10 月 18 号，做日料的王老板发来一条微信：为什么老张家的寿司店搜索里有星星，我这里没有。

他说的星星就是搜索结果里显示的评分。老张家的店旁边有五颗金色小星，下面写着 4.8 分、632 条评价。他自己的店只有一行蓝字标题，什么装饰都没有。

两家店我都去过，菜做得好不好先不说，网络层面的事我懂。我让他把他那个页面的源代码发过来。

打开一看，JSON-LD 是有的。埋在页脚前面一个 script 标签里，类型是 Article。

问题就在这。

Article 是文章类型，用在新闻页、博客页上。餐厅应该用 Restaurant 类型。用错了类型，搜索拿到这段数据之后不知道这是什么，索性就不展示。

这只是第一处问题。我接着往下看，又发现三处。

评分字段的结构不对

他的代码大概长这样：aggregateRating 下面写了 ratingValue: 4.8，但没写 ratingCount 和 reviewCount。这两个字段是配套的，告诉引擎这个评分是基于多少条评价。

只有评分没有评价数，会被认为这个数据不可信。要么不展示，要么把它归到用户上传类别里，权重打折。

地址信息不完整

他的 address 里只写了 streetAddress 和 addressLocality。Schema.org 规范要求，LocalBusiness 及其子类型的地址应该至少包含 streetAddress、addressLocality 和 addressRegion 三个字段，国家级还要加 addressCountry。

缺了字段，拿到的是一段不完整的地址数据。评分星星本来就未必显示，地址再不全，这个 Schema 在系统眼里就没什么价值了。

JSON 语法有个逗号问题

他的代码最后一段是这样的：把 telephone 字段放在最后，但 telephone 那行末尾多了一个逗号，后面紧跟一个右大括号。JSON 规范不允许最后一项有尾随逗号。

这种低级错误会让整个 JSON 解析失败。解析不了，等于没写。

四处问题我列完，跟王老板说：你现在这个 Schema，等于白放了一段。引擎看到它要么解析失败，要么数据不可信，不会拿它做任何展示。

他问怎么改。

修复方案

我先把那段 Article 删掉，然后按 Restaurant 类型重写了一段。

新的 JSON-LD 大概这样：@context、@type: Restaurant、name、image、servesCuisine、priceRange、address（含 streetAddress、addressLocality、addressRegion、addressCountry、postalCode）、telephone、url、aggregateRating（含 ratingValue、ratingCount、reviewCount）、openingHoursSpecification。

字段一共 20 多个。我改的时候对着 Schema.org 官方文档一项一项核对的。

评分这块，ratingValue 填 4.8，ratingCount 和 reviewCount 都填实际数量。他做了五年，大众点评上有 632 条评价，谷歌地图上有 189 条，我把两个都填了。

地址字段，我从他的营业执照上抄的完整地址，包括邮编。

telephone 用带国际区号的格式，+86-xxx-xxxxxxx。

openingHoursSpecification 按每天的时间段分开写。周一休息就单独标出来，不能笼统写每天 11:00-22:00。

改完是 10 月 20 号晚上。10 月 23 号，搜索结果里的变化开始出现。不是星星，是地址。

原来他搜索 XX 区 日料，结果里只显示标题和描述。现在标题下面多了一行地址，旁边一个小地标图标。

评分星星没出现。我问王老板有没有收到通知，他说没有。我说这正常。评分这个展示，审核比较严，可能需要几周甚至几个月才会亮出来。而且前提是你的评价数据来源是平台认可的渠道。

哪些是平台认可的渠道？目前是大众点评、百度地图、携程这几个。他自己官网上的评论数据，不认。

所以评分这块，不能只看自己官网的数据，得让第三方平台的评价也积累起来。

8 步通用检测流程

这次排查之后，我总结了一个 Schema 检测的通用流程，分享给做站的朋友。

第一步，看搜索结果长什么样

直接搜索你的品牌词、核心业务词。搜索结果里如果有额外的展示元素，比如星级、价格区间、常见问答折叠块、面包屑导航，说明 Schema 生效了。如果只有标题和描述，说明没有或者没生效。

这一步最重要，因为它是唯一的事实检验。

第二步，搜 application/ld+json

打开页面源代码，搜这个字符串。每个页面都应该有。找到之后，把那段 JSON 复制出来，用一个在线的 JSON 校验工具过一遍。有语法错误的，先解决语法错误。

第三步，贴到 Rich Results Test

Google 官方有个工具叫 Rich Results Test，地址是 search.google.com/test/rich-results。它不光检查语法，还会告诉你哪些字段缺失、哪些类型不匹配。

百度也有类似工具，在搜索资源平台里。但百度的检测不如 Google 严格，有些 Google 报错的地方百度会通过。

第四步，核对 Schema 类型

用错了类型是最常见的问题之一。一个清单：公司官网用 Organization，餐饮店用 Restaurant，酒店用 Hotel，医疗机构用 MedicalBusiness，电商商品页用 Product，博客文章用 Article 或 BlogPosting，常见问题页面用 FAQPage，教程页面用 HowTo，招聘页面用 JobPosting。

别乱用。Article 用在餐厅上不会有任何效果。

第五步，核对必填字段

每个类型都有自己的必填字段。Article 要有 headline 和 author，Product 要有 name 和 offers，Restaurant 要有 name 和 address。查 Schema.org 官方文档确认。

第六步，检查内容一致性

Schema 里的数据要跟页面上的可见内容对得上。你 Schema 里写评分 4.8，页面上没显示这个评分，会被判定为不一致，可能不展示甚至处罚。这条规则很多人不知道。

我处理过几个案例，站长手动加了一堆评分数据，页面上一个都没体现。结果不但没展示星星，还把整个 Schema 数据忽略了。

第七步，检查嵌套结构

有些类型需要嵌套。比如 Product 里的 offers 是个对象，里面还有 price、priceCurrency、availability 几个字段。写到一起容易出错。

第八步，最后检查支持的类型

百度不是所有 Schema.org 类型都支持。目前明确支持的有：Article、BreadcrumbList、FAQPage、HowTo、Product、VideoObject、Recipe、JobPosting 这些。一些冷门类型没实现，写了也不展示。

Google 支持的范围更广一些。

两个经验

回到王老板这个事，最后说两个经验。

第一，结构化数据不是越快越好，而是越准越好。有人为了快速拿到展示效果，把 Schema 写得比页面内容还丰富，结果反而被降权。写之前先看页面实际有什么，写实际有的。

第二，改完不要急着看效果，引擎抓取和重新评估 Schema 需要时间。快的一周，慢的一个月。这段时间保持其他 SEO 工作正常，别在 Schema 上反复改。

王老板的店现在搜索结果里有了地址行，评分还没出来。他昨天打电话说，最近一周电话咨询量有增加，可能是地址行带来的。这事我没法归因到具体哪一步，可能几个改动叠加的效果。

Schema 这种东西，属于做好了不显眼、做砸了很显眼的那类技术优化。很多人以为它是个小工作，其实里面坑不少。