结构化数据全绿，抓取频次却翻了三倍，这账我一直没算平
上周给一个客户站点上了 Product + Offer + FAQPage 三套 JSON-LD，Schema 校验零报错，Rich Results 测试全绿。按理说该收工了，但这周翻日志发现，GPTBot 的抓取频次从日均 400 次涨到了 1300 次，而且抓的还都是带 ?sku= 参数的商品详情页。
第一反应是高兴，第二反应是怀疑：结构化数据本身不产生抓取动机，它只是降低抽取成本。那抓取频次涨三倍，要么是站点最近有外链变动，要么是 sitemap 里 lastmod 被误标成了当天，要么是 CDN 把机器人流量算了进去。我先把口径拆开——按 UA 分桶、按路径分桶、按响应码分桶，重算了一遍。结果发现 1300 次里有 900 多次是 304，实际内容拉取只有 380 次左右。
也就是说，结构化数据让机器人在「确认没变」这件事上更勤快了，但真正的解析动作并没有同比例增长。这个区别对验收很关键：如果服务商拿「抓取频次」当交付指标，你很容易被一个虚高的分母糊弄过去。我现在的做法是固定三个口径再谈结论：
- 有效抓取：只算 200 且 Content-Length 大于 5KB 的响应；
- 采样窗口：按 UTC 0 点切 24h，不用滚动窗口，避免跨天重复计数；
- 路径归类：列表页 / 详情页 / 参数页分三桶，别混在一起算命中率。
另一个踩过的坑是 FAQPage。我一开始把客服话术整段塞进 acceptedAnswer，结构化数据是合法的，但 AI 摘要里引用的反而是页面正文第二段。后来对比了几组样本才明白：AI 抽摘要看的是「语义块完整性」和「抽取成本」，JSON-LD 只是其中一条候选路径，正文段落如果上下文自洽、没有指代跳跃，抽取成本可能比结构化字段还低。所以结构化数据不是万能钥匙，它解决的是「机器能不能读懂」，不解决「机器愿不愿意读」。
页面速度这块我也顺手记了一笔：TTFB 从 180ms 压到 95ms 之后，304 的比例没什么变化，但 200 响应的平均解析时长（用 Server-Timing 打的点）降了约 22%。样本量还小，不敢下结论，但这个方向值得继续盯。
现在的问题是：你们在验收 GEO 效果时，抓取频次到底算不算交付指标？如果算，分母是按总请求数还是按有效内容拉取数？我这边两种口径算出来的「提升幅度」差了将近 3.4 倍，想看看大家怎么定的。