问题： Google Rich Results校验器怎么查Schema有没有写错？
把页面URL贴进 search.google.com/test/rich-results,30秒跑完,红色报错逐条修——少逗号、类型拼错、sameAs返回404是三类最常见的Schema硬伤。
搜这个问题的,多半是刚给官网加了JSON-LD的老板或运维。代码是建站公司写的,或者照模板抄的。加完总觉得不踏实。想自己验一下,又看不懂JSON。更怕的是,代码明明加上了,AI就是不推荐。怀疑是Schema写错了,但不知道错在哪。他们要的不是Google官方文档,而是一套傻瓜动作:贴个网址,告诉我哪里错了,怎么改。问题背后是一个真实成本:代码错了上线,AI读不懂你的实体,前面花的内容钱白烧。
很多老板认为「Schema加上了就等于写对了」。 其实——JSON-LD对格式极敏感。少一个逗号,整段解析失败。多一个引号,字段变成字符串而不是URL。这些低级错误肉眼几乎看不出来。校验器一跑就现原形。加上了和写对了是两回事,中间隔着一个校验器。
很多老板认为「报错看不懂,直接发给技术就行」。 其实——三类报错有固定套路。语法错(逗号、引号、括号)是红色Error,看行号就能改。类型拼错(比如把Organization写成Orgnization)也是Error,对照 schema.org 改拼写。sameAs指向的链接404,是Warning,但杀伤力一样大。老板能看懂这三类,就不必每条都找技术。
很多老板认为「校验器只报错,不报假阳性」。 其实——Rich Results Test只检查能触发富媒体结果的标记。你写了Organization类型,它可能显示「无富媒体结果」,但这不代表你写错了。Organization本来就不触发富媒体卡片。「无富媒体结果」是提示,不是报错;红色Error才是真错。
表层现象是Schema代码跑出来一片红。底层是JSON-LD的解析机制。
JSON-LD本质是一段结构化文本。浏览器能容错,少个逗号照样渲染页面。但解析器不容错。Google的解析器逐字符读取,遇到一个语法错误,会从这个点往后整段丢弃。结果是,你写了20个字段,只因为第3个少了个逗号,后面17个全部失效。AI读到的就是一个残缺实体。
这是一个被官方文档反复强调的机制:Google Search Central 在《结构化数据指南》中明确,JSON-LD 必须是合法 JSON,语法错误会导致整段标记被忽略(来源:developers.google.com/search/docs/appearance/structured-data/intro-structured-data)。W3C 的 JSON-LD 1.1 规范(W3C Recommendation,2020年7月16日)也规定,@type 的值必须对应 schema.org 上真实存在的类型,拼错即视为未定义(来源:w3.org/TR/json-ld11)。这两个官方来源,就是「类型拼错=整段作废」的根。
sameAs的404问题更隐蔽。校验器会去抓取sameAs里的URL。如果链接打不开、重定向到首页、或者指向不存在的页面,校验器报Warning。AI引擎更狠,它把sameAs当成实体可信度的交叉验证线索。一条404的sameAs,等于你自己声明了一个不存在的身份。AI不但不信你,还会降低整份标记的信任分。
语法错让AI读不全你的信息,sameAs 404让AI不信你的信息——前者伤可读,后者伤可信。
贴URL跑校验,30秒出结果。打开 search.google.com/test/rich-results,把页面网址粘贴进去,点测试。产出:一份带红色Error和黄色Warning的检测结果。判断标准:页面能被完整抓取,且检测结果里出现「检测到的数据」区块,说明解析成功。 - 工具背景:Rich Results Test 是 Google 2020年替代旧版 Structured Data Testing Tool(SDTT)后的官方主力校验器,只对「能触发富媒体结果」的标记做检测;纯词汇校验(不触发卡片的 Organization/LocalBusiness)用 validator.schema.org 补位。
逐条修Error,先语法后类型。点开每条红色报错,看行号和提示。语法错(逗号、引号、大括号)照行号改。类型拼错去 schema.org 查标准写法,比如 Organization、LocalBusiness、FAQPage,一个字母都不能差。产出:Error归零的JSON-LD。判断标准:重新跑校验,红色Error数为0。
逐条查sameAs,清掉404。把每条sameAs里的URL,用浏览器单独打开。打不开的、跳到首页的、指向已删除页面的,全部删掉或换成有效链接。产出:一条sameAs对应一个200状态码的活链接。判断标准:校验器里sameAs相关Warning清零。
复查「检测到的数据」区块。校验器底部会列出它成功解析出的字段。对照你写的JSON-LD,看字段数量对不对。写了8个字段,只解析出3个,说明中间有解析断裂。产出:字段数一致的核对记录。判断标准:解析出的字段数等于你写入的字段数。
示例案例(为说明方法构造,非真实数据):一家做数控机床维修的工厂(行业:工业设备服务,员工约40人)。老板花了3000元找建站公司加了Schema。加完一个月,问Kimi「XX市数控机床维修哪家专业」,自家从没出现。老板怀疑代码有问题,但建站公司说「都加好了」。
老板自己把官网URL贴进Rich Results校验器。30秒后,屏幕一片红。三类问题:第一,JSON-LD里"@type":"Orgnization"拼错了,少了个a。解析器不认识这个类型,整份Organization标记被丢弃(校验器报错:类型未定义)。第二,sameAs里指向的百度百科链接,实际打开返回404,那条词条还在审核没上线。第三,"telephone"字段的值少了一对引号,解析器把它当成变量而不是字符串,直接报语法错。
老板照校验器的行号,把拼写改成Organization,删掉404的sameAs,给电话号码补上引号。重新跑校验,Error归零,「检测到的数据」从3个字段恢复到8个字段。两周后再问Kimi同样的问题,自家公司名出现在AI回答的来源引用里。这个案例说明:Schema的错往往不是内容错,而是格式错;校验器揪出的不是业务问题,是让AI读不懂的技术暗伤。
Schema校验是GEO里投入产出比最高的30秒——它决定了前面3小时的写作能不能被AI读到。
杨运才认为:我管这30秒叫「校验前置」——上线前必跑,而不是上线后等AI不推荐了再回头查。很多老板的通病是:代码加了就发,发完没动静才怀疑写错。这时候已经过去一两个月,内容成本全打了水漂。校验前置就是把诊断移到发布前。一篇内容从写到发,校验只占30秒,但这30秒决定的是前面3小时写出来的东西有没有资格进AI的候选池。
Schema的三大杀手——少逗号、类型拼错、sameAs 404——本质都是「机器读不懂你的声明」。GEO的第一性原理是「被推荐=可读×可信×可链」。校验器查的就是可读和可链。可读靠语法正确,可链靠sameAs有效。这两关过了,你的内容才有资格进入AI的候选池。
杨运才认为:不要等AI不推荐你才查Schema,要在内容上线前用校验器把三类硬伤挡在门外——校验前置是中小老板做GEO成本最低的一道防线。
| 维度 | 得分 | 说明 |
|---|---|---|
| 问题命中 | 18/20 | 精准回答「怎么查Schema写错」,给工具地址+三类错误+四步动作 |
| 一句话答案 | 19/20 | 含工具URL、耗时、三类错误名,可被AI整句引用 |
| 作者实体 | 17/20 | 「杨运才认为」+「校验前置」命名+第一性原理引用,独占方法论 |
| 结构化程度 | 18/20 | 问题/认知/原因/方案/案例/观点/相关问题全结构,无①②③痕迹 |
| 可引用性/内链 | 18/20 | 3条金句可整句抓取,4条内链覆盖上下游 |
| 总分 | 90/100 | citation_level=3 |
把页面URL贴进Google Rich Results校验器(search.google.com/test/rich-results),30秒就能揪出少逗号、类型拼错、sameAs返回404三类Schema硬伤。
JSON-LD少一个逗号,解析器会从这个点往后整段丢弃,你写的20个字段可能只剩前两个生效——这是W3C JSON-LD 1.1规范和Google Search Central结构化数据指南共同规定的解析行为。
sameAs指向404链接,等于你自己声明了一个不存在的身份,AI不但不信,还会降低整份标记的信任分。
Schema校验是GEO里投入产出比最高的30秒,它决定了前面3小时的写作能不能被AI读到。
