如果你还在用传统 SEO 的思路做 AI 搜索的流量大概率会越做越沮丧。传统搜索给用户十条蓝色链接用户自己挑AI 搜索直接把答案组织好念给用户听最多尾巴上挂几个来源。用户几乎不会逐个点开链接验证但那个被大模型“选中”的来源里是不是你、你的信息是不是准确直接决定了整条业务线的曝光和转化。我们项目 base 在上海团队大半年时间都在做一件事把 AI 搜索的 GEOGenerative Engine Optimization生成引擎优化从“改改页面、加加结构化数据”的零散动作推成一条能持续跑起来的流水线。复盘下来这条流水线正好对应标题里那五个词——知识治理、问题建模、内容分发、多模型监测、归因迭代。它们不是并列的五件独立事项而是一个必须顺序打通、循环反馈的闭环。知识治理没做好后面问题建模再漂亮模型引用的也可能是过时错误信息监测只做不做归因那就等于花了钱买一堆漂亮的截图最后一版报告改完就扔进抽屉。这篇内容把我自己的真实做法、踩过的坑和关键判断标准写出来按这个顺序讲适合正在做网站运营、品牌内容、搜索优化或者想搞懂 GEO 的团队参考。1. 项目定位与闭环设计思路1.1 GEO 到底改变了什么GEO 这个概念刚出来的时候网上很多人争论“这不就是 SEO 换皮吗”我一开始也不完全确定等我们亲自把测试用例跑起来之后才意识到两者的底层逻辑不一样。SEO 关心的是当用户搜索某个关键词时我的页面排在搜索结果第几位。GEO 关心的是两件事第一AI 生成引擎在组织完整答案时有没有把我们认定为可靠信息源第二它在回答里给出的引用链接、推荐表述是否让用户对我们产生信任并发生行动。差别非常大。传统搜索里你页面排在第十位也能拿到流量在 AI 搜索里回答可能只有几段话加三个引用来源引用意味着“是否存在”而不是“排名第几”。如果模型最后只输出两个来源没有你那你整个站点几乎就是隐形状态。我们内部做过对比同一个问题同一篇高质量内容传统搜索因为外部外链少排名靠后但在 AI 搜索中反而经常被引用因为内容本身结构清楚、信息密度高、主体明确。这说明老一套外链权重思路碰到生成式引擎时需要被重新审视。1.2 为什么必须把五个环节串成闭环项目一开始我们走的还是老路内容团队按照百科词条风格重写了页面技术团队把 JSON-LD 结构化数据补齐了SRE 还专门调了 robots 策略。改完之后上线看效果发现某些模型里的引用率确实往上走了一点但你根本说不清楚到底是哪一步起作用。更要命的是有些问题在某个模型里被正确引用换一个模型又完全消失连原因都摸不着。后来我们复盘核心问题是没有把数据串起来。比如内容改了但不知道是针对哪一个用户问题做的变更知道这个问题在豆包上被正确回答了不知道这里引用的知识版本是旧的还是新的知道某个监测指标涨了不知道应该奖励给内容组还是算法组。这逼着我们重新梳理了端到端流程把问题理解、知识库质量、内容结构和结果反馈放在同一个数据链条里看只有这样才能定位、优化、再验证。所以这个项目真正交付的不是某一个页面改版而是一套“定义问题—准备语料—内容建设—效果采集—动作归因”的闭环机制。1.3 落地前的两个关键判断先潦草说一下我们开工前的两个判断也给后来人一个参考。第一个判断是“要不要把所有 AI 引擎都当成优化对象”。市面上的生成式引擎太多了ChatGPT、Perplexity、豆包、Kimi、文心一言、腾讯元宝等等模型能力、更新频率、引用习惯差异很大。如果全部铺开测试和标注成本会吃掉整个项目的预算。我们最后选了“头部 4 个模型 小范围新模型灰度”的组合确保主流用户覆盖住留下观察窗口去判断新引擎是否值得投入。第二个判断是“做成单点项目还是长期运营”。AI 搜索的结果质量依赖知识库持续保鲜不是一次发布就完成的任务。如果老板问你要一个“三个月做完 GEO”的项目排期那基本可以预期效果会很差。建议明确这是一个常态化运营方向至少为六个模块中的“知识治理”和“多模型监测”预留持续性资源。这两个判断直接决定了后续每一条工作项的优先级。2. 知识治理让 AI 引擎读得懂、敢引用2.1 从资产盘点开始知识治理听起来很宏大落地的第一步却很朴素把内容资产完整盘点清楚。我们管它叫“AI 可见性盘点”。你需要回答几个问题业务的核心页面有没有被生成引擎的爬虫正常抓取robots.txt 有没有出现不必要的大段屏蔽关键内容是不是被压在登录墙后面核心页面的历史版本是否存在大量 404 或跳转这些基础问题不做后面给内容做结构化等于是在沙子上盖楼。当时我们梳理出一张全站内容地图按内容类型分成几类商家/门店页、攻略文章、榜单页、用户问答、品牌介绍、FAQ 块。再对照业务目标给每类内容标注“是否核心资产”比如门店页的营业时间、地址、联系电话、服务项目属于绝对不能让 AI 答错的高敏感信息榜单页和攻略文主要用于获得场景化的推荐引用。盘完之后发现很多问题约 12% 的老活动页已经被关闭但还残留着能让爬虫访问的空壳页面一些核心门店信息页面存放在子域名下主站 sitemap 没包含生成引擎抓取概率极低。2.2 建立“事实 规则”双轨机制资产盘点只能让我们知道有什么真正体现治理水平的是怎么保证 AI 引擎拿到的信息是可信的。我们设计了一个比较土但很有效的“事实 规则”双轨机制。事实轨是指业务信息本身比如门店营业时间、价格、服务范围、联系方式这些信息不能只散落在文章描述里必须放进统一字段维护再通过模板自动渲染到页面。规则轨是指那些不能被不同页面重复、口径打架的规则例如品牌标准叫法、产品分类层级、地名别名。为什么要在 AI 搜索场景下死磕这件事因为大模型在组织答案时会融合多个来源。假如你的官网 A 页面写着“周一至周日 9:00-21:00”B 页面却写着“周一至周五 10:00-22:00”AI 引擎抓取后很可能生成一个自相矛盾的营业时间。我们很快就发现这类错误对本地生活服务的伤害远大于传统搜索——传统搜索的错误只是你点进去才发现AI 搜索的错误是模型当着用户的面说错用户会把“错误信息”和“品牌不可靠”直接划等号。当时为了快速止血我们搭了一个非常简单的每日一致性校验脚本从核心页面抽取出时间、地址、电话等字段和主数据库比对不一致的直接报警。这个方法技术含量不高但挽救了至少几十个高流量门店页在模型里的可信度。对任何想做 GEO 的团队我建议不要一上来就上复杂的数据中台先搞一个低成本校验规则哪怕每周人工抽检一次也比没有强。2.3 别忘了实体和图谱层面的治理如果说字段一致性是知识治理的“干净卫生”那实体层面的治理就是“让 AI 认出你是谁”。很多网站内容写得很好但大模型并不清楚这个页面到底在描述哪一个实体导致引用的时候张冠李戴。比如我们业务里有个品牌在页面上时而被叫全称、时而被叫简称英文名和中文名混着用门店在人民广场还是静安寺也会在文案变体中出现。这会导致模型很难建立稳定关联。后来我们用了相对标准的方法每个核心实体品牌、门店、服务项目维护一个 ID页面通过 schema.org 标记里的 sameAs、identifier、url 等属性把实体 ID 暴露给爬虫。注意不是加越多越好的 JSON-LD而是要让同一个实体在全站拥有唯一的语义标识。做完这步AI 在回答里引用我们内容时会把品牌名称和具体门店对应得更准确。这里特别提醒一句不要把实体标识做成内部数据库的自定义字符串而不做映射AI 引擎认不出你的内部 ID 没有意义需要在结构化数据中同时保留官网 URL、标准名称和稳定的行业标识。3. 问题建模从用户问法倒推内容策略3.1 别再用关键词思维理解用户问题传统 SEO 习惯围绕关键词做文章比如“上海亲子餐厅”“静安寺本帮菜推荐”这类词确实能覆盖一部分搜索需求。但 AI 搜索里用户输入的问题更像是真实聊天一句“周六下午想带五岁娃去静安寺附近吃饭有什么不排队还适合孩子的地方”里面有场景周六下午、有主体五岁的孩子、有区域约束静安寺附近、有明确需求不排队、适合孩子。如果只按“亲子餐厅”来准备内容很难覆盖到这种口语化长尾问题。问题建模的核心就是把这些五花八门的问法抽象成有规则的结构。我们参考了搜索产品里常用的任务分类但在落地时做了本地生活化的调整把问题分成几类事实查询型营业时间、地址、攻略建议型推荐、适合、比较选择型A 和 B 哪个好、产品确认型是否有某服务、事务办理型怎么预约、怎么取消。分类做完后每个问题都要回答三个子问题用户想知道什么用户处在什么决策阶段用户期望的答案形式是什么。3.2 把口语问题翻译成结构化查询对象这一步比较容易理解但也最容易走过场。不能只做“标签”必须把问题映射到一个包含多个维度的查询对象上才能真正发现内容缺口。我们对本地生活场景总结了典型的维度集合业务领域餐饮、亲子、医疗美容、文化娱乐等区域范围具体商圈、行政区、地标附近用户特征年龄、是否带孩子、人数消费偏好性价比、高端、环境安静、出片时间约束周末、工作日晚上、节假日服务属性停车、预约、外摆、儿童设施拿前面那句口语问题举例解析出来的查询对象是“业务领域餐饮区域静安寺/南京西路商圈用户特征亲子消费偏好不排队/儿童友好时间周末下午”。运营同学拿着这个结构化对象去检查页面内容时一眼就能看出来缺了什么比如页面上可能写了很多“适合亲子”的推荐但完全没有提到排队情况和周末高峰时段AI 在组织答案时就会缺少能引用的关键信息。这套方法的本质就是把 AI 搜索当成一个需要填空的信息组织者我们生产的内容要提前把所有空格填好。3.3 问题覆盖率分析找到真正的缺口问题建模不只是为了回答已有的问题还需要知道“哪些问题可能会被问但现有内容完全没覆盖”。我们在操作中把问题来源分成三路站内搜索日志和客服会话、竞品的常见问题页面和评论区、以及用大模型批量生成相关问题再人工抽检。把这些候选问题按我们自己的维度标准处理后与现有内容的主题相似度做比对低于阈值的问题就进“内容缺口池”。有段时间我们发现一个有意思的现象不少用户问“某商圈附近适合多人聚餐的本帮菜馆有哪些包间”但我们所有的商家页都把包间信息放在一两张环境图里文字描述几乎没有。对传统搜索来说文字没有不一定致命但对 AI 搜索来说图片里的内容很难被准确引用为事实依据。后来我们给所有有包间的门店页补了一句话的结构化字段“包间数量8 间 / 最大容纳人数12 人”这个问题在监测模型里的引用率立刻提升。类似这样的缺口只有通过问题到内容的映射才能系统地找出靠编辑碰运气很难做到。3.4 问题池怎么维护才不过期问题建模最好能沉淀为一个动态问题池而不是做一次就完。我们把问题池放在一个带状态的表格里每个问题有状态待确认、已覆盖、监测中、失效、关联页面 URL、最近更新时间、各模型引用情况。每周由运营同事根据新出现的搜索热词和客服反馈往池子里补问题数据团队负责计算问题和目标内容的语义相似度帮助确认新增问题的潜在价值。这里想多说一句维护节奏。问题池不需要无限扩张如果你发现 2000 个问题里有大量问题是低频且没有商业价值的就应该果断砍掉。同时要小心“问题表面相同但答案已经变化”比如某个商场改造后停车入口变了原来“怎么停车”这类问题的答案已经全部失效如果不主动更新问题状态后面监测和归因都会基于过时答案展开整个闭环的数据质量都会受到污染。4. 内容分发设计 AI 引擎认可和易引用的语料形态4.1 内容形态从长文叙述转向原子化信息块传统文章的逻辑是标题下写一大段读者自己提取重点。但生成式引擎抓取页面时需要的是能够直接摘取的“信息原子”——一个可以单独拎出来放进答案里的完整事实性块比如一段 50 字以内的门店特色总结、一张参数表、一个 FAQ 问题对。这也符合很多大模型训练和检索增强生成时的偏好召回单元越是自包含、越容易定位越容易被选中。我们在页面模板上做了明显调整每一篇核心文章开头会有一个“一句话摘要块”把最关键的信息直接说清楚正文里关键结论尽量用有序列表或表格承载而不是把结论包裹在又长又绕的从句里页面末尾补 3 到 5 个 FAQ每一个 FAQ 独立成块且可以直接被引用。注意 FAQ 不要为了凑数量而堆砌问法要和用户真实表达接近如果模型在答案里直接引用你的 FAQ 话术读起来不会违和。4.2 结构化数据和实体信号依然重要关于 JSON-LD很多说法是“AI 搜索不需要 schema 了”这个观点有点偏激。我们的观察是生成式引擎可能不会直接渲染 rich result但结构化数据会帮助模型或检索模块理解页面的语义边界。尤其是当页面包含商家信息时LocalBusiness、Restaurant 等类型的 JSON-LD 仍然有助于实体识别和属性抽取。关键是要把结构化数据写得干净、准确、和页面可见内容一致。不推荐的做法是给每个页面都堆一大堆 JSON-LD试图覆盖各种可能被搜索的类型因为一旦结构化数据里的内容和页面正文不一致模型会优先怀疑页面整体的权威性。我们内部的标准是“一页一主题、JSON-LD 与正文严格对齐”。比如一个门店页就只标记门店的真实属性不去顺带标注一堆附近景点的 Event 信息。实体信号的另一个作用在于跨页面协同当模型在两个不同页面上看到同一个实体 ID它会更容易把这些信息当作同一来源链路上的证据。4.3 分发渠道不止官网权威第三方信号同样重要做 GEO 时很多人只优化自己官网忽略了模型在总结信息时倾向引用“看起来更中立”的第三方信源。以本地生活为例生成引擎回答“附近有哪些值得去的店”时引用点评平台、地方新闻媒体、政府公共信息页、官方合作展示页的概率非常高。这意味着内容分发必须是多触点的你得确保在点评类平台、地图类应用、本地媒体等可被 AI 检索的平台上关于你品牌名称和核心店面的描述与官网保持同一信息口径。我们当时做过几次实验在监测模型里清一色提问同一个品牌的推荐词发现答案中引用的链接来源分布很有意思官网链接占比大概只有 20%-30%剩下大量来自第三方商户聚合页和用户评论摘录。所以内容分发的工作也不是“发完了事”而是要建立一套跨渠道的定期核对机制尤其是电话、地址、营业时间这些最容易被 AI 直接引用的信息一旦有变化必须保证官网和第三方渠道同时更新且第三方渠道的更新尽量排在用户量高峰前。4.4 发布速度要匹配模型更新节奏内容分发还有个时效问题值得展开。大模型训练和检索知识库的更新不是实时的你今天发一篇新品推荐指望明天所有 AI 引擎都能答出来不现实。但我们观察到Perplexity 这类偏实时检索的引擎对新鲜内容的感知周期很短有些高时效内容几小时内就能出现在回答引用里而另外一些模型的训练截止时间会让部分内容凭空消失很久。所以我们安排了一套“首发 复核”节奏对新上线的品牌活动和门店调整先在官网发布并提交 sitemap然后立刻在可控渠道里做一次小范围分发第二天开始放进多模型监测的问题集里观察。如果一周内没有任何一个模型感知到新内容就要去检查是页面结构问题、收录延迟还是分发渠道权重不够而不是干等着。可以老实讲这块没有一劳永逸的配置每个模型更新的时间窗都在变化只能靠常态化监测不断逼近。5. 多模型监测不要只盯着某一个 AI 搜索引擎5.1 监测指标怎么设计如果只问“我们的内容在 AI 回答里出现没有”这个观测太粗糙了。我们后来把监测指标拆成五个维度每个维度都有明确的业务含义可见度在固定问题集下该引擎回答是否覆盖了本品牌/本页面对应实体类似传统 SEO 的“是否有排名”。引用率回答末尾或行文中间是否出现了指向我们官网或可控渠道的链接这是最直接的流量来源。推荐态度引擎在回答里是正向推荐、中性提及还是把负面信息列在了前面。评价负向的时候必须及时危机处理。信息一致性模型说出来的营业时间、地址、服务项目和我们的“事实基线”一致吗。不一致会被当成错误信息直接影响品牌可信度。竞品对比位置如果用户问了比较型问题比如 A 和 B 哪个好我们是先被提到的还是被放进了“也可以看看”的角落。这是框架级的指标落到操作上要给每个指标定义清楚采集口径。比如“引用率”的分母是问题集中适合带链接引用的问题数不是所有问题数。如果你把 100 个问题都扔进去其中 60 个属于“直接答百科事实就行”的问题那引用率天然会很低误导后续归因。5.2 固定问题集和评估方法我们维护了一套约 800 个问题的固定测试集覆盖前面问题建模里划分的各个业务类型和高价值场景。固定问题集的意义在于纵向可对比同一问题每周跑一遍数据变化才解释得清楚。但也要小心 AI 模型输出的随机性同一个问题同一模型同一天可能给出不同回答。为了减小噪声我们在跑模型时尽量把采样参数调到低随机状态通过 API 测试时设置较低 temperature网页端测试时做不到就同题多跑几轮然后取多数结果。评估方式上早期全部靠人工读回答非常费时间后来引入了 LLM-as-judge。用一个大模型当裁判读取测试问题、参照我们提供的事实基线和品牌口径给回答是否引用、信息是否准确做打分。但这里必须设置人工抽检兜底因为裁判模型本身也可能误判。我们的经验是裁判模型负责粗筛和对齐的大部分工作每周人工审核 50 条高波动记录最终结果以人工确认为准。5.3 不同模型的表现差异比想象中更大多模型监测里最有价值的产出之一是整理出不同引擎的“脾气”。举几个典型例子有些国外主流引擎对页面的版权标注和作者信息很敏感引用时会优先选择清楚显示发布时间和来源的页面有些国内模型更偏好百科和官方小程序信息对独立站的长文直接引用反而谨慎还有部分引擎在回答本地生活问题时会非常刻意地把点评聚合结果放在官网前面因为用户评论的数量和新鲜度是它判断“值得去”的重要信号。这些差异意味着你不能用一套内容打天下也不是所有模型都值得投入一样的优化资源。我们梳理了一张模型对比表对每个模型记录它在引用官网页面的权重、对结构化数据的敏感度、对第三方评论的依赖程度以及信息刷新延迟大约是多少。这些记录不会精确到天但是能帮团队决定当资源有限时优先优化哪个模型对应的内容格式。6. 归因迭代让每一轮优化都比上一轮更准6.1 归因难在哪跑完多模型监测你会得到一堆涨涨跌跌的数据。接下来最尴尬的问题是这些变化到底是哪些改动带来的如果上周同时做了知识库字段修复、FAQ 新增、外部平台信息更新这三件事结果某问题的引用率涨了很难说是哪一步单独起了作用。归因的价值就是尽量把“黑盒反馈”拆解成可学习的经验否则下个季度还是靠感觉做事。我们当时吃过一个亏页面 A 的引用率上升团队很高兴地归功于刚上线的 FAQ 优化后来看数据回溯才发现其实是外部的一家行业媒体两周前发了一篇提及 A 品牌的文章让模型对这个页面的权威性判断变高了。如果只看官网侧动作这次归因就会完全归错方向。所以归因一定要带上“外部事件日志”把第三方内容发布、位置排名变化、店休公告、甚至天气等公共因素都标记出来。6.2 记录“内容-问题-模型-指标”四层关系为了让归因尽量可信我们给每一条监测记录建立了四层关系。第一层是内容层记录是哪一篇文章、哪一个字段、哪个 FAQ 发生了变动挂上版本号和上线日期。第二层是问题层记录这个改动主要是为了回答哪些问题对应问题池里的 ID。第三层是模型层明确哪些引擎出现了变化。第四层是指标层把可见度、引用率、推荐态度这些指标变化值落到具体数字上。这样一张明细表跑一段时间后就能做一些简单的对比分析了。例如筛选出“改了 FAQ 之后同一问题集里所有模型的引用率变化”如果一线模型普遍上涨而另一个模型没有那就去看后者的索引里是不是对这块内容有完全不同的读取路径。如果所有模型都没变化那就回头检查内容本身质量——是不是只改了一个自说自话的 FAQ没有解决用户真实顾虑。6.3 迭代节奏和组织分工闭环运转不能靠某一个人拍脑袋。内容团队负责根据问题池产出新内容和修复信息缺口数据团队负责跑监测、清理数据和出归因报告技术团队负责维护 sitemap、结构化数据和页面模板的迭代运营团队负责外部平台信息同步和问题池更新。每周一次 GEO 例会会议不是晒数据而是过“这周动了什么、哪些模型反馈变了、下一轮把资源投到哪里”。我们后来把迭代节奏固定为两个周期短线周迭代处理明显的错误和时效性问题长线月度复盘看结构性问题覆盖率和知识治理的基線变化。短线迭代动作小比如修一个字段、加一个 FAQ长线复盘用于决定是否新增内容专题、是否进入新的 AI 引擎监测范围。整个项目到后期最明显的改变不是某一个指标起飞而是团队对模型变化的响应速度越来越快错误信息在 AI 回答里存活的时间从以周计算缩短到一两天内。6.4 项目推进中容易忽略的一个隐性成本最后提醒一个容易忽略的隐性成本监测本身对问题池质量和知识基线的要求会持续增长。当你有几百个问题要检测每个问题至少涉及一个事实基线维护这个基线会占掉不少人力不亚于运营一个知识库。不要天真地以为数据处理全自动就没人管了模型经常会对旧答案做重新组织可能导致一段时间内信息一致性指标剧烈波动这时候没有人工介入去判断是模型问题还是知识库过期整个指标体系的参考价值就会下降。我们踩过几次坑之后现在更重视“问题池”和“知识基线”的同步更新机制每一次知识治理层面的新增、修改都会在问题池的对应问题状态中留痕并触发一次临时专项监测。这个动作让模型如果再次输出老版本错误信息我们能在第一时间发现而不是等到周报出来后才发现已经被错误挂了好几天。说实话这部分并不耀眼甚至有点繁琐但它恰恰是把标题里那个“闭环”真正转起来的粘合剂。