canonical：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0bf011ceb0b6.html
📄
canonical：改动前怎样保存原始状态
改动 canonical 之前，必须先把“当前线上真实状态”完整留档，而不是只复制一段标签。最小可交付物包括：原始 HTML 中该 URL 的 canonical 标签原文、它指向的目标 URL、该页面的最终状态码与重定向链、页面可被访问的原始响应头，以及这份记录的抓取时间与执行人。保存的目的是让任何协作者都能回答：改之前它是什么、改之后是否只改了预期部分、出问题时如何回退。
先定义要交付什么，再决定保存什么
从交付结果倒推最稳妥。假设你所在团队要交付的是“把某栏目页的 canonical 从自指改为指向汇总页”，那么验收时需要的证据至少有三类：
- 改动前基线：原始 canonical 值、所在位置（
<head>内还是 HTTP 头）、该页当时的最终 URL。 - 改动记录：改了哪个文件或模板、由谁改、什么时间发布、预期影响哪些 URL。
- 改动后对照：同一 URL 的 canonical 新值、状态码、是否仍可访问，以及与基线的差异清单。
如果只保存 canonical 值，缺少最终 URL 和状态码，后续就无法判断差异是标签造成的，还是重定向或渲染造成的。多人协作中最常见的返工，就是两个人分别改了模板和重定向，却没人知道原始基线长什么样。
保存原始状态的四个具体动作
以下动作可以直接执行，顺序不要颠倒：
- 先抓取，后编辑。在改动任何文件之前，用浏览器开发者工具的“网络”面板或命令行抓取工具请求目标 URL，保存完整响应。命令行示例：
curl -sIL "https://example.com/page"，其中-I只看响应头，-L跟随重定向。假设示例，请替换为实际 URL。 - 记录 canonical 的原始文本。在页面源代码中搜索
rel="canonical"，把整行原样复制，包括引号内的大小写和结尾斜杠。不要只记“指向首页”这类描述。 - 记录该 URL 的最终形态。写下状态码（200、301、404 等）、重定向链每一跳的地址，以及是否由 JavaScript 插入 canonical。若 canonical 由脚本动态写入，要同时保存渲染后的 DOM 片段。
- 给记录加时间戳与责任人。格式建议：抓取时间（含时区）、执行人、使用的工具与版本、抓取的是线上还是预发环境。没有这些，后续无法判断记录是否对应改动前那一刻。
用检查项判断原始状态是否保存完整
保存完成后，逐项核对，任何一项为“否”都要补：
- 能否在不访问线上的情况下，还原出改动前该 URL 的 canonical 值？
- 能否说明该 canonical 是服务端输出、模板输出还是客户端脚本输出？
- 能否指出该 URL 改动前是否参与重定向，以及重定向的终点？
- 记录中是否区分了“抓取到的原始响应”和“浏览器渲染后的结果”？
- 换一个协作者，能否仅凭记录判断改动是否超出预期范围？
适用条件：只要 canonical 改动会影响多个 URL、多套模板或多人协作，就应执行完整留档。若只是单人、单页、可立即回退的实验，可以缩减为保存 canonical 原文加最终 URL，但仍需记录时间。
常见误区与判断结果
第一，把“截图”当作原始状态。截图无法还原标签原文，也无法验证响应头，只能作为辅助。第二，只保存改动后的值。这样在出现收录异常时，无法证明问题是改动引入还是原本存在。第三，把 robots.txt 限制、站点地图提交或 HTTPS 当作 canonical 改动的保护措施——robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名，它们都不能替代原始状态留档。
判断结果的方法：改动发布后，用同样的抓取方式再取一次，与基线逐字段对比。若差异仅出现在预期字段（canonical 值），说明改动范围可控；若状态码、重定向链或渲染结果同时变化，应先排查这些变化是否由本次改动引起，再决定是否继续。
下一步：在改动前，先按上面的四项动作生成一份基线记录，并让至少一名协作者确认能据此还原原始状态，然后再动模板或配置。
