网站迁移计划：阶段、重定向和上线检查

根据 Search Engine Journal 引述、并在 Veza Digital 网站品牌重塑指南^[1] 中转述的一项 2025 年研究，892 次域名迁移 的平均网站需要 523 天才能恢复到先前估计的自然流量水平。这说明迁移应被视为对你已获得流量的保护，而不仅仅是一次成功部署。

网站迁移计划需要涵盖重定向文件上线之后会发生什么。搜索引擎必须能够发现这些变化，访客仍需顺利完成他们的任务，而在上线团队离开后，旧 URL 仍需要有人负责。

本指南即项目计划。有关详细测试顺序，请参阅我们的 网站迁移测试指南；若专门涉及域名更改，请参阅 SEO 域名更改。

迁移阶段、负责人和输出一览#

请围绕验收关卡来安排时间表，而不是围绕设计团队偏好的发布日期。以下内容是示例项目时间表，并非通用的前置时间要求。

迁移阶段、时间安排、输出和负责人

在日期前安排依赖关系#

SEO 负责人在工程编写生产规则之前批准目标位置。重定向必须在站点地图切换之前通过预发布验证，体验测试也必须在团队确认切换前完成。

对于内容稳定的小型宣传网站，审计和映射可以同时进行。这可以节省交接时间，但并不能成为跳过任务测试的理由：一个损坏的咨询表单足以让原本整洁的迁移在商业上失去意义。

如果表格列出了共享责任，请指定一位负责的负责人并记录支持性的审阅者。在审计开始之前就做好这件事，包括谁可以延迟上线以及谁可以授权回滚。否则，未解决的决定往往会在部署窗口关闭时才落到工程团队手上。

审计旧网站并建立基线#

首先使用 Screaming Frog 或 Sitebulb 抓取上线网站。再辅以 CMS 导出、XML 站点地图、分析落地页和服务器日志，因为爬虫不会通过内部链接发现孤立页面。

不要假设主机名配置是不言自明的。根据 HTTP Archive 的技术报告^[2]，在桌面样本中，www 的使用率从 2019 年的 48.64% 下降到 2022 年的 41.01%。你自己的主机行为需要明确测试，而不是基于惯例做决定。

生成可审计的导出文件#

为每个导出文件定义明确的架构，以便其他团队成员能够重现基准数据。

• crawl-export.csv： 包括 URL、状态码、规范目标、可索引性、标题、模板和内部链接数量。将原始 URL 字符串与任何规范化后的匹配键一并保留。
• gsc-landing-pages-12m.csv： 导出可用的年度 Search Console 历史数据，包含落地页、日期、点击量、展示量和属性。确保各导出文件之间的筛选条件保持一致。
• backlinks-by-url.csv： 使用 Ahrefs、Semrush 或其他反向链接工具记录目标 URL、引用域名数量和重要的链接页面。
• host-check.csv： 为安全和不安全请求记录请求的 URL、重定向路径、最终主机名和规范标签，以及主机名变体、大小写差异和尾随斜杠行为。

外部审查有助于区分现有的可见性问题与迁移风险。Baikou 关于审核你的网站搜索可见性^[3]的资源，在决定哪些旧页面值得进一步调查时很有参考价值。

冻结一个可用的参考基线#

创建 baseline-metrics.csv，其中包含已收录页面数量、抓取统计数据、按模板划分的 Core Web Vitals，以及按页面类型划分的转化事件。请包含测量日期和采集方法，这样就不会有人把实际表现与无关的实验室测试进行比较。

为重要模板附加自动化无障碍结果和仅键盘操作的任务发现。记录访客是否能够打开导航、提交表单、从错误中恢复并完成身份验证，而不仅仅是保存一个审计分数。

将导出内容存放在带日期的共享文件夹中，并授予每位所有者读取权限。审计结束后，保留该快照；更正内容应放入带有变更说明的新日期版本中。

映射所有 URL 并编写重定向规则#

按有条不紊的顺序处理清单：

1. 对旧 URL 进行分类。 结合响应状态、流量、反向链接和内容价值。
2. 选择其目标地址。 选择最接近、且能满足相同访客意图的页面。
3. 分配响应。 区分永久迁移、临时路由和真正的移除。
4. 测试规则行为。 检查路径、参数、资源、主机名规范化和规则优先级。

先看相关性，再看便利性#

一个断开的页面如果拥有有价值的引荐域名，就需要调查。一个内容很少、没有实际价值的归档页面，可能并不值得替换。不能仅凭当前响应代码做出这两种决定。

整合需要编辑批准。如果多篇文章合并为一个主题中心，内容负责人必须确认该中心能够回答这些文章所涉及的问题。一个宽泛的分类页面并不自动等同于目标页面。

按旧版 URL 情况重定向操作和状态码

使用永久重定向与临时重定向行为，在实施前先明确意图。临时路由需要确定到期时间，而不仅仅是不同的响应代码。

可重复执行的一跳检查#

上表中的每一行都应在一次跳转内结束。2026年10月27日（约 UTC 01:20），我们从一台云服务器使用 curl 请求了 RedirHub 自身首页的四个变体，且未跟随重定向。每个会重定向的变体都在一次跳转中到达了规范的首页：

在你上线之前，运行 curl -sS -o /dev/null -w "%{http_code} %{redirect_url}" 对你自己主机的每个变体逐一测试，并修复任何会在第二次重定向前才返回的情况。上面的 301 和 308 组合没问题：两者都是永久重定向，选择哪一个只在请求方法必须被保留时才有区别。

编写明确的例外#

保留活动归因和功能性查询参数，但不要盲目保留过时的会话标识符或会破坏目标页面的参数。针对实际应用测试编码字符、重复参数和深层路径。

包括可下载文件和链接图片。对于电商项目，Grumspot 的Shopify 迁移重定向最佳实践^[4]为审查规则及其与店面行为的配合提供了特定平台的背景。

Patrick Stox 的迁移检查清单^[5]建议直接的永久映射，包括资产，并将重定向链控制在大约三次跳转或更少。应优先直接解析到最终目标，而不是叠加主机名重定向、协议重定向和路径重写。

将已批准的映射保存为带版本管理的文件，包含旧 URL、目标地址、预期响应、原因、负责人和审核人。具体映射应优先于宽泛规则，并且当有人更改任一项时都需要审核。Migration Redirect Mapper 可帮助整理旧 URL 与新 URL 的对应关系。

为两个站点设置 Search Console#

在切换前准备好报告访问权限。SEO 负责人需要分别检查旧属性和新属性；合并仪表板可能会把某个疲软的旧版部分隐藏在其他地方的增长之后。

准备访问权限和报告#

• 验证所有权：使用由组织控制的持久验证，而不是即将离职的承包商账户。将带来流量的子域名纳入监控范围。
• 匹配属性范围：域名属性包括主机名和协议变体，而 URL 前缀属性的边界更窄。确保比较覆盖等效的 URL 集。
• 准备站点地图：根据预期的规范化目标生成站点地图，并在发布前进行验证。在这些目标及其重定向在生产环境中正常工作之前，不要提交。
• 归档报告：将效果和索引导出文件保存到审计文件夹中，并记录筛选条件和属性名称。
• 分配审查人员：为每个属性指定一名负责人和一名备份人员，并在稳定期安排定期审查会议。

谨慎处理域名迁移#

对于符合条件的域名迁移，请在旧属性上准备更改地址工作流，并在重定向生效且检查通过后提交。不要将其用作 URL 映射的替代，也不要用于它不支持的更改。

在旧网址仍与监控相关时，保持旧属性已验证。过早移除访问权限会让调查持续曝光、遗漏网址和意外抓取行为变得更困难。

也要保持分析连续性。确认事件名称、同意行为和跨域设置，以免跟踪变更伪装成流量或转化损失。

对于同域迁移，即域名保持不变但其后的平台发生变化，集成模式允许新平台（Cloudflare Workers、Vercel 上的 Next.js 或 Caddy）无需 DNS 变更即可从 RedirHub 提供重定向映射，并报告访问者在上线后仍然命中的 404。

上线前检查与放行或拒绝放行决策#

通过首页测试并不能证明网站已准备就绪。应从有流量的页面、已链接资源、替代 URL 形式以及访问者用于完成有价值任务的模板中构建测试集。

在预发布环境中回放清单#

工程团队应在隔离环境中复现生产环境路由，包括 CDN 规则和应用重定向。使用主机覆盖或等效的受控设置来执行旧请求，而不要让预发布环境对搜索引擎可见。

回放报告需要包含请求的 URL、预期目标、实际目标、响应过程、参数结果以及最终可索引性。标记循环、无法解释的链路、意外的成功响应、目标不匹配、参数丢失以及以错误结束的重定向。

也要检查资源和发现信号：

• 应用资产：JavaScript、CSS、图片和下载文件必须在无需身份验证或路由故障的情况下加载。
• 搜索指令：检查 robots.txt、规范标签、hreflang 引用、内部链接和站点地图条目。
• 发布控制：确认生产环境不会继承测试环境密码、意外的爬取阻止或非预期的 noindex 指令。
• 衡量：使用测试提交和已完成的交易来验证转化事件，而不仅仅是页面浏览量。

我们的免费重定向检查器可以支持回放，而我们的301 重定向服务支持目标映射、所需路径和查询转发，以及上线前的访问路径测试。使用批量重定向检查工作流使结果可重复，而不是依赖浏览器中的抽查。

将响应类别分布与基线进行比较，并考虑已批准的移除项。上线后，已索引页面数量、自然点击和爬虫活动会成为生产环境对比；测试环境可以验证技术就绪性，而不能证明搜索恢复。

测试人们是否能够完成#

使用仅键盘导航、屏幕阅读器和移动设备，在旧版和新版体验上运行等效任务。包括结账或潜在客户表单、身份验证、验证错误，以及在提交失败后的恢复。

正如 Niteco 的网站迁移指南^[6]中所述，《欧洲无障碍法案》已于2025 年 6 月 28 日对面向欧盟用户的适用产品和服务生效。在适用情况下，将无障碍验收视为与合规相关，并让负责的法律或无障碍专家确认项目范围。

在测试前编写任务验收标准。要求在可比条件下成功完成，且不会出现可重复的变慢；应调查时间差异，而不要将正常的参与者差异视为缺陷。

明确发布决策#

迁移负责人应根据具体证据收集签字确认：

• 清单与映射： 清单是最新的，目标决策已获批准，发布引用的是经过审阅的映射版本。
• 技术验收： 高价值 URL 上不再存在无法解释的路由故障。
• 体验验收： 关键任务不存在未解决的无障碍或功能回归问题。
• 恢复准备： 备份可以恢复，回滚已演练，交易对账有明确负责人。
• 运营覆盖： 每个阶段都有负责人员和升级联系人。

高价值项目出现故障会推迟上线。外观问题可以进入有记录的修复队列，但失效的结账、受阻的抓取和无法访问的表单都不是外观问题。

按顺序执行上线日流程#

使用运行手册，并为每项操作安排操作者、验证者和记录结果。选择一个低流量窗口，确保诊断所需的人员都可到位，而不只是流量图上最安静的时段。凌晨 3 点若无人能够排障，风险会比在团队全员在线的中等时段发布更高。

执行切换#

1. 冻结变更。在约定的切换前间隔内，停止两个系统上的内容发布和 URL 编辑。记录必要的例外情况，并在继续之前重新生成受影响的映射测试。
2. 验证发布工件。使用校验和或版本标识，将重定向配置与已批准的映射进行比对。熟悉的文件名并不能证明工程团队已经审阅过这些规则。
3. 同时部署路由和新站点。协调应用、CDN 和基础设施变更，避免访客遇到半切换环境。将仅限生产环境的访问限制和非预期的索引阻止移除，作为受控发布的一部分。
4. 对优先 URL 进行烟雾测试。检查最有价值的旧版落地页、反向链接目标和交易入口。验证直接路由、预期响应、所需参数以及可被索引的规范目标，然后开始完整清单回放。
5. 发布并提交站点地图。仅在目标地址正确解析后，发布生产站点地图。保持旧的 Search Console 资源仍可访问，并完成任何适用的迁移通知。
6. 检查每个主机名。验证旧域名和活跃子域名的 DNS 解析、证书覆盖范围和路由。在另一个端点能够可靠提供重定向之前，不要退役旧服务器。
7. 监控实时行为。工程团队监控服务器错误和重定向日志，分析团队检查传入事件，UX 团队验证关键任务。记录部署时间，以便后续调查能够区分发布影响和无关变更。
8. 应用约定的回滚规则。当关键流程失败、出现重定向循环或服务器错误高于约定的基线容忍度时，停止或回退受影响的发布。在客户遭遇故障时，避免即兴进行大范围的生产环境重写。

保持回滚可用#

明确回滚是指恢复应用文件、切换路由、恢复数据，还是以上某种组合。对于事务型网站，如果在不协调新订单或提交内容的情况下回退基础设施，可能会引发第二次事故。在上线前为对账步骤指定明确负责人，并演练完整流程，以便团队了解在负载下回退需要多长时间。

将重定向层视为回滚决策的一部分，而不是固定背景。如果新的路由规则正是故障来源，仅回滚代码会让同样损坏的重定向继续生效。Google 的网站迁移文档^[7]建议在迁移开始时就启用服务器端重定向，在新 URL 解析正常后提交站点地图，并分别监控旧的和新的 Search Console 属性。因此，部署是一个运营里程碑，而不是迁移责任结束的时点。

上线后监控与重定向治理#

为每个监控窗口都指定一名响应负责人。Siteimprove 的网页转型风险指南^[8]将持续更新的重定向清单、明确的责任分配、升级阈值以及临时规则的终止决策，视为迁移规划中的运营缺口。

上线后监控节奏

以下为建议的运行计划。请根据风险调整人员配置，但不要取消检查。

管理变更，而不仅仅是处理事件#

分析团队负责跟踪完整性和基线对比；SEO 负责搜索调查；工程负责部署和回滚；内容团队负责目标相关性和内部链接修正。使用经过记录的 重定向监控工作流，让告警能够送达负责的人。

保持清单可搜索且有版本记录，并为每次编辑指定审阅者。临时规则需要设置到期日和指定审阅者；到期后应触发决策，而不是不检查流量就自动删除。

Google 的站点迁移文档建议重定向至少保留 180 天，如果旧 URL 仍持续获得 Google 搜索流量，则保留更久。我们的建议是将永久迁移重定向无限期保留，因为外链、书签和已索引的 URL 可能会在多年后继续带来访问者。

假设某家 SaaS 公司把博客迁移到资源目录下。之后，旧新闻通讯仍然会把合格访客送到旧文章地址，因此内容负责人会保持这些映射生效，而不是为了整理清单而将其退役。

通过持续趋势来判断恢复情况，并结合季节性对比和页面级诊断。安静的上线周并不能证明成功，仅凭流量下降也无法定位问题所在。

RedirHub 提供迁移映射，支持 CSV 导入、路径和查询参数转发，以及已连接主机名的自动 HTTPS。访问 RedirHub，将你已批准的 URL 映射投入运行，并在上线后继续保持旧链接可用。