Baiduspider抓取：多系统生成网址规则时怎样定义唯一责任方
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3c5edd454f5f.html
📄
Baiduspider抓取：多系统生成网址规则时怎样定义唯一责任方
唯一责任方不应按“谁写了规则文件”来定，而应按“谁拥有网址的最终生成权”来定。做法是：先列出所有会产出同一批网址的系统，再指定其中一个为唯一权威来源，其余系统只能引用或消费它输出的结果，不能各自生成一份可被Baiduspider抓取到的网址清单。若两个系统都能独立决定URL形态且都能被外部访问，冲突就不可避免。
两种条件下该选谁当唯一责任方
第一种条件：网址由内容系统直接生成，路由、参数和分页逻辑都在同一个应用内。此时责任方应落在内容系统本身，站点地图生成器、缓存预热脚本、站内搜索索引都只能读取它的输出，不得自行拼接URL。判断依据是：只有它能同时知道某条内容是否存在、是否发布、是否允许被抓取。
第二种条件：网址由网关或路由层统一改写，多个上游应用只提供标识符。此时责任方应落在路由层，由它输出唯一的规范化URL集合，内容系统不再对外暴露自己的原始路径。判断依据是：外部可见形态由路由层决定，上游应用改路径不会改变最终URL。
两种选择的分界不在团队规模，而在“谁最后决定浏览器和Baiduspider看到的字符串”。如果两个系统都能决定，就必须先合并，而不是靠沟通约定。
用一组可区分的证据确认冲突来源
不要只看抓取量变化，那只能说明现象，不能定位责任。可用的区分证据包括：
- 同一内容出现两条外部可访问路径，且两条路径返回相同正文、不同URL字符串。
- 站点地图中的URL与页面内规范链接指向不一致，且两者由不同系统写入。
- 分页、筛选参数只在某一系统的输出中出现，另一系统完全不知道这些参数存在。
- 关闭其中一个系统的输出后，被抓取的URL集合发生明显收缩，但另一系统的URL仍然存在。
如果关闭某个系统后抓取量归零，也不能单独证明该系统就是正确责任方，因为也可能是它原本提供了唯一入口，关闭后入口消失，而非冲突被解决。需要同时确认保留下来的URL集合是否完整、是否可访问。
实施动作：先冻结，再收敛，最后验证
具体动作分三步。第一步，冻结所有系统的网址生成逻辑，禁止新增规则，避免冲突继续扩大。第二步，选定唯一责任方，让它输出一份权威URL清单，其余系统改为消费这份清单，不再独立拼接。第三步，用同一份清单去核对站点地图、内部链接和规范链接，发现不一致时以责任方输出为准。
这个动作的结果会直接影响下一步：如果收敛后仍出现责任方清单之外的URL被访问，说明还有未识别的生成点，应继续排查而不是调整抓取规则。如果清单内URL本身不可访问，问题在可用性而非责任归属，应转向发布流程。
例外：责任方无法唯一时怎么处理
有些架构中，多语言、多域名或多端确实需要不同系统各自产出URL。这时唯一责任方不是某一个应用，而应是一份共享的URL命名规范加一个校验环节：任何系统生成URL前都必须通过该校验，校验不通过则不得对外发布。责任落在校验规则的维护方，而不是落在每个生成方。
需要说明的是，robots.txt中的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此责任收敛的目标是让外部可见URL集合唯一且可控，而不是承诺抓取或收录结果。
假设例子：两个系统各生成一份分页URL
假设内容系统生成 /list?page=2，前端渲染层生成 /list/page/2，两者都返回相同列表且都可访问。此时不应比较哪种形式更好，而应先指定其中一个为唯一权威，另一个改为301或不再输出。若保留两种形式，Baiduspider抓取时可能分别访问，导致同一内容对应多个URL。验证方式是：收敛后检查是否还存在责任方清单之外的列表URL被请求；若存在，说明收敛未完成；若不存在，再检查清单内URL是否都能正常返回内容。
责任定义要写进可执行的约束
口头约定“以某系统为准”通常无效，因为发布流程不会自动阻止另一系统输出。可执行的约束包括：在构建或发布阶段比对URL清单，出现清单外URL时中断发布；或在网关层拒绝非规范URL对外返回正文。选择哪种约束取决于团队能在哪一层拦截。能拦截的一层，才适合承担最终责任。
如果当前既无法合并生成逻辑，也无法在发布阶段拦截，那么优先动作不是继续调抓取配置，而是先建立一份人工维护的权威URL清单，并让所有系统在输出前对照它。清单本身可以暂时不完美，但必须只有一个版本，否则责任仍然分散。
