一、先分清两件事：AI 爬虫是抓取，AI 引用是呈现

2023 年之后，站长的日志里开始出现一批陌生 UA：GPTBot、ClaudeBot、PerplexityBot、Bytespider、Google-Extended。很多人第一反应是「这是不是恶意爬虫」，第二反应是「要不要封掉，省点带宽」。这两个反应背后其实是同一个误解：把「AI 抓取」和「AI 引用」当成了同一件事。

这两件事在技术上是分开的。抓取发生在服务器层，你能在 access.log 里看到请求，能在 nginx 里限制速率，能在 robots.txt 里拒绝。引用发生在模型层和答案层，你无法直接观测，只能靠「答案里提到了我」这种间接证据倒推。一个模型可能每天来抓你的站三十次，然后在答案里一次都不提你；也可能三个月只抓过你一次，但那次抓得很全，之后半年答案里反复引用你的段落。

所以处理 AI 爬虫的第一原则是：抓取策略可以精确控制，引用结果不能精确控制，只能靠内容结构去提高概率。把两者混在一起谈，会得出「封掉 GPTBot 就能防止我的内容被 AI 用」这种错误结论——事实是，模型训练数据的来源通道远不止爬虫一条，你封了爬虫，最多是让未来的检索式抓取少了一条路径，历史语料早已不可撤回。

对个人站长来说，真正有价值的判断只有两个：哪些 UA 值得放进来抓，哪些应该拦；以及放进来之后，页面的结构能不能让抓取器在有限的预算里取到最该取的那部分。下面按这两条展开。

二、识别：日志里怎么把 AI 爬虫和伪装者分开

先看日志。最直接的一条命令，是把最近一天的 UA 按频次排一遍：

awk -F'"' '{print $6}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -40

你会看到一长串 UA 字符串。真正需要关注的 AI 爬虫 UA 大致分三类：

第一类是明确声明的。OpenAI 的 GPTBot（训练）、OAI-SearchBot（搜索呈现）、ChatGPT-User（用户主动触发抓取）；Anthropic 的 ClaudeBot（训练）、Claude-User、Claude-SearchBot；Perplexity 的 PerplexityBot 与 Perplexity-User；字节的 Bytespider；Common Crawl 的 CCBot。这些 UA 在官方文档里都能查到完整字符串，把它们抄进一个配置文件是最省事的做法。

第二类是没有统一命名的。比如各类「AI 摘要」插件、浏览器内置助手、RSS 转 AI 摘要的第三方服务，UA 往往长得像普通浏览器，或者干脆是 python-requests、Go-http-client 这种通用 UA。这类只能靠行为特征判断：请求频率高于真实用户、只抓 HTML 不抓 CSS 和图片、不执行 JavaScript、请求路径呈现「顺着 sitemap 走」的规律性。

第三类是伪装的。有人把 UA 写成 Googlebot 来蹭放行策略，但反向 DNS 一查就露馅。验证方法固定：先做 PTR 查询，确认域名属于官方网段，再做正向解析确认返回的 IP 与原始 IP 一致。

ip=66.249.66.1
host=$(dig +short -x $ip)
echo "$host"
dig +short "$host" | grep -qx "$ip" && echo "正向一致" || echo "伪造"

AI 爬虫大多没有公开的、可反向验证的网段（部分有，但不全），所以对它们做「UA 白名单 + 速率限制」比做「严格身份验证」更现实。实践中的做法是：把已知 UA 分组，每组给不同的 limit_req 速率，而不是简单的一放一封。

三、放行还是拦截：按用途分组，而不是按公司分组

很多教程把 AI 爬虫按公司分类：OpenAI 一组、Anthropic 一组、字节一组。这个分法对决策没用，因为同一家公司下面，抓训练语料的机器人和做实时搜索的机器人，对你站点的意义完全不同。

按用途分，AI 爬虫只有三种：

训练型（GPTBot、ClaudeBot、CCBot、Bytespider 等）：抓一次入库，之后长期不再来。它带来的直接价值几乎为零——你不会因此获得流量，也不会知道内容被用了。但它的成本也几乎为零，一个页面抓一次，几 KB 到几十 KB。对个人站来说，训练型爬虫的真正风险不是带宽，而是「内容被吸收后在答案里以他人名义出现」这种无法追责的稀释。

检索型（OAI-SearchBot、PerplexityBot、Claude-SearchBot 等）：为回答某次提问而实时或近实时抓取，抓完可能就把你的页面作为引用来源列出来。这类是有可能带来真实访问的——用户看到答案里的来源链接，会点进来。它的请求量比训练型高一个数量级，因为同一个页面会因不同提问被反复抓。

用户触发型（ChatGPT-User、Claude-User、Perplexity-User）：某个用户把你的链接贴进对话框，或者让助手打开你的页面。这类请求的「人味」最重，本质上是一个真实访问的代理，应当按普通用户对待。

基于这个分法，我的建议是：检索型和用户触发型全部放行，并给一个合理的速率上限；训练型按站点性质决定——内容型站点放行（内容被引用本身就是获客），工具型或付费内容站点可以拦，因为抓走之后没有任何回流路径。

Nginx 里可以这样落地。先定义两个限速区，一个给「人类和用户触发」，一个给「检索型爬虫」，后者更严格但不会 403：

map $http_user_agent $ai_class {
    default                     "";
    "~*GPTBot"                  "train";
    "~*ClaudeBot"               "train";
    "~*CCBot"                   "train";
    "~*Bytespider"              "train";
    "~*OAI-SearchBot"           "search";
    "~*PerplexityBot"           "search";
    "~*Claude-SearchBot"        "search";
    "~*(ChatGPT-User|Claude-User|Perplexity-User)" "user";
}

limit_req_zone $binary_remote_addr zone=search:10m rate=30r/m;
limit_req_zone $binary_remote_addr zone=train:10m  rate=10r/m;

server {
    if ($ai_class = "train") { set $zone train; }
    if ($ai_class = "search") { set $zone search; }
    location / {
        limit_req zone=search burst=20 nodelay;
        limit_req_status 429;
        ...
    }
}

注意这里的取舍：给 429 而不是 403。429 表示「现在太多，稍后再来」，大多数正规爬虫会遵守 Retry-After 退避，而 403 会让它们认为整个站点拒绝抓取，可能直接写进长期黑名单。对训练型如果你确定要拒绝，用 robots.txt 声明比用 403 更清晰，因为 robots.txt 是给「守规矩的爬虫」看的拒绝，而 403 是给所有客户端的硬墙，会连累正常用户。

四、robots.txt 在 AI 时代的三处新写法

robots.txt 的语法十年没变，但 AI 爬虫带来了三个新问题。第一，不同厂商用不同 UA 区分训练与搜索，你得逐条写；第二，有些爬虫尊重 robots.txt 但不尊重 crawl-delay；第三，Google-Extended 这类「控制 AI 训练但不影响搜索收录」的字段，容易被误解成「拦了就不收录」。

一个针对内容型个人站的参考写法：

User-agent: *
Disallow: /admin/
Disallow: /search
Disallow: /*?replyTo=

# 训练型：内容站选择放行，仅限正文目录
User-agent: GPTBot
Allow: /
Disallow: /admin/
Disallow: /search

User-agent: ClaudeBot
Allow: /
Disallow: /admin/

# 检索型与用户触发型必须放行，否则不进入答案候选
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# 明确拒绝不想要的一类（示例：纯采集镜像）
User-agent: Bytespider
Disallow: /

Sitemap: https://www.example.com/sitemap.xml

三个要点。第一，每个 User-agent 段是独立的，后面的段不会继承前面的规则，也不会覆盖前面的规则——是「先匹配到具体 UA 就只用那一段」。很多人写了一个 `User-agent: *` 的 Disallow，再写一个 GPTBot 的 Allow，以为 GPTBot 会被放行，实际两个段各自独立，GPTBot 用自己的段，行为符合预期；但如果反过来写，就容易出现「以为自己放行了其实没放」的错觉。

第二，关于 Google-Extended：它只控制「Gemini 训练与 grounding」，不影响 Googlebot 的搜索抓取与排名。所以「加上 Google-Extended Disallow 会不会掉收录」的答案是：不会直接影响收录，但会影响你在 AI 概览里的出现概率。是否加，取决于你要收录还是要被引用，二者在这里是矛盾的，得选。

第三，robots.txt 是约定不是强制。真正决定请求是否被处理的还是服务器层。所以 robots.txt 和限速要一起配：robots.txt 表达意图，limit_req 兜住成本。

五、让抓取器取到该取的部分：结构比字数重要

AI 检索型爬虫和传统爬虫有一个关键差异：它不是在「索引整个站」，而是在「回答一个具体问题」的瞬间去取最相关的几段。这意味着它对页面结构的要求比 Google 更直接——它需要能一句话定位到「这段在回答什么」。

落到具体做法，有四处值得改。

一是标题层级要能独立成立。很多人写 h2 用的是「首先」「其次」「另一方面」这类衔接词，脱离上下文就看不懂。改成「MySQL 连接数打满时的三个判据」这种自带主语的写法，抓取器切段之后每一段仍有意义。这一点和人类阅读习惯也是一致的，改起来没有代价。

二是关键结论要写成一两句可被摘取的话，而不是埋在长段落中间。AI 摘要倾向于抽取「完整的、自足的陈述句」。一段两百字里如果结论在最后半句，被抽中的概率明显下降。建议在每个 h2 段落的前三句之内，出现一次「结论式陈述」。

三是结构化数据要补。Article、FAQPage、HowTo 这三类 Schema 对 AI 摘要的帮助大于对传统搜索的帮助，因为传统搜索的 rich result 有严格准入，而 AI 抓取器把 Schema 当作「结构提示」直接使用。一个最小可用的 Article 标记：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "标题",
  "datePublished": "2026-11-12",
  "dateModified": "2026-11-12",
  "author": {"@type": "Person", "name": "作者名"}
}
</script>

四是避免把正文塞进 JavaScript 渲染。AI 抓取器绝大多数不执行 JS，也不等异步加载。如果你的正文是靠前端框架拼出来的，在抓取器眼里这个页面就是空的——这一点和百度蜘蛛的行为类似，但对 AI 爬虫更致命，因为它没有「二次渲染队列」这种补偿机制。

六、观测：三个能落地的指标

AI 爬虫的效果无法直接测量，但可以间接观测。我日常只看三个数。

第一个是 AI 系 UA 的请求占比。用一条 awk 就能按天聚合：

awk -F'"' 'tolower($6) ~ /gptbot|claudebot|perplexity|bytespider|ccbot/ {
  split($6, a, "/"); ua=a[1]; gsub(/ .*/, "", ua);
  print ua
}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

这个数本身没有好坏，看的是趋势。如果某天突然从每天 200 次涨到 3000 次，先怀疑是不是某个爬虫在扫你的全站——检查它请求的 URL 分布，如果集中在 sitemap 之外的路径（比如日期穷举、参数爆破），那是采集不是抓取，应该直接限速。

第二个是「来自 AI 域名的引荐」。在日志里筛 Referer 含 chatgpt.com、perplexity.ai、claude.ai、copilot.microsoft.com 的请求，看落地页分布。这个数通常很小，但是它是唯一能直接证明「AI 引用带来了人」的证据。如果某个页面的引荐持续出现，说明那个页面在被反复引用，值得把同类内容做深。

第三个是页面被抓取后是否被「完整取走」。这一项没法从日志直接看，但可以看抓取器请求的字节数分布（$body_bytes_sent）。如果某个 AI UA 对你所有页面都只取了 2KB 以内，说明它只读了头部就放弃了，可能是你的正文位置太靠后，或者首屏全是导航和广告。

三个数一起看，能回答一个实际问题：你在 AI 搜索里到底有没有存在感，如果没有，是没被抓，还是抓了没用上。前者改 robots 和结构，后者改内容判断。

七、几个常见的误判

第一，「封了 GPTBot 就不会被训练」——不成立。公开语料（Common Crawl 等）里的历史快照、第三方转载、镜像站，都是独立来源。封爬虫只能影响增量，不影响存量。

第二，「AI 爬虫都是恶意的，全部 403」——代价是被排除在检索型引用之外。检索型爬虫（OAI-SearchBot 等）带来的访问虽然少，但转化意图很强：用户是在问一个具体问题时看到你的，点进来的基本都是精准流量。

第三，「加了 FAQPage 就一定被引用」——不成立。Schema 只是让结构可读，是否引用取决于内容是否真的回答了那个问题，以及模型是否信任这个域名。信任是长期积累的，靠一堆标记堆不出来。

第四，「AI 爬虫让带宽爆了」——先算清楚再下结论。单个页面平均 30KB，一天一万次请求也就 300MB。真正让带宽爆的通常是被采集站整站镜像，那类请求的特征是 URL 穷举而不是顺着链接走，用 limit_req 加一个「非 sitemap 路径的低速区」即可挡住，不必一刀切。

处理 AI 爬虫这件事，本质上是一次成本很低的结构优化：把 robots 写清楚、把限速配好、把正文结构改成可切段的形式。它的收益不体现在某个具体指标上，而是体现在「当有人问一个你写过的问题时，你的页面有机会被拿出来当答案」。对个人站长来说，这可能是未来几年性价比最高的一件小事。