JSON-LD里@type写成全路径后，富媒体抓取率从41%爬到78%

上周复盘了一个案例，产品详情页的富媒体结果抓取率卡在41%三周不动。用Rich Results Test跑了一遍，结构化数据本身没报错，但Search Console的「富媒体搜索结果」报告里，Product 类型的有效项只有一半。

拆开看，问题出在 @type 的写法上。我们之前图省事，实体类型直接写 "Product"，上下文靠 @context: "https://schema.org" 兜底。但抓取日志显示，带全路径 "https://schema.org/Product" 的页面，被判定为有效实体的概率明显更高。我做了个A/B：50个页面保持短名，50个改成全路径，其余字段完全冻结。两周后，全路径组的富媒体抓取率78%，短名组43%。

顺手还发现一个坑。offers 里的 price 和 priceCurrency 如果拆成两个独立的 @type: Offer 对象，而不是嵌套在一个 offers 数组里，抓取端会漏掉价格字段。我把嵌套层级压平后重新提交，Product 的 price 识别率从62%到94%。

另外提一句字段顺序。我们页面模板里 @context 放在最后，LCP元素是首屏价格块，JSON-LD脚本在body尾部。有人会问这跟速度有啥关系——其实没关系，但 @context 不在首位时，部分解析器会先做一次预扫描再回填，抓取预算紧的时候这就是额外开销。改成首位后，脚本解析耗时降了大约11ms，样本量小，仅供参考。

现在我的验收口径是：先定义分母，是「提交的URL数」还是「被爬取的URL数」，这两个数在Search Console里差着两成。分母没对齐，抓取率就是个玄学数字。

想问下各位：你们在 @type 上用短名还是全路径，有没有遇到解析器行为不一致的情况？我这边只在Product类型上验证过，其他类型还没跑。