提交了 sitemap，AI 爬虫为什么还是不来读你的文章？

一、被高估的 sitemap：它只是一张清单

几乎每个做内容的人都默认一件事：把 URL 提交到 sitemap，爬虫就会来抓。这件事本身没错——sitemap 确实解决了「有哪些页面」的问题。但它没有解决「这些页面值不值得读」和「怎么走到这些页面」这两个问题。

把 sitemap 的能力边界说清楚，后面才好判断问题出在哪。

• sitemap 能做的：告诉爬虫本站有哪些 URL、它们上次什么时候更新、彼此的相对重要性排序。它是爬虫获取「站点地图」的主要途径，尤其对没有外链的新站，sitemap 往往是它发现新页面的第一个线索。
• sitemap 不能做的：它不表达页面之间是什么关系。一篇文章和一个产品页在 sitemap 里长得一模一样，爬虫无法从清单本身推断出「这篇文章讲的主题」与「产品页承接的主题」是同一个。
• sitemap 不会做的：它不传递内容质量信号。清单里有 50 个 URL，爬虫仍会自行决定先读哪几个、后读哪几个——而这个决定，依据的是链接结构，不是清单顺序。

本站的访问日志给出了足够清晰的对照。2026-10-20 至 10-23 四天窗口内，来源 IP 落在各厂商官方网段内的真实 AI 爬虫共发起 345 次请求。这 345 次请求落在哪里，是一个比任何主观判断都更有说服力的分布。

一句话记忆：爬虫花了近一半的力气在读「目录」，却几乎没有花力气在读「内容」。

这组数字说明的不是「爬虫不感兴趣」——如果真的不感兴趣，sitemap 也不会被反复读 167 次。更准确的解释是：爬虫把 sitemap 当成了「校验清单」而不是「抓取路线图」。它需要靠内链来理解站点结构、评估页面重要性、决定抓取深度，而 sitemap 只告诉它「这里有这些 URL」。

二、内链断网：为什么文章抓不到

上一项检查更直接：修复前，本站 12 篇文章（中文 6 篇 + 英文 6 篇）两两互链只有 26 条边；而 13 个中文业务页与 12 个英文业务页（合计 25 个），对文章的入链数量全部为 0。

「入链为 0」是一个比「文章数量少」严重得多的问题。设想你是爬虫：你在 /news.html 上看到 6 篇文章的链接，于是抓了 5 次；这 5 次里你只读到 1 篇的正文——因为剩下 5 篇的入链同样稀薄。而如果某篇文章的入链是 0，它连出现在你的候选队列里的机会都没有。

断网的三个具体位置

1. 孤岛文章：本站的《AI 爬虫到底什么时候来你的网站？9 天实测日志》一文，中英文两版在修复前的站内入链均为 0。它出现在 /news.html 列表里，但没有任何其他页面指向它——对爬虫而言，「列表页上的一个链接」权重远低于「多个页面的正文内链」。
2. 业务页与内容页之间没有通路：/geo.html、/overseas.html、/faq.html、/pricing.html 这些承接商业意图的页面，本身承载了站点最权威的主题信号，但它们一条文章链接都没有。主题信号与内容资产在结构上是断开的。
3. 锚文本缺失或不可读：站内几乎没有正文内链。所谓「延伸阅读」即便存在，也需要是有描述性的锚文本——「本文讲清了 GEO 与 SEO 的区别」这样的锚文本同时携带了语义，而裸 URL 不携带任何语义。

这三个位置指向同一个判断：内容不是被写出来的，是被连起来的。文章的正文质量决定它「值不值得读」，内链结构决定它「有没有被读到」。前者已经达标（22 个页面体检全绿：平均正文 8765 字、canonical 全有、无 noindex），后者此前是空的。

三、llms.txt：写给模型看的事实清单

llms.txt 是 2024 年后被广泛采用的约定：在站点根目录放一个纯文本文件，告诉大语言模型「这个站点是什么、可引用的范围是什么、有哪些关键页面」。它与 sitemap 的分工很清楚——sitemap 给爬虫 URL，llms.txt 给模型事实。

但本站此前的 llms.txt 存在一个典型问题：它详尽地描述了主体信息、服务边界与法务立场，却没有列出文章清单。对模型而言，这等于说「这家公司的服务范围是清楚的，但你写的文章是哪几篇，我看不到」。结果是 345 次真实爬虫请求里，llms.txt 只被读 3 次——爬虫不知道该拿它做什么。

三条可执行的结构改造

1. 把文章清单写进 llms.txt：每篇一行，包含标题、绝对 URL、一句话说明。说明文字用完整的陈述句（写清这篇讲什么、有什么独特结论），而不是标签。这 6 行文本的边际成本极低，但它让模型的「候选引用集」从 0 变成 6。
2. 重建文章互链环：把文章按主题逻辑串成环（定义 → 对比 → 诊断 → 度量 → 选型 → 实测），每篇的「上一篇/下一篇」指向环上的邻居，并保证环是闭合的。修复后孤岛文章归零。
3. 给业务页开正文内链：在 25 个业务页各加一个延伸阅读区块，每页 4–6 篇主题最相关的文章，锚文本写成「标题 —— 一句话说明」。这一步把商业页的主题权重与内容资产连起来。

这三条改造的共同点是：它们不增加任何内容，只改变内容的连接方式。这也是本文的核心主张——在内容总量还不算大的阶段，结构改造的边际收益高于内容新增。

四、改造后的实测变化

上述三条改造已在本站于 2026-10-23 完成。以下是改造前后的结构指标对比，全部可由公开页面与本站审计脚本复现。

需要说明的是，这组数字是结构指标，不是引用指标。引用率的变化要等搜索引擎与 AI 引擎完成一次重新抓取，通常需要一到四周才能观察到。结构改造解决的是「让爬虫够得着」，至于「够得着之后是否被引用」，取决于内容本身的独特性与来源可信度——那是另一件事。

同样需要坦白的是本次实测的边界：观测窗口只有 4 天，345 次请求的绝对量不大；且本站在此期间的服务器状态是稳定的，样本没有覆盖到爬虫抓取高峰的完整周期。结论适用于「结构是否可达」这一层判断，不宜外推为「引用率会提升多少」。

• 本节的全部数字均来自同一份日志快照与同一套判定脚本，可由第三方用公开手段复现；脚本与判定口径随文内说明一并公开。
• 改造前后的对比取自改造完成前后的两次独立测量，两次测量之间站点内容未再变动，因此差异可归因于结构改造本身。
• 「结构指标改善」与「引用率提升」之间没有必然的量级关系——后者还受内容独特性、信源权威度与引擎算法的影响，本文不对此作任何量化承诺。

五、给自己的站点做一次可达性体检

下面这张表可以直接拿去用。它的每一项都可以用公开手段验证，不需要任何付费工具。

这六项里，只要有一项为「否」，你的内容就处在「写好了但送不到」的状态。它们和内容质量是两条独立的线——本站的文章质量体检（正文长度、canonical、结构化数据、FAQ 段落）此前已全部达标，但如果可达性这六项没过，AI 引擎仍然读不到。