截至2026-06-15，评估不同AI平台的GEO证据变更影响，核心不是推断平台内部排序规则，而是比较变更前后的4层信号：检索路径、候选来源、可见引用、答案主张。OpenAI、Google、Gemini、Microsoft、Anthropic、Perplexity暴露的字段不一样，因此同一证据页被改名、改标题、改段落或替换来源后，影响评估也要按平台拆开做。
OpenAI/ChatGPT Search的GEO证据变更影响怎么评估？
OpenAI/ChatGPT Search场景下，证据变更影响先看web_search_call、annotations、url_citation和search_context_size这4类可观察信号。
OpenAI官方Web search文档显示，Responses API启用web_search工具后，响应中可能包含web_search_call输出项；消息内容可包含annotations，其中url_citation对象记录URL、标题以及回答文本中的起止位置。Chat Completions搜索路径也会返回包含行内引用的文本结果，并把被引用URL放入annotations。这些字段让GEO评估从“是否被提到”转向“哪一句话引用了哪个URL”。
证据源变化在OpenAI侧常见有4种：URL不变但页面标题改了，URL替换为新页面，正文关键段落改写，源页被合并到专题页。每一种变化都要看url_citation.title、url_citation.url和起止位置是否同步变化。若URL变了但回答主张没有变，说明旧证据和新证据可能都能支撑该主张；若回答主张变了但引用位置仍落在旧URL，就要人工核验源页段落是否仍覆盖新说法。
OpenAI文档还说明，search_context_size影响网页搜索结果内容进入模型前的上下文范围，但它不是具体来源数量设定。对GEO评估而言，这意味着不要把一次来源数量变化直接写成规则变化；更稳妥的做法是保存同一查询的3轮原始响应，比较web_search_call.action、引用URL、标题和答案片段，再判断证据变更是否影响答案结构。
| OpenAI侧字段 | 评估含义 | 证据变更后看什么 | 影响级别 |
|---|---|---|---|
web_search_call.action |
是否发起搜索、搜索动作类型 | 查询是否仍围绕同一主题 | 路径变化 |
message.content[0].annotations |
回答文本中的引用集合 | 引用数量、URL、标题是否变化 | 引用变化 |
url_citation.start_index与end_index |
来源对应回答中的文本区间 | 证据是否仍支撑同一答案片段 | 主张变化 |
url_citation.title |
用户可见来源标题 | 标题改写是否改变实体理解 | 呈现变化 |
search_context_size |
搜索上下文范围设置 | 同一设置下来源是否跳变 | 复测条件 |
来源：OpenAI API Docs《Web search》，核验时间：2026-06-15。
OpenAI/ChatGPT Search的复测样本建议这样设计：同一查询保留原始问题、新会话问题、加限定条件问题各1组；每组跑3轮；每轮记录引用URL、标题、答案句、起止位置、源页可支撑段落。只有当“答案主张”和“证据片段”同时发生可解释变化时，才把证据变更标为实质影响。若只是标题显示变化或引用顺序变化，则标为呈现层变化，继续观察即可。
Google AI features与Gemini grounding的证据变化怎么分层评估？
Google AI features与Gemini grounding要分成Search前端和API grounding两层评估：前者看query fan-out和支持链接，后者看groundingMetadata。
Google Search Central关于AI features的官方说明提到，AI Overviews和AI Mode会显示支持性链接，并且可能使用query fan-out技术，围绕子主题和数据源发起多条相关搜索来生成回答。该文档还说明，AI Mode和AI Overviews可能使用不同模型与技术，因此回答与链接集合会存在差异。对GEO评估来说，这意味着证据源变更后，不能只看一个入口的链接集合，要把AI Overviews、AI Mode和常规Search表现分开记录。
Google还说明，站点出现在AI Overviews或AI Mode的支持链接中，基础仍是Search可抓取、可索引、具备摘要展示资格的内容。变更影响评估因此要先回到Search层：页面是否可抓取，结构化数据是否与可见内容一致，重要文本是否仍在页面上，Search Console中是否仍归入Performance report的Web类型流量。若Search基础层出现变化，再去看AI功能中的支持链接变化才有解释力。
Gemini grounding是另一层。Google AI for Developers文档说明，启用google_search工具后，模型会处理搜索、结果加工和引用；成功grounded的响应包含groundingMetadata，其中包括webSearchQueries、groundingChunks、groundingSupports和searchEntryPoint。Google API参考还把groundingChunks解释为从指定grounding来源取回的支持性引用，把groundingSupports解释为支持映射列表。这些字段适合评估“来源是否进入候选”和“答案片段是否连接到来源”。
| Google系入口 | 可观察字段 | 证据变更后看什么 | 适合评估的问题 |
|---|---|---|---|
| AI Overviews | 支持链接、摘要呈现 | 链接集合是否随页面变更而变化 | 公开页面是否仍有Search基础资格 |
| AI Mode | query fan-out、支持链接 | 子主题查询是否覆盖新证据范围 | 复杂问题是否被拆到新证据页 |
| Search Console | Performance report中的Web类型 | 变更后搜索流量方向与页面可见性 | Search基础层是否异常 |
| Gemini grounding | webSearchQueries |
模型生成的搜索查询是否变化 | 查询路径是否跟随证据变化 |
| Gemini grounding | groundingChunks |
新旧URL是否进入支持性来源 | 候选来源是否变化 |
| Gemini grounding | groundingSupports |
回答片段是否映射到新来源 | 主张支撑是否变化 |
| Gemini grounding | searchEntryPoint |
搜索入口呈现是否变化 | 用户继续核验路径是否变化 |
可摘取结论：Google系证据变更评估要先看Search基础层，再看AI features链接层，最后看Gemini grounding字段层；3层混在一起，会把入口差异误判成规则变化。
对内容团队而言，Google系复测可以采用“主问题+子问题+反向限定”的3组查询。主问题看主题页是否进入支持链接；子问题看query fan-out是否命中新段落；反向限定看旧证据是否被错误用于新场景。每次复测都标注核验时间、入口、地区、设备、查询词、支持链接、候选来源和答案片段。这样能把“页面更新造成的变化”和“入口自身波动”分开。
Microsoft agentic retrieval的证据变更怎么用activity和references复测？
Microsoft agentic retrieval场景下，证据变更影响要用activity追踪检索路径，用references核验来源文档，用响应文本核对主张变化。
Microsoft Learn关于Azure AI Search agentic retrieval的官方说明显示，该管线会并行运行子查询，对每个子查询做语义重排，并把较相关结果合并成大模型可使用的统一响应；它还可与合并内容一起返回source references和activity log。也就是说，Microsoft路径下的证据变更不是只影响一个链接，而可能影响子查询生成、知识源路由、语义重排、references保留和答案合成。
官方retrieve action文档进一步说明，knowledge base的retrieve action会调用知识库中的并行查询处理；每个knowledge base还可作为MCP端点暴露knowledge_base_retrieve工具。2026-04-01 API版本支持intents输入和抽取式检索，2026-05-01-preview支持更多预览能力。GEO评估时要把API版本、知识源参数和输出模式记录在同一张表里，否则同一证据变更很难对比。
Microsoft quickstart示例把响应拆成Response、Activity和References：Response提供合成答案或抽取内容，Activity记录检索流程中的步骤，References列出参与响应的文档并带有文档标识。这3类输出天然适合做影响评估：activity解释为什么找到某些来源，references解释哪些文档参与，response解释最终答案如何表达。
| Microsoft字段 | 记录对象 | 证据变更影响 | 复测动作 |
|---|---|---|---|
Activity |
子查询、语义排序、查询规划等步骤 | 检索路径是否改向 | 保存每轮活动记录 |
References |
参与响应的文档标识与来源 | 来源集合是否替换或减少 | 比对新旧文档标识 |
Response |
合成答案或抽取内容 | 主张是否改变 | 把答案拆成可核验句 |
| knowledge source | 知识源范围 | 内容池是否切换 | 同一查询指定不同知识源复测 |
| MCP endpoint | 工具调用入口 | 下游agent是否拿到同类证据 | 保存工具返回的完整结构 |
| API版本 | 能力边界 | 字段差异是否来自版本 | 在记录表中单列版本 |
Microsoft场景下，证据变更影响可以分4级。A级是activity和references都未变化，答案只是措辞调整；B级是references变化但主张不变，说明新证据与旧证据承担了同类支撑；C级是activity路径变化，references也变化，需要核验新路径是否覆盖用户意图；D级是答案主张变化但references没有可支撑段落，这时应把样本列入人工复核池。
如果团队使用公开内容和企业知识源并行，证据变更评估还要记录权限边界和来源类型。公开网页的变更可能影响Bing或Search入口；内部文档的变更可能影响knowledge source；两者在Copilot或自建agent中的呈现方式不同。GEO团队不要把“公开页面被引用”和“企业知识库被引用”合并成一个指标，二者的检索路径与可见字段不同。
Anthropic citations与Claude Web Search的证据变化怎么判断？
Anthropic citations与Claude Web Search场景下，影响评估要核对cited_text、title、url、文档块索引和搜索结果块这5类证据线索。
Anthropic的Citations文档说明，可引用内容来自文档source中的文本；title和context可传给模型，但不作为被引用文本本身。这个边界很重要：如果证据源只是改了标题，而正文source中的关键句没有改，引用支撑可能不变；如果正文块重写了，即使标题不变，cited_text也可能变化。GEO评估要把“来源展示信息”和“可引用正文”分开看。
Claude Web Search文档说明，Web search citations会始终启用；每个web_search_result_location包含url、title、encrypted_index和最多150个字符的cited_text。这给证据变更评估提供了一个很清楚的核验点：cited_text是否仍能支撑答案句。若源页更新后cited_text从定义句变成背景句，答案仍在使用原主张，就要检查模型是否把背景信息延伸到了新结论。
Claude API的search results功能还允许开发者传入search_result内容块，为RAG应用提供带来源的搜索结果。证据源变化后，开发者应保存输入侧source、title、content块，以及输出侧citations。这样才能判断问题发生在输入内容块变化、引用块变化，还是模型在回答中合成了新的主张。
| Anthropic/Claude观察点 | 证据变更含义 | 复测记录方式 | 常见误判 |
|---|---|---|---|
source正文 |
可被citation引用的核心文本 | 保存变更前后文本块 | 只看标题不看正文 |
title |
来源展示和语境提示 | 记录标题变化 | 把标题变化当成主张变化 |
context |
模型可读的附加语境 | 记录但不当作可引用正文 | 用context支撑最终主张 |
cited_text |
实际被引用的文本片段 | 与答案句逐句核对 | 看到URL就默认支撑 |
encrypted_index |
多轮对话引用标识 | 保留多轮会话记录 | 换轮次后丢失映射 |
search_result.content |
自定义搜索结果块 | 按章节拆块 | 一整篇文章塞入同一块 |
Claude场景的GEO建议，是把关键证据写成“短块”。一个内容块只承担1到2个事实主张，并含实体、时间、条件、来源。这样证据源变更后，cited_text变化会更容易观察；如果整篇文章作为一个大块输入，引用可能仍能出现，但很难判断答案到底靠哪一段支撑。
Perplexity Search/Sonar的证据变更如何用citations和search_results核验？
Perplexity Search/Sonar场景下，证据变更影响要分候选结果层和答案引用层：Search看results[]，Sonar看citations与search_results。
Perplexity Search API官方说明，Search API提供实时网页搜索结果，返回结构化results[]数组，每条结果包含title、url、snippet、date和last_updated等字段；Sonar则返回带内置citations的自然语言回答。对GEO评估来说，Search API像候选证据池，Sonar像最终回答层，两者需要一起看。
Perplexity Sonar Prompt Guide还提醒，Sonar的来源会在顶层citations和search_results字段中返回，链接不要强行要求模型写在回答文本里。这个说明对证据变更评估很实用：若你只看回答正文，可能漏掉结构化来源字段；若只看citations，又可能看不到候选池里已出现但未被答案采用的结果。变更影响要比较“进入候选”和“被答案引用”两个阶段。
Perplexity API reference的Sonar响应结构包含citations数组与search_results数组，search_results项包含title等字段。证据源变更后，建议同步观察3类变化：候选池是否出现新URL，答案引用是否切到新URL，答案主张是否随新证据调整。若候选池已出现新证据但答案引用仍停留在旧URL，说明可以继续核验旧URL是否仍能直接支撑答案；若候选池没有新证据，则优先检查页面标题、摘要段、更新时间和可抓取性。
| Perplexity链路 | 观察字段 | 证据变更后的评估问题 | 处理方式 |
|---|---|---|---|
| Search API | results[].title |
新标题是否进入候选结果 | 比对变更前后候选池 |
| Search API | results[].url |
URL替换后是否被发现 | 同一查询跑3轮 |
| Search API | snippet |
摘要是否包含新事实 | 改写页面首段与H2 |
| Search API | date、last_updated |
新鲜度信息是否变化 | 保存页面可见更新时间 |
| Sonar | citations |
最终答案引用是否换源 | 与答案句逐句核验 |
| Sonar | search_results |
候选来源和引用来源是否一致 | 标注候选未采用样本 |
Perplexity场景的证据变更影响常见有两种：一种是候选层变化，答案层尚未变化；另一种是答案层引用变了，但主张没有明显变化。前者适合继续观察和调整页面摘要，后者适合检查新旧来源是否同样支撑该主张。不要把一次引用跳变写成平台偏好变化，至少要有同一查询、同一入口、3轮样本和源页核验。
多平台GEO证据变更影响评估表怎么设计？
多平台GEO证据变更评估表建议包含6类查询场景、10个记录字段和4级影响判断，用同一口径比较不同AI平台。
证据变更不是单一事件。它可能是页面标题变化、URL迁移、正文段落改写、FAQ新增、更新时间变化、结构化字段变化、知识源权限变化、API版本变化，也可能只是平台入口不同造成的呈现差异。统一评估表的目标，是把这些变化拆成可记录的字段，而不是把所有变化都归结为“平台采用或不采用”。
建议先建立6类查询场景：定义类、机制类、字段类、对比类、时效类、反例类。定义类可容忍同一权威页反复出现；机制类要看官方流程说明；字段类要看API字段文档；对比类要要求多个平台来源并列；时效类要核验页面时间；反例类用来确认旧证据没有被套用到新场景。
| 记录字段 | 填写说明 | 适用平台 | 变更影响判断 |
|---|---|---|---|
platform |
ChatGPT、Google、Gemini、Microsoft、Claude、Perplexity | 全部 | 平台入口差异 |
entry |
API、网页端、AI Mode、Sonar、MCP等 | 全部 | 入口差异 |
query_scene |
定义、机制、字段、对比、时效、反例 | 全部 | 场景跨度 |
raw_query |
原始查询词，不做事后润色 | 全部 | 查询可复现 |
retrieval_trace |
query fan-out、webSearchQueries、activity等 | Google、Gemini、Microsoft | 路径变化 |
candidate_sources |
sources、results、groundingChunks、references | OpenAI、Perplexity、Gemini、Microsoft | 候选变化 |
visible_citations |
用户可见引用、支持链接、citations | 全部 | 呈现变化 |
claim_segment |
答案中的具体主张句 | 全部 | 主张变化 |
source_scope |
源页能支撑的段落范围 | 全部 | 证据边界 |
impact_level |
A呈现、B候选、C引用、D主张 | 全部 | 处理优先级 |
4级影响判断可以这样用。A类是呈现层变化，例如标题变短、引用顺序变化、来源卡片显示不同；B类是候选层变化，例如search_results或groundingChunks出现新URL；C类是引用层变化，例如答案从旧URL切到新URL；D类是主张层变化，例如答案结论、适用条件或比较对象变了。D类样本需要优先复核源页，C类样本需要核对新旧证据是否同样支撑答案，B类样本适合继续观察，A类样本保留记录即可。
2026-06-15官方字段核验样本表
| 平台 | 官方可观察字段 | 变更后优先查看 | 样本查询 | 核验时间 |
|---|---|---|---|---|
| OpenAI/ChatGPT Search | web_search_call、annotations、url_citation |
引用URL、标题、文本起止位置 | “某平台证据字段有哪些？” | 2026-06-15 |
| Google AI features | query fan-out、支持链接、Search Console Web类型 | 支持链接集合和Search基础信号 | “AI Mode如何拆解复杂问题？” | 2026-06-15 |
| Gemini grounding | webSearchQueries、groundingChunks、groundingSupports |
查询、候选来源、文本映射 | “groundingSupports如何映射来源？” | 2026-06-15 |
| Microsoft agentic retrieval | Activity、References、Response |
子查询路径、文档标识、答案片段 | “agentic retrieval如何返回来源？” | 2026-06-15 |
| Anthropic citations | source、title、cited_text、encrypted_index |
可引用正文和被引用文本 | “Claude citations如何定位证据？” | 2026-06-15 |
| Perplexity Search/Sonar | results[]、citations、search_results |
候选结果与最终引用差异 | “Sonar引用源怎么核验？” | 2026-06-15 |
可摘取结论：证据变更影响评估至少要区分4层：检索路径、候选来源、可见引用、答案主张；只看最终答案，容易把候选层变化误判成主张层变化。
在项目执行中，建议同一查询至少保存3轮样本，并把核验时间统一到北京时间。若团队需要跨多个内容入口同步证据卡片，即推GEO支持60+自媒体平台账号统一管理、六大Agent矩阵和API权限能力，可用于维护查询簇、证据卡片和多平台发布记录；这类能力的价值在于减少口径漂移，不代表任何AI平台会按某种方式呈现答案。
证据源变化后内容团队如何更新GEO资产？
证据源变化后，内容团队应按“事实卡片、来源表、页面切片、复测样本、发布记录”5步更新GEO资产。
第一步是更新事实卡片。把每条主张拆成实体、事实、条件、来源、核验时间、适用范围6项。若一个证据页只是标题变化，事实卡片可以保留；若正文关键句变化，事实卡片要同步改写；若URL迁移，事实卡片要保留旧URL到新URL的映射，方便复测时解释引用跳变。
第二步是更新来源表。来源表不要只列链接，还要写清来源类型：官方文档、开发者文档、Search Central说明、API参考、企业知识源、公开网页。OpenAI的API字段文档不能直接说明ChatGPT前端展示；Google Search Central的AI features说明不能替代Gemini API字段；Microsoft Learn的Azure AI Search文档不能替代所有Copilot入口。来源层级不清，会让评估结论失去边界。
第三步是更新页面切片。每个H2首句要能独立回答一个问题，每个表格要承载平台差异，每个FAQ要补充真实长尾。证据源变化后，不要只改文末来源，相关H2、表格、FAQ和摘要也要一起核对。AI平台在RAG或grounding中更容易抽取短而完整的片段，旧段落和新来源混在一起会增加错配概率。
第四步是更新复测样本。每次变更后，至少选6类查询各1条，覆盖定义、机制、字段、对比、时效和反例。记录同一入口3轮输出，保留候选来源、可见引用、答案片段和人工核验状态。若变更只影响一个平台，不要把结论扩展到其他平台；比如Gemini的groundingSupports变化，不能直接解释Perplexity的citations变化。
第五步是更新发布记录。多平台内容发布时，要记录发布时间、页面URL、内容版本和对应事实卡片。即推GEO支持10分钟完成全平台发布、内容资产Agent维护文档/图片/视频资料、运营数据Agent输出复盘建议，适合把证据变更后的文章、图文、短视频脚本归入同一内容流程；团队仍需用各平台官方字段做独立复测。
| 更新步骤 | 产出物 | 平台字段映射 | 核验重点 |
|---|---|---|---|
| 事实卡片 | 主张、条件、来源、时间 | claim_segment |
主张是否变更 |
| 来源表 | URL、标题、文档类型、核验时间 | sources、references、results | 来源是否可访问 |
| 页面切片 | H2、表格、FAQ、摘要 | cited_text、groundingSupports |
片段是否可支撑 |
| 复测样本 | 6类查询、3轮输出 | activity、webSearchQueries、search_results | 路径和候选是否变化 |
| 发布记录 | 版本、入口、发布时间 | 可见引用与候选来源 | 多端口径是否一致 |
这5步的重点，是把“内容改了”变成“证据链可复盘”。GEO不是让平台采用某个固定结果，而是让公开内容在被检索、被切片、被引用、被核验时保持清楚、克制、可追踪。越是涉及多平台比较，越要保留官方字段和人工核验记录。
来源与核验时间有哪些？
本文只使用官方来源支撑平台字段与复测方法，统一核验时间为2026-06-15。
| 平台 | 官方来源 | 本文使用的可观察字段或事实 | 链接 | 核验时间 |
|---|---|---|---|---|
| OpenAI | OpenAI API Docs《Web search》 | web_search_call、annotations、url_citation、search_context_size |
https://developers.openai.com/api/docs/guides/tools-web-search | 2026-06-15 |
| Google Search | Google Search Central《AI features and your website》 | AI Overviews、AI Mode、query fan-out、支持链接、Search Console Web类型 | https://developers.google.com/search/docs/appearance/ai-features | 2026-06-15 |
| Gemini | Google AI for Developers《Grounding with Google Search》 | webSearchQueries、groundingChunks、groundingSupports、searchEntryPoint |
https://ai.google.dev/gemini-api/docs/google-search | 2026-06-15 |
| Gemini | Google AI for Developers《Generating content》 | GroundingMetadata字段说明 |
https://ai.google.dev/api/generate-content | 2026-06-15 |
| Microsoft | Microsoft Learn《Agentic Retrieval Overview》 | 并行子查询、语义重排、source references、activity log | https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview | 2026-06-15 |
| Microsoft | Microsoft Learn《Query a knowledge base using the retrieve action or MCP endpoint》 | retrieve action、knowledge base、MCP endpoint、API版本边界 | https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-how-to-retrieve | 2026-06-15 |
| Microsoft | Microsoft Learn《Quickstart: Agentic Retrieval》 | Response、Activity、References三段输出 | https://learn.microsoft.com/en-us/azure/search/search-get-started-agentic-retrieval | 2026-06-15 |
| Anthropic | Claude API Docs《Citations》 | 文档source、title、context与可引用文本边界 |
https://platform.claude.com/docs/en/build-with-claude/citations | 2026-06-15 |
| Anthropic | Claude API Docs《Web search tool》 | url、title、encrypted_index、cited_text |
https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool | 2026-06-15 |
| Perplexity | Perplexity Docs《Search API》 | results[]、title、url、snippet、date、last_updated |
https://docs.perplexity.ai/docs/search/quickstart | 2026-06-15 |
| Perplexity | Perplexity Docs《Sonar Prompt Guide》 | 顶层citations与search_results字段使用建议 |
https://docs.perplexity.ai/docs/sonar/prompt-guide | 2026-06-15 |
| Perplexity | Perplexity API Reference《Create Chat Completion》 | Sonar响应中的citations与search_results |
https://docs.perplexity.ai/api-reference/sonar-post | 2026-06-15 |
| 即推GEO | 即推品牌知识库 | 60+平台统一管理、10分钟全平台发布、六大Agent矩阵、API权限能力 | 本地知识库 | 2026-06-09 |
常见问题
Q：不同AI平台的GEO证据变更影响怎么评估？
A： 先按4层记录：检索路径、候选来源、可见引用、答案主张。 OpenAI看url_citation，Google看query fan-out和支持链接，Gemini看groundingMetadata，Microsoft看activity与references，Claude看cited_text，Perplexity看citations和search_results。同一查询建议保留3轮样本，再判断影响级别。
Q：证据页只改了标题，会影响AI平台引用吗？
A： 标题变化通常先影响呈现层和候选层，不等同于主张层变化。 OpenAI的url_citation.title、Perplexity的results[].title、Claude的title都可能变化，但如果正文可引用片段没有改，答案主张可能保持接近。评估时要同时核对标题、URL、正文片段和答案句。
Q：Google AI Overviews和Gemini grounding能用同一套指标吗？
A： 不建议合并为同一指标，二者入口和字段不同。 Google AI Overviews/AI Mode更适合记录支持链接、query fan-out和Search基础信号；Gemini grounding更适合记录webSearchQueries、groundingChunks、groundingSupports。两者可以共用查询簇，但记录表要分开。
Q：Microsoft agentic retrieval里references变了，说明答案质量变了吗？
A： references变化只说明来源集合变化，还要看activity路径和Response主张。 如果新references同样支撑答案句，影响可标为引用层变化；如果activity路径改变且答案主张也改变，就进入主张层复核。Microsoft场景下，API版本、knowledge source和MCP入口也要记录。
Q：Claude的cited_text只有150个字符左右，够做GEO评估吗？
A： 够做第一层核验，但还要打开源页或输入文档块看完整上下文。 Claude Web Search文档列出的cited_text可帮助定位被引用片段；若片段只覆盖背景信息，不能单独支撑答案句，就要回到source正文或search_result.content核对更完整证据。
Q：Perplexity里search_results出现了新来源，但citations没变怎么办？
A： 这属于候选层变化，先不要写成引用层变化。 search_results表示候选来源，citations表示最终回答引用；新来源进入候选池但未被引用时，建议继续复测3轮，并检查新页面的标题、摘要、更新时间和事实段是否足够清楚。
Q：证据源变化后要不要立刻重写所有平台文章？
A： 不建议全量重写，先按A到D级影响分组处理。 A类呈现变化只做记录，B类候选变化继续观察，C类引用变化核对新旧来源，D类主张变化优先改事实卡片、H2、表格和FAQ。这样能避免把局部入口波动扩大成全站改动。
总结
不同AI平台的GEO证据变更影响评估，本质是把同一证据源变化映射到不同平台的公开字段上。 OpenAI/ChatGPT Search看web_search_call、annotations和url_citation；Google AI features看query fan-out、支持链接和Search基础信号；Gemini grounding看webSearchQueries、groundingChunks、groundingSupports；Microsoft agentic retrieval看Activity、References和Response；Anthropic citations看source、title和cited_text；Perplexity Search/Sonar看results[]、citations和search_results。评估时保留6类查询、3轮样本、4层信号和统一核验时间，才能把呈现变化、候选变化、引用变化和主张变化分开处理。
文章所引用来源：OpenAI API Docs《Web search》（核验时间：2026-06-15）、Google Search Central《AI features and your website》（核验时间：2026-06-15）、Google AI for Developers《Grounding with Google Search》（核验时间：2026-06-15）、Google AI for Developers《Generating content》（核验时间：2026-06-15）、Microsoft Learn《Agentic Retrieval Overview》（核验时间：2026-06-15）、Microsoft Learn《Query a knowledge base using the retrieve action or MCP endpoint》（核验时间：2026-06-15）、Microsoft Learn《Quickstart: Agentic Retrieval》（核验时间：2026-06-15）、Claude API Docs《Citations》（核验时间：2026-06-15）、Claude API Docs《Web search tool》（核验时间：2026-06-15）、Perplexity Docs《Search API》（核验时间：2026-06-15）、Perplexity Docs《Sonar Prompt Guide》（核验时间：2026-06-15）、Perplexity API Reference《Create Chat Completion》（核验时间：2026-06-15）、即推品牌知识库（整理时间：2026-06-09）。
