robots.txtとnoindexの使い分け｜クロール制御の基本

Google検索セントラルのrobots.txt入門ドキュメントには、はっきりとこう書かれています——robots.txtは主にサイトへのリクエストが過剰になるのを避けるために使うもので、「ウェブページをGoogleの検索結果に出さないための仕組みではない」。つまり「検索結果に出したくないからrobots.txtでブロックする」という発想は、公式仕様の時点で間違っているのです。robots.txtとnoindexは、どちらも「このページはそのままにしないでほしい」と伝える手段に見えます。ところが止めている工程がまったく違い、しかも重ねて使うと逆効果になります。本記事では、クロール制御とインデックス制御の役割分担、併用が禁じ手になる理由、robots.txtの構文と技術的な制約、パラメータURLやサイト内検索結果・PDF・会員ページ・開発環境といった実務判断、クロールバジェット、Search Consoleでの検証手順までを、公式ドキュメントの記述を軸に整理します。

robots.txtとnoindexは何が違うのか

検索エンジンがページを検索結果に出すまでには、大きく3つの工程があります。URLを見つける発見、ページの中身を読み込むクロール、そして読み込んだ内容をデータベースに登録するインデックスです。robots.txtとnoindexは、この工程のうち別々の段階に作用します。robots.txtが止めるのはクロール、noindexが止めるのはインデックスです。

robots.txtは、サイトの最上位ディレクトリに置くテキストファイルで、「どのクローラーがどのパスにアクセスしてよいか」を宣言します。Googleの位置づけは明快で、クローラーのトラフィックを管理するための道具です。一方noindexは、個々のページに埋め込む指示で、「このページは読んでもいいが、検索結果には載せないでほしい」と伝えます。読ませないのがrobots.txt、載せさせないのがnoindex——この一行で区別を覚えると混乱しません。

観点	robots.txt	noindex
止める工程	クロール（ページの読み込み）	インデックス（検索結果への登録）
書く場所	サイト直下のrobots.txtファイル1つ	各ページのhead内metaタグ、またはHTTPヘッダー
検索結果への表示	外部からリンクされていれば表示され得る	クロールされれば表示されなくなる
主な使いどころ	クロール量の節約・無限に増えるURLの除外	検索結果に出したくない個別のページ

表の3行目が、実務でもっとも誤解される点です。robots.txtでブロックしたURLは、Googleがページを読み込まないだけで、URLそのものが検索結果に出る可能性は残ります。公式ドキュメントも、robots.txtでブロックされたページは他サイトからリンクされていればインデックスされ得ると述べています。この場合、中身を読めていないため検索結果にはスニペット（説明文）が付かず、URLだけが並ぶ不自然な見え方になります。

robots.txtでできること・できないこと

robots.txtの効き方は、対象のファイル種別によって変わります。公式ドキュメントは3つに分けて説明しています。第一にウェブページ（HTMLやPDF）。クロール量の管理には使えますが、検索結果から隠す目的には使えません。ブロックすると「検索結果に説明文が付かない」状態になるだけです。第二にメディアファイル（画像・動画・音声）。これらはrobots.txtでブロックすると検索結果への表示を防げますが、他サイトから直接リンクされている場合は防げません。

第三がリソースファイル（スクリプト・スタイルシートなど）です。これらをブロックしてよいのは、そのファイルなしで読み込まれたページが大きく影響を受けない場合に限られます。レンダリングに必要なCSSやJavaScriptをブロックすると、Googleがページを正しく描画できず、評価に悪影響が出ます。見た目や機能に効いているリソースは、原則ブロックしないと覚えてください。

さらに押さえたい限界が2つあります。ひとつは強制力がないこと。公式は「robots.txtの指示はクローラーの動作を強制できるものではなく、従うかどうかはクローラー側に委ねられている」と明記しています。行儀の良い検索エンジンのクローラーは従いますが、悪意あるスクレイパーは無視します。もうひとつは解釈のばらつきで、クローラーによって構文の読み方が違う場合があります。robots.txtはお願いであって、鍵ではない——この前提を外すと、後述する開発環境の事故につながります。

noindexの2つの実装方法

noindexの実装方法は2通りあり、公式ドキュメントはどちらも同じ効果だと説明しています。使い分けは、単に扱いやすさとコンテンツの種類で決めます。1つ目がmetaタグで、HTMLのhead内に1行加えます。2つ目がHTTPレスポンスヘッダーのX-Robots-Tagで、サーバー側の設定やアプリケーションのレスポンスに含めます。

<!-- すべての検索エンジン向け（HTMLのhead内） -->
<meta name="robots" content="noindex">

<!-- Googleだけに指示する場合 -->
<meta name="googlebot" content="noindex">

<!-- HTTPレスポンスヘッダーで指示する場合 -->
X-Robots-Tag: noindex

metaタグが使えるのはHTMLだけです。したがってPDFや画像、CSVのようにHTMLでないファイルを検索結果から外したい場合は、X-Robots-Tagしか選択肢がありません。逆に、記事や固定ページのような通常のHTMLであれば、CMSの管理画面から個別に設定できることが多く、metaタグのほうが手軽です。テンプレート単位で一括制御したい場合や、ファイル種別ごとにまとめて指定したい場合は、X-Robots-Tagが向いています。

そして最重要の前提が、公式ドキュメントの次の一文です。「noindexルールを機能させるには、ページやリソースがrobots.txtファイルによってブロックされていてはならず、クローラーがアクセスできる状態でなければならない」。noindexは読んでもらえて初めて効く指示であり、読ませない設定と両立しません。次の節で、この帰結を具体的に見ます。

併用が禁じ手になる理由

「検索結果に出したくないから、robots.txtでブロックしたうえでnoindexも入れて二重に対策した」——現場でよく見る設定ですが、これは逆効果です。理由は単純で、robots.txtでクロールを止めると、Googleはそのページを読み込まないため、ページ内に書かれたnoindexを永久に発見できないからです。公式ドキュメントも「ページがrobots.txtでブロックされていたり、クローラーがアクセスできない場合、クローラーはnoindexルールを見ることがなく、そのページは検索結果に表示され続ける可能性がある」と明記しています。

起きる現象を整理すると、次のようになります。robots.txtでブロックされたURLに外部リンクが付くと、Googleはリンク経由でURLの存在を知ります。中身は読めないので評価はできませんが、URLだけをインデックスに載せることがあります。結果として説明文のないURLが検索結果に居座り、noindexで消そうとしても消えないという手詰まりが生まれます。二重の防御が、むしろ防御を無効化してしまうのです。

正しい直し方は、順序を守ることです。まずrobots.txtのDisallowを外してクロールを許可し、noindexを読ませます。Googleが再クロールしてnoindexを認識すれば、検索結果から外れます。外れたことを確認したうえで、クロール量の節約が目的ならその後にrobots.txtでのブロックを検討する——という順番になります。消したいなら、まず読ませる。直感に反しますが、これが公式仕様に沿った唯一の道筋です。

robots.txtの基本構文と4つのフィールド

robots.txtの構文は驚くほど小さく、Googleが認識するフィールドは4つだけです。クローラーを指定するuser-agent、アクセスを禁じるパスを示すdisallow、禁止の中で例外的に許可するパスを示すallow、そしてサイトマップの場所を示すsitemap。これ以外のフィールド、たとえばかつて使われたcrawl-delayはGoogleがサポートしていません。書いても無視されます。

User-agent: *
Disallow: /search
Disallow: /*?sort=
Disallow: /*?color=
Allow: /search/help

Sitemap: https://example.com/sitemap.xml

記述の基本は、user-agentの行でクローラーを指定し、その下にdisallowとallowを並べるグループ構造です。User-agent: *はすべてのクローラーを対象にします。パスは前方一致で、Disallow: /searchと書けば/searchで始まるURLすべてが対象になります。sitemapは絶対URLで書く必要があり、記述できる数に制限はありません。allowは、広く禁止したなかに例外の穴を開けるための道具です。上の例では検索結果ページ全体を止めつつ、検索の使い方を説明する固定ページだけを通しています。

なお、robots.txtは「許可リスト」ではなく「禁止リスト」として働きます。何も書かなければ全許可であり、robots.txtが存在しないサイトでもクロールは正常に行われます。robots.txtの設置は必須ではない——止めたいものが特にないなら、無理に作る必要はありません。作るなら、止める対象を明確に説明できるものだけを並べるのが安全です。

ワイルドカードと優先順位、そして技術的な制約

パスの指定には2つのワイルドカードが使えます。アスタリスクは「任意の文字の0回以上の繰り返し」を意味し、ドル記号はURLの末尾を意味します。たとえば/*.php$は.phpで終わるパスにだけ一致し、/*.phpは.phpを含むパスすべてに一致します。パラメータ付きURLをまとめて止めたいときに、この2つが効きます。

複数のルールが同じURLに当たった場合の優先順位も決まっています。公式仕様によれば、クローラーはルールのパスが長い（より具体的な）ものを優先します。それでも矛盾する場合、ワイルドカードを含むケースを含めて、Googleは制限の緩いほうを採用します。つまり同じ具体度でdisallowとallowがぶつかったときは、allowが勝ちます。意図せず穴が開いていないか、allowの行は特に慎重に見てください。

• フィールド名（user-agentなど）は大文字小文字を区別しないが、パスの値は区別する。/Fishと/fishは別物として扱われる
• robots.txtはホスト・プロトコル・ポート単位で有効。サブドメインや別プロトコルには、それぞれのrobots.txtが必要になる
• Googleが解析するファイルサイズの上限は500KiB（キビバイト）。上限を超えた部分は無視される
• Googleはrobots.txtの内容を最大24時間キャッシュする。修正が反映されるまで時間差があると見込んでおく

設置場所の制約も見落とされがちです。robots.txtはサイトの最上位ディレクトリに置く必要があり、そこに置かれたファイルのルールは、同じホスト・同じプロトコル・同じポートにしか効きません。サブディレクトリに置いても機能しませんし、メインドメインのrobots.txtでサブドメインを制御することもできません。サブドメインを使ったキャンペーンサイトや開発環境は、それぞれ独立したrobots.txtが必要だと押さえておきましょう。

実務判断①：パラメータURLと並び替え・絞り込み

実務で最初に悩むのが、パラメータ付きURLです。ECサイトや求人・不動産のような絞り込み検索を持つサイトでは、色・サイズ・価格帯・並び順といった条件の組み合わせで、URLが理論上ほぼ無限に増えます。中身は同じ商品群の並べ替えにすぎないのに、URLだけが膨れ上がる——これがクロールを消耗させる典型です。

Googleのページネーション関連のドキュメントは、並び替えや絞り込みの代替バージョンは、noindexまたはrobots.txtでインデックスされないようにするという方針を示しています。判断の分かれ目は規模です。URLの組み合わせが爆発的に増えるサイトでは、そもそも読み込ませない意味が大きいためrobots.txtでのブロックが有効です。組み合わせが限られていて、クロールの取りこぼしが起きていないサイトなら、noindexで検索結果から外すだけでも足ります。

いずれの場合も、ユーザーが実際に検索して探す条件は残すという視点を忘れないでください。たとえば「（地域名）の（職種）求人」のような、需要が明確にある絞り込み結果は、むしろ検索で狙いたいページです。止めるのは需要のない組み合わせ、残すのは需要のある組み合わせ。機械的に全パラメータを止めると、集客に効くページまで消してしまいます。

実務判断②：サイト内検索結果ページ

サイト内検索の結果ページは、扱いを間違えやすい領域です。ユーザーが入力した語句ごとにURLが生成されるため、放置すると自動生成された薄いページが無数にインデックスされる状態になります。中身は既存記事のタイトルが並ぶだけで、検索から来た人に独自の価値を提供しません。原則としてnoindexが妥当です。

ここで一段深く考えたいのが、クロールの扱いです。検索結果ページを検索結果から外すだけならnoindexで十分ですが、クロール量まで抑えたい場合はrobots.txtでのブロックも選択肢になります。ただし前述のとおり、両方を同時にかけてはいけません。まずnoindexで検索結果から外し、外れたことを確認してからrobots.txtでのブロックに切り替えるという二段構えが安全です。

外部からのリンクが付いているサイト内検索URLがある場合は、さらに注意が必要です。robots.txtでブロックした状態で外部リンクがあると、説明文のないURLが検索結果に残り得ます。外部リンクの有無を確認してから、止め方を決めるのが実務の順序です。ヒット件数0件の結果ページを別途エラーページとして扱う設計にしておくと、無価値なURLの生成そのものを減らせます。

実務判断③：PDFとメディアファイル

PDFは判断が分かれる対象です。ホワイトペーパーや調査レポートのPDFは、検索から直接見つけてもらえると流入源になります。一方で、社内向け資料や旧版の価格表、フォーム経由でだけ配りたい資料は検索結果に出したくありません。後者を外したい場合、PDFにはmetaタグを書けないためX-Robots-Tagを使うのが基本です。サーバー設定でファイル種別ごとにヘッダーを付ける形になります。

画像・動画・音声といったメディアファイルは、robots.txtでのブロックが素直に効きます。公式ドキュメントは、これらのファイルをrobots.txtでブロックすれば検索結果への表示を防げると述べています。ただし他サイトから直接リンクされている場合は防げません。装飾用のアイコンやボタン画像など、画像検索に出す必要のないディレクトリを止めておくと、クロールの無駄を減らせます。

ここで気をつけたいのが、ページの表示に必要な画像まで止めないことです。記事内の図解やグラフは、ページの理解を助ける要素としてGoogleに読み取られます。まとめて画像ディレクトリを止めると、コンテンツの一部が欠けた状態で評価されることになります。止めるなら、テーマやプラグインが使う純粋な装飾素材のディレクトリに限定するのが安全です。

実務判断④：会員ページと開発・ステージング環境

会員専用ページや管理画面は、robots.txtで隠すものではありません。理由は2つあります。第一に、robots.txtは公開ファイルなので、Disallowに書いたパスは誰でも読める——隠したい場所の一覧を公開しているのと同じです。第二に、強制力がないため、従わないクローラーには通用しません。正しい守り方は認証（ログイン必須）で、必要に応じてnoindexを併せて指定します。

より事故が多いのが開発・ステージング環境です。「robots.txtでDisallowしているから大丈夫」と考えて公開状態に置いたまま、外部リンクや誰かの共有からURLが拾われ、テスト用のコンテンツが検索結果に現れる——これは実際によく起きます。Googleの公式ドキュメントも、検索結果にページを出さないためにはパスワード保護やnoindexといった別の方法を使うよう案内しています。開発環境はBasic認証やIP制限で塞ぐのが原則です。

本番公開のタイミングでも、逆方向の事故があります。開発環境で全ページにnoindexやDisallowをかけたまま本番へリリースし、公開後も検索結果に一切出ないという失敗です。これは新規サイトのローンチで繰り返される典型的な事故で、公開直後にトラフィックが伸びない原因の上位に入ります。リリース手順書に「robots.txtとnoindexの解除・確認」を明示的な工程として入れておくと防げます。

クロールバジェットは誰の問題か

robots.txtの話をすると必ず出てくるのがクロールバジェットです。ただし、これは多くのサイトにとって心配する必要のない概念です。Googleのクロールバジェット管理ガイドは、対象を明確に示しています。「コンテンツが中程度の頻度（週1回）で変わる100万ページ以上の大規模サイト」、「非常に速い頻度（毎日）で変わる1万ページ以上の中〜大規模サイト」、そしてSearch Consoleで「検出 – インデックス未登録」が多いサイトです。公式自身、これらの数字は分類のためのおおまかな目安だと補足しています。

クロールバジェットは2つの要素で決まります。ひとつはクロール能力の上限で、サーバーの健全性や応答速度に応じてGoogleが割り当てる接続時間の総量です。もうひとつはクロールの必要性で、サイトの規模・更新頻度・ページ品質・関連性によって変わります。ガイドは、必要性はクローラーごとに異なるが、能力の上限は全クローラーで共有されると説明しています。サーバーが遅いサイトは、それだけでクロールの取り分を減らしてしまうわけです。

節約の手段としてのrobots.txtとnoindexの違いも、ここで明確になります。ガイドはクロールバジェット目的でnoindexを使わないよう促しています。noindexを付けてもGoogleはページをリクエストし、読み込んでからnoindexを見て破棄するため、クロール自体は発生してしまうからです。対してrobots.txtでのブロックはクロールを止めます。インデックスを減らしたいならnoindex、クロールを減らしたいならrobots.txt——目的が違えば道具も違うという原則が、ここでも一貫しています。

noindexが効くまでの時間差と急ぎの削除

noindexを設定したのに検索結果から消えない、という相談は非常に多いです。しかし多くの場合、これは不具合ではなく時間差です。公式ドキュメントは「まだnoindexを追加してからページをクロールしていないことが原因である可能性が高い」と説明し、さらにインターネット上でのページの重要度によっては、Googlebotが再訪するまでに数か月かかることもあると述べています。設定しただけでは何も起きず、再クロールされて初めて効きます。

急いで消したい場合の手順は決まっています。Search ConsoleのURL検査ツールでそのURLを検査し、インデックス登録をリクエストして再クロールを促します。それでも間に合わない緊急事態——たとえば個人情報を含むページが公開されてしまった場合などは、Search Consoleの削除ツールで一時的に検索結果から隠す手段があります。ただしこれは一時的な措置で、恒久対応はnoindexや認証、ページ自体の削除です。

逆に、noindexを外して検索結果に戻したい場合も同じ時間差が生じます。設定変更の効果は、次のクロールを待って現れる。この性質を理解しておくと、「設定したのに変わらない」と焦って何度も書き換える無駄を避けられます。書き換えを繰り返すと、どの設定が効いているのか自分でも追えなくなり、切り分けがさらに難しくなります。設定日を記録し、少なくとも数週間は様子を見る運用にしてください。

Search Consoleでの検証手順

設定が意図どおり効いているかは、必ず検証します。ここで注意したいのが、かつて存在したrobots.txtテスターは2023年後半に提供を終了していることです。現在のSearch Consoleには代わりにrobots.txtレポートがあり、サイトの上位20ホストについてGoogleが見つけたrobots.txtファイル、最後にクロールされた日時、警告の有無を確認できます。オンデマンドの再取得をリクエストする機能もあり、緊急の修正やサーバー障害の後に役立ちます。

個別URLがブロックされているかどうかを調べたい場合は、URL検査ツールを使うのが現在の推奨です。URLを入力すると、Googleがそのページを取得できるか、robots.txtで許可されているか、インデックスに登録されているか、noindexが検出されているかがまとめて表示されます。「ページのインデックス登録」の項目に表示される理由（robots.txtによりブロック／noindexタグにより除外など）が、原因の切り分けに直結します。

検証は一度きりで終わりません。サイトの改修でURL構造が変わったり、プラグインを追加したりすると、意図しない制御が入ることがあります。robots.txtレポートとインデックス作成レポートを月に一度は開く運用を決めておくと、静かに積み上がる不整合を早めに拾えます。特にCMSのプラグイン更新後は、noindexの一括設定が変わっていないかを確認しておくと安心です。

設定を進める4ステップとよくある失敗

最後に、現場で繰り返される失敗を並べておきます。いずれも「設定したつもりで効いていない」あるいは「意図と逆に働いている」状態を生むパターンです。自サイトに当てはまるものがないか、照らし合わせてみてください。

• 検索結果から消したいページを、noindexではなくrobots.txtのDisallowだけでブロックしている（URLが検索結果に残り得る）
• 同じURLにrobots.txtのブロックとnoindexを同時にかけ、noindexが読まれない状態を作っている
• 開発・ステージング環境をrobots.txtだけで隠し、URLと中身が外部から見える状態のまま放置している
• 本番公開時に開発用のDisallowやnoindexを外し忘れ、公開後も検索結果に一切出ない状態になっている
• XMLサイトマップに載せたURLをrobots.txtでブロックし、「見つけてほしい」と「読まないで」を同時に指示している
• レンダリングに必要なCSSやJavaScriptをまとめてブロックし、ページが正しく描画されない状態にしている

これらの根っこは共通しています。クロールとインデックスを1つの概念として扱っていることです。工程が2つあり、道具も2つあると理解すれば、「消したいのか、読ませたくないのか」という問いに自然と答えが出ます。設定に迷ったら、まずその1問に戻ってください。判断の順序が定まれば、実装は数行の作業で済みます。

AIでインデックス制御の棚卸しを進める

止めるべきURLの洗い出しは、生成AIで効率化できる領域です。Search Consoleからエクスポートしたインデックス作成レポートやページ一覧を渡し、URLの規則性から「パラメータ付き」「サイト内検索」「日付や著者のアーカイブ」「添付ファイル」といった類型に分類させます。数千行を人が目視でグルーピングするより速く、見落としの候補を挙げてくれます。

あなたはテクニカルSEOの点検担当です。
以下はサイトのURL一覧です（形式：URL,インデックス状況）。
1. URLの規則性から類型に分類してください（例：パラメータ付き／サイト内検索／アーカイブ／添付ファイル／通常記事）。
2. 各類型について、検索結果に出す必要性が低いと考えられる理由を1行で添えてください。
3. 「クロールを止めるべき候補」と「検索結果から外すべき候補」に分け、どちらの制御が適切かを示してください。
4. 判断が分かれるものは保留として理由を書き、断定しないでください。
---
（ここにURL一覧を貼り付け）

注意点は、AIの分類をそのまま実装に落とさないことです。AIはURLの文字列から類型を推定しているだけで、そのページに需要があるかどうかは判断できません。前述のとおり、絞り込み結果のなかには検索で狙いたいページも混ざっています。洗い出しはAI、止めるかどうかの判断は人という分担を守ってください。robots.txtの草案を書かせて構文の下書きに使うのも有効ですが、公開前には必ずrobots.txtレポートとURL検査で実挙動を確かめます。

よくある質問

robots.txtでブロックしたページが検索結果に出てしまいます。なぜですか？

robots.txtはクロールを止める仕組みで、インデックスを止める仕組みではないためです。他サイトからリンクされていると、Googleは中身を読まずにURLの存在を知り、URLだけをインデックスすることがあります。この場合は説明文が付きません。解決するには、いったんDisallowを外してクロールを許可し、ページにnoindexを設定して読ませる必要があります。

noindexとrobots.txt、どちらを使うか迷います。判断基準はありますか？

目的で決めてください。検索結果に出したくないならnoindex（HTMLでなければX-Robots-Tag）、クロールの量を抑えたいならrobots.txtです。クロールバジェットの節約を狙う場合、noindexではGoogleがページをリクエストしてしまうため効果が薄く、robots.txtでのブロックが適します。ただし2つを同じURLに同時にかけないことが前提です。

robots.txtは必ず用意しなければいけませんか？

必須ではありません。robots.txtがなければ全許可として扱われ、クロールは正常に行われます。止めたい対象が特にない小規模サイトなら、無理に作る必要はありません。作る場合は、止める理由を説明できる行だけを並べ、サイトマップの場所を追記しておくと管理しやすくなります。なお設置場所は最上位ディレクトリで、サブドメインには別途必要です。

まとめ

robots.txtとnoindexは、止めている工程が違います。robots.txtはクロールを、noindexはインデックスを制御する道具で、Googleは公式にrobots.txtを「検索結果からページを除外する仕組みではない」と位置づけています。だからこそ2つの併用は禁じ手で、robots.txtでブロックするとnoindexが読まれず、説明文のないURLが検索結果に残り得ます。消したいならまず読ませる、というのが正しい順序です。構文は4フィールドとワイルドカードだけの小さな仕様ですが、設置場所・500KiBの上限・24時間のキャッシュ・パスの大文字小文字といった制約が実挙動を左右します。実務では、パラメータURLは規模で判断し、サイト内検索は原則noindex、PDFはX-Robots-Tag、会員ページと開発環境は認証で守る。クロールバジェットを気にすべきなのは大規模サイトに限られます。道具を選ぶ前に「消したいのか、読ませたくないのか」を1問だけ自分に問う。そこから始めれば、設定は迷わなくなります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。