结构化数据检测报的错，一半不用改

2026 年 1 月我们给一个 SaaS 站跑结构化数据检测，340 条报错，逐条看完真正需要动手的只有 27 条。剩下的是插件自动注入的标记、已经不展示的类型，以及工具之间的口径差异。把 340 条全修一遍，两周就没了。

报错分三类

第一类是致命错误，必填字段缺失。Article 缺 headline、Product 缺 offers、Breadcrumb 的 item 顺序错了，这类会影响富媒体展示，必须修。

第二类是警告，建议字段缺失。比如 Article 没写 author、Organization 没写 logo。这类不影响展示，有精力再补。

第三类跟你的页面没关系。很多 CMS 和营销插件会自动注入 Organization、WebSite 标记，字段填得一塌糊涂，检测工具照样报错。这类要么去插件设置里关掉，要么忽略，别手动改模板。

两个工具为什么结论不同

Rich Results Test 测的是你输入的那个 URL 的当前快照，Schema Markup Validator 测的是标记语法本身，GSC 的增强报告看的是线上抓取到的版本。三个来源的时间点不一样，GSC 的报告通常滞后 3 到 7 天。

我遇到过一个页面上线当天测全部通过，一周后 GSC 报错误，原因是部署时模板回滚了。所以别用测试工具的结果当最终结论，以 GSC 为准。

我们只修哪些

影响富媒体展示的优先修：Article、Breadcrumb、Product、SoftwareApplication、Video。这些能在搜索结果里多占一行，或者让实体更明确。

已经不展示的类型不用管。FAQ 类富媒体结果在 2023 年 8 月被收缩到少数站点，很多站还在拼命补 FAQ 标记，白费功夫。HowTo 也类似。

还有一类值得做但不叫修错误：给软件产品页加 SoftwareApplication 标记，写清楚名称、操作系统、价格区间。它不一定带来富媒体，但能让搜索引擎和 AI 搜索更清楚你是什么产品。

修的顺序

先看 GSC 增强报告里错误级别的类型分布，按影响页面数从多到少排。每类先修 5 个页面，等一周看报告有没有变化，确认修对了再全量。

两个容易漏的检查

第一个是 URL 的写法。Schema 里的 item、@id、breadcrumb 的 item 都要用绝对地址，写成相对路径时检测工具不一定报错，但解析会出问题。我们抽查时会专门搜一遍有没有 href=“/” 这种写法。

第二个是标记和页面内容要一致。价格改了但标记没同步，搜索结果里显示的价格和落地页差一倍，用户点进来就觉得被骗。每次改价、改套餐名，顺手检查一下标记。

我自己踩过的坑是一次性改了 800 个页面的模板，改错了一个字段名，等 GSC 报出来已经过了十天。批量改之前一定先用 5 个页面验证，这个习惯省钱省时间。