1. 为什么在上海做GEO搜索引擎流量衰减后的真实信号1.1 我们观察到的流量异常自然搜索下滑但AI推荐上升今年年初我们分析上海本地业务的数据周报时发现了一个反直觉的现象来自传统搜索引擎的自然流量环比下降了约23%但站内核心目标页面的转化率并没有下滑甚至略有上升。这意味着用户仍然在产生需求、仍然在找到我们只是他们进来的路径变了。顺着转化路径倒查我们发现相当一部分流量来自于被AI产品点名之后的直接访问。用户在豆包、DeepSeek、Kimi这类对话式AI里问上海做XX服务的公司哪家靠谱AI的回答里出现了我们用户点进来然后直接填了表单。这个路径在传统统计工具里几乎不可见因为它没有搜索关键词没有来源域名只有一个模糊的直接访问标签。后来我们做了更系统的用户调研在上海的随机抽样里超过40%的年轻用户表示在购买决策前会先问一次AI。这个比例还在涨。而更关键的是AI回答里的信息秩序和搜索引擎完全不同搜索引擎是跳转、筛选、比对AI是直接给结论。谁的资料被AI优先引用谁就能在用户还没打开浏览器之前就把决策倾向抢到自己手里。于是我们启动了GEOGenerative Engine Optimization生成式引擎优化项目。目标很直接让主流AI模型在回答上海相关的问题时稳定地引用我们官方渠道提供的事实、观点和数据。1.2 SEO、AEO、GEO的分工与迭代关系很多团队一上来就问GEO是不是要把SEO推翻重来真不是。我们内部做了一个对比表把几代优化范式的差异列清楚团队对齐起来非常方便优化范式核心对象主要目标典型手段SEO搜索引擎爬虫关键词排名、点击率外链、TDK、内容关键词布局AEO搜索引擎精选摘要/答案框抢占零点击答案FAQ结构化、要点式内容、精选摘要优化GEO大模型生成引擎AI回答中被引用、正面提及知识库投喂、Schema结构化、多模型监测AAOAgent自动化执行链路被AI Agent直接调用API开放、工具Function注册、数据可机读传统SEO思维是在跟爬虫打交道告诉它我这个页面重要GEO是在跟大模型的知识组织和推理方式打交道核心是让模型在生成回答时把你当作可信来源。这个差异决定了我们后面所有动作的优先级不是堆内容、堆关键词密度而是先建知识底座。1.3 为什么不是先投广告而是先做GEO优化成本结构是另一个重要考量。上海市场的竞价广告价格已经不低了本地生活类的获客成本逐年上涨而GEO有一个特点一旦模型形成对你的引用偏好它的推荐惯性会持续很久边际成本会持续下降。广告断投流量就断GEO更像是资产积累。而且AI回答本身带有天然的信任滤镜用户认为AI是中立的信息筛选器通过AI推荐过来的流量意向度和成交率往往比广告流量高一个量级。所以我们把这个项目定位成基建型投入在增长团队里单独拨了一个小组来跑而不是把它塞给原来的SEO外包。这也直接决定了后面统一知识库、Schema结构化、多模型监测几件事可以并行推进。2. 统一知识库建设从零散文档到AI能读懂的实体关系网2.1 知识库的实体优先思路而非纯文档堆积做GEO优化的第一步不是写新内容而是把已有的企业信息整理成一个AI友好的知识资产。我们一开始踩过一个误区以为知识库就是把官网页面、产品手册、案例PPT打包上传到某个系统里像做网盘一样。结果模型检索出来的内容质量非常差经常张冠李戴。后来我们换成了**实体优先Entity-First**的思路。什么是实体优先不把知识库当成一堆文件的集合而是把它当成一张实体关系网。实体包括品牌、产品线、服务项目、办公地址、核心团队、资质证照、典型客户、标准报价、服务流程、常见问题、区域覆盖范围等等。每个实体有明确的属性Attributes和关系Relationships。举个例子我们的一个客户是上海做高端家装的公司如果知识库只是把20份Word项目文档放进去AI检索上海别墅全案设计大概多少钱时很难精准找到答案。但如果知识库里有一个报价体系实体关联了别墅全案单价区间计价逻辑案例项目这些分支模型就能抽取出结构化信息并组织成一段完整的回答。2.2 五步落地方案盘点、清洗、归类、元数据、RAG切分统一知识库的建设我们实际跑了五步每一步都有容易忽略的细节第一步内容盘点。把散落在官网、公众号、销售团队飞书文档、线下宣传册里的内容全部拉一个清单。重点不是数量而是覆盖范围用户可能问AI的问题我们有没有对应的资料比如营业时间服务范围价格区间售后政策公司资质这些基础信息如果连自家资料里都没有统一答案AI就只能去第三方平台抓取不可控的信息。第二步清洗去重。这一步最花时间。同一个产品在不同时期、不同渠道的描述完全对不上价格有新旧版本混淆地址出现了两个写字楼的说法。我们用了一个笨但有效的办法每个核心实体指定唯一事实源以官方发布渠道或合同版本为准其他的全部打上仅供参考标签并从知识库主表中剔除。第三步统一归类。知识库的目录结构不按文件类型来而是按用户决策链路来。我们分成了几个一级目录品牌介绍、产品与服务、价格与商务、客户案例、行业洞察、售后支持、新闻动态、资质荣誉。这样设计的原因是RAG检索增强生成在做语义匹配时更容易定位到对应的知识片段。第四步元数据规范。每一个知识片段都加上统一的元数据字段所属实体、地区标签比如上海、适用产品线、更新日期、来源渠道、审核人。元数据对于多城市运营非常关键。如果没有地区标签AI在回答上海X和北京X的问题时会混用信息。我们在上海本地项目里尤其强调这一步因为总部信息、上海门店信息、其他城市分店信息会频繁出现在同一篇文档里。第五步RAG切分策略。用Dify或开源RAG框架做知识库时切分Chunking粒度会直接影响检索质量。我们最终采用的方案是上下文型内容切分为256~512字问答型内容直接整条入库不做切分同时启用重叠窗口overlap避免跨段语义断裂。这里补充一下切分大小不是越小越好太碎会丢失上下文太大会把不相干的内容混在一起需要根据实际语料做AB测试。2.3 知识库和分站结构怎么联动上海多门店场景标题里特意提到了多城市Schema标记分站这背后有一个很常见的场景一家连锁品牌总部在上海在全国有分站。在GEO时代分站结构和知识库的关系需要重新理解。传统的分站做法是主站一个域名上海一个子目录或子域名其他城市各自一套。站在爬虫视角这没问题但站在大模型知识组织视角模型更倾向于引用信息密度高、实体关系完整的来源。如果你的上海分站下面没有任何结构化信息只是几篇门户新闻稿模型没法把上海门店识别为一个可靠实体。我们的做法是分站页面不再只放文章而是在页面里嵌入对应城市的门店实体信息块同时把分站的关键信息同步进统一知识库形成站点页面展示和知识库系统存储两个副本。这样模型无论通过网页抓取还是通过知识库检索拿到的都是同一套事实。2.4 最容易翻车的细节切分粒度、权限、陈旧内容知识库搭建中翻车概率最高的三个地方我单独拎出来说一下。切分粒度调参翻车。我们上线初期发现AI回答里经常出现这个服务我们不提供的错误排查了一圈是某个竞品文档里的不提供字样被切进了我们的知识片段。后来在切分规则里加了一条每段必须保留完整的主语宾语结构不允许从中间断开。这个小坑非常隐蔽能查出来全靠逐条对照AI回复里的引用原文。权限混乱导致数据污染。企业内部知识库往往有多个权限层级但当知识库用来投喂AI时所有被检索到的内容都会成为回答来源。一次我们把一个销售内部讨论版里的未定稿方案同步进了知识库AI在回答中直接把这个方案当成了既定服务来介绍。此后我们定了一个铁律进入AI知识库的内容必须与对外官网公示内容完全一致任何内部讨论材料一律隔离。陈旧内容的权重衰减。模型检索的时候不会判断信息新旧如果知识库里有一篇2022年的旧报价方案它可能和2024年的新报价同时被检索到AI就可能取旧数据回答。解决方案是给每个知识片段打上信息有效期并设置定期清理流程每月跑一次过期内容清单由业务负责人确认是否下线。3. Schema结构化数据落地多城市标记与AI解析的兼容性3.1 为什么AI搜索优化必须做Schema统一知识库解决的是让AI有内容可用Schema结构化数据解决的是让AI知道这些内容是什么。两者是配合关系。搜索引擎时代爬虫靠超链接和标签理解网页生成式AI时代模型主要靠海量语料预训练 实时检索来组织答案。但有一个普遍的技术共识结构化数据的置信度高于非结构化文本。当模型看到一个用Schema.org标准标记过的实体信息它会更倾向于认为这是官方、准确、可直接引用的信息因为JSON-LD格式本身带有清晰的语义路径。我们做过一个对比实验在官网首页加上Organization和LocalBusiness的JSON-LD标记后明显感觉到AI模型对我们实体评价的确定性更高了。比如问X公司是做什么的原来AI会说X公司是一家据说从事XX的公司措辞是推断语气Schema标记上线后回答变成了X公司是一家位于上海的XX服务商主要提供……语气从推测变成了陈述。这就是结构化数据的力量。3.2 Schema类型选型一张表讲清适用场景Schema.org的类型体系非常大但做GEO优化不需要全部铺开我们经过筛选实际只用了以下六种高频类型Schema类型适用场景关键字段Organization品牌总部信息全站基础name, url, logo, sameAs, contactPointLocalBusiness本地门店/服务网点多城市分站必备address, geo, openingHours, telephoneFAQPage常见问题聚合AI问答高优引用来源mainEntity(QuestionAnswer)Product/Service产品线或服务项目的属性描述name, description, offers, areaServedBreadcrumbList页面层级导航辅助AI理解站点结构itemListElementArticle新闻动态/行业洞察文章headline, datePublished, author我们的经验是基础的三件套Organization LocalBusiness FAQPage足以覆盖大多数企业的GEO需求。Product、Article这些看行业属性电商和内容平台再考虑延展。千万不要为了炫技把所有类型都加上Schema数量多但内容重复反而会稀释每个实体的信息权重。3.3 JSON-LD代码示例本地商户FAQ组合下面给一个我们实际在用的JSON-LD示例这是上海某门店页面的标记片段。注意不是静态死代码而是服务端渲染根据当前页面数据动态生成的确保始终和知识库内容同步。{ context: https://schema.org, graph: [ { type: LocalBusiness, id: https://example.com/shanghai#store, name: 某某服务·上海徐汇店, image: https://example.com/images/shanghai-store.jpg, url: https://example.com/shanghai, telephone: 86-21-12345678, priceRange: ¥¥, address: { type: PostalAddress, streetAddress: 徐汇区××路100号, addressLocality: 上海, addressRegion: 上海, postalCode: 200030, addressCountry: CN }, geo: { type: GeoCoordinates, latitude: 31.1885, longitude: 121.4362 }, openingHoursSpecification: { type: OpeningHoursSpecification, dayOfWeek: [Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday], opens: 09:00, closes: 21:00 }, areaServed: { type: City, name: 上海 } }, { type: FAQPage, mainEntity: [ { type: Question, name: 某某服务在上海有哪些门店, acceptedAnswer: { type: Answer, text: 品牌在上海设有徐汇、浦东、静安三家直营门店徐汇店位于××路100号浦东店位于××静安店位于××营业时间均为每天9:00-21:00。 } }, { type: Question, name: 某某服务的售后服务政策是什么, acceptedAnswer: { type: Answer, text: 产品自验收之日起30天内支持无理由退换1年内提供免费维修详情请见官网售后服务专区。 } } ] } ] }注意几个容易出错的位置id要稳定不要每次刷新生成不同IDFAQ的答案文本要用完整自然语句不能是短语拼接areaServed这个字段很多团队会漏但对本地服务的GEO优化非常关键它直接告诉AI这个实体的服务覆盖范围。3.4 多城市Schema标记分站的正确姿势多城市场景下最容易犯的错误是每个分站各做一套独立Schema彼此没有关联。正确的姿势是主站Organization标记作为总实体各城市LocalBusiness标记通过parentOrganization或department字段关联到主站。这样AI在整合信息时能理解上海门店属于某品牌这个层级关系。同时分站页面不要只做纯文本URL差异化要在内容区、地图区、FAQ区分别结构化标记。一个忠告是GeoCoordinates经纬度一定要写准确我们曾因为用了商场的中心坐标而不是门店实际坐标导致AI在回答离我最近的门店时给用户指错了方向。这个错误在搜索时代影响不大在AI对话场景里会直接导致用户不信任。3.5 LLM解析Schema失败的兼容处理Schema落地过程中我们遇到了一个很有意思的技术问题也是近期圈子里讨论度很高的一个现象LLM在调用Agent工具或解析函数参数时偶尔会返回provider rejected the request schema or tool payload之类的错误。简单说就是大模型虽然能理解Schema.org格式的数据但在把Schema作为工具调用参数时对格式的严格性要求非常高一个多余字段或类型不匹配就会导致整个请求被拒。这给我们的启示是Schema不仅仅要给爬虫看未来还要给AI Agent当工具说明书用。函数式SchemaOpenAPI样式和网页标记式SchemaJSON-LD要尽量保持一致的字段命名和数据格式。我们团队后端做了一个小工具把JSON-LD里的核心实体表定期导出为Agent可识别的tool schema两边共用同一套数据源。这就不会出现A页面标了电话号码但Agent函数里要求的字段叫phone这种低级错位。提示如果你在对接AI Agent过程中遇到schema payload被拒优先检查字段类型是否严格符合模型声明的格式比如字符串不能写成了数组其次检查有没有多余的、未在声明里出现的字段。模型对未声明字段的容忍度极低。4. 多模型监测AI排名本质上是一种引用感知4.1 为什么盯一个模型不够GEO优化做完之后最怕的事情就是闭门造车——我们在自己熟悉的模型上看到效果不错就以为万事大吉。但实际上不同AI模型的训练语料、检索策略、引用偏好差异巨大同一个问题在一款AI里的答案和另一款AI里的答案可能完全相反。我们目前监测的模型池覆盖了几个主要梯队国内主流的对话式产品豆包、Kimi、通义千问、文心一言等以及用户量较大的DeepSeek。每个模型的脾气都不一样有的偏好官网原文引用有的偏好第三方平台评价有的更看重结构化资料。如果你只优化某一家就可能失去其他渠道的曝光。多模型监测的核心目的不是追求在所有模型里都排第一而是最低限度避免在任何一个主流模型中消失或出现负面描述。4.2 监测问题集怎么设计问题集是监测的地基。我们按四层结构设计每层对应不同的商业目的品牌层XX公司怎么样XX是什么XX的官网在哪里——监测品牌基础认知的确定性。品类层上海做XX服务的有哪些公司XX服务哪家比较好——监测品类竞争中的提及度。场景层上海XX户型改造大概多少钱XX多久能完工——监测具体消费决策场景中的内容覆盖。竞品对比层XX和AA竞品有什么区别——监测AI对差异化优势的表述是否准确。每个层级保留5到10个核心问题固定问法每月可以追加一些热搜衍生问题。这里有个重要经验问题设计必须口语化真实用户问AI不会用请比较A公司的B服务与C公司的D服务在E场景下的F维度表现而是非常直接的上海××哪家好。4.3 API自动轮询与结果记录人工一个一个去AI对话框里问时间成本太高也容易漏数据。我们做了自动化的监测脚本通过各模型官方API或合规渠道批量提交问题集定时抓取返回结果。基础流程是这样的import time from datetime import datetime questions [ 上海做全案设计的公司推荐, XX品牌的口碑怎么样, 上海别墅装修报价一般多少 ] def poll_models(question): results {} # 依次调用各模型API这里以示例写法说明逻辑 # llm call_model(doubao, question) # results[doubao] parse_response(llm) # llm call_model(kimi, question) # results[kimi] parse_response(llm) time.sleep(2) # 控制请求频率,避免触发限流 return results # 每日定时执行,结果写入数据库 for q in questions: result poll_models(q) save_to_db({ question: q, result: result, timestamp: datetime.now().isoformat() })抓回来的数据不是看一眼就完事要进入结果分析层级是否提及、提及顺序、表述语气、信息准确性、引用来源。我们做了一个简单的评分模型每一条AI回答按这几个维度打分。比如AI回答是否把我们列为第一顺位AI对服务的描述是否准确有没有把我们说成不存在的服务AI答案里有没有过时信息。分数每周汇总一次成为增长例会上的关键输入。4.4 从监测到归因AI的回答质量、语气与来源多模型监测最有价值的部分不是看见了AI怎么说而是还原AI为什么这么说。一次我们发现某款AI在回答价格类问题时总是引用一个第三方平台上的旧报价我们的知识库里明明已经更新了最新价格。顺着链路排查发现那家第三方平台的文章没有被及时清理AI在检索时优先抓到了它。这就说明GEO优化不仅是优化自己的内容还要关注第三方平台上关于你的信息。我们在后续动作里增加了第三方平台信息核对的环节定期清理和修正外部渠道的过时描述。另一个发现是语气问题。AI在回答哪家好类问题时口头语里往往会有倾向性虽然A也不错但B更专业。这种语气差异很难用关键词排名来衡量需要细看回答上下文。我们的处理办法是对AI回答做细粒度的情感标注把推荐中性负面三种情况标记出来每周比对变化趋势。5. 增长闭环的运转机制内容、收录、流量如何互相喂养5.1 四环节闭环怎么走标题里提到的增长闭环很多人觉得是管理上的概念其实在我们的实践里它是一个非常具体的、可执行的工作流。我画过一张内部协作示意图大致的流转路径是这样的内容生产环节→ 根据多模型监测中发现的问题和用户搜索热词产出高质量内容不局限为文章还包括FAQ条目、案例故事、数据报告内容发布时直接做好Schema标记和知识库同步。知识库更新环节→ 新内容按前文说的五步流程进入统一知识库打上实体标签、地区标签、有效期元数据同时清理已经失效的旧内容保持知识库的新鲜度。AI收录与表现环节→ 多模型监测系统跟踪这些内容在各类AI产品中的被引用情况。注意这里看的不是收录率而是有效引用率——AI引用了你的信息之后回答是否变得更准确、更有利。流量转化与反馈环节→ AI引用带来的访问行为和询盘数据回流到数据分析系统反哺下一轮的内容选题。哪类内容AI喜欢引用且带来高转化询盘哪类内容虽然被引用但用户完全没点击一目了然。5.2 一个季度周期的数据变化案例用我们自己过去三个月的真实曲线来说效果比理论更直观。第一个月主要做知识库盘点和Schema上线。这个阶段AI引用率几乎没变化因为模型需要时间重新抓取和重新建立对实体的认知。第二个月开始在FAQ和场景内容上持续补充AI引用率开始抬头从初始的约12%提升到24%。第三个月在多模型监测的驱动下我们针对哪款AI都没提到我们的场景词专门产出了三篇深度案例文章AI在场景层的提及率明显上升。到季度末核心品牌词的AI正面提及率稳定在35%左右最关键的是AI带来的站内直接访问流量在总流量里占到了接近10%。这里想特别说明GEO不是线性增长的它有一个明显的爬坡-跃迁特征。知识库盘点期通常最痛苦因为脏数据会让你看到各种负面效果但一旦基础梳理完成后续内容补充的边际收益会显著放大。5.3 内容生产规范写人看的也给AI留钩子什么样的内容容易被AI引用我们总结了一套自己的写作规范核心是三个原则。第一个原则答案前置。AI在生成回答时非常偏好结构清晰、结论在前的文本。如果你能在一段文字的开头三句话类内直接回答上海地区价格区间是X到Y被引用的概率会大幅提升。不要学传统软文铺垫一堆最后才抛主题。第二个原则数字和事实要明确。AI引用内容时会偏好包含具体数字、日期、地点、服务范围的句子。比如服务覆盖上海全域就比服务范围广泛有价值得多。数据化表述给了模型更明确的引用依据。第三个原则层级化的FAQ体系。我们给每个核心业务都维护了一套FAQ分层级从品牌基础问题到场景深度问题。这套FAQ成为AI问答最稳定的引用来源。实践下来FAQ在AI回答中的引用率远高于长篇大论的文章。记住这句话在GEO时代FAQ是性价比最高的内容形态。6. 上海落地实践中的取舍与避坑清单6.1 团队分工与预算安排落地GEO项目不需要庞大的团队但需要清晰的职责划分。我们的配置是1名内容运营负责知识库维护和内容生产1名技术同事兼职负责Schema和API监测增长负责人每周花半天看监测报告并定决策。预算上最大的成本不是工具费用而是内容梳理和时间投入。如果企业内容基础很差建议预留至少20%的项目预算给知识库清洗和内容补齐。工具方面可以先用开源的RAG框架和低成本的监测脚本跑通有规模需求后再上商业化工具没必要一上来就采购昂贵的GEO优化平台。6.2 工具选型自研、开源还是SaaS工具选型是大家问得最多的问题我分开说知识库管理我们优先选择了Dify这类开源流水线因为它能灵活对接各种模型API和向量数据库知识库切分、召回配置都可控。如果企业已经有内容管理系统也可以先用Obsidian这类个人知识库工具跑MVP把手写文档整理成标准结构再迁移到企业级RAG系统。Obsidian双层链接的思维方式对实体关系的梳理很有参考价值。Schema维护不建议完全手工管理JSON-LD很容易漏更新。我们做了一个简单的内容源同步逻辑后台业务系统里配置了实体信息发布时自动渲染到页面模板并输出JSON-LD。如果用WordPress或同类CMS也有现成的SEO插件支持基础Schema生成但多城市层级关系和自定义FAQ还是需要自己改模板。多模型监测开源社区有一些AI搜索监测项目可以借鉴但考虑到模型API的更新频率自研脚本维护成本并不低。我们的建议是先自研脚本跑小规模问题集确认ROI后再决定是否引入商业化工具。RAG知识库领域开源方案和SaaS方案的区别主要在于数据安全性、召回可调性和更新时效企业可按自身情况选。6.3 三个伪需求与一个真命题做完这个项目市面上各种讨论也很多我总结了三个容易被误判的伪需求和它们背后的真命题伪需求一要求一周之内AI排名进前三。AI模型的更新是有周期的不是搜索结果可以靠刷排名解决。真命题是在Q2内把知识库基础搭好、Schema上线、监测跑通Q3才可能出现明显效果。谁跟你保证一周见效谁就是在骗你。伪需求二只做Schema结构化不做内容更新。Schema是告诉AI这是什么但AI回答的弹药还是来自内容。空有标记没有内容就像给空盒子贴了漂亮的标签。真命题是Schema是放大器内容是信号源两者同步推进才有价值。伪需求三把所有官方资料一股脑投喂给AI。信息过多、互相矛盾AI就会混淆。真命题是宁缺毋滥知识库里只有经过确认的、口径一致的内容。每一条进AI知识库的内容都要经过能不能对外公示的考验。6.4 ROI如何衡量最后说ROI。GEO的效果不能只看传统流量指标我们内部定义了三级指标第一级是引用可见性指标品牌词在AI回答中的正面提及率、品类词中的被推荐率、信息准确率。这些指标本质上是品牌在AI世界的市场份额。第二级是行为转化指标来自AI产品的点击、访问、询盘、成交。可以通过UTM参数和动态链接追踪部分AI推荐流量虽然做不到100%精确但能抓出大体量。第三级是资产沉淀指标知识库条目数、Schema覆盖的页面数、多模型监测的连续性这些是基础设施层面的健康度。我个人对GEO项目的判断标准很简单**如果六个月后AI在回答你所在行业的核心问题时引用的信息比六个月前更准确、更偏向你的品牌这个项目的价值就已经成立了。**至于流量和转化那是水到渠成的事。上海市场的竞争节奏很快很多同行还在犹豫要不要做GEO我建议的时间点是先动起来。用最低成本跑通知识库—Schema—监测这条小闭环积累数据之后再逐步放大。等风向明朗的时候早期积累的AI引用资产会成为别人追不上的门槛。
1. 为什么在上海做GEO搜索引擎流量衰减后的真实信号1.1 我们观察到的流量异常自然搜索下滑但AI推荐上升今年年初我们分析上海本地业务的数据周报时发现了一个反直觉的现象来自传统搜索引擎的自然流量环比下降了约23%但站内核心目标页面的转化率并没有下滑甚至略有上升。这意味着用户仍然在产生需求、仍然在找到我们只是他们进来的路径变了。顺着转化路径倒查我们发现相当一部分流量来自于被AI产品点名之后的直接访问。用户在豆包、DeepSeek、Kimi这类对话式AI里问上海做XX服务的公司哪家靠谱AI的回答里出现了我们用户点进来然后直接填了表单。这个路径在传统统计工具里几乎不可见因为它没有搜索关键词没有来源域名只有一个模糊的直接访问标签。后来我们做了更系统的用户调研在上海的随机抽样里超过40%的年轻用户表示在购买决策前会先问一次AI。这个比例还在涨。而更关键的是AI回答里的信息秩序和搜索引擎完全不同搜索引擎是跳转、筛选、比对AI是直接给结论。谁的资料被AI优先引用谁就能在用户还没打开浏览器之前就把决策倾向抢到自己手里。于是我们启动了GEOGenerative Engine Optimization生成式引擎优化项目。目标很直接让主流AI模型在回答上海相关的问题时稳定地引用我们官方渠道提供的事实、观点和数据。1.2 SEO、AEO、GEO的分工与迭代关系很多团队一上来就问GEO是不是要把SEO推翻重来真不是。我们内部做了一个对比表把几代优化范式的差异列清楚团队对齐起来非常方便优化范式核心对象主要目标典型手段SEO搜索引擎爬虫关键词排名、点击率外链、TDK、内容关键词布局AEO搜索引擎精选摘要/答案框抢占零点击答案FAQ结构化、要点式内容、精选摘要优化GEO大模型生成引擎AI回答中被引用、正面提及知识库投喂、Schema结构化、多模型监测AAOAgent自动化执行链路被AI Agent直接调用API开放、工具Function注册、数据可机读传统SEO思维是在跟爬虫打交道告诉它我这个页面重要GEO是在跟大模型的知识组织和推理方式打交道核心是让模型在生成回答时把你当作可信来源。这个差异决定了我们后面所有动作的优先级不是堆内容、堆关键词密度而是先建知识底座。1.3 为什么不是先投广告而是先做GEO优化成本结构是另一个重要考量。上海市场的竞价广告价格已经不低了本地生活类的获客成本逐年上涨而GEO有一个特点一旦模型形成对你的引用偏好它的推荐惯性会持续很久边际成本会持续下降。广告断投流量就断GEO更像是资产积累。而且AI回答本身带有天然的信任滤镜用户认为AI是中立的信息筛选器通过AI推荐过来的流量意向度和成交率往往比广告流量高一个量级。所以我们把这个项目定位成基建型投入在增长团队里单独拨了一个小组来跑而不是把它塞给原来的SEO外包。这也直接决定了后面统一知识库、Schema结构化、多模型监测几件事可以并行推进。2. 统一知识库建设从零散文档到AI能读懂的实体关系网2.1 知识库的实体优先思路而非纯文档堆积做GEO优化的第一步不是写新内容而是把已有的企业信息整理成一个AI友好的知识资产。我们一开始踩过一个误区以为知识库就是把官网页面、产品手册、案例PPT打包上传到某个系统里像做网盘一样。结果模型检索出来的内容质量非常差经常张冠李戴。后来我们换成了**实体优先Entity-First**的思路。什么是实体优先不把知识库当成一堆文件的集合而是把它当成一张实体关系网。实体包括品牌、产品线、服务项目、办公地址、核心团队、资质证照、典型客户、标准报价、服务流程、常见问题、区域覆盖范围等等。每个实体有明确的属性Attributes和关系Relationships。举个例子我们的一个客户是上海做高端家装的公司如果知识库只是把20份Word项目文档放进去AI检索上海别墅全案设计大概多少钱时很难精准找到答案。但如果知识库里有一个报价体系实体关联了别墅全案单价区间计价逻辑案例项目这些分支模型就能抽取出结构化信息并组织成一段完整的回答。2.2 五步落地方案盘点、清洗、归类、元数据、RAG切分统一知识库的建设我们实际跑了五步每一步都有容易忽略的细节第一步内容盘点。把散落在官网、公众号、销售团队飞书文档、线下宣传册里的内容全部拉一个清单。重点不是数量而是覆盖范围用户可能问AI的问题我们有没有对应的资料比如营业时间服务范围价格区间售后政策公司资质这些基础信息如果连自家资料里都没有统一答案AI就只能去第三方平台抓取不可控的信息。第二步清洗去重。这一步最花时间。同一个产品在不同时期、不同渠道的描述完全对不上价格有新旧版本混淆地址出现了两个写字楼的说法。我们用了一个笨但有效的办法每个核心实体指定唯一事实源以官方发布渠道或合同版本为准其他的全部打上仅供参考标签并从知识库主表中剔除。第三步统一归类。知识库的目录结构不按文件类型来而是按用户决策链路来。我们分成了几个一级目录品牌介绍、产品与服务、价格与商务、客户案例、行业洞察、售后支持、新闻动态、资质荣誉。这样设计的原因是RAG检索增强生成在做语义匹配时更容易定位到对应的知识片段。第四步元数据规范。每一个知识片段都加上统一的元数据字段所属实体、地区标签比如上海、适用产品线、更新日期、来源渠道、审核人。元数据对于多城市运营非常关键。如果没有地区标签AI在回答上海X和北京X的问题时会混用信息。我们在上海本地项目里尤其强调这一步因为总部信息、上海门店信息、其他城市分店信息会频繁出现在同一篇文档里。第五步RAG切分策略。用Dify或开源RAG框架做知识库时切分Chunking粒度会直接影响检索质量。我们最终采用的方案是上下文型内容切分为256~512字问答型内容直接整条入库不做切分同时启用重叠窗口overlap避免跨段语义断裂。这里补充一下切分大小不是越小越好太碎会丢失上下文太大会把不相干的内容混在一起需要根据实际语料做AB测试。2.3 知识库和分站结构怎么联动上海多门店场景标题里特意提到了多城市Schema标记分站这背后有一个很常见的场景一家连锁品牌总部在上海在全国有分站。在GEO时代分站结构和知识库的关系需要重新理解。传统的分站做法是主站一个域名上海一个子目录或子域名其他城市各自一套。站在爬虫视角这没问题但站在大模型知识组织视角模型更倾向于引用信息密度高、实体关系完整的来源。如果你的上海分站下面没有任何结构化信息只是几篇门户新闻稿模型没法把上海门店识别为一个可靠实体。我们的做法是分站页面不再只放文章而是在页面里嵌入对应城市的门店实体信息块同时把分站的关键信息同步进统一知识库形成站点页面展示和知识库系统存储两个副本。这样模型无论通过网页抓取还是通过知识库检索拿到的都是同一套事实。2.4 最容易翻车的细节切分粒度、权限、陈旧内容知识库搭建中翻车概率最高的三个地方我单独拎出来说一下。切分粒度调参翻车。我们上线初期发现AI回答里经常出现这个服务我们不提供的错误排查了一圈是某个竞品文档里的不提供字样被切进了我们的知识片段。后来在切分规则里加了一条每段必须保留完整的主语宾语结构不允许从中间断开。这个小坑非常隐蔽能查出来全靠逐条对照AI回复里的引用原文。权限混乱导致数据污染。企业内部知识库往往有多个权限层级但当知识库用来投喂AI时所有被检索到的内容都会成为回答来源。一次我们把一个销售内部讨论版里的未定稿方案同步进了知识库AI在回答中直接把这个方案当成了既定服务来介绍。此后我们定了一个铁律进入AI知识库的内容必须与对外官网公示内容完全一致任何内部讨论材料一律隔离。陈旧内容的权重衰减。模型检索的时候不会判断信息新旧如果知识库里有一篇2022年的旧报价方案它可能和2024年的新报价同时被检索到AI就可能取旧数据回答。解决方案是给每个知识片段打上信息有效期并设置定期清理流程每月跑一次过期内容清单由业务负责人确认是否下线。3. Schema结构化数据落地多城市标记与AI解析的兼容性3.1 为什么AI搜索优化必须做Schema统一知识库解决的是让AI有内容可用Schema结构化数据解决的是让AI知道这些内容是什么。两者是配合关系。搜索引擎时代爬虫靠超链接和标签理解网页生成式AI时代模型主要靠海量语料预训练 实时检索来组织答案。但有一个普遍的技术共识结构化数据的置信度高于非结构化文本。当模型看到一个用Schema.org标准标记过的实体信息它会更倾向于认为这是官方、准确、可直接引用的信息因为JSON-LD格式本身带有清晰的语义路径。我们做过一个对比实验在官网首页加上Organization和LocalBusiness的JSON-LD标记后明显感觉到AI模型对我们实体评价的确定性更高了。比如问X公司是做什么的原来AI会说X公司是一家据说从事XX的公司措辞是推断语气Schema标记上线后回答变成了X公司是一家位于上海的XX服务商主要提供……语气从推测变成了陈述。这就是结构化数据的力量。3.2 Schema类型选型一张表讲清适用场景Schema.org的类型体系非常大但做GEO优化不需要全部铺开我们经过筛选实际只用了以下六种高频类型Schema类型适用场景关键字段Organization品牌总部信息全站基础name, url, logo, sameAs, contactPointLocalBusiness本地门店/服务网点多城市分站必备address, geo, openingHours, telephoneFAQPage常见问题聚合AI问答高优引用来源mainEntity(QuestionAnswer)Product/Service产品线或服务项目的属性描述name, description, offers, areaServedBreadcrumbList页面层级导航辅助AI理解站点结构itemListElementArticle新闻动态/行业洞察文章headline, datePublished, author我们的经验是基础的三件套Organization LocalBusiness FAQPage足以覆盖大多数企业的GEO需求。Product、Article这些看行业属性电商和内容平台再考虑延展。千万不要为了炫技把所有类型都加上Schema数量多但内容重复反而会稀释每个实体的信息权重。3.3 JSON-LD代码示例本地商户FAQ组合下面给一个我们实际在用的JSON-LD示例这是上海某门店页面的标记片段。注意不是静态死代码而是服务端渲染根据当前页面数据动态生成的确保始终和知识库内容同步。{ context: https://schema.org, graph: [ { type: LocalBusiness, id: https://example.com/shanghai#store, name: 某某服务·上海徐汇店, image: https://example.com/images/shanghai-store.jpg, url: https://example.com/shanghai, telephone: 86-21-12345678, priceRange: ¥¥, address: { type: PostalAddress, streetAddress: 徐汇区××路100号, addressLocality: 上海, addressRegion: 上海, postalCode: 200030, addressCountry: CN }, geo: { type: GeoCoordinates, latitude: 31.1885, longitude: 121.4362 }, openingHoursSpecification: { type: OpeningHoursSpecification, dayOfWeek: [Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday], opens: 09:00, closes: 21:00 }, areaServed: { type: City, name: 上海 } }, { type: FAQPage, mainEntity: [ { type: Question, name: 某某服务在上海有哪些门店, acceptedAnswer: { type: Answer, text: 品牌在上海设有徐汇、浦东、静安三家直营门店徐汇店位于××路100号浦东店位于××静安店位于××营业时间均为每天9:00-21:00。 } }, { type: Question, name: 某某服务的售后服务政策是什么, acceptedAnswer: { type: Answer, text: 产品自验收之日起30天内支持无理由退换1年内提供免费维修详情请见官网售后服务专区。 } } ] } ] }注意几个容易出错的位置id要稳定不要每次刷新生成不同IDFAQ的答案文本要用完整自然语句不能是短语拼接areaServed这个字段很多团队会漏但对本地服务的GEO优化非常关键它直接告诉AI这个实体的服务覆盖范围。3.4 多城市Schema标记分站的正确姿势多城市场景下最容易犯的错误是每个分站各做一套独立Schema彼此没有关联。正确的姿势是主站Organization标记作为总实体各城市LocalBusiness标记通过parentOrganization或department字段关联到主站。这样AI在整合信息时能理解上海门店属于某品牌这个层级关系。同时分站页面不要只做纯文本URL差异化要在内容区、地图区、FAQ区分别结构化标记。一个忠告是GeoCoordinates经纬度一定要写准确我们曾因为用了商场的中心坐标而不是门店实际坐标导致AI在回答离我最近的门店时给用户指错了方向。这个错误在搜索时代影响不大在AI对话场景里会直接导致用户不信任。3.5 LLM解析Schema失败的兼容处理Schema落地过程中我们遇到了一个很有意思的技术问题也是近期圈子里讨论度很高的一个现象LLM在调用Agent工具或解析函数参数时偶尔会返回provider rejected the request schema or tool payload之类的错误。简单说就是大模型虽然能理解Schema.org格式的数据但在把Schema作为工具调用参数时对格式的严格性要求非常高一个多余字段或类型不匹配就会导致整个请求被拒。这给我们的启示是Schema不仅仅要给爬虫看未来还要给AI Agent当工具说明书用。函数式SchemaOpenAPI样式和网页标记式SchemaJSON-LD要尽量保持一致的字段命名和数据格式。我们团队后端做了一个小工具把JSON-LD里的核心实体表定期导出为Agent可识别的tool schema两边共用同一套数据源。这就不会出现A页面标了电话号码但Agent函数里要求的字段叫phone这种低级错位。提示如果你在对接AI Agent过程中遇到schema payload被拒优先检查字段类型是否严格符合模型声明的格式比如字符串不能写成了数组其次检查有没有多余的、未在声明里出现的字段。模型对未声明字段的容忍度极低。4. 多模型监测AI排名本质上是一种引用感知4.1 为什么盯一个模型不够GEO优化做完之后最怕的事情就是闭门造车——我们在自己熟悉的模型上看到效果不错就以为万事大吉。但实际上不同AI模型的训练语料、检索策略、引用偏好差异巨大同一个问题在一款AI里的答案和另一款AI里的答案可能完全相反。我们目前监测的模型池覆盖了几个主要梯队国内主流的对话式产品豆包、Kimi、通义千问、文心一言等以及用户量较大的DeepSeek。每个模型的脾气都不一样有的偏好官网原文引用有的偏好第三方平台评价有的更看重结构化资料。如果你只优化某一家就可能失去其他渠道的曝光。多模型监测的核心目的不是追求在所有模型里都排第一而是最低限度避免在任何一个主流模型中消失或出现负面描述。4.2 监测问题集怎么设计问题集是监测的地基。我们按四层结构设计每层对应不同的商业目的品牌层XX公司怎么样XX是什么XX的官网在哪里——监测品牌基础认知的确定性。品类层上海做XX服务的有哪些公司XX服务哪家比较好——监测品类竞争中的提及度。场景层上海XX户型改造大概多少钱XX多久能完工——监测具体消费决策场景中的内容覆盖。竞品对比层XX和AA竞品有什么区别——监测AI对差异化优势的表述是否准确。每个层级保留5到10个核心问题固定问法每月可以追加一些热搜衍生问题。这里有个重要经验问题设计必须口语化真实用户问AI不会用请比较A公司的B服务与C公司的D服务在E场景下的F维度表现而是非常直接的上海××哪家好。4.3 API自动轮询与结果记录人工一个一个去AI对话框里问时间成本太高也容易漏数据。我们做了自动化的监测脚本通过各模型官方API或合规渠道批量提交问题集定时抓取返回结果。基础流程是这样的import time from datetime import datetime questions [ 上海做全案设计的公司推荐, XX品牌的口碑怎么样, 上海别墅装修报价一般多少 ] def poll_models(question): results {} # 依次调用各模型API这里以示例写法说明逻辑 # llm call_model(doubao, question) # results[doubao] parse_response(llm) # llm call_model(kimi, question) # results[kimi] parse_response(llm) time.sleep(2) # 控制请求频率,避免触发限流 return results # 每日定时执行,结果写入数据库 for q in questions: result poll_models(q) save_to_db({ question: q, result: result, timestamp: datetime.now().isoformat() })抓回来的数据不是看一眼就完事要进入结果分析层级是否提及、提及顺序、表述语气、信息准确性、引用来源。我们做了一个简单的评分模型每一条AI回答按这几个维度打分。比如AI回答是否把我们列为第一顺位AI对服务的描述是否准确有没有把我们说成不存在的服务AI答案里有没有过时信息。分数每周汇总一次成为增长例会上的关键输入。4.4 从监测到归因AI的回答质量、语气与来源多模型监测最有价值的部分不是看见了AI怎么说而是还原AI为什么这么说。一次我们发现某款AI在回答价格类问题时总是引用一个第三方平台上的旧报价我们的知识库里明明已经更新了最新价格。顺着链路排查发现那家第三方平台的文章没有被及时清理AI在检索时优先抓到了它。这就说明GEO优化不仅是优化自己的内容还要关注第三方平台上关于你的信息。我们在后续动作里增加了第三方平台信息核对的环节定期清理和修正外部渠道的过时描述。另一个发现是语气问题。AI在回答哪家好类问题时口头语里往往会有倾向性虽然A也不错但B更专业。这种语气差异很难用关键词排名来衡量需要细看回答上下文。我们的处理办法是对AI回答做细粒度的情感标注把推荐中性负面三种情况标记出来每周比对变化趋势。5. 增长闭环的运转机制内容、收录、流量如何互相喂养5.1 四环节闭环怎么走标题里提到的增长闭环很多人觉得是管理上的概念其实在我们的实践里它是一个非常具体的、可执行的工作流。我画过一张内部协作示意图大致的流转路径是这样的内容生产环节→ 根据多模型监测中发现的问题和用户搜索热词产出高质量内容不局限为文章还包括FAQ条目、案例故事、数据报告内容发布时直接做好Schema标记和知识库同步。知识库更新环节→ 新内容按前文说的五步流程进入统一知识库打上实体标签、地区标签、有效期元数据同时清理已经失效的旧内容保持知识库的新鲜度。AI收录与表现环节→ 多模型监测系统跟踪这些内容在各类AI产品中的被引用情况。注意这里看的不是收录率而是有效引用率——AI引用了你的信息之后回答是否变得更准确、更有利。流量转化与反馈环节→ AI引用带来的访问行为和询盘数据回流到数据分析系统反哺下一轮的内容选题。哪类内容AI喜欢引用且带来高转化询盘哪类内容虽然被引用但用户完全没点击一目了然。5.2 一个季度周期的数据变化案例用我们自己过去三个月的真实曲线来说效果比理论更直观。第一个月主要做知识库盘点和Schema上线。这个阶段AI引用率几乎没变化因为模型需要时间重新抓取和重新建立对实体的认知。第二个月开始在FAQ和场景内容上持续补充AI引用率开始抬头从初始的约12%提升到24%。第三个月在多模型监测的驱动下我们针对哪款AI都没提到我们的场景词专门产出了三篇深度案例文章AI在场景层的提及率明显上升。到季度末核心品牌词的AI正面提及率稳定在35%左右最关键的是AI带来的站内直接访问流量在总流量里占到了接近10%。这里想特别说明GEO不是线性增长的它有一个明显的爬坡-跃迁特征。知识库盘点期通常最痛苦因为脏数据会让你看到各种负面效果但一旦基础梳理完成后续内容补充的边际收益会显著放大。5.3 内容生产规范写人看的也给AI留钩子什么样的内容容易被AI引用我们总结了一套自己的写作规范核心是三个原则。第一个原则答案前置。AI在生成回答时非常偏好结构清晰、结论在前的文本。如果你能在一段文字的开头三句话类内直接回答上海地区价格区间是X到Y被引用的概率会大幅提升。不要学传统软文铺垫一堆最后才抛主题。第二个原则数字和事实要明确。AI引用内容时会偏好包含具体数字、日期、地点、服务范围的句子。比如服务覆盖上海全域就比服务范围广泛有价值得多。数据化表述给了模型更明确的引用依据。第三个原则层级化的FAQ体系。我们给每个核心业务都维护了一套FAQ分层级从品牌基础问题到场景深度问题。这套FAQ成为AI问答最稳定的引用来源。实践下来FAQ在AI回答中的引用率远高于长篇大论的文章。记住这句话在GEO时代FAQ是性价比最高的内容形态。6. 上海落地实践中的取舍与避坑清单6.1 团队分工与预算安排落地GEO项目不需要庞大的团队但需要清晰的职责划分。我们的配置是1名内容运营负责知识库维护和内容生产1名技术同事兼职负责Schema和API监测增长负责人每周花半天看监测报告并定决策。预算上最大的成本不是工具费用而是内容梳理和时间投入。如果企业内容基础很差建议预留至少20%的项目预算给知识库清洗和内容补齐。工具方面可以先用开源的RAG框架和低成本的监测脚本跑通有规模需求后再上商业化工具没必要一上来就采购昂贵的GEO优化平台。6.2 工具选型自研、开源还是SaaS工具选型是大家问得最多的问题我分开说知识库管理我们优先选择了Dify这类开源流水线因为它能灵活对接各种模型API和向量数据库知识库切分、召回配置都可控。如果企业已经有内容管理系统也可以先用Obsidian这类个人知识库工具跑MVP把手写文档整理成标准结构再迁移到企业级RAG系统。Obsidian双层链接的思维方式对实体关系的梳理很有参考价值。Schema维护不建议完全手工管理JSON-LD很容易漏更新。我们做了一个简单的内容源同步逻辑后台业务系统里配置了实体信息发布时自动渲染到页面模板并输出JSON-LD。如果用WordPress或同类CMS也有现成的SEO插件支持基础Schema生成但多城市层级关系和自定义FAQ还是需要自己改模板。多模型监测开源社区有一些AI搜索监测项目可以借鉴但考虑到模型API的更新频率自研脚本维护成本并不低。我们的建议是先自研脚本跑小规模问题集确认ROI后再决定是否引入商业化工具。RAG知识库领域开源方案和SaaS方案的区别主要在于数据安全性、召回可调性和更新时效企业可按自身情况选。6.3 三个伪需求与一个真命题做完这个项目市面上各种讨论也很多我总结了三个容易被误判的伪需求和它们背后的真命题伪需求一要求一周之内AI排名进前三。AI模型的更新是有周期的不是搜索结果可以靠刷排名解决。真命题是在Q2内把知识库基础搭好、Schema上线、监测跑通Q3才可能出现明显效果。谁跟你保证一周见效谁就是在骗你。伪需求二只做Schema结构化不做内容更新。Schema是告诉AI这是什么但AI回答的弹药还是来自内容。空有标记没有内容就像给空盒子贴了漂亮的标签。真命题是Schema是放大器内容是信号源两者同步推进才有价值。伪需求三把所有官方资料一股脑投喂给AI。信息过多、互相矛盾AI就会混淆。真命题是宁缺毋滥知识库里只有经过确认的、口径一致的内容。每一条进AI知识库的内容都要经过能不能对外公示的考验。6.4 ROI如何衡量最后说ROI。GEO的效果不能只看传统流量指标我们内部定义了三级指标第一级是引用可见性指标品牌词在AI回答中的正面提及率、品类词中的被推荐率、信息准确率。这些指标本质上是品牌在AI世界的市场份额。第二级是行为转化指标来自AI产品的点击、访问、询盘、成交。可以通过UTM参数和动态链接追踪部分AI推荐流量虽然做不到100%精确但能抓出大体量。第三级是资产沉淀指标知识库条目数、Schema覆盖的页面数、多模型监测的连续性这些是基础设施层面的健康度。我个人对GEO项目的判断标准很简单**如果六个月后AI在回答你所在行业的核心问题时引用的信息比六个月前更准确、更偏向你的品牌这个项目的价值就已经成立了。**至于流量和转化那是水到渠成的事。上海市场的竞争节奏很快很多同行还在犹豫要不要做GEO我建议的时间点是先动起来。用最低成本跑通知识库—Schema—监测这条小闭环积累数据之后再逐步放大。等风向明朗的时候早期积累的AI引用资产会成为别人追不上的门槛。
![从摇瓶到开题：生物化工er的 AI 工具搭子怎么选？[特殊字符]](http://pic.xiahunao.cn/yaotu/从摇瓶到开题：生物化工er的 AI 工具搭子怎么选？[特殊字符])
