网站迁移是一个术语，用于描述可能影响 SEO 的网站设置的任何重大更改，例如对域、URL、托管、平台或设计的更改。有许多不同类型的迁移，但规划和故障排除的基本步骤是相似的。迁移可能非常复杂，因为它们通常涉及许多人和移动部件。如果一切都没有按计划进行，请不要惊慌;您几乎可以修复任何出错的地方。
网站迁移准备
您需要知道发生了什么变化以及需要谁参与才能使其发生。换句话说，您需要一个计划和一个位置来跟踪所有活动部件。您需要了解所有相关人员、他们的角色、截止日期，并有一个流程来跟踪一切。项目经理和项目管理系统对此有所帮助。试图在电子邮件和 Slack 中完成这一切可能会很快失控。您还希望有一个回滚计划，以防万一出现可怕的错误。即使您只打算在极端情况下使用它，您也应该始终有办法恢复到原始状态。
您会想知道迁移的影响，因此请确保您可以访问旧站点和新站点上的 GSC 和 Analytics(如果需要查看两者，请创建组合视图)。有些更改可能需要几周甚至几个月的时间，您可能会看到变化，但其他更改可能根本看不到任何变化。例如，如果您要将一个中型站点迁移到一个新域，我预计会出现几周的变化。但是，如果您合并到现有站点中，则可能根本看不到任何流量中断。你还想做一些准备工作。我建议几个步骤：
抓取您的网站。您将使用它作为基线来检查稍后的更改。您可以为此使用站点审计。
创建一组测试页面，例如 Site Explorer 中 Top Pages 报告中的那些页面。稍后您将使用这些来检查错误。您可能希望在单独的 Site Audit 项目中继续抓取这些内容，以便您以后可以轻松地比较它们。
限制对您的登台或开发站点(如果有)的访问，以防止将其编入索引。
备份您的网站，以防万一您需要恢复它。
网站迁移执行
确切地说，网站迁移所涉及的内容取决于 URL 是否保持不变。下面我们将讨论这两种情况。
1. 当 URL 相同时
这通常是一个更直接的举措——至少在 SEO 方面——因为更少的事情需要改变。这可能仍然是一个复杂的举措，但与这些举措相关的许多任务通常更多地是基础设施/DevOps 或开发人员的工作，而不是 SEO。这些迁移可能包括：
托管(Hosting)：CDN、服务器
平台(Platform)：CMS、语言、JS框架
设计(Design)：模板、内部链接、标签
如果您使用的是临时站点或开发站点，最好在实时启动之前访问以检查问题。为此，您实际上是在寻找任何更改，包括以下内容：
规范标签(Canonical tags)。这些应该是一样的。
标题标签(Title tags)。确保这些与您拥有的相同或相似。新系统可能具有自动标记生成或某些可能与您所拥有的不同的默认值。
元描述(Meta descriptions)
标题标签(Heading tags)
指向文档语言(Hreflang)
架构(Schema)
元机器人(Meta robots)。您想确保您的页面没有被编入索引。
内容(Content)。这对于 JavaScript 系统尤其重要。默认情况下，新系统可能不会将所有内容都加载到 DOM 中，因此在某些情况下搜索引擎可能看不到某些内容。
内部链接(Internal links)。面包屑、相关帖子、页脚链接，甚至主导航等内容都可能发生了变化。
速度差异(Speed differences)
使用 Site Audit 的比较功能查看自上次抓取以来的变化。还有几个问题可能会造成更严重的问题。
如果您不小心留下了一个块，搜索引擎将无法抓取您的页面。
有时，旧的重定向不会从 .htaccess 文件或服务器配置文件中复制过来，你会丢失一些指向你网站的链接。这个很棘手，因为它更难注意到，并且经常在更换主机时发生。密切关注站点资源管理器中的最佳链接报告并过滤 404 以查看链接现已损坏的页面。
2. 当 URL 不同时
这些迁移通常会更复杂。例外是从 HTTP 迁移到 HTTPS——如今这很容易。这些迁移可能包括：
域(Domain)：更改域、合并到另一个站点、拆分站点
协议(Protocol)：HTTP > HTTPS
路径(Path)：子域/子文件夹，更改站点架构
特定于 HTTP > HTTPS
使用 upgrade-insecure-requests 的内容安全策略来修复所有混合内容问题。除了内部链接之类的内容之外，它可以快速实施并适用于所有资源，您仍然需要自行更新。
安装安全证书
301 重定向 HTTP > HTTPS
添加 HSTS 标头
我不会担心根路径上的重定向链或更新站点链接之类的事情。修复链和更新链接不会带来任何好处，因为信号会因为重定向而整合。
特定于域更改
暂时降低 TTL(值几个小时)。这将更快地刷新 DNS 缓存，并且当您进行切换时，您的更改将更快地被更多用户看到。
使用 GSC 中的地址更改工具。
检查旧域是否存在 GSC 中可能存在的任何手动操作
这里有一个给 Site Audit 用户的快速提示：如果您将项目设置中的爬网范围更改为不同的域，您的新爬网将在新域上，您将能够将其与旧域上的爬网进行比较领域。
更新内部链接和各种标签(如规范、hreflang 等)中的链接。您可以使用查找和替换插件快速为内部链接执行此操作。
设置 GSC。这可能包括传输拒绝文件、设置地理定位、URL 参数设置和上传站点地图等内容。您需要在短时间内保留带有旧 URL 的站点地图。这将有助于监控 GSC 中 URL 的索引编制。
删除旧站点和新站点上页面的所有爬行块。一切都需要爬行才能正确整合信号。
确保您要编入索引的页面未标记为 noindex。您可以为此使用站点审计。
重定向页面。您希望确保使用 301 重定向将旧页面重定向到您页面的新版本。重定向图像和 PDF 之类的内容也是一个好主意，但不要担心 JS、CSS 或字体文件之类的内容。专注于重定向搜索引擎索引的内容，不要担心其他文件类型。
您希望尽早捕获更改，因此如果您有一个开发站点或临时站点，则应在将更改推送到实时站点之前对其进行爬网以确保一切正常。请记住，如果旧站点使用 HTTPS 并且证书过期，机器人会通过，但用户将收到错误消息并且不会被重定向。有涵盖多个站点的多域证书可以帮助防止此问题。
如果您看到下降，则可能与重定向、无法抓取的内容、未编入索引的内容、内容更改或删除内容、内部链接更改或与技术 SEO 相关的更改有关。如果您正在考虑更新指向您网站的链接，您可能希望更新您控制的页面的链接，但我不会费心去更新指向您的其他网站上的链接。它们应该与 301 重定向正确合并。不值得努力改变它们。
测试和持续监控
Google Search Console 有大量数据可帮助您进行迁移。例如，您可以使用 URL 检查工具检查规范化问题。只需输入 URL，Google 就会告诉您他们选择的规范。除此之外，您可以导出 GSC 数据并在 Excel 或 Google Data Studio 中组合查看您的流量，以更好地观察迁移。您可能还想使用页面或关键字数据的组合视图来解决任何损失。
索引覆盖率报告可帮助您了解您的页面是如何编入索引的。如果您同时上传了旧站点地图文件和新站点地图文件，则可以在此处查看索引的变化并检查是否存在任何问题。通过拥有站点地图文件，您可以获得仅针对这些站点地图中的页面的特定覆盖率报告。
如果您想查看 Google 抓取活动和任何已识别问题的概览，最好查看 Google Search Console 中的抓取统计报告。此处提供了各种报告，可帮助您识别抓取行为的变化、抓取问题，并为您提供有关 Google 如何抓取您网站的更多信息。
如果您没有获得站点的基线抓取并且需要检查新旧之间的差异，请查看 archive.org 以查看他们是否有任何页面的副本。他们通常还拥有来自站点的 robots.txt 文件副本，这些副本可用于查看是否出现问题并在此过程中被意外阻止。
如果您无权访问某个网站的 Google Search Console，您仍然可以通过在 Google 中粘贴 URL 来检查规范化。通常显示的第一页将是规范的。同样，如果您无权访问 GSC，则可以在日志文件中检查与抓取相关的许多其他问题。
只是一个警告，网站：搜索运营商有时会混淆人们。如果您使用 site:，您是在询问 Google 对特定网站的了解程度。仅仅因为您在那里看到页面并不意味着它们的索引方式或迁移存在问题。我已经看到这会导致人们做一些事情，比如阻止旧站点以将页面排除在索引之外——这会导致问题。一些问题可能会在迁移结束后很久才会出现。
监控旧域以确保它得到更新，并对您重定向到该站点的任何其他域执行相同操作。如果域过期，则任何通过旧站点重定向传递的信号都可能丢失。
如果您没有摆脱旧主机并仍然保留重定向，请注意如果关闭它们会中断 - 您将丢失一些链接。您可以通过 DNS 重定向并将重定向存储在新站点上来解决此问题。
确保更新安全证书或切换到多域证书，正如我们之前讨论的那样。
写在最后
迁移网站并非易事，因此如果一切顺利，是时候庆祝一下了。但是，由于这可能不是您最后一次进行站点迁移，因此我建议您再与相关人员聚聚一次，讨论哪些地方做得好、哪些地方出了问题，以及如果必须要更改哪些地方再说一遍。