SEO域名规范化改动前怎样保存原始状态：先做可回滚快照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /86534ae3da38.html
📄
SEO域名规范化改动前怎样保存原始状态：先做可回滚快照
改动前保存原始状态，核心是留下一份可对照、可回滚、可交付的快照：把当前域名、协议、www 与非 www、尾斜杠、大小写、参数处理、robots.txt、sitemap、canonical 标签、内部链接和服务器重定向规则全部记录下来。快照不是简单截图，而是能让协作者判断“改前是什么、改后变了什么”的原始证据。适用前提是多人协作、需要交付清楚、减少返工；如果只是个人临时试验，也应至少保留一份规则文件和抓取结果。
先确定要保存哪些原始对象
SEO域名规范化涉及的是同一内容被多个 URL 形式访问时，搜索引擎应选哪个作为规范版本。改动前要保存的对象包括：
- 当前可访问的域名形式：裸域、www、http、https 各自返回什么状态码。
- 服务器重定向规则：从哪些旧形式跳到哪个目标，跳转类型是 301 还是 302。
- 页面级规范信号：
rel="canonical"指向的 URL、站内链接使用的域名形式。 - 抓取与索引控制文件：robots.txt 内容、sitemap 中的 URL 列表。
- 代表页面的原始抓取结果：首页、栏目页、详情页各取几个，记录最终 URL、状态码和 canonical。
这些对象合在一起，才能回答“改动前搜索引擎看到的是什么”。只保存一份重定向规则不够，因为页面里的 canonical 和内部链接可能仍指向旧形式。
用文件快照而不是口头描述
多人协作时，口头说“之前是跳到 www”很容易在返工后失真。建议在改动前建立一个独立目录，按日期命名，例如 seo-normalization-before-2025-01-15/，把以下内容放进去：
- 导出服务器重定向配置或 CDN 规则原文，保留注释和顺序。
- 保存 robots.txt 和 sitemap 的完整文本。
- 对代表页面执行抓取，保存最终 URL、HTTP 状态码、canonical 和页面内主要内链。
- 写一份变更说明：谁在什么时候、准备把哪个形式改成哪个形式、影响哪些目录。
抓取可以用命令行工具完成，例如：
curl -I https://example.com/
把返回的 Location、状态码和最终地址记录下来。如果站点有登录或地域限制，要注明抓取环境，避免协作者误判。
保存原始状态时容易漏掉的三类信息
第一类是协议与主机名的组合。http 到 https、裸域到 www 是两组不同改动，混在一起记录会导致回滚时只改了一半。第二类是大小写和尾斜杠。有些服务器对 /Page 和 /page 返回不同结果，保存时要分别记录。第三类是参数 URL。带 ?utm_source= 或分页参数的地址如果被内部链接引用，改动前要保存这些链接的原始形式，否则规范化后可能留下新的重复入口。
还要注意：robots.txt 的抓取限制不等于可靠的索引移除。保存 robots.txt 是为了对照抓取规则变化，不是把它当成移除旧 URL 的手段。站点地图也不保证收录，保存它是为了核对规范化后提交的 URL 是否一致。
交付与验收信号
改动完成后，用同一套抓取命令和同一批代表页面复查，对比快照中的最终 URL、状态码和 canonical。验收信号包括：
- 旧形式到新形式的跳转状态码与变更说明一致，且没有跳转链。
- 代表页面的 canonical 指向规范化后的目标 URL，而不是旧形式。
- sitemap 和内部链接不再混用旧域名形式。
- 协作者能根据快照目录独立复现改动前的状态，不需要再问“之前是什么”。
如果发现跳转链、canonical 混用或 sitemap 仍含旧 URL，应回到快照对照，定位是哪一步改动遗漏，而不是继续叠加新规则。下一步建议先选定首页、一个栏目页和一个详情页作为最小对照集，按上述目录结构保存快照，再开始改重定向和 canonical。
