你的网站有第二类用户：Cloudflare 扫了 20 万个域名，Agent 可读性平均只有 48 分

过去三十年，Web 开发的核心假设几乎没变过：人类用浏览器打开页面，用眼睛读内容，用手点按钮。SEO 解决的是"让搜索引擎找到你"，但抓回去本质上还是"给人类看"。 2026 年，这个假设裂开了一道口子。Chrome 149 把 Gemini 直接集成进浏览器：用户可以对浏览器说"帮我找一家附近的意大利餐厅，看看今晚 7 点有没有空位，有的话帮我订了"，浏览器里的 AI Agent 就开始滚动、点击、填写、提交。 关键区别在于：这个 Agent 不是爬虫。它不满足于抓取 HTML 文本，它要理解页面结构、识别可交互元素、执行多步操作、处理错误状态。Google 在 I/O 2026 上的表述是"智能体正在改变各行各业的开发方式，Web 必须能够引导它们"，同期发布了 WebMCP 和 Modern Web Guidance，目标是让网站主动告诉 Agent 该怎么做。 48 分：一份不太好看的体检报告 Cloudflare 走了另一条路：发布 Agent Readability Score，扫描互联网上访问量最高的 20 万个域名，剔除掉重定向、广告服务器和隧道服务之后，聚焦于企业、出版商和平台——也就是 AI Agent 真正需要交互的那批网站。 结果是：平均得分 48 分，中位数 52 分（满分 100）。 拆开看更尴尬。78% 的网站有 robots.txt，但绝大多数是写给传统搜索引擎爬虫的；只有 4% 的网站在 robots.txt 里明确表达了关于 AI 使用的偏好（Content Signals 标准）；只有 3.9% 支持 Markdown Content Negotiation，也就是当 Agent 请求 text/markdown 时返回 Markdown 格式；而 MCP Server Cards 和 API Catalogs（RFC 9727）的采用率几乎为零。 换句话说，超过一半的网站，Agent 根本读不懂。 原因往往朴素得可笑。一个典型企业官网的导航，代码长这样：外层 `<div class="header">` 里塞 logo，导航项写成 `<span class="nav-item" onclick="navigate('/pricing')">Pricing</span>`。对人类来说毫无问题——鼠标悬停变手型，你知道它能点。但对 Agent 来说这是一片混沌：onclick 不是可交互元素的语义信号，Agent 不知道 `<span>` 是可以点击的；没有 role 属性，没有 aria-label，没有 `<a>` 标签，没有 `<button>` 标签；就算它找到了那个 span，onclick 里的 navigate('/pricing') 也不是 href，它无法预知点击之后会去哪。 Lighthouse 把"能不能被 Agent 用"做成了审计项 2026 年 6 月，Chrome 开发者博客发布了一篇重磅文章：Lighthouse 新增 Agentic Browsing 审计分类，从 Chrome M150 开始可用。它不检查你的网站"看起来好不好"，而是检查 AI Agent 能不能可靠地完成一个流程——比如预订会议室、提交订单、填写联系表单。 审计聚焦三个关键领域。 可访问性。 这是最反直觉的一条。a11y 首先是给人用的，但 Agent 理解页面的主要数据模型，恰恰是从 DOM 衍生出的可访问性树。所以审计验证的是 Accessibility 里"对机器交互至关重要"的子集，其中最核心的一条是：每个可交互元素都必须有程序化名称。一个 `<div onclick="submit()">Submit</div>`，对人类来说悬停会变手型；但对 Agent 来说，这个 div 在可访问性树里就是一个没有角色、没有名称的普通容器，它不知道这是按钮，也不知道它叫什么。 稳定性。 用 CLS（Cumulative Layout Shift）衡量。为什么 Agent 在意 CLS？因为它的点击方式和人类不一样：人类看到按钮就在那儿，把鼠标移过去点；Agent 是先读可访问性树、定位到某个元素、计算屏幕坐标，再模拟点击。如果在这两步之间页面发生了布局偏移——比如一张图片加载完，把按钮往下推了 200px——Agent 的点击就会落在错误的位置。它可能点到广告，可能触发不该触发的导航，也可能什么都没点中。一个 CLS 高的页面，对人类来说是"加载时抖了一下"，对 Agent 来说是"操作不可靠"。 WebMCP 集成。 这是最前瞻的检查项。WebMCP 是一个拟议的开放 Web 标准，目标是让网站主动向 AI Agent 暴露结构化的工具和表单。传统模式下 Agent 只能猜：看到页面上有搜索框，猜它可能是搜索；看到 Book Now 按钮，猜它触发预订。WebMCP 模式下，网站直接告诉它："我有一个工具叫 search_rooms，接收 check_in、check_out、guests 三个参数，返回可用房间列表。"审计会检查你的网站有没有注册 WebMCP 工具、表单有没有声明式标记、Schema 是否有效。 想自查，现在就有三个工具：打开 isitagentready.com 输入网址，会返回 0-100 分并逐项列出问题；在 DevTools 的 Lighthouse 面板里勾上 Agentic Browsing 跑一次审计，结果以 pass/fail 和 warning 呈现而不是一个总分；Google 在 I/O 2026 还发布了面向 Agent 的 Chrome DevTools，允许 Agent 直接访问控制台日志、网络流量和可访问性树，无需人类监督即可验证和自动修复代码。 六条已经在落地的工程实践 第一，把可访问性当"Agent 可读性"来做。可交互元素必须有程序化名称和正确角色，表单元素必须有关联的 label，模态框必须有 aria-modal 和焦点管理，导航结构用 `<nav>` 和 `<a>` 而不是 `<div onclick>`。 第二，支持 Markdown Content Negotiation。当 Agent 的请求头包含 Accept: text/markdown 时，返回页面的 Markdown 版本而不是 HTML。HTML 是给浏览器渲染的，Markdown 是给 Agent 阅读的，一份内容两种格式。 第三，在 robots.txt 里声明 Agent 偏好，例如写一行 Content-Signal: ai-train=no, search=yes, ai-input=yes，明确告诉对方内容可以用于搜索、不允许用于 AI 训练。 第四，注册 WebMCP 工具。核心思想是不要让 Agent 猜你的页面怎么用，直接告诉它。在 Chrome 149 的实验里，WebMCP 工具可以让 Agent 在几秒内完成复杂的多步任务，因为 Agent 不再需要"发现"操作，而是直接调用工具。 第五，降低 CLS。图片必须设置 width 和 height，字体使用 font-display: optional 或 swap 配合 size-adjust，动态插入的内容用 content-visibility 或骨架屏占位，避免在首屏内容之上插入广告或通知栏。 第六，提供 llms.txt。它放在网站根目录，告诉 AI 模型你的网站有哪些内容、以什么格式提供、哪些允许被读取。它正在成为 Agent 时代的 robots.txt。 这件事对工程的实际含义 第一，"用户画像"需要更新了。你的网站现在有两类用户：人类用眼睛和手，Agent 用可访问性树和 API。代码要同时服务这两类用户。 第二，可访问性从"合规要求"变成了"Agent 可用性的前提"。过去做 a11y 往往因为法规要求或者道德上应该做；2026 年多了一条更直接的理由：Agent 依赖可访问性树，你的 a11y 做得越差，Agent 在你的网站上就越不可靠。 第三，语义化 HTML 的价值正在被重新定义。`<button>` 不只是"一个可以点击的元素"，它是"这是一个可交互操作"的信号；`<nav>` 是"这里有页面间跳转"的信号；`<form>` 是"这里有结构化数据输入"的信号。 第四，一个新的工程维度正在形成。SEO 优化的是"搜索引擎能不能找到你"，Agent-Ready 优化的是"Agent 能不能可靠地使用你"。当 Agent 开始代表用户执行操作，"可操作性"正在成为和"可发现性"同等重要的工程指标。 参考原文：https://juejin.cn/post/7688192884433682486