Headless Commerce 内容模型开发前检查清单

Headless Commerce 项目在规划时看起来很灵活，但上线后仍然可能很难运营。常见问题不一定是框架本身，而是内容模型不清楚：产品数据在一个系统，编辑内容在另一个系统，SEO 字段上线前才补，没人知道不同市场的文案到底归谁管。

这份清单建议在设计和开发前使用。它帮助团队判断哪些内容属于 Shopify，哪些属于 CMS，哪些应该由模板规则生成，哪些需要编辑团队可以控制的字段。目标不是把所有东西都模型化，而是把影响商品运营、SEO、多语言和日常发布的部分先讲清楚。

先讨论负责人，而不是先列字段。Headless 技术栈通常包含 Shopify、CMS、分析、搜索、评论、订阅、个性化和部署工具。每个系统都可能保存内容，但每个关键决策最好只有一个唯一来源。

请写清楚产品事实、编辑叙事、导航、SEO metadata、重定向、市场差异内容、活动模块和法律文案分别在哪里管理。如果一个值可以在两个地方编辑，模型里就需要定义哪个值优先，以及冲突时怎么处理。

• Shopify 通常负责 SKU、价格、库存、变体、产品状态和 checkout 关键数据。
• CMS 通常负责活动模块、叙事 section、购买指南、落地页和可复用编辑内容。
• SEO 归属要明确到 title、description、canonical URL、索引规则、schema 字段和本地化 alternate。
• 记录哪个团队能编辑每类内容，哪些修改需要开发审核。

不要只用一个完美商品来设计模型。请抽取 10 到 20 个能代表目录复杂度的真实商品：简单商品、变体很多的商品、套装、订阅商品、季节性商品、带合规声明的商品、缺少图片的商品，以及不同市场信息不一致的商品。

对每个商品标记哪些内容需要出现在产品页、集合卡片、搜索结果、购物车、checkout、结构化数据和内部运营视图中。这个过程会暴露哪些字段是产品事实，哪些是展示选择，哪些只是临时活动内容。

• 为产品和变体模板列出必填、选填、计算生成和弃用字段。
• 定义图片角色，例如详情图库、集合卡片、社交分享图、成分或规格细节，以及移动端裁切。
• 规划产品文案、媒体、评论或 metafields 缺失时的 fallback 行为。
• 确认哪些值因为影响价格、合规或 SEO，需要历史记录、审批或限制编辑。

Headless 网站很容易漂移，因为每个活动都变成一个定制组件。开发前先判断哪些 section 应该成为可复用编辑工具，哪些体验值得单独制作。可复用 section 需要清楚字段、输入限制、预览、fallback 状态和编辑能理解的命名。

好的模型能给市场团队足够灵活性，但不会把 CMS 变成空白画布。例如对比表、编辑型 hero、产品故事模块、引用块和 FAQ section 可以复用。高风险品牌发布页仍然可以单独制作，但应该是有维护计划的例外。

• 整理 section 清单，写清用途、字段、媒体比例、字数限制和允许出现的页面类型。
• 避免只因为间距或颜色不同就创建重复模块，除非设计系统真的需要。
• 定义哪些 section 可以引用产品、集合、视频、表单、评论或嵌套内容。
• 补齐空内容、加载中、未发布和归档状态，避免内容变化后页面断裂。

在 Headless Commerce 中，如果 metadata 被当作最后的上线检查项，SEO 会很脆弱。内容模型应该定义每类页面的 page title、description、canonical URL、Open Graph 图片、结构化数据、面包屑、robots 规则、hreflang 和 sitemap 收录规则。

有些 metadata 应该由编辑控制，有些应该由稳定规则生成。产品标题、集合名称、库存状态、价格、评分数据和面包屑通常来自电商数据。编辑型描述、购买指南文案、活动 metadata 和本地化 SEO 字段通常需要 CMS 控制。

• 为产品、集合、落地页、文章、搜索、账户和市场页面分别规划 metadata 规则。
• 决定哪些模板可以 index、noindex、canonical 或从 sitemap 排除。
• 确认相关页面能拿到完整的产品、Offer、面包屑、文章和组织结构化数据。
• 明确重定向归属，避免 URL 变化在上线周变成临时表格事故。

多语言 Headless Commerce 不只是翻译。不同市场可能有不同的商品可售状态、货币、尺码语言、合规文案、配送承诺、促销、图片和法律要求。如果这些差异后期才建模，团队通常只能复制页面或硬编码市场逻辑。

开发前要定义哪些内容是全球共享，哪些需要翻译，哪些是市场专属，哪些可以回退到默认语言。内容模型应该让翻译状态可见，保护必填字段，并支持本地化 metadata 和 hreflang 关系。

• 选择编辑、用户、分析和爬虫都容易理解的 URL 结构。
• 定义产品文案、编辑 section、SEO 字段、媒体和法律内容的 fallback 规则。
• 显式保存翻译关系，让本地化页面保持连接。
• 模板开发前测试市场专属的商品可售状态和集合归属。

Headless CMS 只有在编辑能安全预览真实页面时才有价值。预览应该用和生产站一致的路由、产品数据、价格行为、多语言规则和响应式布局显示草稿内容。只渲染孤立字段的预览，无法发现上线风险。

同时要定义发布角色。明确谁可以发布产品内容、编辑页面、活动模块、SEO 字段、重定向和导航。然后记录当引用商品未发布、集合为空，或活动页排期早于商品可售时间时，系统应该怎么处理。

• 测试产品页、集合页、落地页和本地化版本的草稿预览。
• 为 SEO、媒体、CTA、产品引用和市场专属内容设置必填字段和校验规则。
• 为价格声明、合规文案、重定向和发布页等高风险内容建立审批状态。
• 记录内容发布后发现错误时的回滚步骤。

发现模型缺口最快的方法，是在模板开发前先准备一组 QA 样例。创建包含边界情况的测试商品、集合、页面和本地化版本。这样开发可以用真实数据测试组件，而不是只用设计文件里的干净示例。

样例应该包含缺失媒体、超长标题、很短描述、未发布商品、隐藏集合、缺货商品、折扣商品、变体很多的商品、本地化 URL，以及 metadata 不完整的页面。越早计划这些情况，最终 QA 就越像确认，而不是发现问题。

• 为产品、变体、集合、活动、文章和导航数据准备样例检查清单。
• 包含长文案、空字段、特殊字符、翻译内容和市场差异内容。
• 验证引用商品、评论、媒体或 section 不可用时，模板能优雅降级。
• 把这些样例用于视觉 QA、技术 SEO QA、分析追踪 QA 和编辑培训。