AI 搜索商品页 SEO 检查清单

AI 搜索商品页 SEO 检查清单：Schema、Feed 与商品事实

AI 搜索没有取代传统商品页 SEO，而是把商品事实不一致的问题放大了。商品页仍然需要清晰标题、可抓取内容、稳定移动端体验和 canonical URL；但现在团队还要让页面可见内容、Product JSON-LD、变体属性、图片、政策和 Merchant Center feed 指向同一套商品事实。

这份检查清单适合已经有 DTC 商品页、但希望页面更容易被 Google Search、Google Shopping、AI Mode 式购物体验以及其他商品发现系统理解的团队。重点不是做一堆孤立的 SEO 字段，而是减少可避免的歧义，让 crawler、feed 和分析报表读到同一组事实：页面内容、Product JSON-LD、Merchant Center 数据、图片、变体、配送、退货和 analytics 标记。

商品页 SEO 发生了什么变化

Google 的 Product structured data 文档把 product snippets 和 merchant listings 分开。Product snippets 更偏向展示评分、价格、库存等信息；merchant listings 面向可以直接购买的页面，支持更具体的商业字段，例如配送、尺码、退货和变体。Google 也建议把页面级结构化数据与 Merchant Center feed 结合使用，因为两类数据能帮助 Google 理解和校验商品信息。

AI 购物会进一步提高对属性完整度的要求。Google 在 2025 年 5 月 20 日介绍 AI Mode shopping 时提到，AI Mode 会结合 Gemini 能力和 Shopping Graph，而 Shopping Graph 包含带有评价、价格、颜色、库存等细节的商品 listing。2026 年 5 月 27 日，Google Merchant Center 又宣布 AI performance insights，其中包括 product attribute insights 和 attribute completeness score，用来发现缺失的结构化商品属性。

这意味着 PDP SEO 不能只当成文案优化来做。它更像一套商品数据质量工作流：页面写什么、schema 写什么、feed 写什么、图片和库存如何对应，最后都要能互相解释。

检查 1：先确认页面可抓取、可索引、canonical 稳定

在修改 schema 之前，先检查基础项：

商品页 canonical URL 能稳定返回 200。
canonical URL 与结构化数据里的 URL、sitemap、Merchant Center feed link 保持一致。
robots、noindex、登录墙、地区跳转不会挡住商品页。
多语言商品页有一致的 alternate/hreflang 关系，不在同一个页面里混用多种语言。
变体 URL 的策略是明确的：要么每个变体有自己的 canonical 页面，要么在父商品页面下清楚表达变体。

如果这些基础项不稳，结构化数据只会让冲突更容易暴露。比如 feed 指向一个 URL，schema 写另一个 URL，canonical 又落到第三个 URL，搜索系统很难判断哪一个才是主版本。

检查 2：让页面可见事实与 Product JSON-LD 对齐

PDP 上的 Product JSON-LD 应该描述用户在同一个页面上能看到的内容。优先审计这些字段：

商品名称和商品描述。
可抓取、与商品相关的图片 URL。
SKU、MPN、GTIN、brand 等可用标识。
Offer 数据，例如 price、currency、URL、availability 和 condition。
只有在真实评论数和评分数据存在时，才使用 aggregateRating。

不要把隐藏卖点、虚构评论或页面上没有表达的政策写进结构化数据。Google 的结构化数据指南要求 markup 真实代表页面内容；误导性 markup 会带来质量风险。这里的重点不是把 schema 填满，而是让它成为页面事实的机器可读版本。

检查 3：区分 Product schema 和 merchant listing 深度

Product schema 不是一个大勾选框。Google 会分别处理 product snippets、merchant listings、variants、shipping、returns、loyalty 和 policies。PDP 审计要问两个问题：

当前页面级 Product JSON-LD 能可靠表达哪些事实？
哪些字段更应该放在 Merchant Center feed 或 merchant listing markup 里？

例如价格和库存可能同时出现在页面 markup 和 feed 里。配送和退货可能来自 Merchant Center、商品级 merchant listing markup，或组织级政策 markup。Google 文档也说明了 shipping 与 return 配置的优先级关系，所以团队要避免在多个地方维护互相冲突的值。

检查 4：让页面、feed 和库存事实保持一致

AI 搜索和购物表面对过期商品事实很敏感。重点检查这些字段在 PDP、feed 和后台记录里的关系：

原价、促销价和促销生效日期。
availability、preorder/backorder 状态和 availability date。
主图和附加图片。
brand、GTIN、MPN 和 identifier exists。
Google product category 和 item group ID。
size、color、material、pattern、gender、age group 和 size system。
对购买决策有影响的 shipping weight/dimensions 和 product dimensions。

实用规则很简单：用户看到的页面、schema 和 feed 不应该在“这是什么商品、有没有货、多少钱”这三个问题上互相打架。

检查 5：像商品发现系统一样审计属性

属性完整度重要，是因为用户会用自然语言问商品问题。不要只围绕一个关键词优化标题，还要看页面能不能回答常见购买过滤条件：

这件商品是什么材质？
支持哪种尺码、版型或兼容规格？
当前展示的是哪种颜色、表面处理或款式？
这个 SKU 代表单品、套装、组合装还是某个变体？
页面面向哪个市场、语言和货币？
配送、退货和库存政策如何影响购买判断？

Google 2026 年 5 月的 Merchant Center AI insights 公告在这里很有参考价值：它专门提到 product attribute insights 和 attribute completeness score。这说明商品属性不是后台小字段，而是 AI 购物发现和比较过程里的基础材料。

检查 6：让图片可索引、可理解、能对应变体

商品图片不是装饰。审计时要确认：

主图来自可抓取 URL。
结构化数据里的 image URL 指向真实相关的商品图片。
alt text 用自然语言描述商品，不堆砌关键词。
能区分变体时，图片与所选变体保持对应。
CDN 转换不会阻止 Googlebot，也不会只生成临时 URL。

Google 的结构化数据指南要求结构化数据使用的图片 URL 可以被抓取和索引。图片本身访问不到，就无法支撑更丰富的商品展示。

检查 7：上线后用 Search Console 和 Merchant Center 复盘

发布后不要凭感觉判断效果。至少看这些层：

Search Console 的 Product snippets 和 Merchant listings 报告，用来处理 warnings 和 invalid items。
Search Console Performance report，看 impressions、clicks、CTR 和 rich result appearance。
Merchant Center diagnostics 和 feed issue report，看商品数据问题。
市场可用时，查看 Merchant Center AI performance insights。
店铺第一方分析，看商品页访问后的加购、结账和订单行为。

这应该是一个循环：修复 invalid items，检查 live URL，请求验证，然后在模板或 feed 改动后比较 Search Console 与 Merchant Center 的变化。

Foundax 如何支持这套工作流

Foundax 适合把这件事作为运营工作流来做，而不是让 SEO、商品、feed 和 analytics 各自维护一套事实：

已发布 PDP runtime 可以在底层数据存在时输出包含 Product、Offer 和 AggregateRating 字段的 Product JSON-LD。
SEO 工作台支持 metadata、canonical、sitemap、Search Console 验证和 sitemap 提交流程。
GMC preflight 与 sync 使用严格的对齐模型：必填字段先通过检查，再进入提交；商家提供的事实仍然是 source of truth。
商品导入模板和结构化商品记录帮助团队在同一套运营模型里维护 SKU、属性、图片、价格和 GMC 字段。
多语言店铺和内容工作流可以帮助本地化页面与发现路径保持一致。

AI 搜索更需要这种框架：从商品记录到公开页面，再到 merchant feed，每一层都少一点数据错位，后面的分析才更可用。

30 分钟 PDP 审计顺序

审计重点商品页时，可以按这个顺序走：

打开线上商品页，确认 canonical、语言、标题、描述、图片、价格和库存。
检查渲染后的 Product JSON-LD，并与页面可见内容逐项对照。
在 Merchant Center feed 里找到同一个 SKU 或 item group。
查看 Search Console Product structured data 报告里的 warnings 和 invalid items。
判断缺失字段是否对应真实购买过滤条件。
先修源商品记录，再重新生成页面、schema 和 feed 输出。
复测 live URL，并在 recrawl 后观察 Search Console 与 Merchant Center。

FAQ

Product schema 应该承担什么角色？

Product schema 应该把页面上的真实商品事实转成机器可读格式，包括身份信息、图片、offer、真实评分、配送、退货和变体上下文。它的价值是让可见 PDP、结构化 markup 和 merchant feed 更容易互相校验。

优先审计哪些字段？

先看 title、description、images、SKU 或标识符、brand、price、currency、availability、canonical URL 和 variant attributes。这些字段最容易跨页面、Product JSON-LD 和 Merchant Center feed 对照。

Product snippets 和 merchant listings 有什么区别？

Product snippets 偏向搜索结果里的商品信息展示，例如评分、价格和库存。Merchant listings 面向可以购买的页面，支持更多商业字段，例如配送、退货、尺码和变体。

每个商品页都要加 FAQ schema 吗？

只有当页面真的有面向买家的 FAQ 内容，并且实现方式支持相应 markup 时才需要。为了清单而添加用户看不到的结构化数据，会让页面质量变差。

商品页 SEO 多久复查一次？

模板改动、feed 改动、价格或库存自动化改动、大规模本地化更新，以及 Search Console 或 Merchant Center 出现 warning 后都要复查。高流量 SKU 应该按固定节奏巡检。

Foundax 在这里具体帮什么？

Foundax 把商品记录、PDP metadata、Product JSON-LD、sitemap/Google 工作流和 GMC preflight/sync 放在同一条运营路径里，减少页面、schema 和 feed 的错位风险，同时让商家继续掌握业务事实。

参考资料

延伸阅读

如果要先理解整体发现机制，可以阅读商品数据正在成为 AI 电商发现的 SEO 层，再用Agentic Commerce 商品数据指南梳理 catalog、feed 与店铺字段优先级。

AI 搜索商品页 SEO 检查清单：Schema、Feed 与商品事实