最近看到一份关于网站与 AI 爬虫关系的统计数据两个数字对比非常直观只有 8.9% 的网站主动屏蔽了 AI 爬虫但 94.8% 的网站从未在 AI 回答中被引用。换句话说绝大多数网站既没有对 AI 爬虫做任何限制也几乎没有从 AI 回答中获取过曝光。这篇文章会围绕这两个数据展开讲清楚几个实际问题AI 爬虫到底是什么、为什么大多数网站选择不屏蔽、AI 爬虫怎么识别、屏蔽操作怎么做以及“被 AI 回答引用”这件事和“被 AI 爬虫抓取”到底是不是一回事。适合三类读者阅读一是自己维护网站或博客的站长二是负责内容平台 SEO 和流量运营的同学三是后端开发工程师需要理解爬虫流量特征、UA 识别和 Nginx 拦截配置。读完之后你可以自己完成 AI 爬虫的检测、屏蔽、日志分析和引用跟踪。1. 背景与核心概念AI 爬虫和 AI 回答引用1.1 AI 爬虫是什么AI 爬虫是人工智能厂商为了获取训练数据和实时检索内容而部署的网络爬虫程序。它和传统搜索引擎爬虫比如 Googlebot、Bingbot类似会遍历页面、抓取 HTML、提取正文和链接但抓取目的不同。传统搜索引擎爬虫主要做两件事一是建立索引让网页可以在搜索结果中出现二是计算相关性、权重和排名。AI 爬虫的用途则更偏向两方向训练数据收集抓取公开网页内容用于训练大语言模型让模型学到知识、语言模式和事实关联。实时检索增强在当前主流 AI 产品的联网搜索功能中AI 会先通过爬虫抓取候选页面再基于这些页面内容生成回答并在回答中标注来源。说得直白一点传统搜索引擎是“把网页存进索引库用户搜索时排序展示”AI 爬虫是“把网页内容变成模型知识或回答参考资料”。1.2 AI 回答引用是什么AI 回答引用是指用户在向 AI 提问时AI 生成的回答里附带的来源链接或来源标识。这类场景常见于ChatGPT 的联网搜索模式Google 搜索的 AI OverviewPerplexity 的 Sources 来源列表各种基于 LLM 的问答产品当你的网站出现在这些引用中用户可以直接点击来源进入站点这相当于一种新的流量入口。从搜索生态的角度看AI 回答引用正在慢慢变成传统搜索结果的替代形态。一个很容易混淆的点是网页被 AI 爬虫抓取不意味着它会被 AI 回答引用。被引用是一个综合结果取决于内容质量、页面结构化程度、站点权威性、和问题的匹配度甚至引用排序策略。这也解释了为什么 94.8% 的站点从未被引用——不是它们不被抓取而是抓取后的内容没有进入最终生成答案的引用池。1.3 为什么这两个数据值得关注8.9% 的屏蔽率说明绝大多数网站对 AI 爬虫处于“放任不管”状态。这背后有几种原因站长根本没意识到 AI 爬虫在访问站点不知道如何识别 AI 爬虫不确定屏蔽会有什么利弊认为站点体量小不值得处理但放任不管本身也是一种决策。AI 爬虫占用服务器带宽、消耗请求资源还不一定会给站点带来流量回报。对内容型网站来说如果大量 AI 爬虫频繁抓取但从来没有被 AI 回答引用那么这部分流量就变成了一场单向的“内容搬运”。理解这两个数据之后接下来的问题很实际怎样把 AI 爬虫从日志里找出来要不要屏蔽怎么屏蔽才不误伤正常搜索引擎屏蔽之后如何验证效果2. 这两个数据背后的技术逻辑2.1 为什么只有 8.9% 的站点屏蔽 AI 爬虫从技术实现来看屏蔽 AI 爬虫并不是复杂操作最轻量的方式是在robots.txt里写Disallow或者通过 Nginx、WAF 拦截指定 User-Agent。既然实现成本不高屏蔽率却只有 8.9%主要原因还是认知和运营策略问题。第一很多站长并不清楚自己的站点被哪些爬虫访问。大部分网站分析工具默认展示的是浏览器流量和搜索引擎流量AI 爬虫被归入“其他爬虫”或“直接访问”很容易被忽略。除非专门去翻 Nginx 日志否则根本看不出有 AI 爬虫每天在抓取。第二AI 爬虫的 User-Agent 变化频率较高且不同厂商命名规则不统一。今天拦截了 GPTBot明天又出现一个新的 UA站长如果没有监控机制很容易漏掉。第三部分站长存在“不确定性顾虑”。AI 搜索和 AI 引用可能成为未来重要流量入口如果过早屏蔽会不会影响之后的内容曝光这种顾虑导致很多站长选择“先观察不动手”。从实际运营角度看这个 8.9% 不是“不能屏蔽”而是“没有策略性地处理”。2.2 为什么 94.8% 的站点从未被 AI 回答引用被 AI 爬虫抓取是“到达”被引用是“入选”。从到达候选池到被最终引用中间隔着好几层筛选。第一层是内容质量与相关性。AI 的引用机制通常会优先选择能直接回答问题、信息完整、表述清晰的页面。如果你的页面只是泛泛介绍主题或者正文被大量广告、弹窗、JS 渲染内容占据引用系统很难从中提取有效信息。第二层是页面可解析性。AI 爬虫抓取页面后会尝试抽取标题、正文、发布时间、作者等信息。页面如果依赖客户端 JS 渲染或者正文被复杂的动态加载遮挡爬虫抓到的可能只是一堆脚本和空壳自然不会被引用。第三层是站点权威性和多样性策略。AI 回答的引用列表往往会倾向于权威站点和头部内容源同时会控制同一个域名的出现次数。个人博客如果能进入候选池但在排序上输给大型内容平台依然得不到引用。所以 94.8% 从未被引用并不是一个令人意外的数字。它说明“可被抓取”到“可被引用”之间存在巨大的漏斗损耗。2.3 屏蔽与引用之间的联动关系把两个数据放在一起看可以得出几个结论屏蔽 AI 爬虫的站点大概率不会出现在 AI 回答引用中。这个结论比较明确因为爬虫都进不来自然无法被引用。不屏蔽 AI 爬虫的站点也不一定被引用。94.8% 这个数据说明哪怕允许抓取绝大多数站点仍然无法获得 AI 回答曝光。真正的关键不是“要不要屏蔽”而是“屏蔽之后你是否在意 AI 引用流量”。如果在意就需要在做屏蔽决策的同时推进内容结构化和引用优化。3. 常见 AI 爬虫与 User-Agent 识别3.1 主流 AI 爬虫的 User-Agent目前常见的 AI 爬虫包括但不限于以下这些。需要注意AI 厂商会不定期增加或调整 User-Agent下面列表适合作为排查起点最终还是要以厂商官方文档为准。爬虫名称所属厂商典型 User-Agent 标识主要用途GPTBotOpenAIGPTBot、OAI-SearchBot训练数据与实时检索ClaudeBotAnthropicClaudeBot训练数据收集Google-ExtendedGoogleGoogle-Extended控制网页是否用于 AI 训练PerplexityBotPerplexityPerplexityBot搜索问答数据抓取CCBotCommon CrawlCCBot通用爬虫常用于模型训练Bytespider字节跳动BytespiderAI 训练数据抓取AmazonbotAmazonAmazonbot内容抓取与训练辅助为什么重点提 Google-Extended因为它比较特殊。Google 搜索官方说明中Google-Extended 控制的是站点内容是否被用于 Gemini 等 AI 模型的训练。如果你屏蔽了 Google-ExtendedGoogle 的传统搜索排序不会受影响但网页内容不会进入 Google AI 训练和 AI Overview 的内容池。这是一个典型的“要曝光还是要保护”的取舍。3.2 User-Agent 识别方法在服务端所有爬虫请求都会携带 User-Agent 请求头。识别 AI 爬虫的核心就是分析请求中的 UA 字符串。下面以 Nginx 访问日志为例演示识别方法。假设你使用默认的 combined 日志格式访问日志中会包含$http_user_agent字段。# 从 Nginx 访问日志中统计 AI 爬虫访问量 grep -E GPTBot|OAI-SearchBot|ClaudeBot|Google-Extended|PerplexityBot|CCBot|Bytespider|Amazonbot /var/log/nginx/access.log \ | awk {print $1, $12, $13} \ | sort \ | uniq -c \ | sort -nr \ | head -30如果日志字段是自定义格式字段位置会不一样。更稳妥的方式是直接用正则统计 UA 中包含关键词的请求数量# 按 UA 关键词统计请求量 awk {for(i1;iNF;i){if($i ~ /GPTBot|ClaudeBot|CCBot/){print $i}}} /var/log/nginx/access.log \ | sort | uniq -c | sort -nr建议把 UA 统计和 IP 统计结合使用。很多 AI 爬虫拥有固定的 IP 段如果出现同一个 IP 在短时间内大量请求并且 UA 中包含上面提到的关键词基本可以确定是 AI 爬虫在遍历。3.3 日志中的真实访问形态AI 爬虫的访问特征通常和普通用户差异很大主要有几个特点请求频率高普通用户一分钟内可能只有几个请求爬虫可以达到每秒几十个请求。页面路径规律爬虫通常按照 URL 结构顺序遍历比如先请求/再请求/articles/1、/articles/2路径递增。不加载 CDN 静态资源正常浏览器会请求 CSS、JS、图片而大多数爬虫只请求 HTML。没有 Cookie 和 Session爬虫基本不携带登录态。当你发现日志中有这种访问特征时可以进一步检查对应 IP 的反向解析结果部分 AI 厂商的 IP 段会有明显的 rDNS 主机名标识。如果确认是 AI 爬虫再决定是否屏蔽。4. 屏蔽 AI 爬虫的完整配置方案4.1 robots.txt 屏蔽方案robots.txt是网站与爬虫之间的君子协议。它不会被强制执行但规范的爬虫会遵守。在站点根目录下创建或修改robots.txt示例内容如下User-agent: GPTBot Disallow: / User-agent: OAI-SearchBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: PerplexityBot Disallow: / User-agent: CCBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: * Allow: /这里的关键点解释一下每一个User-agent对应一种爬虫Disallow: /表示禁止抓取全站内容。最后的User-agent: *表示其他未被明确指定的爬虫Allow: /表示允许访问。这样不会误伤正常搜索引擎蜘蛛。如果你只想屏蔽部分目录可以把/改成具体路径比如Disallow: /wp-admin/。注意robots.txt只能起到“告知”作用无法限制不遵守协议的爬虫。如果你发现某类爬虫在配置后仍然疯狂抓取就需要在 Nginx 或 WAF 层面做强制拦截。修改完robots.txt后可以用curl验证文件是否可访问curl -I https://yourdomain.com/robots.txt正常返回 HTTP 200 说明配置已生效。4.2 Nginx 层强制拦截如果你的网站使用 Nginx 作为 Web 服务器可以在 Nginx 层直接拒绝 AI 爬虫请求。这种方式比robots.txt强得多因为请求根本不会到达应用层。推荐做法是使用map模块统一管理 UA 匹配规则。在nginx.conf的http块中引入一个配置文件或直接在http块中添加# 文件路径/etc/nginx/conf.d/block_ai_bots.conf map $http_user_agent $block_ai_bot { default 0; ~*GPTBot 1; ~*OAI-SearchBot 1; ~*ClaudeBot 1; ~*PerplexityBot 1; ~*CCBot 1; ~*Bytespider 1; ~*Amazonbot 1; ~*Google-Extended 1; ~*facebookexternalhit 0; ~*Googlebot 0; }然后在server块中使用server { listen 80; server_name yourdomain.com; if ($block_ai_bot 1) { return 403; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }配置说明map指令负责把 UA 映射为0或1~*表示不区分大小写的正则匹配。default 0表示默认不拦截避免误伤。配置里把Googlebot和facebookexternalhit显式设置为0确保搜索引擎搜索和分享预览不受影响。if ($block_ai_bot 1) { return 403; }直接拒绝访问响应 403 状态码。修改配置后需要重新加载 Nginxnginx -t nginx -s reload建议先在小流量环境下测试确认正常搜索引擎的抓取不受影响再全量生效。4.3 CDN / WAF 层拦截方案如果你使用了 CDN 或云 WAF建议在 CDN 边缘做拦截这样可以在到达源站之前过滤掉 AI 爬虫节省源站资源。以 Cloudflare 为例可以在 WAF 自定义规则中设置匹配字段User Agent匹配条件包含GPTBot、ClaudeBot、CCBot、PerplexityBot、Bytespider、Google-Extended匹配动作Block其他云厂商的 WAF 操作逻辑类似都是在请求头匹配 UA 字段后执行阻断。由于不同厂商控制台界面差异较大这里不贴死具体界面思路是一致的。4.4 层与层之间的选择策略这三层方案不是互斥的可以组合使用单独使用robots.txt适合内容型网站希望用温和方式告知且不承担强制拦截的风险。Nginx 层拦截适合对资源消耗敏感的站点能立刻降低无效请求。CDN / WAF 层拦截适合已接入 CDN 的站点在源头挡住流量节省回源带宽。我自己的建议是先在 Nginx 日志层面观察两周确认 AI 爬虫的 UA 和 IP 特征然后先用robots.txt做第一层控制再在 Nginx 层做强制拦截。不要一开始就全量屏蔽否则很难判断误伤影响。5. 检测你的站点是否被 AI 回答引用5.1 从访问日志反推引用效果站点被 AI 回答引用后用户点击引用链接会进入站点这部分流量会体现在访问日志中。不同的是这类访问的Referer通常会指向 AI 产品页面比如chatgpt.com、perplexity.ai等。可以从 Nginx 日志中统计来自 AI 产品的点击流量# 统计来自 AI 产品的点击量 grep -E chatgpt.com|perplexity.ai|bard.google.com|gemini.google.com /var/log/nginx/access.log \ | awk {print $7} \ | sort \ | uniq -c \ | sort -nr \ | head -20这个统计可以看出哪些页面被 AI 用户点击过。如果完全没有来自这些域名的流量说明站点未出现在 AI 回答引用中或者即便出现也无人点击。5.2 主动查询引用情况目前没有一个统一的官方接口可以查询“我的网站是否被 AI 回答引用”最直接的方法是在主流 AI 产品中主动测试。测试方法打开 ChatGPT 联网搜索模式输入“站点域名 品牌词 核心业务关键词”查看回答是否引用你的域名。在 Perplexity 中搜索关键词查看 Sources 列表中是否出现你的站点。在 Google 搜索结果页触发 AI Overview 后查看引用角标中是否包含你的域名。使用不同表达方式多次查询因为 AI 引用策略会根据问题语序和关键词变化而变化。需要特别说明的是没被引用不等于没被 AI 爬虫抓取。AI 爬虫可能已经抓取了你的内容用于模型训练但在回答生成时没有展示引用来源。训练数据使用和检索引用是两条路径不能混为一谈。5.3 检查站点访问安全状态很多站长忽略了一个前置问题如果站点都无法被稳定访问AI 爬虫抓取和引用自然无从谈起。最近不少用户在 Android 版 Google Chrome 中遇到站点连接安全提示浏览器会显示“检查您的连接是否安全”之类的页面。出现这种情况时用户可能会直接关闭页面甚至 AI 爬虫也可能因为 TLS 握手异常而放弃抓取。如果遇到类似提示建议按以下顺序排查检查 HTTPS 证书是否过期浏览器访问站点看证书状态。检查证书链是否完整部分服务器缺少中间证书会导致部分客户端验证失败。检查是否有混合内容页面中引用了 HTTP 资源会导致连接状态降级。访问https://yourdomain.com后在 Chrome 地址栏点击锁形图标查看证书详情和连接状态。一个连 HTTPS 都配置不完整的站点很难进入 AI 引用候选池。所以在做引用优化之前先把站点访问安全性修好。6. 常见问题与排查思路问题现象常见原因解决思路robots.txt 已配置 Disallow日志里仍有 AI 爬虫robots.txt 是君子协议部分爬虫不遵守在 Nginx 或 WAF 层面强制拦截屏蔽后正常搜索流量下降UA 匹配规则过宽误伤了 Googlebot检查 map 规则显式放行 Googlebot 和 Bingbot日志出现大量相同 IP 高频请求AI 爬虫在遍历站点统计 IP 频次对异常 IP 做限速或封禁设置 Nginx 拦截后出现 403 报错匹配规则生效请求被拒绝确认目标 UA 是否确实需要屏蔽必要时改为 404 降低识别度站点内容出现在 AI 回答中但没有来源链接AI 引用机制不展示所有来源优化正文结构加入作者、发布时间、参考文献提升引用优先级Chrome 提示连接不安全证书过期、证书链不完整或混合内容更新证书、补全证书链、改用 HTTPS 全站访问AI 爬虫 UA 变化后拦截失效UA 列表固定新爬虫未加入规则建立 UA 监控告警定期更新拦截列表清理爬虫流量后服务器负载仍高可能是其他恶意爬虫或攻击结合 IP、频率、路径特征分析必要时接入 WAF这里特别强调一个排查思路不要只看 UA 是否匹配要同时看 IP 归属、请求频率、路径分布和 Referer。真正的 AI 爬虫通常具备稳定的 UA 和固定的抓取行为伪装 UA 的恶意爬虫需要结合 IP 信誉库处理。7. 最佳实践与工程建议7.1 先评估再决定是否屏蔽不要因为看到 8.9% 的屏蔽率就急着把所有 AI 爬虫都挡住。先问自己三个问题站点是否依赖搜索流量如果依赖屏蔽 Google-Extended 会影响 AI Overview 的曝光机会。AI 爬虫是否造成了明显的资源消耗如果一天只有几百个请求影响可忽略。站点内容是否希望被 AI 引用如果是建议优先优化内容结构而不是一刀切屏蔽。屏蔽是手段不是目的。决策的出发点应该是网站的流量结构和内容分发策略。7.2 使用白名单思路管理爬虫相比黑名单不断追加新 UA白名单思路更稳定。允许 Googlebot 和 Bingbot 正常抓取其余未知爬虫先观察确认是恶意爬虫后再拦截。这样做的好处是规则可控不会因为 AI 厂商新增 UA 而失守。缺点是规则更新需要人工维护适合对内容版权敏感的站点。7.3 建立 AI 爬虫监控体系建议把 AI 爬虫访问量作为常规监控指标之一。具体做法在 Nginx 日志中提取 UA 关键词按天生成统计报表。设置阈值告警比如单日 AI 爬虫请求量超过 10000 时通知管理员。持续跟踪 UA 列表变化每月对比一次厂商官方文档。如果站点规模较大可以单独为爬虫访问创建一份独立日志文件避免和正常日志混在一起。7.4 提升被 AI 回答引用的内容策略想要从 94.8% 的“未被引用”阵营进入被引用阵营技术拦截只是边界条件内容优化才是核心。优先做这几件事正文结构化使用语义化 HTML 标签比如h1、h2、article、time让爬虫更容易识别内容层级。补充结构化数据使用 Schema.org 标记文章、作者、发布时间、评分等信息提升内容机器可读性。优化页面加载速度减少 JS 渲染依赖确保爬虫在关闭脚本的情况下也能获得完整正文。提供清晰的站点地图在sitemap.xml中列出核心页面方便爬虫按优先级抓取。建立内容权威性及时更新内容、补充数据来源、展示作者信息这些信号有助于提升引用排序。结构化数据示例script typeapplication/ldjson { context: https://schema.org, type: Article, headline: 如何屏蔽 AI 爬虫并提升 AI 回答引用率, author: { type: Person, name: 你的作者名 }, datePublished: 2025-01-01, description: 本文介绍 AI 爬虫识别、屏蔽配置和被 AI 回答引用的优化思路 } /script这段代码放在页面head中即可。它不会影响用户界面但能帮助爬虫更准确地理解页面主题和发布信息。7.5 注意安全和合规边界对爬虫做拦截时只针对明确识别出的 UA 和异常 IP不要针对所有海外 IP 或所有非浏览器 UA 做粗暴拦截。如果你的站点有 API 接口更要注意不要误伤合法的程序化访问。如果站点面向中国境内用户还需要遵守《数据安全法》《个人信息保护法》等法律法规对用户隐私数据和敏感信息做访问控制不建议在未了解站点数据分类的前提下用robots.txt开放所有目录。尤其涉及用户上传内容、订单数据、后台管理页面的站点应当在 Nginx 层增加基础访问鉴权而不是单纯依赖爬虫协议。8. 总结与后续学习方向回到开头那两个数据8.9% 的站点屏蔽了 AI 爬虫94.8% 的站点从未在 AI 回答中被引用。这两个数字放在一起说明当前绝大多数网站在 AI 时代依然处于“被动被爬取、被动等引用”的状态。从我的实际经验来看比较好的处理顺序是先做日志分析搞清楚站点到底被哪些 AI 爬虫访问再根据流量结构决定是否屏蔽优先用robots.txt做温和限制必要时加 Nginx 和 WAF 拦截同时把内容结构化和 HTTPS 安全性修好为“被引用”创造基本条件。下一步可以继续学习这几个方向Robots 协议规范了解不同 UA 的扩展字段比如Allow、Sitemap、Crawl-delay的用法。结构化数据深入研究 Schema.org 的 Article、FAQPage、BreadcrumbList 类型提升页面机器可读性。日志分析学习使用 GoAccess、Elasticsearch 或简单的 awk 脚本构建自己的爬虫监控面板。AI 搜索优化持续观察 AI 产品引用来源的形态变化调整内容策略。如果你也维护着自己的网站建议今天就打开 Nginx 日志看一眼统计一下过去一周有多少 AI 爬虫访问过。先了解现状再决定要不要屏蔽。这篇文章如果对你有帮助可以收藏备用后续有新的爬虫 UA 变化也可以对照这个思路继续更新。