三年前，我接手了一个已经上线的迁移项目。没有演示环境。没有重定向映射。一个拥有 22,000 页的电商目录，有人刚把它指向新域名就宣布"完成"了。在六周内，自然流量下降了 74%。客户打电话时语气有点慌张，我花了将近四个月才把这个烂摊子收拾好。
关键要点：网站迁移的排名丢失源于跳过重定向审计，而不是平台变更；清单包括重定向映射、元数据传输、Schema连续性和上线后验证。Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.
那次经历——尽管很痛苦——正是这份清单存在的原因。此后我迁移过的网站从800页的宣传网站到拥有地区子域名的31,000页的发行商都有，每次的基本原理都一样。顺序错了，跳过一个步骤，Google会在Search Console里以最不愉快的方式告诉你。
所以就是这样。这是我在 Seahawk Media 实际使用的检查清单，不是理论框架。Seahawk Media, not a theoretical framework.
---
1. 在做任何改动之前先进行完整爬取
显而易见？是的。被跳过？经常发生。
在移动任何文件之前，我用Screaming Frog SEO Spider爬取整个活跃网站。在20,000页的网站上这需要几小时——我通常在夜间启动爬取，使用数据库模式存储，这样内存就不会成问题。我要捕获的是：Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- 每个可索引的URL（规范版本，不是分页噪音）
- 全部响应代码——200、301、302、404，应有尽有
- 现有的内部链接结构
- 规范标签、hreflang属性（如果适用）
- 页面标题和元描述（这样我可以验证它们在迁移后是否保留）
我将完整的爬取数据导出到CSV并保存。这是我的基线。这是我在新网站上线三周后要对比的文档。
很多人跳过这个步骤因为"我们已经了解网站了"。你没有。2021年我以为自己了解一个旅行客户的网站——结果发现他们有4,000个URL被托管在一个遗留CMS子目录中，而没人在简报中提过。在爬取中发现了它。那会是场灾难。
别忘了Google自己的数据
从Google Search Console拉取所有数据——至少过去16个月的性能数据、索引覆盖率报告、任何手动处罚、所有网站地图。从Google Analytics（现在显然是GA4）拉取数据，这样在任何变更发生前，你就锁定了自然流量基准。截图在这里就可以了；我也会导出原始CSV。Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. 构建重定向映射表。然后再检查一次。
这是迁移成败的关键。在大型网站上，重定向映射是一个真实的电子表格——通常与客户、他们的开发团队和任何可能在晚上11点意外覆盖公式的人共享在Google Sheets中。
结构很简单：
- A列：旧URL（精确，包括末尾斜杠或没有斜杠）
- B列：新URL（精确）
- C列：重定向类型（几乎所有情况都是301）
- D列：状态（已映射、已验证、已上线）
- E列：备注（捕获所有重定向、分类合并、有意放弃）
在拥有 20,000 页面的网站上，你显然无法逐个映射每个 URL。这是我的处理顺序：
- 先映射所有高性能URL（按GSC中的自然流量——前500个通常驱动80%以上的流量）
- 映射分类和分类法页面
- 映射任何有有意义反向链接的URL（用Ahrefs做这件事——按引荐域名过滤，而不是仅仅原始链接）Ahrefs for this -- filter by referring domains, not just raw links)
- 对其他所有内容使用基于模式的重定向（例如 /product/old-slug/→/shop/old-slug/）
/product/old-slug/→/shop/old-slug/) - 为你要停用的页面记录有意的 410 错误
基于模式的重定向是大多数初级开发人员容易搞错的地方。他们会编写一个过于宽泛的通配符规则，意外地重定向了他们本来不想重定向的 URL。在将任何模式规则放到生产环境之前，一定要在测试环境中测试。
---
3. 测试环境非可选项
我会长话短说，因为这一点无需太多解释。每次迁移都需要一个测试环境。这是绝对要求。
Seahawk在2022年有一个金融科技客户反对这种做法——想"直接在生产环境上做，因为网站很小"。这个网站有6000个页面。我们在测试环境上做了。发现了一个插件冲突，它正在从所有产品页面上去掉规范标签。这种情况在Google重新爬取所有内容之前是看不出来的，而在权重较低的域名上，重新爬取可能需要几周时间。
在测试环境中，你要检查：
- 所有重定向都能正常工作（我再次使用Screaming Frog，指向测试环境，以批量验证重定向映射）
- Robots.txt正在阻止测试环境被索引（重要——使用Disallow: /，同时添加noindex头部以获得双重保护）
Disallow: /but also add a noindex header for double protection) - 新的网站地图是准确的，不包含测试环境的URL
- 规范标签指向正确的生产URL
- 使用PageSpeed Insights进行页面速度基准测试——迁移往往被用作重新设计的机会，而重新设计经常会破坏Core Web VitalsPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy Core Web Vitals
---
4. 上线流程（顺序比你想的更重要）
这是人们即兴发挥并给自己制造问题的部分。有一个特定的顺序。我不会偏离它。
第一步：发布前（发布前 48 小时）
- 将所有 DNS 记录的 TTL 降低至 300 秒（5 分钟）。这能显著加快传播速度。
- 告知客户：迁移期间不要更改内容、添加新页面或更新插件。
- 通知任何第三方集成（CDN、广告平台、监控工具）即将进行的变更。
第二步：发布窗口
- 更新 DNS
- 在新内容完全传播之前部署重定向——重定向应该在服务器级别是活跃的，而不仅仅是在WordPress中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 导出进行比较。不匹配的内容会立即被标记。: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- 结构化数据：通过 Google 的 Rich Results Test 运行产品页面、文章页面和首页的样本。迁移比你想象的更经常破坏 schema 标记，特别是如果新主题使用不同的插件。: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- 内部链接：Screaming Frog 爬虫，按内链过滤。高价值页面应该仍然有强大的内部链接数。如果一个类别页面之前有 400 个内部链接，现在只有 12 个，说明模板中出了问题。: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
- 图像和替代文本：虽然不是严格的 SEO 关键因素，但破损的图像会伤害用户体验信号，在模板化网站上很容易被遗漏。: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
7. 迁移后 90 天的监控
迁移不会在上线当天结束。它至少要进行 90 天。
我在迁移后的第一个月与客户建立了每周报告节奏,之后改为双周报告。以下是我监控的内容:
- GSC索引覆盖率:索引页面数量是否在恢复到迁移前的水平?超过三周仍未恢复的大幅下降需要调查。: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- 有机流量与基线对比：按登陆页面类型分段（产品、分类、博客）。流量下降通常是不均匀的——有时分类页面会崩溃，而产品页面保持稳定。: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
- 抓取预算:GSC的抓取统计报告显示每天平均抓取的页面数和服务器响应时间。如果Googlebot遇到大量404错误,会在这里显示。: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- 排名位置追踪:我结合使用Ahrefs排名追踪和Google Search Console的性能报告。前两到三周的排名波动很常见,不一定是问题。第四周后持续下降需要采取行动。: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
- 反向链接档案:使用Ahrefs验证指向旧URL的高价值反向链接是否已正确重定向,或者标记为需要外展以更新的链接。: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
说实话?大多数迁移SEO问题在30天内如果你监控正确的指标是可以检测到的。让人吃亏的是那些没有人设置监控、客户在八个月后才发现的情况。
---
8. 我犯过的错误(让你不用重复犯)
回到2019年，我在为一个拥有英国、澳大利亚和加拿大子文件夹的客户进行迁移时，遗漏了hreflang实现。规范标签是正确的。重定向也没问题。但新网站上的hreflang注解有错误的地区代码——是en-au而不是en-AU（在某些实现中，大小写很重要）。Google开始向澳大利亚搜索者提供英国页面。我们花了六周时间才搞清楚为什么澳大利亚有机流量减少了一半。从那以后，我们在每个国际迁移中都加入了hreflang验证步骤。en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
还有一个：包含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则含义不明确。
---
迁移是那些准备工作决定成败的事项之一。技术实施通常是简单的部分。做好发布前的工作——爬取、重定向映射、暂存环境验证——这才是真正的工作所在。如果你接手的是一个已上线且已出现问题的迁移，检查清单仍然适用。你只是需要反向执行。