結論
サイト内検索・絞り込み機能を安全に移行するには、現行の検索対象、よく使われる検索語、ゼロ件になる語、絞り込み条件、結果ページのURL、計測方法を先に棚卸しします。新サイトでは、検索できる情報と公開範囲、語の揺れ、結果順位、絞り込みの組み合わせ、ゼロ件時の案内をテスト表へ落とし込み、検索する経路だけでなくカテゴリやナビゲーションからも主要情報へ到達できる状態を公開条件にします。公開前後で同じ代表クエリを比較し、異常時に旧設定へ戻せるよう、検索インデックスと画面の切替・復旧手順を分けて用意することが重要です。
検索窓ではなく、利用者の探し方と検索対象を棚卸しする
移行前に、検索窓の位置やデザインだけを決めると、現行サイトで見つかっていた情報が新サイトでは出ない、非公開情報が候補に混ざる、同じ内容が重複表示されるといった問題を見落とします。最初に、検索対象となるページ・PDF・お知らせ・事例・商品・施設等の種類、公開状態、更新元、検索結果へ出すタイトル・説明・画像・日付を一覧にします。会員限定、公開前、終了済み、保存用の資料など、検索対象から外す条件も明記します。
現行の検索ログ、問い合わせ、窓口で繰り返し聞かれる言葉を照合し、利用者が入力する語と組織内の正式名称の差を確認します。略称、旧名称、表記揺れ、地域名、型番、制度名など、同じ情報へ到達させたい語を対応表にします。一方、個人名や入力内容がログへ残る場合は、取得目的、閲覧権限、保存方法を確認し、検証用データへ実在する個人情報を使いません。検索機能を残す理由と対象が説明できない場合は、まずカテゴリや導線の改善で解決できないかを判断します。
- 検索対象と対象外をコンテンツ種別ごとに定義
- 結果に表示する項目と正本を確認
- 検索ログ・問い合わせ・現場の呼び方を照合
- 略称・旧名称・表記揺れの対応表を作成
- 検索データの閲覧権限と保存条件を確認
検索インデックス・絞り込み・URLを一つの設計表へまとめる
新サイトでは、どの情報を検索インデックスへ登録し、いつ更新し、削除や公開終了をどう反映するかを決めます。CMSで公開した直後に反映する情報、定期更新する情報、外部システムから連携する情報を分け、更新失敗時の検知方法と担当者を置きます。結果順位はツール任せにせず、語の一致、情報の現行性、対象地域、重要ページ等、業務上必要な優先条件を整理します。広告枠やおすすめ表示がある場合は、通常の検索結果との違いを利用者が判断できる表示にします。
絞り込みは、部門が持つ項目をすべて並べるのではなく、利用者が候補を減らす判断に使う条件へ絞ります。カテゴリ、地域、対象者、年度、受付状況などの値を新旧で対応させ、名称変更・統合・廃止を記録します。Googleは、URLパラメータを使うファセットナビゲーションが多数のURLを生む場合があると説明しています。検索結果や絞り込みURLを検索エンジンへ出す必要があるかを条件ごとに決め、クロール制御、canonical、内部リンク、サイトマップの扱いを同じ設計表で管理します。
- インデックス登録・更新・削除の条件
- 結果順位とおすすめ表示の根拠
- 新旧の絞り込み項目・値の対応
- 組み合わせごとのURLと公開価値
- クロール・canonical・内部リンク・サイトマップ

代表クエリ表で、見つかる・見つからないを対で検証する
公開前に、現行サイトで利用の多い語、重要情報の正式名称、略称、漢字・かな・英数字の揺れ、複数語、結果がない語を代表クエリ表へまとめます。各行に、期待する上位結果、対象件数の目安、利用できる絞り込み、対象外にすべき情報、確認担当を記載します。完全一致だけでなく、語を一部入力した場合、余分な空白、全角・半角、条件を複数選んだ場合、並び替え、ページ移動、条件解除後も確認します。
ゼロ件は単なる失敗画面にせず、入力した語と選択条件を保持したまま、条件解除、表記の確認、関連カテゴリ、主要案内、問い合わせ等の次の手段を示します。ただし、結果がないのに無関係なページを検索結果として混ぜると、利用者は情報の有無を判断できません。検索対象外の重要ページがある場合は検索機能だけを直すのではなく、ナビゲーションやサイトマップから到達できるかも確認します。W3CのWCAG 2.2解説では、ページを見つける方法を複数用意する考え方が示され、検索はその一つの例として扱われています。
- 頻出語・重要語・表記揺れ・複数語を準備
- 期待する上位結果と対象外情報を明記
- 絞り込み・並び替え・ページ移動を確認
- ゼロ件時に条件解除と別導線を提示
- 検索以外のナビゲーションでも到達可能
キーボード操作と結果更新の伝わり方を公開条件にする
検索入力、候補表示、検索ボタン、絞り込み、並び替え、ページ移動、条件解除をキーボードだけで操作し、現在位置と選択状態が見えるかを確認します。入力欄には用途が分かるラベルを設け、検索アイコンだけに意味を任せません。候補を表示する場合は、上下移動・選択・閉じる操作と読み上げ順を確認します。スマートフォンでは、入力中に候補や固定要素が検索欄を隠さないか、絞り込みを開閉した後に結果へ戻れるかも実機相当の幅で確認します。
非同期で結果を更新する場合、画面を見ている人だけに件数変化が伝わる実装を避けます。W3CのStatus Messages解説では、検索中、結果件数、ゼロ件等の短い状態通知が、フォーカスを移さなくても支援技術で把握できる例が示されています。結果一覧そのものへ毎回フォーカスを強制するのではなく、入力・条件変更・読み込み・完了・エラーの状態を適切に伝えます。自動検査だけで合格とせず、キーボード、読み上げ、拡大、スマートフォン表示を代表クエリで操作して確認します。
- 入力から結果閲覧までキーボードで操作
- ラベル・選択状態・現在位置を確認
- 候補表示を開く・選ぶ・閉じる操作を確認
- 結果件数・ゼロ件・エラーを状態通知
- スマートフォンと支援技術で代表クエリを確認
公開前後を同じ検索品質表で比較し、計測と切り戻しまで行う
公開判定では、代表クエリの合格率だけでなく、検索対象の更新、対象外情報の除外、主要な絞り込み、ゼロ件表示、権限、負荷、計測を確認します。新しいインデックスを先に準備して切替できるか、画面だけ旧版へ戻せるか、検索サービス自体を停止したときにカテゴリ導線で補えるかを整理します。切り戻し条件は、検索不能、重要情報の欠落、非公開情報の表示、著しい遅延等に分け、判断者、復旧方法、利用者への案内を公開前に決めます。
公開後は同じ代表クエリを正式サイトで再実行し、検索語、結果件数、ゼロ件、結果選択、絞り込み利用を確認します。Googleアナリティクスの拡張計測では、指定されたURLクエリパラメータをもとにサイト内検索のview_search_resultsイベントとsearch_termを記録できますが、実際の検索URLと設定が一致しているか、収集してよい値だけかを確認します。件数だけを成果にせず、重要情報へ到達できたか、ゼロ件語を本文・同義語・導線のどこで改善するかを月次の判断材料にします。
- 代表クエリを新旧・公開前後で比較
- 対象外情報・負荷・権限・更新反映を確認
- 重大度別の切り戻し条件と責任者を決定
- 検索語・ゼロ件・結果選択・絞り込みを計測
- ログを本文・同義語・導線の改善へ戻す
よくある質問
現在と同じ検索サービスを使えば、移行テストは不要ですか?+
必要です。同じサービスでも、対象ページ、CMSの項目、URL、公開状態、絞り込み値が変われば結果は変化します。代表クエリ表を使い、新旧で上位結果、除外情報、ゼロ件、更新反映を比較してください。
検索結果がゼロ件のとき、TOPへ自動転送してもよいですか?+
通常は、検索語や条件を確認できなくなるため避けます。ゼロ件であることを明示し、入力語と条件を保持したうえで、条件解除、表記確認、関連カテゴリ、主要案内、問い合わせ等の次の選択肢を示します。
絞り込み結果のURLは、すべて検索エンジンへ登録すべきですか?+
一律には登録しません。独自の需要と内容を持つ組み合わせか、重複やゼロ件を大量に生まないかを確認します。登録不要な条件はクロールや内部リンクの扱いを設計し、価値がある条件は安定したURL・本文・canonical・サイトマップを揃えます。
参考にした一次情報
- Google for Developersファセット ナビゲーション URL のクロール管理↗
- Google アナリティクス ヘルプ拡張計測機能イベント↗
- W3C Web Accessibility InitiativeUnderstanding Success Criterion 2.4.5: Multiple Ways↗
- W3C Web Accessibility InitiativeUnderstanding Success Criterion 4.1.3: Status Messages↗
外部仕様は変更される場合があります。最新情報は各公式ページをご確認ください。
提供サービス:FIRST INNOVATION WEB

