网站迁移 301 重定向设置步骤

如何一步一步为网站迁移设置 301 重定向

网站迁移从来不只是一次技术搬家。只要 URL 出错，原本能带来排名、转化，或从新闻邮件中获得链接的页面，就可能落到无人问津的地方。所以，网站迁移 301 重定向必须在上线前就规划好，而不是上线后再补救。

本指南会带你一步一步完成网站迁移中的 301 重定向设置，而且不会把所有工作都压在重定向层上。你会先梳理旧站，判断哪些页面值得跳转，并在搜索引擎和用户发现漏洞前检查结果。至于 301重定向怎么设置，关键思路其实很简单：先定规则，再落地执行，最后验证结果。

1. 明确迁移类型和重定向目标

先回答一个最简单的问题：你做的是哪种网站迁移？域名更换、平台切换、URL 结构调整，这三种情况的思路完全不同。如果这三件事同时发生，先把它写下来。不要等到后面才整理。

比如，品牌从 oldsite.com 搬到 newsite.com，可能需要几乎把所有线上页面都重定向；而从一个模板系统切换到另一个 CMS，则可能保持相同 URL，只是页面渲染方式变了。两者不是同一种工作。如果你把它们当成同一件事，重定向方案很快就会乱套。

给重定向层设定一个目标：保住已经有价值的页面。这里说的是流量、外链和用户意图。商品页应该跳到最接近的商品页。博客文章应该跳到最接近的文章，而不是首页。

用通俗语言写下迁移规则，越简短越好。“旧分类页迁移到新分类页。”“下线的促销页不需要重定向。”“内容很薄的归档页可以删除。”这些决定能在后面省下大量时间，因为 301 重定向应该跟着网站真实结构走，而不是跟着上线周的猜测走。

如果这次迁移还涉及内容归属或分析配置，也要让团队看得见。一次站点迁移通常会影响不止一个小组，重定向方案不仅要符合 URL 规划，也要符合业务计划。想了解迁移相关支持工作的更广视角，可以看网站维护费用是多少。

2. 只整理需要重定向覆盖的 URL

不要把所有历史 URL 都列出来，除非你真的需要。纸面上看起来很完整，但实际上会浪费时间，还会制造噪音。先从仍有价值的页面、目录和文件入手：落地页、服务页、博客文章、分类页、被公开链接的图片，以及仍然有访问量的 PDF。

从多个来源提取 URL。使用当前站点地图、分析数据、服务器日志，以及你手头已有的旧抓取结果。没有访问量、也没有外链的 URL，可能不值得花心思；但有外部链接的 URL 就不同了。哪怕站点搬完半年后，它可能仍然有影响。

把应该主动下线的页面排除掉。2021 年的季节性活动，不需要因为“它还存在”就给它找新家。旧的内部测试页也是一样。这里需要的是克制。只要重要页面都覆盖到，重定向数量少一点，往往比太多更好。

把清单分成几个简单类别：页面、目录、文件和特殊情况。这里数字很有用。12 个 URL 的处理方式，和 1,200 个 URL 完全不同；后者需要的是规则模式，而不是逐条手工写规则。如果跳过这一步，重定向映射表就会变得难以审查。

整理清单时只关注旧站，不要太早混入新站。旧站是现状的事实来源，新站是目标。过早把两边混在一起，会更难发现缺失页面和误判重复页面。

3. 将旧 URL 匹配到正确的新 URL

现在开始做映射。最简单的情况是清晰的一对一跳转：一个旧 URL 对应一个新 URL，关系一目了然。讲价格的博客文章迁移到新的价格文章；讲审计服务的页面跳到新的审计页。很直接。

但真实迁移往往没这么整齐。有时一个旧页面会拆成两个新页面，或者三个旧页面合并成一个更强的页面。这种情况下，要判断用户原本最可能想看什么。如果旧页面同时覆盖“设置”和“支持”，而新站把它们拆成两个页面，那就把主意图匹配到最合适的页面，再在站内用链接补充其余部分。

不要把所有东西都重定向到首页。这样做一下午看起来很省事，但后面几个月会很贵。搜索引擎不喜欢相关性弱的跳转，用户也会更快察觉。找价格页的人不想看一个泛泛的落地页，他们想要价格页，或者最接近的可用替代页。

对于已删除的内容，要明确判断。如果没有替代内容，也没有真正对应的页面，那就不要硬塞进重定向表。比起强行配一个错误目标，这样更干净。比如一场 2019 年的活动页面，就不需要为了填表格而编造一个新去处。

在难处理的 URL 旁边写备注。对于合并页面、拆分页面和已下线内容，用一句简短说明标记清楚。这样当别人上线前两天来审查计划、问为什么页面 A 要跳到页面 B 时，答案能直接在映射表里看到，而不是藏在聊天记录里。

4. 选择合适的 301 重定向实现方式

301 重定向放在哪里，取决于迁移后的网站如何托管。在某些架构里，服务器配置是最干净的方案；在另一些架构里，CMS、CDN 或应用路由层更合适。选择一个能稳定提供跳转、又不会增加额外复杂度的位置。

如果网站运行在传统 Web 服务器上，服务器级规则往往是最直接的方式。如果网站由带内置重定向工具的 CMS 管理，对于小规模迁移可能已经足够。如果流量经过 CDN，边缘规则会很有帮助，尤其当你需要对大量 URL 快速更新时。

每种方式都有取舍。服务器规则很强大，但需要谨慎处理。CMS 插件很方便，但也容易堆积得很乱。CDN 规则速度快，但你必须清楚它和缓存、路径匹配之间的交互方式。要根据迁移后的站点来选，而不是凭习惯。

如果这次迁移还会改动安全设置、主机环境或追踪配置，最好把这些工作放在同一窗口里协调。依赖错误主机名，或者证书还没配好的重定向层，可能会以奇怪的方式失败。想看和站点防护相关的规划，可以参考网站安全。

如果团队规模较大，建议把方法统一记录在一个地方。把负责人、平台和部署路径写在重定向映射表旁边。这样，修改规则的人就知道它们应该放在 Nginx、Apache、CMS 表格、CDN 控制面板，还是应用代码里。

5. 编写并整理 301 规则

现在把映射表转成真正的 301 重定向。规则要保持整洁。一个模式只做一件事。如果某条规则试图匹配太多 URL 形态，它可能会抓错页面，把用户送到奇怪的地方。

注意重定向循环。循环是指页面 A 跳到页面 B，而页面 B 又跳回页面 A；或者两个页面互相来回跳。这对爬虫和用户来说都是死胡同，也会浪费抓取预算。这个词听起来很无聊，但一旦页面没法被正常索引，它就会变得非常重要。

也要避免重定向链。链条是指一个跳转接着另一个跳转，再接着下一个。A 跳到 B，B 再跳到 C。它虽然能工作，但效果很差，还会拖慢速度。如果能让 A 直接跳到 C，就直接这么做。

在文件或界面里使用统一的命名和分组方式。按板块归类：旧博客路径、旧服务路径、旧产品路径、已下线资源。整齐的列表更容易测试，也更方便在上线当天晚上 6 点直接交给另一位开发者，不需要长篇解释。

注意例外情况。像“把 /blog/ 下所有内容都重定向到 /insights/”这样的宽泛规则，看起来高效，但可能会破坏标签页、作者页或旧媒体链接。如果某种模式有例外，就要在发布前先把例外单独排除掉。这样后期清理会轻松很多。

6. 在上线前后验证重定向行为

测试应该在上线前完成，而不是在第一个用户报告页面坏掉之后再做。先抽查映射表中的单个 URL，再测试批量模式，然后测试一些特殊情况，比如末尾斜杠、大小写路径、查询字符串，以及带扩展名的文件。一个 URL 能正常跳转，不代表它的近亲也没问题。

要确认返回的是真正的 301，而不是 302，也不是那种浏览器里看起来像重定向、实际上只是软改写的方式。这个区别很重要。搜索引擎对永久迁移和临时跳转的处理方式不同，用户也不应该靠猜来判断发生了什么。最好用能显示真实响应的工具检查状态码。

不要只测显眼的路径。旧 PDF、图片 URL、嵌套目录 URL 常常会被遗漏。一个缺失的文件路径，可能会在上线后持续制造一串 404，尤其是那些多年以前就嵌在页面里或被社交媒体分享过的资源。遇到网站迁移后404怎么处理，最直接的办法就是先确认原始链接是否应该继续保留，再把缺失目标补回到正确的新地址。

检查分两个阶段进行：一是在预发布环境中、上线前完成；二是在正式站点上线后立刻再跑一遍。第二轮能发现部署问题、缓存意外，以及真正主机环境下才会出现的规则差异。很多团队都是在第二轮里才找到那个漏掉的 URL。

如果迁移还包含新的分析或监控系统，也要确认重定向不会把这些系统弄坏。能同时看到流量、响应码和抓取行为，会让迁移更容易被信任。对于在这类项目中比较测量工具的团队，网站分析费用是多少会是一个有用的参考。

7. 迁移后更新支撑信号

301 重定向不应该独自承担整个迁移工作。要更新站内链接，让新站引用自己的新地址。如果导航里还连着旧地址，每一次点击都会多一次不必要的跳转。那会增加用户等待时间，也会增加爬虫负担。

刷新 XML 网站地图，改成新 URL，并在需要的地方提交它们。把已经重定向的旧 URL 从线上网站地图中移除，只保留目标 URL。即使重定向完全正常，充满过时地址的网站地图也会发出混乱信号。

检查 canonical 标签。它们应该指向新页面，而不是旧页面。这虽然只是代码里很小的一行，但影响不小。仍然引用旧 URL 的 canonical 标签，会让你向搜索引擎传递的信息变得含糊，尤其是在上线后的第一次抓取周期里。

如果可以，也更新外部引用。这可能包括合作网站、社交资料、邮件模板，或者你能控制的目录信息。你不可能改完所有地方，这没关系。目标是减少不必要地走重定向层，而不是把整个互联网都修一遍。

如果这次迁移是更大规模改版的一部分，把重定向工作和更广义的内容与预算决策一起看，会更有帮助。标题为网站改版预算与维护预算的页面，可以帮助你区分“变更工作”和“日常维护”。

8. 在上线后的首个窗口期监控抓取和流量问题

上线后的第一个窗口期，问题最容易暴露。要检查是否有遗漏 URL、意外的 404、异常重定向，以及旧路径请求激增。对于大型网站，最初几天最好每天都看，甚至一天两次也不过分。

把服务器日志、分析数据和搜索控制台数据放在一起看。单一来源总会漏掉一些信息。日志里的 404 可能说明站内链接坏了；抓取错误可能是某个重定向 URL 拼错了；关键页面流量下降，可能意味着某个重要地方还在分享旧地址。

发现缺口就尽快修补。漏掉的 URL 直接补上；规则过宽就收窄；出现链条就压缩成直达。重定向映射表不是上线当天就结束的，它至少在迁移初期几天里仍然是一份活文档。

先跟踪前 7 天最重要的页面，如果迁移规模较大，再在 30 天后复查一次。这样你会得到两个检查点：一个看是否有立刻的故障，一个看较慢的抓取和索引影响。如果数据不对，不要等它自己变好。

向团队汇报时，要给出具体例子，不要只写笼统状态。“还有 4 个商品 URL 返回 404”就很有用。“还有些问题待处理”就没什么意义。如果营销活动、媒体报道，或者高外链页面仍指向旧地址，先修这些路径。漏掉一个 URL 的后果，可能比十几个低价值页面更大。

当第一波问题稳定后，再根据真实流量回头检查重定向层。有些旧 URL 的重要性，会比最初清单显示的更高；也有些 URL 永远不会再被访问。这些证据能帮助你收紧重定向方案，让迁移完成后的网站更干净。