「思ったより検索結果に出ていないページがある」。原因を調べると、robots.txtやnoindexの設定ミスだったというケースは少なくありません。本記事は、Google公式ドキュメントにもとづき、noindexとrobots.txtでよくある9つの誤設定パターンと、見つけるための確認手順を整理します。
01この記事でわかること
- noindexとrobots.txtの役割の違いと、混同すると起きる問題
- robots.txt側の誤設定パターン5つ
- noindex側の誤設定パターン4つ
- Search Consoleで誤設定を発見する具体的な手順
- Search Consoleでは見えないAIクローラーの遮断を、アクセスログで見つける手順
02結論サマリー
noindexは検索結果からページを除外する指示であり、robots.txtはクローラーのアクセス自体を制御する指示です。この2つは別の仕組みであり、組み合わせ方を誤ると意図しない結果を招きます。
代表的な事故は、robots.txtでページをブロックしたままnoindexを追加するケースです。Googleの公式ドキュメントは、この場合クローラーがnoindexタグ自体を読み取れないと明記しています。本記事で紹介する9パターンとチェックリストを使えば、自社サイトの設定を体系的に見直せます。
03noindex・robots.txt誤設定とは（基礎定義）
robots.txtは、クローラーがどのURLにアクセスできるかを指示するファイルです。出典はGoogle Search Central「robots.txtの紹介」です。一方noindexは、クロール後にそのページを検索結果へ載せるかを指示するタグです。
両者は似た文脈で語られがちですが、働く段階が異なります。robots.txtは「読みに行くかどうか」を、noindexは「読んだ後、検索結果に出すかどうか」を制御します。この違いを理解しないまま設定すると、次章で紹介する誤設定が起きやすくなります。
04なぜ誤設定に気づきにくいのか
noindexやrobots.txtの誤設定は、見た目上ページが正常に表示されるため気づきにくいという性質があります。ユーザーがページを直接開けば普通に閲覧でき、エラーも表示されません。
検索結果に出ないだけなので、担当者が能動的にSearch Consoleを確認しない限り、誤設定は放置され続けます。次章から、robots.txt側とnoindex側に分けて代表的なパターンを紹介します。
05robots.txt側の誤設定パターン5つ
robots.txtは書式がシンプルな一方、1文字の誤りが全ページに影響することもあります。公式ドキュメントをもとに、代表的な誤設定を整理しました。
| No. | パターン | 内容 |
|---|---|---|
| 1 | Disallow: /の全体拒否 | サイト全体を意図せず遮断する典型的なミス |
| 2 | Googlebot自体の誤ブロック | AI対策のつもりでGooglebot本体まで拒否してしまう |
| 3 | サブディレクトリへの配置 | robots.txtはルート直下必須。配置場所を誤ると無効になる |
| 4 | 大文字小文字の混同 | ルールは大文字小文字を区別するため、パスの表記違いで対象外になる |
| 5 | AIボットの一括拒否 | 学習用・検索表示用の区別をせず「AI」とつくボットを全て拒否する |
特に見落としやすいのが3・4です。robots.txtはhttps://example.com/robots.txtのようにルート直下に置く必要があります。サブディレクトリには配置できません(出典: Google Search Central「robots.txtの作成方法」)。
またルールは大文字小文字を区別します。公式ドキュメントは、Disallow: /file.aspが/file.aspには適用される一方で/FILE.aspには適用されない、という例を挙げています。
5については、GPTBotとOAI-SearchBotのように、同じ事業者でも学習用・検索表示用でクローラーが分かれているケースがあります。目的別のテンプレートは、別記事『AIクローラー別robots.txt設計テンプレ集【2026年版】』で解説しています。
06noindex側の誤設定パターン4つ
noindex側の誤設定は、robots.txtとの組み合わせに起因するものと、運用フローに起因するものに分かれます。
| No. | パターン | 内容 |
|---|---|---|
| 6 | robots.txtでブロック中のnoindex | クローラーがページにアクセスできず、noindexタグ自体を読み取れない |
| 7 | meta robotsとX-Robots-Tagの矛盾 | HTML側とHTTPヘッダー側で異なる指示を出してしまう |
| 8 | ステージング環境設定の残存 | 開発環境で設定したnoindexを本番公開後に解除し忘れる |
| 9 | CMSテンプレートの初期値 | 新規ページが自動的にnoindexになる設定に気づかない |
6は、特に見落としやすい組み合わせミスです。robots.txtでURLがブロックされていると、クローラーはnoindexルールを見ることができません。その結果、ページが検索結果に表示される可能性があります(出典: Google Search Central「noindexの使い方」)。noindexで確実に除外したい場合は、robots.txt側でそのURLへのアクセスを許可しておく必要があります。
7のmeta robotsタグとX-Robots-Tagは、どちらもnoindexを指定できる仕組みです。同じページで矛盾する指示を出していないか、両方を確認する必要があります。X-Robots-TagはHTTPレスポンスヘッダーで指定するため、PDFなど非HTMLファイルにも使える一方、HTMLソースの目視確認だけでは見落としやすい設定です。
8と9は、設定そのものより「いつ混入したか」が問題になるタイプです。8のステージング環境設定の残存は、本番公開の直後に該当ページのHTMLでnoindexの文字列を検索すれば数十秒で判定できます。公開手順書にこの1行を入れておくだけで再発は止まります。
9のCMSテンプレート初期値は、記事単位ではなくテンプレート単位で確認します。WordPressのSEOプラグインには、投稿タイプごと・タクソノミーごとにインデックス設定を持つものがあります。新しい投稿タイプやカスタム分類を追加したタイミングで初期値を見る運用にしておくと、個別ページを1件ずつ点検せずに済みます。
07誤設定を発見する3つの確認手順
誤設定の発見は、Google向けとAIクローラー向けで手段が分かれます。Google側はSearch Consoleの2つのレポートを併用し、AI側はサーバーのアクセスログを使います。
手順1: robots.txtレポートで取得状況を確認する
Search Consoleの「robots.txtレポート」では、Googleが取得したrobots.txtの内容と、取得ステータス・警告を確認できます。出典はSearch Console ヘルプ「robots.txtレポート」です。このレポートは、対象プロパティの上位20ホストぶんのrobots.txtを表示します。
手順2: ページのインデックス登録レポートで除外理由を確認する
「ページのインデックス登録」レポートでは、インデックスされなかったページとその理由を確認できます。出典はSearch Console ヘルプ「ページのインデックス登録レポート」です。「noindexタグが原因」「robots.txtによりブロック」といった理由が個別に表示されるため、どちらの仕組みが原因かを切り分けられます。
手順3: アクセスログでAIクローラーの遮断を確認する
ここが手順1・2では埋められない穴です。Search Consoleが報告するのはGooglebotの挙動だけであり、AIクローラーを誤って遮断していてもSearch Consoleには何も表示されません。警告もエラーも出ないため、担当者は「特に問題なし」と判断してしまいます。
確認手段は、自社サーバーのアクセスログです。次の3点を順に見ます。
- 直近1〜3か月ぶんのログを、User-Agent別に件数集計する(GPTBot・OAI-SearchBotなど)
- 集計結果に出てこないUser-Agentがあれば、robots.txtの該当ルールを読み直す
- ステータスコードを確認し、200以外(403・404など)が多いパスを洗い出す
「アクセスが0件」と「アクセスはあるが拒否している」は、原因も対処もまったく別です。前者はrobots.txt以前にクローラーが来ていない状態で、後者は自社の設定で遮断している状態です。ログを見ずにrobots.txtだけを眺めていると、この2つを区別できません。
なお、robots.txt側の点検をAIに実行させたい場合は、別記事『AIクローラー向けrobots.txtをAIにチェックさせる方法』のプロンプトも活用できます。noindex側の設定ミスは、別記事『noindex設定ミスの洗い出しをAIに依頼する実践プロンプト』で扱っています。
08チェックリスト
- robots.txtで
Disallow: /の意図しない全体拒否がない - robots.txtがルート直下に配置され、Googlebot本体を誤ってブロックしていない
- AIボットを学習用・検索表示用で区別して設定している
- robots.txtでブロック中のURLにnoindexだけを設定していない
- meta robotsタグとX-Robots-Tagの指示が矛盾していない
- ステージング環境のnoindexが本番公開後に解除されている
- CMSの新規ページ初期値がnoindexになっていないか確認している
- robots.txtレポートとページのインデックス登録レポートを定期的に確認している
- アクセスログをUser-Agent別に集計し、AIクローラーの到達状況を確認している
09よくある失敗
「AI対策」のつもりでGooglebotまで拒否してしまう。Google-Extendedなど特定のAI学習用トークンと、検索インデックス全般を担うGooglebot本体は別物です。両者を混同すると、Google検索結果全体から除外される事態になります。なおGoogle-Extendedの制御自体は、Google検索の登録や順位に影響しないと公式に明記されています。
robots.txtとnoindexを同じ目的の設定だと思い込んでしまう。インデックスから確実に外したいなら、robots.txtのブロックを解除したうえでnoindexを設定します。
本番公開時のチェック項目にnoindex確認を含めていない。ステージング環境からの移行フローにnoindex解除の確認が組み込まれていないと、同じミスが繰り返されます。
10FAQ
Q. robots.txtとnoindexは、どちらを優先して設定すべきですか？
目的によります。ページ自体をクロールさせたくない場合はrobots.txt、クロールは許可しつつ検索結果には出したくない場合はnoindexを使います。なおGoogle公式ドキュメントは、robots.txtを検索結果から隠す手段として使わないよう案内しています。robots.txtでブロックしたページはnoindexを読み取ってもらえないため、併用時は特に注意してください。
Q. noindexを外してから、検索結果に反映されるまでどれくらいかかりますか？
Google公式ドキュメントは具体的な日数を保証していません。急ぎの場合は、URL検査ツールで再クロールをリクエストする方法があります。
Q. 大文字小文字の違いは、本当に別のパスとして扱われますか？
はい。Google公式ドキュメントは、robots.txtのルールが大文字小文字を区別すると明記しています。同ドキュメントの例では、/file.aspと/FILE.aspが異なるパスとして扱われます。
Q. X-Robots-Tagはどんな場合に使いますか？
PDFや動画ファイルなど、HTMLの<meta>タグを埋め込めないファイル形式でnoindexを指定したい場合に使います。HTTPレスポンスヘッダーで指定するため、CMSやCDNの設定を確認する際は見落とさないよう注意が必要です。
11まとめ
noindexとrobots.txtは、クロールの可否とインデックスの可否という別々の役割を持つ仕組みです。この違いを理解しないまま設定すると、本記事で紹介した9パターンのような意図しない誤設定が起きます。
まずはSearch Consoleのrobots.txtレポートとページのインデックス登録レポートを開き、自社サイトの設定が意図どおりになっているかを確認することをおすすめします。そのうえで、Search Consoleが覆っていないAIクローラー側は、アクセスログのUser-Agent別集計でしか見えません。この2レーンをセットで点検してください。
