Headless Shopify 的隐性代价：迁站验收必加的四项检查

这次对比

2026-10-31，我们对八家线上 Shopify 店面跑了完全相同的一组检查，全部是叫得出名字的 DTC 品牌。这是一个小样本——它证明「这类失败会发生」，不说明「发生得有多频繁」。八家协商到的都是同一个带日期的协议版本，所以下面的差异是配置差异，不是协议漂移。

八家里有六家通过了店面侧的检查。它们提供了代理使用说明及其镜像，各约 5.6 至 5.8 KB；发布的发现文档声明 13 或 15 项能力；声明了一组可用的支付处理器；首页注册了浏览器侧的结构化工具标记。这六家里有五家的结算永久链接解析到品牌自有域名；第六家解析到区域结算子域，那是有意的配置而不是故障。

八家里有两家不通过，而且坏的形状一模一样。两家的代理使用说明与其镜像都返回 404；两家首页注册的浏览器侧工具标记都是 0；两家的结算永久链接都离开了品牌主域——一家指向 myshopify 域名，一家指向独立的 shop 子域。协议层本身在这两家上都还活着：发现文档返回 200、MCP 端点列得出工具。缺的全部是店面构建该负责的那部分。

这不是在反对 Headless

这里必须说准确，因为最容易得出的那个结论是错的。Shopify 自己的文档写得很清楚：浏览器侧的工具注册适用于 Liquid 店面，以及渲染其脚本包的、版本足够新的 Hydrogen 店面。而永久链接落在平台域名上，通常反映的是域名与销售渠道配置，而不是框架缺陷。两者都可修，而且两者在有人去看之前都不可见。

真正的要点是结构性的：Headless 把一批原本「默认就有」的东西，变成了「必须有人主动去确认」的东西。而按我们的经验，几乎没有哪份迁站验收清单包含这些项——因为在这次发布之前，它们还不作为一个类别存在。

另外注意：Hydrogen 的 2026-10 版本已经从一个框架转向一个框架无关的库，不再要求部署到单一运行时。这把 Headless 的门槛降低了不少，意味着会有更多品牌做这个动作——也意味着会有更多品牌继承这个同样的缺口。

该加进验收标准的四项检查

• 代理使用说明与其镜像在生产域名上都返回 200，且正文不是空壳——不是 404，也不是跳到平台域名的重定向。
• 协议发现文档在生产域名上返回 200，能力清单与同等 Liquid 店可比，且同时包含购物类与通用类两个能力族。
• 声明的支付处理器对象非空，且包含商家标识与允许的卡组织列表。
• 购物车与结算的永久链接端点解析到你自己的品牌域名，不是 myshopify 域名。另外单列一项：首页注册的浏览器侧结构化工具标记计数大于 0。

为什么是这四项

每一项对应一种不同的失败模式，责任人也不同——当你写的是验收标准而不是愿望清单时，这一点很关键。

代理使用说明缺失，意味着代理拿不到与你交易的说明、也拿不到你协议端点的指针——这是店面构建问题。能力清单很薄，意味着整类代理动作不可用——通常是渠道发布或收录资格问题。支付处理器为空，意味着在代理结算路径上没有支付轨——这是支付与市场配置问题。永久链接指向平台域名，意味着你意图最强的那个链接离开了你的品牌——这是域名与渠道配置问题。而浏览器侧工具标记为 0，意味着浏览器内的代理只能退回去读页面，可是官方技能恰恰要求代理不要退回去用脚本填表或操作页面控件。

四项全部验证的总成本不到十分钟，用的都是公开端点，不需要凭证。漏掉任何一项的代价，是在一条正在成为主路的通道上完全隐形。

把它们放进项目计划的哪一步

• 迁站前：在现有 Liquid 店上把四项都测一遍留底，这样你有一份有记录的「之前状态」，没人能就「是否退化」争论。
• 预发环境：对 staging 域名跑一遍，同时承认永久链接与支付配置在那里可能合理地不同。
• 上线闸门：四项在生产域名上全绿，才算迁站完成。这是一个发布闸门，不是上线后的待办事项。
• 上线后第 7 天与第 30 天：重跑。支付与市场配置经常在上线之后才定稿，而这正是空支付处理器悄悄留存的地方。
• 之后每季度一次，和你现有的技术 SEO 检查一起跑——协议版本与能力清单会漂移。

如果你正在计划迁站、或刚迁完

我们既做 Headless 店面开发，也做 Shopify 迁站，同时还做依赖它们的 AI 可见度工作——这正是为什么这四项检查现在在我们自己的验收标准里，而不是一篇写过一次的博客里。

如果你有迁站正在进行，现在就值得把这几项写进合同。如果你在过去一年里迁过站，今天就值得跑一遍：上面四种失败全都是静默的，没有一项会出现在任何标准报表里，而一旦被看见，修起来都很便宜。把域名发给我们，我们跑一遍检查，告诉你现在处在什么位置。