工业产品常常按配置报价，页面只写联系询价。制作结构化数据时，却有人为了填满表单写一个零元价格，或沿用模板中的示例售价。这会让机器读取的信息与客户真正能看到的报价方式矛盾。
先把一款产品的信息核对完整
XunL Product JSON-LD生成器接受商品名称、URL、图片、说明、SKU与品牌等字段。先选一款实际页面，把这些资料逐项对应，不要从另一型号复制后只换名称。
例如教学产品“桌面支架A型”，SKU可以示意为STAND-A，商品地址应指向它自己的详情页，图片也应是该型号。这里的名称与SKU只是填表演示，正式发布必须改成真实资料。品牌应使用页面实际展示的品牌，不能为迎合搜索随意替换。
什么时候填Offer，什么时候保留基本Product
如果页面有明确公开售价，就进一步核对货币代码、价格和库存。缺货、预售与有货表达的业务条件不同，不能始终保留示例默认值。价格变动时，页面正文和标记都需要同步。
若属于配置询价产品，可清空价格生成基本Product，不必为了获得某种展示填一个估算金额。零元也不是“暂无价格”的通用写法，搜索读取者可能把它当作真实售价。是否满足某些富结果要求，应服从真实数据，而不是反过来捏造数据满足字段。
同样，没有公开真实评价就不要添加五星。评分必须有真实依据并与页面可见内容一致，工具生成代码不提供评价证明，更不能替你核实认证、客户和库存。
生成后分三层验证
第一层是语法与字段内容，检查引号、类型和是否残留示例。第二层是schema词汇与关系，可用Schema.org Validator等工具核查。第三层是目标搜索展示的要求，使用相应官方测试并理解其政策。
通过其中一层，不代表其他层自动通过，更不意味着必定显示商品富结果。最后仍要打开真实页面，把名称、型号、图片、说明及有价时的Offer逐项对照，确认机器内容没有比可见正文多出未经支持的说法。
图片地址应可公开取得，不能指向后台附件预览。若CDN替换图片或产品更新外观，也要检查标记是否仍引用旧素材。对于多型号系列，近似图片容易误配，应在数据表中给每个SKU保留自己的图片关系。
批量做之前，先用一页发现映射错误
如果商品需要按数量、地区或配置报价，说明应准确反映这种询价方式。不要将一个历史样单价格当成当前所有客户适用的公开报价，结构化字段与销售条件必须保持相同口径。
可以先完成一个询价产品和一个有公开价格产品的样本，核对字段映射，再扩展到其他页面。把共享品牌与逐型号字段分开管理，避免所有产品都输出同一个SKU、同一个库存状态或示例价格。
模板更新后仍需抽样读回公开代码，尤其要检查主题或SEO插件是否已生成另一份Product。多套来源同时输出矛盾信息，不能靠再加一段JSON-LD解决，应先确定哪套负责维护。
不写价格，结构化数据还有价值吗？
基本产品信息仍可用于解释页面，但可能不符合部分要求Offer的展示条件。应接受真实资料带来的边界，不通过虚构价格换取表面完整。
验证没有错误，就不用再管了吗？
还要持续同步内容变化。验证不替你维护价格和库存，也不保证展示。把标记检查放进产品更新流程，才不容易在几个月后与正文脱节。
个人微信：ssevening
