网站迁移 SEO 检查清单：从规划到上线的完整流程（2026）

网站迁移是 SEO 最高风险的操作之一。换域名、换 CMS、甚至只是调整 URL 结构——处理不当，搜索流量可以在一周内腰斩，而恢复往往需要数月。

这不是危言耸听。2025 年 Ahrefs 对 182 次公开可追踪的网站迁移进行回溯分析，发现超过 60% 的迁移导致自然搜索流量在首月下降 20% 以上，其中约三分之一在六个月后仍未恢复到迁移前水平。

好消息是，绝大多数流量损失都来自可预防的错误：遗漏的 301 重定向、误配置的 robots.txt、被遗忘的内链指向。这篇检查清单按迁移前、执行中、上线后三个阶段组织，目标是帮你在每个环节把该做的事情做到位。如果你对技术 SEO 的全貌还不够熟悉，建议先读那篇支柱页再回到这里。

什么算 "网站迁移"

"网站迁移"（Site Migration）在 SEO 语境中的含义比字面意思宽泛得多。它不仅仅指把服务器从 A 搬到 B，而是任何可能改变搜索引擎对现有页面索引和排名的结构性变更。

一个关键认知：风险等级取决于 URL 是否变化，以及变化的范围有多大。纯服务器搬迁（URL 不变）风险最低；域名更换 + URL 结构重组（所有 URL 都变）风险最高。如果你的迁移涉及多种类型叠加，请按最高风险等级来准备。

迁移前准备清单

迁移前的准备工作决定了 80% 的成败。这个阶段的目标是记录当前状态、规划变更路径、准备回滚方案。

1. 记录基准数据

迁移后你需要一个参照系来判断 "正常" 还是 "异常"。以下数据必须在迁移前完整记录：

把这些数据导出为本地文件或截图存档——不要依赖在线工具的历史回溯功能，迁移后部分数据可能因为属性变更而无法追溯。

2. 完整爬取现有网站

使用 Screaming Frog、Sitebulb 或类似工具对现有站点做一次完整爬取，输出：

• 所有可索引 URL 列表（状态码 200，canonical 指向自身）
• 每个 URL 的元数据：title、meta description、H1、canonical、hreflang
• 内链关系图：哪些页面链向哪些页面
• 现有重定向链：已经存在的 301/302 跳转
• 结构化数据：每个页面已部署的 Schema Markup 类型

这份爬取报告是制作 URL 映射表的原材料，也是迁移后验证的对照基准。

3. 制作 URL 映射表

URL 映射表是迁移的核心文档。格式很简单：

制作映射表的几条原则：

• 逐条映射，不要批量通配：/blog/* → /articles/* 的通配规则看似省事，但路径结构不一致时会产生大量 404
• 优先一对一映射：每个旧 URL 对应一个内容最相关的新 URL
• 没有对应页的旧 URL：301 到最相关的父级页或同主题页面，而非统一指向首页
• 真正需要删除的页面：用 410（Gone）而非 404，明确告诉搜索引擎这是有意为之
• 覆盖率检查：映射表中的旧 URL 数量应与爬取报告中的可索引 URL 数量一致

4. 准备 301 重定向规则

根据映射表编写重定向规则。具体实现方式取决于你的服务器环境：

无论哪种方式，在迁移前必须在测试环境验证每条重定向规则。常见错误包括：重定向循环（A → B → A）、重定向链过长（A → B → C → D，Google 最多跟踪 10 跳但建议不超过 3 跳）、以及遗漏 query string 处理。

5. 准备 robots.txt 和 Sitemap

这两个文件需要提前准备好，迁移上线后立即部署：

• 新站 robots.txt：确保不会意外屏蔽 Googlebot 或其他搜索引擎爬虫。最常见的灾难是测试环境的 Disallow: / 被原样搬到了生产环境
• 新站 Sitemap：包含所有新 URL，格式正确，lastmod 日期更新为迁移日期
• 旧站 Sitemap（可选但推荐）：保留旧 URL 的 sitemap 并继续提交，帮助搜索引擎发现和跟踪 301 重定向

6. 确认搜索引擎验证

如果域名或协议发生变化，需要提前做好搜索引擎工具的验证准备：

• Google Search Console：为新域名 / 新协议添加并验证新属性。迁移完成后使用 "地址变更" 工具通知 Google
• Bing Webmaster Tools：同样需要添加新属性并验证
• Google Analytics：确认追踪代码中的域名设置已更新，避免迁移后数据丢失

迁移执行清单

迁移日到了。这个阶段的核心原则：按计划执行，逐步验证，不在生产环境即兴发挥。

1. 部署 301 重定向

按照映射表部署所有 301 重定向规则。部署后立即执行以下验证：

• 抽样测试：从映射表中随机抽取 50-100 个旧 URL，用 curl -I 或 HTTP 状态码检查工具验证是否正确返回 301 和目标地址
• 重定向链检测：确认没有 A → B → C 的链式跳转
• HTTPS 一致性：如果涉及 HTTPS 迁移，确认 HTTP 版本和带 / 不带 www 的版本都正确重定向到最终目标
• 特殊字符处理：包含中文、空格、特殊字符的 URL 是否被正确编码和重定向

2. 批量更新内链

内链是迁移中最容易被忽视的环节。新站上线后，所有内链应该直接指向新 URL，而非依赖 301 重定向中转。原因有两个：

• 性能：每次 301 跳转增加约 100-500ms 的延迟
• 链接权重传递：虽然 Google 官方表示 301 不损失 PageRank，但实际观察中，大量内链经过 301 中转的站点排名恢复速度明显慢于直接更新内链的站点

批量更新内链的实操路径：

• 数据库层面：对 CMS 数据库中的内容字段做批量替换（替换前务必备份）
• 模板层面：检查导航、侧边栏、页脚等全局模板中的链接
• Sitemap 和 Canonical：确认这些标签中的 URL 也已更新

3. 迁移结构化数据

如果旧站部署了 Schema Markup（Article、Product、FAQ、BreadcrumbList 等），迁移时需要确认：

• 结构化数据中的 URL 引用（如 @id、url、mainEntityOfPage）已更新为新地址
• 面包屑导航的层级和路径与新 URL 结构一致
• Organization schema 中的域名和 logo URL 已更新
• 使用 Google 的 Rich Results Test 对关键页面逐一验证

4. 提交 Sitemap

上线后立即执行：

• 在新站的 Google Search Console 属性中提交新 Sitemap
• 如果是域名变更，在旧属性中也提交包含旧 URL 的 Sitemap（帮助 Google 发现 301 映射关系）
• 如果是域名变更，在旧属性中使用 "地址变更" 工具
• Ping Sitemap：https://www.google.com/ping?sitemap=https://newdomain.com/sitemap.xml

5. 验证 robots.txt

上线后第一时间检查生产环境的 robots.txt：

• 直接访问 https://newdomain.com/robots.txt 确认内容正确
• 确认没有 Disallow: / 这样的全站屏蔽指令
• 确认 Sitemap 声明指向新地址
• 在 GSC 中使用 robots.txt 测试工具验证关键 URL 的可抓取性

6. 检查 HTTPS 配置

如果迁移涉及 HTTPS：

• SSL 证书是否覆盖所有子域名（包括 www 和非 www）
• 所有 HTTP 请求是否正确 301 到 HTTPS
• 检查混合内容（Mixed Content）：页面通过 HTTPS 加载，但引用了 HTTP 的图片、CSS、JS
• HSTS（HTTP Strict Transport Security）头是否已配置

迁移后监控清单

迁移完成不等于结束。接下来的 2-4 周是关键观察期，需要密集监控以下指标。

1. GSC 抓取错误监控（第 1-7 天）

迁移后 Googlebot 会大量重新抓取，这是发现问题的黄金窗口：

• 每日检查 GSC "页面" 报告：关注 "未找到 (404)"、"服务器错误 (5xx)"、"被 robots.txt 屏蔽" 的数量变化
• 抓取统计信息：在 GSC 的 "设置 → 抓取统计信息" 中查看抓取请求数是否恢复正常
• URL 检查工具：对核心页面逐一提交实时检查，确认 Google 能正常抓取和渲染

如果 404 错误数量在迁移后急剧上升，立即对照 URL 映射表排查遗漏的重定向。

2. 排名和流量追踪（第 1-30 天）

监控工具组合：

• GA4 的自然搜索流量报告（与迁移前基准对比）
• GSC 的搜索效果报告（按页面和查询维度分析）
• Ahrefs / Semrush 的排名跟踪（关注迁移前标记的 Top 50 页面）

3. 404 页面修复（持续）

404 错误会在迁移后持续出现——外部链接、社交媒体分享、书签都可能指向旧 URL。处理策略：

• 高优先级：有外链指向的 404 页面 → 立即添加 301 重定向到对应新页面
• 中优先级：有流量但无外链的 404 → 添加 301 重定向
• 低优先级：无流量无外链的 404 → 可暂不处理，但建议最终也添加重定向或返回 410

使用 Ahrefs 的 Broken Backlinks 报告或 GSC 的外部链接报告来识别高优先级的 404。

4. 外链更新通知

虽然 301 重定向会传递链接权重，但直接链接始终优于重定向链接。对于高价值外链来源：

• 联系外链来源网站，请求将链接更新为新 URL
• 更新社交媒体档案（LinkedIn、Twitter/X、Facebook 等）中的链接
• 更新 Google Business Profile、行业目录中的网址
• 更新邮件签名、名片等线下物料中的网址

5. 索引状态追踪（第 7-90 天）

在 GSC 中持续观察：

• 新 URL 被索引的速度和数量
• 旧 URL 从索引中消失的速度
• 搜索结果中显示的是新 URL 还是旧 URL（使用 site:newdomain.com 和 site:olddomain.com 检查）
• canonical 标签是否被 Google 正确识别

常见迁移灾难案例

以下是实际项目中反复出现的迁移失误。每一条都曾造成过数月的流量损失。

灾难 1：没做 301 重定向，或 301 不完整

这是最常见也最致命的错误。表现形式包括：

• 完全没做 301：上新站、关旧站，所有外链直接 404。Google 需要重新从零开始理解新站，原有排名全部丢失
• 只做了首页 301：所有旧的子页面都 301 到新站首页。Google 会将其视为 "软 404"——几周后这些重定向会被忽略
• 用了 302 而非 301：302 是临时重定向，Google 可能继续保留旧 URL 在索引中，链接权重传递不确定

补救措施：如果发现时间在迁移后 2 周内，立即补上正确的 301 映射，大部分排名可在 4-8 周内恢复。超过 3 个月才补救的，恢复时间可能长达 6-12 个月。

灾难 2：robots.txt 误封新站

最典型的场景：新站在测试环境开发时，robots.txt 中设置了 Disallow: / 以防止被搜索引擎提前收录。上线时忘记移除这条规则，导致整个新站对所有爬虫关闭。

更隐蔽的变体：

• Disallow 规则屏蔽了 CSS/JS 文件，导致 Googlebot 无法正常渲染页面
• X-Robots-Tag 在 CDN 层被配置为 noindex，但团队只检查了 HTML 中的 meta robots
• 测试环境的 meta robots noindex 标签残留在模板中

补救措施：发现后立即修复 robots.txt 并在 GSC 中请求重新抓取。通常 24-72 小时内 Google 会重新读取 robots.txt。但已经被 deindex 的页面可能需要数周才能重新回到搜索结果中。

灾难 3：HTTPS 混合内容

HTTPS 迁移后，页面本身通过 HTTPS 加载，但页面中嵌入的图片、CSS、JavaScript 仍然引用 HTTP 地址。这会导致：

• 浏览器显示 "不安全" 警告，用户信任度下降
• 部分资源被浏览器阻止加载，页面显示异常
• Google 的页面体验评估受到负面影响

排查方法：使用 Chrome DevTools 的 Console 面板，Mixed Content 警告会清楚列出所有不安全的资源引用。批量排查可用 Screaming Frog 抓取新站，筛选所有 HTTP 协议的内部资源引用。

灾难 4：URL 参数变化导致重复内容

CMS 迁移后，新系统对 URL 参数的处理方式可能与旧系统不同。典型问题：

• 旧站的筛选参数 ?color=red 在新站变成了 /filter/color-red/，两个版本同时存在
• 新 CMS 自动给分页、排序、会话 ID 生成独立 URL
• Trailing slash 处理不一致：/about 和 /about/ 返回相同内容但被视为不同 URL

预防方法：在迁移前用 Screaming Frog 爬取新站测试环境，对比去重后的 URL 数量与预期是否一致。对参数页面配置正确的 canonical 标签。

灾难 5：忽略国际化配置

多语言网站迁移时，hreflang 标签的更新经常被遗忘：

• hreflang 标签中的 URL 仍然指向旧域名
• 语言版本之间的映射关系因 URL 结构变化而断裂
• CDN 或服务器的地理定向规则未同步更新

迁移时间线与检查项汇总

将所有检查项按时间线整理：

可下载的检查清单

为了方便在实际项目中使用，以下是精简版检查清单，可复制到你的项目管理工具中：

迁移前

• ☐ 导出 GSC 近 90 天搜索效果数据
• ☐ 导出 GA4 近 90 天自然搜索流量和着陆页数据
• ☐ 导出 Ahrefs/Semrush 关键词排名和外链数据
• ☐ 用爬虫工具完整爬取现有站点并导出报告
• ☐ 制作逐条 URL 映射表（覆盖所有可索引页面）
• ☐ 根据映射表编写 301 重定向规则
• ☐ 在测试环境验证所有重定向规则
• ☐ 准备新站 robots.txt（确认无 Disallow: /）
• ☐ 准备新站 Sitemap（包含所有新 URL）
• ☐ 为新域名 / 协议添加并验证 GSC 属性
• ☐ 确认 GA 追踪代码已更新
• ☐ 准备回滚方案

迁移执行日

• ☐ 部署 301 重定向规则
• ☐ 抽样 50-100 个 URL 验证重定向正确性
• ☐ 检查无重定向循环和过长重定向链
• ☐ 批量更新数据库和模板中的内链
• ☐ 更新结构化数据中的 URL 引用
• ☐ 部署新站 robots.txt 并验证
• ☐ 提交新站 Sitemap 到 GSC
• ☐ 提交旧站 Sitemap（保留旧 URL 以便 Google 发现 301）
• ☐ 使用 GSC 地址变更工具（域名变更时）
• ☐ 检查 HTTPS 混合内容
• ☐ 验证 canonical 标签指向正确

迁移后监控

• ☐ 每日检查 GSC 抓取错误（持续 7 天）
• ☐ 每日检查 GSC 抓取统计信息
• ☐ 每周对比流量和排名与迁移前基准
• ☐ 修复所有有外链指向的 404 页面
• ☐ 联系高价值外链来源更新链接
• ☐ 更新社交媒体和业务目录中的网址
• ☐ 确认搜索结果中全部显示新 URL（30-90 天）

翼果洞察

在我参与过的数十次网站迁移中，流量损失最小的项目有一个共同点：它们在迁移前花了迁移周期 70% 以上的时间做准备。URL 映射表做得越细致，执行日越无聊——而 "无聊" 恰恰是迁移日最理想的状态。

另一个容易被忽视的点是时机选择。避开业务旺季（如电商的黑五、双十一期间）和 Google 已知的核心更新发布窗口。如果迁移期间恰好遇到算法更新，你将无法区分流量变化是迁移导致的还是算法调整导致的。

最后，关于 301 重定向的保留时间：至少保持一年。Google 的 John Mueller 在 2024 年重申，移除 301 后 Google 可能会重新将旧 URL 视为独立页面。对于高权重页面的重定向，建议永久保留。