サイト内検索ページのnoindexとrobots.txtの選び分け

自社サイトの検索窓から出るページ——/?s= や /search?q= のようなURL——が、Googleの検索結果に出てきてしまう。塞ぎたい。ではrobots.txtに Disallow: /?s= を書けばいいのか、それともテンプレートにnoindexを入れるのか。

先に答えを書きます。「検索結果から消したい」が目的なら、noindexです。robots.txtでは塞ぎません。

やっかいなのは、Googleの公式ドキュメントを読み進めると、robots.txtで塞げと書いてある場所にも行き当たることです。しかもそこには「noindexは使用しないでください」と書いてある。矛盾しているように見えます。実際には、その2つは別の目的について書かれた別の指示です。どちらの目的で読んでいるかが決まれば、選ぶ手段も決まります。

「消したい」と「クロールを減らしたい」は別の問題

まず、検索結果からページを確実に出さないための手段について、公式ドキュメントはこう書いています。

検索の検索結果に表示されるのを確実に防ぐには、サーバー上のファイルをパスワードで保護するか、noindex meta タグまたはレスポンス ヘッダーを使用する、もしくは該当ページを完全に削除する必要があります。 （robots.txt の概要）

robots.txtは、この3つのどれにも入っていません。robots.txtが担当するのはクロール（巡回ロボットがページを見に来ること）の制御であって、インデックス（検索エンジンのデータベースへの登録）の制御ではない、という線引きです。

では、robots.txtで塞いだページはどうなるか。

が表示されることはありますが、説明は表示されません。 （同上）

つまり、塞いでも検索結果に出ることはある。ただしスニペット（検索結果に出る説明文）が出ない状態になる。自社の検索結果ページが、タイトルだけ・説明なしの妙な見た目で検索結果に並ぶ、というのはこの状態です。塞いだのに消えない、ではなく、塞ぐことは消すことではない。

一方で、クロールバジェット（検索エンジンが1つのサイトの巡回に割り当てる処理量の目安）を最適化するガイドは、逆のことを言います。

このリストの最初の項目にあるように重複ページを 1 つにまとめることができない場合は、robots.txt を使用して重要でないページをブロックします。robots.txt を使用して URL をブロックすると、Google がその URL をクロールできなくなり、他の Google システム（Google 検索によるインデックス登録など）でその URL が処理される可能性が大幅に低下します。noindex は使用しないでください。使用した場合、Google は引き続きリクエストしますが、HTTP レスポンスの noindex meta タグまたはヘッダーを確認した時点でページを対象外とするので、クロール時間が無駄になります。 （クロール バジェットを最適化する・強調は引用者）

読み方はこうです。noindexは、クローラーがページを取りに来て、中身を読んで、はじめて効く。だからクロールの回数そのものは減らない。クロール回数を減らしたいという目的にとって、noindexは手段として噛み合っていない——ガイドはそう言っています。

2つの記述は、それぞれ別の目的に向けて書かれています。片方は「検索結果から消す」ための手段の話。もう片方は「重複をまとめられない重要でないページのクロールを減らす」ための手段の話です。自社の検索結果ページは、どちらの文脈にも置こうと思えば置ける。だから、先に目的を決めないと手段が決まりません。

1つめの行が、この記事の読者のほとんどが立っている場所です。検索結果に自社の検索結果ページが出るのが気持ち悪い、という動機はインデックスの話であって、クロール回数の話ではありません。

自分がどちらの行にいるかを、まず確定させる

クロールを減らしたい側の行に移るべきかどうかは、規模で決まります。ここも公式が線を引いています。

このガイドでは、大規模かつ頻繁に更新されるサイトの Google のクロールを最適化する方法について説明します。サイト内で頻繁に更新されるページがそれほど多くない場合や、ページが公開日と同じ日にクロールされると考えられる場合は、このガイドを読む必要はありません。

そして対象読者を、こう名指ししています。

このガイドは上級者向けであり、主に次のようなサイトを対象としています。大規模（重複のないページが 100 万以上）で、コンテンツが中程度に（1 週間に 1 回）更新されるサイト 中規模以上（重複のないページが 1 万以上）で、コンテンツがかなり頻繁に（毎日）更新されるサイト Search Console で URL の大部分が 検出-インデックス未登録 に分類されるサイト

ただし、これらの数値については「サイトを分類する際の大まかな目安です。正確なしきい値ではありません」とも書かれています。厳密な合格ラインではなく、自分がどちらの話をしているかを見分けるための目印として使うものです。

判定は3問で済みます。

1. 重複のないページ数は1万を超えていますか。 超えていないなら、robots.txtでクロールを減らす話は、そもそも自分向けに書かれていない可能性が高いです。
2. 新しく公開したページは、公開当日〜数日でクロールされていますか。 Search Consoleの「URL検査」で最終クロール日時を見れば分かります。当日クロールされているなら、クロールが足りていない兆候はありません。
3. Search Consoleの「ページ」レポートで、「検出-インデックス未登録」がURLの大部分を占めていますか。 一部ではなく大部分かどうかを見ます。

3問とも「いいえ」なら、あなたの目的は「消したい」の一択です。noindexを選び、robots.txtでは塞がない。それで終わりです。クロールバジェットの周辺をもっと詳しく整理したものはクロールバジェットは気にしなくていい？中小サイトの正しい対処にまとめています。

実際にやってみる：/?s= が検索に出ている場合

手順を1本通してみます。CMSの検索機能が https://example.com/?s=キーワード の形でページを返している、という前提です。

1. 何件出ているかを数える。 Googleで site:example.com inurl:?s= のように検索します。ここで出てくるURLの見た目を確認してください。説明文が出ていないURLが並んでいるなら、すでにrobots.txtで塞いでいる可能性が高い。説明文が普通に出ているなら、塞いでおらず素直にインデックスされている状態です。この見分けが、次にどちらの手順を踏むかを決めます。

2. robots.txtで塞いでいないかを確認する。 Search Consoleの「URL検査」に該当URLを入れます。robots.txtでブロックされていれば、その旨が表示されます。ここで塞いでいることが分かったら、先に塞ぐのをやめます。理由は次の節で書きます。

3. noindexを入れる。 検索結果ページのテンプレートに <meta name="robots" content="noindex"> を出力します。HTML以外のリソースにも使える形として、レスポンスヘッダーもあります。

ページをインデックスに登録しないよう検索エンジンに指示する X-Robots-Tag ヘッダーを含む HTTP レスポンスの例を次に示します。 HTTP/1.1 200 OK (...) X-Robots-Tag: noindex

テンプレートに手を入れられない場合や、サーバー側でまとめて処理したい場合はこちらを使います。どちらか一方で足ります。

4. Googlebotが実際に読めているかを確認する。 ここを飛ばす人が多いところです。公式はこう案内しています。

noindex ルールが正しく実装されているかどうかをテストするには、URL 検査ツールを使用して、ページのクロール中に Googlebot が取得した HTML を確認します。

自分のブラウザで表示してソースを見ても、それはGooglebotが取得したHTMLではありません。JavaScriptで後から差し込んでいる場合や、条件分岐でボットに別のHTMLを返している場合、ブラウザでは見えてもGooglebotのHTMLには入っていない、ということが起こります。URL検査ツールの「クロール済みのページ」でHTMLを開き、noindexの記述が実際に入っているかを目で確認してください。

5. 消えるのを待ち、レポートで追う。 Googlebotが読んだ時点で処理されます。

がページをクロールしてタグまたはヘッダーを検出すると、他のサイトがそのページにリンクしているかどうかにかかわらず、そのページを Google 検索結果から完全に削除します。

どのくらいで読みに来るかは、そのページがどれだけクロールされるかによって変わります。待っている間の進み具合は、レポートで追えます。

Search Console の ページのインデックス登録レポート を使用して、Googlebot が noindex ルールを抽出したサイトのページをモニターすることもできます。

「noindexタグによって除外されました」の項目に自社の検索結果URLが積み上がっていけば、指示が読まれている証拠です。1で数えたURLがここへ移ってくるのを確認します。逆に、いつまでも移ってこないなら、2か4のどこかで止まっています。

順序を逆にすると、消えないまま固まる

さきほど「先に塞ぐのをやめます」と書いた理由です。noindexとrobots.txtは、両方やれば二重に安全、にはなりません。

重要: noindex ディレクティブを有効にするためには、robots.txt ファイルでページやリソースをブロックせず、クローラがページにアクセスできるようにする必要があります。robots.txt ファイルでページがブロックされている場合、またはクローラがページにアクセスできない場合、クローラは noindex ルールを認識しません。そのため、たとえばそのページが他のページからリンクされていれば、検索結果に引き続き表示される可能性があります。

順序が逆だと、noindexを書いた紙をドアの内側に貼って、そのドアに鍵をかけているのと同じ状態になります。読む人が入れない。

公式はこの手の衝突を、もっと一般的な注意としても書いています。

注意: 複数のクロールルールやインデックス ルールを併用すると、一部のルールがその他のルールの妨げとなる可能性があります。

だから、すでに塞いでしまっている場合の順序はこうなります。

1. robots.txtの該当する Disallow を外す（クロールを許可する）
2. noindexが入った状態で、Googlebotに読ませる（手順4のURL検査で確認）
3. 検索結果から消えたことを確認する
4. そのうえで、クロールを減らす必要が本当にあるなら、はじめてrobots.txtでのブロックを検討する

4は多くのサイトでは不要です。前の節の3問で「いいえ」が並んだなら、3で終わりにしてかまいません。noindexを入れたままにしておけば、以後もクロールのたびに指示は読まれます。

なお、noindexが読まれない原因はrobots.txtだけとは限りません。設定したのに消えない状況の切り分けはnoindexが効かない原因はrobots.txt｜確実な削除手順で扱っています。

つまずきやすいところ

検索結果ページとカテゴリ・タグページを同じ扱いにしない。 どちらもURLが増えやすい一覧ページですが、性質は違います。カテゴリやタグのページは、そのページ自体を入口として使ってもらう設計がありえます。サイト内検索結果は、訪問者が入力した文字列の数だけURLが生まれ、あらかじめ設計された入口ではありません。一律にnoindexへ寄せるかどうかの考え方はカテゴリ・タグページのnoindexは一律にしない：残す基準と5ステップにまとめています。

site: 検索の結果件数を進捗の指標にしない。 手順1で数えるのは、どのURLがどんな見た目で出ているかを掴むためです。件数の増減そのものは日によって振れることがあるので、消えたかどうかの判定はSearch Consoleのレポート側で見るほうが確実です。

ブラウザで見えるHTMLを根拠にしない。 手順4で書いたとおりです。noindexを「入れたはず」で止まっている案件の多くは、ここを一度も見ていません。

パラメータの書き方を実際のURLに合わせる。 ?s= なのか ?q= なのか /search/ なのかはCMSによって違います。手順1の site: 検索で出てきた実物のURLをそのまま見て、テンプレートのどのファイルがそれを描画しているかを特定してください。想像で書いた条件は、想像どおりの場所には効きません。

自己点検リスト

上から順に見ていって、2行目で引っかかったなら前の節の4ステップへ、3行目で引っかかったならテンプレートの出力へ戻ります。5行目だけが「はい」寄りなら、それはインデックスの問題ではなくクロールバジェット側の話になります。

自社サイトで意図しないURLが登録されていないかを定期的に見ておきたい場合は、Wemiroでインデックスの状況やクロールの傾向をまとめて確認できます。