PageSpeed Insights 多年来一直在为性能、无障碍、最佳实践和 SEO 四个项目打分。2026 年，这一行悄悄加入了第五个项目：Agentic Browsing（智能体浏览）。它回答了其他四个类别一直忽略的一个问题——AI 智能体真的能操作这个页面吗？
本文要讲的是如何把这项检查真正用在自己的网站上：跑一次、读懂每一项审计到底在说什么，最后带着一份修复清单离开。
读完之后你会得到什么
适合谁读： 想知道网站在 AI 智能体而非人类浏览时表现如何的 SEO、开发者和网站负责人。
读完之后你手上会有： 自己网站真实的 Agentic Browsing 结果、逐项判读通过／失败／不适用的记录，以及一份排好优先级的修复清单。
前置条件： 一个可公开访问的网址、第一次执行大约十分钟，以及当天就要动手修复所需的代码权限。
完成标准： 你能逐项解释分数是怎么来的，并能判断哪些失败会真正阻碍智能体在你的页面上完成任务。
这项检查从哪来，为什么是现在
Agentic Browsing 类别在一年前并不存在。上线分为三个阶段，全部都有 Google 的官方记录：
- 2026 年 5 月 7 日： Lighthouse 13.3 将这个类别加入默认配置，成为标准执行的一部分。
- 2026 年 6 月 22 日： Chrome for Developers 博客在〈A developer toolkit to make your website agent-ready〉一文中发布了这个类别，同时介绍了面向智能体的 DevTools 和 WebMCP 指南。
- 2026 年 7 月 20 日： Lighthouse 13.4.1 让这个类别在 PageSpeed Insights API 路径上启用，版本说明中写道，该版本预计「两周内」进入 PageSpeed Insights。也就是说，正式上线时间落在 2026 年 8 月初。
我在 2026 年 9 月 11 日执行这项检查时，报告页脚显示的是 Lighthouse 13.4.1 的模拟执行，而 Agentic Browsing 就紧挨着 SEO。换句话说，这个功能已经正式上线，不是 Canary 专属。但它同时也明确尚未完成。报告中的类别说明写得很直白：这个类别仍在开发中，随时可能变化。
开始之前有一个实务提醒：PSI 是在 Google 端为你执行这个类别。页面级检查不需要 Chrome 150，也不需要 origin trial。有版本要求的是在 Chrome DevTools 本地执行的情况。
在自己的网站上执行这项检查
- 打开 pagespeed.web.dev，粘贴你的网址。先跑移动端，再跑一次桌面端，因为两次实验室运行的评分是分开的。
- 等待实验室数据完成。 页面顶部的实测数据来自 Chrome UX Report，加载很快；下方的 Lighthouse 执行耗时更久，类别就在那里。
- 找到分数那一行。 依次是性能、无障碍、最佳实践、SEO，然后是以分数而非 0–100 呈现的 Agentic Browsing。
- 展开类别。 审计列表会分成 Agent Accessibility、WebMCP，以及常见的通过与不适用两组。
- 逐一点开失败的审计。 每一行展开后都会显示造成失败的具体规则、元素或文件，这正是开修复工单需要的信息。
第五个类别就坐在 SEO 团队每天查看的分数旁边。2026 年 9 月 11 日于 PageSpeed Insights 截取。
质量检查： 和同事对比结果之前，先确认执行详情里的 Lighthouse 版本。PSI 按自己的节奏更新 Lighthouse，而这个类别在不同版本之间仍在变化。
如果失败： PSI 偶尔会在沉重页面上返回 RPC 超时。我在调研期间就在一个大型网站上遇到过。请重试，或改用本地 Lighthouse 测试。
正确解读分数
Agentic Browsing 没有加权的 0–100 分数，这是刻意设计。Lighthouse 的文档指出，智能体网络的标准仍在形成中，因此重点放在可行动的信号上，而不是排名。
真正重要的算术是这样的：
显示 | 含义 |
|---|---|
3/3 | 所有计分审计都通过。不适用审计不参与计算。 |
1/3 | 一项通过、两项失败。分母只包含通过与失败的审计。 |
0/3 | 计分项目前还没有通过的。在广告密集的沉重页面上首次运行时很常见。 |
没有分数 | 所有审计都不适用，或这个类别没有执行。请检查执行详情。 |
陷阱在于把 1/3 读成「智能体就绪度 33%」。它不是任何东西的百分比，而是一个计数：该页面可计分的三项检查中有一项通过，不适用的审计完全没有进入计算。在我截取的报告里，共执行六项审计，三项不适用，剩下三项产生了 1/3。
同一页面的分数也会在多次执行之间变化。Lighthouse 点名的三个原因是：动态工具注册（用 JavaScript 注册的 WebMCP 工具会因时序被捕获或错过）、改变无障碍树的 DOM 变更，以及广告、未指定尺寸的图片或注入内容造成的布局偏移。数字如果在晃动，通常就是这些原因。
逐项查看六项审计
当前的 PSI 版本会执行六项审计，还有一项即将加入：Lighthouse 的开发分支已经在新的 Agent Discoverability 分组下加入 ai-catalog.json（Agent Resource Discovery）检查，所以请把这份清单视为版本相关。
审计 | 检查内容 | 「不适用」意味着什么 |
|---|---|---|
无障碍树格式不正确 | 面向智能体的无障碍规则子集：程序可读的名称与标签、有效的 ARIA 结构，以及即使被隐藏仍可交互的元素 | 不会出现；始终计分 |
llms.txt 不符合建议 |
| 文件返回 404。缺少 llms.txt 被视为可选，而不是失败 |
累积布局偏移 | 视觉稳定性，让依据元素位置行动的智能体不会在偏移过程中点错东西 | 不会出现；始终计分 |
WebMCP 工具注册 | 页面是否通过声明式或命令式 API 注册任何 WebMCP 工具 | 未检测到任何 WebMCP 工具 |
WebMCP 表单覆盖 | 缺少工具注释的声明式表单 | 同上 |
WebMCP 架构有效性 | 已注册工具是否发布有效的输入与输出架构 | 同上 |
展开后的类别视图：两项失败、一项通过、三项不适用。失败清单就是最短的工作清单。
三项 WebMCP 审计显示「不适用」在 2026 年是正常的。WebMCP 是提案中的标准，处于 origin trial 和早期预览阶段，包含两套 API：一套是为标准 HTML 表单添加注释的声明式 API，另一套是从 JavaScript 注册工具的命令式 API。大多数网站两者都还没实现，所以大多数报告在那里会显示三个灰圆。灰色不是红色，不要把它当成失败。
修复检查标记的问题
四大修复主题覆盖六项审计。三行 WebMCP 只有在你真的提供智能体工具时才需要处理。
让无障碍树可被智能体读取
智能体把无障碍树当作页面的主要地图，其中列出角色、名称和状态。一个没有可访问名称的按钮，对它们是死路，对屏幕阅读器用户也一样。
做法： 逐一处理展开审计中的失败规则。常见的嫌疑对象包括只有图标的按钮、没有标签的表单字段、文字只有「点这里」的链接、无效的 ARIA 角色组合，以及被 ARIA 引用的重复 ID。优先使用语义化 HTML，为标签加上 for 属性，在无法使用原生元素时，为自定义组件指定明确的 role 和 tabindex。
预期结果： 审计转为通过，而且无障碍分数通常同时提升，因为 Agentic Browsing 版本是同一套检查的精简子集。
卡住时的补救： 如果修复清单累积到数百个元素，不要逐个追。先修公共组件，例如页首那个只有图标的按钮，然后重新执行。一个组件往往能清掉几十行。
发布能通过格式检查的 llms.txt
这里有个会绊倒细心人的陷阱。这项审计不只看 /llms.txt 是否存在，它还会检查文件内容，而只列裸网址的文件会失败，因为检查要找的是 Markdown 形式的链接。
做法： 在根域名创建 /llms.txt，包含 H1 标题和真正的 Markdown 链接：
# 公司名称
简短说明网站涵盖的内容，以及希望它被如何使用。
## 主要页面
- [产品概览](https://example.com/product)
- [价格](https://example.com/pricing)
- [文档](https://example.com/docs)预期结果： 审计变绿。相对地，404 会显示为不适用，目前是可以接受的。500 系列响应或抓取错误则是真正的失败，需要从服务器端修复。
质量检查： 在终端抓取自己的 /llms.txt，数一数链接。如果它们长得像 https://example.com/pricing、没有方括号，那么即使文件已上线、人看得懂，审计仍会失败。
一个诚实的提醒：Google 搜索并不使用 llms.txt。Google 自家的 AI 优化指南写得很清楚，这个文件「对网站在 Google 搜索中的可见度或排名既无帮助也无害，因为 Google 搜索会忽略它们」。请为会读这个惯例的智能体工具而写，而不是为了排名。
稳定布局，让智能体能瞄准
布局偏移比以前更重要了。智能体先找到按钮，再点击它的坐标；如果广告、横幅或延迟加载的图片在这两个瞬间之间把按钮往下推了 200 像素，点击就会落空。
做法： 为图片和嵌入内容设置明确的 width 和 height（或 aspect-ratio）、为广告位和同意声明横幅保留固定空间、避免在加载后向既有内容上方插入新内容，并用 transform 而不是触发布局的属性做动画。
预期结果： 实验室运行中的累积布局偏移低于 0.1，也就是 Core Web Vitals 采用的同一阈值。
质量检查： 报告中性能部分的「布局偏移主因」洞察会指出确切的元素。从那里开始，不要靠猜。
WebMCP 可以之后再决定
三项 WebMCP 审计只有在网站注册工具时才会计分。如果你有预约流程、结账、支持表单，或任何智能体能完成的结构化任务，WebMCP 值得做个原型：它直接告诉智能体该调用哪个工具，而不是让智能体从 DOM 里猜。Chrome 把这项功能放在 origin trial 和本地测试标志之后，所以它是真实选项，不是空想。
如果没有值得自动化的任务，就不要碰 WebMCP。三个灰圆没有任何问题。唯一不该做的，是为了让分数好看而注册装饰性工具。这个类别是就绪度信号，取巧只会让它失去意义。
验证修复结果
在 PSI 重新执行同一个网址，并比较三件事而不是一件：分数、各项审计状态，以及设备类型。修复可能只推动了分数、却没解决你在意的问题；而移动端和桌面端会产生各自的实验室结果。
想加快迭代，就别等 PSI，直接在本地运行 Lighthouse。这个类别自 Lighthouse 13.3 起纳入，安装本地版即可使用。如果你想用 DevTools 面板版本，Google 的文档指出测试这个类别需要 Chrome 150 以上，而 WebMCP 审计还需要注册 origin trial。
留一份简短的修复前后记录。像「2026-09-11：移动端 1/3，无障碍树和 llms.txt 失败」这样一行带日期的笔记就够了。它能让你知道后来的退步是真的，还是只是单次执行的波动。
这项检查不是什么
有三件事它不做，因为误解相当普遍：
- 它不是排名因素。 Chrome 的公告称这个类别为信息性质、未纳入基准评分。Google 搜索排名不受你的 Agentic Browsing 分数影响。
- 它不是 AI 可见度分数。 它衡量智能体能否操作你的页面，完全不说明 ChatGPT 或 Perplexity 是否会在回答中引用你。
- 它不是网站的及格／不及格判定。 简单的营销页面分数偏低，通常只是没什么可评，而不是智能体被挡在门外。
有帮助的视角是这样：这个类别检查的是当访客不是人类时，你的网站站不站得住。它奖励的每一件事本来就值得做：语义化 HTML、稳定的布局、带标签的控件。Google 自家的智能体友好指南也用同一个结论收尾——让网站对智能体就绪的事，同时也让人用得更好。
纳入例行检查
智能体就绪度这类领域，平台的移动速度比检查清单快。两个习惯就能让你保持现状，而不必把它变成一个项目：
- 任何模板、导航、表单或结账流程变更之后，就重跑这项检查。这些正是会移动无障碍树和布局稳定性的修改。
- 跟踪分数时以模板为单位，而不是以网址为单位。十个产品页分数都一样，那就是模板问题，修一次就能全部解决。
PSI 的检查刻意做得很窄：六项审计，一次一页。如果你想要更完整的图景，包括 robots 规则、MCP 服务器卡片、OAuth 发现和智能体商务信号是否到位，Auspia 提供免费的 Agent Readiness 检查，会按这些协议层标准扫描网址，并提供排行榜用于对比。
常见问题
Agentic Browsing 分数会影响 Google 排名吗？不会。Google 将这个类别描述为信息性质，不属于搜索排名系统。请把它当作面向智能体的就绪度检查，而不是 SEO 分数。
为什么同一页面两次执行的分数不同？动态工具注册、改变无障碍树的 DOM 变更，以及延迟发生的布局偏移，都会造成执行间的差异。请重新测试，并比较审计清单，而不只是看分数。
为什么三项 WebMCP 审计全都显示不适用？因为你的页面没有注册 WebMCP 工具。这是 2026 年大多数网站的预期状态，并不是失败。
缺少 llms.txt 是问题吗？就这项审计而言不是。404 会被视为不适用。但存在的文件如果格式错误就会失败，所以要发布就正确地发布。
可以在 CI 里运行吗？可以，只要你的 Lighthouse 版本已包含这个类别。这些审计在设计上是确定性的，因此适合放进流水线检查。请注意 WebMCP 部分取决于浏览器支持和 origin trial 注册，在大多数 CI 环境中预期会显示为不适用。
我需要 Chrome 150 才能用吗？不需要。PageSpeed Insights 在服务器端执行。Chrome 150 的要求适用于在 DevTools 本地执行这个类别。
作者：Alice Monroe，Auspia 的 AI SEO 工具分析师，研究超过 150 款工具。她撰写 SEO 与 AI 搜索工具、哪些检查值得投入时间，以及如何把它们纳入日常工作。
