SEO 迁移检查清单：上线前、上线时与上线后

用网站迁移 SEO 清单安排 URL 映射、负责人、重定向测试与上线后复盘。附可编辑工作模板，适用于改版、换域名和 CMS 迁移。

SEO 迁移检查清单用于帮助团队在网站变更时，衔接有价值的页面、搜索信号与客户访问流程。它需要说明检查什么、由谁负责、怎样算通过，以及失败后怎么处理。

本文适用于换域名、更换 CMS、网站改版和 URL 重组，可配合可编辑迁移工作模板使用。下方示例均为虚构的规划演示，不是客户成果，也不代表承诺迁移时流量完全不变。

确定迁移范围与负责人

列任务前，先用一段话说明：改什么、为什么改、涉及哪些网站和语言、计划何时上线，以及哪些决定已经确定。保留 URL 的视觉改版，与同时更换域名和 CMS，需要的工作不同。

例如：“把公开的营销网站迁入新 CMS，保留域名、费用页和产品页 URL，重新组织指南；应用和支付系统继续使用现有基础设施。”这样的描述足够具体，可以据此检查任务是否遗漏或越界。

明确三类责任：SEO 负责人确定要求与验证方式，开发负责人实施并准备技术恢复措施，发布负责人决定是否上线。一人可以兼任，但每个决定都要有归属。

条件允许时，把无关的变更分开推进。如果只是换主机，公开 URL 不变，重点应该是基础设施检查，而不是额外编一份重定向计划。确认团队能访问测试环境，也有可用的恢复流程，再确定最终发布窗口。

上线前记录基线

趁旧站仍可访问，保留带日期的记录，包括网站抓取、CMS 导出、可取得的 Search Console 和统计数据，以及销售或产品团队认为关键的页面。

按页面组整理证据。产品、费用、指南、语言版本与下载文件各有任务。全站流量总数无法说明迁移影响了哪一类任务。

每个重点页面记录：

• 当前 URL、页面任务、标题、主要内容和预期下一步。
• 可取得的搜索查询、点击、展示与线索，注明日期和指标定义。
• 需要保持可访问的链接与资源，包括有用的下载文件。
• 计划变更、实施负责人，以及确认完成所需的证据。

选择可比较的时间段，标注推广活动或季节变化。小站数据少时，逐日百分比可能有误导性；保留实际数量，并标出上线日期。没有转化历史，不要记成零线索。

如果尚不清楚旧站有哪些问题可能被带入新站，可以先用技术 SEO 审计明确需要处理的事项。

建立 URL 映射

给旧 URL 分别确定保留、移动、合并或下线。目标页要能回答访客原来的需求，不能因为有一个页面存在，就把它当作合适替代。

下表使用虚构 SaaS 网站的路径演示。若涉及换域名，工作文件中应写完整的新旧地址。

合并后的指南应确实包含原日历指南中的有用内容。过期活动没有相关替代时，不应为了让报表少一个错误，就把访客导向无关首页。

永久迁移可使用 Google 支持的服务端永久重定向，包括 301 和 308。要检查旧地址到最终页面的实际响应，不能仅确认 CMS 中写了一条规则。参见 Google 重定向文档。

增加决策理由、内容核查、实施者、测试结果和复测日期。预期响应与实际观察分别记录：表里写了“301 → 200”，在测试前仍只是计划。

发布前测试新网站

在测试环境检查代表性模板，以及事先约定的所有重点路径。首页可用，不能证明产品页、语言导航或预约表单也正常。

先比较内容是否满足原来的任务：主题、主要正文、有用图片和客户下一步是否保留。再核对标题、索引指令、规范 URL、适用的语言标注、结构化数据与内链是否符合计划。

保留测试环境的访问保护，同时单独记录正式站需要移除哪些开发限制。不能把“所有环境都移除保护”当成正确的上线配置。

在桌面与手机实际走一遍访问流程：进入产品页，点击正文内链，在阅读中段切换语言，通过浏览器返回，再打开联系入口。如果改版后的按钮进入了错误语言或丢失阅读位置，单看 HTTP 响应无法发现问题。

阻断问题演示：新版费用页返回 200，却继承了 X-Robots-Tag: noindex 响应头。开发修正正式环境规则，SEO 复查响应与页面；发布负责人在约定的阻断问题通过前暂停上线。这是决策记录示例，并非客户网站的实测结果。

上线当天的检查清单

部署后重新检查公开网站。测试环境的结果是准备依据，不能证明正式站实际发布了什么。

涉及域名或子域名迁移时，判断是否适用 Search Console 的地址更改工具，并确认相关资源权限。站内路径变化、HTTP 转 HTTPS，以及同域名的 www 与非 www 切换，不使用该工具。操作前核对当前适用条件与设置说明。

更新站点地图，使其对应计划公开的新 URL。Google 的网站迁移指南建议重定向至少保留一年。即使项目支持周期结束，也要明确旧域名与重定向基础设施的维护负责人。

上线后按页面组复盘

在迁移计划中约定监测周期与检查节点。即时技术复查、初步抓取后的跟进、稍后的效果复盘，回答的是不同问题；时间取决于网站规模、数据量与变更范围。

每个节点分开记录三类结果：

1. 交付：计划页面与修复是否已发布，检查是否通过。
2. 搜索：哪些页面组和查询的展示、点击发生变化。
3. 业务：客户是否还能联系，实际询盘发生了什么变化。

Google 提到处理迁移时排名可能波动。这不能解释所有下降，也不能成为忽视页面故障的理由。按受影响页面组对照基线，并持续保留带日期的问题记录。技术验收通过和流量恢复，是两种不同结果。

迁移后流量下降如何排查

先确定下降出现在哪里。如果统计系统中的访问减少，而 Search Console 点击变化不大，应先调查统计和报表差异，不能马上推断排名大幅下跌。比较对应日期，也要考虑报告延迟。

如果两边都下降，再检查受影响页面组：有用页面是否消失，核心内容是否丢失，是否跳到了错误目标，或者难以访问？问题是否集中在某个模板、市场或设备？把假设对应到具体 URL 检查。

如果新 URL 尚未进入索引，可以参考已发现但未编入索引的排查指南整理证据，不默认再次提交 URL 就能解决根本问题。

恢复动作要有理由、负责人和复测。不要下意识撤回整个迁移；开发与项目负责人需要先判断哪些变更可以安全回退，以及对客户和数据有什么影响。

约定支持与交接

可用的交接包包含最终映射、已完成检查、未解决事项、基线比较与后续维护负责人。约定支持结束日期，以及新增发布改变范围时如何处理。

需要协助组织这些工作时，可以查看 Meridian 网站迁移 SEO 服务，了解交付结构、团队责任与项目评估所需资料。初步沟通时准备网站、迁移类型、当前阶段和计划上线日期。

也可以下载可编辑工作模板，直接与现有团队使用。模板保留负责人和结果的空白字段，不会预先把任何检查标为完成。