把 Amazon 商品导入 Shopify，最容易产生误解的一句话是：“导一份 CSV 就好了。”
CSV 只是数据进入系统的一种方式，不是迁移方案。
Amazon Listing 围绕 ASIN、父子体和平台类目组织；Shopify 则要把顾客看到的产品、可以购买的变体、用于导航的集合、用于解释商品的元字段，以及真实库存位置组合起来。
如果不先做映射，常见结果是：父子体被拆成一堆重复商品，颜色和规格混在标题里，集合页无法筛选，库存对不上，运营改一次字段就要重新补表。
第二篇只解决一个问题：怎样把 Amazon 的商品资料，重建为可运营的 Shopify 商品模型。
一、先建立迁移映射表，不要先上传
每个源商品至少要有以下字段：
| 源数据 | Shopify 目标 | 迁移前要决定什么 |
|---|---|---|
| ASIN / 父 SKU | Product / Handle | 哪些子体属于同一次购买判断 |
| Seller SKU | Variant SKU | 是否继续作为库存与系统同步主键 |
| Variation Theme | Option / Variant | 哪些属性真的影响购买 |
| Bullet / A+ | 商品描述与页面模块 | 哪些是商品事实，哪些要重写 |
| Browse Node | Collection / Taxonomy | 顾客按什么方式找到商品 |
| 属性字段 | Metafield | 类型、单位和可维护责任人 |
| 库存数量 | Location Inventory | 哪个地点负责履约 |
这张表的目的，是先决定数据落到 Shopify 的哪个对象里，再决定使用 CSV、批量编辑器、应用或 API。
二、产品与变体：先定义“一次购买判断”
Shopify 的 Product 应对应顾客理解中的一款产品；Variant 则对应这款产品中可直接购买的组合。
例如同一款设备有黑白两色和两个容量，颜色、容量可以成为变体选项。材质说明、兼容系统、安装要求通常不是购买选项，更适合放进元字段。
迁移时逐组回答：
- 用户是否会把这些子体理解为同一款产品？
- 切换属性时，主图、库存、条码或履约是否需要变化？
- 这个属性是购买选择，还是商品说明？
- 组合数量是否会让商品页难以维护？
不要为了保持 Amazon 父子体结构，强行把所有子体塞进一个 Shopify 产品；也不要把每个颜色都拆成独立产品，导致集合页出现大量重复卡片。
三、集合：按用户意图重建导航
Amazon 类目节点服务于平台搜索，不应直接成为独立站导航。
Shopify 集合页要帮助顾客缩小选择。常见组织方式包括：
- 按用途：通勤、旅行、户外、专业场景；
- 按兼容性：设备型号、系统、尺寸；
- 按产品角色：入门、核心、升级、配件；
- 按关键规格：容量、材质、功率或安装方式。
先写出集合需要回答的问题，再选择手动集合或基于条件的智能集合。条件要依赖稳定的商品字段，而不是让运营长期手工维护一串“精选商品”。
四、元字段：把商品事实从文案里拆出来
很多 Amazon 卖点进入 Shopify 后，不应继续是一大段富文本。
适合结构化的内容包括：
- 材质与尺寸；
- 兼容型号；
- 功率、容量和工作条件；
- 包装清单；
- 安装与保养；
- 认证或合规信息；
- 保修与售后边界；
- FAQ 与下载资料。
先定义字段名称、类型、单位、适用产品和维护责任，再导入数据。数字不要全部存成文本，真假值不要写成“是/否”字符串，多个对象也不要挤进一个逗号分隔的长句。
当相同内容需要跨多个商品复用，例如兼容设备、规格组或材料说明，可以进一步评估 Metaobject；但不要为了技术感，把所有文案都结构化。
五、素材：不能把 A+ Content 原样贴过来
图片迁移至少要区分五种角色：
- 集合页缩略图；
- 商品主图；
- 规格与细节图；
- 场景图；
- 安装、对比或说明图。
每张图都要记录用途、排序、替代文本和移动端裁切。把一整张长图塞进商品描述，会导致移动端文字过小，也让运营很难更新其中一个卖点。
更稳妥的做法是：商品事实进入字段，页面结构进入主题模块，图片只承担它真正擅长的展示任务。
六、库存与履约：SKU 必须成为稳定连接键
库存迁移前先确认：
- 每个可购买变体是否都有唯一 SKU；
- Amazon、ERP、3PL 和 Shopify 是否使用同一套 SKU；
- 库存由哪个系统作为最终来源；
- 不同地点分别负责哪些市场和订单；
- 套装是独立库存，还是由组件库存计算；
- 同步异常时如何避免超卖。
Shopify 的 Location 不只是仓库名称，还会影响库存与履约。先建立地点、SKU 和履约规则，再导入数量；不要用产品标题或 ASIN 充当长期库存主键。
七、价格与市场：不要只做“平台价减佣金”
独立站价格需要考虑商品角色、套装、服务、币种、税费和市场可见性。它不是把 Amazon 售价减去平台费用后得到一个数字。
如果不同地区销售不同版本，需要同时核对：
- 商品是否在该市场可售；
- 货币与展示价格；
- 对应库存地点；
- 语言和规格单位；
- 售后与合规说明；
- URL 与搜索落地页。
多市场的核心不是翻译首页，而是商品、价格、内容与履约共同对齐。
八、正确的导入顺序
建议按以下顺序执行：
- 锁定字段字典：Product、Variant、Collection、Metafield、Location 的映射先签字；
- 导入少量样本：选择简单、复杂和异常商品各一组；
- 验证商品与变体：标题、Handle、选项、SKU、条码和库存策略；
- 建立集合与筛选：确认顾客能按真实需求缩小范围；
- 导入结构化事实：元字段、说明、下载和 FAQ；
- 补齐媒体与移动端裁切：检查主图、变体图和场景图；
- 导入库存并连接履约：用唯一 SKU 验证不同地点；
- 做完整测试订单：从落地页、变体选择、加购、结账到履约回写逐步检查；
- 再扩大批量：样本稳定后才处理完整目录。
九、上线前检查表
- 同一 Product 下的变体是否属于同一次购买判断；
- 每个 Variant 是否有唯一且稳定的 SKU；
- 集合页是否按顾客意图组织，而不是照搬平台类目；
- 规格、兼容性和包装清单是否进入结构化字段；
- 图片是否有明确角色与移动端裁切；
- 库存地点与履约系统是否已用样本订单验证；
- 不同市场的商品、价格、语言、税费和库存是否一致；
- 旧链接、搜索落地页和必要的重定向是否已规划；
- 运营是否能在不改代码的情况下维护核心商品事实。
十、为什么由 WESWOO 团队落地：技术架构与品牌设计必须一起做
WESWOO 是面向独立站项目提供规划、设计与开发服务的 Shopify 合作伙伴团队。我们不是把 Amazon 表格导入后台的迁移工具，也不把“换个平台”理解为重新套一套模板。真正需要完成的，是把原有商品资料重新组织成顾客看得懂、运营改得动、系统接得上的 Shopify 商业体验。
技术能力决定这套系统能不能长期运行。 WESWOO 会从 Product、Variant、Collection、Metafield、Metaobject 与 Location 的关系开始，继续处理主题架构、可编辑模块、筛选与搜索、库存和履约连接、多市场，以及 B2B、结账扩展与 Shopify Plus 的适用边界。重点不是堆功能，而是明确数据归属、系统主键、维护责任和异常处理方式，让商品目录扩大后仍然可控。
设计能力决定这些技术是否真正转化为品牌体验。 同一组商品数据，如何进入首页、集合页、商品页、购物车与内容页面，需要品牌视觉、信息层级、购买路径和移动端体验共同参与。WESWOO 会把品牌表达落实到可复用的页面模块、商品字段和交互规则中，让视觉不是一次性交付的效果图，也让技术实现不会把网站做成没有品牌差异的后台外壳。
技术与设计在同一支团队里协同，迁移才不会变成“数据已经进去，但顾客仍然不会选，运营仍然不好改”。我们会用少量代表性商品先验证模型、页面和真实购买链路，再扩大到完整目录，并把关键环节拆成可以检查、测试和验收的交付物。
如果你正在准备从 Amazon 扩展到 Shopify，可以带着商品导出表、变体关系、库存系统、目标市场和现有品牌资料联系我们。我们可以先判断问题主要在商品模型、系统连接、页面体验，还是品牌表达，再决定下一步如何落地。
FAQ
Amazon 父子体可以直接对应 Shopify Product 和 Variant 吗？
不能默认一一对应。先判断这些子体是否属于同一次购买选择，再决定合并、拆分或重组。
产品 CSV 能解决全部迁移吗？
不能。它可以承担部分商品数据导入，但集合规则、结构化字段、库存地点、媒体、市场和系统同步仍需要单独设计与验证。
SKU 很多就一定需要 Shopify Plus 吗？
不一定。Plus 的评估应看 B2B、目录和价格、多市场治理、结账扩展及系统协同等实际需求，而不是只看 SKU 数量。