サイト内検索やカテゴリの絞り込みは、利用者が目的の情報へ早く到達するための機能です。一方で、検索語、並び順、地域、診療科、タグ、ページ番号などをURLパラメータへ追加すると、同じ内容を返すURLや、組み合わせだけが違う薄いページが大量に生まれることがあります。画面上では便利でも、どのURLを検索・AI検索へ公開するかを決めないままでは、内部リンク、サイトマップ、canonical、noindex、robots.txtの方針が食い違います。
Googleは、ファセットナビゲーションが非常に多くのURLを生成し、不要なクロールや新しい有用なURLの発見遅延につながり得ると説明しています。Googleが選ぶcanonical URLは、サイト側の指定どおりになるとは限りません。OpenAIは、ChatGPT検索への掲載候補とするため、OAI-SearchBotのクロールと公開IPレンジからのアクセスを許可するよう案内しています。GoogleとOpenAIのどちらも掲載を保証していません。
この記事では、2026年10月16日時点のGoogleとOpenAIの公式情報をもとに、サイト内検索・絞り込みURLのLLMOを5つの確認に整理します。検索・AI検索への表示、引用、順位、流入を保証するものではありません。JavaScriptで結果一覧を描画するサイトはJavaScriptサイトのLLMO、クローラーごとの役割はAI検索のrobots.txtもあわせてご覧ください。
結論：検索機能ではなく「公開するURL集合」を先に決める
最初に、検索条件ごとのURLを、①固有の需要と内容があり公開候補にする、②元の一覧へまとめる、③検索結果には出さないが利用者には提供する、④結果がなくHTTP 404を返す、のように分けます。検索窓やフィルターの実装だけでなく、URL、本文、内部リンク、canonical、robots指示、サイトマップ、HTTP応答を同じURL台帳で管理します。
すべての絞り込みURLを公開する必要はありません。逆に、利用者が繰り返し探す地域別・用途別の一覧で、固有の説明、安定した掲載対象、通常の内部リンクを持つページなら、独立した固定URLとして設計する余地があります。判断基準はAI向けのページ数ではなく、利用者の疑問へ固有の答えを返せるかです。
サイト内検索・絞り込みURLで揃える5つの確認
1．検索条件を「公開候補・統合・非表示・エラー」に分ける
サイト内検索の入力語、カテゴリ、タグ、地域、日付、並び順、ページ番号、表示件数など、URLを変える条件を一覧にします。それぞれについて、内容が実質的に変わるか、同じ条件が別の順序でも作れるか、検索需要が継続するか、運用担当が内容を更新できるかを確認します。
並び順や表示件数だけが違うURL、セッションID、計測用パラメータ、同じ条件の順序違いは、公開ページとして増やさない設計を優先します。利用者に価値がある固定条件は、機械的な検索結果のままではなく、分かりやすい見出し、対象範囲、選び方、更新責任を持つ一覧ページとして設計します。
2．URLの形と内部リンクを一つに揃える
URLパラメータは、一般的な?key=value&key2=value2形式を使い、同じパラメータの重複、順序違い、大文字・小文字の揺れ、時刻やセッションIDのように短命な値を内部リンクへ含めないようにします。ページ番号には固有URLを持たせ、一覧の先頭だけでなく後続ページの項目へ通常の<a href>リンクで到達できる状態を確認します。
GoogleはURLフラグメントを通常のクロールとインデックスでページ内容の切り替えとして扱わないと案内しています。絞り込みをフラグメントで実装すればクロール対象を増やしにくくできますが、その状態を独立ページとして検索へ出す用途には向きません。残すURLは、ナビゲーション、パンくず、関連記事、サイトマップで同じ表記を使います。
3．canonicalを「重複の代表URL」にだけ使う
内容が同一または非常に近いURLには、代表URLへのrel="canonical"を検討します。Googleではリダイレクト、canonical、サイトマップがcanonical選択のシグナルになりますが、指定は命令ではなく、別URLが代表として選ばれる場合があります。公開候補として残すページには自己参照canonicalを設定し、内部リンクとサイトマップも同じURLへ揃えます。
内容が明確に異なるページを一つへ無理にcanonicalでまとめたり、すべての検索結果をトップページへ向けたりしません。canonicalは、検索意図や内容が弱いページを有用なページに変える仕組みではありません。統合後は、ページ本文、title、見出し、掲載項目が代表URLの役割と一致しているか確認します。
4．noindexとrobots.txtを目的で使い分ける
利用者には必要でも検索結果へ出さないページには、robots metaタグまたはHTTPヘッダーのnoindexを検討します。Googleは、クローラーがnoindexを読むには対象URLへアクセスできる必要があると説明しています。robots.txtで先にクロールを拒否すると、ページ内のnoindexを確認できません。OpenAIの公式クローラー資料では、ChatGPT検索への掲載を管理する自動クロールにOAI-SearchBotを使うよう案内しています。
robots.txtは主にクロール量を管理する仕組みで、非公開化やアクセス制御の代わりではありません。機密情報、個人情報、契約者限定情報は、robots.txtやnoindexだけに頼らず、認証や適切なアクセス制御で保護します。検索結果へ出さない条件と、そもそもクロールを抑える条件を分け、クローラーごとの方針表へ記録します。
5．空結果・ページ送り・実際のクロールを検証する
結果がゼロの条件、存在しないページ番号、重複条件などは、見た目だけの「該当なし」をHTTP 200で返し続けず、用途に応じて適切なHTTP 404を返します。Googleのファセットナビゲーション案内は、結果がない組み合わせや意味のない条件、存在しないページ番号に404を返すよう勧めています。別の共通エラーページへ一律リダイレクトするのではなく、発生したURLで状態を明確にします。
公開後は、代表URL、重複URL、noindex URL、robots.txtで抑えるURL、空結果URLをサンプルで確認します。HTTP応答、HTMLのrobots指示、canonical、内部リンク、サイトマップ、PC・スマートフォンの操作、Search ConsoleのURL検査やクロール統計、サーバーログを分けて記録します。表示できたことと、意図したURLがクロール・インデックスされたことは同じではありません。
URL台帳に残す項目
- 検索・絞り込み条件と、生成されるURL例
- 公開候補、統合、noindex、クロール抑制、404の区分
- 検索意図、固有の本文、更新担当、見直し条件
- 内部リンク元、サイトマップ掲載の有無
- canonical URLと、自己参照・統合先の別
- robots meta、X-Robots-Tag、robots.txtの設定
- PC・スマートフォンでの検索・絞り込み操作
- HTTP応答、描画後HTML、URL検査、ログの確認日
よくある質問
サイト内検索結果はすべてnoindexにすべきですか？
一律には決めません。利用者の一時的な入力語ごとに増える検索結果は公開対象から外すことが多い一方、安定した需要と固有の内容を持つカテゴリ・地域別一覧は、固定ページとして設計できる場合があります。検索機能の種類ではなく、URLごとの内容と運用可能性で判断します。
canonicalを設定すれば、robots.txtは不要ですか？
役割が異なります。canonicalは重複・類似ページの代表URLを示すシグナルで、robots.txtはクロールを管理します。noindexは検索結果への掲載を抑える指示です。どれか一つを万能な削除手段として使わず、公開目的と確認方法を分けます。
絞り込みURLを増やすと、LLMOに有利ですか？
ページ数だけでは有利とはいえません。重複URLや空結果が増えると、利用者が正式なページを判断しにくくなり、サイト側の更新・計測も分散します。AI検索だけのために条件ページを量産せず、実際の疑問へ固有の答えを返せるURLだけを残します。
無限スクロールならページURLは不要ですか？
Googleは、クローラーがボタンのクリックやスクロール操作をしないため、各まとまりへ固有URLを付け、通常のリンクで順に到達できる実装を案内しています。利用者向けの無限スクロールを残す場合も、クロール可能なページ送りと履歴・URLの挙動を別に確認します。
公開前チェックリスト
- URLを変える検索・絞り込み条件を棚卸しした
- 公開候補、統合、noindex、クロール抑制、404に分類した
- 残すURLに固有の疑問、本文、更新責任を設定した
- パラメータの形式、順序、大文字・小文字を統一した
- 内部リンク、canonical、サイトマップのURLを一致させた
- noindexを読ませるURLをrobots.txtで遮断していない
- 機密情報を認証なしで公開していない
- 空結果と存在しないページ番号のHTTP応答を確認した
- PC・スマートフォンで検索・絞り込み・ページ送りを確認した
- URL検査、クロール統計、ログの確認担当と日付を決めた
まとめ：便利な検索機能と、公開するURLの境界を揃える
サイト内検索・絞り込みのLLMOでは、機能を増やす前に、検索・AI検索へ公開するURL集合を決めます。条件を分類し、URLと内部リンクを統一し、重複にはcanonical、検索結果へ出さないページにはnoindex、不要なクロールにはrobots.txtを目的に応じて使い分けます。最後に、空結果、ページ送り、HTTP応答、実際のクロールを同じURL台帳で確認します。
サイト全体のURL変更はサイト移転のLLMO、表示・引用・流入の分け方はLLMOの効果測定、会社情報の基準URLは会社情報のLLMOも参考にしてください。
検索・絞り込みURLの棚卸しを始めたい方へ
株式会社メディカルアトラクトでは、企業・医療機関のサイト内検索やカテゴリ・地域・タグ絞り込みについて、生成されるURL、検索意図、内部リンク、canonical、robots指示、HTTP応答を一つのURL台帳へ整理します。お問い合わせページから、対象サイト、検索・絞り込み機能、増えすぎているURLや確認したい検索結果をお聞かせください。初回の相談では、残す固定ページ、まとめる重複URL、検索結果へ出さない条件、制作会社・開発会社・運用担当の確認範囲を具体化できます。
LLMO支援の考え方はLLMOサービスページ、企画・制作・運用を含む支援範囲はサービスページ、制作・運用例は制作実績ページをご覧ください。
本記事は株式会社メディカルアトラクト編集部（LLMO・Web技術担当）が、GoogleとOpenAIの公表資料を2026年10月16日に確認して作成しました。
参考にした一次情報
- Managing crawling of faceted navigation URLs（Google Crawling Infrastructure、2026年10月16日確認）
- URL structure best practices for Google Search（Google検索セントラル、2026年10月16日確認）
- How to specify a canonical URL with rel=canonical（Google検索セントラル、2026年10月16日確認）
- Robots meta tag, data-nosnippet, and X-Robots-Tag specifications（Google検索セントラル、2026年10月16日確認）
- Pagination, incremental page loading, and their impact on Google Search（Google検索セントラル、2026年10月16日確認）
- Overview of OpenAI Crawlers（OpenAI Developers、2026年10月16日確認）
本記事は2026年10月16日時点の公表資料に基づく一般的なWeb制作・検索運用の整理であり、個別案件への法律上・医療上・セキュリティ上の助言ではありません。検索・AI検索の仕様、クローラー、インデックス、表示形式は変更される場合があります。クロール、インデックス登録、表示、引用、順位、流入、問い合わせ、売上を保証するものではありません。機密情報や個人情報はrobots.txt、canonical、noindexだけで保護せず、認証・権限管理を含む適切な方法を個別に確認してください。本記事はGoogle、OpenAIの提携・監修を受けたものではありません。文中の会社名・サービス名は各社の商標または登録商標です。