Shopi8 原创中文封面:Shopify 商品分类先按主功能,再分开 product type、集合和属性

Shopify 商品分类怎么设,AI 才不容易把商品归错类

摘要

把商品主功能、Shopify 标准分类、内部 product type、集合用途和属性字段分开,让页面与商品数据更容易被核对。

很多 Shopify 店铺的商品资料并不少,AI 搜索却会把商品归到不太对的场景里:把亚麻衬衫当成“度假风单品”,把面部精华当成高光,把壁挂收纳架当成装饰品。问题不一定是商品页没有写内容,也可能是商品分类、product type、标签、集合和属性字段各自表达了不同意思。

先给结论:先用一句话确定商品的主功能,再把标准分类、店铺自有的 product type、集合用途和商品属性分开。分类回答“它是什么”,集合回答“它适合放在哪个购物路径”,属性回答“它有什么条件”。这样 Shopify 后台、公开页面和商品渠道的数据才有机会给出同一答案。本文用服装、美妆、家居和数字产品四个样例说明怎么判断和修改。

先给结论:分类先写主功能,用途不要塞进分类

Shopify 商品分类从主功能到标准分类、product type、集合属性和渠道复查的四层判断顺序
主功能定分类,用途进集合,差异放属性,最后检查页面和渠道。

如果一个商品只能用“夏日必备”“专业款”“高端生活方式”来描述,AI 和用户都缺少稳定的商品名词。先问一句:这个商品交付给用户的主要对象是什么,它解决的核心任务是什么?答案通常应该是衬衫、面部精华、收纳架或模板包,而不是季节、风格或人群。

字段层 主要回答 适合放什么 不适合放什么
Shopify product category 商品属于哪个标准类别 主功能和商品形态 季节、活动、人群口号
Shopify product type 店铺内部如何分层 稳定的自有分类路径 一次活动名或临时卖点
Collection / 标签 用户从哪条路径找到它 场景、风格、系列、筛选条件 唯一的商品主身份
Category metafield 这个类别有哪些属性 尺寸、材质、成分、兼容范围 没有依据的评价或泛化承诺
商品渠道字段 外部渠道如何读取和组织商品 标准分类和自定义路径映射 用 feed 掩盖网站实际错误

背景解释:为什么几个“分类”会互相打架

Shopify 的 product category 是标准化分类,Shopify 的 product type 则是商家自己的分类字段。标签可以给商品添加多个维度,集合页也可以按条件把商品放进不同购物路径。它们不是同一个字段的不同写法,维护时也不应该全部写成同一个营销词。

商品分类选得更接近主功能后,Shopify 可能提供更相关的类别属性字段。比如服装需要尺寸、材质或版型,数字产品需要格式、兼容范围和授权条件。属性字段的价值在于补充“这个商品有什么特征”,而不是重新定义商品是什么。

Google Merchant Center 还区分自定义的 product type 和标准的 google_product_category。自定义路径适合表达店铺自己的层级,标准分类用于对齐 Google 的分类体系。两者都不能替代落地页本身的商品名称、描述、价格、库存和使用条件。若 feed 说是一类商品,页面标题和规格却指向另一类,外部渠道和用户都会遇到不一致。

Google 关于 AI features 的说明没有要求商家另做一套“AI 分类标签”。基础要求仍然是页面可抓取、重要信息以文本存在、链接关系清楚,结构化数据与可见内容一致。因此,分类调整应该先解决商品事实和页面理解,不要先堆一套只给 AI 看的词。

具体例子:4 类商品如何判断分类是否写错

下面都是模拟排查样例。每个例子都按“原始问题 → 判断过程 → 改法 → Shopify 落点”展开。分类名称要以店铺实际商品、Shopify 可选分类和渠道要求为准,示例中的字段只是页面写法参考。

例子 1:亚麻衬衫被写成“度假款”

原始问题:服装店把一件女士亚麻长袖衬衫的 product type 写成“Summer Vacation”,标签是 `beach`、`resort`、`new arrival`,集合页标题也只写“度假衣橱”。AI 搜索在回答“适合通勤的亚麻上衣”时,可能找不到它,或者只把它描述成旅行穿搭。

判断过程:先看商品的主要交付对象和穿着形式。它是一件可单独穿着的上衣,衣领、袖长、面料和尺码比“度假”更能确定商品身份。通勤、旅行、夏季都属于使用场景,可以保留,但不应该替代服装类别。

改法:把 Shopify product category 选到与衬衫或上衣最接近的具体标准节点,product type 改成店铺稳定的“女装 / 上衣 / 亚麻衬衫”路径。把 `通勤`、`度假`、`亚麻`分别放到集合或筛选维度,商品页首段直接写“女士亚麻长袖衬衫”,再补面料、版型、袖长、尺码和护理方式。

Shopify 落点:后台的商品分类和 product type 负责身份;category metafield 或自定义 metafield 保存面料、版型和袖长;“通勤上衣”“度假穿搭”做集合;商品页和尺码 FAQ 负责解释适合场景。这样同一件商品可以出现在多个集合里,但主分类不会随活动变化。

例子 2:面部精华被写成“夏日光泽”

原始问题:美妆店把一瓶透明质地的面部精华放在“夏日光泽”集合,product type 写成“Glow Essentials”,商品描述大量使用“提亮、发光、镜面感”。用户问“适合油皮的面部精华有哪些”时,页面容易和高光、妆前产品混在一起。

判断过程:先确认它是护肤品还是彩妆,使用位置是面部皮肤还是妆面,产品形态是精华、乳液还是油。再检查是否有完整的成分、使用方法、香味和注意事项。功效表达要回到标签和合规文案,不能用“光泽”这个视觉结果代替产品类别。

改法:把标准分类选到与面部精华最接近的具体节点,product type 用“护肤 / 面部 / 精华”这类稳定名词。把“夏季”“油皮关注”“无香”作为集合或属性字段;商品页首段先写产品形态和使用步骤,再说明质地、香味、成分和适用边界。不要把用户体验写成所有人都会得到的结果。

Shopify 落点:category metafield 或产品 metafield 保存质地、香味、主要成分和使用顺序;集合页按肤质关注或使用场景组织;FAQ 回答“能否妆前使用”“需要搭配什么步骤”;商品页 Product JSON-LD 只描述真实商品,不用额外造一个“光泽产品”对象。

例子 3:壁挂收纳架被写成“家居装饰”

原始问题:家居店把一个带层板的壁挂收纳架归到“Home Decor”,product type 写成“Small Space Living”,集合页只强调“让空间更好看”。用户问“浴室墙面能放什么收纳用品”时,页面没有把承重、尺寸、安装方式和防潮条件放在商品身份旁边。

判断过程:先判断用户购买它的主要任务是收纳还是装饰。再核对承重、层板数量、外部尺寸、安装墙面和是否需要组装。装饰风格可以影响选择,但不能替代“壁挂收纳架”这个稳定类别。

改法:把标准分类和 product type 调整为与收纳架或壁挂收纳用品相符的层级,把“小空间”“浴室”“极简风”放进集合和标签。商品页首段写清尺寸和用途,规格区列出承重和安装条件,FAQ 回答墙面类型、工具和防潮限制。没有做过的安装测试,要明确写未测试。

Shopify 落点:商品字段保存长宽高、承重、材质和安装方式;集合页负责“浴室收纳”“小户型收纳”等购物路径;安装说明用 Page 或博客承载;商品页和安装页互相链接。AI 和用户都能从同一条路径判断它是不是自己要找的收纳品。

例子 4:设计模板包被写成“专业版”

原始问题:数字产品店销售一组社交媒体模板,三个商品的 product type 分别是“Starter”“Pro”“Business”,但页面没有先说明文件格式、兼容软件、商业授权和更新期限。AI 搜索可能把它们概括成课程、服务或软件订阅,而不是可下载的模板包。

判断过程:先确认交付物是文件、课程、服务还是软件。对于文件类商品,再核对格式、打开方式、编辑权限、授权范围、更新支持和下载方式。Starter、Pro、Business 是套餐或授权层级,不是产品主功能。

改法:标准分类如果没有完全匹配的数字产品节点,就不要凭感觉自造标准路径;用清晰的商品标题和 product type 表达“数字下载 / 社交媒体模板 / 文件包”,并在页面中公开格式、兼容范围和授权边界。把套餐层级留在产品选项、集合或比较页中。

Shopify 落点:metafield 保存文件格式、软件版本、授权类型和更新期限;商品页显示下载说明;授权条款用 Page;FAQ 回答“能否用于客户项目”“购买后是否有更新”;比较页或集合页按使用需求组织,而不是只按“专业”排序。

服装、美妆、家居和数字产品的分类错位、判断依据和 Shopify 改法示例
四个样例的共同点:主功能定身份,场景和差异另放一层。

实战方法:6 步检查商品分类是否互相冲突

  1. 写一句商品定义:不用品牌口号,只写“这是一个什么商品,用来解决什么主要任务”。如果一句话只能写成“生活方式单品”或“专业方案”,先回到商品本身。
  2. 检查标准分类:从 Shopify 可选的标准分类里选最接近主功能的节点。不要为了进入一个活动集合,选择与商品形态无关的类别。
  3. 检查 product type:用稳定的内部路径表达店铺层级,例如“护肤 / 面部 / 精华”或“家居 / 收纳 / 壁挂”。避免把季度活动、折扣层级和广告主题当成 product type。
  4. 把用途拆到集合和标签:把通勤、浴室、小户型、敏感肌、客户交付等场景放到可复用的集合、标签或筛选字段,让一个商品可以进入多个合适路径。
  5. 补类别属性:按商品类型补尺寸、材质、成分、兼容范围、授权、安装条件等属性。缺失值写“未公开”或“以说明书为准”,不要用猜测填满表格。
  6. 固定问题复测:用“它是什么”“适合谁”“有什么限制”“和哪类商品比较”四类问题测试 AI 搜索和人工页面。记录它引用的页面、漏掉的属性以及是否把场景写成主分类。
复查问题 通过表现 发现错位后的动作
它是什么商品 答案是稳定商品名词 改标题、product type 和首段
适合什么场景 场景是条件,不是身份 改集合、标签和 FAQ
有什么关键差异 能说出属性和限制 补 metafield、规格和说明
哪里能继续核对 能进入商品页或政策页 补内链和页面落点

Shopify 页面怎么改:从后台字段一路对到渠道

商品分类从 Shopify 后台字段到商品页、集合页、主题结构化数据、渠道 feed 和复测记录的修改落点
分类修在源数据,属性写进页面,渠道和分析工具用来复查是否一致。

后台:先改商品分类和 product type

在 Shopify 商品编辑页的组织信息区域,先核对 product category、product type、vendor 和 tags。分类字段只承担商品身份,vendor 表示品牌或供应方,tags 和集合条件承担补充路径。改完后不要只抽查一件商品,至少选一个主推商品、一个变体多的商品和一个最近上新的商品。

集合页:让用途成为可进入的购物路径

集合页可以回答“我想找哪一类商品”或“我想解决什么场景”。建议在集合标题和首段写明进入条件,例如“适合浴室墙面的收纳用品”或“支持客户交付的模板包”,而不是只写一个风格词。集合页中的商品卡标题、短描述和链接也要和商品页的主分类一致。

商品页:用公开文本补足属性和限制

后台字段对团队有用,但 AI 和用户最终会读取公开页面。商品页首段先写稳定商品名词,再把尺寸、材质、成分、格式、兼容范围、使用方法和限制放进规格区、FAQ 或说明区。关键字段不要只放在图片、弹窗或点击后才加载的模块里。

主题和结构化数据:不要用 schema 伪造分类

具体商品页可以维护与页面可见内容一致的 Product JSON-LD,重点核对商品名称、品牌、URL、图片、变体、价格、币种和可用性。分类字段是否能被某个搜索系统使用,要以该系统的文档和数据源为准;不要在主题里额外创建一个“综合分类商品”,也不要用结构化数据覆盖页面本身写错的商品名。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "[页面可见的商品名称]",
  "brand": {
    "@type": "Brand",
    "name": "[真实品牌名]"
  },
  "url": "[当前商品页 URL]",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "[页面币种]",
    "price": "[页面价格]",
    "availability": "[页面库存状态]"
  }
}
</script>

这段只是字段边界示例,不是可以直接复制到线上主题的完整代码。结构化数据必须描述当前商品页真实展示的信息;如果主题或 SEO App 已经输出 Product JSON-LD,先检查是否重复、是否引用了旧 product type、旧价格或旧 URL。

渠道与数据:分别看 feed、搜索和后续行为

如果店铺连接了 Google & YouTube 或其他商品渠道,检查 feed 中的标准分类和自定义 product type 是否与商品页的主功能一致。Google Merchant Center 的商品数据诊断用于发现字段、政策和同步问题;它不能替代 Shopify 页面核对。Google Search Console 适合观察分类相关查询是否开始进入页面,Bing Webmaster Tools 的 AI Performance(如果账号可用)可以查看 AI 引用和页面出现情况,GA4 则用来观察用户从集合页进入商品页后的路径。

每次分类调整都保留一条记录:商品 URL、修改前后字段、公开页面变化、固定测试问题、引用页面和后续访问路径。这样可以判断问题是分类写错、属性缺失、页面没有输出,还是外部数据源尚未同步。

可直接套用的商品分类记录模板

下面的模板适合在表格、Shopify metafield 规划文档或发布检查单里使用。方括号内容要换成真实资料。

  1. 商品主功能:[它是什么商品,主要解决什么任务]
  2. 标准分类:[Shopify product category 中最接近的具体节点]
  3. 店铺分类:[稳定的 product type 路径]
  4. 可进入集合:[按场景、系列、风格或需求组织的集合]
  5. 核心属性:[会改变选择的尺寸、材质、成分、格式、兼容或授权]
  6. 公开页面:[商品标题、首段、规格、FAQ、说明页和内链]
  7. 渠道复查:[Google 商品数据、主题 schema、GSC、Bing、GA4 的检查结果]

常见误区

  • 把季节、风格或人群写进唯一商品分类。它们通常是集合或筛选路径,可能随活动变化。
  • 把 product type 当成广告系列名称。广告主题会频繁变化,内部分类需要长期稳定。
  • 用标签数量代替商品身份。标签可以很多,但商品页仍要有一个清楚的主功能名词。
  • 只改后台字段,不改公开页面。后台分类没有输出到标题、规格、FAQ 或集合说明时,用户仍然看不懂。
  • 用 feed 规则掩盖网站事实。渠道映射可以修正格式和正确的字段路径,不能把衬衫页面变成另一个商品。
  • 认为分类正确就一定会被 AI 推荐。分类只是理解链条的一部分,抓取、内容质量、竞争页面、查询匹配和数据新鲜度都会影响结果。

FAQ

Shopify product category 和 product type 有什么区别?

product category 是 Shopify 提供的标准分类,product type 是店铺自己定义的分类字段。前者更适合对齐标准商品类别,后者更适合维护店铺内部的层级和命名。两者都应该围绕商品主功能,而不是临时活动名。

商品用途可以直接写进 product type 吗?

如果用途本身就是稳定的商品层级,可以作为 product type 的一部分,但不要让一次活动或季节口号成为唯一分类。通勤、浴室、小户型、客户交付等通常更适合用集合、标签或属性字段表达。

Shopify 商品分类选错,会直接导致 AI 不引用吗?

不能这样直接推断。分类错误会增加页面、集合和商品渠道之间的理解冲突,但 AI 是否引用还会受到抓取、索引、查询匹配和其他页面竞争影响。先用固定问题检查它把商品归到了哪里,再决定改分类还是补属性。

分类改好后,为什么 AI 还是说错?

常见原因是公开页面仍保留旧商品名词,属性只存在后台,集合说明和商品页冲突,或者 feed 和主题结构化数据还没有同步。先检查页面 HTML、可见文本、Product JSON-LD、商品渠道数据和固定复测记录,不要只看 Shopify 后台字段。

数字产品没有合适的标准分类怎么办?

不要凭感觉造一个看似标准的路径。先用清晰的商品标题和 product type 表达交付物,例如模板包、字体文件或课程,再在页面中写明文件格式、兼容范围、授权和下载方式。外部渠道需要的标准分类另按该渠道文档映射。

分类字段要不要放进 Product JSON-LD?

不要为了补分类而随意增加 schema。先确保 Product JSON-LD 的商品名称、URL、品牌、价格、库存和变体与页面真实展示一致;分类主要在 Shopify 后台、集合逻辑和商品渠道字段中维护。结构化数据通过测试,也不代表商品页面的分类判断已经正确。

下一步阅读

想继续整理 GEO 页面关系,可以先看 GEO / AI 搜索实战文章。如果你不确定问题出在商品字段、主题代码还是 App 输出,先走一遍 独立站诊断入口。需要继续优化商品页承接,可以看 Shopify 商品页与转化优化;准备上线或大改模板,再用 Shopify 上线检查清单 复查基础项。

分享这篇文章

阅读说明

这些文章更适合当作排查笔记,而不是万能模板。

这篇文章适合怎么读?

先看结论和步骤,再对照自己的网站情况判断是否适用。涉及代码或后台设置的部分,建议先在预览主题或测试环境里试。

可以直接照着改吗?

有些步骤可以直接参考,有些要看主题结构、App、页面内容和当前业务阶段。不要在正式主题上直接试,先备份或用预览主题验证。

代码片段需要注意什么?

不同主题的 section、snippet 和 CSS 结构不一样。复制代码前先确认文件位置和命名,改完后检查桌面端、移动端和购物流程。

后续还会补充吗?

会。内容会围绕建站流程、主题代码、页面优化、速度排查和工具实测慢慢补,不追热点,优先写实际遇到的问题。

我的情况和文章不一样怎么办?

可以先把网站链接、页面现象和你已经尝试过的操作记下来,再决定是继续自查,还是发来让我帮你判断问题类型。

继续看 Shopify 实操笔记

如果这篇文章解决了一部分问题,可以回到博客列表继续看相关笔记;如果情况不一样,再带着页面和现象来判断。

返回博客列表 发来问题