网站迁移常被压缩成一个发布按钮：把新站上线，把旧站跳转到新站，然后等待流量恢复。实际情况要复杂得多。更换域名、从 HTTP 切到 HTTPS、改变 URL 路径、调整 DNS、替换证书和迁移邮件，虽然可能在同一个项目中发生，却属于不同的系统事实。首页能打开，只能证明一个请求成功，不代表旧网址全部正确跳转、API 主机名仍然可用、搜索引擎能发现新地址，或企业邮件还在正确投递。验收的目标是把每一层的预期、观测结果和未确认事项记录下来。
先定义迁移范围和成功条件
开始测试前，先写清楚本次变更到底包含什么。是从 old.example.com 迁到 www.example.com，还是同时更换主域名、内容管理系统和 DNS？是否包含 API、登录、图片、下载文件、回调地址和邮件？Google 搜索中心建议准备现有网址到新网址的映射，并在能做到时一次只改变一项内容。对于企业项目，还应该为关键业务定义成功条件，例如登录、付款、表单、API 鉴权和邮件收发必须分别通过。没有范围边界时，团队很容易把某个页面的 200 响应误当成整个迁移完成。
- 旧域名、新域名、www 和非 www 变体
- 页面、API、登录、静态资源、下载和回调主机名
- 旧网址到最终新网址的一对一映射
- DNS、证书、邮件和搜索站点地图的负责人
- 上线时间、回滚窗口和停止旧站的条件
- 可接受的未知状态、重试次数和人工复核步骤
迁移前保存可比较的基准
迁移前先保存基准，才能在发布后解释差异。对域名记录 A、AAAA、CNAME、NS、MX、TXT 和 CAA 保存查询时间、返回值和 TTL；对主要 URL 保存状态码、最终地址、规范链接、robots 规则和页面标题；对 HTTPS 保存证书名称、有效期、SAN 和证书链。邮件域名还要保存 SPF、DKIM 选择器和 DMARC 记录。基准不需要包含所有内容，但必须覆盖真实业务使用的主机名。记录空回答、SERVFAIL、超时和权限要求，因为它们与确认不存在不是一回事。
{
"domain": "example.cn",
"checked_at": "2026-08-31T09:00:00Z",
"dns": "expected",
"redirects": "pending",
"tls": "verified",
"mail": "unchanged",
"unknowns": ["legacy-api-host"],
"decision": "hold"
}逐条检查 DNS 委派和记录
DNS 检查要分成父级委派和权威区域两个层次。先确认注册信息返回的 NS 是否是计划中的服务器，再直接向每个权威 NS 查询主要记录。常见问题包括只有一台 NS 更新、旧区域仍被委派、新区域漏掉 MX 或验证 TXT，以及 CNAME 指向了过期主机。然后从多个公开解析位置观察结果，区分缓存中的旧值、NXDOMAIN、SERVFAIL 和超时。TTL 是缓存行为的参考，不是所有用户同时刷新的一道开关。DNS 传播文章讲的是可见性变化，迁移验收则要证明每一条关键记录都符合映射和业务预期。
测试重定向链而不是只测试首页
为旧站保存的 URL 映射应该包含高流量页面、外部链接较多的页面、登录和表单入口、下载文件、图片以及 API 路径。逐条请求旧地址，记录每次跳转的状态码和 Location，确认最终地址是新页面而不是无关首页。Google 官方建议使用服务器端永久重定向，并尽量避免重定向链。即使搜索机器人能够追踪多次跳转，链条也会增加延迟，而且不同客户端的处理能力不同。测试时还要覆盖大小写、尾部斜杠、查询参数、HTTP、HTTPS、www 和非 www 组合。
重定向测试通过也不代表页面内部已经完成迁移。新页面的 canonical、站点地图、内部链接、结构化数据和多语言标注都应该指向新地址。对于已经删除且没有对应新内容的旧页面，不要把所有访问者都送到首页，可以返回合适的 404 或 410。保存失败 URL 的列表和修复责任人，比只保存一个总体通过率更有用。
同时验收 TLS、API 和邮件入口
迁移到新域名后，浏览器访问通常最先被测试，但 API 客户端、移动应用和第三方回调可能使用不同主机名。对每个主机核对证书是否包含准确的 DNS 名称、证书链是否完整、有效期是否足够，以及 HTTP 响应是否由预期的虚拟主机处理。API 的 401、403 或限流响应可能表示应用保护仍在工作，不应直接当作 DNS 失败；连接超时、证书名称不匹配和 5xx 则需要单独升级。将 TLS 事实、HTTP 事实和业务鉴权结果分开记录，故障定位会更快。
邮件记录也不能因为网站可用而跳过。迁移时检查 MX 优先级、SPF 的授权范围、DKIM 选择器和 DMARC 策略，尤其关注旧域名是否仍会接收密码重置、账单或客户回复。发送和接收测试应覆盖外部地址、转发和退信路径。不要在不清楚用途时删除 TXT 记录，也不要把邮件延迟或单一收件人的失败归因于 DNS 传播。记录实际观察到的路径和仍需邮件管理员确认的事项。
上线后监控索引和真实流量
上线当天继续观察旧站和新站的请求量、4xx 与 5xx、重定向命中、DNS 结果、证书错误和关键业务转化。Google 建议提交新站点地图，并在 Search Console 中分别检查旧、新资源；迁移后搜索表现出现短期波动并不等于失败，但持续增加的抓取错误和大量错误跳转需要处理。对于大型网站，可以先迁移一个稳定板块作为测试，但仍要把测试结果看作局部证据，而不是对全站的保证。重定向通常应保留足够长时间，同时更新自有内部链接和高价值外部链接。
如果团队要重复验收多个站点，手工浏览器检查很快会变成无法审计的过程。可以把 URL、主机名、期望状态、实际状态、证书信息、DNS 观察、检查时间和责任人放进同一份配置，再把每次差异交给人工确认。DomScan 的重定向检查器、DNS 查询、DNS 历史、SSL 检查和域名配置文件可用于建立逐项证据；批量接入前应先确认响应字段、未知状态、使用限制和重试规则。自动化应该减少漏检，不应该把不确定结果包装成通过。