先别找插件,先把一件商品的事实链画出来
很多团队把问题描述成“AI 找不到我的 WooCommerce 商品”。实际排查至少要拆成六件事:搜索能不能发现正确 URL;标题、描述和图片是否可读;价格和币种是否一致;库存和可售状态是否一致;变体能否正确选择;跳到购物车和结账时承诺是否仍然成立。把它们混成一个“AI 收录”开关,几乎一定会误判。
WooCommerce 的 Store API 是面向顾客的、未认证的 JSON 接口,提供产品、购物车和结账相关能力,但它反映当前顾客会话,不是读取后台全部数据的万能目录。WordPress REST API 是内容层的通用接口。对 AI 来说,页面可见内容与机器可读接口是两条都要维护的路径。
发现
品牌、品类或用途查询能到正确商品 URL。
理解
初始 HTML 和首屏包含规格、图片、用途与限制。
报价与可售
页面、Offer、Store API、Feed 与结账保持一致。
承接
落地页保留来源,关键事件能被 GA4 记录。
WooCommerce 能提供什么,不能替你保证什么
官方 Store API 文档列出 /wp-json/wc/store/v1/products 以及 cart、checkout 端点。产品集合可按 slug、SKU、价格、库存状态和目录可见性筛选;未发布的产品不会出现在集合接口里。它适合前端、目录读取器或受控检索层,但不是自动带来 AI 流量的分发渠道。
如果需要电压、包装内容、保修区域或合规标签等字段,可以用 Store API 的扩展机制放入 extensions。WordPress + WooCommerce 还要区分内容层和交易层:文章、FAQ 可走 WP REST API,商品、购物车和结账事实应由 WooCommerce 接口与页面负责。
只读快照:页面、Store API、结构化数据三方对表
选一个真实销售中的 SKU,记录 URL、商品 ID、变体 ID、抓取时间、访问国家和币种。用浏览器看页面可见价格与库存;读取 /wp-json/wc/store/v1/products?slug=your-slug;再在初始 HTML 中查看 Product/Offer JSON-LD。若有缓存,记录响应头和缓存年龄。
不要只问“有没有 price 字段”。要对四个值:active price、currency、availability、variant。Google Merchant Center 要求价格和可用性与落地页、结账页和结构化数据匹配;Google 也建议 Product 数据放在初始 HTML,并用 Rich Results Test 或 Search Console 检查。这些做法帮助系统理解事实,但不保证富摘要或 AI 推荐。
页面
保存 URL、可见价格、币种、库存文字和变体选择。
接口
GET https://shop.example/wp-json/wc/store/v1/products?slug=sample-filter。
标记
搜索 @type Product、offers.price、priceCurrency、availability。
结账
用测试会话核对同一变体;失败就停止,不下真实订单。
完整例子:美国滤水壶页面找到了,却推荐了错误变体
以下“Northline Flow”是虚构示例。Starter 2-pack 页面价 39.00 USD,Family 4-pack 页面价 69.00 USD。页面默认选中 Starter,Store API 返回两个变体,但 JSON-LD 只输出父商品的 39.00 USD。检索系统看到 4-pack 标题,却拿到父商品价格,用户点进页面才发现不一致。
修复分四步:页面、Store API 与结构化数据一一映射变体名称和 SKU;每个 Offer 使用当前市场币种与价格;库存按变体粒度输出;外部摘要注明“价格以所选变体和结账为准”。随后用六组查询测试品牌+品类、用途+品类、两个变体、缺货变体和美国配送,记录 URL、variant ID、price、availability 与结账结果。
若页面和接口一致但 AI 仍未提到商品,结论只能写成“事实链已准备好,发现或推荐尚未发生”。不要为了追一个不可控结果堆关键词或伪造评价。下一步检查 Search Console、站点可抓取性、目录提交和渠道资格,而不是再次改标题。
把更新做成责任表,失败时按顺序停下来
给每个事实指定负责人:商品经理负责标题、规格和用途;库存运营负责 stock_status、backorders 和库存地点;电商运营负责价格、促销和币种;开发负责 JSON-LD、Store API 扩展和缓存失效;客服负责配送、退换与保修边界。变更记录至少保留 captured_at、product_id、variant_id、market、page_price、api_price、markup_price、stock_status、checkout_result。
Store API 404 时,先确认商品已发布、slug 正确、目录可见性允许展示;价格不一致时,检查市场/币种、促销有效期和缓存;库存不一致时,检查父商品与变体的库存管理、backorder 和库存地点。若只有 AI 摘要错误,保留页面与接口证据,人工修正外部描述。没有测试账号时,不声称完成结账验证;没有权限时,不索取或复制管理员令牌。
这套方法能证明页面和公开接口是否互相矛盾,不能证明 Google、ChatGPT 或其他模型一定收录、推荐或成交。把可抓取、被索引、被推荐、产生关键事件分成四个状态,团队会更容易判断下一步和责任人。
参考来源
- [1] WooCommerce Developer Docs — Store API overview (checked 2026-09-13)
- [2] WooCommerce Developer Docs — Products API and stock/catalog filters (checked 2026-09-13)
- [3] WooCommerce Developer Docs — Extending Store API product data (checked 2026-09-13)
- [4] WordPress Developer Resources — REST API Handbook (checked 2026-09-13)
- [5] Google Search Central — JavaScript SEO basics and rendered HTML (checked 2026-09-13)
- [6] Google Merchant Center — Product data specification: price and availability (checked 2026-09-13)
- [7] Google Merchant Center — Structured data for product pages (checked 2026-09-13)