那些“不该影响 SEO”的迁移，总是会影响 SEO
设想一个团队决定把 /products.php?id=4471&cat=12 改成 /products/oak-dining-table。所有人都觉得这早该做了——新 URL 更简洁、更易分享，也更适配改版。市场部门直接放行，理由是“只是改个 URL，内容还是那些内容”。上线几周后，自然流量骤降，而这是谁都没预料到的。
这是 SEO 中最容易避免的排名损失，却又频频发生，原因在于 URL 迁移看起来像是无关紧要的技术细节，但它的真实性质是：你在要求 Google 把多年积累的信任，从一组地址逐一转移到另一组地址上，而这个过程容不得“差不多就行”。
如果执行严谨，一次迁移几乎不会留下痕迹——只是短暂回落，几周内就 能恢复。如果草率行事，就会留下长达数月的流量缺口，而这本不该是一次改版造成的后果。二者的差别几乎完全取决于三样朴素的东西：重定向映射表、canonical 标签，以及站点地图。把这三样做对，迁移的其余部分就只是普通的工程工作。
在改动任何一个 URL 之前，先建好重定向映射表
重定向映射表是一张表格，不是一条规则。每个旧 URL 都要对应一个确定的新 URL。不是某种模式匹配，不是兜底跳转到首页，也不是“重定向自己会处理好”——每个 URL 一行，旧的对新的，由人工核对。
这一点在最容易被跳过的地方恰恰最重要：查询字符串 URL。?category=lighting&sort=price_asc&page=2 不是一个 URL，而是一整套组合爆炸出来的 URL，其中大多数变体并没有真正的排名价值——它们只是你的 CMS 无意中生成的抓取噪音。正确的做法是把它们分成两类：
- 真正有排名、有流量的 URL。 从 Search Console 的效果报告和你的分析工具中提取这些数据，而不是从数据库导出。如果某个带参数的 URL 在过去 12-16 个月里获得过展现和点击，就应该为它设置明确的一对一重定向，指向对应的简洁 URL。
- 纯粹是噪音的 URL。 分面筛选、会话 ID、追踪参数、排序方式。这些应该返回 404，或重定向到最接近的分类页——它们从未积累过值得保留的权重，逐一为成千上万个这样的 URL 做映射，只会浪费本该花在真正重要的 URL 上的时间。
跳过这一步分类，团队往往会走向两个极端：要么把所有内容都重定向到首页（一旦数量达到一定规模，Google 会将其视为软 404 模式），要么试图对曾经存在过的每一种参数组合都做 301（这会让重定向映射表膨胀到没人能维护或核实的程度）。
重定向：一跳到位、状态码正确、没有例外
映射表建好之后，落实它的规则简单且不容通融：
- 用 301，不用 302。 302 告诉爬虫这次变动是临时的，这会影响 Google 认定哪个 URL 为 canonical、以及切换的速度——Google 官方说过，301 和 302 在传递排名信号上效果相近，所以这里 302 的真正代价不是权重损失，而是过渡变得更慢、更不确定。对于永久性的 URL 结构变更，从第一天起，301 才是正确、无歧义的信号。
- 始终只跳一次。 A 重定向到 B，而不是 A 到 B 再到 C。每多一跳，信号就被稀释一分，抓取速度也随之变慢，这也是那些别人已经“完成”的迁移里最常见的翻车点之一。上线前，用 Screaming Frog 这类爬虫工具跑一遍完整的重定向映射表，专门检查跳转链和循环。
- 同时更新站内链接。 就算重定向设置正确，也不代表可以让导航、页脚和正文中的链接继续指向旧 URL。每一条仍然指向重定向的站内链接，都是一次白白浪费的抓取请求，信号强度也比直接链接稍弱。把链接改过来，让重定向成为安全网，而不是主要路径。
- 重定向保留的时间要远超 Google 给出的最低标准。 Google 官方指南建议，网站迁移后至少维持重定向一年。旧的外链、书签和缓存链接不会按你的时间表失效，所以应该把“一年”当作底线，而不是目标——恰好在这个时间点撤掉重定向，是许多网站白白损失外链权重的常见原因。
canonical 标签能完成重定向映射表做不到的清理工作
采用查询字符串的网站，几乎都存在重复内容问题，而这类问题应该借迁移之机解决，而不是原样带过去。如果 /product?id=4471 和 /product?id=4471&ref=email 同时存在，二 者在重定向之后都应该指向同一个简洁 URL，而这个简洁 URL 需要一个指向自身的 canonical 标签。不要让旧的参数变体以“canonical 指向自身”的形式继续存活——那只是把重复内容问题原封不动地搬进了你的新 URL 结构里，而不是解决它。
这项审查要在上线前做，而不是上线后：从 Search Console 的“页面”报告（在“编入索引”下）中提取所有已收录的 URL，按它们应该归并到的那个简洁目标进行分组，并确认目标页面上的 canonical 标签指向自身，而不是意外地被模板保留、指回旧有模式。
站点地图的调整顺序，比大多数人以为的更重要
你调整站点地图的先后顺序，实际上会改变 Google 重新处理这次迁移的速度：
- 上线前： 确认当前的站点地图准确反映了今天线上的实际情况。一份过时的迁移前站点地图，会成为后续对比的糟糕基准。
- 上线时： 发布一份新的站点地图，只包含新的简洁 URL——不含被重定向的 URL，也不含参数变体。立即在 Search Console 中提交。
- 上线后 2-4 周内： 保留旧的站点地图，让它仍可访问（而不是删除），这样 Google 的爬虫仍能找到并处理其中列出的重定向，而不是只能靠速度更慢的偶然抓取来发现它们。
- 过了这个窗口期之后： 下线旧的站点地图。重定向本身仍然保持生效，你只是在旧地图完成使命后，不再主动把爬虫指向它。
在这段窗口期内，每天关注“页面”报告，留意“带有重定向的页面”数量是否在上升，“未找到（404）”数量是否保持平稳。迁移过程中出现 404 激增，说明你的重定向映射表存在缺口，而不是 Google 会自动帮你绕过去的问题。
做对了的情况下，排名回落到底是什么样子
即便是完美无缺的迁移，也会带来实实在在的回落——这不是危险信号，而是 Google 正在重新抓取，并把信号重新关联到新地址上。健康的迁移是这样的：排名在几周内小幅走弱，随后大部分名次恢复，两个月左右就能追平甚至反超此前水平（简洁的 URL 加上改版带来的其他改进）——具体时间会因抓取频率和网站规模而异。不健康的迁移则是：回落在第一个月之后仍持续加深，“页面”报告中开始出现 404，到第三个月流量依然没有恢复。“预期中的回落”和“造成流量损失的失误”之间的差距，几乎完全可以用上面提到的重定向映射表、canonical 审查和站点地图调整顺序来解释——很少会有第四种神秘原因。
结论
URL 迁移靠的不是一条重定向规则加上祈祷。它需要一张表格，把每一个曾带来流量的 URL 精确映射到唯一的新目标；需要一次 canonical 审查，补上旧结构掩盖的重复内容漏洞；还需要一套站点地图调整顺序，在不被噪音淹没信号的前提下，告诉 Google 究竟发生了什么变化。把这三件事做严谨，回落期就是几周，而不是几个季度。如果你正打算调整 URL 结构，并希望在上线前就把重定向映射表建好、核实好，而不是等流量下滑之后再去补救，我们的 SEO 团队会在上线前而不是流量下滑之后，为你规划好这样的迁移。
