SEO 技术问题里，有一类特别让人头大：你明明知道怎么修，但修复需要改后端、改路由、改模板，排期一拖就是几周。比如老 URL 要 301 到新 URL、全站要统一尾斜杠、某些参数页要规范化、不同语言路径要加 hreflang。你要是每次都等开发改，SEO 的节奏就会被拖断。

Cloudflare Workers 提供了一种更靠前的解决方式：把一部分规则放到边缘层（Edge）执行。你可以把它理解为：请求到达你服务器之前，先经过 Cloudflare 这道关口；你在关口写了规则，就能在不动后端的情况下完成很多 SEO 杂活。这就是所谓的 Edge SEO。

Cloudflare Workers 官方文档页面（示意）

图：Cloudflare Workers 官方文档（公开页面，用于说明 Workers 属于 Cloudflare 的边缘计算能力）。

Edge SEO 适合解决什么？

Edge SEO 最适合解决规则型问题：同一类 URL 需要同一类处理，并且你希望快速上线、可回滚、可逐步扩展。比如迁移时的 301、全站 https 强制、URL 规范化、某些目录统一跳转、给特定路径加响应头。它不适合做复杂业务逻辑，也不适合替代后端长期维护；它更像一个快速修复层。

三个最常见的落地场景

  1. 批量重定向：改版/换域名后把旧 URL 301 到新 URL，避免流量断崖。配合：迁移 301 检查清单。
  2. URL 规范化：统一带不带尾斜杠、统一大小写、统一 www 版本，减少重复与内耗。
  3. 语言/国家规则：按路径返回不同 hreflang，或给某些语言版本加不同的缓存/头部策略。

最小可用落地：先从重定向映射表开始

如果你从没写过 Workers，建议从最小风险的场景开始：用一个映射表做 301。先把 20～50 条最关键的旧 URL 与新 URL 列出来（优先处理有流量、有外链、有转化的页面），先上线这一小段，确认无误再扩大范围。这样比一次性上几千条安全太多。

上线后一定要做验收：用浏览器和 curl 检查状态码是否是 301，Location 是否正确，是否存在多跳或循环。迁移翻车往往不是因为不会写规则，而是因为没有严谨验收。

常见坑：Edge SEO 也会翻车（提前避雷）

  • 规则过宽：一个正则写错，整个目录都被重定向。
  • 重定向循环：A → B，B 的规则又把它带回 A。
  • 缓存干扰：上线后你以为没生效，其实是缓存没清或浏览器缓存导致观察偏差。

如果你只是想先把 Cloudflare 当 CDN 用，把速度与缓存打好底层，可以先看这篇更运营可执行的入门：Cloudflare + WordPress 的 CDN/SEO 基础配置（即使不是 WordPress，很多思路也通用）。

延伸阅读

参考资料