百度收录提交，多个系统同时生成网址规则时怎样定义唯一责任方
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /3c00b27b42f4.html
📄
百度收录提交，多个系统同时生成网址规则时怎样定义唯一责任方
先给结论：唯一责任方应当由“最终输出可被抓取网址清单”的那个环节承担，而不是由最先产生URL的系统承担。旧CMS、路由层、站点地图生成器、批量重写脚本都可能产出网址，但只要它们都不直接决定对外可访问的最终清单，就不该被指定为责任方。你需要先做一次“网址来源审计”，把每个系统的输出与线上真实可访问URL做比对，再决定保留哪一层、改写哪一层、退出哪一层。
先分清三种网址来源，别急着合并
多个系统同时生成规则时，常见来源有三类。第一类是内容系统，比如旧CMS或新后台，它们按模板拼接URL。第二类是路由或重写层，它把请求映射到实际路径。第三类是提交侧，包括站点地图生成器、主动提交脚本或人工整理的表单。这三类里，只有“提交侧最终产出的清单”才直接影响百度收录提交，因此责任方通常落在这里。
但前提是提交侧真的在控制输出。如果提交脚本只是直接读取内容系统的URL字段，那么内容系统才是事实上的责任方。判断方法很简单：改动内容系统的一条URL规则，观察提交清单是否同步变化。若同步变化，责任方在内容系统；若不变化，责任方在提交侧。这个动作会决定你下一步是改数据源还是改提交逻辑。
保留、改写、退出分别适用什么前提
旧系统或旧合作关系要退出时，不必一刀切。先按“是否仍产出有效可访问URL”和“是否仍被提交侧引用”两个条件分类。
- 保留：该系统产出的URL在线可访问，且提交侧仍在引用。此时保留它，但必须把它登记为唯一输出口，其他系统改为只读或停止输出。
- 改写：该系统产出的URL仍可访问，但格式混乱或与当前路由不一致。此时改写它的输出规则，使其与最终责任方的规则一致，再接入提交侧。
- 退出：该系统产出的URL已404、被重定向覆盖，或提交侧已不再读取它。此时让它退出，但要确认退出后线上URL仍可访问，否则会制造新的抓取障碍。
这里有一个容易忽略的条件：站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除。所以“退出”一个系统时，不能只靠屏蔽或删除站点地图来收尾，必须确认最终责任方输出的清单与线上可访问URL一致。
用一次假设的比对确定责任方
假设旧CMS输出example.com/item?id=123，新路由输出example.com/item/123，提交脚本读取的是旧CMS字段。此时线上可访问的是新路由地址，提交的却是旧地址。你按下面步骤做一次比对：
- 从线上抓取一份实际返回200的URL清单。
- 导出提交脚本当前输出的URL清单。
- 求两者交集与差集，差集里出现旧地址，说明提交侧读错了源。
- 把提交源改为新路由输出，重新生成清单。
这个动作的结果会直接影响下一步：如果差集缩小到可接受范围，就把新路由定为唯一责任方，旧CMS改为只读；如果差集仍然很大，说明还有第三个系统在覆盖输出，需要继续追查。
唯一责任方需要具备的三个可验证条件
指定责任方不是写一份文档就算完成，要满足可验证条件。第一，它输出的URL清单能被独立导出并复查。第二，它的输出与线上可访问URL的差异可被量化，而不是靠感觉。第三，改动它的规则后，提交清单会同步变化。三个条件都满足，才适合作为唯一责任方。
如果某个系统只满足第一条，它可能只是记录方，不是责任方。如果只满足第三条，它可能只是转发方。把转发方误认为责任方，是多个系统并存时最常见的误判。此时应回到上一步的比对结果，用差集变化来确认，而不是用系统名称或历史关系来判断。
退出旧系统时保留什么
旧系统退出后，仍有两类东西值得保留。一类是历史URL与当前URL的映射关系，用于确认重定向是否完整。另一类是旧系统里仍被外部引用的少量URL，它们需要被纳入最终责任方的清单，而不是直接丢弃。保留这两类内容的前提是，它们对应的线上地址仍然可访问，且不依赖旧系统的运行。
如果旧系统已经无法运行，但你仍需要保留部分URL，就把这些URL迁移到最终责任方的规则里，并重新生成提交清单。迁移后观察提交侧输出是否包含这些URL，若不包含，说明迁移未完成，不能宣告旧系统已安全退出。整个过程中，百度收录提交的清单只应有一个输出口，其他系统最多作为只读来源存在。
