CDN 缓存把旧页面喂给爬虫两周边缘缓存头对收录更新的影响与配置适用读者负责外贸独立站的开发者与站长达人正在用 Cloudflare 或 Nginx 反向代理做加速发现改版后 Google 收录迟迟不更新想从 HTTP 缓存层面排查收录更新延迟的读者。一、问题是怎么被发现的今年 6 月初我们接手一个做工业配件出口的独立站Magento 架构前面套了一层 Cloudflare 免费版。客户 5 月 20 日完成了一次大改版商品页的 SEO 标题全部重写、十几款主力商品调了价格、新增了 60 多个 SKU 页面。按以往经验Google 对这种量级的站点标题更新一般一周内就能在收录里反映出来。结果到了第 10 天用site:语法抽查了 30 个商品页收录快照里的标题还是旧版。Google Search ConsoleGSC里「网页索引编制」报告显示这些页面状态是「已编入索引」但「上次抓取时间」大多停在 5 月 22 日前后——也就是说抓取确实发生了抓到的却是旧内容Google 自然认为页面没变不值得重新收录。真正定位到问题是在 6 月 3 日。我用 GSC 的「网址检查」功能对其中一个商品页点了「测试实际网址」实时抓取返回的 HTML 里title和价格字段全是改版前的旧值。源站当时已经确认是新版内容那么中间只有一个嫌疑人CDN 边缘缓存。结论先说这不是 Google 的问题是边缘节点把旧页面当成新页面连续两周喂给了爬虫。二、排查过程从响应头到日志2.1 curl 看缓存命中状态排查缓存问题curl -I是第一工具。对同一个商品页连续请求两次# 环境要求任意带 curl 的终端Windows 10 自带 curl.exe 即可# 第一次请求观察缓存命中标记与缓存头curl-sIhttps://www.example-parts.com/products/flange-bolt-m12\-HUser-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; http://www.google.com/bot.html)# 第二次请求同样的 URL对比 CF-Cache-Status 是否变为 HITcurl-sIhttps://www.example-parts.com/products/flange-bolt-m12两次响应头里的关键信息响应头实际返回值说明CF-Cache-StatusHIT边缘节点命中内容来自缓存而非源站Cache-Controlpublic, max-age604800, s-maxage2592000HTML 被允许缓存 7 天CDN 边缘存 30 天Last-Modified缺失爬虫无法发起条件请求校验新旧ETag缺失同上连 304 协商缓存的基础都没有Age86423这份缓存已经在边缘节点存活近 24 小时问题很清楚了。max-age604800配在 HTML 上意味着边缘节点最长 7 天才会回源取一次新内容而源站响应里居然没有Last-Modified和ETag即使边缘缓存过期回源也无法利用条件请求Conditional Request机制。更糟的是Cloudflare 命中缓存时直接返回 200 加缓存体Googlebot 拿到的永远是旧快照连发起 If-Modified-Since 验证的机会都没有。2.2 X-Cache 与 Nginx 场景的对照我们另一批客户的站点是 Nginxproxy_cache自建的边缘层排查思路一样只是命中的判断标记换成X-Cache-Status# Nginx 自建缓存层的站点检查 X-Cache-Status 头# 需要在 nginx.conf 的 add_header 中暴露 $upstream_cache_statuscurl-sIhttps://shop.another-site.com/products/valve-actuator|grep-iEx-cache|cache-control|etag|last-modified返回里X-Cache-Status: HIT同样配着proxy_cache_valid 200 7d同样没有给 HTML 关闭缓存。两套架构同一个病根。2.3 GSC 实时抓取与日志的 304 占比第二个证据来自服务器访问日志。我写了个简单的统计脚本把 5 月 20 日到 6 月 3 日的日志里 Googlebot 的请求按状态码分组时间段Googlebot 请求总数200 占比304 占比收录标题更新延迟5 月 20 日 - 6 月 3 日修复前3,18297.4%2.6%约 12 天6 月 4 日 - 6 月 17 日修复后3,40541.8%58.2%1 天以内注意这是单站观测数据样本只有这一个站点不代表行业普遍水平。但方向很有说服力修复前 97% 的爬虫请求都拿到 200 全量响应——全是从边缘缓存吐出来的旧 HTML修复后 304 占比冲到 58%说明爬虫开始大量用条件请求校验页面没变化就省掉传输页面变了收到 200 或新校验结果就立刻更新收录。抓取配额Crawl Budget没有变多但有效抓取的质量完全不同了。这也是网站优化里一个常被忽视的点让爬虫拿到正确的新鲜内容比单纯追求抓取频率重要得多。三、原理剖析抓取、缓存、索引之间的更新时延链路搜索引擎更新一条收录链路是「调度器决定抓取 → 抓取器请求页面 → 解析内容与旧快照比对 → 有实质变化才进入重索引队列」。这条链路里每一步都依赖一个前提抓取器请求到的内容必须能代表源站的当前状态。CDN 缓存介入后这个前提被破坏了。梳理一遍完整链路源站CDN 边缘节点Googlebot源站CDN 边缘节点Googlebotalt[缓存命中且未过期max-age 内][缓存过期]GET /products/xxx200 旧 HTML不回源GET带 If-Modified-Since/If-None-Match304 或 200 新 HTML200可能仍是 TTL 内的旧内容与索引快照比对无变化则不重索引关键在第一个分支只要 TTL 没过期爬虫的请求根本到不了源站。HTML 的max-age604800意味着在最长 7 天的窗口里无论源站改了多少次内容所有访问者——包括爬虫——拿到的都是同一份旧页面。改版日 5 月 20 日写入缓存的旧 HTML会一直存活到 5 月 27 日左右下一个 7 天窗口又是同样的循环。两周看不到更新时间线完全对得上。再看条件请求为什么失效。HTTP 缓存协商依赖ETag实体标签Entity Tag或Last-Modified爬虫第二次请求时带上If-None-Match或If-Modified-Since源站比对后如果内容没变就返回 304只回头部不回正文。但这里有两个坑同时存在源站响应缺ETag和Last-Modified爬虫没有凭证可带每次只能全量请求边缘缓存命中时直接返回 200校验动作被边缘层短路了Cache-Control: public又允许缓存器自作主张跳过回源验证。这就是「缓存命中掩盖内容更新」的机制本质缓存层替爬虫做了「内容没变」的判断但它的判断依据是时间TTL不是内容本身。TTL 是站长配的一旦配得比内容更新周期长爬虫的世界就比真实世界滞后了。MDN 的 HTTP 缓存文档里对stale-while-revalidate的描述恰好给出了折中方案允许先返回旧内容保证速度同时异步回源刷新——对爬虫场景来说这能把「旧内容窗口」压缩到秒级。四、修复配置HTML 短缓存 静态资源长缓存指纹化修复思路是分层的HTML 是收录的载体必须新鲜CSS/JS/图片变化频率低且带指纹可以放心长缓存。两层策略分开配。4.1 Nginx 源站配置# 环境Nginx 1.24作为 Magento 源站的前置层 server { listen 443 ssl; server_name www.example-parts.com; location / { proxy_pass http://magento_backend; # HTML 与动态路径禁止源站输出长缓存头 # 交给 CDN 用 s-maxage 控制边缘短缓存 add_header Cache-Control public, s-maxage120, max-age0, must-revalidate always; # 保留实体校验头让条件请求304能够生效 # etag on 与 last_modified 系列是 nginx 默认值显式写出防止被覆盖 etag on; last_modified compiling; } # 静态资源带内容指纹版本号/哈希文件名可放心长缓存 location ~* \.(js|css|png|jpg|jpeg|webp|woff2)$ { proxy_pass http://magento_backend; # 一年缓存 immutable浏览器和 CDN 都不回头验证 add_header Cache-Control public, max-age31536000, immutable always; } }这里有个容易踩的细节s-maxage只对共享缓存器CDN、代理生效max-age0, must-revalidate约束的是浏览器端不要缓存 HTML。这样即使边缘出了问题用户浏览器也不会本地留存旧页面。4.2 Cloudflare 面板配置对照Cloudflare 免费版默认不缓存 HTML只缓存静态扩展名我们的旧缓存头之所以生效是前任运维加了一条「Cache Everything」页面规则TTL 还被「Edge Cache TTL」设置顶到了 30 天。修改动作配置项修复前修复后作用Cache Everything 页面规则全站启用移除改用 Cache Rules避免无差别缓存 HTMLEdge Cache TTL30 天遵循源站Respect Existing Headers)边缘 TTL 跟随 s-maxage120Browser Cache TTL4 小时遵循源站浏览器侧不再叠加缓存源站 Cache-Controlmax-age604800s-maxage120 must-revalidateHTML 两分钟内过期回源静态资源规则默认max-age31536000 指纹文件名长缓存不回源改完后我又在 Cache Rules 里对/products/*显式加了一条缓存状态可用但必须stale-while-revalidate60即过期后允许先回旧内容撑 60 秒同时后台回源刷新。爬虫的高频抓取由此几乎全部命中边缘源站压力没涨新鲜度却上来了。另外建议保留两个验证手段一是 Cloudflare 的CF-Cache-Status头改版后应当看到 MISS → HIT 的快速交替两分钟 TTL 下正常流量就能观察到循环二是 Nginx 场景下$upstream_cache_status配合REVALIDATED状态能确认条件请求真的在工作。把修复前后的完整状态放在一起对比能更直观地看到每一层的变化对比维度修复前修复后HTML 的 Cache-Control 值public, max-age604800, s-maxage2592000public, s-maxage120, max-age0, must-revalidate边缘 TTL30 天Edge Cache TTL 顶满120 秒遵循源站 s-maxage浏览器 TTL4 小时Browser Cache TTL不缓存max-age0 must-revalidateETag / Last-Modified 是否输出缺失正常输出etag on last_modifiedGooglebot 命中 200 占比97.4%41.8%304 占比2.6%58.2%收录更新延迟天数约 12 天1 天以内其中 200/304 占比与收录延迟数据来自第二节 2.3 的日志观测修复前 5 月 20 日 - 6 月 3 日修复后 6 月 4 日 - 6 月 17 日。核心变化一句话概括缓存头从「长缓存 无校验头」翻转为「短缓存 校验头」爬虫的请求从「全量拿旧 200」变成「增量校验拿 304」收录更新延迟从约 12 天压缩到 1 天以内。五、修复后的缓存策略分层把最终生效的策略画成一张分层图方便对照检查自己的站点HTML 动态页JS/CSS/图片 指纹文件未命中命中没变变了用户 / 爬虫请求请求的是 HTML 还是静态资源?边缘缓存 s-maxage120边缘浏览器长缓存 max-age 一年 immutable缓存是否命中?回源带条件请求 If-None-Match返回 200 缓存内容 Age 小于 120 秒源站内容变了吗?返回 304 边缘继续用旧缓存返回 200 新 HTML 刷新边缘TTL 过期后 stale-while-revalidate 异步刷新爬虫解析新内容 进入重索引 收录更新修复一周后复查GSC 里抽查的 30 个商品页标题全部更新为新版「上次抓取时间」集中在改版后的 24 小时内。源站回源请求量只上升了约 18%从日志统计因为静态资源的长缓存完全没动只有 HTML 层多回了几次源。这笔账是划算的——收录更新延迟从约 12 天压缩到 1 天以内对促销季频繁调价的独立站来说这意味着价格页面的收录能跟上实际售价。六、误区澄清与收尾回顾整条排查链路改版后收录两周不更新根因不在 Google而在边缘节点把旧 HTML 当成新页面喂给了爬虫——HTML 被配了 7 天长缓存源站又缺ETag和Last-Modified条件请求彻底失效。修复路径也很清晰HTML 走短缓存s-maxage120 保留校验头静态资源走长缓存指纹化让爬虫每次都能拿到新鲜内容。这套思路在实操中常被几个误区带偏这里逐一澄清。误区一「CDN 缓存只影响用户不影响 SEO」错误认知缓存是给访客加速用的搜索引擎抓取走的是另一套逻辑不受缓存影响。实际情况Googlebot 和普通访客走的是同一条边缘链路缓存命中时返回的 200 全量响应喂给谁都是同一份旧 HTML。缓存头配错了收录滞后的是搜索引擎不是用户。正确做法把爬虫当成「最高频、最挑剔的访客」来对待HTML 用短缓存 条件请求确保爬虫每次回源都能校验到最新内容。误区二「把 HTML 缓存全部关掉最安全」错误认知既然缓存会喂旧内容那干脆完全禁掉 HTML 缓存一劳永逸。实际情况完全禁缓存会让每次爬虫请求都全量回源抓取配额Crawl Budget大量消耗在重复传输上高频抓取反而变慢源站压力也上去了。正确做法用「短缓存 条件请求」的组合——s-maxage120让边缘短暂缓存ETag/Last-Modified让爬虫用 304 增量校验。页面没变就省掉传输变了就立刻拿到新内容新鲜度与配额兼顾。误区三「配好 Cache-Control 就万事大吉」错误认知只要Cache-Control写对了缓存策略就生效了不用再管。实际情况Cache-Control只是第一步。如果源站没输出ETag/Last-Modified或者中间层安全插件、旧页面规则、proxy_hide_header把这些校验头剥掉了304 协商永远触发不了爬虫只能全量拉取旧快照。正确做法配置完成后必须验证——curl 源站确认校验头存在再带If-None-Match请求确认能拿到 304同时检查边缘层没有剥离这些头。回到开头那个案例客户改版后收录两周不动不是 Google 变懒了而是边缘缓存替爬虫做了「内容没变」的判断判断依据是 TTL 而不是内容本身。把 HTML 缓存从 7 天压到 120 秒、补上校验头之后30 个商品页的标题在 24 小时内全部更新。缓存头这件事配对了是 SEO 的稳定地基配错了就是收录更新的隐形杀手——值得每个独立站站长花十分钟检查一遍。七、常见问题FAQ7.1 Cloudflare 免费版如何确认 Cache Rules 生效Cache Rules 是 Cloudflare 免费版可用的功能但配置后需要确认它真的接管了流量而不是被旧的页面规则或默认行为覆盖。操作步骤如下登录 Cloudflare 控制台进入你的域名左侧菜单找到Rules → Cache Rules。确认你的规则处于Enabled状态且匹配条件如Hostname equals www.example-parts.com加URI Path starts with /products/与预期一致。打开浏览器的开发者工具或直接用 curl对目标 URL 发起请求重点看响应头里的CF-Cache-Status和Cache-Control。验证命令# 连续请求两次观察 CF-Cache-Status 是否出现 MISS → HIT 交替curl-sIhttps://www.example-parts.com/products/flange-bolt-m12|grep-iEcf-cache-status|cache-controlcurl-sIhttps://www.example-parts.com/products/flange-bolt-m12|grep-iEcf-cache-status|cache-control如果Cache-Control里出现s-maxage120且CF-Cache-Status在两次请求间从MISS变为HIT说明 Cache Rules 已生效。若始终是DYNAMIC或BYPASS检查是否还有更高优先级的页面规则Page Rules在拦截或规则里的表达式写错了。7.2 Nginx 源站如何验证 ETag 和 Last-Modified 是否输出Nginx 默认开启etag on和last_modified但很多情况下会被上层代理、安全模块或显式配置覆盖掉。验证方法很简单直接对源站发起请求看响应头# 直接请求源站绕过 CDN检查实体校验头是否存在curl-sIhttp://源站IP或域名/products/flange-bolt-m12\-HHost: www.example-parts.com|grep-iEetag|last-modified|cache-control如果输出里能看到ETag: ...和Last-Modified: ...说明源站正常输出。若缺失检查 nginx 配置里是否有人显式写了etag off;或last_modified off;或者用了proxy_hide_header把这些头剥掉了。更进一步的验证是发起条件请求确认能拿到 304# 先取一次 ETag再带上 If-None-Match 请求观察是否返回 304ETAG$(curl-sIhttp://源站IP/products/flange-bolt-m12-HHost: www.example-parts.com|grep-ietag|awk-F: {print $2}|tr-d\r)curl-sIhttp://源站IP/products/flange-bolt-m12\-HHost: www.example-parts.com\-HIf-None-Match:$ETAG|head-n1返回HTTP/1.1 304 Not Modified即代表条件请求链路是通的。7.3 如果源站是 Apache配置有何不同Apache 的缓存头控制思路与 Nginx 一致但写法不同。核心差异在于Apache 用mod_headers设置Cache-Control用mod_expires或FileETag控制实体校验头。以.htaccess或虚拟主机配置为例# 启用必要的模块通常在 httpd.conf 中已加载 # LoadModule headers_module modules/mod_headers.so # LoadModule expires_module modules/mod_expires.so IfModule mod_headers.c # HTML 与动态路径短缓存 禁止浏览器缓存 FilesMatch \.(php|html?)$ Header set Cache-Control public, s-maxage120, max-age0, must-revalidate /FilesMatch # 静态资源长缓存 immutable FilesMatch \.(js|css|png|jpg|jpeg|webp|woff2)$ Header set Cache-Control public, max-age31536000, immutable /FilesMatch /IfModule # 确保 ETag 输出Apache 默认开启但可显式声明 FileETag MTime Size验证命令与 Nginx 场景相同直接 curl 源站看响应头即可curl-sIhttp://源站IP/products/flange-bolt-m12-HHost: www.example-parts.com|grep-iEetag|last-modified|cache-control需要注意两点一是 Apache 的FileETag默认基于 inode、MTime 和 Size多机负载均衡时建议改成MTime Size避免不同机器生成不同 ETag 导致 304 失效二是如果用了mod_deflate压缩要确认 ETag 是在压缩前还是压缩后生成的避免强校验失败。三个最常见的误区写在最后提醒一下「CDN 缓存只影响用户不影响 SEO」——错。Googlebot 和普通访客走的是同一条边缘链路缓存喂给谁旧内容收录就滞后谁的。「把 HTML 缓存全部关掉最安全」——过犹不及。完全禁缓存会让抓取配额消耗在全量回源上高频抓取反而变慢。短缓存加条件请求才是兼顾新鲜度与配额的做法。「配了 Cache-Control 就完事了」——还要验证ETag/Last-Modified真的输出去了且中间层没有剥离它们。有些安全插件和旧的页面规则会顺手把这些头删掉304 就永远触发不了。Cache-Control 配置属于网站优化SEO里偏基础但收益稳定的工程项它的价值不在单点排名而在保证「源站改了什么搜索引擎就能多快看到什么」。这个能力往后也是 AI 搜索场景的地基——生成式引擎优化Generative Engine Optimization, GEO同样依赖引擎能抓到最新页面缓存头配错了面向 AI 引擎做再多语义优化也是白搭。这一层先夯实后面的路才好走。如果你也在做外贸独立站欢迎在评论区聊聊你们站点 HTML 的缓存策略是怎么配的尤其是 Cloudflare 免费版用户的 Cache Rules 实践。为什么这对 AI 搜索同样重要上面这套缓存逻辑不只对 Google 收录有效对 AI 搜索引擎同样成立。ChatGPT 联网检索、Perplexity 这类引擎在抓取网页时走的也是标准的 HTTP 抓取链路同样依赖Cache-Control、ETag、Last-Modified这些缓存头来判断内容的新鲜度。它们不会因为你做了语义优化就绕过缓存层——缓存头配错了AI 引擎拿到的同样是旧页面。这直接影响生成式引擎优化Generative Engine Optimization, GEO的效果。GEO 的核心是让 AI 引擎能抓到你最新、最准确的内容并据此生成回答。如果边缘节点把改版前的旧 HTML 喂给了 AI 爬虫那么无论你在页面里埋了多少结构化数据、写了多好的语义描述AI 引擎引用的依然是过期信息回答质量自然打折扣。缓存头是 GEO 的地基地基不稳上层优化都是白搭。针对 AI 引擎建议在现有配置上再补三条缩短 HTML 的 TTL——把s-maxage压到 120 秒甚至更短让 AI 爬虫高频抓取时能更快回源拿到新内容而不是长期命中旧缓存。确保ETag和Last-Modified正常输出——AI 引擎同样会用条件请求做增量抓取校验头缺失会让它们每次都全量拉取既慢又容易拿到旧快照。避免边缘层剥离校验头——检查 Cloudflare 页面规则、安全插件或 Nginx 的proxy_hide_header确认没有把ETag/Last-Modified顺手删掉否则 304 协商永远触发不了。这三条和前面给 Google 的配置完全一致一套配置同时服务两类引擎成本几乎为零收益却覆盖了 SEO 和 GEO 两条线。参考与延伸Cloudflare 官方文档Cache Control缓存控制头与 Edge Cache TTL 行为说明—— https://developers.cloudflare.com/cache/concepts/cache-control/Nginx 官方文档ngx_http_proxy_module 的 proxy_cache 指令含 proxy_cache_valid 与 $upstream_cache_status—— https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cacheMDN Web DocsHTTP 缓存Cache-Control、ETag、条件请求与 stale-while-revalidate 详解—— https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CachingSEO、网站优化、独立站自然流量、CDN 缓存、Cache-Control、ETag、收录更新延迟、条件请求MDN Web DocsHTTP 缓存Cache-Control、ETag、条件请求与 stale-while-revalidate 详解—— https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CachingSEO、网站优化、独立站自然流量、CDN 缓存、Cache-Control、ETag、收录更新延迟、条件请求
CDN 缓存把旧页面喂给爬虫两周：边缘缓存头对收录更新的影响与配置
CDN 缓存把旧页面喂给爬虫两周边缘缓存头对收录更新的影响与配置适用读者负责外贸独立站的开发者与站长达人正在用 Cloudflare 或 Nginx 反向代理做加速发现改版后 Google 收录迟迟不更新想从 HTTP 缓存层面排查收录更新延迟的读者。一、问题是怎么被发现的今年 6 月初我们接手一个做工业配件出口的独立站Magento 架构前面套了一层 Cloudflare 免费版。客户 5 月 20 日完成了一次大改版商品页的 SEO 标题全部重写、十几款主力商品调了价格、新增了 60 多个 SKU 页面。按以往经验Google 对这种量级的站点标题更新一般一周内就能在收录里反映出来。结果到了第 10 天用site:语法抽查了 30 个商品页收录快照里的标题还是旧版。Google Search ConsoleGSC里「网页索引编制」报告显示这些页面状态是「已编入索引」但「上次抓取时间」大多停在 5 月 22 日前后——也就是说抓取确实发生了抓到的却是旧内容Google 自然认为页面没变不值得重新收录。真正定位到问题是在 6 月 3 日。我用 GSC 的「网址检查」功能对其中一个商品页点了「测试实际网址」实时抓取返回的 HTML 里title和价格字段全是改版前的旧值。源站当时已经确认是新版内容那么中间只有一个嫌疑人CDN 边缘缓存。结论先说这不是 Google 的问题是边缘节点把旧页面当成新页面连续两周喂给了爬虫。二、排查过程从响应头到日志2.1 curl 看缓存命中状态排查缓存问题curl -I是第一工具。对同一个商品页连续请求两次# 环境要求任意带 curl 的终端Windows 10 自带 curl.exe 即可# 第一次请求观察缓存命中标记与缓存头curl-sIhttps://www.example-parts.com/products/flange-bolt-m12\-HUser-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; http://www.google.com/bot.html)# 第二次请求同样的 URL对比 CF-Cache-Status 是否变为 HITcurl-sIhttps://www.example-parts.com/products/flange-bolt-m12两次响应头里的关键信息响应头实际返回值说明CF-Cache-StatusHIT边缘节点命中内容来自缓存而非源站Cache-Controlpublic, max-age604800, s-maxage2592000HTML 被允许缓存 7 天CDN 边缘存 30 天Last-Modified缺失爬虫无法发起条件请求校验新旧ETag缺失同上连 304 协商缓存的基础都没有Age86423这份缓存已经在边缘节点存活近 24 小时问题很清楚了。max-age604800配在 HTML 上意味着边缘节点最长 7 天才会回源取一次新内容而源站响应里居然没有Last-Modified和ETag即使边缘缓存过期回源也无法利用条件请求Conditional Request机制。更糟的是Cloudflare 命中缓存时直接返回 200 加缓存体Googlebot 拿到的永远是旧快照连发起 If-Modified-Since 验证的机会都没有。2.2 X-Cache 与 Nginx 场景的对照我们另一批客户的站点是 Nginxproxy_cache自建的边缘层排查思路一样只是命中的判断标记换成X-Cache-Status# Nginx 自建缓存层的站点检查 X-Cache-Status 头# 需要在 nginx.conf 的 add_header 中暴露 $upstream_cache_statuscurl-sIhttps://shop.another-site.com/products/valve-actuator|grep-iEx-cache|cache-control|etag|last-modified返回里X-Cache-Status: HIT同样配着proxy_cache_valid 200 7d同样没有给 HTML 关闭缓存。两套架构同一个病根。2.3 GSC 实时抓取与日志的 304 占比第二个证据来自服务器访问日志。我写了个简单的统计脚本把 5 月 20 日到 6 月 3 日的日志里 Googlebot 的请求按状态码分组时间段Googlebot 请求总数200 占比304 占比收录标题更新延迟5 月 20 日 - 6 月 3 日修复前3,18297.4%2.6%约 12 天6 月 4 日 - 6 月 17 日修复后3,40541.8%58.2%1 天以内注意这是单站观测数据样本只有这一个站点不代表行业普遍水平。但方向很有说服力修复前 97% 的爬虫请求都拿到 200 全量响应——全是从边缘缓存吐出来的旧 HTML修复后 304 占比冲到 58%说明爬虫开始大量用条件请求校验页面没变化就省掉传输页面变了收到 200 或新校验结果就立刻更新收录。抓取配额Crawl Budget没有变多但有效抓取的质量完全不同了。这也是网站优化里一个常被忽视的点让爬虫拿到正确的新鲜内容比单纯追求抓取频率重要得多。三、原理剖析抓取、缓存、索引之间的更新时延链路搜索引擎更新一条收录链路是「调度器决定抓取 → 抓取器请求页面 → 解析内容与旧快照比对 → 有实质变化才进入重索引队列」。这条链路里每一步都依赖一个前提抓取器请求到的内容必须能代表源站的当前状态。CDN 缓存介入后这个前提被破坏了。梳理一遍完整链路源站CDN 边缘节点Googlebot源站CDN 边缘节点Googlebotalt[缓存命中且未过期max-age 内][缓存过期]GET /products/xxx200 旧 HTML不回源GET带 If-Modified-Since/If-None-Match304 或 200 新 HTML200可能仍是 TTL 内的旧内容与索引快照比对无变化则不重索引关键在第一个分支只要 TTL 没过期爬虫的请求根本到不了源站。HTML 的max-age604800意味着在最长 7 天的窗口里无论源站改了多少次内容所有访问者——包括爬虫——拿到的都是同一份旧页面。改版日 5 月 20 日写入缓存的旧 HTML会一直存活到 5 月 27 日左右下一个 7 天窗口又是同样的循环。两周看不到更新时间线完全对得上。再看条件请求为什么失效。HTTP 缓存协商依赖ETag实体标签Entity Tag或Last-Modified爬虫第二次请求时带上If-None-Match或If-Modified-Since源站比对后如果内容没变就返回 304只回头部不回正文。但这里有两个坑同时存在源站响应缺ETag和Last-Modified爬虫没有凭证可带每次只能全量请求边缘缓存命中时直接返回 200校验动作被边缘层短路了Cache-Control: public又允许缓存器自作主张跳过回源验证。这就是「缓存命中掩盖内容更新」的机制本质缓存层替爬虫做了「内容没变」的判断但它的判断依据是时间TTL不是内容本身。TTL 是站长配的一旦配得比内容更新周期长爬虫的世界就比真实世界滞后了。MDN 的 HTTP 缓存文档里对stale-while-revalidate的描述恰好给出了折中方案允许先返回旧内容保证速度同时异步回源刷新——对爬虫场景来说这能把「旧内容窗口」压缩到秒级。四、修复配置HTML 短缓存 静态资源长缓存指纹化修复思路是分层的HTML 是收录的载体必须新鲜CSS/JS/图片变化频率低且带指纹可以放心长缓存。两层策略分开配。4.1 Nginx 源站配置# 环境Nginx 1.24作为 Magento 源站的前置层 server { listen 443 ssl; server_name www.example-parts.com; location / { proxy_pass http://magento_backend; # HTML 与动态路径禁止源站输出长缓存头 # 交给 CDN 用 s-maxage 控制边缘短缓存 add_header Cache-Control public, s-maxage120, max-age0, must-revalidate always; # 保留实体校验头让条件请求304能够生效 # etag on 与 last_modified 系列是 nginx 默认值显式写出防止被覆盖 etag on; last_modified compiling; } # 静态资源带内容指纹版本号/哈希文件名可放心长缓存 location ~* \.(js|css|png|jpg|jpeg|webp|woff2)$ { proxy_pass http://magento_backend; # 一年缓存 immutable浏览器和 CDN 都不回头验证 add_header Cache-Control public, max-age31536000, immutable always; } }这里有个容易踩的细节s-maxage只对共享缓存器CDN、代理生效max-age0, must-revalidate约束的是浏览器端不要缓存 HTML。这样即使边缘出了问题用户浏览器也不会本地留存旧页面。4.2 Cloudflare 面板配置对照Cloudflare 免费版默认不缓存 HTML只缓存静态扩展名我们的旧缓存头之所以生效是前任运维加了一条「Cache Everything」页面规则TTL 还被「Edge Cache TTL」设置顶到了 30 天。修改动作配置项修复前修复后作用Cache Everything 页面规则全站启用移除改用 Cache Rules避免无差别缓存 HTMLEdge Cache TTL30 天遵循源站Respect Existing Headers)边缘 TTL 跟随 s-maxage120Browser Cache TTL4 小时遵循源站浏览器侧不再叠加缓存源站 Cache-Controlmax-age604800s-maxage120 must-revalidateHTML 两分钟内过期回源静态资源规则默认max-age31536000 指纹文件名长缓存不回源改完后我又在 Cache Rules 里对/products/*显式加了一条缓存状态可用但必须stale-while-revalidate60即过期后允许先回旧内容撑 60 秒同时后台回源刷新。爬虫的高频抓取由此几乎全部命中边缘源站压力没涨新鲜度却上来了。另外建议保留两个验证手段一是 Cloudflare 的CF-Cache-Status头改版后应当看到 MISS → HIT 的快速交替两分钟 TTL 下正常流量就能观察到循环二是 Nginx 场景下$upstream_cache_status配合REVALIDATED状态能确认条件请求真的在工作。把修复前后的完整状态放在一起对比能更直观地看到每一层的变化对比维度修复前修复后HTML 的 Cache-Control 值public, max-age604800, s-maxage2592000public, s-maxage120, max-age0, must-revalidate边缘 TTL30 天Edge Cache TTL 顶满120 秒遵循源站 s-maxage浏览器 TTL4 小时Browser Cache TTL不缓存max-age0 must-revalidateETag / Last-Modified 是否输出缺失正常输出etag on last_modifiedGooglebot 命中 200 占比97.4%41.8%304 占比2.6%58.2%收录更新延迟天数约 12 天1 天以内其中 200/304 占比与收录延迟数据来自第二节 2.3 的日志观测修复前 5 月 20 日 - 6 月 3 日修复后 6 月 4 日 - 6 月 17 日。核心变化一句话概括缓存头从「长缓存 无校验头」翻转为「短缓存 校验头」爬虫的请求从「全量拿旧 200」变成「增量校验拿 304」收录更新延迟从约 12 天压缩到 1 天以内。五、修复后的缓存策略分层把最终生效的策略画成一张分层图方便对照检查自己的站点HTML 动态页JS/CSS/图片 指纹文件未命中命中没变变了用户 / 爬虫请求请求的是 HTML 还是静态资源?边缘缓存 s-maxage120边缘浏览器长缓存 max-age 一年 immutable缓存是否命中?回源带条件请求 If-None-Match返回 200 缓存内容 Age 小于 120 秒源站内容变了吗?返回 304 边缘继续用旧缓存返回 200 新 HTML 刷新边缘TTL 过期后 stale-while-revalidate 异步刷新爬虫解析新内容 进入重索引 收录更新修复一周后复查GSC 里抽查的 30 个商品页标题全部更新为新版「上次抓取时间」集中在改版后的 24 小时内。源站回源请求量只上升了约 18%从日志统计因为静态资源的长缓存完全没动只有 HTML 层多回了几次源。这笔账是划算的——收录更新延迟从约 12 天压缩到 1 天以内对促销季频繁调价的独立站来说这意味着价格页面的收录能跟上实际售价。六、误区澄清与收尾回顾整条排查链路改版后收录两周不更新根因不在 Google而在边缘节点把旧 HTML 当成新页面喂给了爬虫——HTML 被配了 7 天长缓存源站又缺ETag和Last-Modified条件请求彻底失效。修复路径也很清晰HTML 走短缓存s-maxage120 保留校验头静态资源走长缓存指纹化让爬虫每次都能拿到新鲜内容。这套思路在实操中常被几个误区带偏这里逐一澄清。误区一「CDN 缓存只影响用户不影响 SEO」错误认知缓存是给访客加速用的搜索引擎抓取走的是另一套逻辑不受缓存影响。实际情况Googlebot 和普通访客走的是同一条边缘链路缓存命中时返回的 200 全量响应喂给谁都是同一份旧 HTML。缓存头配错了收录滞后的是搜索引擎不是用户。正确做法把爬虫当成「最高频、最挑剔的访客」来对待HTML 用短缓存 条件请求确保爬虫每次回源都能校验到最新内容。误区二「把 HTML 缓存全部关掉最安全」错误认知既然缓存会喂旧内容那干脆完全禁掉 HTML 缓存一劳永逸。实际情况完全禁缓存会让每次爬虫请求都全量回源抓取配额Crawl Budget大量消耗在重复传输上高频抓取反而变慢源站压力也上去了。正确做法用「短缓存 条件请求」的组合——s-maxage120让边缘短暂缓存ETag/Last-Modified让爬虫用 304 增量校验。页面没变就省掉传输变了就立刻拿到新内容新鲜度与配额兼顾。误区三「配好 Cache-Control 就万事大吉」错误认知只要Cache-Control写对了缓存策略就生效了不用再管。实际情况Cache-Control只是第一步。如果源站没输出ETag/Last-Modified或者中间层安全插件、旧页面规则、proxy_hide_header把这些校验头剥掉了304 协商永远触发不了爬虫只能全量拉取旧快照。正确做法配置完成后必须验证——curl 源站确认校验头存在再带If-None-Match请求确认能拿到 304同时检查边缘层没有剥离这些头。回到开头那个案例客户改版后收录两周不动不是 Google 变懒了而是边缘缓存替爬虫做了「内容没变」的判断判断依据是 TTL 而不是内容本身。把 HTML 缓存从 7 天压到 120 秒、补上校验头之后30 个商品页的标题在 24 小时内全部更新。缓存头这件事配对了是 SEO 的稳定地基配错了就是收录更新的隐形杀手——值得每个独立站站长花十分钟检查一遍。七、常见问题FAQ7.1 Cloudflare 免费版如何确认 Cache Rules 生效Cache Rules 是 Cloudflare 免费版可用的功能但配置后需要确认它真的接管了流量而不是被旧的页面规则或默认行为覆盖。操作步骤如下登录 Cloudflare 控制台进入你的域名左侧菜单找到Rules → Cache Rules。确认你的规则处于Enabled状态且匹配条件如Hostname equals www.example-parts.com加URI Path starts with /products/与预期一致。打开浏览器的开发者工具或直接用 curl对目标 URL 发起请求重点看响应头里的CF-Cache-Status和Cache-Control。验证命令# 连续请求两次观察 CF-Cache-Status 是否出现 MISS → HIT 交替curl-sIhttps://www.example-parts.com/products/flange-bolt-m12|grep-iEcf-cache-status|cache-controlcurl-sIhttps://www.example-parts.com/products/flange-bolt-m12|grep-iEcf-cache-status|cache-control如果Cache-Control里出现s-maxage120且CF-Cache-Status在两次请求间从MISS变为HIT说明 Cache Rules 已生效。若始终是DYNAMIC或BYPASS检查是否还有更高优先级的页面规则Page Rules在拦截或规则里的表达式写错了。7.2 Nginx 源站如何验证 ETag 和 Last-Modified 是否输出Nginx 默认开启etag on和last_modified但很多情况下会被上层代理、安全模块或显式配置覆盖掉。验证方法很简单直接对源站发起请求看响应头# 直接请求源站绕过 CDN检查实体校验头是否存在curl-sIhttp://源站IP或域名/products/flange-bolt-m12\-HHost: www.example-parts.com|grep-iEetag|last-modified|cache-control如果输出里能看到ETag: ...和Last-Modified: ...说明源站正常输出。若缺失检查 nginx 配置里是否有人显式写了etag off;或last_modified off;或者用了proxy_hide_header把这些头剥掉了。更进一步的验证是发起条件请求确认能拿到 304# 先取一次 ETag再带上 If-None-Match 请求观察是否返回 304ETAG$(curl-sIhttp://源站IP/products/flange-bolt-m12-HHost: www.example-parts.com|grep-ietag|awk-F: {print $2}|tr-d\r)curl-sIhttp://源站IP/products/flange-bolt-m12\-HHost: www.example-parts.com\-HIf-None-Match:$ETAG|head-n1返回HTTP/1.1 304 Not Modified即代表条件请求链路是通的。7.3 如果源站是 Apache配置有何不同Apache 的缓存头控制思路与 Nginx 一致但写法不同。核心差异在于Apache 用mod_headers设置Cache-Control用mod_expires或FileETag控制实体校验头。以.htaccess或虚拟主机配置为例# 启用必要的模块通常在 httpd.conf 中已加载 # LoadModule headers_module modules/mod_headers.so # LoadModule expires_module modules/mod_expires.so IfModule mod_headers.c # HTML 与动态路径短缓存 禁止浏览器缓存 FilesMatch \.(php|html?)$ Header set Cache-Control public, s-maxage120, max-age0, must-revalidate /FilesMatch # 静态资源长缓存 immutable FilesMatch \.(js|css|png|jpg|jpeg|webp|woff2)$ Header set Cache-Control public, max-age31536000, immutable /FilesMatch /IfModule # 确保 ETag 输出Apache 默认开启但可显式声明 FileETag MTime Size验证命令与 Nginx 场景相同直接 curl 源站看响应头即可curl-sIhttp://源站IP/products/flange-bolt-m12-HHost: www.example-parts.com|grep-iEetag|last-modified|cache-control需要注意两点一是 Apache 的FileETag默认基于 inode、MTime 和 Size多机负载均衡时建议改成MTime Size避免不同机器生成不同 ETag 导致 304 失效二是如果用了mod_deflate压缩要确认 ETag 是在压缩前还是压缩后生成的避免强校验失败。三个最常见的误区写在最后提醒一下「CDN 缓存只影响用户不影响 SEO」——错。Googlebot 和普通访客走的是同一条边缘链路缓存喂给谁旧内容收录就滞后谁的。「把 HTML 缓存全部关掉最安全」——过犹不及。完全禁缓存会让抓取配额消耗在全量回源上高频抓取反而变慢。短缓存加条件请求才是兼顾新鲜度与配额的做法。「配了 Cache-Control 就完事了」——还要验证ETag/Last-Modified真的输出去了且中间层没有剥离它们。有些安全插件和旧的页面规则会顺手把这些头删掉304 就永远触发不了。Cache-Control 配置属于网站优化SEO里偏基础但收益稳定的工程项它的价值不在单点排名而在保证「源站改了什么搜索引擎就能多快看到什么」。这个能力往后也是 AI 搜索场景的地基——生成式引擎优化Generative Engine Optimization, GEO同样依赖引擎能抓到最新页面缓存头配错了面向 AI 引擎做再多语义优化也是白搭。这一层先夯实后面的路才好走。如果你也在做外贸独立站欢迎在评论区聊聊你们站点 HTML 的缓存策略是怎么配的尤其是 Cloudflare 免费版用户的 Cache Rules 实践。为什么这对 AI 搜索同样重要上面这套缓存逻辑不只对 Google 收录有效对 AI 搜索引擎同样成立。ChatGPT 联网检索、Perplexity 这类引擎在抓取网页时走的也是标准的 HTTP 抓取链路同样依赖Cache-Control、ETag、Last-Modified这些缓存头来判断内容的新鲜度。它们不会因为你做了语义优化就绕过缓存层——缓存头配错了AI 引擎拿到的同样是旧页面。这直接影响生成式引擎优化Generative Engine Optimization, GEO的效果。GEO 的核心是让 AI 引擎能抓到你最新、最准确的内容并据此生成回答。如果边缘节点把改版前的旧 HTML 喂给了 AI 爬虫那么无论你在页面里埋了多少结构化数据、写了多好的语义描述AI 引擎引用的依然是过期信息回答质量自然打折扣。缓存头是 GEO 的地基地基不稳上层优化都是白搭。针对 AI 引擎建议在现有配置上再补三条缩短 HTML 的 TTL——把s-maxage压到 120 秒甚至更短让 AI 爬虫高频抓取时能更快回源拿到新内容而不是长期命中旧缓存。确保ETag和Last-Modified正常输出——AI 引擎同样会用条件请求做增量抓取校验头缺失会让它们每次都全量拉取既慢又容易拿到旧快照。避免边缘层剥离校验头——检查 Cloudflare 页面规则、安全插件或 Nginx 的proxy_hide_header确认没有把ETag/Last-Modified顺手删掉否则 304 协商永远触发不了。这三条和前面给 Google 的配置完全一致一套配置同时服务两类引擎成本几乎为零收益却覆盖了 SEO 和 GEO 两条线。参考与延伸Cloudflare 官方文档Cache Control缓存控制头与 Edge Cache TTL 行为说明—— https://developers.cloudflare.com/cache/concepts/cache-control/Nginx 官方文档ngx_http_proxy_module 的 proxy_cache 指令含 proxy_cache_valid 与 $upstream_cache_status—— https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cacheMDN Web DocsHTTP 缓存Cache-Control、ETag、条件请求与 stale-while-revalidate 详解—— https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CachingSEO、网站优化、独立站自然流量、CDN 缓存、Cache-Control、ETag、收录更新延迟、条件请求MDN Web DocsHTTP 缓存Cache-Control、ETag、条件请求与 stale-while-revalidate 详解—— https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CachingSEO、网站优化、独立站自然流量、CDN 缓存、Cache-Control、ETag、收录更新延迟、条件请求
