UrlEdge
回到博客
2026-03-12 UrlEdge 编辑部10 分钟阅读

网站迁移前后必做的跳转检查清单

网站迁移、换域名、换 CMS 或改 Headless 前,先用这份跳转清单盘点旧 URL、建立对照表、测跳转链,并准备上线后监控。

小型团队围着笔电规划网站迁移、跳转 QA 与上线检查清单

网站迁移会不会掉流量,很多时候不是设计稿或前端框架决定的,而是 redirects 有没有先管好。

在切 DNS、换 CMS、改 Headless 或品牌换域名前,最重要的问题其实很直白:每个重要旧 URL,能不能用一次干净的 redirect 到正确新 URL?

这份 网站迁移跳转清单 适合这些情境:

  • 换新域名
  • 从旧 CMS 搬到新 CMS
  • 从 monolith 改成 headless
  • 从子域名搬到主域名
  • 重整 blog、docs、商品分类或活动页 URL
  • SEO 代理商交接客户网站迁移
  • 电商平台改版或品牌整并

如果你要搬的是 Shopify,可以搭配 Shopify 改到 Headless,怎么保住网址与流量。如果同时换域名,请把 换域名时如何保留路径与 UTM 参数 放在旁边一起看。

迁站前的不可妥协目标

上线前,至少要做到这五件事:

  1. 高价值旧 URL 已对应到正确新 URL
  2. 永久搬移使用永久跳转意图
  3. 跳转尽量一跳抵达最终页面
  4. 站内链接已指向新的 canonical URL
  5. 上线后监控在流量切换前就准备好

少一项,风险就会明显上升。

团队在笔电前讨论网站迁移、跳转 QA 与上线日检查

15 项网站迁移跳转清单

1. 盘点目前所有重要 URL

不要靠记忆规划跳转。

请从这些来源拉 URL:

  • XML sitemap
  • Google Search Console top pages
  • GA4 或数据仓储的 landing pages
  • 广告与活动链接
  • EDM、CRM、WhatsApp、微信服务号或企业微信模板
  • backlink、合作伙伴文件与 KOL 文章
  • 旧 blog、docs、support archive
  • 商品页、分类页与品牌页

只要某个 URL 带来搜索流量、转换流量、客服流量或合作流量,就应该进入迁站 inventory。

2. 早点击定最终 canonical hostname

先决定最后要用哪个 host:

  • https://new-brand.com
  • https://www.new-brand.com

不要上线前才讨论。host 决策模糊,最容易产生 http -> https -> www -> final 这类跳转链。

3. 用真正的表格或 CSV 管跳转对照表

最低限度,请保留这些字段:

old_url,new_url,status,priority,owner,notes
https://old-brand.com/pricing,https://new-brand.com/pricing,301,high,marketing,core landing page
https://old-brand.com/docs/api,https://new-brand.com/docs/api,301,high,engineering,docs migration

这张表是 SEO、marketing、工程、客服和代理商之间的共同真相源。不要把规则散在 Slack、issue、代码注释和某个人的笔记里。

4. 先保护最高价值的 URL

优先处理:

  • 首页
  • pricing 与主要转换页
  • 热门自然搜索 landing pages
  • 商品页与分类页
  • 文件与支持文章
  • 目前仍在投放的活动页
  • email、WhatsApp、简讯中常用的 URL

低流量 archive 页可以稍后处理。上线第一天,不要让最高价值路径跟着低优先级页面一起排队。

5. 把旧 URL 对到最适合的新目的地

目标不一定是完全保留原路径,而是找到最合适的目的地。

好的 mapping:

  • 旧商品页 -> 新商品页
  • 旧分类页 -> 最接近的新分类
  • 旧 docs 页 -> 对应的新 docs 页
  • 旧活动页 -> 仍相关的活动页或产品页

不好的 mapping:

  • 全部导到首页
  • 退役 docs 全部导首页
  • 深层商品页导到泛分类页但没有上下文

用户点进来是为了某个具体目的,不是为了重新逛一次你的网站。

6. 永久搬移就用永久跳转

如果旧 URL 不会回来,请使用永久跳转意图,通常是 301

如果你还在比较 301、302、307、308,可以先看 301、302、307、308 跳转差在哪

重点不是背代码,而是不要让永久网站迁移在暂时跳转上跑好几个月。

7. 路径结构相近时,保留 path

如果新旧站结构接近,path-preserving rules 可以省下大量人工工作。

例如:

  • /docs/* -> /docs/*
  • /blog/* -> /blog/*
  • /features/* -> /features/*

但如果信息架构大改,不要盲目用 wildcard。高价值 URL 仍应该做明确的一对一 mapping。

实作方式可以看 换域名时如何保留路径与 UTM 参数

8. 保留重要 query strings

这件事很容易被忘掉。

常见需要保留的参数包括:

  • UTM 参数
  • affiliate 或 referral 参数
  • coupon 或活动代码
  • App 或页面功能需要的参数
  • CRM、EDM、广告平台用来判断来源的参数

不是每个 query string 都值得永远保留,但重要参数要明确处理,不能靠供应商默认值赌运气。

9. 上线前消掉跳转链

不要等 PageSpeed、crawler 或用户告诉你跳转路径很乱。

这种链:

old-url -> old-intermediate -> final-url

应该整理成:

old-url -> final-url

如果要深入排查,请看 怎么找出跳转链与跳转回圈

10. 在 staging 或受控 host 测试

正式 cutover 前,至少测:

  • 首页
  • 热门 landing pages
  • docs paths
  • blog posts
  • 商品页与分类页
  • 带参数的活动 URL
  • 若有装置导流,也测手机与桌面

可以用浏览器,也可以用命令列:

curl -IL https://old-brand.com/docs/api

请看完整 hop,不要只看最后页面能不能打开。

11. 上线前或上线后立刻更新站内链接

跳转是安全网,不是理想状态。

请更新:

  • nav links
  • footer links
  • 文章内链接
  • 产品 CTA
  • docs sidebar
  • email 模板
  • sitemap 和 RSS 来源

站内链接应该直接指向新 canonical URL。

12. 同步更新 sitemap、canonical 与 navigation

跳转对照表只是迁站的一部分。

也要更新:

  • XML sitemap
  • canonical tags
  • hreflang
  • main navigation
  • structured data URL
  • Open Graph URL 与分享预览

如果跳转说一套、canonical 又说另一套,你只是把清理工作留到上线后。

13. 上线前就准备监控

前 7 到 14 天要有明确监控计划:

  • 看 404
  • 看前几百个跳转 URL
  • 监控高价值页流量
  • 检查广告与 EDM landing pages
  • 确认 docs、support、商品页仍落到正确位置
  • 观察 Search Console 是否出现异常

这时候 analytics跳转检查工具坏链接监控 才是真正有用的运营工具,不只是功能清单。

14. 让旧跳转层稳定存在足够久

不要把跳转当成一周任务。

旧链接可能会在外面活好几个月甚至好几年,尤其是:

  • backlink
  • 书签
  • PDF 和简报
  • 合作伙伴文件
  • 旧社交贴文
  • QR Code 和印刷物

请规划跳转耐久性,而不是只求 launch week 没事。

15. 记录例外与边界情境

不是每个旧 URL 都一定要跳转。

有些应该回 404 或 410;有些法务、支持、账户或 App route 可能需要特殊处理;有些活动页可能只能导到 archive 或说明页面。

把例外写清楚,包含原因、owner 和预期行为。否则半年后没有人知道那条规则是故意的,还是迁移时漏掉的。

最短可行的迁站顺序

如果你需要一个能落地的顺序,可以这样跑:

  1. 导出 URL inventory
  2. 选定 canonical host
  3. 建立跳转对照表
  4. 先测高价值 URL
  5. 消掉跳转链与回圈
  6. 更新站内链接、sitemap、canonical
  7. 切 DNS 或切流量
  8. 监控 404、跳转命中与高价值页流量

这个顺序对工程、营销、SEO 代理商和客服都比较好协作,因为每一步都能明确交付。

UrlEdge 可以怎么帮忙

UrlEdge 适合网站迁移时处理:

  • 大量跳转导入
  • wildcard path forwarding
  • 301 / 302 规则管理
  • staging 验证
  • 快速发布与回滚
  • 坏链接监控
  • 上线后跳转分析

你可以先把旧 URL 对照表导入 大量跳转管理,上线前用 跳转检查工具 抽查高价值 URL,再用 analytics 看上线后是否真的抵达预期目的地。

FAQ

网站迁移一定要每个 URL 都一对一跳转吗?

不一定。高价值 URL 要明确处理;低价值、过期或不该再存在的 URL 可以回 404 或 410。重点是有判断,不是机械式全部导首页。

什么时候可以用 wildcard?

新旧路径结构大致一致时很适合,例如 /docs/*/docs/*。如果分类、slug 或信息架构大改,高价值页还是要手动 mapping。

上线后要监控多久?

至少先看 7 到 14 天,但高价值旧域名和热门 backlink 的跳转通常要保留更久。很多旧链接不会在 launch week 就消失。

SEO 代理商交接时,这份清单怎么用?

把 URL inventory、跳转对照表、例外规则、上线日检查与监控报表都当成交付物。不要只交一份「已设置完成」的口头说明。

准备把链接运营收起来了吗?

开始使用 UrlEdge,把 short links、redirect rules、UTM 参数和 device routing 放进同一个工作台。

开始使用

相关文章

查看全部