URL规范化：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c4ae40fa6a1c.html
📄
URL规范化：怎样取得可复查的状态证据
要取得可复查的URL规范化状态证据，关键不是看某一次抓取结果，而是把“你声明了什么”“搜索引擎实际选择了什么”“这个结论在何时、由谁、用什么方法得到”三件事同时记录下来。常见误解是：只要页面写了rel="canonical"，或者提交了站点地图，就算完成了规范化并已有证据。实际上，这些只是你的声明或提交动作，不等于搜索引擎已经采纳。可复查证据必须能让他人按相同步骤复现同一结论。
先分清“声明”与“选定”两类证据
规范化涉及两个层面。第一层是站点侧声明，包括<link rel="canonical">、301跳转、站点地图中的URL写法、内链指向。第二层是搜索引擎侧选定，即它最终在索引和展示时选了哪个URL。前者你能完全控制，后者只能观察和验证。
- 声明证据：页面HTML源码中的canonical标签、HTTP响应头中的Link、跳转链、站点地图文件内容。
- 选定证据：搜索结果中实际展示的URL、搜索引擎提供的URL检查或索引覆盖信息、抓取日志中搜索引擎访问的URL。
多人协作时最常返工的地方，就是把声明证据当成选定证据交付。正确做法是两类都留档，并明确标注哪一类是“我方配置”，哪一类是“外部观察结果”。
可复查证据必须包含的字段
一份能被他人复查的记录，至少要有以下信息，缺一项就可能导致结论无法复现：
- 目标URL与期望规范URL的完整写法，含协议、主机名、路径、尾斜杠和参数。
- 获取时间，精确到日期，必要时到小时，因为搜索引擎的选定结果会随时间变化。
- 获取方法：是查看页面源码、用命令行请求响应头，还是查看搜索结果。方法不同，结论的效力不同。
- 原始输出：响应头原文、canonical标签所在行、搜索结果截图或文本记录。不要只写“已确认”。
- 执行人与复核人，以及复核时使用的相同步骤。
例如，检查一个页面是否把带参数的URL规范到无参数版本，可以用命令行请求并保存响应头：
curl -I "https://example.com/page?ref=123"
如果返回301且Location指向无参数版本，这是跳转层面的声明证据；如果返回200且页面内canonical指向无参数版本，这是标签层面的声明证据。两者都存在时，跳转通常更强，但仍需观察搜索引擎最终选定的URL。
一个容易误判的检查项：robots.txt与站点地图
robots.txt中的Disallow只限制抓取，不等于可靠的索引移除。一个URL被robots.txt屏蔽后，搜索引擎可能仍因外部链接而将其收录，只是无法抓取内容来判断规范化。因此，用robots.txt来“解决”重复URL问题，往往得不到可复查的规范化证据，反而让状态更模糊。
站点地图同样只是提交动作，不保证收录，也不保证搜索引擎按你期望的URL建立索引。它可以作为声明证据的一部分，说明你希望哪个版本被优先发现，但不能单独作为“规范化已完成”的证据。
多人协作下的交付与复核步骤
要让证据可复查，建议把每次规范化检查做成固定流程，而不是依赖个人记忆：
- 由执行人记录目标URL、期望规范URL、获取时间与方法。
- 保存原始输出，例如响应头文本、源码片段、搜索结果记录。
- 标注结论类型：是“声明已配置”还是“已观察到搜索引擎选定”。
- 由复核人用相同方法重新获取一次，比对两次输出是否一致。
- 若两次结果不一致，先检查是否因时间、地区、登录状态或请求头不同导致，再判断是否需要修改配置。
适用条件是：团队需要交付清楚、减少返工。判断结果是：如果复核人无法用你记录的方法得到相同输出，这份证据就不算可复查，应补充原始数据或更换获取方法。
下一步
选一个当前存在多个URL版本的页面，按上面的字段做一份记录，交给另一位同事独立复核一次。若两次结论不一致，先统一获取方法，再决定是否调整canonical、跳转或内链。
