企业官网建设流程全解析

最近看到一份关于网站与 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 Overview
• Perplexity 的 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，下面列表适合作为排查起点，最终还是要以厂商官方文档为准。

为什么重点提 Google-Extended？因为它比较特殊。Google 搜索官方说明中，Google-Extended 控制的是站点内容是否被用于 Gemini 等 AI 模型的训练。如果你屏蔽了 Google-Extended，Google 的传统搜索排序不会受影响，但网页内容不会进入 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(i=1;i<=NF;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 状态码。

修改配置后需要重新加载 Nginx：

nginx -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. 常见问题与排查思路

这里特别强调一个排查思路：不要只看 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 type="application/ld+json"> { "@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 变化也可以对照这个思路继续更新。