一个做工业设备的客户找我们改官网，需求听上去很小：产品列表页加一个按功率筛选的功能。他们的技术给出的排期是两周。老板不理解——参数明明白白写在每个产品页上，为什么筛一下要两周。
我们打开他们的后台看了一眼，原因很直接：那些参数不在数据库里，在一段富文本里。
富文本是一个黑箱
绝大多数企业站的产品录入页都长一个样：产品名称、一张主图，然后是一个巨大的富文本编辑器，剩下的所有内容——技术参数、规格表、应用场景、安装说明——一股脑塞进去。
对录入的人来说这很顺手，像写 Word 一样。但对系统来说，这段内容是一整块无法拆分的 HTML。它只知道这里有三千个字符，不知道里面哪个数字是功率、哪个是精度。
于是就有了下面这些症状，你可以对照自查：
- 想按参数筛选产品，技术说要改结构
- 新增一个型号，详情页的参数表要手工重排一遍
- 同一台设备，列表页写 5.5kW、详情页写 5.5 kW、样本册写 5500W
- 客户问有没有 6kW 以上的型号，销售只能自己一页页翻
这四件事看上去分属技术、运营、销售三个部门，其实是同一个原因：产品信息从录入的第一步起，就没有被当成数据对待。
一件产品，应该被拆成几张表
正确的做法并不复杂，只是必须在建站的第一天想清楚。
products，一个产品有很多条的内容单独开表，比如 product_specs 和 product_media，几张表靠 product_id 关联。这样加一条参数、换一张图都不用改主表结构。前端的列表筛选、详情页参数表、站内搜索读的都是同一份数据，后台改一次，所有地方同时变——搜索引擎抓到的、AI 引用的、询盘表单带走的，也就始终是同一份。把这四步拆开说：
第一步，把产品拆成能填、也能查的字段。名称、型号、分类、参数、图片各有各的输入框，而不是一个编辑器包打天下。富文本只留给真正没法结构化的内容，比如产品优势、应用案例这类描述性段落。判断标准很简单：任何你将来可能拿来筛选、排序、对比的信息，都必须是独立字段。
第二步，一对多的内容单独开表。一个产品只有一个值的字段——名称、型号、分类——放进主表。一个产品会有很多条的内容——技术参数、产品图片、下载资料——各自开一张表。参数表里，每一行就是一组「参数名 + 参数值 + 排序」。
第三步，用 product_id 把它们串起来。这一步决定了三年后这个网站还能不能用。加一条参数、换一张图、增加一类下载文档，都只是往子表里添行，主表结构原封不动。而参数塞在富文本里的网站，任何一次结构调整都是全站返工——这就是「加个筛选要两周」的真实成本。
第四步，前端读的是同一份数据。列表页的筛选条件、详情页的参数表、站内搜索的索引，全都来自这几张表。运营在后台改一次功率，三个地方同时变。前面说的「三处数值对不上」，本质上就是在三个地方各维护了一份内容。
真正的分水岭出现在 AI 时代
上面这些道理，过去十年也成立，只是很多企业忍下来了——反正客户主要靠销售跟进，网站不过是一本电子样本册。
现在情况变了。越来越多的采购在动手搜索之前，先问了一句 ChatGPT、DeepSeek 或者豆包：这个领域有哪些供应商，他们的设备参数是多少。
AI 回答这类问题时，抓的就是你网站上的文本。而它能不能准确回答，取决于这些信息以什么形态存在。
结构化的字段，可以通过 Schema.org 的 Product 标记明确告诉机器：这是型号，这是功率，这是价格区间。AI 拿到的是一组带标签的事实，引用时不容易出错。
富文本里的参数，机器只能猜。一段中文里夹着一个 5.5kW，它可能理解成功率，也可能和上下文里的另一个数字混在一起。更常见的结果是——它干脆跳过你，去引用那些信息更清晰的同行。
AI 不会因为你的产品更好就多提你一次，它只会引用它能读懂的那一个。
这也是我们现在做 GEO 改造时，第一件事往往不是改文案、不是加内容，而是回头看后台那几张表。文案写得再好，装在一个机器读不懂的容器里，等于没写。
三个问题，自己去后台查一遍
不用找技术，你自己打开后台就能判断：
- 新增一个产品时，技术参数是填在一个个独立输入框里，还是打在富文本编辑器里？
- 改一个型号的功率，你要改几个地方？
- 打开任意一个产品详情页，右键查看源代码，搜一下有没有
Product这个词？
第一题答「富文本」、第二题答「不止一个地方」、第三题搜不到，说明你的产品数据现在还只是给人看的图文，不是能被检索、被引用的数据。
这件事越早改，成本越低。等产品线从二十个涨到两百个再动手，要迁移的就不只是结构，还有几年积累下来的历史内容。
派迪科技专注于企业官网建设与 GEO 优化。如果你想知道自己的产品页在主流 AI 里被怎么描述，可以把网址发给我们，我们会实际去问一遍。
