robots.txtでは隠せない──テスト環境のインデックス対策
社名で検索したら、staging. から始まるURLが並んでいた。robots.txt には Disallow を書いてあるのに。
原因はたいてい、道具の選び間違いです。Google の robots.txt ドキュメントには、robots.txt はサイト上のURLへの検索クローラーのアクセスを管理するもので、主にサーバーの過負荷を避けるためのものだと書かれています。そして、そこにこう続きます。「Google からページを隠すためのものではない。noindex かパスワードを使うこと」。
隠す道具ではないものを、隠すために使っていた。それだけの話です。
Disallow は「来ないでくれ」であって「載せないでくれ」ではない
robots.txt に書けるのは、クローラーの巡回（クロール）についての指示です。検索結果への登録（インデックス）そのものを止める指示ではありません。
同じドキュメントは、画像・動画・音声ファイルについては robots.txt でGoogle検索の結果に出ないようにできる、とも書いています。ただしその直後に但し書きが付きます。他のページや利用者が、そのファイルにリンクすることまでは防げません。robots.txt が触れているのは自分のサーバーへのアクセスであって、外の世界ではない、ということです。
だからテスト環境を守るときは、まず問いを立て直します。「クローラーに来てほしくない」のか、「検索結果に出したくない」のか。後者なら robots.txt では届きません。
noindex を効かせたいなら、先にクロールを許可する
ここが、多くのテスト環境がはまる矛盾です。
noindex は、クローラーが読み取って初めて効く設定です。公式ドキュメントは注意書きとしてはっきり書いています。noindex ルールが有効であるためには、そのページやリソースが robots.txt でブロックされていてはいけません。同じページには、noindex を入れたのに消えない理由として、robots.txt がそのURLをGoogleのクローラーからブロックしているためタグが見えない、というケースも挙がっています。
robots.txt で塞いだ上に noindex も入れる。二重の守りのつもりが、実際には塞いだ側が noindex を無効化しています。
読み取ってもらえた場合の効き目は強力です。Googlebot がそのページをクロールしてタグやヘッダーを取り出すと、他のサイトからリンクされているかどうかに関係なく、Google はそのページを検索結果から完全に削除する、と書かれています。
書き方は2通りあります。HTMLの <head> に <meta name="robots" content="noindex"> を置くか、HTTPレスポンスヘッダーで X-Robots-Tag: noindex を返すかです。Googleのクローラーだけを対象にしたいなら <meta name="googlebot" content="noindex"> という書き方も示されています。ヘッダーのほうは、PDF・動画ファイル・画像ファイルのようなHTML以外のリソースにも使えると明記されています。
なお公式は、noindex ルールの解釈は検索エンジンによって異なる場合がある、とも添えています。Google以外まで一律に消える前提で設計しないほうが安全です。
公式が挙げるブロック方法と、公式が付けた但し書き
「検索エンジンでの表示を管理する」のドキュメントには、コンテンツをブロックする方法として、サイトから削除する・ファイルをパスワードで保護する・noindex ルールを使う・robots.txt でクロールを拒否する・特定のGoogleプロダクトからオプトアウトする、が並んでいます。
ここに順位は付いていません。ただし但し書きが2つあります。削除ツールのヘルプでは、恒久的な手当てとして「パスワードを要求する」ことを挙げた直後に noindex メタタグを示し、こちらは他の方法より安全性が低い、と添えています。robots.txt については、ブロックの仕組みとして使わないこと、と書かれています。
以下の並びは、この2つの但し書きを手がかりにした検討順です。
| 方法 | 公式ドキュメントでの位置づけ | テスト環境での使いどころ |
|---|---|---|
| サイトから削除する | ブロック方法の一つとして明記 | 役目を終えた検証環境。残す理由がないなら消すのが一番速い |
| パスワードで保護する | 恒久的な手当てとして「パスワードを要求する」形で挙がる | 本命。関係者だけが見られればよいテスト環境の性質と噛み合う |
| noindex ルール | 有効。ただし「他の方法より安全性が低い」 | 認証を掛けられない事情があるときの次善。robots.txt の許可とセット |
| robots.txt でクロール拒否 | 「ブロックの仕組みとして使わないこと」 | 隠す目的では使わない。noindex を選ぶなら、むしろ許可側に回す |
| 特定のプロダクトからオプトアウト | ブロック方法の一つとして明記 | 表示先を絞る話。テスト環境を隠す用途とは別 |
二つめのパスワード保護が、冒頭の staging. が並んでしまったケースの答えになります。関係者以外が本文を取得できない状態にしておくのが、いちばん手数の少ない守りです。三つめの noindex は、認証を掛けると動かない外部連携がある、といった事情の逃げ道。そして四つめの robots.txt は、隠す目的の候補から外してかまいません。
すでに検索結果に出てしまったURLの片づけ方
出てしまったあとは、時間稼ぎと恒久対策を並行させます。
- ステージングのホストが自分のSearch Consoleプロパティに入っているか確認する。 削除ツールのヘルプは、対象URLが自分が所有するSearch Consoleプロパティ内にあることを条件として最初に挙げています。本番ドメインだけ登録していて、サブドメインは未登録、という状態はよくあります。ここが欠けていると次に進めません。
- 削除ツールを開き、「一時的な削除」タブから新しいリクエストを作る。 手順もその順で書かれています。あくまで一時的にブロックするための機能なので、これ単体で終わりにはできません。
- 時間稼ぎをしている間に、恒久的な手当てを入れる。 パスワード保護が第一候補、掛けられないなら noindex です。
- noindex を選んだなら、robots.txt の Disallow を外す。 前の節のとおり、ブロックされたままではタグが読まれません。守りを足すつもりで足したものが、ここでは邪魔になります。
- 送るURLはホスト単位で厳密に扱う。 ヘルプには、
m.やamp.のようにサブドメインが違えば一致しない、と例つきで書かれています。http://m.example.com/mypageは一致しない、という具体例です。ステージングが複数ホストに分かれているなら、それぞれ送ります。 - 説明文だけ消したいときは別の選択肢がある。 削除ツールには、検索結果のページ説明（スニペット）を消す機能もあります。次にインデックスされ直すまで説明文が消え、その後は新しい内容から生成される、という説明です。
順番についての注意も、ヘルプに書かれています。コンテンツを恒久的に削除する手順の中で、事前にページをブロックしていた場合は、いったん解除してから再びブロックし直すよう案内されています。塞いだまま消しても片づかないことがある、ということです。
自分の環境で30分で確かめる
設定したつもりで終わっているケースが一番多いので、外から実際に取りに行って確かめます。staging.example.com を例に、順番に手を動かします。
- 社内ネットワークの外から取得を試す。 スマートフォンのテザリングなどでIPを変え、
curl -i https://staging.example.com/を実行します。オフィスのIPだけ認証を素通りさせる設定になっていると、社内からの確認はいつまでも正しく見えません。 - 本文が返ってきたかどうかだけを見る。 認証を掛けたつもりのホストからHTMLの本文が丸ごと返ってくるなら、そのホストには掛かっていません。ここで止めて、サーバー設定に戻ります。
- 認証を掛けられない事情があるなら、noindex の現物を確認する。
curl -sI https://staging.example.com/ | grep -i x-robots-tagでヘッダーを見て、あわせてHTMLの<head>に meta タグが実際に出力されているかを、ページのソースで確かめます。テンプレートの条件分岐で本番だけ出力される、といったずれが見つかることがあります。 - 同じURLが robots.txt で拒否されていないか照合する。
https://staging.example.com/robots.txtを開き、noindex を効かせたいパスが Disallow に入っていたら外します。 - Search Consoleのプロパティ登録状況を見ておく。 万一インデックスされたときに削除ツールを使えるかどうかが、ここで決まります。登録は事故が起きる前に済ませておくほうが速いです。
- 確認した日付と結果を残す。 環境は作り直されます。次にステージングを立て直した人が同じ確認をできるよう、手順ごと置いておきます。
ひととおり通したら、次の表に自分のケースを当てはめてください。
| 確認したこと | 結果 | 次にやること |
|---|---|---|
| 外部から本文が取得できるか | 取得できない（認証あり） | 完了。robots.txt を隠す目的で使っているなら外してよい |
| 外部から本文が取得できるか | 取得できる | 認証を掛ける。掛けられない事情があるなら noindex へ |
| noindex を選んだ | 同じURLを robots.txt で Disallow している | Disallow を外す。読まれない noindex は効かない |
| noindex を選んだ | ヘッダーにも meta タグにも出ていない | テンプレートの環境判定を疑う。本番だけ出力されていないか |
| すでに検索結果に出ている | Search Consoleプロパティがある | 一時的な削除で時間を稼ぎ、その間に認証か noindex を入れる |
| すでに検索結果に出ている | プロパティがない | まずプロパティを登録する。削除ツールの前提条件 |
つまずきやすいところ
「noindex を入れたのに消えない」という相談の多くは、四つめの行に落ちます。robots.txt がクローラーからURLをブロックしていてタグが見えない、というケースが公式にも理由として挙げられています。守りを足したつもりで、守りを壊しているわけです。
もうひとつは、テスト環境を丸ごと Disallow: / にしておけば安心だ、という思い込み。robots.txt は「Googleからページを隠すためのものではない」と公式が名指しで否定しています。安心の根拠がドキュメントのどこにも無い状態で運用している、ということになります。
画像や動画をテスト環境に置いている場合も、扱いは同じ線で考えます。robots.txt でメディアファイルが検索結果に出ないようにはできますが、他のページや人がそのファイルにリンクすることまでは防げない、と書かれています。防ぎたいのが露出そのものなら、やはり認証です。
noindex が効かない症状そのものの切り分けは noindexを設定したのに検索結果から消えない原因 に手順があります。同じ robots.txt でAI向けクローラーの扱いも決めるなら、Google-Extendedの設定と検索への影響 が近い話です。
出典