robots.txtは全許可なのにAIに弾かれる──犯人は見えない「X-Robots-Tag: noindex」ヘッダー

このシリーズでは、自社サイトがAIに読まれているかを確認する方法や、レンタルサーバーの遮断機能について扱ってきました。今回はもう一段深く、**「robots.txtの中身は全許可なのに、なぜかAIに敬遠される」**という、いちばん見つけにくいパターンを掘り下げます。

これは実際に、私たち自身のサイトと支援先のサイトの両方で遭遇した現象です。robots.txtをいくら眺めても原因が分からず、レスポンスヘッダーまで見て初めて正体が判明する――という、少々やっかいなテーマです。技術的な内容が中心なので、サイトを運用・制作する方向けの記事になります。

症状：robots.txtは開いているのに、AIが読めない

きっかけは、あるAIツールにサイトを読ませようとしたときの「robots.txtで自動アクセスが禁止されているため取得できませんでした」というメッセージでした。ところが、実際にrobots.txtを開いてみると、中身はこうなっていました。

User-agent: *
Disallow:

Sitemap: https://（ドメイン）/sitemap_index.xml

Disallow:（値が空）は「何も禁止しない」、つまり全許可を意味します。クロールを妨げる記述はどこにもありません。それなのにAIには弾かれる。robots.txtの中身を見るかぎり、原因が見当たらないわけです。

犯人はファイルの「中身」ではなく「ヘッダー」

答えは、robots.txtの本文ではなく、それを配信するときにサーバーが付けるHTTPレスポンスヘッダーにありました。curl に -I を付けてヘッダーを確認すると、こう出ます。

curl -A "ClaudeBot" -I https://（ドメイン）/robots.txt | grep -i x-robots

x-robots-tag: noindex, follow

この X-Robots-Tag: noindex が正体です。これは「このリソースを検索インデックスに使わないでほしい」という、比較的強い指示です。そして厄介なのが、それが robots.txt という”クローラーの入り口”のファイルに付いているという点です。

一部のAIフェッチャーは、サイトを読みに来る際にまず robots.txt を取得します。その入り口のファイル自体に noindex が付いていると、「このサイトは利用しないでほしいという意思表示だ」と広めに解釈し、サイト全体へのアクセスを控えてしまうことがあるようです。robots.txt の中身は全許可でも、ヘッダーがブレーキになっていた、という構図です。

なぜ robots.txt に noindex が付くのか

このヘッダーの発生源として多いのが、WordPressのSEOプラグイン「Yoast SEO」です。Yoastは、robots.txt や sitemap.xml といった”機能ファイル”が検索結果に出てこないように、それらのレスポンスに X-Robots-Tag: noindex を付ける仕様になっています。

robots.txt が検索結果にヒットしても利用者には無意味なので、Yoast側としては”親切な配慮”のつもりの挙動です。実際、これはGoogle検索には悪影響がありません。記事ページ本体には付かず、あくまで robots.txt のような機能ファイルにだけ付くためです。ところが、その善意の設定が、AIフェッチャー相手には裏目に出ることがある――という、意図と結果のすれ違いが起きています。

まず切り分ける：記事ページにも付いているか

対処の前に、影響範囲を確認します。noindexが「robots.txtだけ」に付いているのか、それとも「サイト全体」に付いているのかで、深刻度がまったく違うからです。実際の記事ページのヘッダーを見てみます。

curl -A "ClaudeBot" -I https://（ドメイン）/（記事URL）/ | grep -i x-robots

ここで何も表示されなければ、記事ページはクリーン。noindexは robots.txt という機能ファイルにだけ付いている局所的な現象で、SEOへの実害はほぼありません。逆に、記事ページにも x-robots-tag: noindex が出るなら、サイト全体が検索避け状態になっている可能性があり、これはAI以前にSEOの緊急事態です。この場合はまず、WordPressの「設定 → 表示設定 →『検索エンジンがサイトをインデックスしないようにする』」のチェックを確認してください。

対処法1：WordPressのフィルターで消す

robots.txt がWordPressによって動的に生成されている（＝物理ファイルではなく、PHPが出力している）場合、robots_txt フィルターのタイミングでヘッダーを取り除けます。functions.php またはコードスニペット系プラグインに、次を追加します。

phpadd_filter( 'robots_txt', function( $output ) {
header_remove( 'X-Robots-Tag' );
return $output;
}, 99 );

これは robots.txt を出力する直前に走り、X-Robots-Tag ヘッダーを削除します。他のページやSEOには影響しません。追加後、先ほどの grep コマンドで x-robots が表示されなくなれば成功です。

私たちのケースの1つ（エックスサーバーで運用しているサイト）では、これできれいに解消できました。

対処法2：フィルターで消えないケース

一方で、同じコードを入れても消えないケースもありました。別の支援先サイト（さくらインターネットで運用）では、robots_txt フィルターを入れても、より後段の template_redirect フックを使っても、ヘッダーが残り続けました。

考えられる理由は、noindexを付けている主体が、robots.txt の”中身”を生成しているWordPressとは別のレイヤーにいることです。robots.txt の本文はYoastが生成していても、X-Robots-Tag ヘッダー自体は、その後段でサーバー（この場合はnginx）側が付けている、という構成があり得ます。サーバーが最後に付けるヘッダーは、WordPress（PHP）の header_remove() の後に付くため、PHP側では消せません。

このパターンでは、直せるのはサーバーの設定側だけになります。レンタルサーバーのコントロールパネルに関連する項目がないか確認し、見当たらなければ、サーバー会社のサポートに「robots.txt に付与される X-Robots-Tag: noindex ヘッダーの解除方法」を問い合わせるのが確実です。

どこまで対処すべきか

最後に、対処の優先度について現実的な整理をしておきます。この X-Robots-Tag: noindex ヘッダーは、それ自体がサイトを致命的に不可視にするものではありません。記事ページ本体がクリーンで、サーバーがAIボットに 200 を返しているなら、記事はAIの参照対象になり得ます。robots.txt のこのヘッダーは、あくまで”入り口での過剰解釈を招きかねない要因”であって、消せれば理想的、という位置づけです。

したがって、対処法1（WordPressのフィルター）で消えるならぜひ消しておく。消えない場合は、サーバー設定やサポート対応が必要になるので、労力と効果を見て判断する――というのが妥当なところです。AIフェッチャーがこのヘッダーをどう扱うかは各社の実装次第で、今後変わる可能性もあるため、「必ず外さなければならない」と過度に神経質になる必要はありません。

大切なのは、「robots.txtの中身を見ただけでは分からない遮断要因がある」と知っておくことだと思います。
中身は全許可、ステータスは正常、それでもAIに読まれない――そんなときは、curl -I でヘッダーまで覗いてみる。こういった打ち手を知っているかどうかが、原因にたどり着けるかの分かれ目になるかと思います。