新しい検索エンジンを購入する前に、あなたのECサイトの検索機能を40点満点で評価しましょう。

ほとんどのサイト検索プロジェクトは間違ったところから始まります。それはベンダーのデモです。デモは常に機能します。なぜなら、デモはベンダーのインデックスとベンダーのクエリで実行されるからです。一方、Baymard Instituteの2026年の検索ベンチマークでは、 ECサイトの56%は検索UXが平凡かそれ以下である。、そして、失敗は「関連性」全体ではなく、特定の名前の付いたクエリタイプに集中している（Baymard、2026年4月更新新しいエンジンはそれらの問題の一部を解決するが、他の問題は解決しない。

これは、既にお持ちの検索機能を評価するための採点基準です。20項目、各項目2点、合計40点満点です。ご自身のカタログに対して午後に一度この基準を実行すると、数値が得られ、その数値から問題が設定、コンテンツ、または検索エンジン自体のいずれにあるのかが分かります。この基準は、検索予算の妥当性を説明を求められているeコマースのUXリーダー、グロースマネージャー、プロダクトオーナー向けに作成されています。

評価基準が測定するものと、意図的に無視するもの

この評価基準では、検索がユーザーが実際に入力するクエリの種類を理解しているか、入力内容が乱雑でも正しく処理できるか、何も見つからない場合に復旧できるか、そしてこれらの要素を測定できるか、という4つの項目を評価します。抽象的な意味での検索結果ランキングの品質は評価対象に含まれません。ランキングは最後に調整すべき項目であり、誰もが最初に議論する項目でもあります。また、クエリがトークナイザーでエラーを起こしている状態では、ランキングを調整することはできません。

スコアはチェックごとに0、1、または2です。2はテストリストのすべてのクエリに合格したことを意味します。1は主要キーワードには合格したがロングテールキーワードには不合格であることを意味します。0は主要キーワードにも不合格であることを意味します。まずテストリストを作成します。アナリティクスから上位50件のクエリを取得し、次にBaymardの8つのクエリタイプそれぞれについて、ロングテールキーワードが網羅されるように5件ずつクエリを追加します。合計で約90件のクエリになります。モバイル端末でログアウトした状態で、ご自身で実行してください。

20回のチェック

グループ A のしきい値は Baymard が公開しているタイプ別の失敗率に基づいています。非製品検索は 66% のサイトで失敗し、略語と記号の検索は 54% で失敗し、互換性は 44% で失敗し、ユースケースは 43% で失敗します (ベイマード) チェック 11 が存在するのは、サイトのほぼ半分がユーザーに袋小路から抜け出す効果的な方法を提供していないためです (バイマード、2025年2月) チェック 10 と 12 は、同じベンチマークのオートコンプリートとクエリ永続性の結果から来ています (Baymard検索ベンチマーク).

7を詳しくチェック：英語圏以外でのみ出現する折りたたみ式トラップ

チェック7は、市場を静かにゼロにしてしまうため、独立したセクションとして扱う価値があります。ほとんどの検索スタックは、マッチングを行う前にクエリとインデックスを小文字に変換します。英語ではこれは問題ありませんが、トルコ語ではそうではなく、基本的なラテン文字以外の文字を使用する言語では同様の問題が発生します。

Unicodeはトルコ語とアゼルバイジャン語のロケール固有の大文字小文字ルールを定義しています。大文字のI（U+0049）はドットなしの小文字になります。 ı 大文字のİ（U+0131）は小文字の通常のİ（U+0130）に相当します。 i (Unicode SpecialCasing.txt) デフォルトのロケールで小文字に変換するスタックは、「İPHONE」を余分な結合ドットが付いた「i̇phone」に変えたり、製品タイトルの大文字の「I」を間違った文字に変えたりします。すると、クエリとインデックスの両方に含まれる単語について不一致が生じます。エラーは発生しません。在庫しているブランドに対して、結果がゼロになるだけです。

2 つの修正は独立しており、両方が必要です。まず、インデックスとクエリの時点でロケール補正された小文字を適用します。Elasticsearch には、 turkish 連鎖分析装置 apostrophe, turkish_lowercase, turkish_stop, turkish_keywords (NAIST) と turkish_stemmer まさにこの理由で（弾力性のある言語アナライザー) 第二に、発音記号についてはどうするかを別途決定します。トルコの買い物客は日常的に キリフ の キリフ (NAIST) と サルジ の 充電 アクセント付き形式を入力するのが遅くなるキーボードの場合。 asciifolding フィルターは非基本ラテン文字をASCII相当の文字に変換し、 preserve_original オプションは、折り畳まれたトークンと元のトークンの両方を出力するため、完全一致が依然として勝ちます（伸縮自在なASCIIフォールディング) 参照用に折りたたみ、正確性を保つために原本を保管する。

トルコ国外では、同じチェック項目でも地域特有の形式が適用されます。例えば、ドイツ語の複合名詞は、2語のクエリに一致する前に分解する必要があり、フランス語とスペイン語のアクセント記号の入力方法は一貫性がなく、ギリシャ語の語尾にはシグマが付きます。チェック項目7を2点と評価するのは、ストアフロントが実際にサービスを提供しているすべての言語でテストした場合のみにしてください。チームが話す言語でテストしても意味がありません。

まず寸法を修正します：16～20をチェックします

グループ D のスコアが 6 未満の場合、他のものに触れる前に停止して修正してください。見えない修正は検証できないためです。GA4 では、拡張測定が発火します。 view_search_results また、 search_term 結果ページに5つのデフォルトクエリパラメータのいずれかが含まれる場合のパラメータ — q, s, search, query or keyword — そして、あなた自身の意見を追加することもできます（Google Analyticsヘルプ2 つの一般的な失敗モードがあります。結果ページでクエリ文字列ではなくパスセグメントを使用している場合、デフォルトのトラッキングでは何も検出されません。また、オートコンプリートが直接製品に移動する場合、その検索ではイベントがまったく発生しないため、クエリログは最初の試行で何も見つからなかった検索に偏ってしまいます。

スコアを読んでいます

重要なルールは、グループDが作業を開始する前に取得したスコアに基づいて、代替契約に署名してはならないということです。測定されていない検索に基づいて評価されたベンダーは、デモに基づいて評価されます。

皆が引用する数字についての注記

サイト内検索ユーザーは非検索ユーザーよりも2～3倍コンバージョン率が高いという統計が提示されるでしょう。これは通常、予算を正当化するためです。この数字はベンダーのまとめ記事で広く出回っています（例）そして、これは統制された研究に由来するものではほとんどありません。また、これは選択効果でもあります。つまり、検索する人は既に購入意欲を持っている人です。検索を検討する理由として利用すべきであり、決して予測される効果として利用すべきではありません。正当なビジネスケースは、自社の検索結果ゼロ件数と検索から購入に至る割合に基づいて構築されます。チェック17とチェック18は、これらのデータを作成するために存在します。[必要な内部データ：Switasクライアントの修正前後の検索結果ゼロ件数（共有可能な場合）。]

この評価基準が破綻するところ

これはカタログ販売向けに構築されています。同じ商品を多数販売するマーケットプレイスでは、重複出品と販売者の質という側面が必要ですが、この評価基準にはそのための列がありません。コンテンツが豊富なサイトや公共部門のサイトでは、グループAではなく、ドキュメントの種類と最新性による重み付けが必要です。SKUが約500未満のサイトは、スコアは高いものの、検索で損失を出すことがよくあります。これは、カタログが小さい場合、真の解決策は検索の改善ではなく、カテゴリナビゲーションの改善だからです。この評価基準には、負荷がかかった状態での検索速度やパーソナライゼーションについても何も記載されていません。どちらも適切にテストするにはコストがかかり、スコアが30未満の場合はどちらも問題にならないため、意図的なものです。最後に、スコアはスナップショットです。属性名を変更するカタログのインポートは、コードをデプロイしなくても、グループAを一夜にして6ポイント低下させる可能性があります。

FAQ

採点にはどれくらい時間がかかりますか？ 90件のクエリからなるテストリストが完成すれば、1人の担当者が1つのストアフロントを担当する場合、およそ半日かかります。リストの作成が時間がかかる部分なので、上位クエリを抽出してロングテールセットを構築するのにさらに2時間を見込んでおきましょう。

運用するには技術サポートが必要ですか？ いいえ。チェック1～15はブラウザ上で実行されます。チェック16～20には分析アクセス権限が必要で、チェック20については検索設定の所有者との話し合いが必要です。

検索分析履歴がない場合はどうすればよいでしょうか？ グループDのスコアをゼロとし、トラッキングを修正し、残りのグループのスコアリングを行う前に4週間分のデータを収集してください。実際のクエリログを使用せずに作成されたテストリストは、チームが入力するクエリを過剰に反映することになります。

28点というのは良い点数ですか？ それは普通のことだ。普通というのは平凡なレベルだ。ベンチマークによれば、ほとんどのサイトはそのレベルに留まっている。重要なのは全体の数値ではなく、どのグループが全体の数値を押し下げているかだ。

誤字脱字許容度は、購入するべきか、それとも構築するべきか？ 購入してください。適切な閾値を用いた編集距離マッチングは解決済みで、しかも安価です。構築作業は同義語と属性構造に集中すべきですが、これらはカタログ固有のものであり、購入することはできません。

これはカテゴリページの監査とどのように関係するのでしょうか？ これらはファセットとフィルタリングを共有しています。チェック14が失敗した場合、修正箇所は通常、検索ではなくカテゴリテンプレートにあるため、同じスプリントで2つの監査を実行してください。

これらの内容は、当社のカタログを読み上げるAIショッピングエージェントにも当てはまりますか？ 部分的にはそうです。エージェントは検索UIではなく構造化属性を利用するため、グループAとBはデータ品質を通じてエージェントにとって重要になりますが、グループCとDは全く関係ありません。これは別の監査です。

どのくらいの頻度で再採点すべきでしょうか？ 四半期ごと、およびカタログの移行、プラットフォームの再構築、検索設定の変更後に実施してください。スコアを比較可能にするため、同じ90件のクエリリストを使用してください。

午後を費やさずにスコアを知りたい場合： 弊社に貴社のストアフロントでこの監査を実行させてください そして、採点済みの評価基準、不合格となった質問、および優先順位付けされた修正リストをお渡しします。

ソース

• Baymard Institute — Eコマース検索UX：8つのクエリタイプとタイプ別の失敗率（2026年4月更新）
• ベイマード研究所 — Eコマース検索のユーザビリティ：レポートとベンチマーク
• Baymard Institute — 「検索結果なし」ページを改善するための、実証済みの5つのUX戦略（2025年2月）
• Unicodeコンソーシアム — SpecialCasing.txt、トルコ語とアゼルバイジャン語の大文字小文字の規則
• Elastic — 言語アナライザー（トルコ語アナライザーチェーンを含む）
• Elastic — ASCII折りたたみトークンフィルタとpreserve_original
• Google アナリティクス ヘルプ — 拡張測定、view_search_results と search_term について
• Hello Retail — サイト内検索コンバージョン倍率の循環例