技术 GEO 检查清单，按你该跑的顺序排好。

一份清单只有在按依赖关系排序时才有价值，而技术类项目之间的依赖尤其重。下面十项里有四项，一次命令行抓取就能定论。三项需要一个月的服务器日志留存，以及一个会查日志的人。还有三项根本不是修复：它们是关于“你希望别人的机器能读到什么”的决策。按这个顺序跑不是为了整齐，而是因为只有这个顺序下，结果才有意义。

依赖只朝一个方向流。如果一次普通抓取返回的是一道挑战而不是页面，那么之后你看的每一份日志都会是沉默，而这份沉默的原因跟引擎对你有没有兴趣毫无关系。如果 robots.txt 禁掉了搜索侧令牌，一个月的抓取数据读起来就像冷淡，团队于是得出“AI 引擎不关心我们这个品类”的结论，而事实是站点自己让它们别来。如果正文只在水合之后才存在，那么一次引用率测量测的是 JavaScript 包，而不是文字。这三种都是长得跟真阴性一模一样的假阴性，所以清单靠上的失败是一条“停止”指令，而不是一条留着以后再说的备注。

成本指向同一个方向。第一层是一台笔记本加十分钟。第二层要占一个人一天，还需要你未必有的日志留存。第三层要开一次会。便宜的检查为贵的检查把关，因此对第一层失败的正确反应是：修掉它、等厂商系统跟上、再从头跑一遍，而不是往下硬推。每一项背后的道理都在它自己的文章里，并从该项目直接链出；这一页新增的是顺序和执行方式。

第 07 项是最常和纸面配置对不上的一项。robots 指令是一个请求，靠守规矩的爬虫自愿遵守；机器人管理规则则是一次强制，它在你的应用看到任何东西之前就已经触发，而且通常由另一个团队维护，不是维护 robots 文件的那个团队。两者冲突时赢的是强制，于是 robots 文件可以错上好几个月，却不产生任何会被人注意到的症状。有个团队围绕一次 robots.txt 修正做了前后对比，发现抓取量纹丝不动，最后在边缘的托管机器人规则集里找到了原因，而不是在他们刚改过的那个文件里。日志数据该怎么读，包括怎么分辨一个真爬虫和一个只是顶着它名字的东西，在读爬虫日志里讲。

这些排除项不是口味问题。Google 的指引写道：你“不需要为了出现在 Google 搜索（包括其生成式 AI 能力）里而创建新的机器可读文件、AI 文本文件、标记或 Markdown，因为 Google 搜索本身并不使用它们”。² 这句话是第一方的、带日期的，这一点已经胜过它排除掉的那些打法所能拿出的任何东西。结构化数据依然值得为富媒体结果而上，那里的证据老而可靠；没有任何证据支撑的，是被硬挂在它身上的“能拿引用”这个说法。而且一份把所有听起来合理的项目都收进去的清单，会毁掉自己的用途。十项会被真的跑完。二十五项只会被扫一眼，而真正要紧的那四项，恰好在被扫过去的那一段里。