最容易被砍掉的三步，恰恰看不出页面变化

把官网改到 AI 能搜到，最容易被砍掉的三步，恰恰是做完之后页面一点变化都看不出来的那三步。

这话说得有点反直觉，但项目里几乎每次都这样。老板说我们在 AI 里搜不到，团队第一反应是改文案、加文章、补结构化数据。这三件事都能截图交差。而真正决定成败的前三步，取证、定主体口径、判断手上的到底是模板源还是渲染产物，做完给谁看都一样，页面上什么都没变。赶进度的时候，先砍的就是它们。

为什么顺序比技巧重要

举个本站遇到过的情形。同一个行业里有几家名字相近的独立法人，各自有站，公开资料里的成立年份、地址、称呼互相打架。这种情况下如果先去补结构化数据，会发生什么？机器不会替你判断哪套信息是对的，它只会挑一套复述。数据写得越完整、越规范，错误版本传播得越整齐。

所以先做主体口径归一，不是行政流程，是防止后面所有努力帮倒忙。

另一个更常见的误判是抓不到。客户说搜不到，听起来像被拦了。实际拿十几种爬虫标识裸请求首页，本站当年 12 种全部返回 200，响应内容摘要一致。门是开的，问题在屋里。这一步不验就动手改 robots 规则，等于给一扇开着的门再刷一遍漆。

一个下午就能自己验的动作

不用等服务商，也不用买工具。找一个能发自定义请求头的命令行工具，拿十来种常见 AI 与搜索爬虫的标识，分别请求首页、一个栏目页、一篇详情页，把状态码和返回内容摘要记下来。四种结果对应四种完全不同的活。

本站属于第三种。后面六周做的事，全是从这个结论推出来的。

网上那些做法，怎么看

公开能查到的建议大致分三类，混着看会出事。

一类有规范原文或平台官方口径撑着，比如爬虫排除协议里关于默认允许与最具体匹配的条款，这类可以直接当依据。顺带能得出一个不太讨喜的结论，把几十种爬虫名字逐个列出来显式允许，协议上并非必需，它的价值在防模板继承和方便日后审计，不在放行本身。

一类是行业里普遍在做、但拿不出公开验证的，比如某个机器可读文件被当成必做项甚至效果杠杆，比如用自研系统名称和精度百分比撑技术感。这类数字彼此矛盾，有些文章自己都写明找不到可链接的方法论，看个方向就行，别拿来做验收标准。企业自己做完对比测试、把结论发在官网并公开可查的，不算这一类，本站关于信源采信顺序的实测记录就按这个口径处理，发布时随文给出可复算的最小要素。

还有一类已经有公开反例。前述那个机器可读文件，一份覆盖 83 个站点、12 周的服务器日志研究里，某主流 AI 爬虫只抓了它 7 次，同期抓 robots 协议文件 3990 次。搜索侧也有官方指南明说不使用它。这类做法可以做，但要写清它管什么、不管什么，不能写进效果承诺。

什么时候不必这么做

只有后台发文权限、动不了服务器配置的团队，做到一半就该停，迁移与日志那两环硬凑没意义。内容型大站日均发稿几十条，主体与模板的复杂度是另一个量级，十步只能当骨架不能当排期。验收标准是两周内看询盘变化的，这套方法会让人失望，它验的是工程正确性，不是生意结果。

判断一家服务商，问三个问题就够

一，你怎么证明是抓不到还是读不懂，给我看请求记录。二，主体信息以哪一份为准，改一处之后哪几处会跟着变。三，做完拿什么复算，别给我看排名曲线，给我看状态码分布和逐页校验结果。

三个问题都答得具体，后面的报价才有得谈。答不上来，多半是打算从第四步直接开工。

想把这条链拆开看，方法论总纲的技术文档版给了十个环节的逐项产物、失败点与验证方式，可以顺着自己复算一遍。