三年前，我接手了一个已经上线的迁移项目。没有演示环境。没有重定向映射。一个拥有 22,000 页的电商目录，有人刚把它指向新域名就宣布"完成"了。在六周内，自然流量下降了 74%。客户打电话时语气有点慌张，我花了将近四个月才把这个烂摊子收拾好。
关键要点：网站迁移的排名丢失源于跳过重定向审计，而不是平台变更；清单包括重定向映射、元数据传输、Schema连续性和上线后验证。
那次痛苦的经历基本上就是这个清单存在的原因。从那以后,我迁移过从800页宣传网站到拥有区域子域的31,000页发布商网站的各种规模的网站,基础知识每次都是一样的。顺序错了,漏掉一步,Google就会在Search Console中以最不愉快的方式告诉你。
所以就是这样。这是我在 Seahawk Media 实际使用的检查清单，不是理论框架。
---
1. 在做任何改动之前先进行完整爬取
显而易见？是的。被跳过？经常发生。
在单个文件移动之前,我用Screaming Frog SEO Spider爬取整个上线网站。在20,000页的网站上这需要几个小时,我通常在夜间启动爬取并将爬取结果存储到数据库模式,以免内存成为问题。我要捕获的内容:
- 每个可索引的URL（规范版本，不是分页噪音）
- 全面的响应代码,200s、301s、302s、404s,所有的。
- 现有的内部链接结构
- 规范标签、hreflang属性（如果适用）
- 页面标题和元描述（这样我可以验证它们在迁移后是否保留）
我将完整的爬取数据导出到CSV并保存。这是我的基线。这是我在新网站上线三周后要对比的文档。
很多人跳过这一步,因为"我们已经了解这个网站了"。你不了解。我以为我在2021年了解一个旅游客户的网站,结果发现他们有4,000个URL从一个没人在brief中提及的旧版CMS子目录中提供。在爬取中发现了。那本来会是一场灾难。
别忘了Google自己的数据
从Google Search Console拉取所有数据,至少过去16个月的性能数据、索引覆盖报告、任何手动操作、所有站点地图。从Google Analytics(现在当然是GA4)拉取数据,这样在任何变化发生之前,你就已经锁定了有机流量基准。截图在这里很有效;我也导出原始CSV。
---
2. 构建重定向映射表。然后再检查一次。
这是迁移成功或失败的地方。对于大型网站,重定向映射表是一个实际的电子表格,通常在Google Sheets中与客户、他们的开发团队以及任何可能在晚上11点意外覆盖公式的人共享。
结构很简单：
- A列：旧URL（精确，包括末尾斜杠或没有斜杠）
- B列：新URL（精确）
- C列：重定向类型（几乎所有情况都是301）
- D列：状态（已映射、已验证、已上线）
- E列：备注（捕获所有重定向、分类合并、有意放弃）
在拥有 20,000 页面的网站上，你显然无法逐个映射每个 URL。这是我的处理顺序：
- 首先映射所有表现最好的URL(按GSC的有机流量,前500个通常推动80%以上的流量)
- 映射分类和分类法页面
- 映射任何具有有意义反向链接的URL(用Ahrefs,按引用域过滤,不仅仅是原始链接)
- 对其他所有内容使用基于模式的重定向（例如 /product/old-slug/→/shop/old-slug/）
- 为你要停用的页面记录有意的 410 错误
基于模式的重定向是大多数初级开发人员容易搞错的地方。他们会编写一个过于宽泛的通配符规则，意外地重定向了他们本来不想重定向的 URL。在将任何模式规则放到生产环境之前，一定要在测试环境中测试。
---
3. 测试环境非可选项
我会长话短说，因为这一点无需太多解释。每次迁移都需要一个测试环境。这是绝对要求。
Seahawk在2022年有一个金融科技客户反对这个,想"就在上线版本做因为网站很小"。该网站有6,000页。我们在staging中做的。发现了一个插件冲突,它从所有产品页面剥离了规范标签。这本来会在Google重新爬取所有内容后才会显现,而在低权限域上这可能需要几周。
在测试环境中，你要检查：
- 所有重定向都能正常工作（我再次使用Screaming Frog，指向测试环境，以批量验证重定向映射）
- Robots.txt 阻止了暂存环境被索引（重要，使用 Disallow: /，同时添加 noindex 标头以获得双重保护）
- 新的网站地图是准确的，不包含测试环境的URL
- 规范标签指向正确的生产URL
- 使用 PageSpeed Insights 制定页面速度基准，迁移通常被用作重新设计的机会，而重新设计经常会破坏 Core Web Vitals
---
4. 上线流程（顺序比你想的更重要）
这是人们即兴发挥并给自己制造问题的部分。有一个特定的顺序。我不会偏离它。
第一步：发布前（发布前 48 小时）
- 将所有 DNS 记录的 TTL 降低至 300 秒（5 分钟）。这能显著加快传播速度。
- 告知客户：迁移期间不要更改内容、添加新页面或更新插件。
- 通知任何第三方集成（CDN、广告平台、监控工具）即将进行的变更。
第二步：发布窗口
- 更新 DNS
- 在新内容完全传播之前部署重定向，重定向应该在服务器级别上线，而不仅仅是在 WordPress 中
- 启用新的网站地图，禁用旧的
- 验证 robots.txt 正确（生产文件，不是测试文件）
第三步：发布后立即执行
- 在两小时内爬取新网站。使用 Screaming Frog 指向生产环境，遵循重定向。我在寻找意外的 404 错误、超过两跳的重定向链，以及任何应该可索引但显示 noindex 标签的页面。
- 在 Search Console 中提交新的 sitemap
- 通过 GSC 的 URL 检查工具获取首页，以提示 Googlebot 访问
我总是向客户强调的一点：Google 不会立即在搜索结果中反映新的 URL。会有爬虫抓取和重新处理的滞后。对于大型网站，在你能清楚地了解情况之前，预留两到六周的时间。在第四天因为排名发生变化而感到恐慌是正常的，这并不意味着出了问题。
---
5. 重定向链审计（大多数代理单独收费的步骤）
重定向链是缓慢的消耗。A → B → C → D 这样的 URL 让 Googlebot 做额外工作，也在多个跳转间稀释链接权益。在有多次之前迁移或平台切换历史的网站上，链可能会变得出人意料地深。
上线后，我导出完整的 Screaming Frog 爬取数据并筛选重定向链。任何超过两跳的都会被折叠。如果原始 URL 在重定向映射表中，我会更新它以直接指向最终目标。如果这是来自某个无人记录的迁移的遗留链，我会添加它。
仅这个步骤，在我们2023年初将一个客户从 Magento 迁移到 WooCommerce 的项目中，就花费了两天。他们在八年间进行了三次迁移。一些 URL 在到达正确页面之前需要通过五个重定向。我们合并了所有这些，一个月内他们在 Search Console 中的爬虫预算指标就有了明显改善。
---
6. 大规模内容验证
你无法手动审查 20,000 个页面。但你可以系统地验证重要的内容。
这是我在上线后前两周检查的内容：
- 标题标签和元描述：将随机 200 个页面样本与迁移前的 Screaming Frog 导出进行比较。不匹配的内容会立即被标记。
- 结构化数据：通过 Google 的 Rich Results Test 运行产品页面、文章页面和首页的样本。迁移比你想象的更经常破坏 schema 标记，特别是如果新主题使用不同的插件。
- 内部链接：Screaming Frog 爬虫，按内链过滤。高价值页面应该仍然有强大的内部链接数。如果一个类别页面之前有 400 个内部链接，现在只有 12 个，说明模板中出了问题。
- 图像和替代文本：虽然不是严格的 SEO 关键因素，但破损的图像会伤害用户体验信号，在模板化网站上很容易被遗漏。
---
7. 迁移后 90 天的监控
迁移不会在上线当天结束。它至少要进行 90 天。
我在迁移后的第一个月与客户建立了每周报告节奏,之后改为双周报告。以下是我监控的内容:
- GSC索引覆盖率:索引页面数量是否在恢复到迁移前的水平?超过三周仍未恢复的大幅下降需要调查。
- 自然流量与基准：按登陆页面类型分段（产品、分类、博客）。流量下降通常不均匀，有时分类页面会下降，而产品页面保持不变。
- 抓取预算:GSC的抓取统计报告显示每天平均抓取的页面数和服务器响应时间。如果Googlebot遇到大量404错误,会在这里显示。
- 排名位置追踪:我结合使用Ahrefs排名追踪和Google Search Console的性能报告。前两到三周的排名波动很常见,不一定是问题。第四周后持续下降需要采取行动。
- 反向链接档案:使用Ahrefs验证指向旧URL的高价值反向链接是否已正确重定向,或者标记为需要外展以更新的链接。
说实话?大多数迁移SEO问题在30天内如果你监控正确的指标是可以检测到的。让人吃亏的是那些没有人设置监控、客户在八个月后才发现的情况。
---
8. 我犯过的错误(让你不用重复犯)
早在2019年，我在为一个拥有英国、澳大利亚和加拿大子文件夹的客户进行迁移时，遗漏了 hreflang 实现。规范标签是正确的。重定向也没问题。但新网站上的 hreflang 注释使用了错误的地区代码，en-au 而不是 en-AU（在某些实现中，大小写很重要）。Google 开始向澳大利亚搜索者提供英国页面。我们花了六周才找出澳大利亚自然流量下降一半的原因。从那以后，我们在每次国际迁移中都加入了 hreflang 验证步骤。
还有一个：包含noindex URL的XML网站地图。这听起来像是个小不一致，但会发送相互矛盾的信号，确实值得清理。Screaming Frog可以审计你的网站地图，并标记其中任何返回noindex标签的URL。
可能是最昂贵的教训：没有回滚计划。在迁移出问题时，能够在一小时内将DNS切换回旧服务器的能力是无价的。我总是坚持让旧环境在迁移后至少保持活跃和完整30天。客户有时会反对托管成本。我向他们解释70%流量下降成本多少收入，他们就不再反对了。
---
常见问题
一个20,000页的网站迁移实际上需要多长时间规划？
现实来说？在上线日期之前需要6到10周的准备。仅重定向映射在这样规模的网站上就可能需要2到3周才能正确构建，特别是如果你要审计每个URL的反向链接。仓促准备会导致你花费数月进行恢复。
迁移后我需要提交一个disavow文件吗？
通常不需要，除非旧域名有有害链接，且你迁移的具体目的是逃离它们。如果你迁移到新域名并想要干净的链接档案，在GSC中的新属性上处理disavow。但对于大多数相同域名上的平台或重新设计迁移，disavow是不相关的。
你在大型迁移中看到的最大代理机构错误是什么？
将重定向映射视为开发任务。重定向是 SEO 任务，由开发人员来实现。拥有搜索策略的 SEO 团队或相关人员应该拥有该映射、审查它并签署批准。我见过开发人员构建的重定向规则在技术上是正确的，但在 SEO 上是错误的，因为没有人告诉他们哪个 URL 变体是规范的。
网站速度会影响迁移的SEO吗?
是的，比大多数人考虑的要多。Core Web Vitals 是排名因素，而迁移通常伴随重新设计，经常会引入更重的 JavaScript 或未优化的图像。在启动前，始终在旧网站和新网站之间运行 PageSpeed Insights 比较。如果新网站在移动设备上明显更慢，请在切换之前修复它。
你如何处理包含大量用户生成内容的网站迁移?
要谨慎处理。UGC页面单个质量往往较低,但汇总起来能驱动长尾流量。我通常建议进行爬虫分析步骤:识别哪些UGC URL有任何自然流量,具体重定向那些URL,其余的使用410状态码而不是留作404。410代表页面已刻意删除;404则含义不明确。
---
迁移是那些好坏之间的区别几乎完全取决于准备工作的事情之一。技术实现通常是简单的部分。做好前期工作，爬虫检查、重定向映射、暂存验证，这才是真正的工作所在。如果你接手的是一个已经上线且已经损坏的迁移，清单仍然适用。你只是以相反的顺序进行而已。