企业官网建设流程全解析

机械设备类官网普遍有一个通病：产品中心是一堆图片。型号、参数、工况都写在设计稿里导出的 JPG 上，人眼能看，机器读不到。结果是用户搜不到型号，搜索引擎和 AI 也摘不出任何可用信息。

这篇讲把产品参数做成"可被检索的结构化数据"的完整做法，从建模到 Schema，都在服务器端完成，不依赖前端框架。

一、先建模：产品、系列、规格不是一张表

最常见的建模错误是把"产品"和"规格"塞进同一条记录，导致一个系列下 20 个型号要维护 20 份重复文案。合理的拆法是三层：

产品线 (line) —— 例如"板式换热器" 系列 (series) —— 例如"BH 系列" 型号 (model) —— 例如"BH-200"，这里才挂具体参数

对应的数据结构大致是：

参数用键值对存储，不要用一整段富文本。富文本无法比较、无法筛选、无法做结构化输出。参数键建议先定一份受控词表（温度上限、压力等级、处理量、材质、接口规格……），新增型号时从词表里选，避免同一个参数出现"处理量/产量/产能"三种写法。

二、URL 与页面模板：一个型号一个可寻址页面

每个型号都应该有独立、稳定、可被外部引用的 URL：

/products/bh-series/bh-200.html

不要用/product-detail?id=1024这类参数式地址（可被抓取但对用户和分享都不友好），也不要让 20 个型号共用一个页面靠 JS 切换内容——JS 切换的内容不会被单独收录。

页面模板里的三块信息最影响收录效果：

1. H1 用型号全称，不要用"产品详情"；
2. 参数表用真正的<table>或<dl>，而不是图片或纯 div 拼版；爬虫对语义标签的解析最稳；
3. 正文里出现一次型号 + 关键工况的自然语言描述，例如"BH-200 适用于 120℃ 以下、处理量 50m³/h 的换热场景"，这句话是给 AI 摘录用的。

三、站内检索：先做文本匹配，别急着上向量

型号数量在几百以内时，站内检索用最简单的文本匹配就够了，关键是可预期：

• 建立一张"型号 → 页面 URL"的倒排索引，新增型号时同步写入；
• 匹配时对型号做归一化（去空格、统一大小写、全角转半角），否则用户搜"bh 200"就找不到BH-200；
• 搜索无结果时，给出同系列型号建议，而不是空白页。

型号上千之后再考虑分词或向量检索，此时真正的问题通常不是算法，而是参数词表不统一——先把受控词表补全，再谈召回率。

四、Schema 结构化数据：给机器一份明确的声明

在型号页输出 Product 类型的 JSON-LD，把参数作为additionalProperty挂上去：

<scripttype="application/ld+json">{"@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>

三点注意：

1. 只声明页面上真实存在的内容。Schema 与可见文本不一致，属于误导性结构化数据，会被判为无效；
2. 单位要带，unitCode用 UN/CEFACT 通用代码（温度 CEL、质量 KGM）比自由文本更稳；
3. 上线前用校验工具跑一遍，Schema 的报错往往在嵌套层级和必填字段，肉眼很难发现。

除了 Product，站点层面还建议补 Organization（企业主体）和 BreadcrumbList（面包屑），这三类是企业官网性价比最高的结构化数据。

五、上线验收清单

• 每个型号有独立 URL，且可被外部直接访问；
• 参数为文本（表格或键值对），不是图片；
• 型号检索对空格、大小写、全半角容错；
• 型号页有 Product JSON-LD，字段与页面内容一致；
• 用搜索引擎的富媒体测试工具校验，无报错；
• 新增一个型号，运营人员能在后台独立完成，不依赖开发。

小结

机械设备官网的"能被搜到、能被摘录"，本质是三件事：参数存成数据、每个型号有独立地址、结构化声明与页面内容一致。这三件事都不难，难的是把它们当成交付标准写进验收清单——否则项目结束时拿到的还只是一堆图片。