上个月翻博客，瞥见那篇讲 Node.js 事件循环的老文章——写的时候觉得“这下够透了”。第二天拿 ChatGPT 试了个相关问题，它却拽出一篇内容更泛的教程。那个瞬间我才反应过来：东西写得再硬，AI 检索时压根“看”不见你，这不就是在无人区里喊破嗓子么。

这跟 SEO 已经完全不是一回事了。2024 年印度理工和普林斯顿那篇论文提出 GEO 的时候，圈子里大多觉得这就是 SEO 套了个新壳。两年过去，到 2026 年，全球用生成式 AI 做搜索的用户已经超过 15 亿。也就是说，你写的文章在 ChatGPT、Perplexity、豆包这些引擎里能不能被当作素材引用，直接决定了你的内容有没有“活”在别人眼前的资格。

概念定义我不想再铺了。直接扎进三个最底层的技术环节：RAG 怎么判定你的内容值得被捞出来、结构化数据到底怎么给 AI 指路、语义网络如何让你的内容在知识图谱里占一个节点。把这些搞明白，你才知道力气往哪使。

AI 读内容的方式变了，别再拿 SEO 的逻辑去套

传统 SEO 的核心是关键词匹配。你拼命堆“最好的跑步鞋”，Google 就给你排在前面。生成式 AI 不一样，它理解的是“用户想买一双适合扁平足的缓震跑鞋，预算一千以内”这个意图，然后从知识库里拼出一段定制化的答案。

差别在哪？SEO 争夺的是排名位置——列表里的第几位；GEO 争夺的是被引用的概率——答案段落里那个来源标注。

拿我自己做过的一个测试说。一篇讲“微服务链路追踪”的文章，在 Google 搜标题能排到第一页第二位。但扔到 ChatGPT 问“如何实现分布式追踪”，它引用了另一篇带 OpenTelemetry 配置示例的。原因是那篇文章有完整的 JSON-LD 标记和 FAQ 结构，AI 检索时判定它更结构化、更可信。我输在没给 AI 铺路。

所以真别用 SEO 的惯性去做 GEO。优化对象从爬虫变成了语言模型的检索模块，这是两套完全不同的打分逻辑，不能混着用。

RAG retrieval augmented generation workflow diagram

RAG 是怎么工作的，以及你写的段落怎么才能被它挑中

现在主流的 AI 搜索引擎——ChatGPT 的联网模式、Perplexity、Google 的 SGE——背后都跑着 RAG（检索增强生成）。流程拆开来就四步：用户提问 → 检索器去索引里找相关片段 → 把片段拼进 Prompt → 大模型生成最终答案。

最关键的其实是第二步。检索器不是靠语义相似度漫无目的地捞东西，它有明确的偏好：

  • 相关性：你的段落是否直接回答了用户的问题。写“Redis 缓存策略概述”不如写“Redis 缓存穿透的三种解决方案”更容易被命中。
  • 权威性：引用来源的域名权重、作者资历、外部链接数量。RAG 系统内部会给每个来源打一个可信度分，这个分数直接影响它在答案里出现的位置。
  • 时效性：2026 年的文章还在讲 2023 年的技术细节，检索器会自动降权。我见过一个案例，一篇讲 Kubernetes 1.22 的博客，因为没有更新版本号，在 AI 答案中被另一篇讲 1.28 的文章替代了。
  • 结构化程度：纯文本段落跟带标题、列表、表格的段落比，后者被切片的粒度更细，更容易匹配到具体的问题。

实战上不复杂。写文章时，每个小标题下的第一段尽量直接回答问题——因为 RAG 切片经常只取前 100 个 token 当摘要。比如你写“Docker 镜像优化”，开头第一句就写“Docker 镜像优化的核心是减少层数和利用构建缓存”，别写“随着容器化技术的普及……”。AI 检索时，前者直接命中，后者被直接忽略。

Structured data JSON-LD schema markup example

结构化数据不是装饰，是给 AI 画的一张地图

这块我踩过最深的坑。去年给一篇“Python 异步编程入门”加了 JSON-LD 标记，但只写了 Article 类型。AI 检索时，竞争对手那篇带 FAQ 标记和 HowTo 步骤的文章被当成了“标准教程”。我的内容明明更全面，但因为缺少明确的“问题-答案”结构，检索器判断它“不够直接”，所以没用它。

Schema 标记不是摆着好看的。对于技术内容，最实用的几个类型：

  • FAQPage：把常见问题写成 Question + Answer，RAG 检索时几乎 100% 命中。
  • HowTo：带上步骤、工具、耗时预估。AI 生成“如何做”类的答案时优先引用。
  • TechArticle：带 proficiencyLevel（难度等级）、dependencies（依赖环境）等扩展属性，让 AI 知道你这篇是入门还是进阶。

我测试过的一个配置：在博客页头 JSON-LD 里同时嵌入 FAQ 和 BreadcrumbList，AI 检索时的片段召回率提升了差不多一倍。但要注意，别把 FAQ 堆在页面底部，RAG 切片可能截不到。放在正文之后、评论之前，检索器能完整抓到。

语义网络优化：让你的内容在 AI 的知识网里占据一个枢纽

大模型内部维护着一张巨大的知识图谱。实体之间有关联：Redis 属于 NoSQL 数据库，NoSQL 数据库又属于数据存储层。你写文章如果不明确建立这些语义关联，AI 不知道你的内容属于哪个“知识板块”。

实操方法有三个。

第一是主题集群。别零散地写“Redis 实战”“MySQL 索引优化”“消息队列选型”，而是围绕“后端数据层架构”这个核心实体，写一组互相引用的文章。每篇文章内部链接都用锚文本传递上下文——比如“关于缓存策略，详见我们的 Redis 缓存穿透解决方案”，而不是“点击这里”。

第二是外部引用。AI 对带引用来源的陈述更信任。我写“WebSocket 在实时协作中的延迟表现”时，引用了两家 SaaS 厂商的公开 benchmark，并且标注了测试环境版本。AI 在生成答案时，把我的段落作为“有来源支撑”的结论优先采用，而不是那些只写“据研究表明”的空话。

第三是实体定义。当你在文章里提到技术名词，花一句话给出精确定义。比如写“JWT（JSON Web Token）是一种无状态认证协议，由 Header、Payload、Signature 三部分组成”。这帮助 AI 建立实体关系，后续任何关于“无状态认证”的查询都可能关联到你这篇。

具体怎么落地，按这个顺序来就行

别想着一次性改造整个站。急不来。

第一步：内容审计。拿你现有最核心的 10 篇文章，用 Perplexity 或 ChatGPT 的联网模式搜相关关键词，看它们引用的是不是你。记录下哪些问题你的内容没被引用，分析差距在哪——是没结构化，还是权威性不够。

第二步：结构化改造。从被漏掉的文章开始，加 FAQ 和 HowTo 标记。别贪多，一篇一篇来。我自己的经验是，每篇加标记大概花 15 分钟，但效果立竿见影。

第三步：语义增强。在每篇文章开头补充实体定义和上下文描述。把原来“Redis 是一种缓存”改成“Redis 是一种基于内存的键值存储系统，常用于缓存、会话管理和实时排行榜场景”。这种改动不影响人类阅读，但 AI 能从中提取更多实体关系。

第四步：持续监控。每月随机抽 5 个业务关键词，用 AI 工具查引用来源。如果发现某篇文章被替换了，去分析竞品多了什么——可能是新鲜度、结构化程度或外部引用。迭代没有终点。

今年做 GEO 你会发现，多模态这块已经躲不掉了。图片 Alt 得写到位，视频加章节标记，表格里的 th 标签别偷懒——AI 抓取结构化信息时，这些细节直接决定它愿不愿意引用你。更关键的是实时数据：那些接了实时 API、能吐出最新行情或动态的页面，在 AI 生成答案里排名飙得飞快。别指望靠一篇静态文章吃半年，引擎越来越挑食了。

检索器其实没你想的那么复杂。它要什么，你就给它什么——这话听起来像废话，但真正做到的站点真没几个。等AI彻底把你忽略再想起来动手，那就晚了。