站点迁移时链接的去向 链接指向的是 URL，而非站点。更改 URL 后，所有指向旧 URL 的链接都需要重定向。
在迁移上线之前，这听起来显而易见。许多团队都了解这一规则。例如，WordPress 迁移、从 www 切换到裸域名或新的分类结构在周五上线，并附注说明“稍后添加重定向”。当你迁移后检查网站外链时，问题从来不是存在多少链接，而是有多少链接仍然指向活跃页面，而十分钟例行检查 中的第五步可以回答这个问题。
Google 关于迁移的官方指南要求旧 URL 到新 URL 的一一映射。服务器端 301 重定向完成这项工作。尽可能长时间保持重定向有效。对于域名变更，Search Console 中的“更改地址”工具是一个额外步骤。映射仍会以可预测的方式出错，Screaming Frog 或 Ahrefs Site Audit 会暴露大多数此类问题。
工具在此处很有帮助：Search Console 显示 Google 侧的抓取和覆盖情况，Screaming Frog 列出抓取过程中的重定向链，而我们的首页数据调用显示哪些 URL 携带外链。没有任何单一工具能提供完整画面，而组合使用在小型站点上只需不到一小时。
错误、症状与修复 错误 数据中的表现 修复 所有链接重定向到首页 被链接最多的页面全部消失；首页是唯一剩余的 URL 将每个旧 URL 映射到其最接近的新页面 www 和裸域名均返回 200 状态码 相同链接分散在两个主机上 选择一个主机，将另一个 301 重定向到该主机 包含三个或更多跳数的重定向链 顶级页面经过多次跳转后才能解析 将旧 URL 直接指向最终 URL 永久迁移使用了 302 状态码 旧 URL 仍作为被链接页面出现 迁移完成后切换为 301 旧的“关于”页面已删除，未进行重定向 一个高外链 URL 返回 404 将其重定向到新的“关于”页面 重新构建分类结构但未进行映射 数十个被链接的 URL 返回 404 先导出旧 URL，然后在电子表格中进行映射
通过两次调用即可找到失效的价值 获取被链接最多的页面，然后在浏览器或使用 curl -I 测试每个 URL。任何非干净的 200 或单次 301 重定向的 URL 都应列入清单。
bash
# which old URLs carry the links (2 credits, billed once)
curl "https://linkskimmr.com/api.php?action=toppages&q=clientsite.com&per=200&key=sk_live_..."
# then, for each URL you care about
curl -sI https://clientsite.com/old-page | head -5
我们会采用的修复顺序 1 首先修复主机 一个规范主机，其他所有主机 301 重定向到它。这只需几分钟，且能一次性影响所有链接。
2 映射前二十个 URL 二十个高外链页面通常承载大部分价值。手动进行一一映射。
3 扁平化重定向链 将每个多跳路径替换为指向最终 URL 的单跳重定向。
4 下个月重新检查 我们的索引大约每月刷新一次，因此在宣布修复成功或失败之前，请等待一个周期。
值得明确指出的限制 修复重定向可将链接价值返回到活跃页面。它不保证排名，也无法恢复在源头被移除的链接。在客户文件中注明这两点。
我们最常听到的重定向问题 我可以只将旧页面重定向到新的“关于”页面吗？ 可以，当新页面提供相同目的时。将旧 URL 301 重定向到最接近的等效页面可保持链接的有用性。将所有死链重定向到首页效果不佳，因为目标页面不再匹配链接所承诺的内容。
一个站点上过多的 301 重定向会有问题吗？ 数量不如路径结构重要。长链浪费抓取精力且更容易出错，因此确保每个旧 URL 仅经过一次跳转，并将完整映射保存在可审计的电子表格中。
如何将 www 重定向到非 www 版本？ 选择一个主机作为规范主机，然后在服务器或 DNS 提供商处添加从另一个主机到该主机的全站 301 重定向。使用 curl -I 测试两个版本，并确认首页数据列表中的链接指向所选主机。
迁移上线当周需检查的内容 如果你在迁移当周检查网站外链，请先检查映射而非数据。映射决定了数据是否有可能恢复。
抓取旧站点地图，而不仅是新站点地图 旧站点地图仍列出最初获得排名的 URL。将其与活跃站点进行比对，每一行返回 404 或重定向链的都将成为映射中的一行。
保留带有日期名称的抓取输出。一个月后的第二次抓取将显示哪些修复有效，哪些重定向悄然消失。
比较迁移前后的顶级页面 保存迁移前的首页数据列表，然后在新站点稳定后再次运行调用。一旦应用映射，两个外链 URL 列表应相互对齐，未对齐的行即为待办事项。
每次运行消耗 2 个信用额，因此比较成本很低。成本在于映射，而非数据。
查找遗留的暂存规则 阻止抓取器的规则可能在发布后未被注意地保留下来。在宣布迁移完成之前，检查 robots.txt 以及承载最佳外链页面的模板中的 noindex 标签。
客户文件中只需一行即可：检查了哪些模板，以及检查日期。在每个重定向旁边注明负责人，因为一个无人能解释的重定向会在下一次重新设计中被删除。
哪种重定向代码适合永久迁移 代码是一个小选择，但对发送的信息影响巨大。抓取器在读取旧页面上的任何其他内容之前，会先读取状态码。
为什么 301 适合最终迁移 301 表示迁移是永久的。302 表示旧地址可能会恢复，这对于最终迁移来说是错误的信息。仅在真正运行临时测试时使用 302。
迁移完成后，将任何临时重定向切换为 301。将 302 保留数年是一种让迁移处于半完成状态的安静方式。
为什么 302 后接 301 会出错 一个转发到第二个 URL 的 302，而第二个 URL 又发送 301，会产生两次跳转和混合信号。搜索引擎通常可以跟随该链，但该链速度较慢，且下次有人编辑规则时更容易出错。
将其折叠为一个直接指向最终地址的 301。单跳更易于测试，更易于向客户解释，也更容易保持有效。
如何重定向带有查询参数的 URL CMS 更改后，带有查询字符串的旧 URL 很常见。假设旧地址是一个带有颜色参数的产品页面。决定该参数是否改变内容。如果改变，将带参数的 URL 映射到匹配的新页面；如果不改变，一条丢弃参数的规则即可服务于该页面。
规则上线后手动测试几个带参数的 URL。适用于纯路径的规则仍可能忽略查询字符串，而携带参数的链接正是你容易遗漏的。
三种看似修复实则不然的重定向 某些重定向通过状态检查，但仍会丢失价值。页面返回 301，但目标对于跟随链接的人和抓取器来说是不正确的。
重定向循环 两个相互发送的规则在浏览器中显示为循环，大多数工具在经过几次跳转后会放弃。测试旧 URL，计算跳数，并修复指向起始位置的那个规则。
循环是最容易发现的问题，也最容易留到一周后再处理。在发现当天修复它，并使用 curl -sIL 计算跳数，以便读取每一行状态码，而不仅仅是最后一行。
重定向到登录界面 一个高外链的旧页面重定向到登录表单，会给访问者带来一堵墙，而不是链接所承诺的内容。假设你将以前的指南重定向到登录页面，然后跳转到第三方登录。这条路径中的任何内容都不利于链接。
重定向到与链接内容匹配的公开页面。如果不存在此类页面，干净的 404 比重定向到无用页面更诚实。
继续 一个假设的工作示例 设想一个客户从一种博客主题迁移到另一种主题。示例数字仅供参考。
假设首页数据报告在迁移前列出了 140 个带有链接的 URL，迁移后有 90 个返回 404，因为新的永久链接模式丢弃了日期文件夹。手动映射其中二十个被链接最多的页面可以在一个下午恢复大部分指向价值，而阈值表 告诉你如何向客户描述这一变化。
当客户询问发生了什么变化时，相同的映射是最好的答案。展示二十个映射 URL 的旧地址、新地址以及每个 URL 的状态码。表格具有说服力。二十行比任何摘要都更具说服力，且该表格可作为下一轮检查的清单。
