跳过内容
ArchiLinks
ArchiLinks领取 $100 免费额度

网站迁移检查清单:从 T-4 周到第 45 天

域名变更、平台迁移、主机迁移或新的 URL 方案:指向你的链接并不在乎你选了哪一种。此清单告诉你上线前需要捕获什么,以及上线后需要重新检查什么。

ArchiLinks 研究团队 ·

等距微缩建筑工地,展示三个分阶段区域,包含蓝图、机械和已完工的结构

我们的立场

大多数迁移损失源于遗漏重定向,而非重定向类型

团队往往就 301 与 302 争论数小时,然后上线时却有 3,000 个外部链接 URL 返回 404。在决定其他任何事项之前,先找出指向网站的所有反向链接,因为这份列表能告诉你风险所在。

  • 提前 4 周提取链接页面,而不是在上线前一晚。
  • 每个包含外部链接的 URL 都需要一个指向相关页面的单跳 301 重定向。
  • 保持重定向至少一年有效,因为旧链接的生命周期往往长于它们曾经指向的页面。

时间线

01

T-4 周:库存盘点

爬取旧站,导出 Search Console 性能报告,并对旧主机运行 toppages 和 refdomains。将这三个文件连同日期一起存储。

02

T-3 周:映射

优先根据链接页面构建重定向映射,其次根据流量,最后根据爬取结果。重定向映射食谱 展示了排名脚本。

03

T-2 周:在预发环境测试

将每个旧 URL 与预发环境进行比对,确保单跳、状态码为 301 且最终返回 200。若出现链式重定向或循环,则构建失败。

04

T-0:上线

在一次发布中部署重定向、新站点地图、更新后的 canonical 标签和内部链接。在 Search Console 中提交新站点地图。若是域名变更,请使用“地址更改”工具。

05

T+1 周:日志和覆盖率

检查服务器日志中 Googlebot 对旧 URL 的抓取情况,然后查看 Pages 报告中 404 或软 404 的激增情况。修复映射表,不要等待。

06

T+30 至 45 天:链接差异分析

月度更新后,提取新主机的 refdomains 并与旧文件进行对比。差异超过几个百分点的情况值得仔细检查。

迁移类型带来的变化

迁移类型重定向额外检查链接数据重点
新域名全站 301 重定向,路径级重定向(适用于路径变更场景)"更改地址"工具,旧域名至少保留 12 个月随时间推移,指向新主机的引用域名
HTTP 到 HTTPS 或 www 的变更主机级 301 重定向Canonical 标签、HSTS、混合内容差异较小;需确认两个主机均能正常解析
平台迁移,域名保持不变路径级映射分页、参数、尾部斜杠发生路径变更的高外链页面
子域名与子文件夹之间的迁移(或反向迁移)路径级映射,主机级规则Cookies、各主机的 robots.txt、分析工具链接是指向旧主机还是新主机
两个站点的合并多对一映射重复内容、Canonical 选择通过 intersect 操作查看引用域名的重叠情况

上线日检查清单

  • 旧 URL 通过单次跳转返回 301 状态码,并通过脚本而非人工进行测试。
  • 新主机在每个模板上均返回 200 状态码,并包含指向自身的 Canonical 标签。
  • 新主机的 robots.txt 未包含测试环境规则。遗留的 Disallow: / 是上线日常见的失误。
  • XML 站点地图仅列出状态码为 200、可索引且带有 Canonical 标签的 URL。
  • 内部链接、导航栏和结构化数据均指向新 URL,而非重定向后的 URL。
  • 在切换前,新主机已配置好分析工具和 Search Console 属性。
  • 基准 JSON 文件已提交,且每个文件名中包含日期。
一个已知限制

我们的链接图谱每月重建一次。在上线周创建的链接可能不会出现在上线第 30 天的数据拉取结果中。请使用 Search Console 的链接报告进行最后阶段的确认,并根据第二次刷新后的差异进行评估。相同的数据也用于上线后的内部与外部权益对比分析,而hreflang 区域域名则涵盖多国家/地区的情况。

等距金属管道连接仓库与空白虚空,象征重定向路径断裂

以 404 结尾的 301 重定向无法保留任何权重

部分团队将所有旧 URL 重定向到新主页,然后让目标页面在后期过期。重定向本身是有效的。这种做法之所以有风险,是因为每次跳转看起来在日志中都是正常的,但最终页面的响应却是 404。

假设你将商店迁移到新域名,并仅保留仍在销售的产品。承载大量外部链接的分类页面现在指向无用的内容。在停用任何内容之前,统计带有外部链接的 URL 数量。将其作为第一步。拥有链接域名的页面需要在同一主题下有一个有效的目标页面,而不是让用户感到困惑。

保持规则简洁:一次跳转,然后是最终的 200 状态。其他任何情况都是你选择造成的流失。

一次跳转 301 到有效页面所保护的价值

链接的价值取决于其指向的 URL。重定向仅在目标地址响应且仍与主题匹配时才能传递该价值。新产品目录中的相同产品可以通过此测试,而发送到首页的产品通常不能,即使它是所有人链接的页面。

每次模板更改后重新检查最终状态。在发布时有效的重定向可能在后续发布后变为 404,当有人在菜单整理期间删除分类时。

何时 410 是诚实的答案

一些旧 URL 没有链接、没有访问也没有真正的替代品。对于这些,清晰的 404 或 410 比重定向到一个不回答旧页面所回答问题页面更诚实。重定向到不相关页面通常被视为软 404,因此无法挽救任何价值。

为每组 URL 写下决定,并在旁边注明原因。已停用的教程文件夹与拥有八十个链接域名的页面文件夹会得到不同的答案,六个月后你将需要向同事解释这种差异。

检查最后一次跳转,而不仅仅是第一次

大多数重定向测试在第一个响应处停止,这是错误的停止位置。跟踪链条直到结束,然后记录跳转次数和最终状态,并将其与旧 URL 并列记录。两次跳转的链条并未断裂,但它增加了延迟,并增加了规则失败的一个更多机会。

如果脚本难以获取,电子表格和几个 curl 调用即可完成工作。API 脚本页面 有一个你可以调度的版本。

等距单株绿色幼苗独自生长在灰色空地上,象征孤立的内容

发布后的站点地图和手动请求

在迁移后几周内保持旧站点地图可访问。重新访问旧主机的爬虫仍可以在一个列表中找到这些地址,这将加快它们第一次遍历重定向的速度。

手动请求是另一种工具。仅用于最重要的少数页面,而不是逐个提交数百个 URL。没有内部链接且内容稀少的请求页面往往会再次消失,因此请求的质量取决于其背后的页面。

等待是一个有效的计划。给予抓取时间,然后根据数据进行判断。

在一段时间内保留旧站点地图的列出

在旧 URL 不再出现在抓取统计信息之前,将旧站点地图保留在 Search Console 中。然后有目的地移除它,并在迁移日志中记录日期。

不要在发布当天移除它,只是为了让属性看起来整洁。早期移除会隐藏唯一列出你仍需跟踪的每个旧 URL 的列表。

请求索引包含链接的页面

使用为跳转映射构建的相同连接,选择具有最多外部链接的二十个新 URL,并手动请求这些。努力应跟随风险,而不是网站的大小。

如果请求的页面在几周后仍然缺失,在再次请求之前查看该页面。检查其内部链接、规范标签和内容。第五次请求不会改变任何内容。

迁移后多久可以进行判断

从第二次链接抓取进行判断,而不是第一次。我们的索引大约每月刷新一次,因此第三天的抓取主要显示上个月的情况。在刷新后运行第二次抓取,并使用它查找新主机上的所有指向网站的反向链接。

页面报告和链接数据回答不同的问题。将它们并排阅读,而不是作为对同一迁移的竞争性判决。

预演站点上线前的五项检查

01

将预演站点排除在索引之外

在预演站点前放置密码或白名单。单独的 robots.txt 规则并不能阻止搜索引擎索引它们已从链接中知道的 URL。

02

检查 noindex 和规范设置

打开模板和 CMS 设置,查找 noindex 标志或指向其他 URL 的规范标签。在 WordPress 中,搜索可见性设置是人们从预演复制网站后容易忘记的。

03

替换预演 robots 文件

切换完成后获取实时 robots.txt,并将其与你打算发布的文件进行比较。到达生产环境的预演规则可能会将爬虫排除在整个主机之外。

04

对活动主机运行跳数测试

预演环境可验证地图在副本上是否有效。DNS 更改后,请在真实域名上再次运行单跳测试,因为 CDN 缓存或主机规则在真实环境中的表现可能不同。

05

保留旧主机继续响应

只要旧域名的 URL 仍有外链或访问,就应让其继续提供重定向。在日历中标记续期日期,以免有人忘记该域名的存在。

上线后持续监控,而非仅关注上线前

上线前的审计记录了运行当天的情况。大多数上线后的问题会在之后显现,例如插件更新、CDN 规则更改或模板修改了无人审核的设置。

将上线后的监控视为与已保存基线的微小差异对比。无需仪表盘,只需制定计划并建立一个按日期归档的文件文件夹即可。

每周监控应对比的内容

选择那些若发生变化会造成最大影响的检查项,并在每周的同一天执行。

  • 前 50 个被链接的旧 URL 的状态码和最终 URL
  • 主模板中的 robots.txt 和 robots meta 标签
  • 有效的 200 状态码 URL 数量与新站点地图中的数量对比
  • 首页、一个分类页和一个文章页的 canonical 标签

为何一次性审计无法发现缓慢的漂移

上线后设置会发生漂移。一个遗留的测试标志、一个重写固定链接的插件,或为修复单个页面而添加的重定向,都可能部分抵消计划的效果。上线当天进行的审计无法发现其中任何一项。

定期差异对比可以。将基线文件保存在版本控制中,并将每周的输出与之对比,以便在意外发生当天即可发现变化。

子域名、移除操作和全站域名变更

一些团队将部分内容移至子域名,并仅索引其热门页面。这种做法可行,但代价是指向较冷门页面的链接现在指向历史较少的主机,因此在削减任何内容前应先统计这些链接。

移除请求的范围比听起来更窄。Search Console 将移除操作应用于提交请求的属性,因此在子域名上提交的请求不会影响主域名。请先检查属性,然后提交,并保持两者均已验证。

仅在子域名上索引热门页面

从该部分每个 URL 的外链数量开始。那些拥有外链但流量较少的页面是“仅热门页面”规则最先隐藏的对象。保持它们可被爬取,或将每个页面重定向至其最接近的热门页面,并在规则旁注明原因。

主站指向子域名的链接决定了其页面被发现的难易程度。在决定哪些页面被隐藏之前,先列出这些链接,因为主站从未链接的页面无论如何都难以被访问。

全站域名变更,逐页处理

主机级规则可处理根路径,但域名变更还需要路径级映射。当 URL 的第一部分发生变化而 slug 保持不变时,主机切换可覆盖大部分页面,其余例外情况需单独列出。

首先从被链接的页面开始构建列表,然后将每个旧路径匹配到新路径。重定向地图制作指南 展示了如何根据外链数量对该列表进行排序。