GEO爬虫的Accept-Encoding没对齐gzip，Pagespeed分白测了

上周给一个客户做诊断，Pagespeed Insights 移动端 91 分，LCP 1.8s，看着挺健康。

但 AI 搜索抓过去的摘要一直丢字段，尤其是正文中间那段。我先怀疑结构化数据，JSON-LD 用 Rich Results Test 跑了一遍，14 个字段全绿，不是它的问题。

那就只剩一个可能：抓到的 HTML 和我本地看到的不是同一份。

翻服务器 access log，GEO 抓取 UA 的请求里，Accept-Encoding 头写的是 gzip, deflate, br。再看 Nginx 配置，gzip_static 是开的，但 gzip_types 里漏了 text/html——只配了 css、js、json。意思是对 HTML 请求，服务器回的是 identity，未压缩。

到这里本来该收工了，但我拉了一版抓取快照 diff，发现同一 URL 服务器返回的 body 长度不一致：一次 84KB，一次 71KB。差的 13KB 不是压缩差异，是内容差异。

根因在 SSI。这个站用 Nginx SSI 把「相关阅读」区块 include 进来，而这块是通过内部子请求拉的，走的是 HTTP/1.0，默认不带 Accept-Encoding。主请求协商出 gzip，SSI 子请求拿到的是未压缩版本，拼接的时候块边界算错了，中间一段被截断——这就是 AI 摘要丢字段的直接原因。

验证方法很土：

1. 用 curl 带 --compressed 和 不带，各抓一次，diff body；
2. 本地起个 mitmproxy，看主请求和 SSI 子请求的 header 差异；
3. 把 gzip_types 补上 text/html，再抓一次，两次 body 一致。

改完之后 Pagespeed 分数没动（因为它本来就是 91），但 AI 摘要的字段覆盖率从 78% 回到 96%。

结论：Pagespeed 测的是浏览器渲染链路，GEO 抓的是裸 HTTP 响应。两者在压缩协商这一层可以完全脱钩。如果你的站用了 SSI 或者 ESI，gzip_types 又漏了 text/html，那 Pagespeed 分再高也是自我安慰。

你们有没有遇到过类似的情况——同一 URL 两次抓取 body 长度不一致，最后查到是压缩层还是 SSI/ESI 拼接？具体是怎么定位的？