Google官方那份《为生成式AI功能优化网站》文档把话挑明了：AEO和GEO本质还是SEO，因为AI Overviews和AI Mode靠RAG加查询扇出，从同一个Search索引里取内容。结论很直接——llms.txt、内容切块、为AI改写文风、刷露出、专门为AI加结构化数据这五件事对Google的AI功能基本无效；真正决定能不能被引用的，是别处搜不到的独到内容加上能被正常索引、能被切出片段的技术底子。agentic和UCP是前瞻可选项，不是现在的KPI。下面把机制、可验证的取舍、以及这套为什么只对Google成立讲透。

先说一句让不少人不舒服的话：过去一年市面上卖的那些“GEO专项优化”，有相当一部分动作，Google现在用官方文档亲口说了——不用做。

这份文档叫《Optimizing your website for generative AI features on Google Search》（为Google搜索的生成式AI功能优化你的网站），是Google在2026年5月放出来的。它不是又一篇语焉不详的官方博客，而是把过去散落在大会演讲、播客、零星帖子里的态度，第一次拢成一份可以引用的参考。它接着2025年那批AI功能文档往下写：早先那批讲的是AI功能怎么工作、怎么控制是否被收录、怎么看效果报告；这一份开始正面给优化建议，并专门辟了一节告诉你哪些流行做法可以直接扔掉。

保哥手上有个北美家居类目的DTC独立站客户，月营收三十多万美金，2026年初被一个服务商说动，花了一笔钱上了llms.txt、把产品长文切成几十个“AI友好块”、又按某套模板给每页塞了一堆结构化数据。两个月跑下来，AI Overviews里的露出没什么变化，自然流量还因为切块把几篇本来排得不错的长文打散，掉了一截。文档出来那天他发消息问：“是不是被收割了？”——这篇就从这个问题讲起，把官方说法掰开揉碎，再补上文档没讲、但你真正要知道的那部分。

这份官方文档凭什么一句话把AEO和GEO定性成“还是SEO”？

文档里有一句话是整份文件的地基：“从Google搜索的角度看，为生成式AI搜索做优化，就是为搜索体验做优化，因此仍然是SEO。”它顺手给了定义：AEO是answer engine optimization（答案引擎优化），GEO是generative engine optimization（生成式引擎优化）。这两个词不是Google发明的，是行业造出来卖课用的；Google的态度是——叫什么都行，做的事没变。这一立场和Google员工此前在Search Central Live上的说法一致：Gary Illyes和Cherry Prommawin都讲过，GEO和AEO不需要独立的框架。

这话不是嘴硬。它背后是一个具体的技术事实：Google的AI功能依赖检索增强生成（RAG）和查询扇出（query fan-out），从Search索引里取内容。这半句话信息量极大，值得拆开。

RAG加查询扇出，AI的答案是怎么从你站里被拼出来的

很多人以为AI Overviews是大模型“凭记忆”写的，所以拼命想办法把品牌“喂”进模型。这是方向性的误解。Google AI功能的实际链路更接近这样：

你问一个问题，系统不会拿这一句直接去生成答案。它先做查询扇出——把你这一个问题，拆成一组它自己合成的子查询。每一条子查询，都去同一个Search索引里跑检索，召回一批页面和片段；这些召回结果经过排序、去重、筛掉垃圾，喂给大模型，模型在这些“检索到的真实片段”基础上生成那段话，并标注引用。

举个具体的：用户问“适合小户型的整体厨房怎么选”，扇出大致会拆成“小户型厨房布局原则”“整体橱柜常见尺寸”“开放式厨房油烟怎么治”“整体厨房预算区间”等若干条。注意，用户从没输入过“油烟”这个词，是系统替他想到的。如果你那篇厨房选购长文里恰好有一段把油烟问题讲到了别处没有的程度，那条子查询召回时你就在集合里，这段就可能被引——哪怕主词“整体厨房”你根本没排到第一。

看懂这个链路，三件事自然就清楚了。第一，你不是在优化模型，你是在优化召回——能不能被引用，取决于子查询检索时你的页面在不在召回集里、片段够不够好，这跟传统SEO的“被检索到”是同一件事。第二，查询扇出意味着排在主关键词第一页已经不够了，那些被扇出来的、你可能从没研究过的长尾子问题，谁答得准谁被引。第三，既然走的是Search索引，那些试图“另开一条AI专属通道”的做法（llms.txt、AI专用文件）天然就不在这条链路上——它们根本不参与召回。

“同一个Search索引”这半句，为什么是全文最关键的

记住这句：AI功能和蓝链搜索共用一个索引。不是Google为AI又爬了一遍、建了个新库。这意味着你的页面要进AI功能，前置条件和进普通搜索结果完全一样——能被抓取、能被索引、内容质量过得了核心排序那一关。

这也解释了为什么文档敢说“这还是SEO”：它不是公关话术，是架构决定的。一个进不了Search索引的页面，给它做再多“GEO优化”都是零，因为它压根没机会被任何子查询召回。反过来，一个本来在传统SEO里就扎实、主题覆盖全、被信任的页面，它在AI功能里的起跑线天然就靠前。GEO不是SEO之外的新赛道，是SEO这条赛道在AI出口处的延伸。

Google点名叫停的五个动作，哪些正好是GEO课在卖的？

文档专门有一节叫“Mythbusting generative AI search”（生成式AI搜索辟谣），逐条点了五类“对Google搜索而言没必要”的动作。下面按机制重排，并补上每条“怎么自己验证”，因为光说“没必要”你未必敢停，得知道为什么、怎么自查。

被叫停的动作	课程/服务商常见话术	Google官方实际说法	机制层面的原因
做llms.txt等“喂AI”文件	不做AI就读不到你	无需创建机器可读文件/AI文本/专门标记	AI走Search索引召回，这类文件不在链路上，也不给特殊待遇
把内容切成小块（chunking）	大模型只能吃小块	不需要，系统能理解一页里多主题并展示相关片段	段落级索引早就替你切了，手动切反伤语义连贯
为AI重写文风、堆长尾变体	要写成AI喜欢的句式	AI懂同义词和大意，不必为AI改写	语义匹配不是字面匹配，堆变体是旧时代关键词思维
刷各种“被提及”	多平台铺mention才会被推荐	刷不真实的提及没那么有用	核心排序按质量、其它系统拦垃圾，刷量被抵消
专门为AI加结构化数据	不加schema AI看不懂	对生成式AI非必需，没有专门schema	富结果该做，但那是为rich result，不是为AI理解

llms.txt和各种“喂AI”文件：Google为什么根本不读

文档原话是：站点不需要为生成式AI搜索的呈现去创建机器可读文件、AI文本文件、标记或Markdown。Google确实会发现并索引HTML之外的很多文件类型，但这些不会获得特殊待遇。

把这句话翻译成机制：llms.txt之类文件的设想是“给AI准备一份精简版站点说明”，可Google AI功能的内容来源是Search索引里那些被正常抓取索引的页面，不是某个根目录下的txt。你额外放一个文件，它要么被当成普通文件随大流处理，要么干脆不影响召回——它不在RAG那条链路上。这跟“Google会不会读robots.txt”是两码事：robots.txt是抓取协议的一部分，llms.txt不是任何已被Google承认的协议。

要说清一个容易被带偏的点：llms.txt这个提案本身不是骗局，它在某些第三方工具链、某些非Google的AI产品里可能有人会读。站内之前有一篇手把手讲怎么给网站生成llms.txt和llms-full.txt，那篇的结论现在依然成立——可以做，成本也低，但请把它的预期收益从“影响Google AI露出”里彻底划掉。验证方法很糙但有效：在Search Console的搜索结果报告里，对比上线llms.txt前后AI功能相关的展示与点击，曲线该怎么走还怎么走，不会因为多了个txt而抬头。

内容切块chunking：段落级索引早就替你切好了

文档说得很干脆：把内容拆成小块不是必需的，Google的系统“能够理解一个页面上多个主题的细微差别，并把相关的那一段展示给用户”。Google的搜索联络人在2026年1月也提过类似观察，说跟工程师聊下来，他们并不鼓励为AI切块。

机制上，Google早就有段落级的理解和召回能力——它能在一篇长文里精准定位到回答某个具体子查询的那一段，单独拿出来用。你手动把一篇结构完整的长文切成几十个独立小块，反而干了两件坏事：一是破坏了语义连贯和内部上下文，模型本来能靠上下文消歧的，被你切散了；二是稀释了页面权重，一篇本来有内链、有沉淀的强页，被拆成几十个弱页，每个都打不动。前面那个家居客户掉量就是栽在这儿——一篇排在第一页的“开放式厨房油烟治理”长文被切成二十多块，三周后那个词掉到第三页，召回时反而是被切碎的弱页互相抢，谁都没抢过原来那一篇。

这背后其实是另一个更大的话题：渲染方式和页面结构怎么影响AI能不能把你的内容“看全、切对”。SPA站、内容靠JS异步塞进来的站，问题比切块严重得多。这块站内单独写过AI搜索为什么跳过你的SPA站，要做AI可见性，那篇里的渲染和段落级竞争比你纠结要不要切块重要得多。

为AI重写文风、堆长尾变体：模型早就懂同义词了

这一条最省钱。文档说AI系统理解同义词和大致含义，你不需要为了生成式AI去覆盖每一个长尾关键词变体，也不需要采用某种特定写作风格。

翻译过来：那种“同一个意思用十种问法各写一段”的页面，是2015年关键词时代的肌肉记忆。今天的检索和生成是语义层面的，“小户型厨房”和“迷你公寓做饭空间”在向量空间里离得很近，你不需要两段都写。为AI改写文风更是反效果——把人话写成那种四平八稳、信息密度低的“AI腔”，恰恰削弱了文档反复强调的那个真正有用的东西：独到、具体、别处没有的内容。你越像AI写的，越没有被AI引用的价值，因为模型不缺会写通顺废话的能力，它缺的是事实和独特视角。

刷“被提及”：核心排序按质量，反垃圾在另一头拦着

文档承认AI功能确实会在博客、视频、论坛里捞产品和服务的提及，但紧接着说：刻意去搞不真实的提及“没有看上去那么有用”，因为核心排序系统优先质量，而另一些系统专门拦垃圾。

这是一个双层结构：一头是核心排序，按质量和相关性给分，刷出来的低质提及在这层本来就拿不到权重；另一头是反垃圾系统，主动识别异常的、协同的提及模式。你花钱铺一百个软文站的“提及”，第一层不给分，第二层还可能给你打上垃圾标记。真实的、自然发生的讨论才是信号——一个用户在论坛里自发吐槽你产品的某个细节并被你解决，这条提及的价值比一百条买来的高。这事没有捷径，承认这点比卖你一个“mention包”诚实。

专门为AI加结构化数据：富结果要做，为AI理解不必

这条最容易被误读，得讲细。文档的完整意思是两句不矛盾的话：结构化数据对生成式AI不是必需的，没有专门给AI用的schema；但Google仍建议你把结构化数据作为整体SEO的一部分继续做，用于富结果资格。

怎么落地？该做的结构化数据照做，但目的写清楚——你做Product、Review、FAQPage、Breadcrumb这些，是为了富结果、为了SERP里那块更显眼的展示、为了电商feed，不是因为不加AI就读不懂你。所以判断要不要加一个schema，标准回到“它能不能带来富结果或feed价值”，而不是“AI会不会因此更引用我”。别为了一个想象中的AI收益，去给整站套一堆和富结果无关的冷门schema——那纯属增加维护成本和出错面，schema写错了还会在Search Console里给你报一串结构化数据错误。

那力气到底该往哪儿使？

叫停五件事之后，文档把建议拉回熟悉的SEO地界。核心就一句：做别处没有的非通用内容，把技术底子打扎实，让页面能被索引、能被取片段。

通用内容还是独到内容：写每段前过的三连问

文档给了一个特别好的对照例子：通用内容长这样——《首次购房者的7个小贴士》；非通用内容长这样——《我们为什么放弃验房却反而省了钱：一次下水管道的真实复盘》。区别不在字数，在有没有别人给不出的、具体到细节的亲历信息。

这套判断怎么变成可操作的动作？保哥写每一段会过三个问题，任意一个答不出就重写：第一问，这段话在Stack Overflow、知乎、各家营销博客上是不是随手能搜到的标准段子？是，删。第二问，这段里有没有只有真做过的人才给得出的东西——具体数据、具体踩坑日志、版本差异、客户场景里的边界条件？没有，补。第三问，把这段贴给大模型让它再生成十段，能不能写出几乎一样的？能，说明它没有独特信息密度，重写。三连问过一遍，剩下的就是文档说的那种“非通用内容”——也正是RAG召回时，模型在一堆雷同结果里会优先挑出来的那种。

查询扇出之后，关键词研究到底该怎么改？

这是文档没明说、但顺着它的机制必然推出来的一件事。既然召回是按系统扇出的子查询来的，你的关键词研究就不能停在“主词加几个长尾”，得变成问题簇研究：围绕一个主题，把真实用户会延伸出来的子问题尽量穷举，每个子问题在页面里都有一段能独立成答的内容。

子问题从哪儿挖？三个来源拼起来基本够用：一是Search Console里的查询报告，按主题筛出那些长尾问句式query，它们就是真实扇出的影子；二是SERP上的“People Also Ask”和相关搜索，那是Google自己暴露的需求邻域；三是你自己站内搜索的日志——用户在你站里搜什么、搜了没结果跳走，是别人拿不到的一手需求数据，这条最容易被忽略也最值钱。把这三类汇成一张问题清单，再回头看每个问题在你页面里有没有一段“拿出来就能直接当答案”的内容，没有就补。这件事本质还是关键词研究，只是颗粒度从“词”降到了“可被独立引用的答案段”。

能被索引、能被取片段：技术底子的硬清单

文档列的技术建议没有惊喜，但每条都对应着前面那条召回链路，少一环就掉链子，这里把每条配上最常见的翻车点：

• 页面必须被索引、且具备出精选片段的资格，否则连进召回集的门票都没有——常见翻车是上线时忘删staging的全站noindect，或被一条过宽的robots规则误伤；
• 遵守抓取最佳实践，别用robots或noindex误伤该露出的页——见过客户写了一行Disallow把放结构化数据的接口路径也封了，富结果直接消失；
• 尽量用语义化HTML，让结构本身表达层级，而不是一堆无意义div套div；
• 遵守JavaScript SEO最佳实践，关键内容不要只存在于客户端渲染之后——内容如果是onload之后再fetch塞进DOM的，召回时大概率拿到的是空壳；
• 页面体验过关、重复内容收敛——同一主题十个近重复页，召回时是你自己的页面互相打架，谁都进不了引用。

这几条没一条是新的，这恰恰是文档想说的：你2026年做AI可见性的清单，和2018年做技术SEO的清单，重叠度高得让卖新概念的人尴尬。

本地和电商：Merchant Center、商家资料和那个会聊天的Business Agent

这部分对DTC独立站和本地生意更实在。文档建议用Merchant Center feed和Google商家资料（Google Business Profile）来提升产品与本地业务在AI回答里的可见性，还提了一个叫Business Agent的东西——一个对话式体验，让顾客能在Google搜索里直接跟品牌“聊”。

对Shopify/独立站卖家，这条的潜台词是：AI电商可见性的入口，很大一部分不在你网页的正文里，而在你的结构化商品feed里。Merchant Center里的标题、属性、GTIN、价格、库存准不准，直接决定AI在比价、选品类问题里要不要带上你。保哥给电商客户排优先级，一直把feed数据完整度和准确度放在博客GEO之前：一个feed里属性残缺、GTIN乱填的店，正文写得再AI友好也没用，因为产品类查询的召回主力是Shopping那套结构化数据，不是你的产品描述段落。先把feed做干净，再谈内容层。

agentic体验和UCP，现在到底要不要碰？

文档新开了一节讲AI agent，定义是“能代替人执行任务的自主系统，比如订位、比较产品规格”。这节给了两条具体信息，对懂前端的人很有用。

浏览器agent怎么“看”你的站，这对前端意味着什么

文档说，浏览器类agent可能通过截图分析、DOM检查、可访问性树（accessibility tree）解读这三种方式访问网站。这三个词每一个都对应一类前端工程动作：

截图分析意味着视觉上关键信息不能只靠hover、不能藏在需要交互才出现的层里；DOM检查意味着内容要真实存在于DOM中，而不是渲染后才异步塞进来的空壳；可访问性树解读意味着你为无障碍做的那些事——语义标签、aria属性、合理的标题层级、按钮和链接的可访问名称——现在多了一个受益方：agent。做无障碍这件事，对一线顾问来说从来不只是合规，现在多了个更硬的理由：一个accessibility树混乱的站，agent解析你的下单流程时会卡在某一步，等于把未来的agentic流量挡在门外。这活儿不用等agent普及才做，它和你现在就该做的语义化HTML、可访问性是同一件事，相当于一笔投入兑两份收益。

UCP和Shopify共建：DTC独立站现在该提前做什么

文档提到一个新协议——通用商务协议（Universal Commerce Protocol，UCP），说它会“让搜索agent能做更多事”。Google在2026年早些时候宣布了UCP；据相关年度公开信，它是和Shopify共同开发，并获二十多家公司背书。

这条对Shopify生态的卖家是个明确的前瞻信号：未来agent帮用户“在搜索里直接下单/比价”，走的可能就是UCP这类标准化通道，而Shopify是共建方，意味着Shopify店在这条通道上大概率有结构性便利。现在要不要为此大动干戈？不要——文档自己把这节标成“如果跟你业务相关、又有余力再去探索”，是前瞻不是紧急。但有一件低成本的事可以现在做：保证商品数据结构化、标准化、feed干净，因为不管最终协议长什么样，脏数据在任何agentic通道里都是第一个被淘汰的。UCP对电商SEO到底改了哪些游戏规则，站内单独拆过Google UCP与agentic commerce的完整影响，这里不展开。

这套结论，对ChatGPT和国内引擎也算数吗？

这是最容易被忽略、却最影响你实际投入的一点。文档从头到尾只代表Google自己的AI功能。它说llms.txt没用、切块没用，是对Google成立；它没有、也无权替ChatGPT、Perplexity、百度AI、豆包、夸克这些发言，这些引擎的取内容机制和信号权重各不相同。

引擎	内容来源机制	llms.txt是否相关	切块/结构化的实际意义	给中国出海与本地团队的落地建议
Google AI Overviews / AI Mode	RAG加查询扇出，走Search索引	不相关	都不必为AI专门做，技术底子优先	就按SEO做，重点是独到内容加可索引
ChatGPT（搜索增强）	调用必应等检索源加自身知识	部分工具链可能读，收益不稳定	清晰结构有助于检索后理解，仍非硬指标	盯必应可见性，做实体与权威信号
Perplexity	实时检索加引用，强调来源	边际影响，不作为主线	结构清晰、有明确答案段更易被引	答案前置、来源可信，监控被引列表
百度AI搜索 / 文心	百度自有索引加生态内容	不相关，吃百度生态	结构化与百度规范对齐更重要	备案、移动端、百度系内容沉淀仍是地基
豆包 / 夸克	字节、阿里自有索引与生态	不相关	平台内内容与合规优先	分平台单独做，别套Google那套

对做出海的团队，真正的风险是拿Google这份文档当“全AI通用说明书”，把ChatGPT、Perplexity那边也按“llms.txt没用、不用管结构”一刀切——那边的检索源、引用偏好和Google并不一样。对做国内的团队，更别直接平移：百度AI吃的是百度生态，备案、移动端体验、百度系内容沉淀这些地基Google文档里一个字都没提，但它们在国内的权重一点没降。正确的姿势是：把Google这套当作Google渠道的定论，底层策略（独到内容、可被检索）跨引擎共用，但监控口径和平台细节必须分引擎单独做。SEO/AEO/GEO/AAO这几条路径怎么协同不打架，站内单独梳理过四条优化路径的区别与协同，做多引擎的可以对着那篇排自己的资源分配。

文档结尾那句“没有SEO也能活”，是让你别做了吗？

文档收尾有句话很容易被断章取义：你不需要把文档里的每件事都做到才能成功，“在Google搜索里（包括生成式AI体验），大量内容没有任何刻意SEO也活得很好”。卖课的会拿前半句说“看Google都说SEO没用了”，焦虑的人会拿它当躺平的理由。两种读法都错。

这句话的真实含义是反过度优化，不是反优化。它在说：别把SEO做成一套和内容质量脱节的仪式动作；真正靠独到价值赢的内容，不需要靠技巧硬撑。它针对的是那种内容空洞却堆满SEO套路的页面，不是针对认真做内容和技术底子的人。

保哥的判断，给三类人三个不同结论，因为这套打法有它的适用边界，不该一刀切：

• 有真实一手经验、能持续产出别处没有内容的品牌或个人：把llms.txt、切块、为AI改写这些动作的预算砍掉，全投到内容深度和技术可索引性上，这是当前ROI最高的路径。
• 电商/DTC独立站：正文GEO是次要矛盾，feed数据质量、Merchant Center、商家资料是主要矛盾，先把结构化商品数据做干净，再谈博客层的AI可见性。
• 纯靠内容套路、没有独特信息密度的站：这套对你最不友好——文档等于明说，没有非通用内容打底，任何AI优化技巧都补不上窟窿。这不是坏消息，是省钱消息：别再为技巧付费，把钱花在产生真东西上。

落到一个可执行的90天动作上：第一个月，停掉所有“AI专项”付费动作（llms.txt维护、切块改造、为AI改写的外包），把这部分预算和工时冻结出来；第二个月，用Search Console加站内搜索日志建那张问题簇清单，挑流量最大的十个子问题，逐个回到对应页面补“能独立成答”的段落；第三个月，对照AI功能相关的展示点击曲线看变化，同时把电商feed的属性完整度和GTIN准确率拉满。三个月跑完，你会发现真正动了指标的，没有一件是过去一年被当成“GEO秘籍”卖的东西。

说句行业切片观察收尾：过去两年“万词霸屏”改卖“GEO专项”，这份文档出来后，估计下一季就会有人改卖“agentic优化”和“UCP抢跑课”。这条规律比任何算法都稳定。你能做的，是每次都回到这篇反复在说的那个地基——别处没有的内容，加上能被正常检索的技术底子。这地基十年没变过，换几次皮也不会变。

常见问题解答

AEO、GEO和SEO到底有没有区别？

按Google官方文档的定性，没有本质区别。AEO（答案引擎优化）和GEO（生成式引擎优化）只是把SEO用在AI搜索这个出口上，Google AI功能从同一个Search索引取内容，不需要单独的优化框架。

llms.txt文件对Google的AI搜索有用吗？

对Google没用。官方明确站点无需为生成式AI创建机器可读文件或专门标记，这类文件不获得特殊待遇。它可能对部分非Google工具链有边际作用，但别算进Google AI露出的预期收益。

内容要不要切成小块方便AI抓取？

不需要。Google系统能理解一页里多个主题并把相关片段单独展示，段落级索引早就替你做了。手动切块反而破坏语义连贯、稀释页面权重，可能让原本排得好的长文掉量。

结构化数据现在还要不要做？

要做，但目的要摆正。对生成式AI它不是必需，也没有专门的AI schema；继续做是为了富结果资格和电商feed价值。判断标准是能否带来富结果或feed收益，不是AI会不会更引用你。

Google这套说法对ChatGPT、Perplexity、百度AI也成立吗？

不一定。文档只代表Google自己的AI功能。各引擎内容来源和信号权重不同，底层策略（独到内容、可被检索）可共用，但监控和细节要分引擎单独做。

怎么验证我的页面进没进Google的AI功能？

用Search Console的搜索结果报告，观察AI功能相关的展示与点击变化，并确认页面可被索引、具备出精选片段的资格。改动前后对比这条曲线，比听服务商口头承诺可靠。

agentic和UCP现在需要专门投入吗？

暂时不需要专项投入，文档自己把这节标为前瞻可选项。能现在做的低成本动作是保证商品数据结构化、标准化、feed干净，因为脏数据在任何agentic通道里都会第一个被淘汰。