一、先确定产品页要表达什么
讨论AI搜索时，结构化数据经常被说成万能入口。它更实际的作用，是把页面上的产品名称、型号和企业等信息按约定格式表达出来。Google没有要求为AI Overviews或AI Mode添加专用Schema；增加标记也不能保证排名提升或被AI引用。
对工厂而言，先写清买家能看到的事实，再让程序提取这些事实。本文假设一家泵厂有P40工业泵详情页，客户需提交介质、流量和工况后询价。这个虚构型号仅用于演示，不能当作现有产品、检测结果或销售案例。
二、询价页和在线购买页，采用不同判断
Google的Product文档区分两类呈现：product snippets适用于不能直接购买的产品页，merchant listings面向可以向商家购买产品的页面。两者字段和资格要求不同。只有询价表单的工厂官网，不能因为放了产品照片，就照搬在线商店的全部配置。
另一个区别是Schema.org词汇可用，不等于符合Google某项富结果要求。基础Product可以准确表达产品；但当前产品摘要要求name，并至少具备review、aggregateRating或offers之一。若没有相应真实资料，应接受暂不具备该富结果资格，而不是凑字段。
三、无公开报价，不把price写成0
P40的成交价取决于材质、密封、数量和交付条件，页面只写“联系获取报价”，就不要自动生成offers.price=0。零元代表免费，不能代替待报价，也不要把后台占位数字、旧报价或其他配置的样品价填进去。模板插件预设的价格同样需要检查。
若确实公开销售标准样品，先明确该页面对应的配置、币种和购买条件，再评估适用的Offer规则。merchant listings要求大于零的价格。需要另行评审的定制整机，与已定价的样品不能共用一个含糊报价；销售应能解释页面价格究竟买到什么。
四、整理一份可交接的产品资料表
先给每个页面建一行记录：正式英文名称、型号、内部SKU、制造商部件号、品牌、详情页地址、主图、用途说明、参数版本、审核人和更新时间。没有的标识留空；SKU是企业自己的库存编号，不能随便复制成GTIN或制造商部件号。
P40还应记录介质适用范围、流量条件和材质选项的资料出处。运营可以整理内容，工程人员负责确认技术边界。若图纸写的是新版接口，网站仍用旧参数，先解决资料冲突。结构化数据只能表达已经核实并在页面呈现的内容，不能替代工程审核。字段旁注明原始文件和负责人，下一位接手者就能找到确认依据。
五、按可见内容映射字段
name对应页面产品名称，description概括实际用途，image对应本型号的清晰图片，url指向该详情页。brand填真实品牌；sku、mpn各按资料表映射，不把所有编号都写成型号。图片地址应公开可访问，不能引用需要登录的网盘预览链接。开发最好从同一条产品记录生成正文与标记，减少人工复制后产生差异。
泵的扬程、材质等额外特性，可在符合Schema词汇定义时考虑additionalProperty，并保留单位和条件；这些字段不等于Google承诺展示的搜索元素。运营验收时逐项反查：每个输出值都能在正文或参数区找到依据，不能只在隐藏标记里出现。
六、分类、型号与变体不要混在一起
“工业泵产品中心”列出多个系列，不是一个特定产品。产品富结果支持聚焦单一产品或同一产品变体的页面，因此优先处理P40这样的详情页，不把整个分类页硬标成一个Product，再把所有系列的优点和价格拼进去。
对于不锈钢和铸铁等配置，先确认它们是同一产品的明确变体，还是独立型号。页面、选项、图片和标记必须对应；切换后不能仍显示另一个配置的编号。需要复杂变体关系时，由开发按官方变体文档实施，不能把一组不同配置简单包装成多商家报价。
七、把企业身份与产品评价分开
企业名称、官网、标志、地址和联系方式可以用Organization表达。Google建议放在首页或介绍企业的单一页面，不要求全站重复。先统一英文品牌名与注册名称的使用方式，海外销售办公室也不要误写成制造工厂地址。
客户感谢邮件、合作伙伴标志和工厂自评，不能直接变成P40的五星产品评分。没有真实、适用且符合评价规则的内容，就不输出review或aggregateRating。项目内部可以把“评价资料尚未具备”列成状态，避免运营为了消除工具提示临时编一个评分。
八、分三层测试，再小范围上线
开发可使用JSON-LD输出，先检查语法与字段类型，再用Schema Markup Validator核对词汇；接着用Google Rich Results Test检查其支持的富结果要求。基础Product没有满足产品摘要必填项时，工具可能报告相关错误，这与JSON本身是否合规是两个问题。
第三层是人工对照真实页面：名称、配置、图片、报价和企业关系是否准确，移动端是否同样看得到。先挑代表性询价型号测试；网站确有可直接购买的型号时，再增加该类页面，而后推广模板。上线后通过Search Console网址检查确认Google实际看到的内容，别只验收开发环境截图。
测试时也安排边界样本：缺失主图、名称含引号、旧型号停用、没有品牌资料。检查系统能否安全处理缺项，而不是自动补一个默认品牌或价格。运营提交页面地址和对应资料版本，开发返回检测结果与处理说明，让验收人员可以复查同一个页面。
九、型号更新时，让页面和标记一起更新
把责任写进发布流程：工程批准参数，销售确认公开的报价条件，运营更新正文和图片，开发维护字段映射。P40修改密封方案时，在同一任务里检查参数区、下载图纸、图片说明与JSON-LD，不能网站正文更新了，隐藏数据还沿用旧版。
记录每次修改涉及的型号、页面、资料版本和测试结果。模板或插件升级后，抽查常规型号、未公开价格的型号和变体页面，检查是否重复输出两个相互矛盾的Product。存在异常时，先移除错误标记并修复事实，不让不准确的数据继续批量扩散。
另外保留一份例外清单，区分暂缺工程资料、产品不适用和富结果必填项尚未满足。前两类找业务负责人处理，最后一类根据真实经营方式决定是否继续投入。不能把每一条工具提示都当成必须购买插件、补写内容或承诺展示效果的理由。下一次型号更新时，重新核查这些例外的处理状态。
十、验收看事实一致，复盘看实际询盘
交付清单应写明：页面类型判断、可见事实对应表、未采用字段的原因、测试记录和维护负责人。正确标记也不保证Google展示富结果，因此不能把“搜索中必须出现星级价格”写成询价站的验收承诺；Search Console报告也需要结合实际抓取进度观察。
后续仍要看买家是否理解型号、是否提交了可用于选型的工况、销售是否减少重复澄清。这些结果需要真实数据和同一口径的观察，不能归功于一段Schema代码。先把产品资料维护准确，再持续改善搜索呈现和询盘路径，才是工厂能够长期执行的工作。