【SEO学习系列】 37 | Schema检测通过，为什么搜索结果还是没变化？

给网站加好Schema，检测工具显示通过，再去Google搜一下，结果还是原来的样子。

这时很容易继续找插件、补字段，甚至再贴一份代码。可问题未必出在“标记不够多”。你得先确认：刚才通过的是哪一种检测？Google访问线上页面时，拿到的又是不是这一份内容？

结构化数据能帮助搜索引擎识别页面信息，也可能让页面具备某种富结果的资格。但具体怎么展示，不能由一段代码预订。Google结构化数据指南也明确说明：即使测试正确，仍不保证出现富结果。

上一篇检查爬虫能不能进来。这一篇接着看：进来以后，你交给它的那份页面说明，是否选对类型、写对信息，又经过了实际验证。

Schema.org是一套描述事物和关系的词汇。比如用Article描述文章，用Product描述商品。JSON-LD则是把这些信息写进页面的一种格式。平时说“加Schema”，常常把词汇、代码和搜索外观混在了一起。

实际检查时，可以分成三层。

• 代码能解析。
   引号、括号、属性和值有没有基本问题，声明了什么类型。
• 符合Google某项功能的条件。
   这个类型是否受支持，必填字段、页面内容及相关政策是否满足要求。
• 搜索中实际展示。
   Google是否已经处理了这个页面，当前查询、设备和其他条件下是否选择展示。

配图 01

代码能解析、符合功能条件和实际展示，是三层不同检查

第一层正常，不代表后两层就自动通过。比如Schema.org定义了某个类型，并不等于Google一定为它提供专门的搜索外观。Google支持哪些功能，要看它自己的现行功能列表，不能只看生成器里有多少选项。

因此，测试工具里出现“有效”或绿色提示时，先读它检测的对象和提示内容。别把“没有发现这类技术错误”理解成“Google已经决定给它展示”。

不用先记一大串类型。把你准备处理的页面打开，看读者实际能看到什么。

一篇有标题、作者和正文的教程，可以考虑Article或更具体的BlogPosting。字段应对应真实的标题、作者、日期和配图。当前Google的Article文档没有列必填属性，而是建议添加适用于内容的推荐属性；这不等于可以随便填，也不等于缺少某个推荐项就必然失败。Article说明

一张具体商品页，需要看Product及其适用要求。读者能直接在页面购买时，关注商家列表要求；商品介绍或评测还有商品摘要的场景。这两类不能混成一张字段清单。价格、币种、库存、评价是否需要，以及怎么写，都要按对应功能核对。商品结构化数据入口

一条真实的面包屑导航，对应BreadcrumbList。它表达页面在站内的浏览路径，不是把URL中的每段字符拆出来就算完成。Google建议体现典型用户路径。目前Google的面包屑搜索外观在桌面端提供，手机上没出现，不能据此断定标记配错了。面包屑说明

网站的机构信息，可以用Organization说明名称、网站、标志和相关身份信息。组织资料适合在首页或相关介绍页上如实表达，不用为了填满字段编一个办公地址。Organization说明

配图 02

从页面实际内容选择类型，不把类型清单当成必装清单

一页可以同时有文章、面包屑和作者信息；并不是只能选一个类型。但每一项都应有对应对象，关系也应说得通。普通服务介绍页，不要为了追求商品样式就硬塞一个带虚构价格的Product。

还有两个旧教程常见的入口，最好现在就划清边界：Google已停止展示HowTo富结果；FAQ富结果也已于2026年5月7日停止展示。Schema.org的类型还存在，不代表过去的Google展示功能仍在。FAQ内容本身是否有用，仍然取决于它能不能回答读者问题。Google功能更新记录

一个WordPress网站，主题和SEO插件可能都参与页面输出；Shopify也可能由主题、应用或自定义代码提供标记。后台看到一个开关，并不足以判断线上最终结果。

先选一张页面，打开网页源代码，搜索application/ld+json。如果没找到，也别立即断定没有：网站可能使用Microdata、RDFa，或在JavaScript执行后才生成JSON-LD，还要看渲染后的页面。

把已发现的内容简单记下来：谁生成的、描述哪个对象、关键字段是什么。能找到生成源头，再决定是修改、补充，还是保留。

一个页面有几段JSON-LD不一定有问题。真正值得处理的是：同一件商品被写成不同价格，同一个作者出现相互矛盾的身份，或者新代码加入后，旧版本仍在输出。

例如，Yoast提供了让扩展接入其Schema图的方式，目的之一就是把不同实体连接起来。对正在使用它的网站，先查已有图和集成方式，通常比另写一套互不相认的描述更容易维护。Yoast集成说明

Shopify官方的structured_data过滤器支持商品和文章对象；但这只能说明系统提供了这种能力，不能证明你的主题已经正确调用，更不能证明应用没有额外输出。最后仍要回到具体页面核对。Shopify过滤器文档

假设有一张教学页面，读者看到的路径是“指南 → 亚麻衬衫怎么洗”。下面用example.com作演示地址，不对应真实项目：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "指南",
      "item": "https://example.com/guides/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "亚麻衬衫怎么洗",
      "item": "https://example.com/guides/wash-linen-shirt/"
    }
  ]
}
</script>

这里最值得看的不是括号数量，而是几项对应关系：

• @context
  说明使用的词汇体系；@type说明描述的是面包屑列表。
• position
  表达顺序；name是各层名称。
• item
  对应那一层的页面地址，不能把整站每一页都写成同一个URL。

这段示例只描述导航，不描述商品，也不描述文章作者。不同对象有不同字段，不能换个@type名称就原样搬过去。完整定义可以对照Schema.org的BreadcrumbList。

Google推荐在便于实现时使用JSON-LD，它可以放在页面的head或body里。Microdata、RDFa也受到支持，并非必须因为“格式旧”而全部重做。支持的格式

以一件衬衫作演示：页面售价由49美元改成59美元，但手工写在模板中的price仍是49。代码没有语法错误，问题是它已经不再准确描述页面。

配图 03

价格变更演示：页面改了，结构化数据也要同步

这种情况不能只靠再点一次检测按钮处理。应该找到售价、币种和库存的实际数据源，让页面和结构化数据使用一致的信息；清理过期输出后，再看线上HTML及必要的缓存。

如果页面只有“联系询价”，没有公开售价，就不能随手填0或填一个大概价格来消除错误。它未必满足某个商家展示功能的要求，这时应重新判断适用功能，而不是补出并不存在的交易条件。商家列表要求

评价同样如此。没有真实评价，就不要编评分和评价数量。商品摘要允许的属性组合，与商家列表的要求也不同，不能把“没有offers就永远无效”当成所有Product场景的规则。商品摘要要求

文章字段也会过期。作者、发布时间、更新日期应与实际内容相符；不要只为了显得新，把所有文章的修改时间每天刷成当天。

如果用JavaScript生成标记，Google可以处理，但需要验证它实际拿到了什么。Google尤其提醒，动态生成的Product标记可能让购物抓取变得不够频繁或可靠；价格和库存变化快的网站，更应该重视生成方式和稳定性。JavaScript生成指南

Schema Markup Validator：先看你写出了什么。

打开https://validator.schema.org/，可以输入代码或页面地址，查看识别到的类型、属性和基本问题。它负责通用Schema.org标记验证，不负责判定Google每一种富结果的具体资格。验证器说明

Rich Results Test：看Google支持的功能和技术问题。

打开https://search.google.com/test/rich-results。开发时可以先测代码；上线后更应该测试实际URL，查看取回和渲染的内容、检测项目及错误详情。代码粘贴通过，不能证明你的服务器正在输出同一份代码。

优先修关键错误，再判断非关键问题中哪些信息真实存在、值得补充。没有真实数据的推荐字段，不靠编造补齐。工具没有识别出某类项目时，也先核对该类型是否在其支持范围内。Rich Results Test帮助

GSC：看上线之后Google记录了什么。

用URL检查区分已编入索引的历史版本与当前在线测试，再看适用的富结果状态报告。报告能帮助发现同一模板下多张页面出现的问题，不是每一种Schema.org类型都有独立报告，数据也不是发布即刷新。富结果状态报告

配图 04

三个工具分工：通用标记、Google功能测试、上线后的记录

一个省力的顺序是：先拿少量有代表性的页面测试，确认输出、字段和访问都正常，再扩大到其他页面。修改记录里至少保留页面URL、修改日期、生成来源和检查结果。以后换主题或升级插件，能顺着记录重新测。

先看Google是否还支持你期待的外观。不要用几年前教程中的截图，要求今天的搜索结果一模一样。

再看目标URL和访问条件。页面是否被robots.txt挡住、带noindex、需要登录，或者Google记录的还是修改前版本？这些问题没有解决，继续加字段通常回答不了当前疑问。上一期的robots检查方法，在这里就能接上。

然后比对标记与页面内容：商品、价格、作者、图片是否确实属于这张页面？渲染后有没有旧插件留下的另一份信息？关键字段是否只在你的登录状态下才出现？

最后，检查适用政策和GSC是否有相关人工处置提示。即使技术和内容检查都正常，Google仍可能选择普通文本结果。结构化数据的质量要求，有一部分无法仅靠自动工具判断。通用质量要求

如果要观察效果，先固定页面组、时间范围、国家和设备，再比较适用的搜索外观、展示、点击等数据。同期改了标题、内容或促销，也要记录，不能把全部变化归因于Schema。没有足够曝光时，结论也应保留余地。

至于AI搜索，不需要为了“被AI看见”再编一套特殊Schema。Google对AI功能的说明没有要求专门的Schema.org标记；页面可访问、内容有用、结构化信息与可见内容一致，仍然是更扎实的工作。Google AI功能说明

今天就可以选一篇文章或一张商品页：确认类型，找到现有输出的来源，把几个关键字段逐项对回页面，再按工具各自的职责测试。