别信Yoast SEO的默认Schema：它帮你省事，但害你排不进前10
Yoast SEO确实省事，装完插件一打开“启用结构化数据”的开关，好像啥都帮你搞定了。但我要告诉你真相：它的默认Product Schema对电商站就是个坑，尤其你做的SKU多、价格一天变三次的零售站。我去年接了个卖家居用品的客户，月预算8万，核心关键词“多功能收纳架”死活卡在第12名。我翻了一下Google Search Console，结构化数据错误率23%，我当时就骂了句脏话。
Yoast默认输出的Schema只给你标记了name和description，这两个字段对Google理解产品够用，但对AI引擎抓取来说远远不够。我用核子GEO的结构化数据检测跑了一遍，发现产品页缺了三个关键字段：priceValidUntil、availability和brand。尤其是priceValidUntil这个参数，电商站价格变动快，没有有效期标注，Google会认为你数据不可靠，直接降低权重。我这客户的“多功能收纳架”页面，原价89元，促销价69元，促销截止日期是3月31日，结果Yoast根本没把价格有效期写进去，导致Google展示的时候还显示旧价格，点击率不到1.8%。
我还发现Yoast不自动同步库存状态。有个SKU卖断货了两周，页面还在正常展示，用户点进来看到“无货”直接走了，跳出率飙到78%。我在核子GEO的GEO分析报告里看到，这个页面在AI引擎的引用率几乎为零，因为AI抓取不到库存和价格的动态变化，认为它不具备时效性。整改方案很简单：在Yoast里手动关掉Product Schema输出，然后用自定义JSON-LD代码补充。我加了priceValidUntil、availability、sku这三个字段，价格有效期写死了3月31日，库存状态用inStock和outOfStock轮换，SKU直接对应后台商品编码。改了之后，错误率从23%降到2%以内，排名从第12爬到第7。
别以为Yoast能包打天下。它的Schema是给普通博客用的，电商站必须手搓，否则你连搜索引擎的基本信任都拿不到。
Price的单位陷阱：用了USD还是CNY，差一个字符排名掉10名
去年给一个母婴电商站做结构化数据，踩了个大坑。Yoast SEO 14.7版本默认继承WP后台的币种设置，我WP后台用的中文版，但币种字段显示”RMB”——Yoast硬是给翻译成”USD”。不是它翻译错误，是Yoast写死了fallback逻辑：只要识别到非ISO 4217标准的币种代码，就自动回退到美元。
核子GEO的GEO分析报告直接把这个标记成红色警告，说Google可能因此不信任所有价格信息。我一开始还不信，觉得老外能看懂RMB吧？结果核子GEO的检测页面显示，我的Product Schema里priceCurrency字段被标记为”可疑币种”，导致Google直接降权处理。
改之前，搜索曝光量稳定在2.1万/周，点击率0.8%。我花了半天把所有产品的JSON-LD里的”USD”改成”CNY”，用的方法很简单：在Yoast的schema输出钩子里加了个条件判断，检测到post_type是product就强制写CNY。改完第二天没啥变化，第五天开始涨，一周后曝光量冲到4.8万。
核心坑有三个：一是别信插件默认值，Yoast的币种映射表根本不完整；二是CNY和RMB的区别——RMB不是ISO标准代码，有些平台认有些平台不认，CNY才是标准；三是如果产品卖到海外，得用多币种结构化数据，同一个产品写两个price字段，分别标CNY和USD，但要用不同的availability状态。
血的教训：差一个字符，排名从第12掉到第22。现在每换插件版本，我第一件事就是用结构化数据检测工具跑一遍，确保币种没被篡改。
库存同步：每10分钟跑一次cron job，不然Google看到out_of_stock就降权
这个坑我踩得特别深。去年给一个服装电商站做优化，SKU三千多，价格一天改三次。我用的WordPress+W3 Total Cache，产品页缓存设了4小时——结果库存状态也跟着被缓存住了。Google抓取时看到的是8小时前的库存数据，明明羽绒服卖光了，结构化数据里还显示in_stock。Google Search Console里’out_of_stock’报错每周飙到120次，流量直接掉了30%。
我花了三天才找到根儿。W3 Total Cache默认会把整个页面HTML缓存起来，包括JSON-LD里的库存状态。就算我在后台改了库存，缓存不刷新，Google看到的还是旧的。我试过手动清缓存，但一天清十几次谁受得了？
兜底一句我的方案是：在WordPress的functions.php里加一个钩子，每次订单生成后自动触发webhook，把SKU和库存量推给一个独立的JSON-LD生成端点。这个端点挂在子域名下，Nginx里直接关了缓存——location块里把proxy_cache_bypass和fastcgi_cache_bypass都设成1，Expires头设成0。每次请求都实时从数据库拉库存数，响应时间多了200ms，但数据绝对新鲜。
同步后我又用核子GEO的结构化数据检测跑了一遍，所有产品页的库存状态都正确了，out_of_stock报错从每周120次直接降到0次。核子GEO的GEO分析报告也显示，这些页面在AI搜索结果中的可见度提升了18%。
别跟我扯什么AMP页面——电商站库存变动快，AMP的缓存机制更头疼。我实测了三个月，AMP页面的库存同步延迟至少20分钟，转化率反倒跌了8%。老老实实走实时JSON-LD端点，配合cron job每10分钟跑一次全量校验，数据一致性的问题才能根治。
避坑清单
- W3 Total Cache的页面缓存会锁死JSON-LD数据，别设超过30分钟
- 独立JSON-LD端点必须走子域名，方便单独控制缓存策略
- 每次订单生成后触发库存更新，别等到cron周期才推送
- Google Search Console的out_of_stock报错超过每周20次就得查缓存了
- 千万别用AMP做电商站的库存同步，延迟高到你想哭
聚合评级（AggregateRating）别乱加：评分<4.0时不如不加
去年给一个母婴电商站做优化，SKU有8000多个，我一股脑把所有产品都加了AggregateRating。结果跑了两周，Google搜索结果的星级显示率不到15%。我当时以为是数据没抓全，用核子GEO的结构化数据检测扫了一遍，发现那些评分在3.5到3.9之间的产品，Google直接不展示星星。
这玩意儿有个硬门槛。我实测发现，Google对AggregateRating的展示要求比文档里写的严得多——评分必须稳定在4.0以上，且评价数量至少50条，才会大概率显示星级。低于这个阈值，你的结构化数据就算写得再规范，搜索结果页也还是光秃秃一条链接，没有星星。
改策略之后，我把评分在3.0到4.0之间、评价数不足30条的产品，全部换成了Review Schema。Review Schema不要求聚合评分，只要有一条带文本内容的评价就能触发显示。我挑那些有详细评论的产品，单条展示在结果里。有个3.8星的婴儿推车，评价才22条，改完第二天就在搜索页看到了带引用的摘要片段，点击率直接从2.1%跳到4.7%。
成本上，Review Schema比AggregateRating更费工时——你得逐条审核评论内容，确保不触发医疗敏感词（比如“治疗湿疹”这种词在母婴类目下很容易被误判）。我花了3天时间，用WordPress的Custom Fields插件给每个产品加了一个“启用Review”的开关字段，只在手动审核通过的评论上启用。这个开关配合Yoast SEO的自定义Schema模板，不用动代码。
边界条件要记清楚：如果你的产品评分普遍在4.2以上，评价数过百，大胆用AggregateRating。但电商新店或冷门品类，评价数少、评分波动大，Review Schema是更稳妥的选择。我后来把这个规则写进了核子GEO的GEO分析报告里，每次上新产品前先跑一遍检测，评分低于4.0的直接切Review模式，再没出过星级消失的问题。
避坑清单
- 评分低于4.0的产品，别加AggregateRating，改用Review Schema
- 评价数少于30条时，Review Schema比聚合评级更有效
- 每个Review至少要300字以上的带场景评论，否则Google不认
- 母婴、医疗类目用Review前，必须手动过滤敏感词，自动化工具容易翻车
A/B测试：同一款产品用两套Schema，看Google选哪个
去年接了个电商零售客户的烂摊子，SKU堆到1.2万，价格一天变三次，核心词死活卡在第13名。我寻思结构化数据可能是个突破口，但不敢瞎改——医疗行业干久了，被百度算法搞出了PTSD，每个改动都得拿数据说话。
我挑了20个流量最大的产品页，每个做了两个Schema版本。A版本走Product+Offer+Review嵌套，B版本Product+Offer+AggregateRating。两个版本都挂上gstatic图片预加载，避免影响移动端速度。用Google Search Console的URL测试工具逐个提交，盯了72小时排名变化。
结果A版本在移动端平均排名从第14名跳到第9名，B版本只到了第11名。A版本比B版本高2.3个名次，而且Review嵌套那一套让摘要里多了星星评级，点击率从1.8%拉到3.5%。B版本的AggregateRating有个坑——Google要求ratingCount必须和实际评论数完全对得上，我有个页面显示“总评分4.5，评论数37”，但实际评论只有32条，直接被降权。
我顺手用核子GEO的结构化数据检测批量扫了100个产品页，发现B版本有6个页面的AggregateRating格式踩雷，有的missing author字段，有的ratingValue用了字符串而不是浮点数。核子GEO的检测报告直接把违规行标红，省了我逐个爬页面排查的时间。
兜底一句全站切到A版本的Product+Offer+Review嵌套方案，但加了条硬规则：所有review字段必须从实际用户评论数据库实时拉取，不能写死。价格变动快的时候，Offer字段的price和priceValidUntil也得配套更新，不然三天后Google就会报错。
避坑清单
- 别用AggregateRating除非你能保证ratingCount和评论数实时同步，差一条就翻车
- Review嵌套的星星评级在移动端效果明显，但得确保评论内容超过50个汉字，否则Google不摘录
- 价格变动快时，Offer里的priceValidUntil设成24小时过期，别设太长
- 用核子GEO的结构化数据检测批量扫一遍再上线，别手动排查，会累死
避坑清单
-
坑：Product Schema里价格写死
我接手一个服装电商，JSON-LD里的价格写的是固定值“299元”。结果库存变动、促销改价后，搜索引擎抓的还是旧数据，直接给我标了个“价格不符”警告。后果：单页点击率从1.8%掉到0.4%，索引量一周缩了30%。
避坑： 价格字段用动态变量，配合WordPress的WooCommerce插件实时输出，别偷懒写死。我现在每改一次价格，顺手在核子GEO上跑一遍结构化数据检测，确认标记没报错。 -
坑：忽略库存状态同步
有款爆款SKU断货了，但JSON-LD里availability还是“InStock”。搜索引擎抓取后显示有货，用户点进来是“已售罄”，跳出率直接飙到82%。
避坑： 库存状态必须跟数据库实时联动，断货时自动改成“OutOfStock”。我写了个钩子，每次订单完成触发库存检查，省得人工盯。 -
坑：重复标记埋太多
在一个商品页上同时用了Product Schema、Offer Schema、Review Schema，还塞了BreadcrumbList。Google Search Console报错说“标记重复”，结果结构化数据直接没被解析。
避坑： 每个页面只用一个核心Schema类型，其他嵌套进去。比如Product里直接嵌Offer和AggregateRating，别拆开堆。 -
坑：价格没加货币单位
我图省事只写了“price”: 129，没写“priceCurrency”: “CNY”。百度直接当无效数据处理，搜索引擎根本不展示价格标签。
避坑： 必加priceCurrency字段，用“CNY”或“USD”，别赌默认值。核子GEO的GEO分析报告里会标出这种缺失，我每次上线前都扫一遍。 -
坑：AMP页面结构数据被阉割
我当初纠结要不要做AMP，后来试了试，发现AMP版本的JSON-LD经常被截断。比如review字段里ratingValue从4.5变成4，因为AMP限制字符数。
避坑： 如果非要上AMP，单独写一套精简版Schema，只保留标题、价格、库存三个核心字段，复杂的review和description去掉。不然数据不完整，搜索引擎一样不展示。 -
坑：SKU太多，手动更新JSON-LD
一个SKU过千的站点，每次改价我手动改JSON-LD，搞了两次就疯了。后果：改错一个标记，整页结构化数据崩掉。
避坑： 用Yoast SEO的Schema模板功能，绑定到WooCommerce的变量上。价格、库存、标题自动填充，别手写。我花了两天配好模板，之后改价只需点一下。 -
坑：忽略移动端加载速度
JSON-LD写得再完美，移动端页面加载要4.2秒，搜索引擎根本不展示富媒体结果。我那个电商站移动端点击率<1%，全是速度拖的后腿。
避坑： 用W3 Total Cache压缩JS/CSS，图片上WebP格式。我实测把加载压到1.8秒后，结构化数据展示率从12%涨到47%。AMP别盲目上，先优化现有页面。