Headless Commerce 迁移上线前检查清单

Headless Commerce 可以让品牌拥有更快的页面、更灵活的内容系统、更清晰的多市场路由，以及更自由的商品叙事。但如果 Shopify 数据、CMS 内容、结账流程、SEO 规则和维护责任没有一起规划，它也会变成一个很难运营的技术栈。

这份 Headless Commerce 迁移检查清单适合使用 Shopify 管理商品和 checkout，同时准备把前台 storefront 迁移到 Next.js 等定制前端的电商团队。建议在开发前用一次，内容录入前用一次，上线前再用一次。

Headless 应该解决一个明确的业务或运营问题。常见理由包括内容结构复杂、多市场 storefront、需要更强的商品教育、现有主题性能受限、营销模块太难维护，或者 Shopify theme section 已经无法干净支持设计系统。

在架构确认前，把理由写下来。如果理由只是 Headless 听起来更先进，团队可能会额外承担 hosting、preview、cache、deployment 和集成维护成本，却没有清楚的回报。

• 业务需求：Headless 能解决当前 theme 解决不好的什么问题。
• 证据：哪些页面、活动、市场或工作流证明这个需求真实存在。
• 负责人：上线后谁负责内容、数据和部署流程。
• 边界：哪些能力必须留在 Shopify，例如 checkout、库存、折扣或客户账号。

迁移最容易失控的地方，是团队说不清每个内容字段到底在哪里维护。Shopify 通常负责产品、变体、库存、价格、折扣、collection、checkout、税费和配送。CMS 可能负责 landing page、编辑内容、购买指南、导航文案、本地化文案、SEO 字段和可复用活动模块。

组件开发前，先做一份字段地图。每个模板都应该写清数据来源、必填字段、fallback 规则、preview 方式、图片比例、本地化需求和可编辑负责人。这样前端不会依赖一个运营团队根本无法长期维护的字段模型。

Headless Commerce 最大风险通常不在首页，而在购买流程。要测试加购、数量调整、变体切换、缺货状态、购物车持久化、折扣码、礼品卡、配送费、税费展示、跳转 checkout、支付方式、客户登录、订阅应用、评价应用，以及每个市场特有的交易逻辑。

这些 QA 应该在移动端和桌面端都用真实测试商品完成。边界情况也要覆盖：售罄变体、多选项商品、组合商品、预售商品、草稿商品、旧产品 URL 的重定向，以及邮件里的 checkout recovery 链接。

Headless 迁移经常会改变 URL 规则、collection 筛选、产品 handle、博客路由、图片输出、内部链接、结构化数据和 sitemap 生成方式。这些决定会影响排名、抓取效率和广告落地页，所以不能拖到上线周才处理。

在模板设计阶段就做 route map 和 redirect map。确认 canonical 规则、分页、筛选 URL、robots 指令、XML sitemap、产品结构化数据、collection metadata、Open Graph、图片 alt text，以及如果是多语言商店，还要确认 language alternates。

定制前端必须有清楚的缓存规则。产品信息、价格变化、库存状态、CMS 更新和活动页，应该按照业务能理解的节奏更新。如果 webhook 或 revalidation 失败，团队要知道哪些内容会变旧，以及怎么手动修复。

不要只测试正常页面，也要测试异常状态。Shopify 响应慢怎么办？CMS 暂时不可用怎么办？产品被归档、collection 为空、图片缺失、编辑打开 preview link 时，前端应该展示什么？这些状态提前设计好，上线后才不会让客户帮你发现问题。

Headless build 很容易在最后阶段才补埋点，结果数据不可用。上线前要确认商品曝光、商品点击、加购、开始结账、购买、搜索、筛选使用、订阅、表单提交、consent 行为和 campaign attribution 是否正确。

同时也要测试运营工作流。非技术团队应该能更新推荐商品、调整活动模块顺序、发布 landing page、修改 SEO 字段、安排内容上线，并在发布前 preview，而不是每个小改动都要找开发。