结构化数据生成器怎么用？13种Schema类型一键生成JSON-LD

太长不看：结构化数据生成器把Article、Product、FAQPage、HowTo、LocalBusiness等13种Schema类型做成填表式的表单，你填字段、它出标准JSON-LD。它干的活有两层：一是按Google对每种类型的要求，把表单字段映射成正确嵌套的Schema对象（作者包成Person、发布者包成Organization、价格包成Offer）；二是用一套递归清洗算法把所有空字段剔干净，保证输出的代码不带一丝冗余。这篇把13种类型、字段映射逻辑、那套清洗算法和从生成到验证的动线全讲透。

先说个判断：如果你还把结构化数据当成“有空再搞”的可选项，这几年大概率吃了亏。富媒体结果、知识面板、AI搜索的引用，越来越依赖你有没有用机器读得懂的方式，把页面信息标注清楚。而标注的标准语言，就是Schema结构化数据。

问题是，手写JSON-LD又啰嗦又容易错。一个嵌套层级写错、一个必填字段漏了、一个日期格式不对，整段Schema就废了，还未必报错。结构化数据生成器存在的意义，就是把这件容易翻车的体力活，变成填表那么简单。

为什么结构化数据从“加分项”变成了“入场券”？

三五年前，结构化数据确实更像锦上添花——加了可能拿富媒体，不加也不影响基本排名。但游戏规则变了。

第一层变化在搜索结果页。带评分星级、FAQ折叠、面包屑、价格库存的富媒体结果，在SERP里占的面积更大、视觉更抢眼，点击率显著高于纯文字结果。而这些富媒体，每一种背后都对应一段特定的Schema。没有结构化数据，你连参加富媒体这场竞争的资格都没有。Google在《Introduction to structured data markup in Google Search》里说得直白：必填属性给齐了，才有资格在搜索里获得增强展示。

第二层变化在AI搜索。豆包、Perplexity、Google的AI Overview这些引擎抓取、理解、引用网页时，结构化数据是它们快速读懂“这页讲的是什么、有哪些实体、价格多少、作者是谁”的捷径。标注清晰的页面，被AI准确理解和引用的概率更高。在GEO（生成式引擎优化）的语境里，Schema已经从SEO的配角，升格成内容可被机器消费的基础设施。

第三层是信任信号。完整的Organization、Person、Article标注，等于把你的身份、作者、发布关系明明白白告诉搜索引擎，是E-E-A-T信号的机器可读版本。这三层叠加，结构化数据早就不是“要不要做”，而是“做得多规范”的问题了。结构化数据Schema怎么配合SEO落地这篇把这套配合关系讲得更系统，想先建立全局认知可以从它读起。

13种类型覆盖了哪些场景？

生成器内置13种最常用的Schema类型，基本覆盖了内容站、电商、本地商家、个人品牌的主流需求。每种类型都标好了Google要求的必填字段（带星号），照着填就不会漏。

选型其实有规律。内容站主力是Article和FAQPage、HowTo；电商主力是Product加BreadcrumbList；本地服务业靠LocalBusiness；做个人IP或公司站补Person和Organization。一个页面常常不止配一种——一篇带常见问题的教程，可以同时上Article、HowTo、FAQPage三层标注。

生成器的算法核心：表单到JSON-LD的映射与清洗

表面上你只是填了几个框，点一下生成。底下其实有两步关键处理，决定了输出的JSON-LD规不规范。

第一步：字段映射与嵌套包装

Schema不是把字段平铺出来就完事，它有严格的嵌套结构。生成器的核心工作，就是把你填的扁平表单，按Schema.org的规范包装成正确的嵌套对象。

拿Article举例。你填了作者姓名，生成器不会直接写成一个字符串，而是包成一个Person类型的对象，写成作者是一个“类型为Person、名字为某某”的结构。你填的发布者和Logo，会被包成一个Organization对象，里面再嵌一个ImageObject类型的Logo。你填的文章链接，会被包成mainEntityOfPage下的WebPage对象。这些嵌套关系，正是Google验证Schema合不合规的关键。

Product类型更典型。价格、货币、库存状态会被一起包进一个Offer报价对象，库存状态还要转成Schema.org规定的完整网址形式——比如有货对应一个特定的schema.org链接，而不是随手写个InStock。评分和评价数包成AggregateRating，品牌包成Brand，卖家包成Organization。

这一整套包装规则，生成器都按Schema.org的词汇表替你处理好了。Schema.org官方的Product类型定义页就是这套词汇的源头，列清了name、image、offers、brand、aggregateRating这些属性各自该怎么用，生成器做的就是把它翻译成填表动作。

第二步：递归清洗空字段

第二步同样关键，却最容易被忽略：清洗。你填表时不可能每个可选字段都填满，没填的那些怎么办？如果生成器把空字段也一股脑写进JSON-LD，输出就会塞满一堆值为空的属性——这既冗余，有些还会让Google的校验报警。

所以生成器在输出前，会用一套递归清洗算法把整个对象过一遍，把所有空值彻底剔干净。这套算法下一节专门拆。结果就是：你填了的字段才出现在代码里，没填的一个不留，输出永远干净利落。

cleanEmpty：为什么生成的代码总是干干净净

这套清洗算法值得单独讲，因为它是“生成的代码能不能直接用”的关键。它的逻辑是递归地遍历整个JSON-LD对象，逐层把空东西删掉。

具体分几种情况处理。遇到值是空字符串、null或未定义的属性，直接删掉这个属性。遇到值还是个对象，先递归进去把里面清干净，清完如果这个对象变成了空对象，连它自己也删掉。遇到值是数组，先把数组里的空元素过滤掉、再对每个元素递归清洗，清完如果数组空了，也删掉。

这个“递归”很重要。结构化数据是多层嵌套的，一个空字段可能藏在第三层第四层。非递归的清洗只能扫到第一层，深层的空值照样漏网。递归清洗则是一层层钻到底，确保从最外层到最里层，没有一个空属性能蒙混过关。

举个直观的例子。你填Product时填了名称、价格，但没填品牌、没填评分。生成器先按完整模板把Product对象搭出来，里面brand、aggregateRating这些字段此刻都是空的。然后cleanEmpty一过，空的brand、空的aggregateRating整个被删，最终输出的JSON-LD里只有name、offers这些你真填了的字段，干净得像手写精修过一样。这就是为什么生成器的代码可以放心直接贴进页面。

逐类型拆解：几种主力Schema的骨架

把几种最常用类型的骨架结构摊开看看，理解了结构，你才知道生成器替你省了多少事、也才会判断生成的代码对不对。

Article：内容站的标配

Article的骨架是：顶层是Article类型，挂着headline标题、image主图数组、datePublished发布日期。作者不是裸字符串，而是一个Person对象。发布者是一个Organization对象，内嵌logo的ImageObject。再加一个mainEntityOfPage指明这段Schema描述的是哪个页面。Google官方的《Article结构化数据》文档其实说明它没有死规定的必填项，但作者、发布者、日期这些是富媒体展现真正吃得上的信息。

Product：电商的命脉

Product顶层挂name、image、description，核心是那个offers报价对象——price价格、priceCurrency货币、availability库存状态（用schema.org完整网址表示）缺一不可。想出星级，再加aggregateRating，里面是ratingValue评分和reviewCount评价数。这套是拿产品富媒体的标准配置。

FAQPage与HowTo：内容增强双子星

FAQPage的结构最简单也最实用：一个mainEntity数组，每个元素是一个Question，每个Question挂一个acceptedAnswer的Answer。一问一答，规规整整。HowTo则是step步骤数组，每步是一个HowToStep；还能挂tool工具、supply耗材、estimatedCost预估成本（包成MonetaryAmount货币金额对象）。这两种是内容站把普通文章升级成富媒体的利器。

LocalBusiness：本地商家的门面

LocalBusiness顶层挂name、image、telephone，地址是一个PostalAddress对象，拆成街道、城市、州省、邮编、国家。填了经纬度还会包成GeoCoordinates，营业时间包成OpeningHoursSpecification数组。本地服务业把这套填全，是抢本地搜索和地图展现的基础。

怎么用生成器给页面配上结构化数据？

原理讲完，落到动作。下面这套四步法，是保哥给页面补Schema的标准流程。

第一步：按内容选类型

先判断页面是什么。文章选Article、产品选Product、问答选FAQPage、教程选HowTo。别硬套——给一个产品页配Article是文不对题，Google一眼识破。一个页面同时具备多种性质，就分别生成多段Schema叠加，比如教程页同时上Article和HowTo。

第二步：先填必填，再补可选

带星号的是Google要求的必填字段，优先填满，这是拿富媒体资格的底线。填完必填再按需补可选字段，能让Schema更丰富、信息更完整。不用担心填不全——没填的字段会被自动清洗，不会留下空属性。

第三步：生成、复制

点生成。工具吐出一段嵌套规范、空值清干净的JSON-LD，带着script标签，可以整段复制。这段代码已经是可以直接用的成品，不需要你再手动修嵌套、补引号。

第四步：贴进页面，验证资格

把JSON-LD贴进页面，head或body里都行。贴完别想当然，用Google的富媒体测试工具验一遍它认不认，再用Meta标签检测器确认结构化数据项被识别到。验证通过，这页的Schema才算真正落地。

串进工具链：从生成到验证到展现

生成JSON-LD只是一环，结构化数据是个“生成—验证—展现”的闭环，前后还得搭别的工具才完整。

生成之后第一件事是验证落地。把页面丢进Meta标签检测器跑一遍，它的Schema项会告诉你结构化数据有没有被识别到、是什么类型。检测器里Schema是权重15的大项，从20分跳到100分，靠的就是你这段生成的JSON-LD。生成器出代码、检测器验落地，天生上下游。

验证之后看展现。结构化数据的回报是富媒体，而富媒体在搜索结果里长什么样，用SERP模拟器提前预览。它能模拟评分星级、FAQ折叠这些富摘要的展示效果，让你在配Schema之前就知道“配了能换来多大的展示面积”，反过来指导你该优先配哪种类型。

如果你的页面FAQ多、想专门把问答Schema做到极致，FAQ Schema优化器是更聚焦的选择。而想看竞品页面到底埋了哪些结构化数据，Schema提取器能把任意页面的Schema扒出来，抄作业、找差距都用得上。一条线串下来，从规划到生成到验证到展现就齐了。

新手最常踩的五个坑，生成器替你躲了几个

手写结构化数据的翻车姿势，来来回回就那么几种。把它们列出来，你会更清楚生成器的价值边界——哪些它替你躲了，哪些还得你自己留神。

第一坑，嵌套层级写错。把作者直接写成字符串而不是Person对象、把价格平铺出来而不是包进Offer，是最高频的错误，Google校验直接判不合规。这个坑生成器替你躲得最彻底，它的嵌套是按规范写死的。

第二坑，日期格式不对。Schema里的日期要用ISO 8601标准格式，手写常写成中文习惯的年月日，机器读不了。生成器用日期选择器收集，输出自动是标准格式，这个也替你躲了。

第三坑，枚举值瞎写。库存状态、活动出席模式这些必须用schema.org规定的标识符，凭感觉写英文单词十有八九不对。生成器内置了合法枚举的下拉，选而不是写，又躲一个。

第四坑，标注与页面内容不符。这个生成器躲不了，得靠你自己——标了评分，页面上就得真有评价；标了价格，就得是真实在售的价格。这是会招Google人工处罚的红线，工具只负责生成，真实性得你把关。配Schema之前，先确保页面上这些信息用户真看得见，这和你优化标题描述时讲究的SERP真实展现是一个道理：标给机器看的，必须和给人看的一致。

第五坑，贴了不验证。很多人生成完贴上就走，从不回头确认Google认不认。结构化数据是“静默失败”的——错了往往不报错，只是默默不生效。所以生成只是上半场，拿Meta标签检测器的Schema项和Google富媒体测试工具验一道，才算把这件事做完。

JSON-LD、Microdata、RDFa：为什么首选JSON-LD

结构化数据有三种写法：JSON-LD、Microdata、RDFa。生成器只产JSON-LD，这不是偷懒，是有讲究的。

Microdata和RDFa都是把标注属性直接掺进HTML标签里，和你的页面结构、视觉内容缠在一起。改个版、调个样式，一不小心就把标注碰坏了，维护起来提心吊胆。JSON-LD则是一整段独立的script，和页面HTML完全解耦，想加想改想删都是动这一段，不碰页面其余任何地方。

这正是Google官方推荐JSON-LD的理由——它在《Introduction to structured data markup in Google Search》里明说，只要站点条件允许，推荐用JSON-LD，因为它对站长来说最容易实现和规模化维护。生成器只做JSON-LD，就是把这条官方最佳实践替你定死了，你不用纠结选哪种格式。Schema结构化数据怎么做？@graph与知识图谱怎么搭这篇能带你从单段JSON-LD进阶到用 @graph把多个实体串成图谱，是这块的下一站。

中文站与AI引擎场景的额外考量

得诚实交代几个生成器顾不到、但你得心里有数的点。

其一，类型枚举值用英文。Schema.org的词汇本身是英文体系，库存状态、活动模式这些枚举值必须用规定的英文标识符（和schema.org网址里的写法一致），不能改成中文。但描述性的字段值——产品名、文章标题、FAQ答案——完全可以、也应该用中文，这部分照你页面的真实语言写。

其二，富媒体资格因地区和类型而异。同一种Schema，Google在不同国家、不同时间支持的富媒体形态会变。最典型的是FAQ富结果，Google一度大幅收缩了它的展示。所以别把“配了Schema”等同于“一定出富媒体”，配Schema永远是必要不充分条件，展现与否的最终决定权在搜索引擎手里。

其三，AI引擎的口味还在变。在GEO场景下，结构化数据帮AI理解实体和事实，但各家AI引擎对Schema的依赖程度、解析方式并不统一，且都在快速演进。保哥的建议是：把规范、完整的Schema当成长期资产去建——它对传统富媒体、对AI理解都有正向作用，是少数“做了不亏、长期复利”的基础设施。把它做扎实，比追逐某个引擎的短期偏好更划算。

哪些页面优先配Schema？按ROI排个序

一个站几百上千个页面，不可能一夜之间全配上结构化数据。和做meta体检一样，配Schema也讲究优先级，把有限的精力先砸到回报最高的地方。保哥的排序逻辑是这样的。

第一梯队，能直接换富媒体、且流量价值高的页面。电商的核心产品页配Product拿星级和价格展示、有真实评价的页面配AggregateRating、菜谱站的热门食谱配Recipe。这类页面Schema和富媒体的转化最直接，配了就可能在SERP里多占面积、多拿点击，ROI最高，先配它们。

第二梯队，结构清晰、适合AI引用的内容页。深度教程配HowTo、问答密集的页面配FAQPage、所有文章配Article。这一梯队的回报未必是肉眼可见的富媒体，而是让搜索引擎和AI引擎更准确地理解、引用你的内容——在GEO时代，这层价值正在变重。

第三梯队，站点级的身份标注。首页配Organization或WebSite、关于页配Person、全站配BreadcrumbList。这些标注的是你的身份和站点结构，是信任信号和导航信号的底座。配一次管全站，工作量小、长期价值稳，适合在前两梯队铺开后顺手补齐。

这个排序不是铁律，得结合你站的类型微调——电商把Product顶在最前，内容站把Article和HowTo提前，本地服务业LocalBusiness就是第一优先。但核心思路一致：先配“能换富媒体、流量大”的，再配“帮机器理解”的，最后补“站点身份”的。照这个顺序推进，每一步都踩在回报最高的点上，不会把力气浪费在没人看的页面上。

常见问题解答

结构化数据生成器和手写JSON-LD比，到底省在哪？

省在三件最容易翻车的事上。一是嵌套——作者要包成Person、价格要包成Offer、库存状态要写成schema.org完整网址，手写极易写错层级，生成器按规范替你包好。二是清洗——没填的字段会被自动剔除，不会留下一堆空属性触发校验警告。三是必填提示——带星号标出Google要求的字段，避免漏填导致拿不到富媒体资格。这三件事手写时最耗神，也最容易出隐性错误。

一个页面可以放多段不同类型的Schema吗？

可以，而且很常见。一篇带常见问题的操作教程，同时放Article、HowTo、FAQPage三段Schema完全合理，因为这个页面确实同时具备这三种性质。做法是分别生成三段JSON-LD都贴进页面。进阶玩法是用 @graph把多个实体合并进一段、并用 @id互相关联，但对多数页面，分开贴几段已经够用。

生成的JSON-LD贴进页面后，多久能出富媒体？

没有固定时间，而且不保证一定出。Google要先重新抓取这个页面、解析到结构化数据、判定它合规且值得展示，才可能给富媒体。这个过程从几天到几周不等，取决于你站的抓取频率。更重要的是：合规只是资格，最终给不给富媒体由Google决定。配好Schema、通过富媒体测试，你能做的就到位了，剩下的是耐心等抓取。

库存状态、活动模式这些为什么要用一长串网址，不能直接写文字？

因为它们是Schema.org定义的枚举值，规范要求用完整的schema.org网址形式来表示，这样机器才能无歧义地识别。比如有货不是随手写InStock，而是写成对应的那个schema.org链接。这种地方手写最容易写错或写漏，生成器会自动转成规范形式，是它替你避坑的典型场景。

FAQ Schema还值得做吗？听说Google砍了FAQ富结果？

值得，但要降低对“富结果展示”的预期。Google确实大幅收缩了FAQ富结果在普通站点的展示，所以别再指望靠它白捡SERP面积。但FAQPage结构化数据对AI引擎理解你的问答内容、对内容的语义清晰度仍有价值。把它当成给机器读的结构标注、而非纯展现手段，它依然该写，只是动机从“拿富媒体”转向了“被准确理解”。

JSON-LD该贴在head里还是body里？

两处都行，Google都能识别，这正是JSON-LD解耦的好处之一。实践中放head更常见、也更整洁，因为它和页面其他元数据待在一起，便于统一管理。如果你的Schema是由页面正文动态生成的（比如评论数据），放对应内容附近的body里也完全没问题。关键不是位置，而是这段script能被抓取到、内容和页面一致。不像Microdata必须贴着可见元素写，JSON-LD在哪儿都能独立工作。

生成器支持的13种类型不够用怎么办？

13种覆盖了绝大多数常见场景，但Schema.org的完整词汇表有上百种类型。如果你需要的是更冷门的类型，比如Course课程、JobPosting招聘、SoftwareApplication软件，生成器没内置，就得手写或基于它生成的相近类型改。不过对内容站、电商、本地商家、个人品牌这四类主流站点，这13种基本够使，真正会用到冷门类型的是少数垂直场景。先把主流类型用好，再说特殊需求。

结构化数据写错了会被Google惩罚吗？

无心写错一般不会招致惩罚，最多是这段Schema不生效、拿不到富媒体。真正有风险的是“结构化数据造假”——比如标了评分但页面上根本没有评价、标的内容和页面可见内容不符。这种欺骗性标注Google是会人工处罚的。原则很简单：Schema标注的必须是页面上真实存在、用户看得见的信息，别拿它骗富媒体。