永久重定向改动前怎样保存原始状态：先留证据再动手
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0a2c009808c5.html
📄
永久重定向改动前怎样保存原始状态：先留证据再动手
在配置永久重定向之前，先把原页面的可访问状态、响应头、正文内容和内部链接关系完整留存下来。保存的目的不是备份文件本身，而是保留一份可以对照的“改动前快照”，这样重定向上线后如果出现异常，你能判断是跳转方向错了、状态码用错了，还是原内容被误删。适用前提是：你打算让某个已有URL永久指向新地址，并且这个URL已经有流量、有外链或有排名。
先分清要保存的是哪几类状态
“原始状态”不是单一文件，至少包含四层信息，缺一层后面就可能说不清问题出在哪。
- HTTP层：原URL返回的状态码、响应头，尤其是
Location、Cache-Control、Content-Type。 - 内容层：页面正文、标题、结构化数据，以及页面上的规范链接标签。
- 链接层：站内有哪些页面指向这个URL，外链大致来自哪些域名。
- 索引层：该URL此前是否被搜索引擎收录、收录的是哪个版本。
这四层里，HTTP层和内容层最容易在改动中被覆盖，所以必须在配置重定向之前抓取，而不是之后补。
具体做法：用可复核的方式抓取快照
下面是一套可以直接执行的步骤，按顺序做，每一步都留下带时间的文件。
- 用命令行抓取响应头，保存为文本。例如对单个URL执行
curl -I https://example.com/old-page，把输出重定向到文件并记录抓取时间。注意-I只取头部，适合看状态码和跳转链。 - 抓取完整响应，保留状态码与正文：
curl -i https://example.com/old-page -o old-page-before.txt。加-i是为了让状态行和头部一起进文件，日后能证明当时返回的是200还是301。 - 保存页面正文的可读副本。浏览器“另存为”或抓取工具导出HTML都可以，但要同时记录抓取日期。如果页面内容由前端脚本渲染，纯HTML快照可能不含正文，需要额外截图或保存渲染后的DOM。
- 导出站内链接关系。用站点爬取工具跑一遍，筛选出“链接到该URL”的页面清单，导出为表格。没有工具时，至少用站内搜索或数据库查询列出引用该路径的模板和文章。
- 记录索引状态。在搜索引擎中用
site:加具体URL查询，截图保存结果。这一步只作参考，因为site:查询结果不等于官方索引数据，不同搜索引擎结果也会不同，需要分别核查。
如果原URL本身已经在做跳转，抓取时要特别小心：curl默认不跟随跳转，能拿到第一跳的状态码；加-L会跟随到最终地址。两种都抓一次，才能看清跳转链的原始形态。
保存时容易踩的三个坑
只存了正文，没存状态码。很多人习惯复制页面文字，但重定向出问题时，争议点往往是“原来返回的是200还是301”。没有状态码记录，就无法判断改动是否引入了额外的跳转层。
用robots.txt当作保护手段。抓取限制不等于可靠的索引移除。如果改动前想临时阻止抓取，要明白robots.txt只约束爬虫抓取行为，已经收录的URL仍可能出现在结果中，也不能替代对原始状态的保存。
把站点地图当成收录证明。站点地图里列出了某个URL，不代表它一定被收录。保存原始状态时应以实际抓取到的响应和页面内容为准，而不是以站点地图条目为准。
验收信号：怎样算保存到位
改动完成后，用保存的快照做对照，满足以下条件才算原始状态留得住：
- 能拿出改动前的状态码记录，且与改动后第一跳的状态码形成明确对比。
- 原URL的正文快照可读，标题和主要段落与记忆中一致。
- 站内链接清单存在，重定向上线后可以逐条检查这些链接是否仍能到达有效页面。
- 如果原URL此前被收录，改动后仍能通过查询确认它指向了新地址，而不是变成404或软404。
判断结果时注意：重定向生效需要时间，不同搜索引擎对永久重定向的处理节奏不一致，短时间内查询结果未更新属于正常现象，不能据此断定配置失败。真正需要立刻排查的是跳转链是否出现循环、是否跳到了无关页面、是否返回了5xx。
下一步：把上面抓取到的文件按“URL+日期”命名归档，然后再去配置永久重定向。配置完成后，用同一套抓取命令再跑一次，把前后两份响应头并排比对，确认第一跳就是目标地址且状态码符合预期。
