商品页模板的 GEO 组件库

周一下午，一家做家用咖啡机的出海团队在两个市场同时调价。运营在 Perplexity 里问“千元价位、能打奶泡的半自动咖啡机怎么选”，答案里他们的型号排第四，参数栏写着“规格详见商品页”。技术打开源码，泵压、粉碗直径都在——写在一个可复用的富文本组件里，模板改版时被折进了“了解更多”，德国站那份还是两年前从英语站复制过来的插头说明。

商品页的 GEO 不是把一页改好，而是把答案拆成有字段、有顺序、有折叠规则的组件，让模板替每个 SKU 说同一套能被摘录的话。

组件库决定事实落在哪个字段

抽取器读的是 DOM 里的块，块的边界来自标签，也来自组件。设计系统里，组件是唯一同时决定视觉边界和源码边界的地方：一条规格如果长在表格的一行里，它在屏幕上是一行，在源码里也是一对键值；如果长在富文本里，屏幕上仍是一行，源码里只是三百字中的一句。

这就是单页改造撑不过两百个 SKU 的原因。运营改得动一页，改不动两千页；模板里的一个字段却会替所有页面说话。组件库的价值不在“统一视觉”，而在把同一个错误也只犯一次——这句话反过来同样成立，一个写错的固定单位会被复制到全站。

判断标准只有一条：关掉 CSS、关掉 JS、换一个语言版本，字段还成对出现。三个条件里任一条不成立，说明这条事实还没有槽位，只住在一段文案里。

六个组件，每个只回答一类问题

六个组件足以覆盖大多数商品页，多出来的组件通常是同一个问题的变体。

组件	回答哪个问题	必填字段与来源	顺序与折叠
答案块	这是什么、给谁、凭什么	品类、场景、3–5 个硬规格、一条差异；PIM 拼装，运营只写差异句	首屏第一段，不折叠
规格表	能不能满足我的条件	键值对、单位、测试条件；来自 PIM 与检测报告	首屏之后，默认展开
对比块	和上一档差在哪	同口径字段、明确的对手型号	规格表之后，可折叠
评价块	别人用得怎样	评分、样本量、场景标签、差评摘要；来自评论系统	中段，默认展开
物流与退货	多久到、能不能退	市场级时效、运费、退货窗口与条件；来自履约配置	价格附近，可折叠
兼容与边界	什么情况不适用	不适用清单、兼容型号、认证	末段，不折叠

顺序不是设计偏好，是买家判断的顺序：先能不能用，再好不好用，最后才信不信。折叠本身没有错，错的是“折叠后消失”——用 details/summary，或者默认渲染后再用 CSS 隐藏，内容仍在 DOM 里；点击才请求的组件，对抽取等于不存在。这条要写进组件规范，不是写在设计说明里。

多语言与多市场：组件复用，证据重取

同一套组件进到第二个市场，会立刻暴露一件事：字段可以复用，证据不能。

电压与插头、认证（CE、FCC、PSE 各管一段）、保修期、退货窗口、计量单位，这些不是翻译问题，是本地事实问题。把英语站的退货窗口直接机翻到德语，得到的是一条错误承诺，而错误承诺比信息缺失更容易被引用。

多语言版本还要各自有可抓取的 URL 和正确的 hreflang，否则模型分不清哪个价格属于哪个市场。字段层面把数值和单位分开存，展示时再拼；型号与认证编号不要进机器翻译队列，它们在德语里也不该变成德语。

五步落地：先盘事实，再定槽位

组件库的落地顺序和写一篇文章相反：先盘事实，再定槽位，最后才谈样式。

步骤	做什么	谁来做	怎么算过
1 盘事实	取 20 个 SKU 页，把买家问题逐条列出，标出每条事实现在住在哪个字段	内容 + 品类运营	每条都能指到一个组件，指不出的单独成表
2 定槽位	六个组件定字段、类型、必填与来源系统	前端 + 主数据	每个字段有 owner，缺失时显示“待补”而非自动隐藏
3 定顺序与折叠	按判断顺序排，折叠内容留在 DOM	设计 + 前端	关 CSS 后纯文本仍成对，折叠块仍可读
4 做回归	固定 20 个问题 × 20 个 SKU 跑一遍，比对答案里的值与页面值	增长 + 工程	错值能追到具体组件与字段
5 上治理	组件变更走评审，字段缺失进周报	产品	三个月内没有新增自由填写的规格区

第 1 步最容易被跳过，因为它不出设计稿。团队常从设计稿开始排组件，排出来的是一套视觉系统，不是一套事实系统。第 5 步决定这套库能活多久：没有 owner 的组件库，半年后一定长出第二个富文本。

先改哪些 SKU 不按销量排，按“事实缺失最严重、又被问得最多”排，排序方法见先写哪一页；字段在源码里成不成对，见语义 HTML 与段落边界。

示例：一个咖啡机模板的六组件改造

示例：某家用咖啡机品牌（假设场景，不含真实品牌与数据），两个市场、约 60 个 SKU。原模板有四十多个视觉组件，答案相关的事实散在富文本、图片规格表和一篇 FAQ 里，每个市场各写一份。

改法是把六个组件固定成 12 个必填字段：答案块由 PIM 的品类、泵压、粉碗尺寸和适用场景拼成一句，运营只补差异句；规格表的数值与单位分开存，测试条件写在同一行；对比块只与同价位的两个公开型号比，并把型号写在页面上；评价块加场景标签与差评摘要；物流退货按市场取配置；兼容与边界列出不适用机型与插头标准。

验收不看排名看三件事：关 JS 取源码，六个组件是否都在；同一批问题复测，答案里的数值有没有和页面打架；德语站的答案引用的是德语页还是英语页。前两项过不了，先别开第三个市场。

边界：什么时候别做组件库

第一，页面少、SKU 少。五十个页面以内，逐页改比建库快，治理成本会超过收益。

第二，成交集中在平台内。亚马逊、Shopee 的详情页模板不由你控制，先把属性字段和 feed 修好。

第三，主数据本身不稳。组件会把“待补”复制到全站，也会把一个错误单位复制到全站，上库之前先统一品类与单位。

第四，配置型商品。价格、尺寸、配件随配置变化，组件要按配置渲染，不能只留一个单值字段；强定制品类先解决“可选范围 + 起价”，再谈复用。

第五，组织里没有组件 owner。没人对字段负责时，库会退化成第二个富文本，只是多了一层样式。

组件库是规模化手段，不是起点。它放大的东西取决于你先放进去什么：把答案单元放进模板，得到全站可摘录；把营销话术放进模板，得到全站不可摘录。答案单元的四段结构怎么写成句子，见答案单元：一段话让 AI 说清你卖什么；组件库有没有真的放大，看的不是一个页面的引用，而是能被 AI 认出的 SKU 比例，口径见实体覆盖率；这条线上其他文章在技术底座主题页。

先做一件事：取销量前 20 的 SKU，把商品页上的事实列成一张 12 行的表，逐行标出它现在住在哪个组件、哪个字段；标不出来的那些行，就是下个月要新建的第一个组件。