十分钟自查:你的 Shopify 店对 AI 代理可见吗?(6 项检查)
六个公开端点就能告诉你 AI 购物代理能不能找到、读懂并买到你 Shopify 店里的东西。不需要 API Key、不需要后台权限、不需要工具。这篇给出检查项、每项的健康基线,以及团队里该由谁去修。
为什么布尔值检查比仪表盘更有用
代理可达性不像排名那样渐进衰减。一次工具调用要么返回你的商品,要么返回空;一次结算要么在对话里完成,要么不能。没有中间态,也没有部分得分——所以这是一份通过/不通过的核对清单,不是一张趋势图。
这在运营上是好消息:检查快、便宜、可重复,而且大部分失败是配置问题而不是工程问题。下面全部使用你自己域名上公开可读的端点。把 yourstore.com 换成你的域名,现在就能跑。
检查 1 —— /agents.md 与 /llms.txt 返回 200
符合条件的 Shopify 店会在 /agents.md 托管一份平台生成的「给 AI 代理的使用说明」,并在 /llms.txt 镜像它。对两个路径取响应头,确认是 200。
健康基线:两个都返回 200 且正文不是空壳——通常在 5.6 至 5.8 KB 之间。2026-10-31 我们检查的八家线上店面里,六家两个文件都在,两家两个都 404。责任人:控制店面构建的那一方——Liquid 是主题团队,Headless 是前端工程。
检查 2 —— /.well-known/ucp 存在且声明了真实能力
取 https://你的域名/.well-known/ucp。这是协议发现文档:协商版本、服务端点、声明的能力与支付处理器。
健康基线:200 响应并声明完整的能力清单。2026-10-31 我们检查的八家店声明的是 13 项或 15 项;多出来的那两项是门店检索与取回,只有有线下门店的品牌才会带。八家协商到的都是同一个带日期的协议版本。明显比这更短的清单——尤其是整类能力缺失——值得升级处理。责任人:通常是平台侧;但自定义域名下清单很薄,往往指向你自己的店面配置。
检查 3 —— payment_handlers 不为空
还在同一份文档里,看声明的支付处理器。这是我们见过最常坏、也最少被检查的一个字段。
健康基线:至少一个完整声明的处理器。2026-10-31 我们检查的八家全部通过,通常是 Google Pay 加上 Shopify 自家的卡与 Shop Pay 处理器——所以预期它会通过。它留在清单里,是因为空对象意味着在那条代理结算路径上你的店没有可用支付轨(无论目录多好),而你的任何报表都不会告诉你这件事。责任人:支付与 Markets 配置,不是主题团队。
检查 4 —— 永久链接能力指向自有域名
仍在发现文档里:找到永久链接能力,看它的端点解析到哪个主机。
健康基线:你自己的品牌域名。2026-10-31 我们检查的八家里有两家不通过——一家解析到 myshopify 域名,一家解析到独立的 shop 子域——而这两家恰好也是检查 1 与检查 6 不通过的那两家。区域结算子域是有意的配置而不是故障,所以升级处理之前先把值读清楚。责任人:域名与销售渠道配置。
检查 5 —— 你的 MCP 端点能列出工具
向 https://你的域名/api/ucp/mcp 发一个标准 JSON-RPC 的 tools/list 请求。在 2026-10-31 这一轮里,这份清单在八家店上都可以匿名调用,返回一个约 207 KB 的响应,描述 14 或 16 个工具,覆盖目录、购物车、结算、订单,以及(有线下门店的店铺才有的)门店检索。
健康基线:工具数在这个量级,且包含目录检索、购物车操作与结算。注意这里刻意的设计:清单是公开的,但真要执行一次目录检索,需要一个可公开访问的代理身份档案——用不可达的档案去调用,它会直接以「档案不可达」报错失败,而不是降级返回一个更差的结果。清单开放不等于店铺开放。责任人:平台侧;端点整体缺失则需升级处理。
检查 6 —— 店面注册了 WebMCP 工具
取你的首页 HTML,统计浏览器模型上下文接口相关标记的出现次数。Shopify 会在 Liquid 店面上、以及在渲染其脚本包的受支持新版 Hydrogen 店面上注册一组结构化工具,让浏览器里的代理能调用工具而不是去解析截图。
健康基线:计数大于 0。2026-10-31 我们检查的八家里六家注册了这些标记,两家是 0——而返回 0 的这两家,正是检查 1 与检查 4 不通过的那两家。浏览器内的代理在这两个站上没有任何结构化工具可用。责任人:Liquid 是主题团队;Headless 则看你的 Hydrogen 版本与脚本初始化。
怎么计分,以及拿到结果之后做什么
- 六项全绿——你在结构上是在场的。接下来做目录质量:标准商品分类、可过滤属性、库存卫生、可被抽取的商品事实、已发布的政策事实。
- 检查 1 或 6 红——店面构建问题。在 Headless 与自定义域名的配置里最常见。先修这个,再谈任何内容工作。
- 检查 3 或 4 红——支付、Markets 或域名配置。通常当天可修,影响却不成比例地大。
- 检查 2 或 5 红——需要升级处理;协议面整体缺失通常指向收录资格或渠道发布问题。
- 至少每季度重跑一次。协议版本与能力清单会漂移,十月通过不构成一月也通过的证据。
如果你不想自己跑
这六项检查刻意做得很简单,任何团队都能做。更难的是解读:你的品类在两套目录里的哪一套竞争、你在哪些过滤维度上不达标、你的商品文案能不能产出可抽取的事实,以及在你既有路线图下该按什么顺序修。
这份解读是我们 AI 可见度(GEO/AEO)与 Agentic Commerce 服务的第一个交付物,也是价值最集中的地方。如果你想拿到自己域名的读数——包括代理用你的核心品类词当前会检索到什么——把域名发给我们,我们带你逐条过结论。
常见问题
跑这套检查需要后台权限或 API Key 吗?
不需要。六项检查全部使用你自己域名上公开可读的端点。修其中几项失败需要后台权限,但发现它们不需要。
我的店是 Headless,是不是注定不通过?
不一定,但你应该去查,不要假设。Headless 把很多原本「默认就有」的东西变成了「需要你主动确认」的东西。在 2026-10-31 这一轮里,不通过的那两家是三项同时坏——代理使用说明、永久链接指向、浏览器侧工具标记——这也是我们现在建议把这几项全部加进每一份迁站验收清单的原因。
多久重跑一次?
季度是下限;另外在任何店面迁移、主题换栈、域名变更、支付服务商变更或 Markets 重配之后立即重跑——正是这些动作会悄悄弄坏检查 3、4、6。
单项影响最大的修复是哪个?
在我们的样本里是店面构建类失败——/agents.md 与 /llms.txt 返回 404,加上浏览器侧工具标记为 0。这两项总是一起出现,它们直接把入口整个拿掉,而且一旦有人真的去看,修起来最便宜。