预渲染检测踩坑：首屏11秒出正文，爬虫到底吃的是哪一版

上周给一个客户官网做交付前压测，本地 Lighthouse 跑出来 LCP 2.3s，挺好看。结果上真机 4G 一测，首屏正文 11 秒才出来。我当时第一反应是 CDN 回源慢，查了日志不是，是首屏那坨内容全靠 JS 客户端渲染，HTML 里就是个空壳。

问题来了：GEO 场景下，AI 爬虫抓到的是空壳还是渲染后的 DOM？这直接决定我们验收要不要把预渲染算进去。我做了组对照：

• 同一 URL，服务端返回的原始 HTML 里，正文段落数 = 0，只有 <div id="app">
• 用 headless 渲染后的 DOM 里，正文段落数 = 14，结构化数据 3 段 JSON-LD
• 两种状态下，<title>、<meta description> 一致

也就是说，如果爬虫不执行 JS，它拿到的是一份几乎没有正文的页面。这种情况下你 JSON-LD 写得再规范也白搭，因为正文和结构化字段对不上——字段里说页面讲的是 A，正文里压根没 A 的文本，这是典型的口径断裂。

我坚持的验收口径是：结构化数据里的每个字段，必须在服务端直出的正文里找得到对应文本。找不到就判不通过。预渲染不是加分项，是及格线。

踩第二个坑：预渲染检测怎么测才准。我一开始用 curl 直接抓，发现返回的 HTML 带了预渲染内容，以为没问题。后来对比了 UA，发现服务端是按 UA 分流的，普通 curl UA 给的是预渲染版，某些爬虫 UA 反而走了 SPA 兜底。所以检测必须锁死 UA 和 Accept 头，固定成目标爬虫的指纹，再对比首字节到正文出现的时间戳，精确到小时都不够，得精确到秒，因为爬虫回抓有滞后，你上午改的预渲染规则，下午测到的可能还是旧版。

我的做法是：改完配置后，在观测窗口里每 6 小时抓一次，连续 4 次，看正文段落数是否稳定 ≥ 10 且和 JSON-LD 字段对齐。不稳定的那几次，基本都是爬虫回抓滞后在捣鬼。

现在这个客户的页面，服务端直出正文 14 段，LCP 压到 2.1s，JSON-LD 字段逐条核对通过。但我还是留了个尾巴：他们部分二级页用了动态 import，首屏正文依赖一个异步 chunk，这种页面预渲染规则一漏就是空壳。

想问问大家：你们做预渲染检测的时候，是只测首页，还是按模板把所有二级页的正文直出率都跑一遍？有没有踩过异步 chunk 导致预渲染漏掉的坑？