Cloudflare日志显示AI助手访问Shopify店铺次数远超实际点击量

Arber Xhindoli · 2026年11月2日 · 10分钟阅读 人类创意 · AI撰写 · 人工审核 Arber Xhindoli 构思了观点与案例，主导了论证方向，并审核了最终文章。文字部分由 AI 撰写。

如果你问一位店主 AI 给他们带来了多少流量，他们会打开 Google Analytics。本文提到的这家时尚品牌，GA4 在 30 天内记录了来自 ChatGPT 的 121 次会话，远不到网站总流量的 1%。按这个口径衡量，AI 的贡献几乎可以忽略不计。

但同一时段的服务器日志显示的却是另一番景象。ChatGPT 和 Claude 为用户提问而打开该商店页面的次数达到 1,264 次。它们不断请求商店已经不再销售的商品，猜测店面并不提供的 Shopify 地址，而这些日志中还混入了约 10,600 次伪装成 AI 爬虫的机器人请求。这些都不会出现在分析工具里，而其中一部分还指向了商店一天之内就能完成的修复。

该品牌通过一个 headless Shopify 店面销售服装：前端为自研，运行在 Cloudflare 上，结账由 Shopify 处理。我们隐去了品牌及其产品的名称。

店面中的一个 Cloudflare Worker 会把来自机器人、AI 助手以及从 AI 回答跳转而来的访客的请求副本转发给 Canonry。Canonry 会对每个请求进行分类，并将每个机器人的 IP 地址与其运营方公布的地址段进行比对。访问与购买数据来自该商店的 GA4 媒体资源。统计窗口为 2026 年 10 月 3 日至 11 月 1 日的 30 天，下文所有数字均来自这两个来源。

这里有三类请求值得关注，它们很容易被混为一谈：

AI 爬虫与用户触发的抓取如何区分，详见《Classifying AI crawlers and user fetches》一文。

ChatGPT 和 Claude 为用户抓取了 1,264 次页面

ChatGPT 抓取了该商店页面 1,100 次，带来 121 次访问，大约每 9 次读取对应 1 次访问。Claude 抓取页面 164 次，GA4 未记录到任何来自它的访问。Perplexity 也没有带来访问。Gemini 带来了 1 次。

读取对商店的分析工具不可见，因为助手是从自己的服务器抓取页面的。页面的 JavaScript 从未运行，因此 GA4 标签也不会触发。用户得到的回答可能参考了该页面，但本人可能从未访问网站。

首页是助手读取最多的页面，在已验证的读取中占 357 次。它们经常读取的其他页面包括一个热门商品页、关于页面、一个商品系列页，以及配送、联系和退货页面。其中好几个页面回答的是关于这家企业的问题，而非关于某个产品。

实际发生的访问大多来自手机。10 月 22 日至 11 月 1 日期间，有 69 位访客从 AI 回答跳转而来，其中 68 位来自 ChatGPT，69 人中有 42 人在 iPhone 上使用 Safari。在他们的 70 次访问中，27 次从首页开始，24 次从商品页开始。访问中位数浏览了 2 个页面，有 32 次访问只浏览了 1 个页面。7 次访问是通过 ChatGPT 购物结果中的商品链接进入的。

在更长的 90 天窗口内，ChatGPT 带来了 370 次会话，产生 4 笔购买，转化率为 1.1%。全站转化率为 2.4%。4 笔购买太少，不足以称为趋势，但与上面的漏斗相符：在这家商店，ChatGPT 读取的量远大于它卖出的量。

30 天内，ChatGPT 请求了 28 个已不再销售的商品页面，总计 81 次。其中一款已停产的夹克占了 17 次请求。搜索爬虫的规模更大：来自 Google、Amazon、Bing 等的已验证机器人请求了 273 个发生重定向的商品 URL，共计 2,166 次。

店面处理缺失商品的方式是重定向到 /404，而 /404 页面以 HTTP 200 响应，也就是正常页面的状态码。搜索引擎称这种情况为软 404。对爬虫或助手来说，一个已不存在的商品看起来就像一个正常页面，只不过内容碰巧写着“未找到”。

日志无法显示助手拿这个页面做了什么。但日志确实显示 ChatGPT 在一个月内 17 次回到同一个已下架夹克的 URL，这说明该 URL 仍存在于 ChatGPT 回答用户关于该品牌问题时所用的某处信息中。最后这一点是我们的推断，日志本身无法证明。

在 headless 店面中，决定缺失商品返回什么的是前端，而不是 Shopify。因此我们向该商店的开发者提出了分三部分的修改建议：

对一个已停产且没有相近替代款的款式，返回普通的 404。 将其重定向到一个通用分类页，会把购物者送到他们并不想去的地方，而且 Google 可能本来就会把这类重定向视为软 404。

Claude 一直在请求标准 Shopify 商店提供、而这家商店不提供的地址。 已验证的 Claude-User 请求发往 /products.json、/products/<handle>.json 和 .js(Shopify 的商品数据 URL)，以及 /pages/contact、/pages/shipping、/pages/size-guide、/policies/privacy-policy 和 /policies/terms-of-service。30 天内，其中 18 个请求失败。

在标准的 Shopify Online Store 中，政策页面和商品数据 URL 默认存在，/pages/contact 页面也很常见。而这个 headless 店面使用自己的路由，例如 /contact 和 /shipping-and-delivery，因此每一次猜测都撞上了重定向或 404。我们的解读是，Claude 识别出这是一家 Shopify 商店(因为结账运行在 Shopify 上)，于是尝试了标准路径。

修复方法是在店面配置中加一小串重定向。Shopify 的 /pages/* 地址指向店面中同名的页面，名称不一致的地方显式列出对应关系。/policies/* 页面指向店面的隐私、条款、配送和退货页面，商品数据 URL 指向商品页。这不会带来任何成本，而猜 Shopify 路径的助手会得到正确的页面，而不是一个错误。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）