Shopify 变体选项迁移检查清单：主题重构前先整理

Shopify 变体经常被当成目录里的一个细节，但它会影响客户如何选择商品、集合筛选如何工作、商品 feed 是否通过审核，以及客服团队如何确认正确 SKU。如果主题重构前变体数据已经混乱，新主题只会让问题更明显。

这份清单适合正在准备 Shopify 改版、主题重构、headless 迁移或商品目录整理的团队。开发开始前先使用它，让商品数据、模板、筛选、翻译和 QA 一起推进，而不是变成上线周的补丁。

先从商品导出开始，而不是从主题编辑器开始。列出所有选项名、选项值、SKU 规则、变体图片规则、价格差异、库存规则和 app 依赖。目标是在它变成模板问题前，先找到不一致的数据。

尤其要注意意思重复的字段。Size、Sizes、Package Size 和 Volume 可能是在描述同一个购买决策。Color、Colour、Finish 和 Material 可能是独立选择，也可能应该合并成一个商品展示字段。新 section 开发前要先决定。

• 导出当前 active 商品、未来可能恢复的 archived 商品，以及过去 12 个月的高销量商品。
• 按含义归组选项名，而不是只看完全相同的拼写。
• 标记只存在于某个旧商品上的一次性选项值。
• 记录变体图片、订阅、组合套装、评价、feed 或库存 app 对变体数据的依赖。
• 标记那些把规格信息塞进变体，而不是只表示可购买选择的商品。

不是每个商品差异都应该做成变体。变体通常应该代表会影响购买、库存、履约、价格或商品展示的可购买选择。只描述商品但不改变可购买项目的规格，通常更适合放在 metafield 里。

这个决定会同时保护用户体验和后续维护。干净的变体模型能让 PDP 控件更容易理解，而 metafield 能让对比表、徽章、尺码指南、成分、材质、兼容说明和技术规格更容易管理。

• 当 size、color、pack quantity、subscription interval 和 configuration 会改变被购买的项目时，保留为变体。
• 当 dimensions、materials、compatibility、certifications、care notes 和 technical specs 不产生独立可购买项目时，迁移到 metafield。
• 当选项列表大到影响 PDP 使用时，考虑使用商品组或 sibling products。
• 记录哪些字段由商品运营、销售运营、客服和开发维护。
• 确认新模型仍然支持商品推荐、组合套装、评价和订阅。

变体迁移不是选项标签看起来干净就结束了。每个变体都需要可靠的 SKU、必要时的 barcode、库存策略、履约行为、价格、compare-at price、税务规则、重量和图片关系。这些字段经常是静默出错。

在改完整个目录前，先建立一组样本 QA。样本应该包括畅销品、多选项商品、低库存商品、订阅商品、套装商品、多语言商品，以及有变体专属图片的商品。

• 检查每个 active 变体是否有正确的 SKU 和库存跟踪规则。
• 导入后确认 price、compare-at price、cost、tax、weight 和 fulfillment 字段。
• 映射变体专属图片，并确认选择选项时会切换到预期媒体。
• 验证 unavailable、sold-out、backorder 和 discontinued 状态。
• 保留迁移前后导出文件，让客服能追溯旧值和新值。

变体选项经常驱动集合筛选、站内搜索 facet、商品 feed、商品排序规则和广告属性。标签整理可以改善客户体验，但如果没有检查下游系统，也可能导致 feed 审核失败，或者把有用筛选项删掉。

SEO 风险通常来自商品 handle 变更、重复参数 URL、隐藏商品内容或内部链接断裂。导入过程中变体 ID 可能变化，所以不要依赖旧的变体专属 URL，除非你已经测试它们如何解析。

• 确认整理后集合筛选仍然展示有用的选项值。
• 检查站内搜索、商品推荐和商品排序规则是否依赖选项名。
• 必要时验证 Google Merchant Center 或商品 feed 里的 color、size、age group、gender、material 和 item group ID。
• 除非有明确 redirect 计划，否则尽量保持商品 handle 稳定。
• 测试多变体商品的 canonical、参数处理、结构化数据和内部链接。
• 确认 analytics 事件仍然能记录已选择的变体、SKU、价格和库存状态。

当店铺支持多语言、多币种或多市场时，变体整理会更敏感。选项名和选项值需要翻译规则，但 SKU、库存和履约数据必须保持运营上的一致。

QA 要按市场执行，而不只是按商品执行。某个变体可能在一个国家可见，在另一个国家隐藏；也可能按市场定价不同，或者被配送规则限制。主题应该清楚解释这些状态，而不是显示一个坏掉的选项选择器。

• 检查所有上线语言里的选项名和选项值翻译。
• 确认不同语言下选项顺序保持一致。
• 测试市场可售性、价格、币种、税费、配送和售罄行为。
• 确认 hreflang 页面指向等价商品，而不是错配变体。
• 如果渠道会接收翻译后的选项值，检查本地化商品 feed。

不要等完整目录导入后才判断新模型是否可行。先选择 30 到 50 个能代表真实目录的商品样本，然后测试 PDP、集合筛选、站内搜索、购物车、结账、feed、analytics 和后台编辑流程。

样本应该包含边界情况，而不只是干净商品。当团队能迁移样本、解释规则，并且不依赖开发临场判断就能重复 QA，主题重构才有更稳的基础。

• 包含高收入商品、长尾商品和多变体商品。
• 包含变体图片、订阅、组合套装、折扣和低库存商品。
• 测试桌面端和移动端 PDP 选择、加入购物车，以及购物车行项目显示。
• 让非开发成员按照新规则编辑一个商品。
• 在完整目录迁移前记录尚未解决的边界情况。