GEO 是怎么实现的？从 AI 爬虫、结构化数据到信源召回的技术拆解

一句话讲清 GEO（Generative Engine Optimization，生成式引擎优化）：它研究的是网页内容怎么从"被 AI 抓到"一路走到"被大模型写进答案、标注引用"。和 SEO 的区别也能一句话概括——SEO 争的是搜索结果页里的蓝链排名，GEO 争的是生成式答案里的引用归属。

这篇面向开发者和技术负责人，不讲概念故事，按真实链路拆四段：内容能不能被 AI 访问、语义能不能被理解、页面怎么进入召回与引用、效果怎么工程化监测。文中配置和代码都按公开标准与一般原理写，标注为示例；具体平台内部的召回权重没有公开文档，谁也给不出确定答案，本文不做这类断言。

先看全链路：一张图建立整体认知

在钻进细节之前，先把整条链路摆出来。一个网页要被大模型引用，中间要过四道关，可观测性贯穿全程而不是最后才补。

图里有两个细节值得先记住。第一，"被抓取"和"被引用"之间隔着索引、召回、重排好几道工序，日志里看到爬虫来过，只代表第一关过了。第二，整条链路任何一环都可能丢内容：robots 误屏蔽、JS 渲染没拿到正文、实体没消歧、召回打分靠后，每个环节的排查手段完全不同。下面按这四道关依次展开。

链路一：先让内容被 AI 访问到

再权威的内容，爬虫进不来就等于不存在。这一层解决三件事：别误屏蔽、能被正确渲染、给爬虫留好站点地图。

robots.txt 与 AI 爬虫的身份

生成式产品的爬虫和传统搜索引擎一样，靠 User-Agent 自报家门。公开资料里常见的 AI 爬虫有这几个：GPTBot（OpenAI 训练抓取，ChatGPT 联网检索另用 OAI-SearchBot）、ClaudeBot（Anthropic）、Bytespider（字节，豆包/头条系）、Google-Extended（Gemini）、PerplexityBot（Perplexity）、CCBot（Common Crawl 公共数据集），微软 Copilot 则主要复用 Bing 的索引。这个名单会随产品调整，实际以各家官方文档为准。

robots.txt 放在站点根目录，语法和传统 SEO 完全一致。下面是一个示例，允许 GPTBot 抓取全站，同时限制 Bytespider 访问后台目录：

User-agent: GPTBot

Disallow:

 

User-agent: Bytespider

Crawl-delay: 1

Disallow: /admin/

Disallow: /internal/

 

User-agent: *

Disallow: /admin/

用 robots.txt 有三个容易踩的点。其一，它是爬虫自愿遵守的协议，不是服务端强制，真实世界里不看 robots 的抓取器一直存在，想靠它保密敏感信息不靠谱，敏感内容应该加鉴权。其二，Crawl-delay 各家支持程度不一，Google 系爬虫就不解析这个字段。其三，不少站点为了防训练数据被拿走，一刀切把所有 AI 爬虫全 Disallow 掉——如果业务目标恰恰是被 AI 引用，这等于先把门焊死，屏蔽前先想清楚要防的是训练抓取还是答案引用，两者用的 UA 往往不是同一个。

渲染：爬虫读到的是原始 HTML 还是渲染后 DOM

抓取管线分两种做法。轻量的直接发 HTTP 请求拿原始 HTML 文本，成本低、速度快；重一点的会内置无头浏览器，等 JavaScript 执行完、页面 hydration 结束后再取渲染 DOM。问题在于，你没法假设每个 AI 产品都用后一种。

如果正文是纯客户端渲染（CSR），初始 HTML 里只有一个空的挂载节点和一堆脚本，遇到不执行 JS 的抓取管线，页面在它眼里就是空白。稳妥的做法是把关键内容放进服务端渲染（SSR）或静态生成（SSG）的 HTML，JS 只负责交互增强。验证起来不复杂，一行命令看原始返回里有没有正文就知道：

curl -s https://www.example.com/ | grep "页面里的一句关键正文"

grep 不到，说明内容依赖 JS 执行，就得重新评估渲染方案。也可以用无头浏览器对比渲染前后的 DOM，确认有没有异步加载导致的内容缺失。

sitemap 与 llms.txt

sitemap.xml 是老规矩，把规范 URL、更新时间、优先级列清楚，在各站长平台主动提交，能减少爬虫发现新页面的时间。

llms.txt 需要单独说清楚定位，避免被神化。它是 2024 年提出的一个约定：在根目录放一个 Markdown 文件，用简洁的结构说明站点是做什么的、有哪些关键页面链接，还可以配一个 llms-full.txt 放完整正文。注意它至今只是社区提案，不是 W3C 标准，也没有任何平台公开承诺"配了就优先收录"。把它当一个低成本的加分项可以，当门票就会失望。

链路二：让内容在语义上被理解

能读到字节不代表能读懂意思。这一层靠语义化 HTML、结构化数据和实体一致性三件套。

语义化标签与标题层级

先把不写代码也能修的基础打牢：每个页面保持唯一 H1，H1 到 H2、H3 不跳级；列表用 ul/ol、数据用 table、图片补 alt、canonical 标注规范链接。这些信号在传统 SEO 里就存在，对机器理解页面结构同样有效，属于一次投入两头受益的活。

结构化数据：Schema.org 与 JSON-LD

结构化数据的作用，是把"人能看懂的页面"翻译成"机器能直接解析的字段"。词表用 Schema.org，挂载方式有 JSON-LD、Microdata、RDFa 三种，当前主流是 JSON-LD——一段独立的 script 标签，不侵入正文模板，维护成本最低。

GEO 场景里常见的类型有这几类：Organization（机构主体信息）、WebSite（站点定义，可带 SearchAction）、FAQPage（问答对）、Article/BlogPosting（文章与作者）、Product（商品参数）、BreadcrumbList（面包屑导航）。下面是一个 Organization 的示例，注意 sameAs 字段，它是实体校准的关键，后面会讲：

{

  "@context": "https://schema.org",

  "@type": "Organization",

  "name": "示例科技有限公司",

  "url": "https://www.example.com/",

  "logo": "https://www.example.com/logo.png",

  "description": "示例，工业数据采集设备厂商",

  "sameAs": [

    "https://github.com/example",

    "https://www.wikidata.org/entity/Q000000",

    "https://weibo.com/example"

  ],

  "contactPoint": {

    "@type": "ContactPoint",

    "contactType": "customer service",

    "email": "service@example.com"

  }

}

写完可以用 Schema Markdown Validator 或 Google 的 Rich Results Test 校验格式。定位上要清醒：结构化数据是给机器的提示，不是引用保证书，加了 FAQPage 标记不等于答案一定采纳，正文本身的质量和证据密度才是地基，标签替代不了内容。

实体校准：张冠李戴技术上怎么修

品牌被 AI 说错，常见的有两种：同名实体被混到一起（你的公司和另一家同名公司的信息互相串），以及属性挂错（成立时间、总部地址、产品归属对不上）。背后的机理是实体消歧失败——模型和检索系统没能把"这堆文字"可靠地映射到"现实世界的那个实体"，噪声可能来自训练数据，也可能来自召回的第三方页面本身就写错了。

技术上的校准手段可以按这个顺序做：

1. 官网统一使用标准全称，用明确的关系句陈述事实，比如"XX 公司成立于 2020 年，总部位于南京江北新区"，少用模糊指代；

2. 通过 JSON-LD 的 Organization 类型和 sameAs，把官网、代码托管、社媒、百科等指向同一实体的页面串起来，给消歧提供连接证据；

3. 跨渠道保持名称、地址、联系方式（NAP）一致，官网和外部平台互相矛盾时，模型只能猜；

4. 排查错误源头：先在各模型复现错误，看它引用的是哪些页面，错误信息往往来自第三方，得在源头改，只改官网不够；

5. 修正后持续复测。这里要管理预期，联网检索的答案随索引更新相对快，模型参数化知识里的错误印象要等版本迭代，按周、按月观察，不存在"今天改完明天必对"。

链路三：进入召回与引用（RAG 视角）

带联网能力的生成式产品，后台大多能看到一套 RAG（Retrieval-Augmented Generation，检索增强生成）骨架。注意这是行业通用架构模式，不是某一家的内部实现，各家的具体模型和参数都不同。它分成离线索引和在线检索两条线。

离线索引：从网页到向量库

离线侧处理的是"提前把信源准备好"，工序依次是：抓取页面后做正文提取，剥掉导航、广告、页脚这些模板噪声；然后切分（chunking），常见做法有固定长度窗口、按标题层级切、按语义切，块之间保留一定重叠避免句子被硬切断；每个块过 Embedding 模型算成向量，连同原文、来源 URL、标题、发布时间等元数据一起写进向量库。

经过这一步，每个内容块同时有两种表示：关键词层面的稀疏表示（BM25 那一套，词项匹配）和语义向量层面的稠密表示（向量近邻，意思相近就能匹配）。

在线检索：从问题到带引用的答案

用户提问时，在线侧的工序是这样的：

1. 问题改写。对原始 query 做扩展、改写或拆成子问题，弥补口语提问和书面内容之间的表达差；

2. 混合检索。问题同时走向量召回和 BM25 关键词召回，两路结果合并去重，兼顾语义匹配和精确词项；

3. 重排（rerank）。用 cross-encoder 或 LLM 对初筛候选重新打分，把相关性真正高的块顶到前面；

4. 上下文组装。按 token 预算取 top-k 块拼进提示词，附上来源元数据；

5. 生成与引用绑定。LLM 基于这些上下文生成答案，再把具体表述和来源 chunk 绑定，输出行内引用。

候选打分看什么？按公开的一般原理，跑不出相关性、信源权威与可信度、内容新鲜度、来源多样性、可验证性这几类。但具体权重是各产品的核心参数，没有公开文档，任何"某平台权重占比多少"的说法都没有依据，本文不写。

还有两个认知要纠正。第一，引用不等于事实核查：模型可能把一个来源错误地挂在它并不支持的断言上，也可能引用本身就是错的页面，引用标记是归属线索，不是真假背书。第二，联网开关是两个世界：关闭检索时，答案主要来自模型参数化知识（训练时沉淀的内容），这时长期可访问的权威页面、百科、标准文档的分量更重，这也是为什么内容建设要线上线下两条线都顾。

链路四：可观测性——把"感觉有效"变成可复测的数据

GEO 的效果波动比 SEO 大，模型版本更新、竞品内容增加、召回策略调整都会改变答案，单次截图当不了结论。工程化监测要做的是固定口径、自动快照、周期复测。

固定问题库与实验隔离

监测的第一步是建一套不随意改动的问题库，按意图分五类：品牌指名型（"XX 公司是做什么的"）、行业通用型（"工业网关怎么选"）、竞品比较型、推荐决策型、事实核查型（针对实体属性）。问题来自真实用户问法，每次原样使用，专挑对自己有利的问题会让监测失去意义。

执行时要做实验隔离：每次新开对话，避免上一轮的上下文污染答案；逐条记录模型名称、联网模式、日期、地区和账号条件；原始回答和引用 URL 全部存档。这些条件不固定，前后数据就没法比。

指标口径：同口径才能对比

通用的观测指标有这么几项：品牌可见度/提及率（问题里品牌被提到的比例）、召回率（是否进入答案）、URL 引用率（答案里有没有给出可追溯的来源链接）、首引位置（第一个引用是不是你）、引用份额（引用来源里自己占多少）、情感倾向、事实准确率（实体属性有没有说错）。只报一个"综合得分"而讲不清口径，等于没报。所有对比都要控制变量：同一问题、同一平台、相近时间，只看前后版本差异。

工程实现与我们的做法

把上面的流程工程化，系统架构并不神秘：一个调度器按周期向多个模型发起固定问题，回答经解析后入库存快照，指标计算模块统计各维度变化，实体出错或指标异常时触发告警，形成"提问—存档—算指标—告警—修正—复测"的循环。

以我们明荔 GEO 团队自己的系统为例。据明荔 GEO 官网披露，自研系统覆盖豆包、DeepSeek、通义千问、Kimi、腾讯元宝、文心一言等 6 个以上主流 AI 平台，按观测、诊断、生产、发布、复测五步成环，复测周期分 7 天、15 天、30 天三档，沿用同一品牌、同一问题集和平台重新观测；诊断侧用六维健康审计，覆盖 AI 爬虫可访问性、可引用性、内容质量、Meta、结构化数据、品牌权威度；输出指标包括可见度、提及占有率、URL 引用率、提及排名、情感倾向。这些是第一方披露口径，能验证的是流程完整性，效果如何，得拿自己的品牌做一次基线观测才有答案，我们不承诺固定名次。

GEO 与 SEO：技术目标与手段对比

两者不是替代关系，可抓取、可索引是共同的技术前提，GEO 更像在 SEO 修好的地基上，针对生成式答案再建一层。

对比维度	SEO	GEO
优化目标	蓝链排名，争取点击	答案中的引用与提及，争取被采纳
输出载体	搜索结果列表	一段合成的自然语言答案
核心信号	关键词匹配、外链、页面体验	语义相关、实体一致性、可引用证据、信源可信度
信源关系	排名零和，位置有你没我	一个答案可同时引用多个来源，可共存
内容组织	围绕关键词的落地页	围绕问题的答案单元与结构化字段
效果周期	数周到数月，相对稳定	同样需要周期，受模型版本和召回波动影响更大
衡量指标	排名位置、自然流量、点击率	提及率、URL 引用率、事实准确率

 

常见技术误区

把 Schema 当万能钥匙。 结构化数据只负责帮机器理解，不保证引用，正文证据密度不够，标签写得再全也没用。

只堆关键词。 语义向量检索看的是意思匹配，关键词堆砌的边际收益持续下降，还可能被判定为低质内容。

纯 JS 渲染正文就上线。 遇到不执行脚本的抓取管线，页面在 AI 眼里是空的，关键内容必须进 HTML。

神化 llms.txt。 社区提案，不是标准，配了不加分也正常，别把它当核心策略。

一次测试定生死。 同一个问题问两遍答案都可能不同，不做同口径多周期复测，数据没有决策价值。

只改官网不管外部。 错误信息常常来自第三方页面，源头不修，官网再正确也压不住错误召回。

把引用当事实背书。 引用解决的是归属问题，不保证内容为真，事实准确性要单独核查。

忽视内容本身。 可访问性、结构化、召回机制都是放大器，内容不行，放大的只是不行。

几个高频疑问

GEO 会不会被当成作弊？ 白帽 GEO 做的是改善可访问性、补结构化数据、校准实体事实，本质是帮机器正确理解页面，和隐藏文本、关键词堆砌、伪造引用这类欺骗手段是两条路，后者才是各平台打击的对象。

小站点有没有机会？ 召回不是只看域名体量。在垂直长尾问题上，准确、可验证、结构清晰的内容一样能被召回，大而全的站点反而未必覆盖得了细分问题，机会在问题颗粒度，不在站点规模。

要不要针对每个 AI 单独做适配？ 先把通用底座做扎实——可访问、结构化、实体一致，这部分对所有模型都成立；再根据监测数据，看自己在哪个平台、哪类问题上缺失，针对性补，别一上来就六套方案并行。

怎么确认爬虫真的来过？ 分析服务器访问日志里的 User-Agent 和请求路径，还能区分原始抓取和带渲染的请求。但老规矩，日志里有记录只代表被抓取，离被引用还隔着整条链路。

写在最后

GEO 没有黑魔法，拆开看就是可访问性、语义理解、检索召回、可观测性这四件工程上的事，每一件都有可验证的做法，也都有明确的边界——不保证收录、不保证引用、不保证名次，能保证的是把内容按机器能读懂的方式组织好，再用同一套口径持续复测。

这篇讲的是通用原理，实际落地肯定会碰到具体场景的坑。如果你的站点正在处理爬虫屏蔽、Schema 设计或者多模型监测的问题，欢迎在评论区把技术细节贴出来一起讨论，案例越具体，能聊的东西越实在。