Redirect API 与规则即代码：用 CI/CD 管好 URL 变更

很多重定向一开始只是小修小补：商品 URL 改了，帮助文档搬了，活动页换了 slug，有人在 next.config.js、Cloudflare、CMS 插件或 Nginx 里加一条规则。

少量规则这样做问题不大。到了网站迁移、域名切换、Shopify/WordPress/headless 改版、跨境电商、私域二维码、达人链接、广告投放和合作伙伴流量，重定向就不再是“顺手配一下”的东西。

一条重定向规则会决定老链接、搜索流量、付费点击、邮件、二维码、affiliate 链接和文档地址最终落到哪里。它是生产流量配置。

更稳的做法是把 redirect rules 当成可发布配置：规则结构化，CI 做校验，预发环境展示真实行为，生产发布 versioned snapshot，并且在流量切过去之前准备好 rollback。

为什么重定向应该进入发布流程

工程团队已经会评审环境变量、数据库迁移、feature flag 和 middleware。影响 SEO、投放、支持和收入的重定向也应该进入同一套流程。

脆弱的流程通常是这样：

• SEO 维护一张 redirect map
• 工程把部分行复制到应用配置
• 市场在另一个工具里改活动目标页
• CMS 插件悄悄生成规则
• CDN 负责域名规范化
• 出问题时没人知道哪一层生效了

规则即代码的价值，不是一定要把所有东西写成某种格式，而是让 redirect map 变成可评审的发布资产。它可以是 YAML、JSON、Terraform、CSV 或 API payload。关键是有 owner、有测试、有回滚。

规则不该只有 source 和 destination

old_url 和 new_url 可以创建一条 redirect，但解释不了这条规则是否安全。

更好的规则契约会写清意图：

{
  "source": "/old-pricing",
  "destination": "/pricing",
  "status": 301,
  "match": "exact",
  "queryPolicy": "preserve_allowlist",
  "preserveQuery": ["utm_source", "utm_medium", "utm_campaign", "gclid"],
  "owner": "growth",
  "reason": "pricing page consolidation",
  "expiresAt": null
}

迁移、电商和活动场景还需要 priority、locale、country、device、batch、review status 和 fallback。

Google 对 redirects 的说明也围绕意图：这次移动是临时还是永久，搜索结果应该展示哪一个 URL。CI 不能替团队做业务判断，但可以阻止明显危险的组合发布出去。

API 同步比手动复制可靠

重定向经常不是从代码仓库里产生的。CMS 改 slug，商品下架，文档版本更新，SEO 代理交付迁移表，合作伙伴需要品牌链接，运营希望快速切 fallback。

如果这些来源都靠人工导入，规则迟早会漂移。

Redirect API 给团队一个更清晰的边界：

Cloudflare 可以通过 Rulesets API 创建 redirect rule。Next.js 和 Vercel 也支持配置式 redirects。这些都是执行层。真正难的是执行层之外的治理：校验、归属、预发、analytics 和 rollback。

CI 应该检查什么

重定向 CI 不应该只检查 JSON 能不能 parse，而应该验证行为。

值得检查的项：

• source path 重复
• destination 格式错误
• 缺 owner、reason 或 status
• wildcard 或 regex 覆盖 exact rule
• 有到期时间的活动却用了永久状态码
• 目标页返回 404、410、5xx 或意外 redirect
• redirect chain 过长
• loop
• UTM、click ID、coupon、partner ID 丢失
• country、device、header、query 条件没有 fallback
• 与其他 batch 冲突

高风险 URL 可以跑 request matrix：

source=/old-pricing
country=CN
device=desktop
query=?utm_source=google&gclid=test
expectedStatus=301
expectedDestination=/pricing?utm_source=google&gclid=test

这样上线前就能回答：这个请求到底会去哪里。

预发环境要展示最终路由

重定向的 staging 环境应该回答一个简单问题：这条 URL 带着这个请求上下文，在生产会发生什么？

最好展示：

• 命中的规则
• status code
• final destination
• query handling
• condition result
• competing rules
• chain length
• owner 和 batch
• 与当前 published snapshot 的 diff

GitHub Actions environments 可以在 deployment 前要求 reviewer。重定向也可以用同样模式：CI 校验，staging 给证据，production publish 等待正确负责人批准。

Rollback 是产品需求

回滚一条 redirect 不应该意味着半夜重新部署 origin app。

保留已发布 snapshot。给 import batch 打标签。把临时活动规则和永久迁移规则分开。紧急 override 必须可见，不能藏在 CDN 或 app middleware 里。

如果规则会影响搜索、广告、支持或收入，rollback 就不是附加功能。

UrlEdge 适合哪里

UrlEdge 适合那些想自动化 redirect，但不想每次 URL 变化都部署 origin app 的团队。

• API 用于 domains、rules、publishing 和 automation
• Redirect Management 用于 ownership、analytics、snapshots 和 rollback
• Bulk URL Management 用于迁移表和大批量导入
• Advanced Redirect Rules 用于 wildcard、regex、query 和条件
• Redirect Checker 用于路由和状态码 QA
• Collaboration 用于 SEO、市场、平台和代理商之间的审批

属于应用本身的小规则可以留在 app config。简单的 host 规范化可以交给 CDN。只要规则需要评审、证据、自动化和快速恢复，就应该考虑 Redirect API 和 rules as code。

FAQ

什么是 redirect rules as code？

把重定向规则放在结构化、可评审的格式里，并经过校验、预发、发布和回滚流程。

所有重定向都要放 Git 吗？

不需要。稳定迁移规则适合 Git。来自 CMS、电商目录、合作伙伴和内部工具的动态规则更适合 API sync。

CI/CD 可以直接发布 redirect 吗？

可以，但前提是有校验、预发证据、权限控制、高风险变更审批和 rollback。

参考资料

• Google Search Central: Redirects and Google Search
• Cloudflare Rules docs: Create a redirect rule via API
• Next.js docs: next.config.js redirects
• GitHub Docs: Managing environments for deployment