robots.txt・meta robotsのSEO監査方法｜クロール許可とindex制御の矛盾を確認

監修: 菊地 将（リブランディング株式会社）

「公開したはずのページが検索結果に出ない」「noindexを外したのにインデックスされない」といった問題は、robots.txtだけを見ても原因を特定できません。robots.txt、meta robots、X-Robots-Tag、XMLサイトマップをURL単位で突き合わせる必要があります。

特に注意すべきなのが、robots.txtでクロールを拒否しながら、同じURLへnoindexを設定している状態です。Googleがnoindexを認識するには対象URLをクロールできなければならないため、この組み合わせでは意図したインデックス制御にならないことがあります。

この記事では、マーケティング担当者がサイト全体のrobots制御を監査し、「どのURLをクロールさせ、どのURLを検索結果に出すのか」をURL群ごとに整理する方法を解説します。

関連する全体像や前提は「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき」で整理しています。

robots制御監査では「クロール」と「インデックス」を分けて確認する

robots制御を監査するときは、最初に「GooglebotがURLを取得できるか」と「取得したURLを検索結果へ登録してよいか」を分けて考えます。

robots.txtは主にクロール可否、meta robotsとX-Robots-Tagはインデックス制御を担当します。監査では4つを別々に見るのではなく、同じURL単位で照合します。

robots.txtは主にクロールを制御する仕組みです。一方、meta robotsやX-Robots-Tagのnoindexはインデックス登録を制御します。Googleもrobots.txtについて、ページをGoogle検索から除外するための仕組みではないと説明しています。

Googleは、PDFや画像などHTMLにrobots metaタグを設定できないリソースについて、X-Robots-Tagを利用できると案内しています。

最優先で確認するのは「robots.txtでブロック＋noindex」の矛盾

robots監査で優先度が最も高いのは、robots.txtによってクロールできないURLへnoindexを設定しているケースです。

Googleがmeta robotsやX-Robots-Tagを認識するには、URLをクロールしてHTMLまたはHTTPレスポンスを取得する必要があります。robots.txtで取得を拒否すると、そのURLに書かれたnoindexをGoogleが確認できません。

たとえば、次の設定を考えます。

“`text User-agent: * Disallow: /search/ “`

同時に`/search/`配下のHTMLへ次の設定がある状態です。

“`html <meta name=”robots” content=”noindex”> “`

「クロールもインデックスも禁止しているので安全」と考えやすい組み合わせですが、Googleはrobots.txtによってHTMLを取得できないため、noindexを確認できません。

robots.txtで対象URLの取得を拒否すると、Googlebotはページ内のmeta robotsやHTTPレスポンスのX-Robots-Tagを確認できません。

外部ページなどからURLの存在を認識した場合には、robots.txtでブロックされたURLそのものが検索結果に現れる可能性もあります。Google Search Consoleも、robots.txtはクロール制御に使い、検索結果への表示を避ける目的ではnoindexを利用するよう案内しています。

robots制御監査はURLを5種類に分類してから始める

サイト全体を1URLずつ無作為に確認するのではなく、最初にURLを役割別に分類すると監査しやすくなります。

noindexやDisallow自体に問題があるわけではありません。URLの目的と実際の制御が一致しているかを確認します。

重要なのは、robots.txtを「非公開機能」と考えないことです。RFC 9309でもRobots Exclusion Protocolはアクセス認証の代わりではないとされています。機密情報はrobots.txtではなく、認証など適切なアクセス制御を使用する必要があります。

robots.txt監査では重要URLの誤ブロックから確認する

最初に確認すべきなのは、「本来インデックスさせたいURLがDisallowに一致していないか」です。

robots.txtのルールは単純な上から順の処理だけではありません。RFC 9309では、AllowとDisallowのパスについて、より具体的に一致するルールを使用することが定められています。同じ長さでAllowとDisallowが一致する場合はAllowを使うことが推奨されています。

そのため、目視監査では次を確認します。

1. `User-agent`ごとのルール
2. `Disallow`対象パス
3. `Allow`による例外
4. `*`や`$`を使ったパターン
5. URLごとに最終的に適用されるルール

たとえば、ECサイトで商品ページが`/products/`配下にあるにもかかわらず、古い開発設定として`Disallow: /products/`が残っていれば重大な問題です。

Search Consoleのrobots.txtレポートでは、Googleが検出したrobots.txt、最終クロール時点、警告・エラーを確認できます。重要なブロックを解除した場合にはrobots.txtの再クロールをリクエストすることも可能です。

meta robotsとX-Robots-Tagは両方取得して監査する

HTMLソースにnoindexが見当たらなくても、インデックス制御が存在しないとは限りません。サーバーやCDNからX-Robots-Tagが返されている可能性があります。

Googleはrobots metaタグとX-Robots-Tagの両方をサポートしており、競合するrobotsルールがある場合には、より制限の強いルールを適用すると説明しています。

そのためURL監査では、最低限次の情報を同時に取得します。

“`text URL HTTPステータス robots.txt判定 meta robots Googlebot向けmeta robots X-Robots-Tag canonical XMLサイトマップ掲載有無 “`

特に注意したいのが、テンプレートやHTTPヘッダーによる一括設定です。

たとえばCMS上では記事を「index」に変更していても、Webサーバー側でディレクトリ全体に`X-Robots-Tag: noindex`を返していれば、Googlebotに対してはnoindexが残ります。

XMLサイトマップとrobots制御の矛盾を洗い出す

次に、XMLサイトマップへ掲載されているURLとrobots制御を照合します。

Googleは、XMLサイトマップにはGoogle検索結果に表示したいURLを含めるよう案内しています。また、基本的にはcanonicalとして扱いたいURLをサイトマップへ載せることが推奨されています。

したがって、次の状態は監査対象です。

Search Consoleも、送信したサイトマップ内のURLがrobots.txtやnoindexなどによってブロックされている場合に問題が発生し得ると案内しています。

CSS・JavaScriptなど重要リソースの遮断も確認する

robots.txtではHTMLだけでなく、CSS、JavaScript、画像などのリソースも対象になります。

重要なのは「ファイルだから全部許可」「ファイルだから全部拒否」と判断しないことです。Googlebotがページを正しく取得・処理するために必要なリソースまでブロックしていないか確認します。

特に過去のrobots.txtには、次のような広範囲な指定が残っていることがあります。

“`text Disallow: /.js$ Disallow: /.css$ “`

変更履歴が分からない設定を一括削除するのではなく、対象URLとページ表示への影響を確認してから修正します。

サイト横断監査では「URL×制御状態」の表を作る

数百〜数万URLを扱う場合、robots.txtのファイルだけをレビューしても不十分です。

サイト横断監査では、robots.txtだけでなくmeta robots、X-Robots-Tag、サイトマップをURL単位でまとめ、期待状態とのズレを判定します。

実務ではクロールデータ、サイトマップ、HTTPヘッダーなどを統合し、URLごとに次の状態を持たせます。

ここでのポイントは、設定そのものに「正解」「不正解」を付けるのではなく、URLの役割と設定が一致しているかを見ることです。

noindexは常に悪い設定ではありません。robots.txtのDisallowも同様です。検索流入を獲得する重要URLへ意図せず適用されていることが問題です。

修正は検索への影響度とURL数で優先順位を決める

問題を見つけたら、すべてを同じ順番で修正する必要はありません。

次の2軸で優先順位を決めます。

検索流入への影響が大きく、かつ多数のURLへ波及する問題ほど先に修正します。サイト全体や主要ディレクトリの誤Disallowは最優先です。

検索への影響度

検索流入やコンバージョンにつながる重要URLかどうか。

影響URL数

1URLだけの問題か、テンプレートやパス指定によって数百・数万URLへ波及しているか。

優先度の目安は次の通りです。

サイト移行時は特に注意が必要です。Googleはサイト移行の一般的な問題として、開発時に設定したnoindexやrobots.txtのブロックを本番公開後も残してしまうケースを挙げています。

修正後はSearch ConsoleでGooglebotの実際の認識を確認する

設定ファイルを修正して終わりではありません。

重要URLについてSearch ConsoleのURL検査を行い、少なくとも次を確認します。

• クロールが許可されているか
• ページを正常に取得できるか
• インデックス登録が許可されているか
• Googleが認識したcanonical
• 最新クロール後に変更が反映されているか

GoogleのURL検査関連ドキュメントでも、「クロールを許可」「ページ取得成功」「インデックス登録を許可」という項目を分けて確認できます。

robots.txtを変更した場合は、Search Consoleのrobots.txtレポートも確認します。

robots制御監査のチェックリスト

実務では次の順番で確認すると、重大な問題を見落としにくくなります。

• [ ] robots.txtが正常なHTTPステータスで取得できる
• [ ] 重要URLがDisallowに一致していない
• [ ] User-agentごとのルールを確認した
• [ ] AllowとDisallowの優先関係をURL単位で確認した
• [ ] 重要URLにmeta robotsのnoindexが残っていない
• [ ] X-Robots-TagをHTTPレスポンスから確認した
• [ ] robots.txtでブロックしたURLにnoindexを依存させていない
• [ ] XMLサイトマップ掲載URLとrobots制御が一致している
• [ ] 404・410・リダイレクトURLがサイトマップへ残っていない
• [ ] 重要なCSS・JavaScript等を誤って遮断していない
• [ ] 開発・移行時の一時的なnoindexやDisallowが残っていない
• [ ] 修正後にSearch Consoleで実際のGooglebot判定を確認した

まとめ

robots制御監査では、robots.txtだけを確認してはいけません。

robots.txtはクロール、meta robotsとX-Robots-Tagは主にインデックスや検索結果での表示を制御するため、役割が異なります。特に、robots.txtでクロールを止めたURLへnoindexを設定すると、Googleがnoindexを確認できなくなる点には注意が必要です。

実務では、サイト内URLを役割ごとに分類したうえで、robots.txt、meta robots、X-Robots-Tag、HTTPステータス、canonical、XMLサイトマップをURL単位で突き合わせます。

まず「重要URLがクロール・インデックス可能か」を確認し、その後に不要URLのクロール最適化へ進めると、SEOへの影響が大きい設定ミスから優先的に修正できます。

参考文献・データ元

‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト