做独立站的人应该都经历过这种事
新发了一篇文章，提交了 Search Console，等了三天、五天、七天，Google 就是不收。去搜一下 site:你的域名，发现还是上周那几页。然后你开始怀疑是不是内容写得不行，是不是域名权重不够，是不是被惩罚了。
但有一个原因很多人想不到：缓存。
开缓存本来是为了让网站变快。CDN 加速、页面静态化、浏览器缓存，这些在用户体验上确实有用。但缓存配置一旦不对，它会在你完全不知情的情况下，让 Googlebot 反复抓到旧内容、空内容、甚至被直接拦在门外。收录就是这样变慢的。
今年年初我帮一个做家居出口的客户排查收录问题，新站上线两个月只收了 18% 的页面。查了一圈，最后发现是 Cloudflare 的 Rocket Loader 和 Tiered Cache 开了之后，Google 看到的内容和用户看到的完全不一样。关掉这两个功能、重新配了 Page Rules，两周后收录率跳到了 70% 以上。这件事让我意识到，缓存对 SEO 的负面影响，比大多数人想的要普遍得多。
缓存本来是在帮你，怎么变成在坑你？
先理清一个基本逻辑。
缓存的原理是：当有人访问你的页面时，服务器不每次都从零开始重新生成内容，而是把之前生成好的"快照"直接丢出去。这样省了数据库查询和服务器渲染的时间，页面打开快得多。对于人在浏览器里看网页来说，这个逻辑完美。但对于 Googlebot 来说，问题就出在这个"快照"上。
Googlebot 来抓你的页面，拿到的不是服务器刚刚生成的最新版本，而是一个可能已经存了 10 分钟、1 小时、甚至 24 小时的旧快照。如果你在这一天里更新了内容，修改了 TDK，调整了结构化数据，Google 看到的还是旧的。更糟的是，Google 会对比它前后两次抓到的内容是否有变化。如果每次都一样，因为缓存给的永远是同一个快照，Google 就会降低对你的抓取频率。它的逻辑很简单：这个站的内容不怎么变，不需要经常来。
这就是缓存拖慢收录的第一层逻辑：它让 Google 误以为你的网站不更新。
但更隐蔽的情况在后面。缓存不仅会给 Googlebot 旧内容，有时候压根就不给它内容。
 |
▲ 用户看到的 vs Googlebot 看到的：缓存导致内容不一致
最坑的情况：Googlebot 抓到的页面是空的
如果你的独立站是 JavaScript 渲染的——比如用 React、Vue、Next.js 做的——页面的实际内容是通过 JS 在浏览器里动态生成的。HTML 源文件里可能就一个空的 <div id="root"></div>。
CDN 缓存的恰恰就是这个"JS 还没执行时的样子"。Googlebot 来抓取，CDN 直接把这份空的 HTML 快照丢给它。Google 一看：这个页面啥也没有，大概是低质量内容。收录自然就慢了，或者干脆不收。Google 的 John Mueller 在 2025 年专门提过这个问题，说 Search Console 里出现"Page Indexed Without Content"这个错误，通常是 CDN 在拦截 Googlebot 拿内容。这个错误一旦出现，页面就会逐步从索引中被移除。
Prerender.io 做过一个统计，他们处理的客户里，有相当比例的问题是 CDN 把未渲染的 JS 页面缓存并直接返回给了爬虫。修复方法是让 CDN 识别爬虫的 User-Agent，对爬虫请求绕过缓存，把请求透传到源服务器，由预渲染服务返回完整的 HTML。修复之后，索引覆盖率一般能从 40-50% 回升到 95% 以上。
CDN 防火墙：你以为在防攻击，其实在防 Google
这个坑我亲眼见过好几次。
CDN 服务商比如 Cloudflare，默认会开一些安全防护功能：Bot Fight Mode、速率限制、DDoS 防护、甚至人机验证页面。这些功能的设计初衷是好的，拦住恶意爬虫和攻击流量。但问题是，它们有时候分不清 Googlebot 和恶意爬虫。
Cloudflare 社区里有一个很典型的案例。一个新闻站开了 Tiered Cache 和 Rocket Loader 之后，文章从原来发布后 2-6 分钟被 Google 收录，变成了要等 10 个小时。查服务器日志，Googlebot 明明正常访问了页面，内容拿到了，状态码也正常，但就是不收录。最后排查发现，Rocket Loader 改变了 JS 的加载方式，导致 Google 在渲染页面时拿不到正确的资源文件。页面在人眼里是正常的，在 Google 的渲染器里是残缺的。
还有一个更严重的案例。2025 年 7 月，一个网站在开启了 Cloudflare 的 Bot 防护之后，Google News 直接把它移除了。Googlebot-News 的抓取量从每天 8000 次掉到了 3000 次。站长后来把 Googlebot-News 加入了白名单，Google News 的恢复仍然花了几个月，效果还不理想。
DooDoo.Love 游戏门户站的案例也很说明问题。他们用 Cloudflare 免费版的 Cache Rules 来做 HTML 缓存，结果发现不管怎么配置，HTML 永远不命中缓存，Googlebot 每次请求都要等源站响应（TTFB 高达 1800ms）。站上有 6725 个页面，Google 只收了 1250 个，收录率 18.6%。改成 Page Rules 里的 "Cache Everything + Edge Cache TTL" 之后，TTFB 降了 68%，收录才开始恢复正常。
还有一个非常隐蔽的问题：CDN 的人机验证页面。如果你的 CDN 对疑似机器人的请求弹出一个"确认你是人类"的验证页面，而这个页面返回的 HTTP 状态码是 200（而不是 503），Google 就会认为这个验证页面就是你网站的内容，然后把它当成正常页面来索引。结果就是你的页面被一个"验证页面"替代了。
| CDN 人机验证必须返回 503 状态码，这样 Googlebot 才知道"现在暂时访问不了，等下再来"。返回 200 的话，Google 会觉得验证页面就是你的正文内容。 |
 |
▲ 收录慢排查顺序：先查缓存/CDN → 再查服务器 → 最后看 Google 端数据
WordPress 缓存插件：提速是提速了，但 Googlebot 那边发生了什么？
外贸独立站用 WordPress 的比例很高。WP Rocket、W3 Total Cache、LiteSpeed Cache 这些插件几乎人人都在用。它们确实把页面加载速度提升了，但每种插件都有可能在 SEO 上搞出问题。
JS/CSS 合并压缩功能。几乎所有缓存插件都有这个功能，把多个 JS 文件合成一个、多个 CSS 文件合成一个、然后压缩。问题是每次合并后的文件名会变（比如从 bj55m.css 变成 bj63m.css）。Googlebot 之前抓取时缓存了旧的资源链接，下次来的时候发现这些链接全变成了 404。CSS 加载失败，页面在 Google 的渲染器里就变形了。Google 官方论坛里有多个帖子讨论过这个问题，结论是这种资源 404 确实会影响排名信号。
Googlebot 被排除了。有些缓存插件在检测到"已登录用户"时会跳过缓存，直接给动态页面。但它们的"已登录检测"偶尔会误判，把 Googlebot 也当成已登录用户，然后丢给它一个未经缓存的、最慢的版本。或者反过来，Googlebot 被识别为普通访客，拿到的是缓存中的旧版本。两种情况都不对。
残留文件。W3 Total Cache 是出了名的"卸载不干净"。即使你在 WordPress 后台停用了它，服务器上还会残留 advanced-cache.php、object-cache.php、cache 文件夹和 .htaccess 里的规则。这些残留会继续干预 Googlebot 的抓取行为，而你已经完全意识不到了。
LiteSpeed Cache 激进模式。LiteSpeed 有一个激进优化选项，开完之后 Google Search Console 里可能会出现 503 错误。Googlebot 来抓取的时候，恰好碰上缓存正在重建，拿到了一个临时的错误页面。更惨的情况是 50 多个已经收录的页面突然被 Google 移除了索引。
缓存配置不当，你的抓取预算全被浪费了
Google 给每个站分配的抓取预算是有限的。独立站不像大站那样有充足的预算，一次可能就几十到几百个页面的配额。如果 Googlebot 每次来抓，拿到的都是缓存里的同一个旧版本，它怎么判断要不要多抓一点？只能靠内容有没有变化来判断。缓存让内容看起来"一直没变"，Google 就觉得没必要加预算。
更糟的是，如果缓存配置里有错误，比如资源 404、503 错误，Google 会消耗额外的抓取配额去重试这些失败的请求。本来可以用来抓新页面的配额，全都耗在了反复尝试那些出错的旧页面上。
先搞清楚：你的缓存是不是已经在影响收录？
动缓存之前，先确认问题到底是不是出在缓存上。有几个简单的排查方法：
用 Search Console 的 URL 检查工具看 Googlebot 到底拿到了什么。这是最直接的。输入一个没被收录的页面 URL，点击"测试实际网址"，看 Google 抓取到的 HTML 截图和你的实际页面是不是一样的。如果截图是空的、缺了内容、或者长得跟你的页面完全不一样，大概率是缓存或 CDN 的问题。
用 curl 模拟 Googlebot 请求。在命令行里执行 curl -I -H "User-Agent: Googlebot" 你的网址，看返回的 HTTP 头里有没有异常的 Cache-Control、X-Cache 状态、或者重定向。如果看到 X-Cache: HIT 但你刚刚更新了页面内容，说明 Googlebot 拿到的是旧缓存。
对比 Search Console 的抓取统计。去设置 → 抓取统计，看每天的抓取请求数。如果哪天装了个缓存插件或者改了 CDN 配置之后，抓取量突然掉下来了，基本能确定是缓存的问题。
检查 Sitemap 的已收录比例。Search Console → 站点地图 → 看"已发现"和"已收录"之间的差距。差距超过 15% 就要排查，可能的原因之一是 Googlebot 抓到了空内容或者旧内容。
怎么正确配缓存，让它帮 SEO 而不是害 SEO
缓存本身不是坏事。配好了，它同时提升用户体验和 SEO；配不好，它就是收录的头号障碍。以下是我在实际操作中总结的几条配置原则：
| 让 CDN 对 Googlebot 绕过缓存。在 Cloudflare 的 Page Rules 里设置 "Cache Level: Bypass"，匹配条件为 Googlebot 的 User-Agent。其他 CDN（AWS CloudFront、Fastly）也有类似的配置。这样 Googlebot 每次来拿到的都是源站的最新版本，不会因为缓存错过你的内容更新。Advanced Hosting 做过一个案例，一个网站给 Googlebot 做了白名单和缓存绕过之后，自然流量涨了 34%，索引覆盖率达到了 100%。 |
| 按页面类型做分级缓存。不要全站一把梭。静态资源（CSS/JS/图片，文件名带哈希版本号的）可以设长缓存：max-age=31536000, immutable。HTML 页面用 no-cache 或 max-age=0, must-revalidate，配合 ETag/Last-Modified 头让 Google 判断要不要重新抓。首页和固定页面可以缓存久一点，但文章页和产品页，更新频率高的，缓存时间要短，最好控制在 10-30 分钟以内。 |
| 更新内容后主动清缓存。每次发布新文章或修改产品页内容后，立即手动刷新 CDN 缓存和相关页面。大多数 CDN 和缓存插件都支持"发布时自动清除缓存"。如果你用的是 Cloudflare，可以用 API 做批量刷新。如果你用的是 WP Rocket，去设置里确保"发布新文章时清除缓存"是勾上的。 |
| 关掉那些"花活"功能。Cloudflare 的 Rocket Loader 和 Tiered Cache，LiteSpeed 的激进优化，WP Rocket 的 JS/CSS 合并，这些功能在 SEO 场景下出问题的概率远高于正常使用的概率。如果收录有问题，第一步就是先把这些关掉，观察一到两周看变化。我接触的案例里至少有四五个收录问题最后都是关掉 Rocket Loader 解决的。 |
| CDN 人机验证只拦恶意爬虫，不拦 Googlebot。在 WAF 规则里把 Googlebot 的 User-Agent 和 Google 官方的 IP 段加入白名单。如果必须对可疑流量弹验证，确保验证页面返回 503 状态码。Cloudflare 社区里有不止一个用户反映站点从 Google News 消失，就是因为 Bot Fight Mode 把 Googlebot-News 也拦了。 |
| WP 缓存插件：只用核心缓存，别开附加功能。WP Rocket / W3 Total Cache / LiteSpeed Cache，用它们的基本页面缓存就够了。JS/CSS 合并、延迟加载、数据库优化这些附加功能，除非你非常确定它们不会影响 Googlebot 的渲染，不然就别开。另外，如果你卸载了一个缓存插件，一定要去 wp-content 目录下手动删除它留下的 advanced-cache.php 和 object-cache.php，并且清理 .htaccess 里的相关规则。 |
| 对 Sitemap 和关键动态页面排除缓存。Sitemap XML、robots.txt、API 接口、购物车页面等等，这些永远不要缓存。可以在 Cloudflare Page Rules 或缓存插件的排除列表里手动加上这些路径。 |
如果你用的是 Next.js 或者 React 做的站
JS 渲染的站点受缓存影响最严重。因为 Google 渲染 JS 本身就需要额外的资源和时间，Google 叫"第二波渲染"（second wave rendering），相当于 Googlebot 先抓 HTML，再单独跑一遍 JS 把内容渲染出来。如果你的缓存在这个链路中间任何一个环节给了错误的数据，索引就会出问题。
几个额外要注意的：
用 SSR 或者预渲染。Next.js 有 getServerSideProps 和静态生成，确保对 Googlebot 返回的是完整 HTML，而不是空的 div#root。
不要缓存初始 HTML。如果你用 Cloudflare 缓存 Next.js 的页面，Googlebot 拿到的 HTML 可能是在 CDN 边缘节点缓存的"第一次生成的样子"，后续任何内容更新都看不到。
用 Search Console 的渲染截图对比实际页面。URL 检查 → 测试实际网址 → 看截图。如果截图里缺图片、缺文字、布局乱了，Google 索引的就是这个残次版本。
不要同时有 www 和裸域都返回 200。Cloudflare Pages 上这个问题特别常见。两个域名都能访问，内容一模一样，Google 在你两个域名之间反复横跳，最后干脆不收。必须做 301 跳转。
最后聊一个容易被忽略的点
很多人解决收录问题的思路是从内容入手，是不是文章写太短了，是不是关键词没布局好，是不是内链太少。这些当然重要，但如果缓存配置有问题，你写再多好内容，Googlebot 看到的也可能是一张旧快照、一个空白页面、或者一个人机验证的拦截页。
排查收录问题的正确顺序应该是：先确认 Googlebot 能不能正常拿到你的最新内容（缓存和 CDN），再确认你的内容质量本身。很多收录慢的问题，到最后发现不是内容不行，是 Googlebot 压根没看到你写的东西。
如果你用的是 Cloudflare，可以先做两个最简单的操作：去 Page Rules 里给 Googlebot 的 User-Agent 设一条绕过缓存的规则；去安全设置里确认 Bot Fight Mode 是关闭的。这两个操作不会影响网站速度，但可能让你的收录速度有一到两周后出现可见的改善。
缓存不是敌人。但缓存配置错了，它确实能让你的 SEO 努力全部白费。而且最让人头疼的是，你很难第一时间发现，网站看起来很快，用户体验很好，Google Search Console 也没有报错，一切看起来都正常。唯一不对劲的，是新内容就是迟迟不收。