先给结论:不要按系统数量或生成顺序决定责任方,而要按“哪一层拥有可对外承诺的网址语义”来定。若旧系统仍在产出可访问链接,唯一责任方应设在负责最终响应状态与规范标签的那一层;若旧系统只产出内部标识、不再对外暴露链接,责任方应设在承接迁移映射的新层。收录检查工具在这里的作用是提供证据,而不是裁决权。
判断责任方之前,先确认一个事实:旧系统生成的网址规则,是否还会进入用户可见页面、站点地图、站内搜索结果或外部引用。这个条件不同,责任归属完全不同。
两种条件的分界不是系统新旧,而是“是否还有对外可访问入口”。这个判断直接决定后续动作由谁执行。
不要凭系统名称或团队归属拍板。用下面三组证据交叉确认,能区分“看起来像责任方”和“实际能承担后果”的系统。
这三组证据指向同一层时,责任方基本可以确定;若指向不同层,说明存在职责重叠,需要先拆掉重叠,再指定唯一责任方。
确定责任方后,按以下顺序执行,避免两套规则继续同时对外生效。
这个顺序的关键是:先减少来源,再指定责任,最后验证。反过来做,责任方会在两套规则同时生效时被迫处理矛盾结果,无法给出稳定判断。
旧合作关系退出时,常见情况是旧系统由合作方控制,无法直接冻结其输出。这时唯一责任方仍应设在承接方,但需要额外动作:由承接方主动对旧地址做跳转或保留声明,而不是等待合作方配合。若合作方仍保留部分内容的对外入口,必须明确哪些路径由承接方负责、哪些由合作方负责,不能出现同一路径两方都声称负责。
另一种例外是旧系统仍产出被外部引用的地址,但合作方已无法修改。此时承接方应优先保证这些地址可访问或可跳转,再逐步替换引用。收录检查工具若显示这些地址仍在被引用,说明替换尚未完成,不能提前宣布旧系统已退出。
责任方指定后,用收录检查工具做一次验证,重点看三件事:同一路径是否只返回一种结果;旧地址是否仍被站内或站点地图引用;保留内容的规范标签是否指向自身而非旧地址。
假设一个场景:旧系统产出带参数的地址,新系统产出静态地址,两者都能访问。若责任方设在新系统,但旧参数地址仍被站内链接引用,收录检查工具会同时看到两个版本。此时正确动作不是让工具去重,而是回到引用层,把站内链接改为新地址,再由责任方对旧参数地址做跳转。这个动作完成后,工具看到的地址来源才真正收敛到一处。
需要说明的是,robots.txt 的抓取限制不等于可靠的索引移除,站点地图也不保证收录。因此验证责任方是否唯一,不能只看工具报告的数量变化,还要确认响应状态、引用来源和规范标签三者一致。请求量或抓取量下降本身不能证明责任方已唯一,也可能只是抓取预算变化或临时屏蔽所致。
最终判断标准很简单:当同一路径只由一个系统决定对外结果,且旧系统的输出不再进入可访问链接或站点地图时,唯一责任方才真正成立。在此之前,收录检查工具给出的任何异常都只是症状,不是责任归属的依据。