一行配置能让 GEO 全盘归零：上线前必查 robots.txt
先说我们自己的一次疏漏：给一个新站做多站点主机名改写时，我们只改了 sitemap 里的页面 URL，漏掉了索引文件里指向子 sitemap 的地址，整份 sitemap 等于失效 —— 而文件都在、都能打开、内容看着也对。这类错的共同点是不报错，站点跑得很正常，只是永远不被收录。这篇把这一类问题整理成一份上线自检清单。
后果是一条没有缓冲的链条
robots.txt 禁止抓取 → 页面进不了搜索索引 → AI 检索不到 → AI 不可能引用。
这条链上没有任何环节能补救。站内做得再好、内容写得再扎实、结构化数据标得再全，都停在第一步。这是 GEO 里唯一一类「一票否决」的问题。
而它的修复成本几乎是零 —— 删掉一行。零成本可避免、一犯就全盘归零，所以它必须排在检查清单的第一位。
为什么这么常见
最典型的一个是 robots.txt 里的 Disallow: /。而它常见的原因是：测试期禁止收录本身是对的做法。新站还没定稿就被收录，会留下一堆垃圾索引，所以开发时加上禁止抓取是标准操作。
问题出在上线是一个多方协作的节点：设计确认、内容确认、域名解析、备案、SSL……robots.txt 不在任何人的验收清单里，因为它不影响页面看起来对不对。我们见过注释里明明写着「测试期使用，正式上线后请删除」，上线了但没删的情况。
更麻烦的是它没有任何报错。站点跑得很正常，只是永远不会被收录。往往几个月后才发现「怎么一直搜不到」 —— 而这几个月里做的所有内容工作都是白做的。
我们的上线自检顺序
按「一票否决 → 影响面大 → 优化项」排序，前四项没过就不用往下看：
- robots.txt 是否放行。 确认没有全局
Disallow: /，也确认没有单独屏蔽某个搜索引擎的爬虫段。 - 是否专门放行 AI 爬虫。 主流搜索引擎的爬虫大家都会放，但 AI 厂商的抓取 UA 是另一批，默认规则未必覆盖。我们自己站上逐个列出并放行了二十多个 AI 相关 UA 段。
- sitemap 是否可访问、且主机名正确。 这里有个容易漏的点见下一节。
- 首页与关键内页返回 200，不是 302 到别处。
- 结构化数据能否解析。 一个 JSON 语法错误会让整块数据失效，而页面看起来毫无异常。
- llms.txt 是否存在。 这一项不是硬门槛，是加分项 —— 它是一份给 AI 看的站点摘要，成本极低但需要主动做，目前在中文站点里还很少见。
- 站内搜索索引是否生成。 如果用的是构建时生成索引的方案，要确认那一步真的跑了。
sitemap 的一个隐蔽错误
如果站点在构建时要改写主机名（比如多站点复用同一套模板），注意 sitemap 是两层结构：一个索引文件，里面列着若干子 sitemap 的地址，子 sitemap 里才是具体页面的 URL。
我们自己踩过这个坑：改写脚本只处理了子 sitemap 里的页面 URL，漏掉了索引文件里指向子 sitemap 的那几行地址。结果索引文件指向一个错误主机名下的子 sitemap，整份 sitemap 等于失效。
表面现象很不明显 —— sitemap 文件都在、都能打开、内容看着也对。要发现它得对着索引文件里的地址逐个访问一遍。
这件事和「诊断」的关系
这也是为什么我们把可见性诊断放在所有工作的第一步，而且诊断的第一个动作是查 robots。
对一个被 robots 挡住的站点做内容优化，是纯粹的浪费。而这类问题往往一次检查就能发现、当天就能修 —— 投入产出比高到不做没有道理。
要点回顾
- robots.txt 一行 Disallow 会让整条 GEO 链路归零，且没有任何环节能补救
- 它常见的原因是测试期禁止收录是对的做法，但删除动作不在任何人的上线清单里
- 自检顺序：robots → AI 爬虫放行 → sitemap → 状态码 → 结构化数据 → llms.txt → 站内索引
- sitemap 是两层结构，改写主机名时索引文件里的子 sitemap 地址也要一起改
依据：sitemap 两层改写的错误来自我们自己的建站过程，已修复并写入上线自检清单；robots.txt 为公开可访问文件，任何站点的配置都可自行核验。本文不针对任何特定站点。