核心网页指标与延迟：更快的页面能否获得更多人工智能引用？

核心网页指标与延迟：更快的页面能否获得更多人工智能引用？

简介

一个快速的网站对用户来说更容易使用。对于搜索引擎和人工智能系统来说，它也可能更容易抓取、渲染和理解。

但一个重要的区别常常被忽视：

更快的页面可能会改善抓取和内容可用性。但这不意味着速度本身会导致人工智能系统引用该页面。

截至 2026 年 8 月 2 日，Google 表示稳定的服务器响应时间和较低的延迟可以增加网站的抓取容量。Google 还表示，其人工智能搜索功能使用与传统搜索相同的基本搜索和索引系统，并且不需要特殊的人工智能标记或速度优化。 (developers.google.com)

本文提出了一项基于证据的测试计划，而非声称已完成实验。未提供任何网站、页面集、服务器日志或引用数据集。目标是定义一项受控研究，以衡量：

1. 首字节时间 的缩短是否会增加抓取频率。
2. 最大内容绘制 的降低是否会改善发现或索引。
3. 累计布局偏移 的降低是否会影响抓取或人工智能检索。
4. 性能改进是否会提高页面被人 T 工智能搜索系统明显引用的速率。

简短回答

在适当条件下，更短的首字节时间可以改善抓取

Google 当前的抓取文档指出，当网站具有稳定或改善的响应时间（包括首字节时间）时，其抓取容量限制可能会增加。如果响应时间增加，或者网站返回过多服务器错误或速率限制响应，Google 可能会减少抓取。(developers.google.com)

然而，更快的响应时间并不能保证更多的抓取。抓取需求还取决于以下因素：

• 网站更改的频率。
• 网站及其页面的受欢迎程度。
• 内容是否有用且独一无二。
• 存在多少重复或低价值的 URL。
• 更新的 URL 是否包含在站点地图中。

这意味着较低的延迟对大型、频繁更新或受服务器限制的网站应该具有最强的影响，而不一定是对内容有限的小型网站。

较低的最大内容绘制可能会间接有所帮助

最大内容绘制衡量用户何时看到主要可见内容。Google 还指出，服务器响应时间以及渲染页面和嵌入资源所需的时间都会影响抓取效率。(developers.google.com)

可能的关系是间接的：

较低的延迟 → 更快的资源交付 → 更高效的渲染或抓取 → 更少的抓取超时或不完整抓取。

当重要内容依赖于以下情况时，效果应该最强：

• 缓慢的 JavaScript。
• 大型图片。
• 渲染阻塞的样式表。
• 客户端渲染。
• 大量嵌入资源。

快速的最大内容绘制分数本身不太可能成为直接的人工智能引用信号。

较低的累计布局偏移可能几乎没有直接抓取影响

累计布局偏移衡量可见内容意外移动的程度。它主要是一个用户体验指标。常见原因包括没有尺寸的图片、动态插入的广告、嵌入内容和网页字体。(web.dev)

抓取工具不会像人类访问者那样体验布局偏移。因此，较低的累计布局偏移与更多抓取之间不太可能存在直接关系。

当高布局偏移由以下原因引起时，可能存在间接关系：

• JavaScript 后期插入的内容。
• 在脚本运行前隐藏的重要文本。
• 延迟页面构建的图片或嵌入内容。
• 在不同抓取过程中生成不同内容的不稳定模板。

在这些情况下，真正的问题不是布局偏移分数。真正的问题是页面可能难以处理，或者过晚显示重要内容。

更快的页面不会自动获得更多引用

Google 表示，出现在人工智能功能中的页面必须首先被索引，并有资格在正常搜索结果中显示摘要。Google 还表示，其人工智能概览和人工智能模式没有额外的技术要求或特殊人工智能优化。(developers.google.com)

OpenAI 同样表示，ChatGPT 搜索排名取决于多个因素，并且允许其搜索抓取工具 OAI-SearchBot 对于收录至关重要。它没有说明较低的核心网页指标会直接增加引用概率。(help.openai.com)

这提出了一种四阶段模型：

1. 发现 — 系统是否知道 URL 存在？
2. 抓取和处理 — 系统能否检索并理解页面？
3. 索引和检索 — 页面是否被选中用于特定查询？
4. 引用选择 — 页面是否在答案中作为可见来源显示？

页面速度可能会影响前两个阶段。它尚未被确定为第四阶段的直接原因。

最近的研究还表明，人工智能系统可能会阅读许多相关页面，但只引用其中一部分。换句话说，检索和引用是独立的事件。(cambridge.org)

应该测试什么？

该研究应该测试两个不同的问题，而不是将“人工智能可见性”作为一个指标来对待。

问题 1：性能是否影响抓取？

主要结果：

• 从发布到首次抓取工具请求的时间。
• 每页每天的抓取工具请求数量。
• 成功重新抓取之间的时间。
• 每 1,000 个已发布页面中被抓取的页面数量。
• 成功抓取的百分比。
• 服务器错误和速率限制响应的发生率。
• 从发布到索引的时间。

问题 2：性能是否影响引用选择？

主要结果：

• 产生可见引用的测试查询百分比。
• 每合格页面的引用率。
• 查询中的引用份额。
• 成为可见引用的检索页面百分比。
• 引用的随时间持久性。
• 按人工智能系统划分的引用率。

这些结果必须按提供商分开。Google 人工智能概览、ChatGPT 搜索结果、Microsoft Copilot 答案、Perplexity 答案和 Claude 搜索响应可能使用不同的索引、抓取工具、排名系统和刷新计划。

实验设计

1. 构建受控页面集

使用足够大的页面集，以产生有意义的抓取工具和引用数据。

一个实用的初始设计将包括：

• 240 到 800 个页面。
• 每个页面模板至少20 个页面。
• 三到五个内容类别。
• 混合常青页面和定期更新的页面。
• 每个处理组中页面数量相等。

每个页面应具有：

• 相似的 HTML 结构。
• 相似的内容长度。
• 相同的发布系统。
• 相同的内部链接模式。
• 相同的规范规则。
• 相同的站点地图处理。
• 相同的 robots.txt 权限。
• 独特、有用的主题。

不要仅仅为了实验而创建数百个内容稀少或近似重复的页面。Google 的指南警告说，重复和低价值的 URL 会浪费抓取资源并降低网站效率。(developers.google.com)

匹配对设计很有用。例如，将具有相似以下特征的页面配对：

• 内容长度。
• 主题需求。
• 更新频率。
• 内部链接数量。
• 外部链接数量。
• 历史流量。
• 搜索排名位置。

然后将每对中的一个页面放入对照组，另一个放入处理组。

2. 使用因子处理设计

主要性能处理应独立和共同进行测试。

这为三个请求的优化创建了一个受控实验：

• HTTP/3。
• 内容分发网络边缘缓存。
• 图片压缩。

布局稳定性处理是必要的，因为前三个优化无法可靠地隔离累计布局偏移。图片压缩可能会降低最大内容绘制，而不会改变布局稳定性。

为什么 HTTP/3 需要单独测量

HTTP/3 使用 QUIC 传输协议并提供独立的流，可以避免 HTTP/2 over TCP 中发现的传输层队头阻塞。其优势取决于客户端或抓取工具是否实际协商使用 HTTP/3。(rfc-editor.org)

因此，记录每个请求协商的协议：

• HTTP/1.1。
• HTTP/2。
• HTTP/3。

不要假设启用 HTTP/3 意味着每个抓取工具都会使用它。如果 Googlebot、OAI-SearchBot 或其他抓取工具继续使用 HTTP/2，HTTP/3 将无法影响该抓取工具的请求。

为什么边缘缓存需要仔细测试

内容分发网络可以通过将内容更接近请求者来减少首字节时间。它还可以减少到达源服务器的请求数量。(web.dev)

测试至少三种缓存状态：

1. 冷缓存 — 边缘必须联系源站。
2. 热缓存 — 边缘在不联系源站的情况下提供页面。
3. 重新验证缓存 — 边缘或抓取工具使用 ETag 或 Last-Modified 值并收到 304 Not Modified 响应。

Google 特别推荐高效的 HTTP 缓存，并支持使用 304 Not Modified 响应来减少不必要的处理和带宽。(developers.google.com)

不要允许缓存向抓取工具提供过期或不正确的内容。记录：

• 缓存命中或未命中。
• 缓存时长。
• 边缘位置。
• 源站响应时间。
• 内容版本。
• 状态码。
• 验证头。

为什么图片压缩应与最大内容绘制相关联

WebP 和 AVIF 通常比旧图像格式提供更好的压缩。较小的图像可以减少传输时间，并且当图像是最大内容绘制元素时，可能会改善最大内容绘制。(web.dev)

测试应使用：

• 相同的图像尺寸。
• 相同的视觉质量目标。
• 响应式 srcset 图像。
• 具有合适回退的现代格式。
• 明确的 width 和 height 值。
• 最大内容绘制图像不进行延迟加载。
• 初始 HTML 中可见的图像 URL。

如果真正的延迟来自 JavaScript 或后期资源发现，单独的图像压缩可能无法改善最大内容绘制。Google 的性能指南指出，如果最大内容绘制元素显示较晚，减少图像下载时间可能只是将延迟转移到页面的另一部分。(web.dev)

3. 运行足够长的测试

短期测试可能会错过抓取调度和索引刷新的影响。

一个实用的设计是：

• 两周的基线测量。
• 六到十二周的处理测量。
• 如果可能，进行最终的逆转或交叉期。

对于交叉测试，在匹配的页面组之间切换处理。如果移除处理后性能影响消失，则结果比简单的前后比较更强。

核心网页指标的现场数据应在适当的时间段内进行评估。Chrome 用户体验报告采用滚动 28 天聚合，因此它并非旨在显示部署后的即时变化。(developer.chrome.com)

4. 测量完整的抓取工具群体

不要将所有自动化流量视为一个群体。

至少，区分：

搜索抓取工具

• Googlebot。
• Bingbot。

人工智能搜索抓取工具

• OAI-SearchBot。
• PerplexityBot。
• Claude-SearchBot。

用户请求抓取器

• Perplexity-User。
• Claude-User。
• 可识别的 ChatGPT 用户抓取器。

训练抓取工具

• GPTBot。
• ClaudeBot。
• Google-Extended 控制。

训练抓取工具不应被用作人工智能搜索引用的代理。Anthropic、OpenAI 和 Google 区分用于训练、搜索或用户请求检索的抓取工具。Google 还声明 Google-Extended 不影响 Google 搜索的收录或排名。(help.openai.com)

Perplexity 同样区分支持搜索索引的 PerplexityBot 和可能响应用户请求检索页面的 Perplexity-User。(docs.perplexity.ai)

在提供商支持的情况下，使用已发布的 IP 范围或反向 DNS 验证抓取工具身份。用户代理字符串可能被不相关的抓取工具复制。Google 明确警告 Googlebot 用户代理字符串可能被伪造。(developers.google.com)

收集的指标

性能指标

收集实验室和真实用户数据：

• 首字节时间。
• 首次内容绘制。
• 最大内容绘制。
• 累计布局偏移。
• 下一次绘制交互。
• 页面总重量。
• 初始 HTML 大小。
• 图片传输大小。
• 请求数量。
• 服务器处理时间。
• 等待最大内容绘制资源的时间。
• HTTP 协议。
• 缓存状态。

Google 建议的首字节时间大致目标是800 毫秒或更短，但首字节时间本身并非核心网页指标。(web.dev)

当前核心网页指标在第 75 百分位处的“良好”阈值是：

• 最大内容绘制：2.5 秒或更短。
• 累计布局偏移：0.1 或更低。
• 下一次绘制交互：200 毫秒或更短。(web.dev)

抓取指标

对于每个经过验证的抓取工具请求，记录：

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

计算：

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

人工智能引用指标

在每个平台使用一组固定的查询。查询集应包括：

• 直接的事实性问题。
• 比较问题。
• “最佳”或推荐问题。
• 对时效性敏感的问题。
• 被测页面是最佳答案的问题。
• 被测页面相关但不占主导地位的问题。

对于每个查询，记录：

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

重复查询，因为人工智能答案可能有所不同。使用固定时间表，例如每周三次，并记录引擎或模型的变化。

Microsoft Bing 网站管理员工具现在提供人工智能性能报告，显示所引用的页面、基础查询以及支持的 Microsoft 人工智能体验中的引用趋势。Microsoft 警告称，这些数据是聚合、抽样和观察性的；它无法证明特定的页面更改导致了引用更改。(bing.com)

Google 还在 2026 年 6 月开始在 Search Console 中推出专门的生成式人工智能性能报告。这些报告最初仅对一部分网站可用，因此访问权限可能会有所不同。(developers.google.com)

统计分析

抓取频率

使用混合效应计数模型，例如负二项式模型：

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

页面和抓取工具效应很重要，因为某些页面自然会比其他页面获得更多关注，并且不同的抓取工具具有不同的调度。

发现和索引

对以下内容使用生存分析：

• 从发布到首次抓取的时间。
• 从发布到首次索引的时间。
• 从更新到重新抓取的时间。

关键结果不仅仅是页面是否最终被抓取。它是指处理是否缩短了页面被发现和处理所需的时间。

人工智能引用选择

使用分层逻辑模型：

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

运行两个独立的模型：

1. 检索模型 — 页面是被检索还是显示为候选？
2. 引用模型 — 如果被检索，页面是否被明显引用？

这种区别至关重要。一个增加抓取但不增加检索的性能改进不是人工智能引用效应。一个增加检索但不增加引用的性能改进表明页面正在被考虑，但在源选择过程中落选。

预期发现

这些是工作假设，并非声称的实验结果。

假设 1：首字节时间将具有最清晰的抓取效果

在以下情况下，预计较短的首字节时间与抓取容量之间存在正向关系：

• 网站页面很多。
• 页面经常更改。
• 源服务器速度缓慢或过载。
• 网站返回 5xx 或 429 响应。
• 抓取工具花费大量时间等待响应。

预计对抓取需求低的小型网站几乎没有可衡量的影响。

假设 2：最大内容绘制将通过渲染和资源交付发挥作用

在以下情况下，预计较低的最大内容绘制会有所帮助：

• 页面依赖于浏览器渲染。
• 重要内容在 JavaScript 之后加载。
• 索引需要大型图像或样式表。
• 抓取工具抓取许多页面资源。
• 较慢的处理导致超时或不完整渲染。

当页面的重要文本已存在于初始 HTML 中时，预计关系较弱。

假设 3：累计布局偏移的直接影响很小

在控制页面结构和 JavaScript 行为后，预计累计布局偏移与抓取频率或引用率之间没有有意义的直接关系。

如果累计布局偏移似乎能预测引用，则调查它是否充当以下方面的代理：

• 客户端渲染。
• 后期内容插入。
• 不稳定的广告。
• 隐藏或延迟的文本。
• 结构不良的 HTML。

假设 4：仅靠速度不会产生更多人工智能引用

引用选择最强的预测因素可能仍然是：

• 与查询的相关性。
• 内容质量。
• 清晰的答案。
• 新鲜度。
• 权威和信任。
• 搜索索引资格。
• 检索排名。
• 页面是否直接支持所提出的主张。

Google 的指南强调有用、可靠、以人为本的内容，并表示人工智能搜索功能以现有的搜索和索引系统为基础。(developers.google.com)

为人工智能检索调整的性能预算

以下是建议的运营预算。它不是已发布的人工智能排名公式。

Google 当前的文档指出，Googlebot 抓取支持文件的前 2 兆字节，并单独抓取外部脚本和样式表。它还建议将重要的元数据和结构化数据放置在 HTML 的早期。(developers.google.com)

实施建议

HTTP/3

当托管提供商和内容分发网络支持时，使用 HTTP/3。

测量：

• HTTP/3 协商率。
• HTTP/2 回退率。
• 连接建立时间。
• 首字节时间。
• 按地理区域划分的性能。
• 按抓取工具划分的性能。

不要将 HTTP/3 视为有保证的搜索或人工智能优化。它是一种传输改进，可能只对使用它的客户端有所帮助。

内容分发网络边缘缓存

对于公共、非个性化页面：

• 设置明确的 Cache-Control 规则。
• 对带版本号的静态资产使用长期缓存。
• 对频繁更新的 HTML 使用短期但有用的缓存。
• 避免因不必要的查询参数造成的缓存碎片。
• 保留规范 URL。
• 支持 ETag 和 Last-Modified。
• 测试冷、热和重新验证的缓存状态。
• 确认抓取工具请求与人类请求接收到相同的重要内容。

内容分发网络应在不创建过期、不一致或特定于机器人的页面版本的情况下减少延迟。

图片压缩

对于图片：

• 在视觉质量可接受时使用 AVIF 或 WebP。
• 提供响应式图片尺寸。
• 不要向小型移动屏幕提供桌面尺寸的图片。
• 不要延迟加载最大内容绘制图片。
• 包含图片尺寸。
• 将最大内容绘制图片放置在初始 HTML 中。
• 仅在适当时使用 fetchpriority="high"。
• 将重要解释保留在文本中，而不是仅将其嵌入图片内。

当图片是最大内容绘制元素时，图片压缩最有价值。它无法解决主要延迟来自服务器渲染或 JavaScript 执行的页面问题。(web.dev)

布局稳定性

为了降低累计布局偏移：

• 在图片上设置宽度和高度属性。
• 为广告保留空间。
• 为嵌入式视频和社交内容保留空间。
• 避免在现有文本上方插入横幅。
• 使用稳定的字体加载策略。
• 避免在页面加载后替换大块服务器渲染的内容。

这些更改可以改善用户体验，即使它们对抓取或引用没有可衡量的影响。(web.dev)

工具和监控

性能工具

使用：

• Chrome 用户体验报告 用于真实用户核心网页指标。
• Chrome 用户体验报告 API 用于自动化现场数据收集。
• PageSpeed Insights 用于实验室审计和现场数据。
• Lighthouse 用于可重复的实验室测试。
• Lighthouse 持续集成 用于拉取请求性能预算。
• WebPageTest 用于多地点测试、缓存状态和协议比较。
• Chrome 开发者工具 用于最大内容绘制和布局偏移调试。
• web-vitals JavaScript 库 用于真实用户监控。

Chrome 用户体验报告 API 提供页面级和源站级聚合现场数据，包括最大内容绘制、累计布局偏移、下一次绘制交互和实验性首字节时间。(developer.chrome.com)

Lighthouse 持续集成可以在每次代码更改时运行性能检查，并在超出预算时使构建失败。(github.com)

抓取工具监控

使用服务器日志、边缘日志和一小组合成探测。

探测示例：

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

使用以下工具运行相同的测试：

• Googlebot。
• Bingbot。
• OAI-SearchBot。
• PerplexityBot。
• Claude-SearchBot。
• 普通浏览器用户代理。

测试应验证：

• 状态码。
• Robots 权限。
• 响应头。
• HTML 内容。
• HTTP 版本。
• 缓存状态。
• 响应时间。
• 是否存在无 JavaScript 的重要文本。

搜索和索引监控

使用：

• Google Search Console 抓取统计信息。
• Google Search Console 页面索引报告。
• Google Search Console URL 检查。
• Google Search Console 站点地图数据。
• 可用时使用 Google Search Console 生成式人工智能报告。
• Bing 网站管理员工具抓取请求和索引页面。
• Bing 网站管理员工具人工智能性能。
• 每日站点地图和 lastmod 检查。

Search Console API 可以按页面、查询、日期、设备和搜索展示次数检索性能数据，但受其数据限制。(developers.google.com)

引用监控

为每个主题创建包含 50 到 200 个稳定查询的引用面板。按固定时间表运行面板并记录：

• 平台是否搜索。
• 出现了哪些来源。
• 被测 URL 是否被引用。
• 引用顺序。
• 答案日期和时间。
• 页面是否更改。
• 模型或搜索体验是否更改。

不要将来自不同系统的引用计数进行比较，就好像它们是等效的一样。Microsoft 表示，引用活动不是排名分数、权威分数、流量衡量或质量分数。(bing.com)

警报规则

创建以下警报：

• 首字节时间增加超过 25%。
• 第 75 百分位的最大内容绘制超过 2.5 秒。
• 累计布局偏移超过 0.1。
• 5xx 或 429 响应持续增加。
• 抓取工具成功率下降。
• robots.txt 更改。
• 站点地图错误。
• 索引页面突然下降。
• 多个平台上人工智能引用突然下降。
• 仅影响一个平台的引用量变化。

影响单个平台的引用下降可能由模型、索引、查询或产品更改引起，而非页面性能问题。Microsoft 明确警告，引用趋势是观察性的，可能因内容更新、用户需求以及系统或模型更改而变化。(bing.com)

最终结论

最有力的结论是：

更快的页面可以提高抓取效率，尤其是在服务器延迟、资源大小、错误或渲染延迟是限制因素的情况下。但目前没有强有力的证据表明较低的核心网页指标直接导致人工智能系统选择页面作为引用。

预期的因果链是：

text 较低的延迟 → 更好的服务器容量 → 更少失败或延迟的抓取 → 更快的发现和处理 → 提高被索引和检索的机会 → 可能增加引用

最后一步仍不确定，因为引用选择取决于相关性、质量、时效性、权威性、查询意图、检索排名以及每个人工智能系统的行为。

因此，对于大多数网站而言，正确的性能策略并非孤立地“优化人工智能引用”。它应该包括：

1. 将重要内容保留在初始 HTML 中。
2. 保持首字节时间稳定。
3. 对公共内容使用边缘缓存。
4. 压缩并优先加载重要图片。
5. 防止布局偏移。
6. 返回可靠的状态码。
7. 保持站点地图和内部链接最新。
8. 允许正确的搜索抓取工具。
9. 将抓取、索引、检索和引用作为单独的阶段进行衡量。

这种方法为用户提供了更快的网站，为搜索抓取工具提供了更健康的网站，并为理解人工智能可见性奠定了可测试的基础。