GEO技术优化：页面结构、加载速度、结构化数据对AI抓取的影响
一、L1 进门：bot 能不能读到你的页面
技术优化的第一层不是优化，是排雷。B2B 官网最常见的 GEO 技术问题，是 bot 根本没进来。原因有三个：robots.txt 误屏蔽、防火墙按 UA 拦截、纯 JS 渲染返回空壳。
| 问题 | 检测方法 | 修复动作 |
|---|---|---|
| robots 误屏蔽 AI bot | 查 robots.txt 与 bot 状态码 | 显式 Allow GPTBot、OAI-SearchBot、PerplexityBot |
| WAF 拦未知 UA | 用 curl 加 bot UA 测试 | 白名单这几个 bot UA |
| 纯 JS 渲染首屏空白 | curl 抓 HTML grep 正文 | 上 SSR 或 SSG |
| 页面对中文/英文双版不一致 | 分别 curl 两个版本 | 确保两版都直出正文 |
检查方法很具体。在服务器日志里按最近 30 天过滤这几个 bot 的 UA：GPTBot、OAI-SearchBot、PerplexityBot、ClaudeBot、Googlebot。如果状态码全是 4xx，说明被拦了；如果有 200 但访问的都是首页，说明内链或 sitemap 没让 bot 爬到深层。sitemap 怎么写，见 站点重构与换域名里的链接结构部分。
场景化示例：一家做 WordPress 独立站的客户，装了一个安全插件默认拦所有不明 bot，上线半年后我们查日志发现 PerplexityBot 一次都没来过。把它加进白名单后第二周，bot 开始访问产品页，4 周后 Perplexity 答案里开始出现这家公司的引用。这个问题不需要改内容，只改一行配置。
二、L2 速度：TTFB 和 LCP 决定 bot 多久来一次
传统 SEO 把页面速度当用户体验问题，Core Web Vitals 也是为真人设计的。但对 AI bot 来说，速度决定的是抓取优先级和频率。bot 在队列里按响应时间排序，TTFB 超过 2 秒的页面会被排到后面，重抓周期从 3 天拉到 2 周。
| 指标 | 合格线 | 不达标影响 | 优化方向 |
|---|---|---|---|
| TTFB | ≤ 1.5 秒 | 抓取优先级下降 | CDN 缓存、PHP 升级 |
| LCP | ≤ 2.5 秒 | 首屏 chunk 不完整 | 图片压缩、关键 CSS 内联 |
| INP | ≤ 200 毫秒 | 对 bot 影响小，对真人影响大 | 第三方脚本延迟加载 |
| CLS | ≤ 0.1 | 对 GEO 影响小 | 图片宽高比固定 |
对 GEO 来说，TTFB 和 LCP 最重要。INP 和 CLS 主要服务真人用户，对 bot 抓取影响不大，不必过度优化。具体阈值和优化优先级见 Core Web Vitals。CDN 节点选择对 TTFB 影响最大，B2B 出海站建议把北美、欧洲节点都配上，见 CDN 全球加速。
反直觉判断：慢页面不是「用户体验问题」，是 GEO 抓取频率问题。一个 TTFB 3 秒的产品页，内容和竞争对手一样好，但 bot 两周才来一次，你的内容更新要两周后才被模型看到，引用率自然落后。把 TTFB 压到 1.5 秒以内，等于让 bot 来得勤 4 到 5 倍。
三、L3 读懂：页面结构让模型不猜
bot 读得到、读得快之后，还要读得懂。这一层靠页面结构和结构化数据。模型靠 HTML 的标题层级、表格、链接锚点判断页面在讲什么。结构混乱时，它要靠上下文猜，猜错的概率就上升。
| 结构项 | 合格写法 | 不合格写法 |
|---|---|---|
| H1 | 每页唯一，含主关键词 | 多个 H1 或无 H1 |
| H2/H3 层级 | 按内容逻辑递进 | 跳级用 H4 当小标题 |
| 表格 | 有 thead，首行是阈值 | 用图片拼表格 |
| 锚点 | 每个 H2 有 id | 无 id，模型无法指向段落 |
| 内链 | 锚文本是关键词 | 锚文本是「点击这里」 |
结构化数据三件套（Organization、WebSite、BreadcrumbList）全站必上，这是给模型发的实体身份证。产品页和文章页再加 Product、Article、FAQPage。字段要和可见内容一致，错配会触发 Google 手动操作。具体标记清单见 结构化数据 Schema。实体怎么在 AI 答案里被识别，见 知识图谱与实体标记。
场景化示例：一个产品参数表如果用图片拼出来，bot 看到的是一张图，OCR 不一定能读出表格里的数字；如果用真正的 HTML table，thead 里写「PN16 蝶阀工作温度上限」，模型就能直接把这一行当事实摘出。图片本地化的边界见 多语言站的图表处理。
四、检查顺序与上线时限
三层不要同时改。按顺序来，每层有明确的验证工具和时限。
| 步骤 | 工具 | 时限 | 通过标准 |
|---|---|---|---|
| 1 查 robots 日志 | 服务器日志过滤 bot UA | 当天 | 5 个 AI bot 均有 200 状态码 |
| 2 测 TTFB/LCP | Lighthouse、PageSpeed | 3 天内修复 | TTFB ≤ 1.5s，LCP ≤ 2.5s |
| 3 查 Schema | Rich Results Test | 当天 | 三件套无错误 |
| 4 查 H 层级 | 浏览器插件 outline | 当天 | H1 唯一，层级无跳级 |
| 5 等 bot 重抓 | 服务器日志持续观察 | 1 至 2 周 | bot 访问频次上升 |
改完不要期待第二天就有引用提升。bot 重新抓取需要 1 至 2 周，模型索引更新还要再加 1 至 2 周。所以技术优化后至少等 4 周，再跑固定问题集看引用率变化。这种时间差是 GEO 实验设计里必须考虑的，见 GEO 实验设计。
常见误区是一上来就写新内容。L1、L2 没过时，新内容和旧内容一样到不了模型那里。先排雷，再加速，最后才谈内容。这三层的顺序反了，每一步的收益都会打折。
还有一个容易被忽略的点：多语言站点的技术层要单独检查。德语、西语、阿语版本如果用同一套 robots 但 CDN 节点只配了美国，非英语市场的 TTFB 会偏高，对应语言的 AI 引用率就上不去。多语言 GEO里讲的德西阿语市场，技术上就是先把本地节点、本地 hreflang 标记、本地缓存三件事落地，再谈内容。
场景化示例：一家做多语言出海的客户，英语版引用率正常，德语版在 Gemini 里几乎为零。查日志发现 Googlebot 从欧洲节点访问德语版时 TTFB 是 3.2 秒，被排到队列尾部。把 CDR 欧洲节点加上、德语版页面在法兰克福缓存后，TTFB 降到 1.1 秒，三周后德语版引用率开始爬升。这个问题和内容无关，纯粹是技术层漏了一个地区。
最后提醒一句：技术优化完成后不要频繁改 URL。每次改版都要做 301 交接，否则 bot 刚爬熟的旧链接会断，新链接要重新排队。站点迁移时的 301 地图画法见 站点重构与换域名。技术层是慢工，一旦稳定下来就别乱动。
把三层技术检查做成月度固定动作，和 官网维护期里的其他例行项放在一起：每月跑一次 bot 日志、一次 Lighthouse、一次 Rich Results Test。技术债不像内容债那样肉眼可见，但它决定了你的内容能不能被模型读到。一个稳定、快速、结构清晰的站点，是所有 GEO 内容工作的前提。
FAQ 常见问题
GEO 技术优化先做哪一层？
TTFB 慢为什么会影响 AI 引用？
纯 JS 渲染的站对 GEO 有什么影响？
结构化数据 Schema 对 AI 引用有多大作用？
改完技术优化多久能看到引用提升？
页面里的参数表用图片还是 HTML table？
写在最后
GEO 的技术层经常被内容团队低估。大家都在写更好的文章，但文章再好，bot 进不来、来得慢、读不懂，一切都是白搭。三层技术优化本质上是给模型修路：先把大门打开，再把路铺平，最后把路标画清楚。
落地三步：本周用服务器日志查 5 个 AI bot 的状态码，把被拦的加进白名单；下周用 Lighthouse 测 TTFB 和 LCP，把 TTFB 压到 1.5 秒以内；第三周用 Rich Results Test 检查 Schema 三件套，补齐全站标记。做完这三件事，等 4 周再跑问题集，你会看到引用率的第一次跳变。
一句可以记住的话：GEO 技术优化不是给用户看的，是给 bot 铺路的——门打开、路铺平、路标画清楚，内容才到得了模型面前。