机械设备类官网普遍有一个通病产品中心是一堆图片。型号、参数、工况都写在设计稿里导出的 JPG 上人眼能看机器读不到。结果是用户搜不到型号搜索引擎和 AI 也摘不出任何可用信息。这篇讲把产品参数做成可被检索的结构化数据的完整做法从建模到 Schema都在服务器端完成不依赖前端框架。一、先建模产品、系列、规格不是一张表最常见的建模错误是把产品和规格塞进同一条记录导致一个系列下 20 个型号要维护 20 份重复文案。合理的拆法是三层产品线 (line) —— 例如板式换热器 系列 (series) —— 例如BH 系列 型号 (model) —— 例如BH-200这里才挂具体参数对应的数据结构大致是层级关键字段说明产品线名称、简介、适用行业承接某类产品的搜索意图系列系列名、结构特点、选型要点承接对比型意图型号型号编码、参数键值、工况条件承接精确型号查询参数用键值对存储不要用一整段富文本。富文本无法比较、无法筛选、无法做结构化输出。参数键建议先定一份受控词表温度上限、压力等级、处理量、材质、接口规格……新增型号时从词表里选避免同一个参数出现处理量/产量/产能三种写法。二、URL 与页面模板一个型号一个可寻址页面每个型号都应该有独立、稳定、可被外部引用的 URL/products/bh-series/bh-200.html不要用/product-detail?id1024这类参数式地址可被抓取但对用户和分享都不友好也不要让 20 个型号共用一个页面靠 JS 切换内容——JS 切换的内容不会被单独收录。页面模板里的三块信息最影响收录效果H1 用型号全称不要用产品详情参数表用真正的table或dl而不是图片或纯 div 拼版爬虫对语义标签的解析最稳正文里出现一次型号 关键工况的自然语言描述例如BH-200 适用于 120℃ 以下、处理量 50m³/h 的换热场景这句话是给 AI 摘录用的。三、站内检索先做文本匹配别急着上向量型号数量在几百以内时站内检索用最简单的文本匹配就够了关键是可预期建立一张型号 → 页面 URL的倒排索引新增型号时同步写入匹配时对型号做归一化去空格、统一大小写、全角转半角否则用户搜bh 200就找不到BH-200搜索无结果时给出同系列型号建议而不是空白页。型号上千之后再考虑分词或向量检索此时真正的问题通常不是算法而是参数词表不统一——先把受控词表补全再谈召回率。四、Schema 结构化数据给机器一份明确的声明在型号页输出 Product 类型的 JSON-LD把参数作为additionalProperty挂上去scripttypeapplication/ldjson{context:https://schema.org,type:Product,name:BH-200 板式换热器,sku:BH-200,brand:{type:Brand,name:示例品牌},category:板式换热器,additionalProperty:[{type:PropertyValue,name:最高工作温度,value:120,unitCode:CEL},{type:PropertyValue,name:处理量,value:50,unitText:m³/h}]}/script三点注意只声明页面上真实存在的内容。Schema 与可见文本不一致属于误导性结构化数据会被判为无效单位要带unitCode用 UN/CEFACT 通用代码温度 CEL、质量 KGM比自由文本更稳上线前用校验工具跑一遍Schema 的报错往往在嵌套层级和必填字段肉眼很难发现。除了 Product站点层面还建议补 Organization企业主体和 BreadcrumbList面包屑这三类是企业官网性价比最高的结构化数据。五、上线验收清单每个型号有独立 URL且可被外部直接访问参数为文本表格或键值对不是图片型号检索对空格、大小写、全半角容错型号页有 Product JSON-LD字段与页面内容一致用搜索引擎的富媒体测试工具校验无报错新增一个型号运营人员能在后台独立完成不依赖开发。小结机械设备官网的能被搜到、能被摘录本质是三件事参数存成数据、每个型号有独立地址、结构化声明与页面内容一致。这三件事都不难难的是把它们当成交付标准写进验收清单——否则项目结束时拿到的还只是一堆图片。