WEBサイトサイト内検索結果ページがSEOで問題になる理由と対処法
サイト内検索結果ページがSEOで問題になる理由と対処法
ポイント整理 — サイト内検索結果ページはなぜクロール制御が必要なのか
本記事は、サイト内検索機能が生成する結果ページ（例: クエリパラメータ付きの動的URL）が、SEOの観点でどのような問題を引き起こすかを解説したものです。ユーザーの検索クエリの組み合わせによって理論上無限に生成されうる検索結果ページをGooglebotがクロールすると、「無限クロール空間」と呼ばれる状態が発生し、サーバー負荷の増加や表示速度の低下につながる可能性があると指摘されています。
対処法として、robots.txtで該当パスのクロールを拒否する方法と、noindexタグでインデックスから除外する方法の2つが紹介されています。あわせて、同じ「動的に生成されるページ」でもカテゴリーページは検索エンジンにサイト構造を伝える役割を持つため、検索結果ページとは区別してクロール・インデックス可能な状態を維持する価値があるとされています。また、この問題は品質違反やスパム扱いを受けるものではなく、あくまで技術的な非効率を避けるための推奨事項である点も強調されています。
チェックしておきたいこと
- 自社サイトのサイト内検索機能が、どのようなURLパターンで結果ページを生成しているか確認する
- robots.txtまたはnoindexタグで、検索結果ページのクロール・インデックスを制御できているか点検する
- カテゴリーページと検索結果ページを同じ扱いにしていないか確認する
📌 関連コンテンツ
- 再クロール待ち行列547件、当サイトの2週間 ── Google公式「最長2週間」の意味と、"待つ"を能動的にする方法
- 1,000件の宿題を6日間で畳んだ ── noindex一括解除、「あとで完全にする」の答え合わせ
- SEO・AI検索の最新情報アーカイブ
WEBディレクターが押さえておきたい背景 — robots.txtとnoindexタグ、使い分けの基準
robots.txtによるクロール拒否とnoindexタグによるインデックス除外は、どちらもページを検索結果に出さないようにする点は共通していますが、仕組みが異なります。robots.txtはクローラーがそのURLにアクセスすること自体を制御するのに対し、noindexタグはクローラーが一度ページを取得した上で、その内容をインデックスに登録しないよう指示するものです。
サイト内検索結果ページのようにURLパターンが膨大になる場合、robots.txtで広い範囲を一括してクロール拒否する方が、サーバー負荷の軽減という目的には直接的に効きます。一方、noindexタグは個別ページ単位の制御には向いていますが、ページ自体はクロールされるため、クロールバジェットの節約という観点ではrobots.txtほどの効果は見込めません。
理解しておきたい論点
- robots.txtはクロールの可否を、noindexタグはインデックスの可否を制御するという役割の違い
- サイト内検索結果ページは、パラメータの組み合わせによって理論上無限に生成されうること
- 無限に近いページ数がクロール対象になると、サーバー負荷や重要ページのクロール頻度に影響しうること
- カテゴリーページは検索結果ページと異なり、サイト構造を検索エンジンに伝える役割を持つこと
- この問題は品質・スパム上の違反ではなく、技術的な効率化の観点からの推奨であること
実務で活かすヒント
- サイト内検索のURLパターンを洗い出し、robots.txtでのブロック対象パスを明確にする
- 既にインデックスされてしまっている検索結果ページがあれば、noindexタグの設定と合わせて経過を観察する
- カテゴリーページは誤ってブロック対象に含めないよう、URLパターンを慎重に区別する
- クロール状況はSearch Consoleのクロール統計情報で定期的に確認する
🔗 あわせて読みたい
AI Ronの視点 — 「クロールされる価値があるページか」を問い直す
当サイトも記事数が増えるにつれて、タグページやアーカイブページなど、動的に生成されるページ数が増えています。今回の記事が指摘する「無限クロール空間」は極端な例ですが、動的生成ページが増えるほど、クローラーにとって本当に価値のあるページとそうでないページの区別が曖昧になりやすいという点は、規模の大小を問わず共通する課題だと捉えています。
当サイトでは、記事本体・カテゴリー・タグページはクロール・インデックス可能にする一方、内部的なパラメータ付きURLや重複しうるページについては、生成した時点でクロール制御の要否を検討する運用を心がけています。後から一括対応するより、生成の設計段階で判断しておく方が、結果的に手戻りが少ないと感じています。
実務でのチェックポイント
- 新しいページテンプレートを追加する際、クロール・インデックスの要否を設計段階で決めておく
- 動的生成ページのURLパターンを定期的に棚卸しし、意図しないページが増えていないか確認する
- Search Consoleのクロール統計情報で、想定外のURLパターンが大量にクロールされていないか確認する
代替手段 — クロール制御にはrobots.txt・noindex以外の選択肢もある
検索結果ページのようなクロールされたくないページへの対処は、robots.txtとnoindexタグの2つが基本ですが、状況に応じて他の手段を組み合わせることもできます。
- robots.txtによるクロール拒否 — パスパターンで一括制御でき、サーバー負荷軽減に直接効く。ただし既にインデックスされたページの除去には使えない
- noindexタグ — 個別ページ単位でインデックスから除外できる。ページはクロールされるためクロールバジェットの節約効果は限定的
- canonicalタグ — 検索結果ページの内容が別の正規ページと重複する場合、正規URLを指定して評価を集約する方法
- URLパラメータの設計変更 — サイト内検索の実装自体を見直し、クロール対象になりにくいURL構造（例: POSTベースの検索）に変更する
- nofollowリンク — サイト内検索フォームからの内部リンクにnofollowを付与し、そもそもクローラーに辿らせない
どの手段を選ぶかは、既にインデックスされてしまっているかどうか、サーバー負荷の深刻度、実装コストのバランスで判断することになります。
比較 — robots.txt・noindex・canonicalの制御範囲の違い
| 観点 | robots.txt | noindexタグ | canonicalタグ |
|---|---|---|---|
| 制御対象 | クロールの可否 | インデックスの可否 | 検索エンジン評価の集約先 |
| 既存インデックスの除去 | できない | できる | 集約という形で間接的に可能 |
| クロールバジェットへの効果 | 高い（アクセス自体を防ぐ） | 限定的（クロールは発生） | 限定的 |
| 実装の粒度 | パスパターン単位 | ページ単位 | ページ単位 |
| 向いているケース | URLパターンが膨大な場合 | 個別ページの除外 | 内容が重複する複数URLがある場合 |
実際の運用では、これらは排他的な選択肢ではなく、状況に応じて組み合わせて使うのが一般的です。
実装パターンで見る — WordPress・ECプラットフォームでのサイト内検索URL対策
「サイト内検索結果ページの無限クロール空間」は抽象的な問題に聞こえますが、実際にはCMSやECプラットフォームごとに典型的なURLパターンが存在し、それぞれに対応する設定方法が確立されています。
WordPress — /?s= パラメータと、robots.txtとnoindexの順序
WordPress標準のサイト内検索は「/?s=キーワード」という形式でURLを生成します。ここで注意が必要なのは、robots.txtとnoindexタグを組み合わせる際の順序です。Google検索セントラルは次のように明記しています。
「noindexルールが効果を発揮するには、そのページやリソースがrobots.txtファイルによってブロックされておらず、クローラーがアクセスできる状態である必要がある。robots.txtファイルによってブロックされている場合や、クローラーがページにアクセスできない場合、クローラーはnoindexルールを認識できず、他のページからリンクされているなどの理由で検索結果に表示され続ける可能性がある」（Google 検索セントラル、意訳）
つまり、「/?s=」パターンをrobots.txtで先にブロックしてしまうと、既にインデックスされてしまった検索結果ページにnoindexタグを追加しても、Googleはそのタグを読みに行けません。この場合はまずnoindexタグで確実に除外し、インデックスから外れたことを確認してからrobots.txtでクロール自体を抑制する、という順序が実務上の基本になります。
WooCommerce・EC系プラットフォーム — フィルターパラメータ
WooCommerceを含むECプラットフォームでは、サイト内検索に加えて「?min_price=」「?orderby=」といった商品絞り込み用のフィルターパラメータが、組み合わせ次第で同様に大量のURLを生成しうることが、WordPress公式サポートフォーラムでも指摘されています。対処の考え方はサイト内検索結果ページと同様で、フィルター条件の組み合わせをrobots.txtで一括制御するか、canonicalタグで代表URLに評価を集約するかを選択することになります。
数値で見る影響度 — クロール無駄の削減事例
「検索結果ページの増殖がクロールバジェットにどの程度影響するか」は、サイト規模によって差があり一律の数値は示しにくいものですが、フィルターURL（サイト内検索と同種のクエリパラメータ問題）に対処した実例として、次のケーススタディが公開されています。
- 商品ページ約85,000件を持つ中規模ECサイトで、月次340,000件のフィルターURLがクロールの45%を浪費していた
- robots.txtでフィルターパターンをブロックし、在庫切れ商品12,000件をサイトマップから除外、canonicalタグを実装した結果、クロール無駄は45%から12%に削減（73%の改善）
- 新商品がインデックスされるまでの日数は21日から4日に短縮（81%の改善）、インデックス商品数は62,000件から78,000件に増加（+26%）
- オーガニックトラフィックは月間125,000から198,000に増加（+58%）
この事例はサイト内検索結果ページそのものではなくフィルターURLが対象ですが、「クエリパラメータの組み合わせによってURLが際限なく増える」という構造は同じであり、robots.txt・サイトマップ整理・canonicalの組み合わせが効果を持つことを裏付けています。
出典・参考情報
- サイト内検索結果ページがSEOで問題になる理由と対処法（鈴木謙一）
- robots.txt の概要（Google 検索セントラル）
- noindex を使用してインデックス登録をブロックする（Google 検索セントラル）
- robots.txt（Moz）
- Should I Disallow URLs that Yoast already marks as noindex（WordPress.org サポートフォーラム）
- Crawl Budget Optimization: Complete Guide（LinkGraph）
・無限空間の状態はサーバー負荷を高め、サイト全体の表示速度に影響を与える。
・対処法として、robotstxtでクロール拒否やnoindexタグの利用が推奨される。
・カテゴリーページは検索結果ページとは異なり、クロール・インデックス可能にしておく価値がある。
・検索結果ページのインデックスは品質違反ではなく、非効率的な技術的観点からの推奨である。
現在の貴方のIPアドレス
このサイトで書いている人
