Schema结构化数据怎么做才好？@graph与知识图谱完整指南20步

写过Schema但富结果一直不出，十有八九问题不在格式，而在还停留在“一块JSON-LD一个Type拼上去”这个阶段。Google现在按整站实体网读你的结构化数据：谁该是哪个实体、谁挂在谁身上、Knowledge Panel要看的Organization与Person主体一致性，单一Type一块块写很难传得清楚。这篇把高级编排拆开——@graph容器为什么必要、六个核心节点怎么互相引用、Knowledge Panel与富结果是两条命运、富结果不出的五大类机理、JSON-LD为何一家独大、AI检索把Schema的价值彻底重估了哪部分。配复合Type编排清单、三格式取舍决策表、Validation三层流程图。读完你会重新画自己的Schema架构。

大家好，我是保哥。前两天有位做SaaS的同行问我：“我们每个文章页都打了BlogPosting的Schema，必填字段全有，Rich Results Test也是绿的，为什么Google搜索结果里就是不出富结果？”我让他把站点架构发我看一眼，五分钟就找到症结——他在20个页面上写了20份各自独立的Schema，author字段每一份都填了同一个人，但author从来没作为一个独立Person节点被定义，每份Schema里的author都只是一个嵌套的字符串“张某某”。Google在他站点上看到了20个名叫张某某的人，没法把它们认成同一个实体，整站的E-E-A-T信号像撒了一地的碎片。

这是Schema编排从入门到能用的分水岭。入门阶段会照着seo-schema-guide把单一Type的字段填齐就发布，看到Rich Results Test绿灯就觉得活做完了；真正起作用的Schema必须是整站层面一致的实体网，每个核心实体只声明一次，所有页面都通过@id去引用。我在结构化数据是什么？Schema标记SEO实施与避坑全指南那篇里讲过入门怎么把字段填对、避哪些常见雷，这一篇把它没展开的高级部分——@graph容器机制、Knowledge Panel触发条件、复合Type编排、AI检索时代价值重估——一次说清。如果你Schema写过两年还在原地踏步，问题大概率在这。

为什么写满字段还是拿不到富结果？

这个问题我每年要被问几十次。大多数情况下提问者已经做过非常细致的字段功课，Rich Results Test的截图里所有required和recommended都打勾了，但Google搜索结果里那个带星星、价格、问答框的展示就是不出。回答之前我得先泼一盆冷水：Schema写对≠拿富结果。从写对到展示富结果之间，至少要过五道闸。

富结果不是格式胜利，是Google的展示决策

保哥在咨询里反复纠正过这个误解：富结果的逻辑被想成“格式正确→展示出来”是错的。富结果是Google针对每一次搜索每一个页面单独决策的展示样式，决策时不只看你的Schema，还要看你站点的整体质量信号、用户在这个查询下需要什么、其他候选页面的Schema有没有更全。也就是说，同一个页面在不同查询下会有不同的富结果展示概率，甚至同一个查询不同地区不同时间结果都会变。这是为什么有些站点Schema天天报告“一切正常”，搜索结果里却时有时无。

资格、字段、质量、政策、信任五道闸都要过

下面这张表是保哥在几个SaaS和DTC站点上反复验证过的诊断框架。任何一道闸没过都会导致富结果不展示，但报告往往只告诉你“有效”，让人误判。诊断时按顺序自查最省时间：

• 先看Schema类型本身在Google官方支持列表里是否还有富结果资格，FAQPage和HowTo桌面端已经退场。
• 再用Rich Results Test跑一遍必填字段与值合法性，常见坑是priceCurrency和datePublished的格式。
• 第三步对照正文，看Schema声明的事实（评分、价格、步骤）是否在可见内容里有据可查。
• 第四步检查有没有政策红线：评分作假、隐藏内容、Schema与可见内容矛盾，任何一条都会失资格。
• 最后看站点信任度：新站、HCU受影响站、低权重子域的展示配额本来就低，别把信任问题当成Schema问题去返工。

这张表里最容易被忽视的是质量闸和信任闸。Search Console里只要Schema语法合法、必填字段齐就标“有效”，但展示与否还要再过质量与信任两关，Google从不会在报告里告诉你“你的站不够格”。

Search Console报告读法的真相

“增强”报告里那个绿色的“有效”项数字，只代表“Google解析过你的Schema、字段语法没问题”，跟实际富结果展示次数没有任何对应关系。要看真实展示，得去搜索结果页报告（performance）里把外观维度（search appearance）开出来，按富结果类型分别看曝光。我服务过的一个北美宠物用品DTC站，增强报告里Product Schema “有效”2万多条，性能报告里富结果曝光只有约3千次的样本——91%的“有效”根本没拿到展示位。这不是异常，是常态。

@graph到底解决了什么？

开篇那位SaaS同行的问题就出在这一节要解释的概念上。把同一个实体（一个Person、一个Organization、一个WebSite）拆成20份分别嵌进20个BlogPosting里，对Google来说不是“写了20次的同一个张某某”，而是“可能有20个不同的张某某”。@graph容器存在的意义就是给Google一个明确指针，让它知道哪些实体声明指的是同一个东西。

多块JSON-LD的隐藏分裂

JSON-LD规范允许一个页面里写多块独立的script，Google官方文档也说“多块和@graph一种容器，效果上是等价的”。但等价是从语法层面，不是从实体识别层面。多块独立写时，Google需要自己根据字段值（name、url、sameAs等）去推断哪些声明指向同一实体；声明越多、字段越接近，推断成本越高、出错概率越大。@graph相当于把这个推断成本由你显式声明清楚，让Google少做猜测。

我见过一个北美户外装备DTC站，每个产品页都单独写了Organization+WebSite+Product+BreadcrumbList四块JSON-LD，Organization里name都是“某某Outdoors”，url都是同一个域名。Google在它的Knowledge Graph里把这家公司分裂识别成至少三个不同的Organization实体，Knowledge Panel卡了一年多上不来。我们做的事情很简单：用@graph把Organization节点提到全站只声明一次，给它一个稳定的@id“https://example.com/#organization”，所有页面通过references挂这个id。两个月后Knowledge Panel出现，又过了一个月品牌词搜索时右侧实体卡完整加载。

@id作为节点指针的水流模型

把整站的Schema理解成一张实体关系图最直观。@id是节点的稳定地址，类似数据库里的主键；任何引用都通过@id指向，类似外键。设计原则只有一条：同一个真实世界实体在全站只声明一次，其他地方一律用@id引用。

下面是一个简化的站点级实体图，结构上能套绝大多数中等规模站点：

注意所有@id都是绝对URL，且建议带#锚点后缀做语义区分。这不是Schema强制要求，但能避免你之后改路径时引用关系全断。

站点实体网示意

实体网搭好之后，Google抓取每个页面都会增量更新它对你站点的内部知识图谱。如果你不太确认搜索引擎抓取、索引、排名这三步内部到底各干了什么，可以先把那篇看完再回头读这一节，机制层会非常清楚。新文章发布时不需要重新声明Organization和WebSite，只声明文章本身的BlogPosting节点+引用即可。这种增量更新让站点级的实体一致性变得稳定可维护——你不会因为某个开发者改了某页的Schema字段，导致Organization识别出现裂痕。

六个核心节点怎么互相挂引用？

下面六个节点构成绝大多数站点的Schema地基。这一节给具体怎么写，每个节点的关键字段、容易踩的坑、对应实体识别贡献。

Organization节点：sameAs与logo是Knowledge Panel地基

Organization是品牌实体的根。要让Google把你的站点和现实里的公司挂上钩，必须显式告诉它“这家公司在哪里还有别的官方身份”，这就是sameAs字段的作用。我服务过的一个北美咖啡器具DTC品牌，Knowledge Panel卡了八个月，根因是Organization的sameAs只挂了Facebook主页，没挂Twitter/X、Instagram、LinkedIn、YouTube、Wikidata。补全sameAs（一定要是官方账号，不是品牌词搜索结果）+把logo字段从相对路径改成绝对URL之后，约六周后Knowledge Panel上线。logo必须是PNG或SVG、宽至少112像素、背景透明或单色，太多人把站点头部那张带阴影的JPG直接当logo用，Google根本不会采纳。

WebSite节点：Sitelinks Search Box触发条件

WebSite节点不只是装饰，它的potentialAction字段定义了你的站内搜索URL模板，这是触发SERP里搜索框（Sitelinks Search Box）的唯一信号源。模板里的{search_term_string}占位符必须精确匹配你的搜索结果页URL格式，模板里写https://example.com/search?q={search_term_string}就要确保站内搜索真的走这个URL。Google现在对搜索框的展示越来越保守，但配置错了一定不出，配置对了仍然按品牌权重和点击信号决定展不展示。

WebPage节点：mainEntityOfPage指针

WebPage和BlogPosting之间靠mainEntityOfPage和isPartOf相互引用：BlogPosting.mainEntityOfPage指向当前页的WebPage@id，WebPage.isPartOf指向WebSite@id。很多人嫌麻烦只写BlogPosting不写WebPage，技术上Google能解析，但失去了一个明确的“当前文章在哪个页面”的语义层，Breadcrumb和WebPage之间的关系也建不起来。规模站推荐每页WebPage+主实体节点（BlogPosting/Article/Product/Recipe等）配套写。

BlogPosting与Article节点：author与publisher嵌套是E-E-A-T载体

BlogPosting的author字段不要直接写字符串名字，要引用Person节点的@id。publisher字段引用Organization@id。这两个嵌套引用是Google判断E-E-A-T的核心结构信号——文章是谁写的、属于哪个组织发布，Schema里如果只是字符串“张某某”和“某某科技”，搜索算法很难把它们和实体网里的真实Person与Organization对上号。这是HCU之后Schema对E-E-A-T最强的杠杆，比正文里随便挂几行作者介绍要硬得多。

BreadcrumbList节点：itemListElement的索引坑

BreadcrumbList几乎是所有站点都写的，但写错率惊人。我数过我服务过的最近十个站，七个都在position字段上踩过坑——position必须从1开始计数、连续、整数；很多人从0开始或者跳号。第二个常见坑是item字段：item应该是被引用节点的@id或完整URL对象，很多人直接写一个字符串URL或者干脆缺item。第三个坑是面包屑里最后一项（当前页）有些指南说不该带URL，但Google明确说带URL不算错且推荐带。

Person节点：作者E-E-A-T信号的载体

Person节点是HCU时代最被低估的Schema节点。把每位作者建一个独立的作者归档页，页面上挂Person Schema，字段填齐name、jobTitle、worksFor（引用Organization@id）、sameAs（作者在LinkedIn/X/学术档案/媒体专栏上的官方身份）、description（一段真实的从业履历，不是营销文案）、url（作者归档页本身的URL）、image（真人头像，非默认头像）。这是Schema里少数能直接让Google把E-E-A-T信号挂到具体人身上的结构。我服务过的一个北美宠物保健DTC站，没做这件事之前YMYL类内容长期被压，给所有作者都挂了完整Person节点+作者归档页之后，约四个月内核心评测类页面的曝光提升了近三成，HCU影响也减轻。Person节点的价值在Schema里被严重低估，多数指南只字未提。

富结果为什么会失败？

这一节给五类失败的具体机理。我把它们按出现频率从高到低排，看完你能自己判断手头那个不出富结果的页面卡在哪一层。

类型本身没有富结果资格

这是被问得最多的一类，特别是FAQPage和HowTo。Google在2023年8月把FAQPage的桌面富结果几乎全部下线、把HowTo桌面端完全取消，2024年继续收缩。这两类Schema今天写进去Rich Results Test能验证通过、Search Console报告里也显示“有效”，但桌面搜索结果里就是看不到展示。不是你的Schema错，是Google主动把这个展示位关了。

把FAQPage Schema继续写有没有意义？我现在的建议是：写，但理由变了。富结果时代写FAQPage是为了拿那个折叠展示位换点击；现在写它是为了让ChatGPT、Perplexity、Google AI Overviews更容易抽取你的问答段落作为可引用事实块，附带回链到你的页面。FAQPage Schema今天的回报落在AI引用上，不在SERP星条上。

必填字段缺失或字段值不合法

这一类Rich Results Test会直接报错，相对好诊断。常见坑：Product的price字段必须带priceCurrency；aggregateRating必须同时有ratingValue和reviewCount且reviewCount>0；Recipe的cookTime必须用ISO 8601时长格式（PT30M而不是“30分钟”）；Article的datePublished必须是ISO 8601带时区的完整时间戳。遇到Rich Results Test报错先别急着改Schema，先看是不是你CMS自动注入的字段被覆盖或重复声明——WordPress装了三个SEO插件常见的就是三套Schema互相冲突。

内容质量门槛未过

这一关最隐性。Google会读你正文，看正文内容是否真的支持你Schema里声明的东西。一个常见的反例：Schema里写了aggregateRating 4.8/52条评论，正文里却找不到任何评论展示——Google会判断评分声明无支撑，富结果不展示且可能触发政策标记。另一个反例：Recipe Schema里写了step-by-step的recipeInstructions，但正文实际只有一段连续叙述、没有步骤分隔——Google抓不到对应的可视化锚点，也不会展示富结果。Schema必须是正文的结构化抽取，不能是空中楼阁的额外声明。

政策违规与作弊

Schema政策红线：评分作假、价格虚假、隐藏内容（Schema里有但正文里没有）、与可见内容矛盾、商家虚假宣传。任何一条都会触发对应页面失去结构化数据资格，严重的会触发手动操作（Manual Action）影响整站。恢复要等你修复后提交reconsideration、等Google重新审核，少则两周多则半年。我见过一个客户图省事把全站每个文章都Schema塞个5星好评，三个月后整个域名的Article富结果资格被吊销，恢复周期八个月。

站点信任不足或抽样配额限制

这一关报告里完全不会告诉你。Google对每个域名有一个隐形的富结果展示配额，配额受站点信任度、HCU影响、新站资历影响。我服务过的一个2024年新上线的B2B SaaS站，所有Schema完美无瑕，富结果三个月才陆续开始展示，初期展示比例不到5%；半年后慢慢爬到约30%，一年后才进入正常区间。新站和HCU受影响站要做好心理预期，Schema做对了也不意味着马上有富结果，富结果展示与否对应着站点级信任的反映。

Knowledge Panel和富结果是同一回事吗？

不是，而且差别比大多数人以为的大得多。这一节专门把这两个概念分开。

两条独立流水线的根本差异

Knowledge Panel触发的真实信号

Knowledge Panel能不能出，主要看Google能否在它的Knowledge Graph里把你的品牌识别为一个独立实体并积累足够多的关联信号。这些信号包括：Wikidata是否有对应条目、Wikipedia是否有页面、官方网站Organization Schema是否一致、各大社交平台官方账号通过sameAs是否打通、行业目录/媒体提及里的品牌名一致性。Schema只是其中一个信号，且是“必要非充分”——没有Schema基本不可能拿到Knowledge Panel，有了Schema也不保证一定拿到。

sameAs与identifier是Entity锚定的关键

Organization节点里的sameAs字段是连接你的站点和外部实体身份的桥梁。Google会沿着sameAs去验证：你声明的是这家公司，那这家公司的LinkedIn页面、Wikipedia条目、行业目录页是不是都指回同一个实体？验证通过，实体识别加固；验证失败或缺失，实体在Google Knowledge Graph里就是孤岛。identifier字段（如果有DUNS号、税号、行业注册号）能进一步加固。Knowledge Panel不是一夜之间出现，是这些信号长时间一致积累的结果。

复合Type和多@type是怎么回事？

到这一节假设你已经掌握了单一Type的写法。Schema.org允许一个节点同时声明多个@type，也允许通过嵌套把多个Type的字段拼成复合声明。这是高级编排里出现频率最高的一组场景。

Product+Offer+Review的三件套

电商产品页几乎都是这套：Product声明主体，Offer声明定价与可购状态，Review/AggregateRating声明评价。三者必须互相嵌套或通过@id引用，缺一不可。我反复见到的踩坑：Offer没写availability，导致购物搜索结果里完全不展示库存状态；priceValidUntil缺失或过期，Google会主动停止展示价格；AggregateRating的reviewCount写成0或1，Google就当不存在。电商产品页Schema做对最大的回报是Merchant Center里的商品自动同步、Shopping富结果展示、Product Reviews的星评展示，三者都直接影响转化率。

Article加VideoObject的多媒体复合

带视频的文章页推荐写Article+VideoObject双节点。VideoObject里的thumbnailUrl、uploadDate、duration、contentUrl、embedUrl字段如果填齐，能让Google视频搜索结果里出展示卡，YouTube嵌入的视频Article页里也能拿到视频富结果。很多带视频的文章只写了Article却没写VideoObject，相当于把视频这一信号完全放弃。

LocalBusiness与多个@type并列

本地业务的Schema最复杂。一家咖啡店可能同时是LocalBusiness、CafeOrCoffeeShop、Restaurant，Schema.org允许在@type字段里直接写数组["LocalBusiness", "CafeOrCoffeeShop"]同时声明。Google对多@type的支持较好，但建议优先用最具体的子类（CafeOrCoffeeShop），实在不确定再用父类LocalBusiness，避免Google在内部分类时混乱。

复合Type的Validation坑

Schema Markup Validator对多@type和深嵌套支持完整，但Google Rich Results Test对超过两层嵌套或多Type并列声明有时会报“无法识别”——这不代表Google抓取时也不识别，是Rich Results Test工具本身的覆盖范围有限。双工具交叉验证：Validator看语法、Rich Results Test看富结果资格，两者结果不一致时以Validator+Search Console增强报告为准。

三种格式到底选哪个？

Schema.org原始规范支持JSON-LD、Microdata、RDFa三种序列化格式，Google官方都支持。但三者今天的地位差别很大。

JSON-LD、Microdata、RDFa取舍对照

结论清晰：新项目一律JSON-LD，老系统留着Microdata能跑就别动。这不是教条，是过去五年大量站点验证过的事实。

同页混用的优先级

如果一个页面上同时有JSON-LD和Microdata声明同一个实体，Google会怎么处理？官方说法是“都解析、按字段合并”，但实际抓取里JSON-LD优先级更高。不要混用——混用会让你后续诊断变得极其困难，字段冲突时根本不知道Google用了哪一份。要么纯JSON-LD要么纯Microdata，选一个就贯彻到底。

老系统迁移到JSON-LD的五步

这是我帮过几个老电商站做过的迁移路径：第一步，全站爬取，把所有Microdata/RDFa声明导出到一份清单，按页面类型分组；第二步，按页面类型设计JSON-LD模板，每类一个；第三步，在staging环境部署JSON-LD模板，保留原有Microdata；第四步，等GSC增强报告里JSON-LD类型也开始计数（通常一到两周），确认双重声明都被识别；第五步，灰度逐批删除Microdata。千万不要一夜之间替换，原Microdata富结果停掉而新JSON-LD还没被Google索引，中间会有几天富结果缺失窗口。

怎么验证Schema没写错？

这一节给三层验证流程。任何Schema上线前都要走完。

schema.org Validator：纯语法层

schema.org官方的Markup Validator只检查Schema语法本身——类型存在不存在、字段名拼写有没有错、值类型对不对。它不知道Google的富结果资格规则，所以Validator通过≠富结果能出，但Validator不通过几乎肯定富结果出不来。这是第一道闸。

Google Rich Results Test：富结果资格层

Rich Results Test覆盖的是Google目前公开支持富结果的Schema类型子集，会告诉你“这个页面有资格拿哪些富结果展示”。注意它返回的“有效”只是资格层确认，不保证一定展示（还要过质量/政策/信任三关）。这道闸通过是必要非充分。

Schema Markup Validator：兼容性深度层

Schema Markup Validator是schema.org社区维护的更深度工具，对@graph、复合Type、多节点嵌套的支持比Rich Results Test更完整。当你写复杂编排Rich Results Test报“无法识别”但你怀疑是工具问题时，用SMV交叉验证。

Search Console增强报告：上线后真实表现

三个工具都过了，上线后还要看GSC增强报告里类型计数有没有正常涨。一般部署后24-72小时内Google会开始增量识别，一周内基本稳定。如果一周后增强报告里相应类型仍为0，要回头检查sitemap是否包含这些页面、robots.txt是否屏蔽了爬取、是否页面rendering出了问题（JS生成Schema但渲染失败）。

三层验证流程对照表

AI检索时代Schema价值重新评估了什么？

过去两年Schema的价值结构发生了根本变化。富结果星标在SERP里的总展示量下降——FAQPage桌面下线、Product Reviews频繁更新缩减展示、Discover富结果收紧；同时AI检索（ChatGPT、Perplexity、Google AI Overviews、ChatGPT Search、Claude检索）的增长改写了Schema的回报路径。

SERP星标价值的衰退路径

2019-2022是富结果的黄金期，特别是FAQPage展开折叠展示能把单条SERP位的可视面积扩到原来三倍以上。2023年8月Google宣布FAQPage桌面端展示对“authoritative health and government sites”之外的所有站点关闭，HowTo桌面完全下线；2024年继续收缩Product Reviews、Article富结果展示。SERP总体在变干净、变保守、AI Overviews占用更多顶部空间，留给富结果的版位越来越少。纯为了富结果展示去写Schema，回报率在快速下降。

模型抽取概率信号

但Schema并没有失去价值，它的作用迁移到了AI检索抽取上。ChatGPT和Perplexity在生成答案时，对结构化数据的偏好相当明显——FAQ Schema里的Q&A、HowTo里的steps、Recipe里的ingredients和instructions，这些都是模型可以直接抽取成事实块、附带回链来源的内容。同样的内容，写在裸HTML里和包在Schema里，被AI抽取概率有显著差异。我做过一个跟踪：某北美保健品DTC站把所有评测文章的FAQ段都加上FAQPage Schema之后，三个月内ChatGPT和Perplexity在相关查询里引用它的频率提升了约2.5倍。Schema今天的回报落在AI引用上，不在SERP星条上。

Entity一致性比格式正确更重要

AI检索时代Google把更多权重放在Entity层面——你这家公司是谁、这位作者是谁、这个产品在你的实体网里是怎么定位的。这一波趋势的来路其实在从蜂鸟到BERT再到MUM那段搜索语义理解演变史里就埋下了，搜索引擎读你的页面早已不再是匹配关键词，是构建实体之间的关系。Schema作为Entity信号的载体，整站实体一致性比单页字段完美更重要。一个Organization节点贯穿全站、Person节点挂作者归档页、sameAs挂全官方账号，这套Entity地基对AI检索把你识别成“可信信息源”的影响远超单页Schema的字段细节。如果你想从更抽象的方法论层看Entity SEO怎么搭，2025实体SEO的AEEBM五阶段那篇是配套读物，本文是Schema结构层落地，那篇是方法论上层。

AI Overviews、Perplexity、ChatGPT怎么抽取Schema

三家具体行为有差异。Google AI Overviews明显偏向有Schema结构的内容，特别是HowTo、Recipe、FAQPage这类高结构化Type，抽取出来的步骤清单和问答块在生成的答案里直接可见。Perplexity偏向有清晰段落标题、blockquote结论先行的内容，对Schema的依赖弱于Google但Schema仍是加分项。ChatGPT在SearchGPT和Pro模式下抓取页面时，对结构化数据有明显偏好，FAQPage Schema是最容易被引用的格式之一。三家共同的偏好：结构化的事实块（FAQ、HowTo、Recipe）比纯叙述更容易被引用。

北美保健品DTC从富结果零展示到Knowledge Panel上线的过程

这是我服务时间最长的一个DTC客户的Schema改造复盘，因为时间线足够长（约14个月），各项信号变化看得清。客户类型是北美保健品DTC，营养补剂为主，月营收七位数美元，独立站架构在Shopify+自研评论模块上。

初始状态：每个产品页都有Product+Offer+AggregateRating的基础Schema，每个文章页有BlogPosting Schema，所有Schema都是Shopify默认模板自动生成。Rich Results Test全绿。但富结果展示率不到10%，品牌词搜索没有Knowledge Panel，竞品（更老牌的同类品牌）已经有完整Knowledge Panel至少三年。

第一阶段做的事情：用@graph重写所有页面Schema，Organization+WebSite节点提到全站统一@id声明，sameAs补全（Twitter/Instagram/LinkedIn/YouTube/TikTok/Wikidata申请条目），logo从带阴影JPG换成透明背景PNG。Person节点为三位主要作者建独立作者归档页+完整Person Schema，sameAs挂作者的LinkedIn和Twitter。这一阶段用了大约三周完成全站改造。两个月后Knowledge Panel首次出现，但还不完整。

第二阶段：补Schema与正文的一致性，凡是Schema声明了aggregateRating的Product页，正文必须显式展示评论列表+评分汇总；凡是FAQPage声明的页面，正文里也要有可见的Q&A段（不能只在JSON-LD里有）；Wikidata条目获批后把Q编号填进Organization.identifier和Person.identifier。这一阶段用了大约一个月。三个月后Knowledge Panel完整加载，含logo、社交链接、相关查询。

第三阶段：监测与AI引用追踪。从第八个月开始系统化追踪ChatGPT、Perplexity、Google AI Overviews对客户站的引用情况。14个月时，AI引用次数比改造前提升约4倍，主要增长来自评测类文章的FAQ Schema段被抽取。这是个时间线很长但每一步都能验证的过程，没有奇迹也没有快速通道。

保哥拿这个案例做复盘最想说的不是结果数字，是改造逻辑的迁移：从“字段填齐拿富结果”转到“Entity一致性+AI抽取友好性”。这套逻辑对今天准备认真做Schema的站点都适用。

常见问题解答

我每个页面都打了Schema，为什么富结果还是不出？

Schema打过≠拿富结果。Google还要过资格、字段、质量、政策、信任五道闸；任一关没过都不展示。控制台报告里的“已识别”只算第一步。

@graph和单独写多块JSON-LD有什么区别？

两种Google都吃，但@graph能用@id把多个节点显式挂引用，站点级实体关系传得清；多块分写易让搜索引擎把同一组织或人物看成不同实体，弱化主体识别。规模站推荐@graph。

Knowledge Panel和富结果是同一回事吗？

不是。富结果按页面级判定，是SERP里那条增强样式；Knowledge Panel按品牌或人物实体级判定，是右侧实体卡。Schema对前者直接控制，对后者只是必要非充分信号。

Microdata和RDFa还要不要写？

Google三种格式都支持但JSON-LD维护成本最低、和DOM解耦、不影响渲染，已成事实标准。新项目直接JSON-LD；老系统留着Microdata能跑就别动，别为统一格式重写。

Schema写错会被Google惩罚吗？

结构性错误只不展示富结果不拖排名；但内容欺骗（评分价格优惠与正文不一致）算政策违规，对应页失去结构化资格甚至全站受影响，恢复要等下一轮Manual Action review。

FAQPage和HowTo Schema是不是没用了？

Google 2023-2024把这两类桌面富结果几乎清零，纯为富结果写没意义；但它们仍是AI检索（ChatGPT、Perplexity、AI Overviews）抽取问答和步骤的高价值信号，回报落在AI引用上。

AI搜索时代Schema还值不值得花力气？

值得，但收益结构变了。富结果换的是SERP点击量；AI检索时代Schema帮你的内容更高概率被抽成可引用事实块、附带回链。重心要从凑字段拿星标转到把核心事实显式表达。