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

301转向怎样形成可复用检查清单：从单次改版到每次上线都能照着走

把301转向做成可复用检查清单，核心是把一次改版中“凭记忆检查”的动作，固化成固定顺序的核对项：先确认旧地址确实需要迁移，再逐条记录旧URL、目标URL和跳转类型，然后验证状态码、跳转链、参数与内链，最后留下可复查的记录。下面这份清单可以直接复制到表格或工单模板里，每次改版、换域名、调整目录结构时按同一顺序执行。

第一步：确认哪些旧地址必须做301

不是所有被删除的页面都适合301。判断依据是旧页面是否还有搜索流量、外部链接或用户收藏价值。

• 要查什么：旧URL清单，以及每个URL对应的新URL是否存在。
• 怎么查：从站点地图、服务器访问日志、搜索平台的效果报告、外链工具中导出旧地址，逐条标注“有等价新页”“无等价新页”“应返回410”。
• 结果说明什么：有等价新页的做301；内容彻底消失且无替代的，返回410比301到首页更合适；把大量无关旧页301到首页，通常会被视为软404式处理，不利于权重传递。

这一步的产出是一张映射表，至少包含三列：旧URL、新URL、处理方式。这张表就是后面所有检查的依据。

第二步：核对跳转本身是否正确

映射表确定后，要验证服务器实际返回的响应，而不是只看配置文件写了什么。

1. 用命令行工具请求旧URL，例如 curl -I https://example.com/old-page，观察第一行状态码和 Location 头。
2. 确认状态码是 301（永久）而不是 302、307。302是临时跳转，不适合长期迁移。
3. 确认 Location 指向的新URL与映射表一致，且新URL本身返回 200。
4. 检查是否存在跳转链：旧URL→中间URL→最终URL。每多一跳都会损失传递效率，应尽量压成一跳直达。
5. 检查是否形成循环：A跳B、B又跳回A，这类问题会导致页面无法访问。

判断结果：状态码正确、目标可达、无链无环，这一项才算通过。任何一项不满足，都要回到映射表修正。

第三步：检查参数、大小写与斜杠变体

同一页面常有多种URL写法，迁移时容易漏掉变体，造成部分流量仍落在旧地址上。

• 要查什么：带查询参数的旧URL、大小写不同的路径、带与不带结尾斜杠的版本。
• 怎么查：抽样请求 /Old-Page、/old-page/、/old-page?ref=abc，看是否都能到达正确目标。
• 结果说明什么：如果只有标准写法跳转、变体返回404，说明规则覆盖不全。参数应尽量保留或按业务需要决定是否丢弃，但不要出现参数版落到错误页面。

适用条件：站点使用不区分大小写的服务器时，这一项可能自动通过；若使用区分大小写的环境，必须单独验证。

第四步：处理内链、站点地图与robots相关项

301只解决外部和旧入口的跳转，站内如果还大量指向旧URL，会持续产生跳转消耗。

• 内链：全站扫描是否还有指向旧URL的链接，能改直连的就改成新URL，减少不必要跳转。
• 站点地图：更新为只包含新URL。站点地图不保证收录，但保留大量旧地址会干扰抓取判断。
• robots.txt：不要用robots.txt屏蔽旧URL来“代替”301。抓取限制不等于可靠的索引移除，被屏蔽的旧页可能仍留在索引中且无法传递信号。
• HTTPS：若迁移同时涉及协议变更，确认跳转终点是HTTPS版本。HTTPS不保证安全无漏洞或排名提升，但协议不一致会产生额外跳转。

第五步：上线后按固定周期复查并留档

清单的价值在于每次都用同一套记录，便于对比和追责。

1. 上线当天：抽查高流量旧URL和随机样本，记录状态码、目标URL、跳转跳数。
2. 上线后一周：复查服务器日志中仍返回404或302的旧地址，补充遗漏映射。
3. 上线后一个月：核对搜索平台中旧URL的索引状态变化，确认新URL开始被正常抓取。
4. 留档：把映射表、检查日期、检查人、异常项与处理结果存进同一工单，下次改版直接复用格式。

不同搜索引擎对跳转的抓取与处理节奏不同，复查时应分别查看各自平台的数据，不能用一个平台的结论推断全部。

下一步：拿最近一次改版的旧URL清单，按上面五步跑一遍，把缺失的列补进表格，这份表格就是你自己的301转向检查清单初版。