Cloudflare 免费版网站加速与 SEO 优化全流程：以我的博客为例

很多人和我一样把网站部署在 Cloudflare 上，这类网站无需服务器，但不像 WordPress 有完整的后台，部署完往往不知道 SEO 从哪下手。其实，在不改源码的前提下，Cloudflare 免费版里本身能帮上忙的 CDN 设置一共有5 项，这篇文章是给我自己博客（blog.1day.vip）配这套东西的完整记录。全篇按操作顺序走，每一步都是后台路径、具体动作、配完怎么验证。里面的数据都是我在这个站上实测的，命令可以直接抄。 想弄明白原理的，跳最后一节「原理与补充说明」。

一、先看一下：5 个选项有什么作用

二、第 0 步：把域名接进 Cloudflare

付费或是免费的域名都可以，但要先通过 NS 的方式接入 Cloudflare，一般都是免费计划

三、第 1 步：缓存规则 —— 收益最大的一项

Cloudflare 默认只缓静态文件（图片、CSS、JS），HTML 默认不缓。而 HTML 恰恰是 TTFB 的大头：访客第一次打开页面，请求要回源站取 HTML，这段往返就是慢的根源。让 HTML 也进边缘缓存，访客就近拿到，速度立竿见影。

操作

缓存 → 缓存规则 → 创建规则，

按下表填：

验证

抓一次页面，看响应头里的 cf-cache-status：

curl -s -D - -o /dev/null "https://你的域名/" | grep -i "cf-cache-status"

三个值的含义：

我的站实测（规则建好、缓存清过之后）：

/                             CF-Cache-Status: HIT   Age: 198
/posts                        CF-Cache-Status: HIT   Age: 177
/post/image-tools-ai-cutout   CF-Cache-Status: HIT   Age: 177
/robots.txt                   CF-Cache-Status: HIT   Age: 176
/sitemap.xml                  CF-Cache-Status: HIT   Age: 176

Age 是这条缓存在边缘已经放了多久（秒）。该 HIT 的 HIT，就对了。上面几个值都是三位数，是清过缓存之后的样子。

建规则不等于立刻生效在已有缓存上。缓存对象按它建立时的 TTL 走，改匹配条件或 TTL 都不会让它重算。所以规则配好后，如果抓到的 Age 已经是几万秒甚至十几万秒，说明边缘躺的还是旧对象，要么等它自己过期，要么手动清一次缓存（缓存 → 配置 → 清除缓存），新配置才会应用到之后重建的对象。

⚠️ 动态路径必须排除：带登录态、购物车、后台、搜索词的页面，一旦被缓存就会串号，A 用户看到 B 用户的内容。配规则时先排除、再缓存，顺序不能反。

判断标准一句话：换个访客来，这页内容会变吗？会变就排除，不变就缓。

为什么这条规则能压过源站自己的缓存头

我的站是 Workers 部署的，源站给每个响应都带了一个头：

cdn-cache-control: public, s-maxage=31536000

一年。对经常更新内容的站来说，这个值明显过长：文章早就在线上了，边缘发的还是上一批快照。

那就有一个问题：规则里设的 1 天，压得过源站的 1 年吗？

压得过。Cloudflare 官方文档写得很明确：Edge TTL 这个规则设置会覆盖 Cloudflare-CDN-Cache-Control / CDN-Cache-Control 里的指令。

但前提是 Edge TTL 那一栏得选「忽略缓存控制标头，使用此 TTL」。选「尊重源站」的话，还是源站的头说了算，那个一年照样生效。

另外注意，Edge TTL 只管边缘这一层，它不改下发出去的 Cache-Control。浏览器缓存多久是另一套设置管，两码事。

顺带检查一下静态资源的缓存头

抓一下你站的 CSS/JS，看 Cache-Control 是什么。资源路径每个站都不一样，先从首页里把真实的列出来：

curl -s "https://你的域名/" | grep -oE '(src|href)="[^"]+\.(css|js)"' | sort -u

拿列表里任意一个路径，替换下面这条命令的 URL：

curl -s -D - -o /dev/null "https://你的域名/assets/你的css文件.css" | grep -i "cache-control"

我的站实测结果是：

Cache-Control: public, max-age=0, must-revalidate

这个值偏保守。构建产物文件名里带了 hash（比如 index-DVdxQU0V.css），内容一变文件名就变，本来可以放心给一年长缓存（max-age=31536000, immutable）。现在设成 0，等于浏览器每次都要回访验证一遍，白白多一个来回。同一批文件的 CF-Cache-Status 都是 HIT，边缘缓存本身没问题，要调的就是这行浏览器 TTL。

Workers 或 Pages 部署的话，这行头由项目代码控制，要动源码才能改；用传统主机的话，在服务器配置里给静态资源加长缓存即可。

四、第 2 步：HTTP/3 —— 默认开启，确认一下

HTTP/2 在 Cloudflare 上默认就是开的，而且免费版关不掉，不用管。HTTP/3 基本也不用动：免费版默认就开启（反倒是付费版要自己开，挺反直觉）。

操作

速度 → 设置 → 协议优化，找到 HTTP/3 (with QUIC) 这一项，看开关是开还是关。开着就不用管，关着就打开。

验证

看响应里有没有 alt-svc 宣告：

curl -sI "https://你的域名/" | grep -i "alt-svc"

我的站实测：

alt-svc: h3=":443"; ma=86400

有 h3= 就说明边缘已经在向浏览器宣告支持 HTTP/3。支持 QUIC 的浏览器会自动优先走它，不支持的自动退回 HTTP/2，没有兼容风险。

五、第 3 步：Brotli —— 只能靠响应头确认

Brotli 比 gzip 压缩率更高，而 Cloudflare 早就免费给开上了：2024 年 5 月起对 Free 计划铺开，2024 年 8 月 15 日起所有站点默认启用，连开关本身都从后台撤掉了。

所以这一步没有「开」这个动作。你在后台找不到 Brotli 开关是正常的，别以为是版本问题。唯一的验证方式是看响应头。

验证

U=https://你的域名/
# 不压缩
curl -so /dev/null -w "%{size_download} B\n" "$U"
# gzip
curl -so /dev/null -w "%{size_download} B\n" -H "Accept-Encoding: gzip" "$U"
# brotli
curl -so /dev/null -w "%{size_download} B\n" -H "Accept-Encoding: br" "$U"

我的站实测（同一个首页）：

Brotli 比 gzip 又小了 15.2%，和官方说的「再压小 15%–20%」对得上。

再直接确认一下：

U=https://你的域名/
# 声明支持 br 和 gzip
curl -sI -H "Accept-Encoding: br,gzip" "$U" | grep -i content-encoding
# 只声明 gzip，做对照
curl -sI -H "Accept-Encoding: gzip" "$U" | grep -i content-encoding

Content-Encoding: br
Content-Encoding: gzip

两行对照着看：声明支持 br 它就回 br，只声明 gzip 它回 gzip。说明边缘确实在按你声明的压缩方式协商，Brotli 在干活。

六、第 4 步：始终使用 HTTPS

这一项跟速度无关，是给收录扫雷的。

操作

SSL/TLS → 边缘证书，往下滚找到「始终使用 HTTPS」，打开开关。

验证

curl -sI "http://你的域名/" | grep -iE "^(HTTP|Location)"
curl -sIL -o /dev/null -w "%{url_effective} %{http_code}\n" "http://你的域名/"

我的站实测：

HTTP/1.1 301 Moved Permanently
Location: https://blog.1day.vip/

https://blog.1day.vip/ 200

第一条看跳转声明，第二条看最终落点。两条都对了，说明强制跳转确实在生效。

顺手检查加密模式

同一区域里的 SSL/TLS → 概述，看加密模式选的是哪个：

模式	含义	建议
灵活（Flexible）	访客到 CF 是 https，CF 到源站走 http，明文	别用
完全（严格）Full (Strict)	两端都加密，且校验源站证书	用这个

七、第 5 步：图片优化 —— 免费版要绕道

先避坑：Cloudflare 的图片压缩功能叫 Polish，免费版没有，是 Pro 及以上的功能。

免费版做图片优化，就三件事。

一是源头先压好。 图片上传前先压一遍、去掉 EXIF 元数据。这一步最实在，比任何 CDN 都管用。

二是换 WebP 或 AVIF。

转换不难，用我部署的图片工具就行，也可以自己免费部署：https://img.1day.vip/。注意 WebP / AVIF 老浏览器不支持，源图最好保留一份原格式兜底。

三是尺寸给对。 别让 2000px 的图去填 400px 的位，上传前裁到实际显示尺寸。

我自己是用图床解决图片上传问题，如果你的网站是附件的形式，可以把图片压缩的功能放到网站前端解决。

八、原理与补充说明

下面这些跟「怎么点」无关，但知道了能少走弯路。

8.1 为什么 CDN 能帮到 SEO

CDN 不能直接提排名，谷歌没有「用了 CDN 就加分」这条规则。它走三条路间接帮忙。

一是压 TTFB。它取决于访客和服务器之间的物理距离，CDN 把内容推到离访客近的节点，几百毫秒掉到几十毫秒是常事。TTFB 是 LCP 的一部分。

二是改善 Core Web Vitals。三项里 CDN 主要改善 LCP（首屏渲染速度）和 INP（交互响应速度）；CLS（元素跳动）得靠前端给图片、广告位预留尺寸。

三是省抓取预算。站慢、超时多，谷歌来爬的频率就降，新页面收录变慢。

8.2 缓存：什么该缓、什么不能缓

静态的缓，动态的不缓。图片、CSS、JS、字体、公开内容页可以缓；带登录态的、带购物车的、后台、搜索结果页必须排除。

判断标准一句话：换个访客来，内容会变吗？

8.3 HTTP/1.1、HTTP/2、HTTP/3 有什么区别

HTTP/2 建在 TCP 上，握手要几个往返；HTTP/3 用基于 UDP 的 QUIC，握手合并、一次连接就能跑，丢包也不堵管道，弱网和网络切换时优势明显。

结尾

这 5 项配完就结束了，剩下的是交给时间：谷歌重爬、重算分数都要几天到几周，别隔一天就去看排名。整个流程是我查了资料后自己完整的跑了一遍，原理是靠 AI 补充的。