网站改版、换域名、调整目录结构，这些动作在业务上很常见，但对搜索引擎来说，是一次大规模的地址变动。如果处理得草率，原本能正常抓取的页面会变成 404，已经积累的内链会指向失效地址，蜘蛛再来时看到的是一片断头路。下面按迁移的时间顺序，整理一份可执行的自查思路。

一、迁移前：先把现有地址盘清楚

迁移最容易出问题的环节，是没搞清楚自己到底有哪些页面。凭印象整理必然遗漏，尤其是运营多年、栏目反复调整过的站点。

从日志和 sitemap 取并集

把服务器访问日志中近期被请求过的地址导出来，去掉静态资源、参数页和明显的垃圾请求，得到一个真实被抓取过的地址列表。同时把现有 sitemap 里的地址也导出来。两份清单取并集，才是需要逐条处理的资产，而不是只盯着 sitemap。

给每个地址定去向

建议把旧地址分成三类，逐条标注：

• 保留：新版仍有对应内容，地址尽量不动，或做 301 到新地址。
• 合并：多个旧页面并入一个新页面，选一个主目标做 301，其余同向跳转。
• 废弃：内容确实不再提供，返回 410 或 404，不要全部硬跳首页。

把所有旧地址统一 301 到首页，是最常见的偷懒做法。它会让蜘蛛在每个旧地址上都被送到同一个页面，既浪费抓取，也让跳转失去语义。

二、映射表：迁移的核心文档

旧地址与新地址的对应关系，应该落在一张表里，而不是散落在开发同学手改的配置中。这张表至少包含旧 URL、新 URL、跳转类型、负责人、上线状态。

• 跳转类型统一用 301，除非是临时活动页；302 传递不出地址变更的信号。
• 跳转目标必须是最终地址，避免 A 跳 B、B 再跳 C 的链式跳转。
• 表里的每一行都要在测试环境实际验证一次，确认状态码和目标地址都正确。

三、切换时：顺序比速度重要

切换当天最忌讳的是一次性全改完再看效果。建议按下面的顺序推进，每一步留出观察时间。

1. 先在新环境完成内容、结构、跳转配置的部署，用临时域名或 hosts 验证。
2. 确认新站可正常访问后，再开启跳转规则，并让旧站保留一段时间可读，便于比对。
3. 更新 sitemap，只保留迁移后的有效地址，删除已废弃的老地址。
4. 检查站内链接、导航、面包屑里是否还有指向旧地址的硬编码。
5. 如果涉及域名变更，同时更新 robots.txt 中的 sitemap 地址和页面上的 canonical。

跳转规则上线后，不要立刻删掉旧站内容。保留一段时间，方便对照日志确认蜘蛛确实按 301 走了新地址。

四、迁移后：用日志验证，而不是凭感觉

迁移完成后的一到两周，重点看三件事。

看旧地址的响应

抽样请求一批旧 URL，确认返回 301 且 Location 指向正确，没有 302、没有跳回自身、没有跳到 404 页面。批量检查可以用脚本跑，逐条记录状态码。

看新地址的抓取

日志里新地址的请求量应该逐步上升，旧地址的请求量逐步下降。如果旧地址仍被大量抓取却没有跳转，说明映射表有遗漏，或者规则没有真正生效。

看内链是否干净

站内链接如果还指着旧地址，蜘蛛会顺着这些链接重新走一遍跳转链，等于把迁移的工作量翻倍。用抓取工具跑一遍站内链接，把残留的旧地址替换掉。

五、容易遗漏的几个点

• 页面的 canonical、社交分享用的 URL 等元信息还写着旧域名。
• 图片、CSS、JS 等资源仍从旧域名加载。
• 移动版或其他渲染版本的地址没有同步迁移。
• 第三方后台、投放落地页里配置的链接未更新。
• sitemap 里混着新旧两套地址，互相矛盾。

迁移不是一次性动作，而是一段需要持续观察的过程。把地址盘点、映射表、切换顺序和事后验证这几件事做实，能减少很多改完之后流量慢慢下滑、却找不到原因的情况。