用Lighthouse和Schema折腾了两周，聊聊GEO里最容易被忽视的技术债

最近手头项目告一段落，花了两周时间把公司官网的GEO基础重新过了一遍。

先说结论：很多团队一上来就聊内容策略、聊AI引用率，但底层的技术债不还，后面全是空中楼阁。

我主要做了三件事：

1. 结构化数据从“有”到“对”

之前页面只有基础的 Organization 和 WebSite 标记，用 Rich Results Test 跑一遍，报了一堆 warning。比如 Product 的 offers 缺 priceCurrency，FAQPage 的 acceptedAnswer 没嵌套全。

我的判断依据是：AI 抓取时解析 JSON-LD 的容错率远低于 Googlebot。字段缺失或类型错误，可能导致整个实体被丢弃。

改完之后，在本地用 schema-dts 做了类型校验，确保 TS 编译期就能发现问题。

2. 页面速度不是“差不多就行”

拿 Lighthouse 跑了移动端，LCP 3.8s，CLS 0.21。主要问题是首屏图片没做响应式，以及字体加载阻塞渲染。

具体操作：

• 图片全量换 AVIF，加 srcset 和 sizes
• 字体改 font-display: swap，并 preload 关键字体
• 第三方脚本全部改 defer，部分直接移除

一周后 LCP 降到 1.9s，CLS 0.04。

为什么速度对 GEO 重要？我的观察是：AI 爬虫的抓取预算比传统搜索引擎更紧张，慢页面直接降低被抓概率。而且速度本身是质量信号。

3. 语义化 HTML 和可访问性

这个最容易被忽略。很多页面 div 堆砌，heading 层级乱跳。AI 解析 DOM 时，section/article/nav 这些标签能提供明确的语义分块，比纯 div 好太多。

我顺便用 axe-core 扫了一遍，修了十几个 contrast 和 aria 问题。

踩坑记录：

• JSON-LD 里的 @id 要统一用绝对 URL，相对路径有些解析器会丢
• 别在 structured data 里塞营销词，有页面因为 description 堆关键词被判 spam
• 页面速度优化后，记得重新提交 sitemap，不然索引更新滞后

以上都是脏活累活，但我觉得这才是 GEO 的地基。内容再好，机器读不懂、读得慢，白搭。

想问下各位：你们在结构化数据这块，是手动维护还是接了自动化生成？有没有遇到过 schema 改动后反而被降权的情况？