去年十月，一个客户给我打电话，很着急。他的电子商务网站从分析显示为"直接"访问的流量中获得了大量流量，但转化率下降了。我花了大约一小时挖掘服务器日志后，意识到其中很大一部分流量根本不是人类。是AI代理，具体是购物助手和由大语言模型驱动的比较工具，在爬取他的产品页面，但因为无法正确解析内容而反弹。结构化数据一团糟。价格埋在JavaScript中。产品名称放在样式看起来像<h2>的<h3>标签中。代理到达了，发现噪音，然后离开了。
我们现在就处于这个阶段。AI代理不是即将到来。它们已经在这里了，已经在读取你的网站，已经根据能否提取的内容做出决策。在过去的几年里，我在Seahawk为之建立或接触的12,000多个网站大多都没有考虑到这一点。你的网站也可能没有。
"代理可读"究竟意味着什么
让我坦白说一件事。代理可读并不是指那种模糊市场营销意义上的"AI友好"。它意味着一台机器可以到达一个URL，在不执行三层JavaScript的情况下解析内容，提取它寻找的东西，并对其采取行动。就是这样。
人类是宽容的。我们扫一眼。我们进行推断。我们在定价页面上看到一个大数字，即使它被包装在<div class="fancy-number">中，我们也知道它是价格。但一个遵循结构化工作流程的AI代理？不那么宽容。它需要信号、层级和可预测性。
目前从事这项工作的代理包括OpenAI的浏览工具、Perplexity的在线模式，以及使用LangChain和AutoGen等框架构建的数十个自定义代理。它们都有一个共同的需求：干净的、可解析的、语义有意义的HTML以及支持性的结构化数据。
真正的问题：JavaScript优先架构
这是我最常看到的情况。代理商和自由职业者用React或Next.js（或Vue、Svelte，随你）建设网站，他们进行客户端渲染，然后认为工作完成了。网站看起来很漂亮。Google可以爬取它，多多少少，因为Googlebot现在内置了无头Chrome渲染器。
但大多数AI代理都没有运行无头Chrome。他们通过HTTP获取原始HTML。如果你的内容只在JavaScript执行后才存在，那些代理得到的就是空白页面或被序列化为文本的加载旋转器。
早在2022年，Seahawk有一个金融科技客户，他们的整个汇率和产品对比部分都是用React SPA构建的。没有SSR，没有静态回退。我们对他们的URL运行了一个简单的curl命令，得到的就是字面意思上14行HTML：一个<div id="root">和一些脚本标签。这就是代理看到的。十四行。
解决办法不一定是放弃你的JS框架。而是服务端渲染（SSR）或静态网站生成（SSG）。使用getServerSideProps或getStaticProps的Next.js。Vue的Nuxt。SvelteKit。甚至如果你卡在旧系统上，只需用Prerender.io之类的工具预渲染关键页面。内容需要在初始HTML负载中。
语义HTML已不再是可选项
我知道。你从2009年就听说过"使用语义HTML"。但我现在说这话不是出于SEO的原因。我说这话是因为代理用语义标签来理解他们看到的是什么类型的东西。
<article>、<nav>、<main>、<aside>、<header>、<footer>，这些不是装饰性的。它们是信号。试图提取页面主要内容的代理会首先查看<main>。如果你用嵌套的<div>s构建了你的布局，什么都没有，代理就得猜测。猜测不好的代理会给用户返回错误的答案。
现在我审核每个网站时都会查看的内容：
- 每个页面是否恰好有一个 <main> 元素？
- 标题是否遵循逻辑层级（<h1> 到 <h2> 到 <h3>）且没有跳过级别？
- 导航菜单是否在 <nav> 元素中？
- 补充内容（边栏、相关文章）是否在 <aside> 中？
- 项目列表是否实际使用 <ul> 或 <ol>，而不是一串 <div class="item"> ？
这些看起来都是基础的东西。但我要说，我审查的 60% 的 WordPress 网站至少有三项不符合。标题层级那一项几乎是普遍的，设计师把 <h3> 设计得很大，把 <h2> 设计得很小，但没有人修复下面的标记。
Schema Markup：在这里做实际工作
大多数指南都太泛泛而谈。我会尽量避免这样。
Schema.org 结构化数据告诉代理的不仅是页面上是什么，还有它是什么类型的东西。一个产品。一个食谱。一个本地企业。一个常见问题。一个事件。它以代理可以使用的格式提供这些数据，而无需解析文本。
根据我的经验，现在最重要的类型包括：
- 产品（包含优惠、价格、可用性，全部三项，必须有）
- 本地商户（包含营业时间规范和地理坐标，不仅仅是地址字符串）
- 文章（包含发布日期、修改日期和作者（Person 类型），不是纯文本字符串）
- 常见问题页面（下文详述）
- 面包屑列表（容易被忽视，但能给 AI 代理提供网站层级地图）
- 操作指南（如果你发布教程或流程文档）
对于 WordPress 网站，我用 Yoast SEO 或 Rank Math 处理基础部分，然后在 <script type="application/ld+json"> 块中手动添加自定义 schema，覆盖它们没有涵盖的内容。使用 JSON-LD 格式。不是 RDFa，不是 microdata。JSON-LD。这样标记保持整洁，AI 代理可以直接提取，不会涉及你的展现层。
我在 2021 年犯过一个错误：我在客户的产品页面上添加了 schema，但留下了 price 字段为空，因为他们的价格是"联系报价"。schema 验证器通过了。但 AI 代理提取的是空白价格，并将其作为"价格：未知"返回给用户，这破坏了信任。修复办法是要么包含一个真实的价格范围（使用 minPrice / maxPrice），要么完全删除 offers 块。不完整的数据可能比没有数据更糟。
内容结构：为可扫描提取而写作
AI 代理阅读文章的方式和你不一样。它们在寻找问题的答案、可以提取的事实和主张之间的明确关系。
这意味着你的内容结构应该在前面就给出答案。如果有人（或某个程序）问"配送需要多长时间？"，你的页面应该有一个标题，比如说"配送时间"，标题下的第一句话应该直接说出具体数字。而不是先讲一段关于你仓库运营的背景。先给出数字，然后再讲背景。
我已经开始在客户网站上这样组织内容，几乎像是对每个小节都使用倒金字塔结构：
- 在标题下的第一句话直接陈述事实或答案
- 再加一两句支持性的背景信息
- 如果话题值得深入讨论，就链接到更详细的资源
就这样。没有开场段落。没有"好问题，让我们一起深入探讨这个话题"。智能代理会跳过这些噪音，有时甚至会搞错真正答案的位置。
在我们去年春天重建的一个旅游网站上，我们花了大约六周时间用这种方式重组了80篇文章。Perplexity对这些页面的引用次数明显增加了。更重要的是，这些引用指向的答案确实是准确的，因为相关事实是可以找到的。
Robots.txt、llms.txt和访问控制
这个比较新。现在有一个逐渐形成的惯例——还不是标准——叫做llms.txt的文件，放在你域名的根目录。这个想法是由Jeremy Howard提出的，目的是给语言模型智能代理一个纯文本形式的你网站最重要内容地图，以及任何访问偏好。把它想象成robots.txt的姐妹文件，但是是用纯英文写给语言模型代理而不是爬虫的。
你应该实现它吗？坦白说，应该。写一个只需要20分钟。这表明你的网站是具有代理意识的，随着越来越多的智能代理被训练去查找它，它会变成一个有意义的信号。
关于robots.txt，要特别谨慎。现在有些网站所有者本能地屏蔽所有AI爬虫。这是你的选择，但无差别屏蔽意味着你的内容也不会出现在AI生成的答案中，这是你放弃的一个分发渠道。把它看得像你在2005年考虑屏蔽Googlebot一样。可能不是个好主意。
内部链接和爬虫架构
遵循工作流的代理不只是登陆一个页面。它跟随链接。你的内部链接结构的质量决定了代理实际能遍历多少网站内容以及能理解多少。
内部链接差意味着代理只索引你网站的一两个页面然后停止。它们无法了解你提供的全貌。
好的内部链接意味着：
- 每个重要页面都可以从首页在三次点击内到达
- 锚文本具有描述性，不是"点击这里"或"阅读更多"
- 相关内容在正文中有上下文链接，而不仅仅在小工具侧边栏中
- 不存在孤立页面（或如果存在，你知道它们的存在，并选择故意留下它们）
在进行任何代理可读性工作之前，我在客户网站上运行Screaming Frog爬虫。仅孤立页面报告通常就能揭示客户认为已发布和易于查找但实际上并非如此的内容。一个客户有34个孤立页面，包括他们的主要案例研究。没有任何东西链接到它们。代理没有，人类也没有。
常见问题
我需要重新构建整个网站以便agent读取吗？
不需要。从你流量最高的页面和转化关键页面开始。通常是你的主页、主要服务或产品页面，以及那些目前排名靠前并带来线索的内容。先把这些做对。完整的网站审计最终很有用，但不是从这里开始的地方。
schema标记是否真的有助于AI agent响应？
根据我在客户网站上的观察，是的。当存在schema时，提取结构化数据的agent会返回更准确的答案，并更可靠地标注来源。不过这不是魔法开关。底层内容仍然需要准确和结构良好。Schema帮助agent找到和信任数据；它不能修复坏数据。
付费墙内容的网站怎么办？
在你的 Article 类型上使用 isAccessibleForFree schema属性，以及 hasPart / isPartOf 模式来标记哪些部分是付费的。这告诉agent他们可以使用什么。Google关于付费墙内容结构化数据的文档很清楚，相同的逻辑也适用于非Google agent。
llms.txt 是否已广泛支持？
还不是普遍支持。但实现它的成本几乎为零，早期采用这样的约定往往会获得回报。自2024年初以来，我就把它添加到Seahawk客户网站上了。现在是个小信号。12个月后会更重要。
我怎样测试agent是否能读取我的网站？
在终端中运行 curl -A "Mozilla/5.0" [your URL] 并查看返回的内容。如果你的主要内容没有出现在输出中,说明你有渲染问题。然后通过 Google 的富媒体搜索结果测试来验证 schema。同时检查 Chrome Lighthouse 的无障碍审核,因为 agent 可读性和无障碍性的交集比大多数人意识到的要大。
---
网络最初是为人类构建的,然后为搜索引擎进行了改造。现在需要再次改造,这次是为了适应 agent 的浏览方式——这与任何人类的浏览方式都不同。这不是危机,只是下一轮的工作。说实话,其中大部分都是良好实践,同样也会让网站对人类更友好。更干净的标签、更清晰的内容、更少的 JavaScript 冗余。你本应早就这样做了。