搜了半天，结构化数据报错还是没头绪？别急——你不是漏了什么关键步骤，是谷歌那个红色三角警告，本来就不该让你慌成这样。
它不等于网站崩了，也不代表排名马上掉。它只是谷歌在说：“嘿，这页的结构化数据里，有几处我读不太懂。”听懂它在说什么，比赶紧删代码重要十倍。
报错信息到底在说什么？别被红色吓到
结构化数据的报错，其实就两类：错误（Error）和警告（Warning）。
错误必须修。比如“Product”类型漏了price，或者把<script type="application/ld+json">写成了<script type="text/json">——这类问题会导致富媒体摘要彻底消失。
警告可以缓一缓。比如description字段内容太短，或datePublished格式对但没带时区。搜索结果照常出，只是展示效果可能打点折扣。
我帮一个做皮具定制的客户查过类似问题：他用的是 WooCommerce + Rank Math，一直显示“结构化数据有效”，但 Search Console 持续报“缺少 availability”。后来发现，Rank Math 新版默认关掉了库存状态输出，而 WooCommerce 的库存字段又没同步到 JSON-LD 里。补上一行 "availability": "https://schema.org/InStock"，报错当天清零，那个月询盘明显多了。
所以第一步，别截图发群里问“这是啥意思”，直接点开 Search Console 里的报错详情。它会明确告诉你：哪个页面、哪行代码、缺哪个字段。跟着这个定位走，80% 的问题，15 分钟内就能闭环。
5类最常见的结构化数据报错，你中了几个？
干了十年 SEO，经手过上千个站，90% 的结构化数据报错，都落在下面这五类里。你可以现在就打开自己网站的 Search Console 对着看。
第一类：必填字段空着或填了空值
比如“Article”类型要求 headline 和 author，结果你写了 {"headline": ""}，或者 author 直接没写。空字符串 ≠ 有内容。检查 CMS 输出逻辑，确保字段真有值，不是占位符。
第二类：一个页面硬塞多个核心类型
比如同时给同一篇文章标上 Article 和 BlogPosting。这两个类型属性重叠但不完全一致，谷歌会卡住。记住：一页只配一个主类型。需要多层语义？用 @graph 包一层，别并列堆。
第三类：URL 写得不像 URL
常见写法：“/product/123”（缺协议和域名）、“https://example.com/文章”（中文路径未编码）、“https://example.com/ ”（末尾多空格）。复制粘贴时手抖一下，就挂半天。
第四类：字段值类型不对ratingValue 要纯数字，写成 "4.5星" 就废；datePublished 必须是 ISO 8601 格式，比如 "2024-03-15T10:30:00+08:00"，写成 "2024年3月15日" 或 "Mar 15, 2024" 都不行。
第五类：同一页面，结构化数据反复出现
Yoast 输出一份，Schema Pro 又输出一份，再加个手动写的 JSON-LD —— 三份内容还不一致。谷歌不挑食，但怕打架。留一个来源，其他全关掉。
修复报错的时间顺序：先救急再治本
别想着一口气清完所有报错。你的时间很贵，优先处理真正影响用户看到什么的那些。
第一优先级：影响富媒体展示的错误
比如电商页的 price 报错，用户搜索时看不到价格标签；食谱页的 cookTime 错了，搜索结果里时间显示成“NaN 分钟”。这类问题，今天发现，今天改。
第二优先级：高频重复的警告
比如全站文章都提示“缺少 image”或“缺少 description”。单看不痛不痒，但 Google 会把它当信号：这个站的数据质量不稳定。修完后，通常一周内富媒体曝光就有变化。
第三优先级：孤立页面的冷门报错
404 页面、已下线的老活动页、测试用的草稿页……这些页面本身流量趋近于零，结构化数据有没有，几乎不影响任何事。等下次大版本更新时顺手清理就行。
关键动作：每修完一个错，立刻用谷歌的富媒体结果测试工具验证。别等 Search Console 更新——它延迟长，本地测完才踏实。
谷歌测试工具说“有效”却报错？别信它
这是最让人抓狂的情况：工具打绿勾，上线就红标。原因很简单：
测试工具只验语法，不验逻辑。
比如你写了个食谱，cookTime 是 "PT45M"，prepTime 也是 "PT45M"，语法全对。但加起来 90 分钟，谷歌爬虫一看：“等等，这菜要一个半小时准备+烹饪？用户点进来怕不是要报警。”——于是悄悄记个警告，Search Console 里就冒出来了。
再比如 sameAs 字段，你填了三个社交链接，其中一个是 https://twitter.com/xxx，另一个是 https://x.com/xxx（Twitter 已改名），两个指向同一平台但 URL 不同，谷歌会认为数据矛盾。
解决方法就两条：
- 测试工具通过后，人工扫一遍字段值是否合理：数字是不是离谱？日期是不是未来？URL 能不能打开？
- 如果用插件，去它的「高级设置」或「JSON-LD 自定义」页面，确认没有默认覆盖你手写的字段。Rank Math 和 Yoast 都有这类隐藏开关。
插件和手写代码，哪个更不容易报错？
一句话：插件省力但藏坑，手写可控但易漏。
插件的问题在于“不可见”。你点了“启用结构化数据”，它就默默生成一堆 JSON-LD。某次更新后，它突然给每个页面加了 BreadcrumbList，而你主题里已有面包屑微数据，两套并存，直接触发“重复定义”报错。这种问题，得翻更新日志才能发现。
手写 JSON-LD 的问题在于“太自由”。新手常犯的错：忘了加 "@context": "https://schema.org"，或者把 author 写成 "author": "张三"，而不是嵌套成 "author": {"@type": "Person", "name": "张三"}。少一层对象，谷歌就认不出这个人是谁。
实用折中法：用插件生成基础结构，再进 WordPress 后台 →「外观」→「主题编辑器」→ 打开 header.php 或子主题的 functions.php，用 wp_add_inline_script 微调。比如 Rank Math 生成了文章结构，你再补一句 "image": {"@id": "#main-image"}，让图片 caption 也能被识别——不碰插件核心，又拿到控制权。
报错修完就没事了？你需要一个持续监控机制
结构化数据不是“一次配置，永久生效”。CMS 升级、插件更新、内容模板改版、甚至谷歌规范调整，都会悄悄埋雷。
去年谷歌把 Review 类型的 bestRating 从必填改成可选，很多站还按老文档写，结果批量报错。还有一次，他们临时收紧了 logo 字段的尺寸校验逻辑，一批站的站点名称富媒体突然消失，两周后又自动恢复。
我的做法很土，但管用：
- 每月初固定 20 分钟，打开 Search Console →「增强功能」→ 点开每个结构化数据类型，看“错误数”和“警告数”。超过 3 个，当天处理；少于 3 个，记到 Notion 表格里，月底统一扫。
- 订阅 Google Search Central Blog（邮箱推送），有规范变更，他们会直接发提醒。别指望靠朋友圈转发获知。
一个小技巧：如果报错是“被忽略的字段”，比如 videoFrameSize 或 thumbnailUrl，先别急着删。去 schema.org 查最新文档，再搜下谷歌官方博客有没有相关说明。有时候不是你写错了，是谷歌还没全量支持新字段。
今天就能做的3步操作
别收藏吃灰，现在就打开电脑，照着做：
- 打开 Search Console →「增强功能」→ 找到错误数最多的那个类型（比如 Product 或 Article），点进去，选第一个报错 URL，右键复制。
- 打开谷歌富媒体结果测试工具，粘贴刚才的 URL，点“测试 URL”。看红框提示具体哪行、哪个字段出问题，直接在你网站后台改（WordPress 就进「文章编辑页」→「Rank Math/Yoast 设置」→「结构化数据」里补或修）。
- 改完保存，回到测试工具，点“测试更新的 URL”。显示绿色“有效”后，立刻回 Search Console，找到这个页面 →「请求索引」。
做完这三步，最扎眼的那个报错，今天就能从列表里消失。剩下的，明天早上花 10 分钟，继续清。