分析迁移期间的链接网站变化

在上线前构建重定向映射

重定向映射是迁移中最容易被低估的部分。目标 URL 至关重要。在迁移后分析链接网站数据之前，旧 URL 需要有明确的目标，因为这些是链接已经指向的地址。

一对一重定向优于首页重定向

将数百个不相关的旧 URL 重定向到首页，向搜索引擎和访客传递的信息非常有限。相关性是测试标准。将每个高价值的旧 URL 映射到其最接近的新页面，其余的则重定向到仍与其主题匹配的分类页面。

首先导出带有状态码的旧 URL。妥善保存该文件。该文件就是检查清单，它显示了哪些页面获得了链接。

如果某个页面没有接近的匹配项，请在映射表中注明，并将其重定向到最近的分类，并添加备注。空白单元格会隐藏决策。表格中的空白单元格意味着没有人做出决定。

在上线前简化重定向链

在到达新页面之前经过两个早期规则的重定向会增加延迟和风险。当第二次迁移叠加在第一次迁移之上时，很容易形成重定向链，因此在每次切换前审查映射表，而不是假设它仍然干净。每次额外的跳转都会带来成本。在切换后请求每个旧 URL 一次，并确认它仅通过一次跳转响应。

尽早修复。在映射表中修复重定向链，而不是在上线后逐个修复，以保持列表简短。

保留仍然有效的路径

在重新设计时更改 URL 结构是最可避免的损失。对路径的每次更改也会改变指向它的所有链接，而这些链接不受你的控制。保留有效的路径。如果路径仍然有效，请保留它，只更改迁移迫使你更改的部分。

更少的重定向，更少的错误。你保留的每个路径都是一个根本不需要重定向的链接。

保留的路径意味着旧的锚文本行继续指向有用的位置，这减少了电子表格中需要重建的内容。减少后期的重建工作。

迁移后预期

它们承担主要工作，从旧 URL 到新 URL 的 301 重定向让旧链接继续生效。每个旧 URL 保持一个重定向，中间没有链，是保持每个链接价值完整的最简单方法。重定向。三到四次跳转的重定向链会减慢爬虫速度，最好进行简化。

URL 移动时锚文本不会改变，因为文本位于链接页面上。改变的是目标数量：你的 top-pages 表格将显示旧主机的权重逐渐下降，而新主机的权重在几次月度更新后逐渐上升。目标转移是缓慢的。

一个常见的意外是过早删除旧平台。不要这样做。Squarespace、Wix 和类似的主机通常保留重定向规则，因此取消计划可能会删除这些规则，链接随后将指向死胡同，直到你在其他地方重建规则。

Hreflang 和 canonical 标签也值得关注。不匹配很常见。例如，在从 CRA 迁移到 Next.js 后，网站通常会最终出现 canonical 标签与其 hreflang 集不一致的情况，导致链接分散在页面的两个版本中。

如果迁移后数字不一致，在假设链接丢失之前，请检查故障排除表。仅月度更新就解释了大多数差距。差距通常是由于时间造成的。

预计第一次干净的比较将在上线后约两个月度更新时进行，并在电子表格中记录每次更新的日期，以免将平稳的月份误认为是停滞的。给它时间。如果需要中间读数，Ahrefs 或 Semrush 可以通过更新的爬虫来填补差距。

注意无上线通知的迁移

上线日有一个清单，但几个问题会在之后悄然出现。它们在行和索引中显示，远在团队转向其他工作之后。它们很容易被忽视。

随预发构建一起传播的 noindex

预发副本可能将其设置带入生产站点。在第一次抓取时检查 robots meta 标签和任何 noindex 标头，并对每个分类的页面进行抽样，而不仅仅是首页。对每个分类进行抽样。

模板最先出错。如果整个分类在上线后从索引中消失，请先查看其模板，然后再查看其内容。

截图也有帮助。保留预发构建的 robots 设置副本。当某些内容从索引中消失时，比较两组设置只需几分钟，而不是一个下午。

被索引的片段链接

跳转链接（如目录锚点）可能作为单独的 URL 出现在搜索结果中。搜索引擎通常会将这些折叠到主页面，但当它们不折叠时，相同的内容可能会出现在多个地址下。它们将信号从主页面分散，并且在覆盖率报告中可能看起来像重复页面。Hash URL 会悄然增加。

一个版本，一个地址。指向一个地址的 canonical 标签而站点地图列出另一个地址，会发送混合信号，报告将显示不匹配。为每个页面设置一个 canonical 版本，并确认站点地图列出相同的版本。

上线后检查覆盖率报告，查找包含 hash 的 URL，因为这些 URL 会悄然增加。Hash 是罪魁祸首。

子域名变为主域名

将网站从预发子域名移动主域名会带来自身的重复，因为两个版本都可以同时访问。在上线前决定哪个主机是 canonical。尽早选择主机。

一个主机，无处不在。当一个主机在一个地方改变而在另一个地方没有改变时，旧版本可能会在无人注意的情况下继续收集链接数月。然后保持站点地图、canonical 标签和任何 hreflang 集指向该主机。

看似消失的 do-follow 链接

重新设计后，工具中的 do-follow 行可能会急剧下降，最初的猜测是链接消失了。在接受该猜测之前，将旧的顶级页面与新的顶级页面进行比较，然后检查每个旧地址现在是否正确重定向。在恐慌之前进行检查。

首先修复那个。链接仍然存在于链接页面上，但指向死地址的情况是首先要修复的。

尽早设定日期。为团队设定固定的比较日期，这样没有人会每天重新抓取并读取噪音作为新闻。

与开发人员合作完成迁移

大部分重定向工作落在开发人员身上，监控落在阅读电子表格的人身上。将分工写成一张短表，每个单元格一个名字，通常足以防止两个人假设同一项任务。在上线前在纸上划分这些角色，这样没有人会假设另一个人正在监控。角色需要名字。

给开发人员地图，而不是任务列表

任务列表告诉开发人员要做什么，而地图显示旧地址指向哪里。发送带有状态码和每行原因的一对一表格，以便边缘情况得到决策而不是猜测。决策优于猜测。

测试计划优先。要求一个简短的测试计划，从顶级页面文件中的旧地址开始。

同意谁阅读月度文件

第一次干净的比较将在上线后约两次更新时进行，文件将需要读者。上线后的第一次读取通常噪音很大，知道这一点的读者会避免对单个异常月份做出反应。指定这个人，他们打开文件的日期，以及结果所在的电子表格。必须有人负责。

日期解决问题。在每个文件旁边记录更新日期，将关于索引停滞的担忧变成关于日历的简单事实。除非有人写下更新日期，否则平稳的月份很容易被误读为停滞的月份。

要求那个人每次更新写一行，即使没有变化，以便文件保持连续记录。每次一行。

在上线前规划回滚

如果新主机破坏了关键路径，团队需要一种预先测试的回退方式。写下步骤，包括谁可以切换开关以及重定向在撤销时的行为。在上线前进行演练。

写下回滚方案。仅存在于一个人头脑中的回滚不是计划。