页面速度优化后AI抓取量反降，我把LCP和TTFB拆开才找到原因
上周把官网首屏 LCP 从 4.2s 压到 1.8s，满心以为 AI 爬虫抓取量会涨。结果 Search Console 里 AI 爬虫的请求数从日均 3200 掉到 2100，掉了三成多。
我先锁口径：抓取量按天、按 UA 分组，排除掉图片和 CSS 请求，只看 HTML 文档。确认不是统计口径问题，是真掉了。
然后拆变量。先查 TTFB，优化前 820ms，优化后 210ms，没问题。再查 LCP，确实降了。但把响应头拉出来对比，发现一个细节：优化前 Cache-Control: max-age=3600，优化后 CDN 默认改成了 s-maxage=86400, stale-while-revalidate=30。
问题就出在这。stale-while-revalidate 让边缘节点在缓存过期后先返回旧内容，异步回源。AI 爬虫拿到的是旧版本 HTML，里面指向的 JS/CSS 资源哈希已经变了，它再去请求那些资源，404 率从 0.3% 飙到 7%。爬虫判定页面不稳定，主动降了抓取频率。
我做了个对照实验：把边缘节点强制回源，关掉 stale-while-revalidate，跑了两天。抓取量回到 3100 左右，404 率降到 0.5%。
另一个坑是结构化数据。优化时顺手把 JSON-LD 内联到了 <head> 里，但 CDN 缓存策略没区分 HTML 和静态资源，每次回源重建页面时，@id 字段里的时间戳都会变。AI 解析时认为这是两个不同的实体，重复抓取同一页面，白白消耗了抓取配额。
现在我的做法是：
- 页面速度优化和缓存策略分开验收，先看爬虫日志再动 Cache-Control；
- 结构化数据里的
@id用稳定 URI，不带时间戳； - 每轮优化后拉一周的爬虫 UA 分布和 404 率，对比 LCP 和 TTFB 的变化曲线。
结论是页面速度不是孤立指标，Cache-Control 的语义直接决定爬虫看到的是哪个版本的 HTML。有没有人遇到过类似的情况——优化完速度，抓取量反而掉了？你们怎么定位是缓存层还是渲染层的问题？