WordPress で AI クローラーをブロックする方法(本音で)
GPTBot に WordPress サイトをクロールさせないようにするには、robots.txt に次の行を追加します。
公開
GPTBot に WordPress サイトをクロールさせないようにするには、robots.txt に次の行を追加します。
User-agent: GPTBot
Disallow: /
行儀のよいクローラーに対しては、これで対応は完了です。ただし、自分が今やったことを正直に理解しておいてください。robots.txt はあくまで「お願い」であって、フェンス(柵)ではありません。OpenAI の GPTBot はこのファイルを取得し、その内容に従います。一方、この標準を尊重しないスクレイパーも同じファイルを取得しますが、書かれている行をすべて無視します。この違いを頭に入れてから、半日かけて調整に取りかかるかどうか判断してください。
主要な AI クローラーをまとめてカバーしたい場合、よく使われる user-agent トークンは次のとおりです。
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Bytespider
Disallow: /
GPTBot は OpenAI の学習用クローラー、CCBot は Common Crawl(多くのモデルがこのデータを間接的に学習に使っています)、ClaudeBot は Anthropic、Google-Extended は Google の AI 学習用トークン、Bytespider は ByteDance のものです。このうち 2 つは、すでに「お願いベース」のモデルを破っている点に注意してください。Bytespider と PerplexityBot は、いずれも disallow で拒否したサイトをクロールしていたことが公に記録されています。これらを列挙しておくことは正直なボットに対しては依然として有効ですが、すでに素性を偽っているボットには何の効果もありません。
WordPress が実際に robots.txt を配信する仕組み
ここが、多くの人の編集が黙って無効になってしまう場所です。ウェブルートに物理的な robots.txt ファイルが 存在しない 場合、WordPress はその場で robots.txt を生成します。このリクエストは wp-includes/functions.php 内の do_robots() が処理し、出力は robots_txt フィルターを通ります。「設定 → 表示設定」にある「検索エンジンでの表示 / このサイトをインデックスしないように検索エンジンに要求する」のチェックボックスは blog_public オプションを切り替えるもので、この仮想ファイルに Disallow: / を出力させているのがこの仕組みです。
そのため、AI クローラー向けのルールをプログラムで追加できます。
add_filter( 'robots_txt', function ( $output, $public ) {
$output .= "User-agent: GPTBot\nDisallow: /\n";
return $output;
}, 10, 2 );
ここで何時間も溶かしがちな落とし穴があります。ウェブルートに静的な robots.txt ファイルが存在した瞬間、Apache や nginx はそのファイルを直接配信し、WordPress は一切実行されなくなります。 robots_txt フィルターも、Yoast / Rank Math の robots エディターも、表示設定も、すべてバイパスされます。プラグインで robots.txt を編集したのに実際のファイルが変わらなかったのなら、原因はほぼこれです。シークレットウィンドウで https://yoursite.com/robots.txt を開き、自分が設定したと思っている内容と比べてみてください。ディスク上に実ファイルがあるなら、そのファイルを編集します。フィルターは無関係です。
順を追って直す
まず、きれいなルールを書く。 Googlebot をうっかりブロックしてしまわないよう、構文とクローラーのリストを正しく整えます。当サイトの robots.txt の書き方ツール が AI クローラー用のブロックを組み立て、貼り付けるべき正確なファイルを表示します。最終的に唯一の正となるファイルが手元に残るので、仮想ファイルと物理ファイルの混乱を回避できます。
次に、実際に反映されているか確認する。 URL に直接アクセスして取得します。プラグインのプレビュー画面を信用してはいけません。
3 つめに、単なるお願いではなく強制力が必要なら、レイヤーを上げる。 robots.txt はアプリケーション層に存在し、ボットの善意に依存しています。実際に接続を拒否するには、サーバー側で user-agent によってブロックします。.htaccess では次のようにします。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|CCBot|ClaudeBot|Bytespider) [NC]
RewriteRule .* - [F,L]
</IfModule>
これで、これらの user-agent を送ってくるものに対して 403 を返します。当サイトの .htaccess の書き方ツール でこのルールを組み立てられます。ただし、その限界を理解しておいてください。user-agent は簡単に偽装できるため、これで止められるのは自分の素性を正直に名乗るボットだけ、つまりすでに robots.txt に従っているのと同じボットだけです。本当に堅牢な選択肢は、検証済みのクローラー識別情報や IP レンジでブロックする CDN や WAF です。Cloudflare のワンクリック「Block AI Scrapers and Crawlers」マネージドルールは、その中でも最も手間のかからない方法で、リクエストが WordPress に届く前のエッジで動作します。
やってはいけないこと
AI Overviews から除外されると思って Google-Extended をブロックしない。 これは正しておく価値のある誤解です。Google-Extended はクローラーではなく製品トークンです。制御するのは、あなたのコンテンツが Gemini モデルの学習やグラウンディングに使われるかどうかだけです。Google 自身のドキュメントによれば、これは ページのクロール、インデックス、Google 検索でのランキングには一切影響しません。 そして AI Overviews は、Googlebot がクロールする通常の検索インデックスから生成されるもので、Google-Extended からではありません。Google-Extended をブロックしても AI Overviews から外れることはなく、検索順位を 1 つも失うこともありません。AI Overviews から外れる唯一の方法は Googlebot をブロックするか、ページを noindex にすることですが、それをすると検索結果からも完全に消えてしまいます。それはまず割に合わないトレードオフです。
robots.txt をセキュリティ対策として扱わない。 これは公開情報であり、あくまで勧告的なものです。/wp-admin/ や非公開のパスを列挙すると、どこを狙えばよいかの地図を公開しているだけになります。本当に守るべきエンドポイントは、disallow の 1 行ではなく認証で保護してください。
noai / noimageai メタタグに頼らない。 これらは提案されただけで標準化されておらず、対応しているプラットフォームもごくわずかです。汎用的な防御策にはなりません。
「AI をブロックする」プラグインが robots.txt を書く以上のことをやったと思い込まない。 その大半は、手で書けるのと同じ行を書いているだけで、同じ限界をそのまま引き継いでいます。信用する前に、プラグインが実際に何を変更したのかを確認してください。
それでも解決しない場合
編集が反映されないなら、答えはほぼ間違いなく、ウェブルートに紛れ込んだ物理的な robots.txt が WordPress の仮想版を上書きしていることです。URL に直接アクセスして確認してください。ルールに従うボットは消えたのにスクレイパーが叩き続けてくるなら、それは robots.txt にできることの限界に達したということであり、次の一手は、丁寧にお願いするのではなく検証済みの識別情報でブロックする WAF や CDN のルールです。