NPCNUCLEAR POWER CREATIVE

WooCommerce 接上 AI 之后,为什么价格和库存还是会“说错”?

问题通常不在有没有接 AI,而在同一个商品事实有没有被页面、Store API、结构化数据和结账系统同时说清楚。

先别找插件,先把一件商品的事实链画出来

很多团队把问题描述成“AI 找不到我的 WooCommerce 商品”。实际排查至少要拆成六件事:搜索能不能发现正确 URL;标题、描述和图片是否可读;价格和币种是否一致;库存和可售状态是否一致;变体能否正确选择;跳到购物车和结账时承诺是否仍然成立。把它们混成一个“AI 收录”开关,几乎一定会误判。

WooCommerce 的 Store API 是面向顾客的、未认证的 JSON 接口,提供产品、购物车和结账相关能力,但它反映当前顾客会话,不是读取后台全部数据的万能目录。WordPress REST API 是内容层的通用接口。对 AI 来说,页面可见内容与机器可读接口是两条都要维护的路径。

一件商品的事实链
  1. 发现

    品牌、品类或用途查询能到正确商品 URL。

  2. 理解

    初始 HTML 和首屏包含规格、图片、用途与限制。

  3. 报价与可售

    页面、Offer、Store API、Feed 与结账保持一致。

  4. 承接

    落地页保留来源,关键事件能被 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 推荐。

只读核查清单
  1. 页面

    保存 URL、可见价格、币种、库存文字和变体选择。

  2. 接口

    GET https://shop.example/wp-json/wc/store/v1/products?slug=sample-filter。

  3. 标记

    搜索 @type Product、offers.price、priceCurrency、availability。

  4. 结账

    用测试会话核对同一变体;失败就停止,不下真实订单。

slug 和域名为示例;不要把管理员令牌放进命令。

完整例子:美国滤水壶页面找到了,却推荐了错误变体

以下“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. [1] WooCommerce Developer Docs — Store API overview (checked 2026-09-13)
  2. [2] WooCommerce Developer Docs — Products API and stock/catalog filters (checked 2026-09-13)
  3. [3] WooCommerce Developer Docs — Extending Store API product data (checked 2026-09-13)
  4. [4] WordPress Developer Resources — REST API Handbook (checked 2026-09-13)
  5. [5] Google Search Central — JavaScript SEO basics and rendered HTML (checked 2026-09-13)
  6. [6] Google Merchant Center — Product data specification: price and availability (checked 2026-09-13)
  7. [7] Google Merchant Center — Structured data for product pages (checked 2026-09-13)

继续了解