零售电商GEO踩坑复盘：商品列表页懒加载让 AI 爬虫只抓到八分之一的商品，前端改造全程记录

适用读者：电商前端工程师、负责独立站/自营商城 SEO 技术优化的团队；正在排查"AI 引擎只引用了部分商品"问题的技术负责人。文中示例基于 Vue 3 + Nginx，思路同样适用于 React 等其他前端技术栈。

这是一次典型意义上的"前端无感知、AI 引擎有感知"的踩坑。我们接手的一家家居用品电商，站内 SKU 一千二百多个，商品详情页早就配好了 Product Schema，团队以为结构化数据做完就万事大吉。结果用 DeepSeek、豆包问品类选购问题（比如"预算三千以内买什么材质的餐桌"），AI 回答里引用的永远是那固定的十几款商品------全站八分之一的 SKU 反复出场，剩下的一千个商品像不存在一样。

排查到最后，问题不在 Schema、不在内容质量，而在商品列表页的懒加载与无限滚动。这篇文章把整个排查、定位、改造、验证的过程完整记录下来，给同样在用"加载更多"的电商团队提个醒。

一、现象：AI 引擎只认识列表页第一屏的商品

先复述现象。用不同 AI 引擎问了二十多个品类选购类问题，统计回答中引用的商品 SKU 分布：

观察项	数据	说明
被引用过的 SKU 总数	156 / 1247	仅 12.5% 的商品在 AI 回答中出现过
被引用 ≥3 次的 SKU	38 款	集中在"新品推荐"和"热销榜"
引用来源 URL 的类型分布	列表页 71%、详情页 29%	AI 大量引用列表页而非详情页
被引用 SKU 与列表页首屏位置的相关性	极强	前 2 屏商品占引用量的 83%

第三行数据是破案关键：AI 引擎大量引用的是列表页。回头检查列表页源码，问题一目了然------列表页 HTML 里只服务端渲染了前 24 个商品卡片，其余商品全部依赖 JS 调接口懒加载，且用的是"点击加载更多"按钮，不是滚动自动加载。AI 爬虫不执行点击，也不触发 IntersectionObserver，一千多个商品在它眼里只有 24 个。

更隐蔽的第二层：分页参数对 AI 爬虫不友好

我们本来以为改成分页就能解决，但翻看 Nginx 日志发现，即便改成 ?page=2 这种链接，AI 爬虫也很少主动翻页------它不会像搜索引擎那样发现并跟随分页链接。也就是说，靠"爬虫自己翻页"这条路径在 AI 时代基本走不通，必须让每个品类的重要商品在静态可达的 HTML 里出现。

二、日志验证：AI 爬虫到底抓了什么

用一周的 Nginx 日志验证上述推断。筛选四类 AI 爬虫 UA，统计其请求路径分布：

请求路径类型	占比	典型表现
首页 / 品类列表页（第 1 页）	68%	每个品类只抓第 1 页
列表页第 2 页及以后（?page=N）	4%	几乎不翻页
商品详情页	22%	从列表页第 1 页的链接进入
API 接口（/api/products?offset=）	6%	个别爬虫试探后放弃

日志数据把结论钉死了：AI 爬虫的行为模式是"抓一个入口页 + 顺着首屏链接进详情"，不做任何翻页和交互。列表页第 1 页装不下你的商品，等于其余商品在 AI 的世界里被除名。

快速验证用到的日志统计脚本很简单，贴出来供大家复用：

python 复制代码

# analyze_ai_crawler.py：统计 AI 爬虫的路径分布
import re
from collections import Counter

AI_UA = re.compile(r"GPTBot|PerplexityBot|Bytespider|DeepSeekBot|ClaudeBot", re.I)
PATH_TYPE = [
    (r"^/category/[^?]*$", "category_p1"),
    (r"^/category/.*[?&]page=[2-9]", "category_p2plus"),
    (r"^/product/", "product_detail"),
    (r"^/api/", "api_call"),
]

counter = Counter()
with open("access.log", encoding="utf-8", errors="ignore") as f:
    for line in f:
        m = AI_UA.search(line)
        if not m:
            continue
        path = re.search(r'"(?:GET|HEAD) (\S+?) ', line)
        if not path:
            continue
        url = path.group(1)
        for pattern, label in PATH_TYPE:
            if re.search(pattern, url):
                counter[label] += 1
                break

total = sum(counter.values())
for label, n in counter.most_common():
    print(f"{label:16s} {n:6d}  {n / total:6.1%}")

三、改造方案：让"人的体验"和"爬虫的体验"分叉

改造的核心思路不是推翻懒加载------懒加载对真人用户依然是正确的性能优化------而是给 AI 爬虫提供一条静态可达的平行路径。我们做了四件事，按投入产出排序：

1. 列表页 SSR 直出关键商品集合

每个品类页的服务端渲染部分，从"前 24 个商品"改成"分品类精选集合"：热销 Top 40 + 新品 Top 20 + 库存告急 Top 10，去重后约 60 个商品卡片直出 HTML。这部分数据缓存在 Redis，TTL 10 分钟，服务端渲染开销完全可控。

为什么是"精选集合"而不是"前 60 个"？因为前 60 个是按默认排序（销量）截断的，和原来前 24 个高度重叠，新增的可见商品只有三十多个。精选集合的三个来源覆盖了不同的提问意图：热销对应用户问"什么牌子卖得好"，新品对应"最近有什么新款"，库存告急对应促销期提问。这个设计后来被证明是引用分布均匀化的关键------改造后 AI 引用的 SKU 集中度明显下降，不再全是销量头部商品。

2. 静态化"品类精选"子页

对 Top 20 的核心品类，生成静态精选页 /category/{slug}/top，每页完整列出该品类 80 个重点商品，带标准分页链接互链。这个页面真人用户也会用（相当于官方导购页），不是纯给爬虫的 doorway page------这一点很重要，无价值复制品会被 AI 引擎降权。

精选子页的生成交给了构建流程：每天凌晨跑一次全量重建，商品池内数据变更时触发增量刷新。页面用最朴素的服务端模板直出，不引入任何前端框架的水合过程，保证响应体在没有 JS 的环境里完整可用。上线后这批页面的日志占比（第三节的表格里那 27%）验证了它们对 AI 爬虫的真实吸引力------爬虫会主动发现并反复抓取这些信息密度高的页面。

3. 懒加载保留，但首屏兜底

Vue 侧把"加载更多"改为默认触发前自动加载两屏内容，同时首屏卡片不参与懒加载（去掉 loading="lazy"，不用 JS 占位渲染），保证不执行 JS 的客户端也能拿到首屏完整 DOM。

html 复制代码

<!-- 改造后的商品卡片：首屏卡片静态直出，图片不用 lazy，链接真实 href -->
<div class="product-card">
  <a href="/product/oak-dining-table-odt601">
    <img src="/img/odt601-main.jpg" alt="白橡木实木餐桌 ODT-601，1.6米四人位"
         width="400" height="300">
    <h3>白橡木实木餐桌 ODT-601 · 1.6米四人位</h3>
    <p class="price">¥2,499 <span>直降300</span></p>
  </a>
</div>
<!-- 首屏之外的卡片才用 IntersectionObserver 懒加载 -->
<div class="product-card" data-lazy="/api/products?category=dining&offset=60">
</div>

4. 商品卡片标题升级为"属性词 + 品名"

原来卡片标题只写"ODT-601"，改造后统一输出"材质 + 品名 + 规格"。AI 引擎回答"什么材质的餐桌"这类问题时，靠的正是这些属性词匹配。改动只涉及列表渲染模板一行，但直接决定了商品能否命中属性型提问。

图片这一层也顺手做了一遍治理：首屏商品图补齐了描述性 alt 文本（材质、规格、使用场景），而不是模板里默认的文件名。随着多模态 AI 引擎普及，图片正在成为独立的内容入口，豆包联网版已经会引用带清晰 alt 的商品图。另外把详情页首图的 loading="lazy" 去掉了------首图懒加载除了拖慢 LCP，对爬虫没有任何好处，这是纯习惯性写法留下的坑。

改造过程里最费时间的其实是跨团队沟通：精选集合的商品池需要类目运营确认，"库存告急"的定义需要和供应链对齐口径，卡片标题的属性词模板需要文案审核。技术上三天的工作量，前后拉扯了两周。这也是我们后来复盘时反复强调的一点：GEO 改造一半是工程问题，一半是内容治理问题，排期时别按纯技术项目的节奏估。

四、改造后 35 天的验证数据

四项改造分两批上线（8 月 20 日直出集合上线，9 月 1 日精选子页上线），对比数据如下：

补充一个验证环节的细节：为了排除"AI 回答引用了但链接点不开"的干扰，我们把 AI 回答里出现的本站 URL 全部做了可达性回归，顺带修出了三个因为改造引入的 404（都是精选子页分页翻过头的边界页）。引用链路的终点必须是活页面，这最后一公里的检查别省。

指标	改造前（8 月第二周）	改造后（9 月第二周）	变化
AI 回答中被引用 SKU 数	156 / 1247	489 / 1247	12.5% → 39.2%
列表页第 1 页平均包含的商品数	24	61	+154%
AI 爬虫抓取品类精选子页的会话占比	0%	27%	静态平行路径生效
属性词型提问（"什么材质""适合小户型"）的引用命中率	9%	34%	卡片标题升级的直接收益
详情页跳转型引用（引用具体 SKU 页）	29%	46%	引用质量提升

最后一个指标值得强调：引用从"引用列表页"转向"引用具体商品详情页"，说明 AI 不再只是泛泛地提及你的站点，而是精确推荐到商品。对转化而言，这两种引用的价值差一个量级。

五、误区澄清与收尾

误区一：不要一刀切拆掉懒加载。真人用户的加载体验依然重要，正确的姿势是"首屏静态兜底 + 后续懒加载 + 给爬虫一条静态平行路径"，三者共存。

误区二：不要给爬虫单独返回精简版页面。基于 UA 返回不同内容属于 cloaking，AI 引擎对这类行为的惩罚比搜索引擎更直接。我们选择的路径是同一份 HTML 同时服务两类访客，精选子页对真人也有导购价值，这才是可持续的做法。

趋势上看，AI 爬虫的抓取行为比搜索引擎更"保守"：更少的页面预算、更浅的交互能力、更强的首屏依赖。前端团队需要把"不执行 JS 的浏览器里站点长什么样"重新纳入验收标准------这曾经是上个时代的 SEO 常识，在 AI 时代以更高的权重回来了。

整场改造没有动后端数据模型，没有改任何商品数据，纯粹是前端渲染策略与页面结构的调整，两批上线合计三个工作日。如果你的站点也在用无限滚动或"加载更多"，建议先跑一遍上面那段日志统计脚本，看看 AI 爬虫的真实路径分布，再决定要不要动手术。欢迎在评论区交流你们站点的抓取路径数据。

关键词：GEO、AI优化AIO、懒加载、SSR直出、AI爬虫抓取、无限滚动、商品列表SEO、Vue性能优化