网站迁移的成功，靠的不只是一份清单
网站迁移有许多不同类型，但规划与排障的基本步骤是相似的。迁移可能极其复杂，因为它们往往涉及许多人和许多环节。如果事情没有完全按计划进行，也不必惊慌；几乎所有出错的地方你都能修复。
网站迁移（website migration）是指对网站的域名、URL、主机、平台或设计所做的任何重大变更。
迁移有很多不同类型，但规划与排障的基本步骤是相似的。迁移可能极其复杂，因为它们往往涉及许多人和许多环节。如果一切没有按计划进行，也不必惊慌；几乎所有出错的地方你都能修复。
本指南将涵盖：
网站迁移的准备工作
你需要知道有哪些东西在变、需要哪些人参与才能完成。换句话说，你需要一份计划，以及一个用来追踪所有环节的地方。你需要了解所有参与人员、他们的角色、截止时间，并有一套流程来追踪一切。SEO 项目经理和项目管理系统能帮上忙。试图全靠邮件和 Slack 来推进，很快就会失控。
你还需要一个回滚方案，以防出现严重错误。你应当始终有办法回到原始状态，即便你只打算在极端情况下才用到它。
你会想了解一次迁移带来的影响，所以要确保你能访问新旧两个网站的 GSC 和分析工具（如有需要，可以做一个合并视图来同时查看两者）。有些变更可能要过几周甚至几个月才能看到变化，期间你可能会看到波动，而另一些则可能完全看不出任何变化。例如，如果你把一个中型网站迁移到新域名，我预计会有几周的波动。但如果你是合并进一个已有网站，则可能完全看不到流量中断。
你还需要做一些准备工作。我建议分几步走：
- 抓取你的网站。你会把它作为基准，用来在之后检查变化。你可以用 Site Audit 来做这件事。
- 创建一组测试页面，比如取自 Site Explorer 中热门页面（Top Pages）报告的那些页面。你稍后会用它们来检查错误。你或许可以先把它们放在一个单独的 Site Audit 项目中抓取，这样之后就能轻松地做对比。
- 限制对你的预发布（staging）或开发（dev）站点的访问（如果你有的话），以防止它被索引。
- 为你的网站做一份备份，以防你需要回退到它。
执行网站迁移
网站迁移具体涉及哪些工作，取决于 URL 是否保持不变。下面我们将讨论这两种情形。
当 URL 保持不变时……
这通常是一次更直接的迁移——至少在 SEO 层面如此——因为变化的东西更少。它仍可能是一次复杂的迁移，但这类迁移涉及的许多任务通常更多是基础设施/DevOps 或开发人员的工作，而不是 SEO 人员的工作。
这类迁移可能包括：
- 主机：CDN、服务器
- 平台：CMS、语言、JS 框架
- 设计：模板、内链、标签
如果你使用预发布或开发站点，最好先获得访问权限，在上线前检查问题。
需要检查什么
在这方面，你本质上是在找任何变化，包括诸如以下这些：
- 规范标签（Canonical tags）。它们应当保持一致。
- 标题标签（Title tags）。确保它们与你原有的相同或相似。新系统可能有自动标签生成功能或某些默认设置，可能与你原有的不同。
- 元描述（Meta descriptions）
- 标题标签（Heading tags）
- Hreflang
- 结构化数据（Schema）
- Meta robots。你要确保你的页面没有被设为 noindex。
- 内容。这对 JavaScript 系统尤其重要。新系统可能默认不会把所有内容都加载进 DOM，因此在某些情况下搜索引擎可能看不到部分内容。
- 内链。面包屑导航、相关文章、页脚链接，甚至主导航等都可能发生了变化。
- 速度差异
使用 Site Audit 的对比功能，查看自上次抓取以来的变化：
还有几个问题可能造成更严重的麻烦。
- 如果你不小心把某个屏蔽设置留着没关，搜索引擎就无法抓取你的页面。
- 有时旧的跳转规则没有从 .htaccess 文件或服务器配置文件中复制过来，你就会丢失一些原本指向你网站的链接。这个问题很棘手，因为它更难被发现，而且常常在更换主机时发生。留意 Site Explorer 中的按链接排序的最佳页面（Best by links）报告，并筛选 404，看看哪些页面的链接如今已变成死链。
当 URL 发生变化时……
这类迁移通常会更复杂。例外是从 HTTP 迁移到 HTTPS——这在如今相当容易。
这类迁移可能包括：
HTTP > HTTPS 专项
- 使用值为 upgrade-insecure-requests 的内容安全策略（CSP），以修复所有混合内容问题。它实施起来很快，除内链这类你仍需自己更新的资源外，对其余所有资源都有效。
- 安装安全证书
- 将 HTTP > HTTPS 做 301 重定向
- 添加 HSTS 响应头
我不会去操心根路径上的重定向链或更新指向网站的链接这类事。修复重定向链和更新链接不会带来任何好处，因为由于重定向的存在，信号会自然合并。
域名变更专项
- 暂时调低 TTL（把值设为几小时）。这会让 DNS 缓存更快刷新，当你完成切换后，你的更改会更快被更多用户看到。
- 使用 地址变更工具（change of address tool）（GSC）。
- 检查旧域名在 GSC 中是否存在任何人工处理措施（manual actions）
给 Site Audit 用户的一个小提示：如果你在项目设置中把抓取范围改到另一个域名，你的新抓取就会面向新域名，你就能把它与旧域名上的抓取做对比。
通用事项
- 更新内链和规范标签、hreflang 等各类标签中的链接。对于内链，你也许可以用查找替换插件来快速完成。
- 配置 GSC。这可能包括转移你的拒绝链接（disavow）文件、设置地域定向、URL 参数设置、以及上传站点地图。你会希望在短时期内保留一份含旧 URL 的站点地图。这有助于在 GSC 中监控 URL 的索引情况。
- 移除新旧网站上页面的任何抓取屏蔽设置。为了让信号正确合并，所有内容都需要被抓取。
- 确保你希望被索引的页面没有标记为 noindex。你可以用 Site Audit 来完成这件事。
- 重定向页面。你要确保旧页面通过 301 重定向指向页面的新版本。把图片和 PDF 之类的资源也做重定向是个好主意，但不必操心 JS、CSS 或字体文件之类的东西。重点重定向那些会被搜索引擎索引的内容，其他文件类型则不必在意。
你希望尽可能早地发现变化，所以如果你有开发或预发布站点，就应该抓取它，确保一切正常后再把更改推送到线上站点。请记住，如果旧站点使用 HTTPS 而证书过期，爬虫会被放行，但用户会收到错误信息并且不会被重定向。有覆盖多个网站的多域名证书，可以帮助避免这个问题。
如果你看到流量下滑，它很可能与重定向、某些内容无法被抓取、某些内容被设为 noindex、内容的更改或删除、内链的变化，或与某处技术 SEO 相关的变更有关。
测试与持续监控
有多种方式可以观察迁移的进展，并确保一切按应有的方式推进。
使用 Ahrefs
有几种不同的方式来查找变化。正如我之前提到的，你可以在 Site Audit 中更改抓取范围，并得到一份显示变更内容的对比。你要留意以下这类内容的变化：
- 规范标签（Canonicals）
- Hreflang。如果你更换域名，它会中断一段时间，因为页面需要一些时间才能被重新抓取并建立关联。
- 结构化数据（Schema）
- Meta robots