我今年上半年接到一个上海的客户项目对方负责人给我看了一张AI搜索结果截图里面回答“XX品类哪家好”这个问题时推荐的整整五家竞品没有一家是他们。更扎心的是搜索他们自己的品牌词AI模型连品牌核心业务都描述得含糊其辞。这种体验我相信很多做品牌的朋友都不陌生——传统搜索引擎的流量还在但用户的注意力已经开始把AI当作第一入口了。我们做的事就是AI搜索GEO优化落地。简单说就是先通过统一知识库把企业零散的内容资产盘活再用Schema结构化数据让AI模型读懂“这家企业是谁、在哪、提供什么服务”接着用多模型监测盯着各大AI引擎对品牌的引用和推荐情况最后把监测数据拉回内容生产环节形成增长闭环。整套方案在上海这家本地生活服务企业跑了大约四个月核心服务词的AI搜索引用率从0提升到接近四成自然流量也出现了肉眼可见的回升。这篇文章我就把这套打法完整拆开讲包括每一步的选型逻辑、实操细节和踩过的坑给正在纠结怎么做GEO的团队一个可以直接抄作业的参考。1. 项目背景与整体设计思路1.1 为什么GEO不是换了个名字的SEO在讲具体方案之前先说清楚GEO到底解决了什么问题。数字营销圈这几年有一个比较清晰的演进脉络从SEO到AEO再到GEO后面还有个更前沿的AAO。SEO做的是让网页在传统搜索引擎里排名靠前AEO做的是让内容成为“答案引擎”的直接答案而GEO做的是让AI大模型在生成式回答中主动引用、推荐你的内容。AAO则是更远的个性化智能体阶段暂时还不在绝大多数企业的落地范围内。这四者不是替代关系而是叠加关系。SEO流量不会瞬间消失但用户问AI的次数会持续增长尤其在上海这种生活服务竞争激烈的市场用户已经开始习惯直接问“哪家服务好”“怎么选”AI给出的答案等于提前替用户做了一次品牌筛选。如果品牌在AI答案里隐身那后面所有的营销动作都失去了一个前置入口。GEO和SEO最核心的差异在于“优化对象”。SEO优化的是爬虫和排名算法你只需要关心关键词密度、外链、加载速度这些信号。GEO优化的是大模型的理解、检索和引用决策你要让模型在生成回答时认为你的内容是“最值得引用”的信源。这意味着你既要提供机器可读的结构化信息也要保证内容本身的信息质量足够高还要持续观测不同模型对你的引用态度。1.2 四条主线是怎么协同起来的这个项目的整体设计可以拆成四条主线缺一不可。统一知识库是内容基座。先把散落在官网、公众号、知乎、门店信息、客服话术里的内容统一清洗、切块、向量化形成一个AI可检索的内容资产池。没有这一步后面所有优化都是无源之水。Schema结构化数据是技术基座。通过JSON-LD标记把企业实体、服务范围、FAQ、地理位置等信息显式地告诉模型相当于给AI画了一张企业信息地图。模型理解你的速度快了引用你内容的概率自然高。多模型监测是度量基座。不同AI引擎的检索和引用策略差异非常大只盯一个模型很容易产生误判。我们在ChatGPT、Perplexity、Kimi、豆包、通义千问等引擎上建立了一套固定的监测问题集按周记录引用率和推荐语境。增长闭环是运营基座。监测数据不能只停留在报表里要回流到内容选题、知识库更新和Schema调整中。哪类问题品牌未被引用就优先生产哪类内容哪个页面被多个模型引用就加大对这个主题的投入。这四条线的关系我习惯用一句话概括知识库负责“有料”Schema负责“被看懂”多模型监测负责“看清效果”增长闭环负责“越做越准”。它们不是一个线性的项目流程而是一个持续运转的飞轮。2. 统一知识库让AI搜得到的前提2.1 内容资产盘点第一步不是建库而是清点家底很多团队一上来就急着选知识库工具、跑向量化这是顺序错了。我接到这个项目后先做了一周的内容资产盘点列了一张很粗的表格把客户所有和品牌相关的内容源摸了一遍底。内容源载体形式数量级质量状态优先级官网产品/服务页HTML40部分页面陈旧P0微信公众号文章图文200排版脏、含图片文字P0知乎机构号内容专栏/问答60质量高但分散P1门店/服务网点信息数据库30结构规整P0客服FAQ话术文档100散落多个系统P1小红书种草笔记图文80适合做场景词P2这次盘点的价值在于我们发现了几个后续影响很大的问题官网有三分之一的服务页描述非常单薄只有两三句话加一张图这种页面模型根本没法提取有效信息公众号文章大量信息藏在图片里OCR之前等于不存在各地分站的内容重复度极高同一段介绍改个城市名就发布了。内容盘点不是体力活它决定了知识库的边界和后续优化的优先级。没有这一步直接建库大概率会把低质量内容也向量化进去脏数据会持续污染检索结果。2.2 知识库工具选型为什么选了“内容资产池RAG流水线”的组合盘点完资产接下来是选型。客户内部有同事建议直接用Notion搭一个内部知识库还有人说用Obsidian甚至有人提议上企业微信文档。这些工具做内部协作没问题但GEO场景下有一个本质差异知识库最终要服务于外部AI引擎的检索和引用。我们的目标是建一个“AI可读资产池”而不是一个内部文档系统。最终方案是两条腿走路内容协同用飞书云文档因为客户团队已经重度使用飞书对外统一收口到官网和授权内容平台所有内容先清洗成干净的Markdown再进入一个基于Dify搭建的RAG流水线完成切块、向量化、索引和检索测试。向量化模型当时对比了OpenAI的text-embedding-3-small、智源的BGE-M3和阿里通用文本向量模型最后线上用了BGE-M3。原因有两个一是中文长文本效果实测更稳对品牌类长描述的理解明显更准二是BGE-M3支持稠密检索和稀疏检索的混合模式在后续做混合检索时不需要额外维护两套向量。Dify在这个项目里承担的角色很大它不是简单把文档丢进去就完事而是把“内容更新→清洗→切块→向量化→检索测试”的流水线串起来了。飞书文档更新后自动触发同步增量更新的设计让知识库始终保持最新这个在后面的监测复测环节帮了大忙。2.3 清洗与切块决定检索命中率的隐藏细节知识库搭建中最容易翻车的是清洗和切块。我见过太多团队直接把公众号文章导出成PDF就丢进知识库结果检索时匹配到的全是“点击上方蓝字关注我们”这种垃圾片段。清洗阶段我们写了一套Python脚本核心做了三件事去掉公众号排版里的固定装饰文案和二维码引导语把长表格转成干净的Markdown表格格式防止向量化时表格结构错乱对图片里的关键文字做OCR识别并补充到正文里这个动作让知识库的召回质量提升非常明显。切块策略更关键。我们没有用固定字数硬切因为中国企业的页面结构差异太大。最终采用的是按标题层级切块以H2和H3作为自然边界每一块控制在500到800字之间并保留一个带有上下文的锚点前缀。比如某服务页的H3“售后保障范围”会带着H2“服务流程”的上下文信息一起切出来这样模型在检索时能理解这段内容属于哪个主题域。另一个细节是重叠窗口。相邻两个块之间重叠一到两个句子避免一个完整信息被拦腰截断。这些策略看起来笨拙但实际跑下来检索命中率比固定800字暴力切块高了差不多15个百分点。知识库上线后我们用一个两百个问题的测试集跑了一遍核心问题类型命中率在八成左右这个结果支撑了后续优化动作的推进。3. Schema结构化数据把内容包装成AI能看懂的信息3.1 Schema为什么对GEO有效很多人觉得Schema是SEO老技术和AI搜索没什么关系。这个理解在GEO场景下是片面的。AI模型虽然不像传统爬虫那样直接按Schema解析排名但Schema提供的实体关系信号能显著降低模型理解页面的成本尤其是在处理“这家企业到底卖什么、覆盖哪些区域、有什么资质”这类事实性问题时。传统搜索引擎读Schema是为了展示富媒体摘要AI模型读Schema是为了建立实体关联。一个带有Organization、Geo、FAQPage结构化标记的页面和一个只有纯文本的页面在模型面前的信息密度是完全不同的。模型不需要从一段话里猜这家企业有多少年经验、服务哪些城市因为JSON-LD已经把答案写清楚了。这次项目中我们给客户官网全面部署了JSON-LD标记覆盖了六类核心页面。下面这段是我们在某城市服务页上实际使用的Schema简化示例{ context: https://schema.org, graph: [ { type: Organization, id: https://www.example.com/#organization, name: 示例企业名称, url: https://www.example.com/, logo: { type: ImageObject, url: https://www.example.com/logo.png }, sameAs: [ https://www.zhihu.com/org/example, https://weibo.com/example ] }, { type: LocalBusiness, id: https://www.example.com/shanghai/#localbusiness, name: 示例企业上海店, image: https://www.example.com/store-shanghai.jpg, telephone: 86-21-12345678, address: { type: PostalAddress, addressLocality: 上海, addressRegion: 上海, streetAddress: 某某路100号 }, geo: { type: GeoCoordinates, latitude: 31.2304, longitude: 121.4737 }, areaServed: { type: City, name: 上海 }, priceRange: $$ }, { type: FAQPage, id: https://www.example.com/faq/#faqpage, mainEntity: [ { type: Question, name: 示例企业提供哪些服务, acceptedAnswer: { type: Answer, text: 我们提供……服务覆盖上海全区域。 } } ] } ] }这里有一个关键点FAQPage里的问答应尽量和页面正文内容保持一致不要为了堆结构写一些页面里根本没有的答案。模型在训练和推理时会交叉验证结构化数据和正文的一致性如果发现对应不上反而会伤害可信度。3.2 多城市分站的Schema部署细节客户有一个典型场景是多城市覆盖官网按照城市做了分站。分站如果只是复制主站内容Schema再怎么标也救不回来。我们在分站部署上做了三个动作每个分站用独立的LocalBusiness节点geo坐标精确到所在城市的经纬度areaServed用City类型做明确的服务区域声明分站之间通过主站Organization节点的sameAs建立关联而不是让每个分站像一座孤岛。多城市Schema标记还有一个容易被忽略的坑地址信息必须和页面上展示的信息完全一致。之前客户有些分站页面显示的是总部地址而Schema里写的是分站地址这种不一致信息会让模型的实体识别产生错乱。3.3 动态注入和Online校验客户官网基于Next.js构建JSON-LD我们选择了动态注入方案在页面组件里根据当前页面类型生成对应的Schema对象然后渲染到Head区域。这样做的优势是新增内容页时不需要手工维护标记所有Schema都由模板自动生成减少了人为出错概率。上线后我们用Google的结构化数据测试工具和一个Schema校验工具分别跑了一遍重点检查三项JSON语法是否合法、id是否存在重复冲突、页面内容与Schema声明是否一致。第一次校验结果里大概有六七个页面有问题大部分是FAQPage里的问答内容过长超出了正常长度建议另外两个是geo坐标格式错误。这些问题如果不提前查出来等搜索引擎或者AI引擎爬取时就会直接忽略标记。部署Schema后大约三周我们观察到两个变化一是多模型监测里品牌词相关的实体描述准确率明显上升之前有AI引擎把客户描述成“中介平台”Schema上线后回答里开始出现正确的“服务商”定位二是FAQ类问题的引用率开始出现增长一些AI答案直接采用了FAQ的结构化内容。4. 多模型监测不是用一个引擎看效果4.1 监测问题集怎么设计GEO效果监测最大的坑是“用单一模型搜一下品牌词就下结论”。不同AI引擎的语料来源、检索策略、回答风格差异极大同一个问题在ChatGPT上品牌被引用在Kimi上可能完全隐身。只有建立一套跨模型、固定口径的监测体系才能真实反映品牌的AI搜索可见度。我们把监测问题集分成了四类品牌词类用来验证实体识别准确性品类词类用来观察品牌是否被推荐竞品词类用来检验竞争位置场景词类用来发现用户真实需求与品牌内容之间的匹配度。每一类下面又细化了具体问法比如“XX品类哪家好”“XX应该怎么选”“XX服务大概多少钱”这种真实用户口语化的表述。问题集确定后就固定下来不要频繁改动。AI模型的回答本身具有随机性同一个问题连续问三次结果都可能不同固定问题集才能做趋势对比。我们每台引擎每个问题至少跑三轮记录所有提及品牌的内容样本。4.2 评价指标和工具选择两套评价维度并行。首先是客观的统计指标引用率即多少轮回答中品牌被当作信息来源提及链接可见性即品牌官方链接是否出现在回答的引用来源中推荐语境即回答是正面推荐、中性提到还是负面关联。其次是内容质量维度品牌描述是否准确、推荐的场景是否匹配、有没有被错误归类。工具层面我们用了AI OS类的监测平台搭配自建脚本。监测平台负责批量获取各大AI引擎对固定问题集的回答快照自建脚本负责把结果结构化存储然后人工复核一遍每次的回答内容。单靠平台完全自动化目前不现实因为AI回答的语义判断还需要人来兜底。下面截取我们某一次周报中的实际监测表格片段这会比较直观问题类型ChatGPTPerplexityKimi豆包通义千问品牌词实体识别准确准确准确准确准确品类词推荐提及有引用有引用未提及未提及有引用竞品词竞争关联中性提到未提及中性提到未提及未提及场景词需求匹配有引用有引用有引用未提及有引用4.3 不同模型的“脾气”差异跑了这么久的监测一个很深的体会是不同AI引擎简直是不同性格的推荐官。Perplexity是“信源控”它非常依赖检索到的外部链接引用来源展示得很明显所以对知识库覆盖度高、Schema齐整的页面特别友好。条款类、价格类、服务流程类问题在Perplexity上的引用率提升很快。ChatGPT更偏向“对话式推荐”多轮追问时它会综合上下文推荐品牌但对新内容的收敛速度不如Perplexity快尤其是新上线的内容如果没有在多个独立来源形成交叉印证它通常不敢直接作为答案引用。Kimi在中文长文理解上表现突出对知乎、公众号这类长内容偏好明显所以在Kimi上知识库里的深度长文和FAQ话术起了很大作用。豆包则对结构化信息尤其敏感FAQPage的Schema内容在豆包上更容易被直接采纳。这也说明了为什么统一知识库和Schema部署必须同步推进不同模型吃的是不同形态的“粮食”。监测周报的固定格式也很重要我们每周输出三张表各模型引用率变化趋势、问题类型的覆盖矩阵、重点内容页面的引用表现。这个周报不仅是给客户看的也是我们内部调整优化策略的核心依据。5. 增长闭环把监测数据拉回内容生产5.1 四步闭环的具体玩法监测数据如果只沉淀在周报里那GEO优化就是一次性的美化工程不是增长引擎。我们的闭环是监测、洞察、生产、验证四步循环。洞察是最容易偷懒也最关键的环节。每次监测后我们不是单纯统计“哪些词没上榜”而是看用户问法背后的真实需求缺口。有一次监测发现“XX服务价格”这个问题在多个AI引擎上都没有引用客户内容但竞品被推荐了。追踪下去发现竞品页面虽然没有报价表但内容里很清楚地描述了价格区间和影响因素。我们当时就意识到客户官网虽然服务页很齐全但一直回避谈价格这在AI搜索场景里等于主动放弃了最核心的转化型问题。生产环节围绕洞察结果展开。那之后我们专门生产了一批对应内容不是传统意义上的“SEO文章”而是针对AI引用结构优化的“GEO内容”标题直接采用用户问法开头用清晰的事实性陈述给出核心答案正文按维度拆成小标题段落关键信息用列表和表格呈现结尾补充资质、案例和数据。这种内容形式既是给人类读者看的更是给AI模型“裁切”用的。新内容发布后自动同步进知识库并检查对应页面Schema是否完整。然后等爬虫重新收录一般需要两到四周的沉淀期再纳入下一轮监测问题集复测。5.2 一个词从0到40%引用率的自然增长过程举一个实际的增长案例。客户有一个核心服务词最初在所有监测引擎上的引用率都是0。这个现象其实挺反常的因为客户在这个服务上经营了很多年资历和口碑都不差但AI搜索完全不推荐。我们拆解后发现三个问题一是官网服务页描述过于官方通篇都是“致力于”“专注于”这种没有信息量的表述二是知乎上虽然有一篇深度介绍但内容和官网页面存在明显差异模型无法建立关联三是没有一篇内容直接回答“这个服务怎么选”这类决策型问题。针对这三个问题我们分别做了调整重写官网服务页加入服务流程、服务团队背景、典型客户案例等事实信息在知乎和公众号发布问答型长文并在文中自然引用官网的一致信息新增了决策型FAQ内容用Schema的FAQPage部署。内容上线后第七周首次在Perplexity上看到引用第十周ChatGPT开始推荐到第四个月监测周期这个服务词的引用率已经稳定在四成左右。自然流量方面官网该服务相关页面的周访问量也环比增长了接近一倍。这个过程没有做任何黑帽操作纯粹是靠内容覆盖和结构优化。5.3 团队分工和节奏建议做GEO不能只靠一个SEO专员也不能只靠技术团队。这个项目实际投入了三类角色内容岗负责选题、撰写、审核技术岗负责Schema、知识库流水线和数据采集数据岗负责监测、统计和洞察。每周一次例会先过监测周报再过上一周期内容效果最后对齐本周期生产计划。如果团队比较小至少也要保证一个人盯内容、一个人盯技术和数据。最大的风险是内容和技术脱节——内容生产了一堆优质页面但知识库没同步Schema没部署结果AI搜不到等于白做。我们后来定了一条硬规矩新内容上线必须同时完成知识库同步和Schema部署这步走不完就不算发布完成。6. 常见问题与排查技巧实录6.1 知识库检索匹配度低这个问题出现的频率最高。处理路径三板斧先检查清洗环节看看粘贴进知识库的内容是不是干净文本有没有残留标签和导航文案再检查切块策略如果内容块太大或者太小都会影响召回质量一般建议按标题层级切500到800字窗口最后考虑加rerank模型Dify里可以挂一个交叉编码器的重排模型第一次排序后重排一下检索精准度会有明显提升。6.2 Schema部署后迟迟看不到效果不要指望Schema上线当天就有效果。AI模型爬虫的更新周期各不相同有的几天有的要几周。判断Schema本身是否生效可以用工具抓取页面源码看生成结果是否正常返回也可以直接把URL丢给一个AI引擎问它“这个页面讲了什么”看它的回答是否包含了Schema里声明的实体信息。如果模型已经能准确说出地址、服务范围这些结构化信息说明标记是生效的剩下的只是时间问题。6.3 不同模型监测结果差异很大这属于正常现象不用慌。AI模型的语料来源和检索策略不同本来就该存在差异。正确的做法是分模型看趋势而不是追求所有模型表现一致。如果某个模型连续两轮监测在同一类问题上都“隐身”那就是一个值得深挖的洞察信号大概率是这个模型更偏好某种特定形态的内容。6.4 新内容迟迟不被AI引用最常见的原因是内容缺乏“交叉印证”。单个页面的内容再优质如果全网没有第二个独立来源提到同样的信息模型会认为这个信息不够可靠。解决方法是在公众号、知乎、百家号等多平台同步发布核心事实内容多个来源指向同一个信息后被引用的概率会大幅增加。另外新内容上线后要尽快提交链接给各平台的收录入口缩短爬虫发现时间。6.5 知识库常见问题速查表问题现象可能原因排查优先级检索召回结果乱清洗不彻底脏文本进入向量库高匹配片段太碎切块窗口太小信息不完整高已发布内容搜不到知识库未同步或增量更新失效中模型回答引用的是旧信息页面已更新但爬虫未重新收录中Schema校验报错JSON语法或id重复冲突高这次项目做下来我个人最深的体会是GEO优化没有那么多玄学核心就是把企业内容资产当成一种AI可消费的数据产品来运营。知识库决定了AI有没有素材可用Schema决定了AI能不能快速看懂多模型监测决定了你能不能看清真实的位置增长闭环决定了你能否持续前进。这四件事单独拎出任何一件都撑不起效果协同起来才是完整的GEO落地体系。最后再分享一个小技巧如果你刚开始做GEO不用一次性把全站内容都重做先挑十个核心服务词对应的页面把知识库、Schema、监测这三件套跑通看到第一个引用率的变化后再复制到其他页面。小步快跑比一开始就铺一个大盘子稳妥得多。