唯一责任方不是某个团队,而是“网址规范源”这一角色:所有对外可见的URL必须由它生成,其他系统只能引用或校验,不能各自拼装。这个结论成立的前提是,你已确认当前存在至少两套系统会产出可被爬虫发现的网址;如果只有一套,问题就不在责任划分,而在配置正确性。
假设某业务同时运行CMS、商品中台和营销活动页生成器。CMS负责栏目与详情页,中台按SKU拼出带参数的列表页,活动生成器再根据渠道拼出带追踪参数的落地页。三套系统都能输出完整URL,也都能被站内链接或站点地图暴露。此时若只问“谁的规则对”,永远吵不出结论,因为三套规则都“对”,只是各自面向不同用途。
把问题换成:对外可索引的规范URL由谁签发。这个角色一旦确定,其他系统产出的URL只能作为内部跳转或参数变体,不进入站点地图,不作为内链首选目标。责任方定义的是签发权,不是所有URL的生成权。
关键前提发生变化时,原责任方可能不再适用。常见变化包括:业务从单渠道变成多渠道、从静态页转为参数化列表、从自建CMS换成外部中台、或者原本只做站内搜索的页面开始被允许索引。
判断依据不是系统数量,而是“谁有权决定一个URL是否对外可见”。如果两个系统都能决定,就等于没有责任方。
以下现象不能单独证明责任方错了,但组合出现时,说明签发权已经分散:
这些证据指向的是同一件事:没有单一签发方。此时先不要改规则,先指定签发方,再让其他系统改为引用。
责任方确定后,第一个动作是产出一份“可索引URL签发清单”,只包含允许对外索引的路径模式与参数白名单。其他系统不得自行扩展该清单。
这个动作的结果会直接影响下一步:如果签发清单落地后,站点地图与 canonical 开始收敛到同一组地址,说明责任方生效;如果仍然出现清单外的可索引地址,说明还有系统保留了签发权,需要继续收回,而不是继续加规则。
签发清单解决的是站内一致性问题,不解决各搜索引擎的抓取与索引差异。不同搜索引擎对参数处理、canonical 信号和站点地图的采用方式并不相同,必须分别核查。站点地图不保证收录,HTTPS 也不保证安全无漏洞或排名。责任方的职责是让对外信号一致,而不是承诺收录结果。
如果核查后发现某搜索引擎仍抓取清单外地址,先确认该地址是否被其他系统引用,而不是直接改签发规则。签发规则一旦被个案频繁修改,责任方就会再次失效。
两个系统同时生成网址并非绝对禁止,但必须满足一个条件:只有一个系统拥有签发权,另一个只生成内部使用的临时地址,且这些地址不进入站点地图、不作为内链目标、不被任何可索引页面引用。如果做不到这一点,就不要保留双生成,否则责任方只是名义上的。
假设情境中,活动生成器可以继续拼追踪链接,但这些链接只能出现在广告跳转或站内点击事件中,不能写入 canonical,也不能被站点地图采集。这样既保留渠道追踪,又不破坏唯一签发方。
最终判断标准很简单:当有人问“这个URL为什么存在”时,能指向唯一一个系统给出答案,并且该答案与站点地图、canonical 和内链一致。做不到这一点,就还没有定义好责任方。