拆了20个AI搜索首页结果，发现GEO技术坑比想象的多
最近在优化我们公司官网的GEO，顺手用脚本抓了20个AI搜索首页结果做逆向分析。
主要看两个指标：
- 结构化数据覆盖率
- 首屏HTML的TTFB和LCP
结果有点意外。
先说结构化数据。
20个结果里，有14个页面至少用了三种以上的Schema类型。最常见的是Article、FAQPage、HowTo。但重点不是用了多少，而是字段填得全不全。
比如FAQPage，很多页面只填了name和acceptedAnswer，但没填mainEntity。AI搜索抓取时，mainEntity这个字段直接决定它能不能把问答对关联到主实体上。少了这个，命中率掉一大截。
我数了一下，完整填mainEntity的只有5个页面。
再说性能。
AI搜索的爬虫和传统搜索引擎不一样。它更倾向于抓取首屏渲染完成的DOM，而不是原始HTML。我用Playwright模拟了一下，发现LCP超过2.5秒的页面，被完整索引的概率明显降低。
具体数据：LCP<1.8s的页面，完整索引率92%；LCP>2.5s的，直接掉到64%。
这个阈值卡得很死，差不多就是Core Web Vitals的及格线。
然后是踩坑细节。
我们之前用Next.js的SSR，以为服务端渲染就够了。结果发现AI搜索的爬虫会执行JS，但执行超时设得很短——大概3秒左右。
如果页面依赖客户端二次请求拿数据（比如useEffect里fetch），大概率抓不到。
后来我们把关键数据全部改成SSR直出，同时把结构化数据用JSON-LD内联到head里，才稳定下来。
还有一个容易被忽略的点：HTML语义结构。
AI搜索对article、section、h1-h3的层级关系很敏感。如果h1里面塞了一堆关键词，但没有和正文的section对应，它可能直接跳过整块内容。
我试过把h1改成纯描述性标题，正文用h2拆分，命中率反而提高了。
总结一下目前跑通的技术方案：
- SSR直出关键内容，不要依赖客户端fetch
- JSON-LD结构化数据内联到head，字段填全（尤其是mainEntity）
- LCP控制在2秒以内，TTFB<500ms
- 语义化HTML，h1和section严格对应
- 图片用WebP，srcset做响应式
这套下来，我们官网在AI搜索的展现量涨了大概40%，但还没到稳定期，继续观察。
社区里有没有人研究过AI搜索爬虫的JS执行超时具体是多少？我测出来是3秒左右，但不确定是不是有波动。