robots.txtとnoindexの違い｜遮断で一緒に失うもの

「このページは検索に出したくない」と思ったとき、robots.txtで塞ぐのとnoindexを入れるのは、目的が似ているだけでやっていることが正反対です。混同したまま片方だけを使うと、消したいURLが消えないどころか、消すつもりのなかった検索結果のサムネイル画像まで一緒に失います。

先に結論を書きます。使い分けはこの表で決まります。

やりたいこと	使うもの	理由
検索結果に出したくない	noindexメタタグ	クローラーにページを読ませたうえで「載せるな」と伝える
クローラーに読ませたくない（負荷・非公開領域）	robots.txt	アクセス自体を遠慮してもらう。載る載らないは制御しない
検索結果から確実に消したい	noindex（robots.txtでは塞がない）	塞ぐとnoindexが読まれず、逆に消えなくなる
人にも見せたくない	Basic認証・IP制限	robots.txtは紳士協定であって、アクセス制限ではない

ポイントは3行目です。robots.txtで丸ごと遮断すると、noindexを書いても効きません。クローラーはそのページを読みに行かないので、「載せるな」という指示に到達できないからです。結果として、本文の中身を知らないままURLだけが検索結果に残る状態が起こり得ます。塞いだのに消えない、という一見矛盾した現象の正体はこれです。

以下、この使い分けを間違えたときに実際に何が起きるかを、自社サイトで観測した数字で説明します。

robots.txtは「読むな」、noindexは「載せるな」

まず役割を整理します。

robots.txtは、サイトの入り口に置く案内板です。「この階層には入らないでください」とクローラーに伝えます。守るかどうかは相手次第で、主要な検索エンジンは守りますが、強制力はありません。アクセス制限ではないので、URLを知っている人は普通に開けます。

noindexメタタグは、ページのHTMLの中に書く指示です。<meta name="robots" content="noindex"> の1行で「このページは読んでいいが検索結果には載せるな」と伝えます。HTMLの中にあるので、ページを読んでもらえなければ存在しないのと同じです。

この2つは併用しても、片方が無効になります。robots.txtで塞いだ階層にnoindexを書いても、クローラーはHTMLを取得しないため、その1行は永久に読まれません。

したがって、検索結果から消したいなら、robots.txtでは塞がずにクロールさせるのが正解です。逆に感じるかもしれませんが、「読ませて、読んだうえで載せないでもらう」以外に消す手段はありません。

丸ごと遮断すると、検索結果のサムネイルが消える

もう1つ、遮断の副作用として見落とされやすいのが画像です。ここには先に守るべきルールがあります。検索結果に出したい画像は、robots.txtで遮断していないドメインから配信する。これを外すと、画像が正常に存在していても検索結果には出ません。

具体的に見ます。編集用のWordPressを管理用サブドメインに置き、表示側は静的サイトとして本番ドメインで配信する構成は、表示速度と運用の分離という点で有利です。自社サイトもこの構成をとっています。管理用サブドメインは検索結果に出す必要がないので、robots.txtに Disallow: / を置いて全面遮断します。ここまでは設計どおりです。

ここで確認が要るのが、表示側の記事が指しているOGP画像（og:image）の置き場所です。

記事のアイキャッチ画像は編集用WordPressにアップロードされるため、何もしなければ画像のURLも管理用サブドメインを指します。画像ファイル自体はHTTP 200で正常に配信されており、ブラウザで開けば普通に表示されます。人間には見えているので気づけません。しかしクローラー側から見れば、そのドメインは Disallow: / で入るなと言われている領域です。

自社サイトで実際に測ったところ、この状態では記事168本すべてで、検索結果のサムネイル画像とDiscoverへの表示、構造化データの画像指定が機能していませんでした。画像は存在し、配信もされ、記事のHTMLにもog:imageとして書かれている。それでも取得できない、という状態です。

これは「robots.txtで塞ぐ範囲」を、ページ単位ではなくドメイン単位で考えたときに起こります。塞ぐ対象は管理画面のつもりでも、そのドメインに置いてある画像・CSS・JSも同じ扱いになるという点が抜けやすいところです。ヘッドレス構成に限らず、テスト用サブドメインから画像を借りている場合も同じことが起こります。

対処と実測値

対処は、画像を検索させたいドメイン側へ移すことです。自社では、サイトのビルド時に編集用WordPressからアイキャッチ画像を取得し、1200×630ピクセル・JPEG品質82に圧縮して本番ドメイン配下へ書き出す処理を追加しました。og:imageと構造化データの画像指定を、その本番ドメインのURLに差し替えます。

実測値は次のとおりです。

項目	数値
生成した画像	167枚
1枚あたりの平均容量	約69KB
サイト全体の容量増分	約11.25MB
差し替え後の確認	全記事のog:imageが本番ドメインを指し、HTTP 200

原寸のまま載せれば約30MBになる計算だったので、圧縮を挟んで3分の1に収めています。アイキャッチが設定されていなかった記事は、サイト共通の既定OGP画像へ退避させました。画像生成が全部失敗しても既定画像に落ちてビルドは通るようにしてあります。ここを止めると記事更新そのものが止まるためです。

なお、この対処で直るのはOGP画像だけです。記事本文中に貼られている画像は依然として編集用ドメインから配信されているため、Google画像検索には載りません。本文画像も移すなら、OGP用の1200×630をそのまま流用してはいけません。本文中の見た目が変わるので、別サイズで生成し直す必要があります。ここは分けて考えてください。

管理用ドメイン・テスト環境の正しい塞ぎ方

では、編集用WordPressやテスト環境のように「検索に出したくないが、システムからは読ませたい」領域はどう塞ぐのが正解か。手順に落とすとこうなります。

1. サイトを置く前にrobots.txtを先に置く

新しいサブドメインを作ってからWordPressをコピーすると、コピー完了から遮断設定までの間、無防備な状態が発生します。この隙間にクロールされると、後から消す作業が発生します。

空のディレクトリの段階で Disallow: / のrobots.txtを置いてから、中身をコピーする。この順番にするだけで露出時間はゼロになります。

2. WordPressの設定と物理ファイルを二重にする

WordPressには「検索エンジンがサイトをインデックスしないようにする」という設定があります。これを有効にすると、全ページにnoindexメタタグが出力され、同時に仮想的なrobots.txtも生成されます。

ただし仮想robots.txtは、キャッシュプラグインや他のプラグイン、サーバー設定の影響を受けることがあります。確実に効かせたいなら、公開ディレクトリ直下に物理ファイルとしてrobots.txtを置くのが安全です。物理ファイルがあれば、WordPressが生成する仮想ファイルより優先されます。

この二重化には役割分担の意味があります。noindexメタタグ（WordPress設定）が「載せるな」を担当し、物理robots.txtが「無駄に読みに来るな」を担当するという形です。

3. 公開動線に載るページだけAllowを切る

ここが最も間違えやすい部分です。全面 Disallow: / にすると、前述のとおりnoindexが読まれません。管理用ドメインの中に外部からリンクされるページが1枚でもある場合、そのURLだけが中身不明のまま検索結果に載る可能性が残ります。

実際にこの設計が必要になったのが、ある医療機関のサイト移行案件でした。新サイトは静的構成で作りましたが、採用ページだけは既存のWordPressをそのまま使う判断をしたため、管理用ドメインの一部が公開動線に載る状態になりました。

このとき採用した設定はこうです。

User-agent: *
Disallow: /
Allow: /recruit/
Allow: /entry/
（以下、公開動線に載る数ページのみ列挙）

公開動線に載るページだけクロールを許可し、そのページ側にnoindexメタタグを書く。こうするとクローラーはページを読める→noindexを読める→検索結果に載せない、という流れが成立します。全面遮断のままだと、この流れが途中で切れてURLだけが残ります。

4. Basic認証をかけるかどうかは、システム連携で決まる

「そもそもBasic認証で閉じればいい」という判断もあり得ます。人にもクローラーにも見せない、最も確実な方法です。

ただし、その領域をシステムが読みに行っている場合は使えません。自社と前述の医療機関の案件では、表示側のサイトをビルドするときにWordPressのREST APIから記事データを取得しています。Basic認証をかけると、この取得が認証エラーで落ちてサイトのビルドが止まります。

判断基準はシンプルです。

• 人もシステムも読まない領域 … Basic認証・IP制限をかける
• システムだけが読む領域 … 認証はかけず、robots.txt＋noindexで検索側だけ塞ぐ
• 一部を人に見せる領域 … 全面Disallowにせず、見せるパスだけAllow＋noindex

robots.txtで一緒に確認しておくこと

robots.txtを触るタイミングで、同じファイルに書くsitemapの宣言も確認してください。ここも実害が出やすい箇所です。

自社サイトでは、robots.txtに書かれていたサイトマップのURLが存在しないファイルを指していたことがありました。宣言としては書いてあるので設定漏れには見えず、実際には記事のサイトマップが1本も検索エンジンへ届いていない状態が続いていました。

もう1つ、サイトを移行したあと、旧ディレクトリのサイトマップ宣言が残っているケースも要注意です。新旧どちらのURLも「これが正しいページです」と申告することになり、同じ記事が2つのURLで評価される状態を自分から作ることになります。移行時は、301転送・canonicalの統一とセットで、robots.txtのsitemap宣言も差し替えてください。

確認方法は単純です。ブラウザで https://自分のドメイン/robots.txt を開き、書かれているサイトマップのURLをそのままクリックする。開けば正常、404なら届いていません。これは費用ゼロ・数分で終わります。

よくある質問

Q. robots.txtで塞げば、そのページは検索結果から消えますか

消えません。むしろ、既に検索結果に載っているページをrobots.txtで塞ぐと、noindexを読ませる手段が消えるため残り続けます。消したいなら、robots.txtの記述を外してクロールさせ、ページ側にnoindexを入れてください。消えるまでには再クロールを待つ時間がかかります。

Q. noindexを入れたページは、リンクされても評価されませんか

noindexは「検索結果に載せない」という指示で、ページ自体は読まれます。リンクをたどってほしくない場合は別途 nofollow を併記します。サイト内の回遊を残したい場合は noindex, follow とするのが一般的です。

Q. 管理用のサブドメインを全面Disallowにしていますが、問題ありますか

そのドメインから画像やCSSを本番側で参照していないかを確認してください。参照している場合、それらは検索エンジンから取得できない扱いになります。特にOGP画像は、ブラウザでは正常に表示されるため気づきにくい箇所です。本番ドメイン側から配信するように変えるのが確実です。

Q. テスト環境が検索に出てしまいました。どうすればいいですか

まずページ側にnoindexを入れ、robots.txtで塞いでいる場合はその記述を外してクロールさせてください。塞いだままだと消えません。消えたことを確認してから、改めて塞ぐか、Basic認証に切り替えます。順番を守らないと、消したい状態のまま固定されます。

Q. 検索から消したページは、公開自体をやめるべきですか

用途によります。会員向けページや申込フォームの完了画面のように、人には見せるが検索には出さないページは、noindexのまま公開して問題ありません。noindexは非公開設定ではないという点だけ、社内で共有しておくと事故が減ります。

まとめ

robots.txtとnoindexは、対象も効き方も違います。

• robots.txtは「読むな」、noindexは「載せるな」。検索結果から消したいならnoindexを使い、robots.txtでは塞がない
• 全面Disallowにすると、noindexが読まれない。公開動線に載るページがあるなら、そのパスだけAllowを切ってnoindexを読ませる
• 遮断する範囲はドメイン単位で影響が出る。そのドメインから画像やCSSを本番側で参照していないか、必ず確認する
• OGP画像は検索させたいドメインから配信する。ブラウザで見えているかどうかは判断材料にならない
• robots.txtを触るときは、sitemapの宣言URLを実際に開いて確かめる

いずれも設定ファイル1〜2行の話ですが、間違えたときに気づけるのは「検索結果に画像が出ていない」「消したはずのURLが残っている」といった、日常運用では見えない場所です。サイトの構成を変えたとき、特に管理用ドメインやテスト環境を新しく作ったときが確認のタイミングになります。

graciautoでは、ホームページ制作とあわせて、公開後に検索から人が来る状態までを設計しています。サイトを移行したあと数字が戻らない、検索結果の見え方がおかしい、といった段階でのご相談も承っています。