AI 爬虫走哪道门进来：11 天 12,867 条外部请求的门牌分布，以及 88 次 /null 的真相

一、摘要：11 天 2,235,940 行日志，外部有效请求只有 12,867 条

这是「AI 爬虫可达性审计」系列的第一篇。我们要回答一个很具体的问题：生成式 AI 的爬虫到我们站点来，是从哪道门进来的？

我们把站点（yuezhitong.com）2026-09-25 03:30 到 2026-10-06 02:01 的全部 nginx 访问日志拉下来——11 个日志文件、2,235,940 行请求记录。做三层剔除之后，真正来自外部、有分析价值的只剩 12,867 条；其中带生成式 AI 厂商身份的爬虫请求 681 次。

三条主要结论：

• 门大体是走对的。681 次里有 97 次读 robots.txt、49 次读 sitemap.xml、159 次进内容目录。生成式 AI 爬虫确实按「先看规则、再按索引取页面」的路径工作，而不是随机漫游。
• 但我们自己砌的那道门，没人走。站点根的 llms.txt（llmstxt.org 提案里的「AI 索引文件」）11 天被请求 14 次，其中 0 次来自任何 AI 厂商的爬虫——14 次全部来自我们自己的评分脚本、curl 和一家第三方数据商。
• 爬虫会替我们找 bug，也会产生噪声。11 天里有 88 次请求打在一个叫 <目录>/null 的路径上（例如 /geo/blog/null、/vietnam/ho-chi-minh/cost/null），87 次返回 404。我们逐页核对了页面源码：站点里不存在 “null” 字面量，也没有缺失 href 的链接。这是一个跨站复现的爬虫侧伪路径，不是我们的页面缺陷——但它确实在浪费抓取预算，所以本轮做了服务端处置（第八节）。

下面是完整口径、七个爬虫的逐家画像，以及一份可以直接照做的 6 步自查清单。

二、方法：三层剔除与身份判定口径

爬虫分析最容易错的一步，是没把「不是访客的流量」剔干净。本站日志里 95% 以上是内网健康检查，另外还有我们自己的发布机与审计脚本——不剔除，任何「爬虫占比」的结论都是错的。

身份判定口径：按请求头里的 UA 声明归类（GPTBot / OAI-SearchBot / ChatGPT-User / ClaudeBot / Claude-SearchBot / PerplexityBot / meta-externalagent 等），不做事后反向 DNS 核验。UA 是可以伪造的，所以我们不对「某个 IP 一定是某家公司」下断言，只描述「以某厂商身份发出」。所有比例都只在本文窗口、本站范围内成立，不外推为行业比例。

三、盘子：生成式 AI 爬虫走的是哪几道门

把 681 次请求按「进站点后第一个被取的东西」分类，得到下面这张门牌分布表：

读法有三点：第一，robots.txt + sitemap.xml 合计 146 次（21.4%），说明「规则 + 索引」是生成式爬虫的常规入口，把这两个文件做对是有确定回报的。第二，内容目录只有 159 次（23.3%），加上首页 20 次，真正落到「我们写的文章和报告」的请求不到三成——爬虫的预算比想象中分散。第三，「其它路径」占了 36.3%，这里面混着大量攻击扫描和伪路径，需要用后文的 404 模式审计单独拆开看。

四、逐家画像：七个生成式 AI 爬虫的入口偏好

把门牌分布拆到每一家，差异比想象中大：

三个值得记住的差异：

• OAI-SearchBot 是「只读规则」型。63 次请求里 50 次是 robots.txt（79.4%），一次内容页都没取。它像是在确认边界，而不是来取料。
• ClaudeBot 是「先读门再进门」型。87 次规则+索引，26 次内容页——两步都走，而且 404 率只有 0.8%，说明它拿到的索引是准的。
• meta-externalagent 是「只进门、不看门」型。0 次 robots.txt、0 次 sitemap，直接取内容页 105 次；但从 92 个不同 IP 发出，404 率 35.3%。它的行为更像在渲染页面并顺带跟随页面上的链接——这也是第六节 /null 伪路径的来源方。

作为对照，同期搜索引擎爬虫（Googlebot / bingbot / PetalBot 等）共 687 次，规模与生成式 AI 爬虫相当；它们的入口也集中在 robots.txt（Googlebot 22 次、bingbot 17 次）与 sitemap.xml（bingbot 24 次）。

五、洞察一：llms.txt 是我们自己做的门，11 天里没有一个 AI 爬虫走

2026-09-17 我们给站点根目录加了 llms.txt 与 robots.txt 里的显式 AI 爬虫放行声明，并在 llms.txt 里按 llmstxt.org 的写法列出了公司主体、核心服务、内容中心、产业研究与对外数据口径。它的假设是：AI 引擎会用这个文件当「给机器的站点地图」。

11 天的日志给出的答案是：它被读了 14 次，但没有一次来自 AI 厂商的爬虫。

对比同期：robots.txt 被请求 315 次、sitemap.xml 87 次。也就是说，在 2026 年 9–10 月的这个窗口里，真正在起作用的机器入口仍然是 robots.txt 与 sitemap.xml，llms.txt 还不是。

我们的判断（诚实版）：这不代表 llms.txt 应该删掉。它的维护成本近于零，对 GEO 审计工具、对将来才会读它的引擎都是现成资产；但它现在不能被当成「做了就会被 AI 发现」的交付项。我们在给客户的诊断里，会把它放在「加分项」而不是「必做项」。

六、洞察二：88 次 <目录>/null——一个跨站复现的爬虫侧伪路径

在拆 404 的时候，我们发现一组形状非常规整的请求：路径永远等于「当前目录 + /null」。它们不集中在某一个目录，而是跟着爬虫当时所在的页面走。

88 次请求全部来自同一个 UA：meta-externalagent。我们做了三步排查：

1. 页面源码递归检索。把涉及的全部页面（含 zh / vi、文章页、产业报告页、城市库页）逐页抓下来，做大小写不敏感的 “null” 全文检索：0 命中。
2. 链接完整性检查。统计每页的 <a> 标签数量与缺失 href 的数量：例如某篇 vi 产业报告页为「11 个 a 标签 / 0 个缺 href」，<link> 标签 5 个全部带 href。没有残缺链接。
3. 外部交叉验证。公开的运维记录里，至少有三处独立复现了完全相同的指纹——同样的「<目录>/null」形状、同样的 meta-externalagent、同样在页面源码里找不到 null 字面量。

三处外部记录的结论一致：爬虫渲染页面时，把某个「期望是 URL」的字段读成了空值；空值被强制转成字符串 “null”，再按相对 URL 解析到当前目录，于是产生了一次 404。在服务端，没有任何配置能产生这个模式——因为链路上每一环单独看都是正确的。

我们据此把它定性为爬虫侧伪路径，而不是我们的页面缺陷。这个定性很重要：如果当成自家 bug 去「修页面」，会白改一轮；正确的动作是在服务端把这类路径明确处置掉，减少抓取预算的浪费。

七、洞察三：AI 爬虫的 404 率从 0% 到 35% 不等

同样的站点、同样的窗口，不同爬虫踩到 404 的比例差异极大：

另一个更值得看的数字是「内容目录里的 404」。外部请求共 5,085 次 404（占外部请求 39.5%），其中 5,024 次落在与内容无关的路径上（/.env、/.git、/wp-login.php 这类凭证扫描）。落到 /geo/blog/ 的 404 只有 18 次——而这 18 次全部是 /geo/blog/null。

换句话说：11 天里，我们没有任何一篇真实文章返回过 404。内容资产的健康度是干净的；看起来「一团糟」的 404 里，绝大多数是外部扫描和这一条伪路径。

八、处置：把 <目录>/null 从 404 改成 410

处置原则有两条：不动真实内容，只改对伪路径的应答；改完必须做正负对照。

为什么不用「修页面」这个方案：因为我们先证明了页面没有问题（源码 0 命中 null、链接无缺失）。在页面上找 bug 会是无功而返。

为什么是 410 而不是保持 404：410 Gone 是明确信号——「这个资源永久不存在」。相比 404 的「暂未找到」，它更能抑制爬虫反复重试，也更省服务端开销。业内同类处置亦用此解（Apache 侧的等价写法是 RedirectMatch 410 "/null/?$"）。

实现说明：nginx 的 location ^~ /geo/ 与 location ^~ /vietnam/ 这类前缀块会屏蔽 server 级正则 location，所以规则不能只写在 server 层，需要在相应前缀块内各嵌套一条，再对全站其它路径保留 server 级兜底。改完跑 nginx -t 通过、reload 生效，然后按上表逐条回读。处置结果是 8/8 伪路径转 410、10/10 正对照保持 200、2/2 负对照保持 404。

九、给客户的可达性自查：6 步清单

这套动作不需要买工具，只需要日志和一条命令行里的 curl。顺序按投入产出比排列：

补一条经验：不要把 llms.txt 写进 KPI。把它做上，成本很低；但在本项目 11 天的窗口里，它带来的 AI 访问是 0。真正决定「AI 能不能找到你」的，仍然是 robots.txt、sitemap.xml 和内容页本身的可解析度。

十、边界与局限

• 范围：本文所有比例只代表本站（yuezhitong.com）在 2026-09-25 03:30 至 2026-10-06 02:01 这一个窗口内的特征，不外推为行业比例。
• 身份：爬虫身份按 UA 声明归类，未做反向 DNS 与 IP 段核验；UA 可伪造，因此本文描述的是「以某厂商身份发出」的请求。
• 窗口：日志按 03:2x 轮转，服务器上现存最早的一份是 2026-09-25，更早的窗口已不在本地，无法回溯。
• 引荐：本窗口内，referer 指向 chatgpt.com / perplexity.ai 等 AI 产品的请求为 0 次。referer 在 App 内打开与隐私模式下会被剥离，因此这个 0 是「可观测上限为 0」，不等于「AI 一定没有带来访客」。
• 定性：<目录>/null 的根因判定采用「服务端源码排除 + 跨站交叉验证」，非厂商官方文档确认。我们据此做的是「对伪路径明确应答」，不是「宣布某厂商有 bug」。
• 不可复算项：外部交叉验证的三处公开记录属第三方观察，我们只做了指纹一致性比对，未复跑对方环境。

十一、落到 GEO：为什么这件事对中越品牌重要

传统搜索的下滑已经是定论：Gartner（2024-02）预测 2026 年传统搜索引擎流量将下降 25%；Bain 的调研显示 80% 的消费者已有至少 40% 的搜索需求交给 AI 结果。中国 GEO 市场从 2025 年的 349.3 亿元预计增长到 2026 年的 942 亿元（艾媒咨询 2026-02）；在越南，ChatGPT 的覆盖率已达 81%（Technode 2025-08）。

这些数字常被用来论证「要买 GEO 服务」。但本文的数据指向一个更朴素的结论：生成式引擎是从 robots.txt、sitemap 和内容目录里取材料的——这三件事做不好，谈被引用就是空话；这三件事做对了，才有资格谈内容与品牌。

所以越智通给客户做的 GEO 诊断，前三项就是本文第三节的三道门：规则可读（robots.txt + 放行声明）、索引完整（sitemap 无 404 的 loc）、内容页可解析（干净的结构化数据与正文）。第四项才是内容本身。

十二、数据来源与核验方式

第一方（可复算）：yuezhitong.com 站点 nginx 全量访问日志，窗口 2026-09-25 03:30:02 → 2026-10-06 02:01:28，共 11 个日志文件、2,235,940 行；管线为按 UA 声明分类 + 三层剔除（内网健康检查 / 自身来源 / 外部有效），产出结构化计数后写入本文。本文每一个第一方数字都可以用同一份 ETL 脚本在原始日志上重算，不依赖抽样。

第三方交叉验证（第六节 /null 指纹）：shuffle-on.com 威胁情报日志还原（Null: Eight Hundred Requests for a Page Nobody Ever Wrote）· headwall-hosting.com 的 WooCommerce 主机处置记录（把 /null 改判 410）· dev.ootssu.com 的 Search Console 404 排查记录。三处均为独立观察记录（其中两处日志时间戳为 2026 年），指纹一致。

行业口径（对外统一引用）：Gartner（2024-02，传统搜索 2026 年下降 25%）· Bain（80% 消费者至少 40% 搜索依赖 AI）· 艾媒咨询（2026-02，中国 GEO 市场 2025 年 349.3 亿元 → 2026 年预计 942 亿元）· Technode（2025-08，越南 ChatGPT 覆盖率 81%）。

处置核验：nginx 配置变更前做备份、nginx -t 语法校验、reload 后用 curl 对 8 条伪路径 / 10 条正对照 / 2 条负对照逐条回读，结果见第八节表。