AI搜索时代，页面性能优化如何兼顾AI可读性？

上个月我们团队开了一次很诡异的例会：性能看板全线飘绿，LCP稳定在1.8秒以内，CLS控制在0.02，INP也压进了200毫秒以下——按任何指标来衡量，这都算一份相当漂亮的成绩单。可就在同一周，客户丢过来一份AI搜索产品的测评报告：我们的核心页面在三个主流AI搜索工具里，要么根本不引用，要么引用的是三个月前的旧快照。那一刻我们才意识到，过去半年我们一直在用传统搜索引擎的思路做页面性能优化，而AI搜索的胃口，完全不是我们想的那样。

这篇文章不是“AI搜索优化怎么做”的标准答案，而是我们团队从踩坑到爬出来的完整复盘。里面记录了我们在“页面性能”和“AI搜索优化”这两个目标之间反复拉锯的过程：为什么优化到极致的页面反而被AI忽略，AI抓取器的行为模式和Googlebot有什么本质差别，以及我们最终摸索出的那套“既快、又能被大模型读懂”的工程方案。适合正在负责页面性能优化、又突然被老板问到“为什么AI不引用我们内容”的团队参考。

1. 性能指标和AI可读性：被忽略的结构性冲突

先说一个让我印象特别深的场景。我们当时把页面加载性能优化到了极致，甚至为了保证CLS为0，给所有图片都手动指定了宽高占位，给所有异步组件都写了骨架屏。结果用GPTBot模拟抓取一看，AI拿到的HTML里，正式文章内容只占整个文档的不到30%。我们把“视觉呈现的完美”误当成了“内容可读的完美”，这俩根本是两回事。

1.1 两个KPI体系之间的矛盾根源

传统页面性能优化，本质是围绕浏览器的渲染管线做优化。核心目标是让像素更快出现在屏幕上、让用户交互不被阻塞。所以我们会做代码分割、懒加载、客户端渲染、资源预加载——这些手段的共同特点，是“内容可以晚点到位，但视觉体验不能差”。

可AI搜索的抓取器不是这样工作的。无论GPTBot、ClaudeBot还是PerplexityBot，它们本质上是一个“戴着高度近视眼镜、逐字逐句读HTML源码”的读者。它们不关心你的动画流不流畅，不关心你的图片是否延迟加载，它们只关心一件事：这个页面的核心信息能否被我低成本、准确地提取出来。

这里就出现了第一个深坑：我们做的很多性能优化，本质上是在把内容藏起来。比如客户端渲染，浏览器里看起来一切正常，但AI抓取器如果没有执行JavaScript，拿到的就是一块空白。比如懒加载，图片在视口外不加载，AI拿到的就是一个没有语义的占位符。比如无限滚动，第一屏只有最新两篇文章，AI以为你的页面就这么点内容。

1.2 为什么“分数漂亮”和“内容能读”经常打架

我把我们团队踩过的所有冲突场景整理成了表格，这比任何理论都直观：

这张表里最扎心的一行是“字体子集化”。我们曾经为了CLS好看，把字体加载改成了font-display: block——也就是字体没加载完之前，文本完全不显示。这在浏览器里没有任何问题，因为本地开发网络快，字体一两秒就到了。但AI抓取器远没有那个耐心，它在抓取窗口里看到的是没有文本的页面，自然就判定这个页面内容不足。

1.3 我们当时没有想明白的一个问题

回头复盘，我们最大的认知错误在于把“性能优化”当成一个孤立的技术指标问题，而不是一个“内容可达性”问题。传统SEO里有一句话叫“让搜索引擎看到的内容和用户看到的一致”，大家听得耳朵起茧，但实际落地时，绝大多数团队只做了前者——让搜索引擎能看到 —，却没人验证“AI搜索引擎看到的”和“用户看到的”是否真的是同一份内容。

这个偏差在关键词排名时代还不致命，顶多影响一下收录速度。但在AI搜索时代，它直接决定了你的内容是否会被大模型采纳。因为大模型生成答案时，它不会去看你页面的渲染效果，它只读取抓取到的文本快照，再判断这段文本和用户问题之间的相关性。如果快照本身是残缺的、顺序混乱的、语义不连贯的，那你的内容再好也白搭。

2. 从抓取日志开始：AI搜索引擎的采集行为，和传统搜索引擎完全不是一回事

当我们意识到冲突之后，团队做了一个决定：不再猜，直接看数据。我们把服务器上近三个月的访问日志全部拉出来，用UA字段过滤了一遍，结果发现了几个让我们后背发凉的事实。

2.1 AI Bot的真实抓取画像

传统印象里，搜索引擎爬虫是Googlebot那一类，UA清晰、来源固定、遵守robots.txt，而且会明确宣告自己是哪个搜索引擎。但AI时代的爬虫群体要复杂得多。

我们当时在日志里识别出的主要AI抓取器包括这些：

• GPTBot：OpenAI的抓取器，用于训练和检索增强。UA是Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible with GPTBot/1.1; +https://openai.com/gptbot，来源多为OpenAI的机房IP段。
• ClaudeBot：Anthropic的抓取器，行为特征和GPTBot不太一样，抓取频率更高，对页面大小更敏感。
• PerplexityBot：Perplexity的抓取器，它会带着一个Accept头，而且有一个明显的特点：它很看重页面抓取的“干净程度”，对正文可提取性要求极高。
• Google-Extended：这是Google为了AI产品单独出的一个抓取器标识，并非传统Googlebot。
• Applebot-Extended：Apple的AI抓取器，同样是从Applebot体系分出来的。

我们统计了一下，这些AI抓取器合起来已经占到了总爬虫流量的12%~18%，而且增长非常快。更麻烦的是，它们的行为模式和我们熟悉的Googlebot有巨大差异。

2.2 AI抓取器对页面性能的真实敏感点

先看一张表，这是我们从日志里统计出来的行为差异：

这组数据对我们的冲击很大，因为我们一直以为“Googlebot能正常抓取的页面，其他爬虫也能正常抓取”。后来才发现，Googlebot会用现代Chromium内核去渲染整个页面，等待网络请求，甚至还会等JavaScript执行完毕。而GPTBot这一类AI抓取器，很多根本不执行JavaScript，它们就是“裸抓”HTML。

那这就意味着，我们过去为了提升用户体验而做的那些JavaScript渲染方案——React SPA、Vue单页应用、动态import——在AI抓取器眼里就是一堆需要被解析的源码，而真正的内容在源码里根本不存在。

2.3 一次失败的抓取日志复盘：从“被访问”到“被采纳”之间隔着一堵墙

我们当时挑了一个流量最高的阅读页面做实验。这个页面用的是纯客户端渲染，内容全部来自接口动态加载。浏览器显示一切正常，LCP 2.1秒，交互响应流畅。

我们把UA改成GPTBot去访问一次：

bash复制curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible with GPTBot/1.1; +https://openai.com/gptbot" \
  https://example.com/article/how-to-speed-up-ai-search \
  -o gptbot_raw.html

# 查看正文区域到底有没有内容
grep -o '<article.*</article>' gptbot_raw.html | wc -l
# 0

结果清清楚楚：article标签内的内容数量是0，因为正文是JavaScript渲染的，HTML源码里只有一个空的容器节点。我们再用同样方式抓取一个服务端渲染的页面，这次article标签里的文字完整可见。

这一刻团队彻底明白了：在AI搜索的体系里，页面性能优化的核心不再是“让页面加载得快”，而是“让页面即使没有任何JavaScript、没有任何现代浏览器渲染，它的核心内容也依然可用”。我把这个叫做“裸HTML可用性”。这个概念成了我们后续所有优化方案的基石。

3. 五个让我们栽跟头的典型案例

这五个坑是我们团队在“页面性能AI搜索优化”实战中真实栽过的跟头。每一个都值回一次加班，我把它们拆开来讲清楚，包括当时的现象、排查链路和最终修复方案。

3.1 字体加载优化做过头，AI判定页面无内容

现象：一个资讯类页面，内容很扎实，每篇文章至少1500字，但连续三周在AI搜索产品里没有任何引用。初始怀疑是内容质量问题，后来用GPTBot UA抓一次，发现HTML里确实有文字，但文字都被包裹在一个visibility: hidden的样式下——因为我们的字体加载策略是等自定义字体完全加载后才显示文字。

排查链路：

1. 先用浏览器打开页面，肉眼看不到任何问题，文字显示正常。
2. 用curl -A模拟GPTBot抓取，查看HTML源码。
3. 发现正文区域的style属性里有visibility: hidden; font-family: 'CustomFont'。
4. 再查看自定义字体加载，发现字体文件有3个subset，总共约900KB，加载完之前文字一直隐藏。

修复方案：把font-display从block改成swap，确保文字在字体加载完成前先用系统字体渲染。这会让CLS有轻微上升，但换来的是AI抓取器永远看得到文本。事实上，我们用font-display: optional做了更激进的优化，它在大多数情况下根本不下载自定义字体，直接用系统字体渲染，性能损耗最小，AI抓取完全不受影响。

3.2 无限滚动：AI只抓到了第一屏

现象：我们的技术博客首页做成了无限滚动，用户往下滑轮子会不断加载更多文章。看起来体验很好，首屏加载只有两篇文章的数据，性能指标很漂亮。但AI搜索工具在引用我们首页时，永远只引用最新一篇，而且经常引用到旧文章——因为它只抓到了第一屏的两篇内容，后面的内容根本没进入它的抓取视野。

排查链路：

1. 用PerplexityBot的UA抓取首页，保存HTML。
2. 用grep统计文章链接数量：第一屏正好只有2条。
3. 对比用户真实访问时能看到的30多条文章链接，确认是懒记载导致的内容不完整。
4. 进一步检查分页逻辑，发现URL只有/?page=1，没有为爬虫提供完整的?page=2、?page=3链接。

修复方案：在无限滚动的基础上，给页面底部加了一个隐藏的分页导航，让爬虫能顺着链接抓取全部分页内容。同时把前5篇文章改成服务端直出，保证第一屏HTML里至少有5条完整信息。改动之后，AI搜索工具里我们的文章引用率立竿见影地提升了。

3.3 图片懒加载的代价：alt文本集体消失

现象：一个产品文档站，大量截图说明步骤，每张图都有详细的alt文本。可是AI搜索工具在回答“XX产品怎么配置”时，总是引用文字步骤，从不引用图片里的关键信息。我们以为是AI不支持图片理解——后来发现是懒加载导致alt文本在初始HTML里就没了。

排查链路：

1. 查看一段图片比较多的文档页面的原始HTML。
2. 发现图片标签是<img data-src="..." alt="配置步骤三" loading="lazy" />，真正的src和alt都是通过JavaScript在滚动进入视口后才注入的。
3. 在GPTBot的抓取快照里，所有loading="lazy"的图片都变成了空壳，alt属性是空的。

修复方案：对于内容页里的说明性图片，去掉loading="lazy"，使用loading="eager"确保初始加载。同时把关键信息的alt文本提炼成正常段落文字，放到图片旁边的HTML里。这样即使AI不能识别图片，也能从相邻的文本里获取同样信息。这是我们在内容组织上做的一次重要调整：把信息从“只能通过图片传达”改成“文字和图片双通道传达”。

3.4 客户端渲染导致AI看到的是空壳

现象：这个坑最经典，也最致命。我们其中一个业务线用的是Next.js，但大部分页面是纯客户端渲染模式（CSR），也就是浏览器先加载一个空的HTML壳，然后JavaScript请求接口，渲染整个界面。性能面板显示FCP只要1.2秒，但页面上真正有内容的FCP其实是2.8秒。

排查链路：

1. 用ClaudeBot UA抓取页面，保存HTML后搜索关键词，结果只匹配到<div id="app"></div>。
2. 用无头浏览器执行JavaScript后再抓取，发现内容出现了。
3. 结论：AI抓取器对JavaScript的执行能力参差不齐，直接裸抓全部失败。

修复方案：把核心内容全部改成服务端渲染（SSR）或静态生成（SSG），确保HTML源码中直接包含完整内容。不依赖任何JavaScript框架，也不依赖接口请求。只有非核心区域的交互组件保留CSR。这个改动让页面的“裸HTML可用性”从0直接提升到100%，AI抓取器拿到HTML就能提取出完整正文。

3.5 为了降低CLS做的“占位”，反而让AI抓取噪音变大

现象：我们有一个页面用组件化方式搭建，为了稳定CLS，在正文前面固定了一个大的banner占位、两个推荐位占位、一个评论区占位。从视觉上看，这些占位在用户滚动时不会导致布局抖动，很稳定。但AI抓取时，它会把整个HTML当成一个文档流来理解——先读banner的推荐标题，再读正文开头，接着读评论区——内容顺序被打得七零八落。

排查链路：

1. 把页面的正文区域单独抽出来，用纯文本模式读一遍。
2. 发现内容顺序是：“推荐阅读：XX赚钱技巧”“限时优惠”“正文第一句”“热门评论：网友A说…”“正文第二句”。
3. 这样一段语义混乱的文本，AI提取器很难判断哪些是核心内容。

修复方案：在源码层面重新组织内容顺序，把核心正文放在HTML的最前面，所有辅助区域（推荐、评论、广告位）全部挪到正文之后。同时给辅助区域加aria-hidden和role="presentation"，明确告诉机器“这些不是主要内容”。这个改动不会影响视觉布局，因为CSS完全可以用flex或grid把内容重新排序，但HTML的文档流顺序变得非常干净。

4. 我们找到的答案：以“可解读性”为导向的页面性能优化

踩了这么多坑之后，我们总结出了一套新的工作方法。核心思路只有一句话：不要以“指标绿”为目标，要以“AI能低成本读懂”为目标。这个目标达成后，传统性能指标通常也不会差，因为AI能读懂的页面，用户也一定不会觉得慢。

4.1 重新定义“AI友好且快”的页面标准

我们把“AI友好”拆成了四个可验证的硬性维度：

1. 裸HTML完整度：关闭JavaScript后，页面的核心内容是否完整存在、可读、语义连贯。这是我们最重要的衡量标准，没有之一。
2. 内容位置：核心正文是否在HTML文档流中靠前的位置，是否被大量导航、广告、推荐位包裹甚至淹没。
3. 结构化程度：是否有清晰的标题层级（h1-h3）、段落、列表、表格结构，是否用Schema.org标记了Article、FAQPage、BreadcrumbList等实体。
4. 抓取成本：页面原始HTML体积是否可控，是否含有大量无关脚本、样式、追踪代码，导致AI抓取器在有限时间内只能读到一小部分正文。

这四个维度对应的优化动作，几乎全是传统性能优化里被忽略的“脏活累活”。比如清理冗余的HTML、精简内联脚本、给图片配套文字描述，这些事不比配置CDN、压缩图片那么“高级”，但它们对AI搜索的友好程度有决定性影响。

4.2 技术栈调整：SSG优先，CSR只做配角

经历过客户端渲染的教训后，我们的技术选型原则变成了：核心内容必须服务端直出，交互部分可以客户端增强。

如果你用的是Next.js或Nuxt，具体来说是：

• 页面级优先用generateStaticParams做静态生成（SSG），把内容在构建时就固化到HTML里。这样AI抓取时，拿到的HTML就是完整的静态文档。
• 对于需要实时数据的页面，用SSR（服务端渲染）而非CSR。服务端渲染出来的HTML同样包含完整内容，只是增加了服务器端渲染的耗时。我们在实践中发现，只要把缓存策略做好，比如Cache-Control: public, s-maxage=300，SSR的性能损耗完全可以接受。
• 实在没法做服务端渲染的页面，至少使用prerender方案或动态渲染（dynamic rendering），保证抓取器拿到的是渲染后的HTML。

代码层面还有一个容易被忽略的细节：在React里，useEffect里发请求渲染数据是最典型的CSR陷阱。我们要求团队把这类逻辑改成getServerSideProps或generateStaticParams之后再落到页面组件里，而不是在客户端用Effect去拉数据。

4.3 内容组织的GEO优化：让大模型“愿意引用”你

“页面性能AI搜索优化”里，性能解决的是“AI能不能读到”，但真正决定“AI愿不愿引用”的，是内容组织方式。这部分就是现在非常火的GEO——生成式引擎优化（Generative Engine Optimization）。简单说，就是让内容结构适配大模型的检索和摘要机制。

我们总结了一套比较实用的内容组织规则：

• 答案先行：每个页面的前100字内直接给出核心答案，不要铺垫。AI在提取摘要时，通常会把开头当作答案的锚点。
• FAQ结构：在正文后面加一个清晰的FAQ区块，每个问题一句话，下面直接跟答案。AI模型在回答具体问题时，直接匹配FAQ能显著提升被引用的概率。
• 表格优先：能用表格表达的对比信息，尽量用表格。大模型对结构化表格的提取准确率远高于自由文本。
• 明确的段落边界：不要写超过300字的超长段落，每段聚焦一个观点。模型切分文本块（chunk）做向量化时，段落边界清晰的文本召回率更高。
• 实体与关系显式化：在文中明确写出“A属于B”“A的B指标是C”这样的断言句式，让模型更容易抽取实体关系。这比隐晦的隐喻式表达要有效得多。

我给一个对比示例。优化前你可能会写：

有研究表明，页面加载速度对用户体验有着重要影响，这可能影响用户留存，也可能影响转化率，而且不同行业的影响程度存在差异，所以我们在进行性能优化时应该综合考虑多方面因素。

优化后改成：

页面加载速度直接影响用户体验。数据显示，加载时间每增加1秒，移动端用户跳出率提升约15%。在内容型网站中，这一影响更明显。因此，页面性能优化的第一优先级应该是缩短服务端响应时间。

后者的大模型友好度明显更高，因为它有明确的数据、明确的因果链条、明确的排序结论。

4.4 现代工具的取舍：哪些性能优化动作值得保留，哪些该放弃

既然核心标准变成了“裸HTML的完整度”，那传统性能优化的部分动作就需要重新评估。我按我们的实践给了一份建议清单：

这张表不是绝对的，但如果你看到某个优化动作会让原始HTML里的核心内容变少，那就要警惕了。在AI搜索时代，这个动作很可能是在“优化性能”的同时“杀死可见性”。

5. 用数据说话：AI搜索优化的度量与月度巡检

说了这么多实操，最后分享一套我们正在用的度量体系和巡检方法。没有度量，你很难知道自己的“AI搜索优化”到底有没有生效。

5.1 三类关键指标

我们分成了抓取质量、内容理解、流量结果三层来看：

抓取质量层

• AI抓取器访问次数：在日志里按月统计GPTBot、ClaudeBot、PerplexityBot等的访问总量，观察趋势是否增长。
• 抓取深度：AI抓取器是否访问了二级、三级页面，还是一直停留在首页。
• 抓取内容完整度：用模拟UA抓取页面HTML，统计正文字数与源码中实际出现的正文字数的比例。100%是理想状态。

内容理解层

• 结构化数据校验：用Google Rich Results Test或Schema.org验证工具，确保Article、FAQPage等结构化数据无报错。
• 关键实体识别：用LLM或关键词提取工具检查，AI模型是否能从页面中正确抽取核心实体。
• 语义答案匹配：针对目标用户的常见问题，看页面是否能给出直接、清晰的回答。

流量结果层

• AI推荐带来的访问：在GA4里通过referrer信息识别来自AI搜索产品的访问。
• 品牌提及率：定期用AI搜索工具提问，看自己的品牌或域名是否出现在答案中。
• 引用率变化：跟踪核心页面在AI答案里被引用的次数，这是最终的KPI。

5.2 我们每月的AI搜索巡检流程

我直接贴一份我们团队在用的巡检脚本思路，你可以照抄：

第一步，用模拟UA批量抓取核心页面，检验裸HTML内容完整性：

bash复制#!/bin/bash
# check_ai_readiness.sh
UA="Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible with GPTBot/1.1; +https://openai.com/gptbot"
for url in $(cat core_pages.txt); do
  echo "Checking: $url"
  curl -s -A "$UA" "$url" -o /tmp/ai_page.html
  # 提取正文区域文本
  python3 -c "
from bs4 import BeautifulSoup
html = open('/tmp/ai_page.html').read()
soup = BeautifulSoup(html, 'html.parser')
article = soup.find('article') or soup.find('main')
if article:
    text = article.get_text(strip=True)
    print(f'正文长度: {len(text)} 字符')
    if len(text) < 500:
        print('警告：正文内容过短，AI可能无法提取有效信息')
else:
    print('警告：未找到article或main标签')
"
done

第二步，检查日志里AI爬虫的访问趋势：

python复制# analyze_ai_bots.py
import re
from collections import Counter

ai_patterns = [
    r'GPTBot',
    r'ClaudeBot',
    r'PerplexityBot',
    r'Amazonbot',
    r'Applebot-Extended',
    r'Google-Extended',
]

with open('/var/log/nginx/access.log', 'r') as f:
    lines = f.readlines()

counter = Counter()
for line in lines:
    for pattern in ai_patterns:
        if re.search(pattern, line, re.IGNORECASE):
            counter[pattern] += 1
            break

print("AI爬虫访问统计：")
for bot, count in counter.most_common():
    print(f"  {bot}: {count}")

第三步，用AI搜索工具做人工验证。我们每个季度会准备一组核心行业问题，逐个去ChatGPT、Perplexity、Gemini里提问，看答案是引用了我们的页面，还是引用了竞品页面，顺便记录答案内容是否准确。这个没法全自动化，但它是判断“优化是否真正带来引用”的最直接手段。

5.3 月度AI搜索优化检查清单

最后整理一份可以直接打印出来贴在工位上的检查清单：

1. 核心页面的HTML源码，正面正文是否在第一个屏幕内可见且无需JavaScript。
2. 所有内容图片的alt属性是否在初始HTML里存在，且描述准确。
3. 标题层级是否清晰，h1是否唯一，h2/h3是否合理嵌套。
4. 页面是否有FAQ结构化数据，且FAQ内容与正文相关。
5. 正文开头100字是否直接给出核心答案。
6. 是否有表格或结构化数据辅助说明对比信息。
7. 页面的HTML体积是否控制在合理范围（参考值：纯文本内容不超过150KB）。
8. 是否有无限滚动或懒加载影响AI抓取的隐患。
9. 检查robots.txt，确保AI抓取器没有被意外屏蔽。
10. 在日志里对比AI爬虫访问量环比变化，连续下降要警惕。

这套清单我们团队每个月过一遍，基本能把AI搜索优化的状态控制在一个稳定的水平线上。

最后分享一个心态转变

做了半年“页面性能AI搜索优化”之后，我最大的体会是：不要把AI搜索优化当成一种新的玄学，它的本质还是“让内容更容易被理解”。只不过这次需要理解你的不是某个搜索引擎的算法工程师，而是一个见多识广却不读你JS代码的大模型。

我们犯过最大的错误，就是把“性能优化”和“内容优化”当成两件事在做。性能团队追求指标，内容团队追求产出，中间完全没有人关心“AI抓取器到底拿到了什么”。现在我们的工作流变成了：任何页面在上线前，先做一次“裸HTML测试”——模拟一个不执行任何JavaScript的爬虫，看看它从这个页面能读到什么。如果它只能读到三行导航和一句“请启用JavaScript”，那这个页面不管性能指标多漂亮，都不允许上线。

这个习惯改变了一切。