要阻止 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 是字节跳动的。要注意其中有两个已经打破了”礼貌请求”这套模式：Bytespider 和 PerplexityBot 都有公开记录，被证实抓取过明确禁止它们的站点。把它们列出来对那些诚实的机器人仍然有用；但对那些已经在谎报自己身份的机器人，则毫无作用。
WordPress 到底是怎么提供 robots.txt 的
大多数人的修改之所以悄无声息地不起作用，问题就出在这里。如果你的网站根目录里没有一个实际存在的 robots.txt 文件，WordPress 会动态生成一个。这个请求由 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。不要相信插件里的预览面板。
**第三步，如果你需要的是强制拦截而不是礼貌请求，那就往上一层走。**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 的机器人。真正靠谱的方案是用 CDN 或 WAF，按经过验证的蜘蛛身份或 IP 段来拦截。Cloudflare 一键式的”Block AI Scrapers and Crawlers”托管规则是这类方案里最省事的一个，它在边缘节点上就起作用，请求根本到不了 WordPress。
不要做的事
**不要以为屏蔽 Google-Extended 就能让你不出现在 AI Overviews 里。这是个值得纠正的误解。Google-Extended 是一个产品标识，不是一个蜘蛛。它只控制你的内容是否被用来训练和支撑 Gemini 模型。按照 Google 自己的文档，它对你的页面如何被抓取、索引，或在 Google 搜索中的排名毫无影响。**而 AI Overviews 是从 Googlebot 抓取的常规搜索索引里生成的——不是从 Google-Extended。屏蔽 Google-Extended 既不会把你从 AI Overviews 里移除，也不会让你在搜索里掉哪怕一个名次。想不出现在 AI Overviews 里的唯一办法是屏蔽 Googlebot 或给页面加 noindex，而那样做也会把你彻底从搜索里删掉。这几乎从来都不是你想做的交换。
**不要把 robots.txt 当成一种安全控制。**它是公开的，而且只是建议性的。在里面列出 /wp-admin/ 或某个私密路径，只不过是把”该往哪儿看”的地图公之于众。用身份验证来保护真正的端点，而不是靠一行 disallow。
**不要指望 noai / noimageai 这类 meta 标签。**它们只是被提议过，从未成为标准，而且只有极少数平台会遵守。它们不是一种通用的防御手段。
**不要以为一个”屏蔽 AI”的插件做了比写 robots.txt 更多的事。**它们中的大多数写的就是你自己手工也能写的那几行，并且继承了同样的局限。在信任一个插件之前，先看看它到底改了什么。
还是搞不定？
如果你的修改没有生效，答案几乎总是：网站根目录里有一个多余的实体 robots.txt 文件，覆盖了 WordPress 的虚拟版本——直接抓取那个 URL 检查一下。如果守规矩的机器人已经消失、但采集程序还在不停地打你，那你就已经触到了 robots.txt 能力的天花板，下一步该上 WAF 或 CDN 规则了，按经过验证的身份来拦截，而不是靠好言相劝。