从这一章开始，我们进入 GEO 的实操层。

第一章到第三章建立的是认知框架——你已经知道 AI 正在带来什么变化，生成式 AI 如何处理内容，RAG 的完整流程是怎样的。现在的问题是：具体该做什么？

答案从地基开始。回到第一章 1.6 节的方法论骨架——你的内容要被 AI 采用、提及或引用，前提是 AI 能找到你（可检索性）。可检索性取决于两件事：内容在技术层面是否可达（可抓取性）、是否可读（可提取性）。这两件事是整个 GEO 大厦的地基——如果 AI 爬虫连你的页面都看不到，后面的内容优化就很难发挥作用。

可抓取性回答的是第一个问题：AI 爬虫能不能把你的页面下载下来？可提取性回答的是第二个问题：下载下来的东西里，AI 能不能把正文和噪音分开？两个问题都过关，你的内容才算真正进入了 AI 的视野。

这一章的内容偏技术，但不需要你懂技术。我会把每个技术点翻译成「这件事对 GEO 意味着什么」和「你该怎么检查和修复」。如果你团队里有负责网站开发的同事，把这一章直接转给他们，附上末尾的 30 分钟自检清单。

4.1 AI 爬虫 vs 浏览器：两种差异很大的「阅读」方式

在排查任何具体问题之前，有一个反直觉的认知需要先建立：AI 的抓取系统看到你网站的方式，和用户用浏览器访问时看到的，差异很大。

浏览器是一个完整的运行环境。它下载 HTML，执行 JavaScript，渲染 CSS，处理动画，最终呈现一个视觉上完整的页面。你在屏幕上看到的每一个字、每一张图、每一个交互效果，都是浏览器「跑完全套流程」之后的结果。

在很多生成式搜索场景里，初始 HTML 仍然是最可靠、成本最低的内容入口。Googlebot 具备较强的 JavaScript 渲染能力，Google AI Overviews 也建立在其技术基础之上；但不能假设所有 AI 抓取系统都具备同等能力，也不能假设它们会等待所有异步内容加载完成。从 GEO 的保守策略看，核心内容最好在初始 HTML 中可见。

这意味着一件很具体的事：如果你的网站用 React、Vue、Angular 等现代前端框架，且核心内容依赖客户端 JavaScript 渲染——也就是内容在浏览器中加载后才出现——那么这些内容对部分抓取系统存在明显的不可见或提取不稳定风险。你的页面在浏览器里看起来信息丰富，但某些抓取系统拿到的可能只是一个空壳。

这是我在排查中遇到的最常见的 GEO 基础设施问题。「内容明明在页面上，AI 为什么看不到？」——在现代前端网站里，JavaScript 渲染是最常见的原因之一，也可能叠加 robots.txt、反爬、图片表格或正文提取失败等问题。对 WordPress 用户来说这个问题通常不存在，因为 WordPress 默认就是服务器端渲染。但对于使用现代前端框架的网站，这是第一个需要排查的问题。

后面几节会逐一讲解影响可抓取性的各个技术因素。但如果你只有时间做一件事，先做 4.3 节的 JavaScript 渲染检查——它是所有问题中优先级最高、影响最大的。

4.2 TTFB：首字节时间决定 AI 爬虫的第一印象

TTFB，Time to First Byte，首字节时间——从爬虫发出请求到收到服务器返回的第一个字节的时间。

TTFB 过慢既影响用户体验，也可能造成抓取超时、渲染失败或资源消耗增加。不同爬虫的超时、重试和抓取调度策略并不公开统一，因此不能由某个 TTFB 数值直接推导 AI 可见性；但服务器长期不稳定或经常超时，显然会降低页面被可靠获取的机会。

具体阈值因系统而异，目前没有公开的统一标准。从 Google Web Vitals 的公开口径看，TTFB 低于 800 毫秒通常可视为较好，超过 1.8 秒属于明显偏差。对希望提升抓取效率和页面响应速度的网站，我建议把核心页面的 TTFB 尽量压到 200–500 毫秒区间；如果长期超过 500 毫秒，值得优先排查——但这是基于工程经验的建议，不是公开硬性门槛。

检测方法：在 Chrome 或 Edge 浏览器中按 F12 打开开发者工具，切到 Network 面板，刷新页面，点击第一个 HTML 文档请求，在 Timing 标签页中查看「Waiting for server response」即为 TTFB。也可以访问 pagespeed.web.dev 在线检测，在诊断结果中查看服务器响应时间。建议测试首页和最重要的 3 个内容页面。

如果 TTFB 偏高，主要优化方向有三个：

• 服务器和 CDN 选择：国内用户优先使用国内 CDN（阿里云、腾讯云），避免服务器在境外导致的延迟。

• 启用服务器端缓存：对静态内容页面缓存 HTML 响应，避免每次请求都重新生成。

• 数据库查询优化：动态页面的 TTFB 高通常源于慢查询，使用 Redis 或 Memcached 做查询缓存可以显著改善。

4.3 JavaScript 渲染陷阱：最常见的高优先级问题

这是本章最重要的一节。如果你的网站使用了 React、Vue、Angular 等前端框架的客户端渲染模式，或 Next.js / Nuxt.js 等框架的 CSR 配置，请认真读完。

怎么判断你是否有这个问题

三种检测方法，任选其一：

• Chrome 源代码检查。在你的核心页面按 Ctrl+U（Windows）或 Cmd+Option+U（Mac）查看页面源代码。在源代码中搜索你最核心的产品名称或关键结论。如果搜不到，说明这段内容依赖 JavaScript 渲染，对部分 AI 爬虫存在明显的不可见风险。这是最快的初筛方式，十秒钟就能完成。

• Google Search Console 的 URL 检查。输入你的页面 URL，点击「测试实时 URL」，查看 Google 渲染后的页面截图与你实际看到的是否一致。如果有明显差异——比如 Google 渲染结果里大片空白——说明有渲染问题。（注意：GSC 验证的是 Google 视角下的抓取与渲染，不代表其他 AI 爬虫也能同样看到。）

• 命令行测试。把 URL 换成你要测试的页面，把「产品名」换成实际关键词。

Windows PowerShell：

“`powershell $url = “https://example.com/your-page” $keyword = “产品名”

((Invoke-WebRequest -Uri $url -UseBasicParsing).Content).Contains($keyword) “`

如果返回 True，说明关键词出现在初始 HTML 中。如果返回 False，说明没有匹配到，内容可能是通过 JavaScript 后加载出来的。

macOS 终端：

“bash curl -L -s 'https://example.com/your-page' | grep -F '产品名' “

如果有输出，说明关键词出现在初始 HTML 中；如果没有任何输出，说明没有匹配到。

如果需要批量检查多个页面，可以让开发同事用脚本自动化完成。

怎么修复

核心原则只有一个：确保你的核心内容在初始 HTML 中就存在，不依赖 JavaScript 执行后才出现。

• 如果你用 WordPress： 大概率没有这个问题。WordPress 默认服务器端渲染，内容直接在 HTML 中。但有几种情形例外：使用页面构建器（Elementor、Divi 等）、装了过度激进的懒加载或前端优化插件、内容主要通过短代码异步加载、或采用了 Headless WordPress（前端由 React/Vue 接管）——这些都可能让核心内容不在初始 HTML 里。值得用上面的方法一快速验证一下。

• 如果你用 React/Vue/Angular： 需要确保核心内容能在初始 HTML 中直接呈现。最常见的方案是 SSR（服务器端渲染）或 SSG（静态站点生成）——Next.js 用户可以使用 getServerSideProps 或 getStaticProps（Pages Router），或在 Server Component 中直接 fetch 数据（App Router，Next.js 13+ 默认）；Nuxt.js 用户默认支持 SSR。

预渲染、混合渲染、关键内容服务端输出等方案也可以达到类似效果。具体路径因技术架构而异，但核心原则不变：关键内容不能依赖客户端 JavaScript 才出现。这个改动通常需要开发团队介入，优先级应该排在所有 GEO 优化动作之前。

• 如果短期内无法改动技术架构： 至少确保页面的标题（H1）、Meta Description 和核心结论段落以纯 HTML 形式存在于初始响应中。这些是 AI 爬虫最可能提取的首要内容。

4.4 HTML 信噪比与语义标签

AI 爬虫成功下载了你的页面之后，下一个挑战是：从一堆 HTML 代码中识别出哪些是正文内容、哪些是导航栏、广告、页脚等「噪音」。

这就是可提取性的核心问题。页面在技术上可以被下载（可抓取性达标），但正文淹没在大量非内容代码中，AI 难以准确提取有效信息。

改善页面区域表达的基础手段之一，是正确使用 HTML5 语义标签。主要内容区域用 <main>，文章正文用 <article>，导航用 <nav>，页脚用 <footer>，侧边栏用 <aside>。这些标签主要服务文档语义与无障碍，也可能为部分正文提取和解析工具提供边界线索；它们不能单独保证正文提取正确，实际结果还取决于 DOM、模板和解析器。

一个常见的反面案例：很多网站把所有内容都放在 <div> 标签里——导航是 <div>，正文是 <div>，广告也是 <div>。对人类来说，通过视觉排版可以区分这些区域；对抓取系统来说，如果所有区域都用无语义的 <div> 承载，正文和噪音的区分会更依赖算法判断，提取稳定性也更差。

这个问题不只影响搜索引擎抓取。大模型训练数据管线在处理网页时，第一步就是用正文提取工具（业界常用的有 trafilatura、jusText 等）把正文从 HTML 噪音中分离出来——导航、页脚、cookie 提示、广告等样板内容会被丢弃，只保留主体文本。如果你的正文和广告、导航混在无语义的 <div> 里，提取工具更容易出错——要么把广告当成正文保留（污染内容质量），要么把正文连同噪音一起丢弃。语义标签在这个环节的作用是帮助提取工具做出正确的边界判断。

多语言站点的语言声明：lang 属性与 hreflang

如果你的网站有中英文（或其他多语言）版本，HTML 层面的语言声明是一个容易被忽视但影响实际的技术点。

大模型训练数据管线在正文提取之后，通常会做语言识别，用分类器判断页面的实际语言，并按各自标准过滤低置信度内容。不同数据集使用的工具和阈值并不统一：例如 C4 与 FineWeb 的语言识别方案就不能用同一个阈值概括。因此，这里不应把某个数值当成行业标准。更实际的启示是：中英无规则混杂、机器翻译残留明显、页面 lang 属性与实际语言不一致，都可能增加语言识别和内容处理的不确定性。

对搜索引擎和 AI 检索来说，语言声明同样重要。操作要点：

lang 属性。在 <html> 标签上声明页面的主要语言——中文页面用 <html lang="zh">，英文页面用 <html lang="en">。它主要帮助浏览器、辅助技术和部分处理工具识别页面语言。需要注意，Google Search 主要根据页面可见内容判断语言，而不是依赖 lang 属性；因此，正确填写是基础规范，但不能把它当作搜索或 AI 收录的单独开关。

hreflang 标签。如果同一内容有中英文两个版本，用 hreflang 标签在两个版本之间建立双向关联——告诉搜索引擎「这两个页面是同一内容的不同语言版本，请根据用户的语言偏好展示对应的版本」。格式为 <link rel="alternate" hreflang="en" href="英文版URL" /> 和 <link rel="alternate" hreflang="zh" href="中文版URL" />，两个页面各自都要包含指向对方和自身的 hreflang 声明。

语言组织。每个页面应有明确的主要语言。必要的专业术语、引文和双语对照可以保留，但大段无规则混杂会增加阅读负担，也可能给部分语言识别与质量分类流程带来不确定性。引用外文术语时，建议用「中文翻译（English Term）」的格式在首次出现时做好对照，后续保持一致。

翻译质量。如果英文版是从中文翻译而来，不自然的句式、错误术语和语境错配会直接损害读者体验，也可能影响部分检索、语言识别或质量分类流程。不同系统并不使用同一套「困惑度阈值」，因此不宜把影响归结为单一指标。对核心页面——尤其是希望在英文产品中被检索和采用的页面——建议使用专业翻译或至少经过熟悉该领域的英文审校。

图片表格：可提取性的最大障碍之一

很多企业官网把产品参数做成图片表格。图片中的文字能否被 OCR、多模态索引或具体产品解析，没有跨平台统一保证；即使能够识别，表格关系和单位也可能丢失。不要用「系统一定不会看图」解释全部情况。更稳妥的做法是保留图片展示，同时在可见 HTML 表格或正文中提供同等参数，兼顾无障碍、搜索和不同检索链路。

H 标签层级：帮助 AI 理解内容结构

H 标签（H1 到 H6）首先用于表达页面的标题层级，也有助于阅读、无障碍访问和搜索系统理解内容组织。部分网页解析或切片流程会参考标题边界，但具体实现因系统而异，不能假设每个 H2 都会被切成一个独立切片。

从编辑一致性、可读性和无障碍体验出发，建议设置一个清晰的页面主标题，并用 H2、H3 等表达真实的内容层级。这是一项内容组织建议，不是「每页只能有一个 H1」或「标题绝不能跳级」的搜索排名硬规则。标题应概括对应部分的核心意思；当解析或切片流程参考标题时，它可以为正文提供额外上下文，但不会单独决定向量位置或采用结果。

实战插曲：一个典型的排查过程

上面讲了 TTFB、JavaScript 渲染、语义标签这些技术要素。它们在实际排查中经常不是单独出现的，而是叠加的。用一个典型的排查场景来串一下：

某家建材品牌的官网，产品参数齐全，行业口碑也不错，但在百度 AI 和豆包的回答中几乎从不出现。排查过程是这样的：

第一步，查 JavaScript 渲染。按 Ctrl+U 查看源代码，搜索核心产品名——找到了，说明不是 JS 渲染问题。但同时注意到，产品参数全部是图片，源代码里没有任何参数文字。第二步，查 robots.txt——发现 User-agent: * 下有一条 Disallow: /product/，把整个产品目录都封了。技术确认这是两年前网站改版期间加的，当时产品目录还在测试阶段，为了防止搜索引擎收录未完成的页面，临时封了这个目录，上线后忘了删。

问题找到了两个：一个是 robots.txt 挡路，AI 爬虫根本进不来；一个是图片表格，即使进来了也抓不到参数。修复分两步走：先改 robots.txt（三分钟的事），再逐步把图片表格替换为 HTML 原生表格，同时为每个产品页补充一段纯文本的答案块。从修复到观察到显性引用、品牌提及或内容采用出现明显变化，这个案例中大约经历了六周——但实际周期因行业、平台和内容竞争状况而异。

这个案例的教训是：可抓取性问题往往不是单点故障，而是一串连锁障碍。你解决了一个，下一个才暴露出来。这也是为什么本章末尾的自检清单要按优先级从高到低排列——从最致命的问题查起，逐层排除。

4.5 Core Web Vitals 的 GEO 视角

Core Web Vitals 是 Google 用来衡量页面用户体验的三个核心指标。先说清楚：CWV 本身不是 AI 系统的直接评分维度。CWV 异常不等于 AI 一定抓不到内容，但它常常提示页面存在性能、渲染或脚本阻塞问题，这些问题可能间接影响抓取效率和内容可访问性——把它们当成性能风险的「预警灯」来看，就很有用。

指标	含义	目标值
LCP（最大内容绘制时间）	核心内容区域完成渲染所需时间	低于 2.5 秒
CLS（布局偏移）	页面加载过程中视觉布局的稳定性	低于 0.1
INP（交互到下一次绘制）	用户交互后页面响应速度	低于 200 毫秒

检测工具：Chrome 或 Edge 浏览器内置的 Lighthouse 面板（F12 → Lighthouse，建议在无痕模式下测试，避免浏览器扩展干扰结果），或 Google PageSpeed Insights（pagespeed.web.dev）。三个指标都可以一次测试得到。

4.6 robots.txt：最容易犯的致命错误

robots.txt 是网站根目录下的一个文本文件，告诉爬虫哪些页面可以抓取、哪些不可以。它的 GEO 风险在于一个极其常见的配置错误：无意中封锁了 AI 爬虫。

最高风险的配置是 robots.txt 中出现 User-agent: * 加上大范围的 Disallow 规则。User-agent: * 表示对所有爬虫生效——包括你可能根本没想到的 AI 爬虫。

验证方法：在浏览器中访问 https://你的域名/robots.txt，检查是否有可能影响 AI 爬虫的封锁规则。前面那个建材品牌的案例就是典型——整个团队花了几个月做内容优化，结果 AI 根本没看到过。

一个需要特别注意的区分是「训练数据爬虫」和「检索类爬虫」。以 OpenAI 和 Anthropic 为例，两家都按用途发布了不同的 user-agent：训练用的（OpenAI 的 GPTBot、Anthropic 的 ClaudeBot）、检索用的（OAI-SearchBot、Claude-SearchBot），以及用户在 AI 产品里发起临时访问时用的（ChatGPT-User、Claude-User）。不过，不同厂商对「用户触发」类爬虫是否适用或遵守 robots.txt 的口径并不一致，而且可能调整。不要仅凭本书中的静态表格做永久配置，实际部署前必须查看相应平台的最新官方文档，并用服务器日志验证真实访问情况。

如果你不希望内容被用于模型训练，但仍然希望被 AI 采用，就需要按用途分别配置这些爬虫。

推荐配置示例

下面这份配置是截至 2026 年 7 月的用途快照，参考了 OpenAI、Anthropic 和 Perplexity 当时公开的爬虫说明。这类文档会随产品迭代而调整——user-agent 名称可能更新，爬虫数量可能变化，适用范围也可能改变。实际配置前请查阅各平台的最新官方文档。本书配套网站 geobok.com 会跟进重要变更。

爬虫标识	用途	建议配置
OAI-SearchBot	ChatGPT 搜索索引	Allow: /
GPTBot	OpenAI 训练数据	按版权策略决定
ChatGPT-User	用户在 ChatGPT 中触发的临时访问	建议查官方文档后决策
Claude-SearchBot	Claude 搜索索引	Allow: /
ClaudeBot	Anthropic 训练数据	按版权策略决定
Claude-User	用户在 Claude 中触发的临时访问	建议查官方文档后决策
PerplexityBot	Perplexity 检索	Allow: /
Perplexity-User	用户在 Perplexity 中触发的临时访问	建议查官方文档后决策
Baiduspider	百度搜索	Allow: /

注：OpenAI 还发布了 OAI-AdsBot，用途是检查 ChatGPT 广告落地页，不用于训练，也不属于 GEO 检索入口；本表未纳入推荐配置，需要时请参考 OpenAI 最新爬虫说明单独决策。

Google AI 功能建立在 Google Search 的抓取和索引基础上，不需要为 AIO 另设专门的爬虫规则——如果你的网站允许 Googlebot 访问并符合 Google Search 的技术要求，你的内容就有机会作为支持链接出现在 Google 的 AI 功能中，但平台不保证一定展示。

需要注意的是，robots.txt 主要是爬虫协议层面的访问声明，不能保证覆盖所有产品侧访问、用户触发访问或第三方代理访问。对于重要站点，除了配置 robots.txt，还应结合服务器日志和访问频率监控来判断实际抓取情况。

从 GEO 角度，robots.txt 的配置需要区分两类爬虫做不同决策：

对检索类爬虫（用于 AI 产品实时搜索采用的爬虫），通常应优先保证可访问。这是 RAG 通道的入口——如果检索爬虫进不来，你的内容就无法出现在 AI 的实时回答中。

对训练类爬虫（用于收集模型训练数据的爬虫），则需要结合企业自身的版权和品牌策略单独决策。允许训练类爬虫意味着你的内容有机会进入模型的参数化记忆（第三章讲的长期通道）；屏蔽训练类爬虫则关闭了这条通道，但保护了内容的知识产权。这不是一个有标准答案的决策，取决于你的业务目标。

上面的推荐配置表就是按这个逻辑设计的：检索类爬虫默认 Allow，训练类爬虫根据企业策略决定。

4.7 Sitemap 与 IndexNow：提高页面被发现和更新的效率

robots.txt 解决的是「允不允许抓」的问题，Sitemap 解决的是「能不能找到」的问题。

Sitemap 是一个 XML 文件，列出你网站所有希望被爬取的 URL。它是帮助爬虫发现新页面最直接的方式——尤其对于网站结构复杂、内部链接不完善的情况，Sitemap 可能是爬虫发现深层内容的最可靠途径之一。

Sitemap 和 IndexNow 不能保证 AI 产品立刻采用你的页面，但能改善搜索系统发现和更新页面的效率；对于依赖搜索索引或联网检索的 AI 产品，这属于间接但重要的基础工作。

Sitemap 的 GEO 配置要点

• 格式： 使用 XML 格式，包含 lastmod 字段。

• 提交：在 robots.txt 中声明 Sitemap 位置（Sitemap: https://你的域名/sitemap.xml），这是 AI 爬虫发现你 Sitemap 的主要方式。同时建议在 Google Search Console、百度资源平台等站长工具中主动提交。

• 内容筛选： 只包含你希望被 AI 检索的页面。不要把重复内容页、临时页、管理后台页面塞进去。

lastmod 字段：容易被忽视的新鲜度信号

Sitemap 的 lastmod 字段有助于搜索系统判断哪些页面需要重新抓取，间接影响新内容进入检索链路的速度。

两个常见错误需要避免。

第一，格式无效。lastmod 必须使用 W3C Datetime 格式，否则解析器无法识别，等于没有写。建议使用包含时间和时区的完整格式，如 2026-03-15T09:30:00+08:00，日期粒度（如 2026-03-15）也可以。2026/03/15、March 15, 2026 等非标准写法都不会被识别。

第二，值不真实。lastmod 应该是对应页面内容的最后实质性修改时间，而不是 Sitemap 文件的生成时间。如果你的 Sitemap 每天自动重新生成但页面内容没有变化，lastmod 不应该每天更新——虚假的 lastmod 会浪费抓取资源，也会让搜索系统和 AI 抓取调度不再信任你的时间标记。

WordPress 用户注意： 部分 Sitemap 插件的默认行为是「每次重新生成 Sitemap 时，把所有页面的 lastmod 都更新为当前时间」。请实际抽查你的 Sitemap 输出，不要假设插件默认行为一定正确。

IndexNow：向搜索系统主动发送更新信号

Sitemap 通常以天为单位被爬虫重新访问，对刚发布或刚更新的内容有一定延迟。IndexNow 是微软和 Yandex 推动的实时 URL 提交协议：当页面新增、更新或删除时，主动向支持该协议的搜索系统发送通知，而不是等待爬虫自己发现。WordPress 用户可以通过 Rank Math 等插件自动触发提交，无需手动操作；非 WordPress 站点可以通过 API 调用实现。

内部链接：AI 爬虫的「发现路径」

AI 爬虫从你的一个页面进入后，会通过页面中的链接发现更多内容。不同爬虫的抓取预算、访问频率和页面发现路径差异很大；如果一个重要页面需要从首页点击四五次才能到达，它被及时发现和重复抓取的机会通常会下降。良好的内部链接结构可以减少核心页面成为抓取孤岛的风险。

内部链接帮助搜索系统发现页面、理解页面关系并传递导航路径。Google 的 AI 功能建立在 Google Search 体系之上；其他 AI 产品可能使用自有索引、第三方搜索、合作数据或临时抓取，不能统一概括为依赖同一种传统搜索索引。因此，保持页面可发现、可抓取和内链清楚是基础，但某个搜索引擎已收录并不是所有 AI 产品采用内容的共同前提。

确保核心内容页面之间有清晰的链接路径，使用描述性的锚文本（比如「板材环保等级对比」而不是「点击这里」），保证每个重要页面从首页出发在三次点击内可达。

近期行业内出现了一种做法：在网站根目录放置 llms.txt 文件，试图为 AI 系统提供网站的结构化摘要。Google 官方指南（2026 年 5 月）对此明确回应：「您无需为了在生成式 AI 搜索结果中占有一席之地，而专门创建新的机器可读文件、AI 文本文件、标记或 Markdown。」对于 Google 搜索来说，llms.txt 不会被特殊处理。技术可抓取性的核心工具仍然是 robots.txt、Sitemap、标准 HTML 结构和 Schema 标记——这些才是经过验证的、被主要搜索系统实际使用的协议。需要说明的是，部分独立 AI 产品或工具可能读取 llms.txt，但这尚未形成通用行业标准。在当前阶段，将精力投入到 robots.txt 和 Sitemap 的正确配置上，回报更确定。

4.8 Schema 结构化数据

Schema 不是最显眼的优化动作，但它是成本较低、搜索端收益明确的辅助优化之一。

你可以把它理解成一套给页面内容「贴标签」的方法：这部分是文章，那部分是产品信息，那是操作步骤。它不会改变读者看到的正文，但能按统一词汇向支持相应类型的搜索系统描述页面类型、实体和属性。至于其他 AI 产品是否读取并如何使用，取决于各自实现。

在 GEO 语境下，Schema 有一层明确的价值——帮助搜索系统准确理解你的页面类型和实体关系。对 Google Search 来说，结构化数据的作用有明确的官方依据；对 ChatGPT、Perplexity 这类产品，结构化数据的收益目前还缺乏公开验证，但机器可读的信号理论上有助于抓取和提取。（注：近年也有研究测试 Schema.org 与结构化链接数据的作用，初步结果显示单独部署 JSON-LD 提升有限，而与实体页面、面包屑、实体互链等组合使用时效果更明显——这与本节判断一致：Schema 降低的是被理解的门槛，不是决定采用的开关。）Schema 部署成本较低，搜索端收益明确，AI 端可能有帮助——属于值得部署的辅助优化。Schema 的前提是标注页面真实存在的内容，而不是为了 GEO 额外虚构页面没有的信息。

GEO 优先部署的 Schema 类型：

Schema 类型	适用场景	GEO 价值
Article	博客文章、行业分析、技术指南	帮助 AI 识别内容类型、作者和发布时间
Product	产品详情页	结构化呈现参数、价格、评分等关键信息
Breadcrumb	所有页面	帮助 AI 理解页面在网站中的层级位置
Organization	关于我们 / 首页	建立品牌实体与网站的关联
VideoObject	含视频的页面	让视频内容（标题、描述）可被 AI 索引
QAPage	允许用户提交多个答案的单问题页面	标明一个问题与多个用户答案之间的结构关系，不适用于普通 FAQ 页面

FAQ 和操作步骤仍然值得采用清晰的问答、列表和标题结构，但需要校准对 Schema 的预期。Google 已停止展示 HowTo 富结果；FAQ 富结果自 2023 年起被大幅限制，通常只面向知名、权威的政府和健康网站，而不是对所有网站全面开放。因此，多数普通内容站不应把 FAQPage 或 HowTo 当作获取 Google 富结果的优先手段，也没有证据证明它们能单独提高 Google AI 功能中的采用概率。其他系统是否读取这些 Schema.org 类型，取决于各自实现。对内容站，Article、Organization、Breadcrumb 和 VideoObject 通常更值得按真实业务优先维护；对产品站，Product、Offer、Organization 和 Breadcrumb 更常见。

验证工具需要分开使用：validator.schema.org 用于检查通用 Schema.org 语法和类型关系；Google Rich Results Test 用于检查页面是否符合 Google 当前支持的富结果类型。前者通过，不代表后者一定支持或展示。

如果你用 WordPress，Yoast SEO 和 Rank Math 等插件可以生成部分 Schema——Article 类型通常会根据页面类型自动生成，但仍要检查作者、发布时间、组织和页面可见内容是否一致。如果你用自建网站，可以在 HTML 的 <head> 中插入 JSON-LD 格式的 Schema 标注，让技术团队参照 schema.org 以及目标搜索平台当前支持的文档执行。

一个需要校准预期的信息。Google 官方指南（2026 年 5 月）明确指出，生成式 AI 搜索不需要专门的结构化数据或特殊的 schema.org 标记，但仍建议把结构化数据作为整体 SEO 策略的一部分继续维护。这意味着 Schema 对 Google 的 AI Overviews 和 AI Mode 不是必要条件。它在 Google Search 中的明确价值，是帮助系统理解符合支持规范的页面信息，并可能获得相应搜索展示；对于其他 AI 产品，目前缺少可概括为统一规则的公开证据。正确的优先级是：先保证可见正文真实、完整、结构清楚，再把 Schema 作为与正文一致的机器可读补充，不把它写成 AI 采用的核心开关。

还要注意，页面并不是企业向搜索与 AI 生态提供结构化信息的唯一入口。对于适用的商品和本地业务，Google 官方建议同步维护 Merchant Center Feed、Google Business Profile 等第一方数据入口；微软也建议本地企业维护 Bing Places。它们主要服务各自平台的产品、地点和实体信息，不是跨平台通用的 GEO 技巧，但比在网页里反复堆同一段介绍更直接、更可控。

4.9 存量内容治理：重复、冲突、薄页面与过期内容的处理

前面几节讲的都是新内容该怎么做。但如果你的网站已经运营了几年，很可能积累了大量「技术上能抓到、但对 AI 没有价值」的页面——它们不是打不开，而是信息含量太低，或者互相矛盾。

这类页面带来的问题不只是「没效果」。它们会制造噪声：同一个产品在不同页面上参数对不上，AI 在综合信息时很难形成稳定判断；大量只换了一个城市名的模板页面，切出来的内容块在向量空间中高度重叠，不会为任何具体问题增加新的匹配价值。

值得一提的是，大模型训练数据管线在处理互联网内容时，也在做本质相同的「存量治理」——URL 去重、文档级近似去重（通常使用 MinHash 算法检测高度相似的文档）、行级重复检测、模板噪声清理。你的网站在 AI 眼中就是一个待清洗的数据集：URL 重复对应你的参数页和筛选页被大量收录，文档重复对应你的城市分站只换了地名，行级重复对应每个页面都重复同一段厂商介绍。下面这四类问题，在训练数据管线和网站治理中几乎一一对应。

第一类：重复页面。 典型场景是本地服务站做了几十个城市分站，每个分站的内容几乎一模一样，只换了城市名。还有一种是同一篇文章被发布在多个 URL 下（带参数的分页、标签页自动生成的聚合页）。处理方式：合并为一个权威页面，其余页面用 canonical 标签指向它，或者做 301 重定向。

第二类：同一件事，不同页面说法冲突。 比如产品 A 的参数在产品页写的是「续航 8 小时」，在对比页写的是「续航 6-10 小时」，在 FAQ 里又变成了「长续航」。AI 如果同时检索到这三段，很难判断哪个是准确的。处理方式：确定一个标准口径，全站统一。建议维护一份核心实体参数表（产品名、型号、核心参数、适用场景的标准说法），内容团队每次写新内容时以此为准。

第三类：模板化薄页面。 大量产品页只有型号名加一句「欢迎咨询」，没有任何场景、参数或判断依据。这种页面对 AI 来说接近空白——切出来的内容块信息量极低，被高质量采用的概率很低，即便偶尔被召回，也很难支撑起一段可用的回答片段。处理方式：要么补充真实内容（适合什么场景、核心参数是多少、跟同类产品有什么区别），要么对这些页面设置 noindex，避免它们继续进入传统搜索索引。注意，noindex 和 robots.txt 作用不同：如果目标是让搜索引擎看到 noindex 指令并停止索引，不要同时用 robots.txt 阻止它抓取该页面——否则搜索引擎可能无法读取到 noindex 指令。如果目标是减少无价值页面被抓取，可以在确认索引处理策略后再考虑页面合并或其他方案。

第四类：过时内容。 价格、政策、标准、软件版本、产品型号这类信息变化快。一篇两年前写的选购指南，如果还在推荐已经停产的型号，对 AI 来说就是一份会误导用户的来源。处理方式：不一定要删除旧内容，但至少做两件事——在页面上标注更新日期和适用范围，同时在内容中更新已经过时的数据。第八章 8.7 节有更详细的定期内容刷新机制。

存量治理不是做一次就完事的。建议每季度花半天时间扫描一遍核心页面，重点检查参数一致性、内容重复度和数据时效性。这件事的投入产出比往往比写新文章还高——清理掉一批互相矛盾的旧内容之后，AI 对你剩余内容的理解会更稳定。

4.10 30 分钟可抓取性自检清单

这一章内容偏多。以下是一份可以在 30 分钟内完成的自检清单，帮你快速定位最高优先级的问题。按照影响程度从高到低排列：

• JavaScript 渲染检查（优先级最高）。对每个核心页面按 Ctrl+U 查看源代码，搜索最关键的产品名或结论。找不到 = 存在明显的 AI 不可见风险，建议优先修复。

• robots.txt 检查。访问 https://你的域名/robots.txt，确认没有封锁主要 AI 爬虫。如果有 User-agent: * 加 Disallow，逐条检查是否影响 AI 爬虫。

• TTFB 检测。在 Chrome DevTools 的 Network 面板查看核心页面的 TTFB（Waiting for server response），或访问 pagespeed.web.dev 查看服务器响应时间。工程上建议尽量压到 200–500ms 区间；如果长期超过 500ms，建议优先排查。

• 语义标签检查。查看页面源代码，确认正文被 <main> 或 <article> 包裹，导航、页脚、侧边栏各自有正确的语义标签。

• 图片表格检查。确认核心产品参数是否使用 HTML 表格。如果参数是图片形式，标记为需整改。

• Sitemap 检查。确认 Sitemap 存在且 lastmod 真实准确，已在 robots.txt 中声明 Sitemap 路径。

• 标题层级检查。确认页面有清晰的主标题，H2/H3 等标题反映真实内容层级，标题文字能概括对应部分；不要把「只能有一个 H1」或「绝不能跳级」当作搜索排名硬规则。

• Schema 检查。先用 validator.schema.org 检查通用 Schema.org 语法，再用 Google Rich Results Test 检查 Google 当前支持的富结果。内容站优先检查 Article、Organization、Breadcrumb，产品站优先检查 Product、Offer、Organization；不要再把 FAQPage 或 HowTo 视为 Google 富结果优先项。

• 语言声明检查（多语言站点）。确认 <html> 标签的 lang 属性与页面实际语言一致（中文页面 lang="zh"，英文页面 lang="en"）。如果同一内容有多语言版本，确认两个版本之间有正确的 hreflang 双向关联。

如果这些检查项中有任何一项亮红灯——尤其是前三项——建议优先修复这些基础问题，再进入内容层面的 GEO 优化。地基不稳，上面的内容优化很难真正发挥作用。