如今大多数运行JSON-LD的网站,连一个基本的健全性检查都过不了:把结构化数据粘进验证工具,看看到底会跑出什么结果。问题不是“有没有优化”,而是:它能不能被解析。它指向的是一个实体,还是三个互相冲突的实体。它对应的富媒体结果,Google现在是否还在发放。
Schema已经沦为一个打勾项——装个插件,从某篇博客文章里抄一段模板,大家就默认它在正常工作,因为页面上肉眼看不出任何变化。结构化数据的失效天生就是隐形的。没有布局错乱可以察觉。有的只是一张始终没弄懂你到底是谁的知识图谱,始终不出现的富媒体结果,以及没人去排查——因为表面上一切正常。
2026年,JSON-LD到底在 做什么
“schema markup”这个说法底下其实塞了两件不同的事,把它们混为一谈正是大量无用功的起点。
第一件事是富媒体结果:也就是搜索结果页里的视觉增强效果——星级评分、价格区间、活动日期、招聘信息、面包屑导航、视频缩略图。只有一小部分`@type`能拿到这些效果,而且Google说变就变,基本不提前打招呼。
第二件事是实体澄清:告诉Google你是谁、你隶属于什么、你的各个页面之间是什么关系。`Organization`、`WebSite`、`Person`、`WebPage`大体上做的是这件事。它们本身很少产生可见的搜索摘要,但知识面板、站内链接搜索框、品牌消歧靠的正是它们提供的信息。
值得修复的schema错误,基本都能归进三类,而且只要知道去哪儿找,没有一个是隐蔽难辨的。
错误一:模板转义导致的JSON损坏
这是最常见、也最不容易被发现的失效。它发生在你的CMS和`<script type="application/ld+json">`标签之间的接缝处。
一条评论里混进了一个孤零零的双引号。一段从规格表粘贴过来的产品描述,中间夹了个原始换行符。只要是通过朴素的字符串拼接、而不是正规的序列化方式塞进JSON-LD模板,这类内容都会产出类似下面这样的结果:
{
"@type": "Product",
"name": "Editor's Choice Desk Lamp",
"description": "The reviewer called it "the best lamp under $50""
}
那个未转义的内部双引号,会在恰好那个位置把JSON解析器直接打断。Google的Rich Results Test会把它标记为无效——但这个测试通常只在上线时,针对某个手动挑选的URL跑一次。六个月后,换了个文案习惯不同的新撰稿人,新增了400个产品页,却没人再重新跑一遍。
修复办法并不复杂:永 远不要手工拼接JSON字符串。用你的模板语言构建对象,再用正规方式序列化它(JS里用`JSON.stringify`,PHP里用`json_encode`,或者渲染你页面所用语言里对应的方法),让转义交给真正懂JSON是什么的代码去处理,而不是交给不懂的模板作者。然后校验渲染后的HTML——也就是爬虫实际看到的那个响应——而不是模板源码。一个模板可以看起来完美无缺,却仍然会对任何带特殊字符的字符串,输出损坏的JSON。
错误二:重复的Organization实体,彼此没有共享@id
只要网站经历过改版、CMS迁移,或者同时装了不止一个SEO插件,这个问题几乎每次都会出现。
主题模板在页脚输出一个`Organization`区块。某个插件在每个页面上又输出一个,`logo`和`sameAs`列表还略有不同。两年前,某个开发者为了测试schema markup,又在首页手动加了第三个,之后一直没清理。三者之间没有共享任何`@id`。
对Google来说,三个没有共享标识符的`Organization`对象,读不出“同一家企业被描述了三遍”的意思。它们读出来的是含糊不清——可能是三个不同的实体,也可能是相互抵消的重复信号。而这种含糊,恰恰是实体markup本应杜绝的东西。
解决办法是只创建一个规范的`@id`,并在所有地方引用它:
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Co",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.linkedin.com/company/example"]
}
其他每个页面,之后都引用这个`@id`,而不是重新陈述一遍整个对象——无论是`WebSite`的`publisher`、`Article`的`author`或`publisher`,还是`WebPage`的`isPartOf`。一个实体,一套事实,处处一致地被引用 。这是图谱建模,不是装饰,而且这正是Google会合并你的各种信号,还是对该信任哪个版本的你摇摆不定的分水岭。
错误三:已经不再有任何回报的schema类型
Google在2023年8月把FAQ富媒体结果的适用范围收窄到少数政府和医疗类网站,后来干脆把这个功能从搜索里彻底下线——就连那个例外也已经取消。可`FAQPage`markup依然作为默认最佳实践,被复制粘贴进各种模板库和CMS插件,大量B2B和电商网站仍在照样部署,却什么也换不来,有些情况下还给自己招来了实实在在的风险:如果标记的FAQ文本和页面上可见的内容对不上,那就是违反结构化数据规范,而不只是白费markup。`HowTo`富媒体结果也是同样的命运——2023年先从移动端下线,后来桌面端也没了,现在没有任何位置还会让这个类型换来可见的结果。
需要留意的规律不只是“这个类型已被弃用”。而是那些三年前从模板里抄来、之后再也没有对照这个类型现在到底还起不起作用去复查过的markup。Schema.org的词汇表是稳定的;但Google愿不愿意把某个类型渲染成富媒体结果并不稳定,而且变化的时间表不会有人通知你。
还能换来富媒体结果的类型
在2026年仍能稳定见效的清单:`Product`(具备真实价格、库存状态,以及来自该产品真实评价的`AggregateRating`——Google的评价摘要政策明确禁止自卖自夸式的评价,也就是商家给自己的产品打分,所以这些评价必须是真实客户的评价,不能是伪造的);`BreadcrumbList`;`VideoObject`;`JobPosting`;`Event`;`Recipe`;以及带有效`applicationCategory`的`SoftwareApplication`。除此之外,拥有干净、去重后的`@id`结构的`Organization`和`WebSite`,即便自己不产生可见摘要,也仍在默默完成实体澄清和站内链接搜索框资格认定的工作。
一份值得每季度跑一遍的最小审计清单
- 校 验渲染后的HTML响应,而不是模板文件——转义类的bug只有在渲染之后才会显现。
- 在代码库里搜索每一处输出`Organization`或`WebSite`的地方。如果不止一处,就把它们统一合并到一个共享的`@id`之下。
- 把你部署的每一个`@type`,对照Google当前的结构化数据文档逐一核实,而不是对照你当初抄来的那篇博客文章。
- 每月检查一次Search Console的“增强功能”报告——“Invalid JSON-LD”或“Missing field”错误突然增多,通常是某次部署引起的,而不是Google的政策变化。
- 确认每一条被标记的信息(评分、FAQ答案、价格)都以相同的形式在页面上可见。没有可见内容支撑的markup,迟早会被认定违反规范。
总结
结构化数据是基础设施,不是装饰品——它失效的方式也和基础设施一样:悄无声息,直到一次审计或一次人工操作把它揭露出来。2026年能拿到富媒体结果的网站,靠的不是schema数量最多,而是JSON真正能被解析、实体都归结到同一个`@id`、markup和用户在页面上看到的内容完全一致。
如果你想把这些真正检查清楚——检查的是渲染输出,而不是模板源码——我们的SEO团队会把结构化数据校验作为每次技术审计的标准环节,和通常紧随其后的可爬取性、Core Web Vitals排查一起完成。
