📍 WDQWDWQD987AAAAA:216.73.216.150
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5de81aa98986.html
📄

永久重定向，怎样形成可复用检查清单

把永久重定向做成可复用检查清单，关键是固定三个环节：改前登记旧地址与新地址的一一对应关系，改中用状态码和最终落点做验证，改后定期抽查并保留回滚记录。永久重定向一般指 HTTP 301 或 308 状态码，它告诉浏览器和搜索引擎旧地址已永久迁移到新地址。清单的价值在于每次迁移都按同一顺序执行，避免漏掉某一批 URL 或某个语言版本。

先明确清单的适用前提

这套清单适用于站点改版、域名更换、目录结构调整、HTTP 迁移到 HTTPS 等场景。前提是你能拿到完整的旧 URL 列表，并且有权修改服务器或 CDN 的重定向规则。如果只是少量页面调整，用简化版清单即可；如果是整站迁移，必须逐条核对，不能只依赖一条通配规则。

需要区分两件事：永久重定向解决的是地址迁移，不等于索引移除。如果某个旧页面想彻底消失，应返回 404 或 410，而不是把它 301 到首页。把大量不相关旧页面重定向到首页，既不符合永久重定向的语义，也无法达到移除效果。

可复用检查清单的具体条目

1. 整理旧 URL 清单：从服务器日志、站点地图、站内链接和外部反向链接中汇总，标注每个旧地址对应的新地址。
2. 确认映射是一对一：内容相近的页面指向最相关的新页面，不要全部指向首页。确实没有对应内容的，标记为 404 或 410。
3. 选择正确的状态码：永久迁移用 301 或 308。308 会保留请求方法，涉及表单提交或 API 时可优先考虑；普通页面 301 已足够。
4. 检查重定向链：避免 A 跳 B、B 又跳 C。用 curl -I 逐条查看响应头中的 Location，确认一次跳转到位。
5. 检查循环：确认新地址不会再跳回旧地址，尤其是带斜杠与不带斜杠、带 www 与不带 www 之间的规则冲突。
6. 保留查询参数：带参数的旧地址跳转后，确认参数是否仍需传递。若参数影响页面内容，规则中应保留；若只是跟踪参数，可按需丢弃。
7. 核对大小写与结尾斜杠：服务器对大小写和斜杠的处理方式不同，清单中应列出这两类边界情况并逐一测试。
8. 更新站内链接：重定向是兜底手段，站内导航、文章内链、站点地图应直接指向新地址，减少不必要的跳转。
9. 记录回滚方案：保留旧规则备份，注明修改时间和负责人，出现问题时能快速还原。

用命令做一次最小验证

假设旧地址是 http://example.com/old-page，新地址是 https://example.com/new-page，可以执行：

curl -I http://example.com/old-page

观察返回结果：状态行应为 301 或 308，Location 应指向新地址。再对新地址执行一次，确认返回 200 而不是又一次跳转。如果第一跳返回 302，说明配置成了临时重定向，需要改为永久重定向。如果连续出现多个 301，说明存在重定向链，应合并规则。

这里的状态码是判断依据，不是唯一依据。服务器配置、CDN 缓存和浏览器缓存都可能影响实际表现，测试时应带上禁用缓存的参数，或换一个未访问过的环境验证。

验收信号与后续抽查

验收时看四个信号：旧地址返回永久重定向状态码；Location 指向预期的新地址；新地址直接返回 200；站内不再有指向旧地址的链接。四项都满足，才算这一批迁移完成。

上线后按固定周期抽查，比如每周抽一批旧地址重新执行上面的命令，观察是否出现新的跳转链或失效。搜索引擎处理重定向需要时间，不同搜索引擎的抓取和更新节奏不一样，不能以某一次抓取结果作为全部完成的依据。站点地图和 robots.txt 只能辅助发现和抓取，不能替代对重定向本身的验证。

下一步：从现有旧 URL 清单中挑出十条，按上面的命令逐条测试，把实际返回的状态码和 Location 填回清单，形成你们自己的基线记录。