Shopify怎么做GEO？从整理商品资料，到检查AI实际引用了什么

客户问 ChatGPT：“我的 MacBook 能不能用这款扩展坞接两台显示器？”对商家来说，当然希望 AI 能推荐自己的产品。但如果推荐时漏掉了芯片型号、合盖条件或接口限制，即使客户顺着推荐进入店铺，也可能买错。

因此，Shopify 做 GEO，更重要的是弄清楚：AI 获取的是哪一款商品的信息，关键条件有没有说明白，引用链接能不能支撑回答中的结论，以及客户进入店铺后能不能选到正确的版本。

GEO 是 Generative Engine Optimization，通常译为生成式引擎优化。对free-standing station团队，可以先把它理解成一项具体工作：把商品和店铺事实整理清楚，让不同入口能获取，再用真实购买问题检查回答与交易过程。

下面按从入门到深入的顺序展开：先看 Shopify 后台有哪些现成功能，再处理字段、网页和结构化数据，最后建立引用与转化的复测方法。

文中功能与路径按 2026 年 11 月 4 日的官方资料核对。真实产品例子采用 Satechi 公开商品页与支持文档；后台配置部分是 Shopify 的实施方法，不代表我们接触过该品牌后台或验证过它的 AI 渠道表现。

一、先分清楚，AI是从哪里拿到商品信息的

同一家 Shopify 店铺，可能通过 AI 的商品卡片展示商品，也可能因为一篇兼容性指南而出现在回答的引用链接中。这两种情况涉及的数据来源和检查方式并不一样。

实际操作时，可以先把工作分成两个方向。这样的划分主要是为了方便团队分工，具体到 AI 的回答中，两类信息也可能同时出现。

Shopify Catalog 会整理商品数据，供支持的购物入口使用；AI 代理也可以通过 Storefront MCP 查询已发布的 Knowledge Base。Google AI Mode、Gemini 的商品接入还涉及 Google & YouTube 销售渠道或 Merchant Center，Meta 的相关购物场景则有 Facebook and Instagram by Meta 渠道要求。不能开了一个入口，就当所有平台都已经接好。 各渠道仍要分别核对资格和商品状态。Shopify 商品发现说明

公开网页也会参与发现与回答。即使商品已通过 Catalog 共享，AI 仍可能使用品牌支持页、零售商或第三方评测；反过来，网页能被搜索到，也不能证明商品已经进入某个购物渠道。

刚开始做，不必全店同时改。可以选一批正在主推、咨询多或容易选错的商品，先保存当前资料与测试结果，再按这个顺序处理：

1. 查渠道资格与政策，确认商品具备进入目标入口的条件。
2. 整理商品字段、变体关系和店铺知识库，核对送出的内容。
3. 对齐公开网页、结构化数据和国家语言版本。
4. 用固定问题复测回答，再看访问、订单与退货变化。

等这批商品的流程跑通，再把字段规范和检查方法扩展到其他品类，后续维护起来会更顺手。

二、先把Shopify后台的商品资料整理好

很多店铺其实并不缺商品内容，真正的问题往往出在信息之间没有对应好：详情页写着最大性能，变体选项只写 US、EU；兼容条件放在产品图片里，Catalog 默认读取的描述中却没有相关信息。先把已有资料整理准确，再增加其他内容。

1. 先查目标渠道资格，不要从“找不到商品”直接跳到改文案

进入 Sales channels > Agentic，查看渠道与 Sources > Shopify Catalog 的状态。显示 Ineligible 时，先点开原因；如果当前无法取得资格结果，就保留该状态，稍后复查或联系支持，不要把它解释成商品文案问题。

以 ChatGPT 渠道为例，目前要求店铺面向美国客户销售、商品符合 Catalog 资格、接受 Agentic Storefronts 补充条款，并在 Settings > Policies 完成服务条款、隐私政策和退换货政策。店铺主体可以在美国以外。这是当前 ChatGPT 渠道的接入条件，其他渠道要看各自要求。ChatGPT 渠道要求

员工看不到 Agentic 时，先核对权限：店主可以访问；员工需要相应的 App development > View apps developed by staff and collaborators 或 App and sales channel > Agentic 权限。后台权限说明

如果同时做批发和零售，还要单独检查价格隔离。Shopify 可以识别其原生 B2B 机制，但第三方应用或定制代码隐藏的批发价格，不一定会被商品发现系统正确识别。应核对实际共享的商品与价格，并采用适合业务的 B2B 目录、身份访问及渠道设置。Unlisted 可以移出 Catalog 等发现入口，但也会影响搜索引擎、站内搜索和站点地图，不能把它当成保护敏感价格的登录权限。B2B 与发现范围说明

2. 用Listing insights找缺项，再按真实购买问题补资料

在 Agentic 的搜索预览中找到商品，展开 Listing insights，可以看到描述、图片、评价、变体选项和店铺政策这五类提示。它适合找资料缺口；分数没有解释某次 AI 排名的全部原因。

具体整理时，可以这样使用：

Shopify 的描述指标包含字数判断，评价指标只统计其可信来源验证的评价。看到提示后，仍要按商品实情处理，不能为“补齐”而堆字、堆图或制造评价。Listing insights 说明

涉及 ChatGPT 的商品，相关法律与合规披露应在描述的前 6,000 个字符内；这是披露位置要求，不是建议把每篇描述写到 6,000 字符。描述披露要求

3. 看一个真实产品，哪些资料值得优先整理

Satechi 的 Thunderbolt 4 Multimedia Pro Dock 很适合说明这个问题。对于这类扩展坞，客户经常会问：“有多少个显示接口？”但电脑能否连接多台独立显示器，还要看芯片型号和具体使用条件。这几个问题需要分开解释。

资料见 Satechi 商品页的 Tech Specs 与 Compatibility、官方包装与供电说明。

拿这类商品做自己的数据整理，第一步应先建一份事实清单：型号、地区 SKU、供电、主机条件、显示限制、来源链接及核对日期。接着决定各项放在哪：购买选项对应变体；共享参数放商品描述或已定义的产品元字段；主机兼容条件则要在正文中完整呈现，并与前台选择、提示组件使用的数据一致。

如果新增元字段，顺序应是先定义字段和类型，再填真实值，再核对页面及 Catalog 读取结果。不要只给页面加一个好看的参数模块，却留着另一份无人维护的 Catalog 描述。

整理完成后，至少能回答：“这段性能说明适用于整个产品，还是只适用于某个设备和条件？”答不清这一句，先不要把它扩写成 AI 推荐文案。

4. 核对Channel mapping，确认Catalog到底收到了什么

后台路径是：Sales channels > Agentic > Sources，点击 Shopify Catalog 旁的下拉图标，再选 Review product data mapping。

默认来源对许多店铺已经够用。只有详细内容放在其他字段、或产品分组与前台不同时，才需要定制映射。

exist Product fields 里，先看标题、描述的来源和覆盖率；点覆盖率看缺项，用 Fix [number] products 补齐。若完整描述存在元字段，就把相应来源指向它。标题、描述支持组合来源、固定文字及 Liquid；Catalog 的产品分类不能在这里映射，需要在商品资料本身正确维护。

然后切换有值、缺值和特殊规格的商品，检查预览中的实际输出。映射来源为空时回退到默认字段，是系统的正常机制。 需要判断的是回退内容能否继续准确说明商品，而不是一见 Fallback 就删配置。改动有处理延迟，应记录保存时间后再复查；预览显示的是 Catalog 接收的数据，不是某个 AI 平台最终的回答。字段映射、覆盖率与回退说明

价格还要单独看 List price：可选 Price 或 Compare-at price，后者只在高于当前售价时使用，并可通过 UCP 的 list_price 提供给代理。这个设置主要关系到原价口径，不能用来要求 AI 永远显示某个促销价。复查时应同时记录当前售价、原价、币种、变体与市场。

5. 自定义变体分组之前，先看店里是否用了Combined Listings

同系列被拆成多个独立 Product，不代表必须把它们强行合成一组。只有产品关系确实相同、分组选项又能准确区分时，才考虑 Custom variant grouping。

这里有一个会影响现有配置的条件：开启自定义分组后，Shopify Catalog 会忽略原有的 Combined Listings 分组配置，改用你选择的新方法。 它不会直接改写在线商店的产品结构，但会改变 Catalog 使用的关系。

操作前先保存当前分组、代表商品和选项；再选标题分隔符、元字段或标签前缀作为依据。在预览里核对 Group name、Products in group，并检查组合成功、保持独立、need review 三类结果。need review 可能是不同商品出现相同选项组合，应先回到数据中修正，而不是反复点保存。

对于 Satechi 这类已有地区 SKU 的商品，不能为了让列表“看起来统一”，把地区差异、另一款扩展坞或主机兼容条件混成同一组选项。分组依据应来自真实商品关系。自定义分组及其影响

三、把售前会问的店铺事实放进Knowledge Base

商品描述主要回答“这是什么、适不适合我”。但客户在购买前还会关心：能不能配送到自己的地区，退货流程是什么，产品出现问题后应该联系谁。这些属于店铺层面的事实，需要有明确来源，也需要有人负责维护。

进入 Sales channels > Agentic > Sources > Knowledge Base。AI 代理可以通过 Storefront MCP 查询已发布事实，但不同平台是否调用、怎样组织答案，由相应入口决定。

1. 先看来源和发布状态，再处理更新

Shopify 从后台政策、联系方式等设置生成的事实，创建时会发布；从前台扫描出来的事实，要审核后发布。发现 Suggested update 时，先对照现行页面，再选择 Approve & publish 或拒绝，最后保存。只改了政策网页，却没处理建议更新，可能留下两套口径。

逐项检查时，把事实内容、来源、发布状态和引用 URL 放在一起看。扫描没有识别到重要变更时，可以直接编辑，也可以用 Request rescan 请求重新扫描；官方说明重新扫描可能需要最多 48 小时。

未发布的事实不会作为该知识库的已发布答案提供给代理，但同一条信息若已经公开在网页上，仍可能被其他检索方式发现。因此，“AI 说对了”也不能反向证明知识库已发布。知识库来源、更新及发布机制

2. 用合适的格式补事实，不要把标签当作资质证明

Additional facts > Add fact 可以补充店铺特有信息：

• Paragraph 适合解释流程与条件，例如保修申请需要哪些资料、哪些情况不覆盖。
• Yes/No 适合答案确实只有是或否的问题；涉及地区或商品例外时，应另补清楚条件。
• Tags. 适合一组短值，例如有依据的材质或业务资质。不能把“行业常见”认证批量贴成自家已取得的认证。

新增后填写标题和内容，补充公开参考链接，悬停在 Unpublished 上选择 Publish，最后点击 Save。知识库上限是总计 1,000 条事实，包含自动生成与手动新增，并非还可以额外新增 1,000 条。

自定义店面和 Agentic plan 的店铺，目前只能添加 Additional facts；密码保护中的在线商店无法被扫描，显示的资料主要来自后台。旧 Knowledge Base 应用将于 2027 年 1 月 15 日停用；旧应用不超过 1,000 条事实时，自动迁移发布的是手动覆盖的店铺事实与新增事实。正在迁移的团队，应逐项核对这些内容，而不是以为旧应用的全部结果已经照搬。知识库容量、店型与迁移条件

3. References的作用是让事实有出处

每个知识库字段选择一种来源，可以附多个参考链接。给现有类别字段手动添加引用时，要先把来源改成 Manual，再点击引用数量、进入 References，添加店内公开页面或相关外部链接。改成 Manual 会移除旧来源自动提供的引用，因此要核对保留下来的链接；之后这条事实也由团队自行维护。

引用应该直接支持答案。退货条件链接到现行退货政策，保修流程链接到保修说明，不能都指向首页。更换 Reference URL 后还要核对事实文字本身，换链接并不会自动把事实内容更新好。

这些链接会随事实提供给代理，帮助其识别出处；是否在最终回答里展示引用，仍要去实际入口观察。另外，已发布知识库是公开数据，不要填内部报价、未公开客户资料或保密售后记录。References 操作与公开范围

四、让公开网页能把同一件事讲清楚

前面处理的是 Shopify 后台的数据。接下来，还要从客户和搜索系统实际访问网站的角度检查：他们看到的信息，是否与后台维护的事实一致。

1. 从具体URL排查抓取与索引

选定一个商品 URL 或政策 URL，检查响应是否正常，再查 robots.txt、页面或 HTTP 的索引指令、canonical，以及站内是否有可发现的链接。用 Search Console 的 URL 检查功能区分：页面有没有被发现、最近抓取的是哪版、抓取与索引分别处于什么状态。

robots.txt 管抓取，noindex 管索引意图，canonical 提供规范页信号。三者作用不同，不能看到政策没被引用，就直接去删 noindex。如果确实发现误设，再由开发修改相应模板或响应配置；同时保留原来有意不公开的页面边界。

Shopify 管理网络层的爬虫安全，主题可以通过 robots.txt.liquid 调整规则。阻止公开网页抓取，不会自动停止已开启的 Catalog 分享；需要退出某个渠道时，应去相应渠道设置处理。robots 规则也不是访问鉴权。Shopify 爬虫与数据分享说明

多市场网站还要把“国家、语言、币种、供货范围”一起核对。检查 hreflang、canonical、地区 URL 和落地后的实际币种，并在测试记录中注明市场。hreflang 有助于表达地区语言关系，不能保证每次 AI 都选中正确市场页面。

2. 先检查原生发现文件，再决定是否定制

Shopify 已默认提供 /agents.md、/llms.txt 和 /llms-full.txt。后两者默认镜像前者；对于多数标准店铺，不需要再买应用生成三份重复文件。

先在主域名根路径打开它们，核对店铺名称、主域名、政策和发现端点。它们没有 Markets 语言子目录的本地化副本。如果默认内容准确，继续维护商品与政策即可。

确有特殊公开文档或路由需求时，再由开发进入 Online Store > Themes > Edit code > Add a new template，按需要添加对应模板：

这类模板只提供受限的 agents 与 request Liquid 上下文，普通的 shop、collections 等全局对象不能照搬使用。定制时应保留正确的 UCP、MCP、站点地图等发现信息，并安排后续维护。它也不同于代码仓库里给编程助手看的 AGENTS.md。Shopify 发现模板说明、llms.txt 覆盖顺序

这些文件有明确用途，但不要把它们卖成 Google AI 排名开关。Google 对 AI Overviews 和 AI Mode 的说明仍强调可索引、可抓取、可靠的正文与一致的数据，不要求特殊 AI 文件或专用 Schema。Google AI 搜索说明

3. 让兼容性和参数成为正文的一部分

产品图片可以做得精致，真正影响购买判断的参数和条件，也应该能够直接从网页正文中读取。以前面的 Satechi 扩展坞为例，135W 电源与最高 96W 主机充电功率，以及基础款 M3 的合盖使用条件，都应出现在相关说明附近，不能只放在长图或图片替代文字里。

做 Shopify 整站定制时，可以把经过确认的字段渲染成参数表、兼容性分组和选中规格提示。关键内容尽量在服务端输出的 HTML 中提供，再用交互帮助客户筛选；这能减少不同读取方式下的信息缺失。并不是所有 JavaScript 内容都不能被读取，实际还要检查初始 HTML、渲染结果及目标抓取工具。

验收时，可以按实际购买顺序检查：

1. 在手机上打开商品页，切换不同版本。
2. 核对当前版本适用的条件与参数，确认选中 SKU 正确。
3. 加入购物车，检查购物车中的规格是否与选择一致。
4. 查看页面源代码或渲染检查结果，确认能找到相同的关键事实。

这样，页面设计、机器读取和实际购买使用的才是同一份商品资料。

4. 结构化数据要表达真实关系，不要只追求“检测全绿”

已有主题或评价应用可能已经输出 JSON-LD。先盘点来源，再补缺项，避免同时存在价格、库存互相矛盾的多份 Product 标记。

核对重点是：具体商品的名称、品牌和身份；对应 Offer 的价格、币种、库存与链接；变体之间的真实关系。需要表达一组变体时，按页面结构使用 ProductGroup、hasVariant、variesBy、productGroupID 等，而不是把所有版本不加区分地塞进一个 Offer。Google 变体结构化数据指南

SKU 是商家库存标识，GTIN 是全球贸易项目代码，MPN 是制造商零件编号，三者不能混用。能取得真实标识时按实际填写，不为了检测通过而编号码。MPN 定义、GTIN 定义

用 Rich Results Test 检查支持的富媒体类型，再用 Schema 校验检查语法，同时逐项对照前台文字和实际选中版本。工具无报错，只能说明通过了相应检查；不能证明模型理解正确。

FAQ 应先解决顾客的问题。Google 已从 2026 年 5 月 7 日起停止展示 FAQ 富媒体结果，因此不能把给每页加 FAQPage 当成普适 GEO 套餐。保留有用问答，按真实页面语义决定是否标记，价值比堆一项不相干的结构化数据更直接。Google 更新记录

五、检查AI实际引用了什么，要留下可复查的记录

后台预览正常，说明某一层的数据已经整理好。但客户最终看到的 AI 回答，还会受到问题表述、上下文、地区和平台处理方式的影响。想知道下一步应该修改什么，就需要把测试过程记录完整。

1. 先用Search preview检查Catalog搜索结果

进入 Sales channels > Agentic，在 Enter a search query to see how you might rank 输入商品词或购买需求，也可以选 Top search queries、Queries where your products appeared。在 Preview this search 里，查看支持的渠道预览。

保留查询、返回商品和 Listing insights，作为 Catalog 层的基线。商品没进前列时，先处理确实存在的资料缺项，再看同一查询的变化。预览是 Catalog 搜索的原始结果，各 AI 渠道可能重新排序；不能把预览位置写成客户一定看到的位置，也不能凭质量提示认定排名原因。搜索预览与排序边界

2. 把“能否发现”和“能否答对”分开测试

可以先从 15～30 个高价值问题起步，这是便于团队维护的抽样建议，不是 Shopify 或 AI 平台的官方标准。问题应来自真实售前咨询、站内搜索和退货争议，并分成两组。

不带品牌名的问题，测试在具体购买需求下是否被发现；带品牌与型号的问题，测试已知产品能否被解释准确。后者答对，不能说明前者也有曝光。

以 Satechi 的公开资料为基础，可以准备下面这些测试输入。它们是待执行问题，不是已经取得的 AI 回答。

执行前固定语言、市场、问题原文与对话条件。记录平台、模型或模式、测试时间、地区、是否登录、记忆及个性化状态，并保存完整回答、商品卡片链接与引用 URL。换一个问题表述，就另起一条记录，不覆盖旧结果。

新会话、关闭记忆有助于减少部分上下文影响，但不会消除地区、时间和模型波动。同一问题应保留重复样本，比较同条件下的变化。OpenAI 也明确说明，商品选择会受到问题、上下文与个性化影响，资料还可能来自第一方和第三方。ChatGPT 商品信息与选择说明

3. 点击引用，核对它是否真的支持那句话

逐条摘出回答中的可核查事实，例如芯片限制、充电功率、退款条件，然后打开对应引用：该页有没有写这条事实？是否有条件被省略？页面是不是旧版、错误市场，或另一个型号？

商品卡片的购买链接与回答的来源链接也应分别记录。前者可能用于交易跳转，后者用于支持解释；看到一个官网 URL，不代表回答中所有参数都来自该页。

建议每次保留一条完整记录：问题和环境、原回答、被核对的具体结论、实际引用、官网证据、偏差、待验证原因、修正记录与复测时间。 如果答案没有提供来源，就记录“未提供引用”，不能把模型声称“来自官网”当作已取证。

下面这张表用来安排排查，不代表已经发现了这些问题。

一个引用能证明 AI 在回答中提供了这个出处，但不能直接证明模型内部只读取了这一条数据。 记录时分清已知问题、可能原因和仍需验证的假设，团队就能减少没有依据的反复修改。

六、最后接到访问、订单和售后，别把几种指标混在一起

GEO 的效果要分开观察：品牌是否出现，官网是否被引用，关键事实是否表达准确，有没有带来可识别来源的访问，以及访问之后客户有没有完成正确购买。这些指标反映的是不同环节，应分别记录变化。

1. 先看Agentic报表，再明确其覆盖范围

在非无头店铺的 Sales channels > Agentic 主分析区选择时间与渠道，可以查看 Sales、Orders、Online store sessions 和 Online store conversion。也可以在 Explore > Understand your performance on agentic channels > Review 打开汇总报表。

其中 Sales 汇总引荐销售与直接结账销售；不能把它等同于“某条引用产生的销售”。当前这套 Agentic 分析尚不支持 Headless 店铺，需要在自己的分析系统中建立适用的采集与归因。Agentic 报表说明

Search Console 可以辅助判断页面抓取、索引与搜索流量，但 Google AI 功能的数据包含在 Web 搜索整体报告中，不能把 Web 点击增长直接宣布为 AI 流量增长。Google AI 流量统计口径

2. Customer events管采集，分析报告要另接

Settings > Customer events 用于管理与测试像素，不是一张现成的购买行为报表。Shopify 标准事件包括 product_viewed、product_added_to_cart、checkout_started、checkout_completed 等，但没有一个适用于所有主题和应用的标准“变体切换”事件。标准事件列表

要看“AI 进站用户有没有选错版本”，开发需要把事情接完整：在实际选择器中采集需要的自定义行为，明确商品、变体与操作含义；通过符合隐私与同意设置的像素链路送到分析工具；再用测试访问核对事件、加购的 variant ID 与后台订单是否对应。事件未记录，也可能与同意、浏览器限制或采集故障有关，不能直接解释为用户没有操作。Shopify 像素管理说明

退货原因则应来自订单、退货与售后记录。把“兼容性不符、地区规格买错、物流或质量问题”按统一口径记录，才有条件比较。统计时保持产品、市场、时间范围和样本口径可比；没有明确渠道来源时，不把全部退货变化归因于 AI 推荐或 GEO 改动。

七、整站设计与开发应该交付什么

对 Shopify 整站定制项目来说，GEO 会影响数据怎么建、页面怎么呈现、购买过程怎么确认，以及上线后怎样持续维护。它不应该停在交付几篇文章或一个发现文件。

WESWOO 在这类项目里，可以把实施范围落到三份具体交付上：

• 商品与事实清单：明确每项资料的来源、维护人、适用商品和更新位置；运营负责确认业务事实，开发处理字段与读取关系。
• 页面与数据的一致性检查：Catalog 预览、商品页、兼容提示、结构化数据与购物车规格逐项对应；需要定制的部分明确到模板、组件和数据源。
• 可重复的复测记录：保留购买问题、原回答、真实引用、发现的问题及修改前后记录，并把访问、订单与售后统计接到同一批商品上。

商品资料和政策缺项，先在后台补齐；参数只藏在图片里、变体提示与购物车脱节，再改页面与交互；多个模板或应用输出冲突数据，则由开发治理。这样安排，商家知道钱花在了哪里，也知道之后由谁维护。

下一次新品上线或政策调整时，只要沿着同一份事实清单更新后台、网页和引用，再重跑相关问题，就能继续维护这套工作。真正有用的 GEO，最终要让客户更容易找到商品，也更容易理解条件、买对商品。