企业官网建设流程全解析

1. 为什么网站要对 Agent 友好：一场访问方式的静默变革

做 Web 开发这么多年，最近这一年我越来越感觉到一个变化——网站流量里"非人类"访客的占比在悄悄抬升。这个"非人类"指的不再是传统爬虫，而是 AI Agent。你打开后台的访问日志，会看到大量来自 OpenAI、Anthropic、Perplexity 等官方爬虫的 User-Agent，以及各类 Agent 框架发起的自动化请求。这不是偶发，而是结构性趋势：越来越多的用户不再直接访问网站，而是让 AI Agent 替他们"跑腿"——查资料、比价、订票、总结文档。

这就引出一个很现实的问题：你的网站是不是为这些"新访客"做好了准备？如果网站结构混乱、内容靠 JS 动态渲染、信息散落在图片和 PDF 里，Agent 读不懂、抓不全，那你就等于在 AI 时代"闭店歇业"。反过来，一个对 Agent 友好的网站，不仅能在 AI 搜索里获得更高的引用率，还能被各类智能体顺利对接，成为整个 AI 生态里的"基础设施"。

这几年 Agent 相关的讨论非常多，从框架选型到编排模式，从记忆机制到工具调用，但很少有人系统讲过"网站侧"该怎么配合。本文就围绕"怎样构建一个 Agent-friendly 的网站"这件事，把我在实际项目里踩过的坑、验证过的方法、以及沉淀下来的检查清单完整梳理一遍。无论你是个人站长、企业 Web 开发者，还是正在做 Agent 应用的大模型开发工程师，这篇文章都能给你一份可以直接落地的参考方案。

2. Agent 到底是怎么"看"网站的

要构建 Agent-friendly 的网站，首先得搞清楚 Agent 访问网站的技术路径。和浏览器不同，Agent 没有"视觉"和"交互"的完整链路，它依赖的是以文本为主的提取机制。

2.1 Agent 获取网页内容的三种主流方式

第一种是直接抓取 HTML。Agent 通过 HTTP 请求获取页面源码，然后用提取逻辑（比如 BeautifulSoup、Trafilatura 这类解析库）从 HTML 里剥离正文。这个方式最贴近传统爬虫，但 Agent 往往会在提取后把正文发给大模型做理解，所以对 HTML 的语义化要求更高。

第二种是通过浏览器自动化。很多 Agent 框架内嵌了浏览器工具，可以打开页面、滚动、点击、读取 DOM。这种方式能处理动态渲染的内容，但代价是速度慢、token 消耗大。OpenAI 的 Operator、Anthropic 的 Computer Use 这类产品走的就是这个路线。它们对网站的要求是：DOM 结构清晰、可交互元素有明确的语义标注。

第三种是调用站点提供的 API 或数据接口。这是效率最高的方式，也是 Agent-friendly 的终极形态——网站主动暴露机器可读的接口，Agent 直接拉 JSON 而不是啃 HTML。你会看到越来越多的站点开始提供 Markdown 或 JSON 格式的内容端点，原因就在于此。

2.2 Agent 访问与传统爬虫访问的本质差异

很多人觉得"我的网站爬虫能抓，Agent 就能用"，这个想法在 2024 年还行，2025 年就很危险了。传统爬虫的核心目标是索引，它把网页塞进搜索引擎的索引库，用户后续通过搜索引擎来访问。而 Agent 的核心目标是理解与决策，它抓取页面的目的是让大模型基于内容做推理、回答用户问题、甚至执行后续动作。

这个差异带来几个连锁反应：Agent 对内容的完整性更敏感，你页面上一段关键数据如果被折叠在"更多"按钮后面，爬虫可能还能抓到，但 Agent 在自动化操作里很可能直接漏掉；Agent 对信息的"噪声"容忍度更低，大模型的上下文窗口是有限的，如果你的页面塞满了广告、无关推荐、弹窗文案，Agent 把整页抓回去后，真正有用的信息会被稀释，回答质量直线下降；还有一点，Agent 对内容的可信度更看重，它没办法像人一样判断一个页面是不是软文，所以结构化数据（比如 Schema.org 标注）和明确的来源信息会成为 Agent 判断页面权威性的重要依据。

理解了这个底层差异，后面的所有优化动作就都顺理成章了：你要做的不是"让 Agent 能访问"，而是"让 Agent 低成本地、准确地、安全地使用你的网站"。

3. 构建 Agent-friendly 网站的五个核心维度

把"Agent 友好"拆开看，可以落地到五个具体维度。这五个维度互相独立，又彼此关联，我建议你按顺序逐一排查。

3.1 robots.txt 与抓取策略升级

robots.txt是第一个要动的地方。很多站点的 robots.txt 还是老一套：User-agent: *加Allow: /，或者干脆没有。但在 Agent 时代，你需要显式地考虑不同 Agent 的访问策略。

首先是识别。目前主要的 AI 爬虫包括 GPTBot、ClaudeBot、PerplexityBot、Google-Extended、CCBot 等。你可以针对性地做 allow/disallow 配置。我见过不少站点直接屏蔽了所有 AI 爬虫，理由是"带宽被大量消耗但没带来转化"，这个决策本身没问题，但你要想清楚：屏蔽意味着你的内容不会出现在 AI 搜索和 Agent 的引用来源里，这在 AI 流量占比越来越高的当下，等于主动放弃了未来的分发渠道。

其次是效率。如果你决定开放给 AI 爬虫，一定要控制抓取频率。AI 爬虫的抓取策略和搜索引擎不一样，它们经常会在短时间内对同一站点发起大量请求，如果没有限速控制，很容易把一个小站打挂。你可以给 AI 爬虫单独设置Crawl-delay指令，或者在服务器层面按 User-Agent 做限流。

这里有一个我实际用过的配置模板，可以给你参考：

User-agent: GPTBot Allow: / Crawl-delay: 10 User-agent: ClaudeBot Allow: / Crawl-delay: 10 User-agent: PerplexityBot Allow: / Crawl-delay: 5 User-agent: Google-Extended Allow: / Crawl-delay: 10 User-agent: * Disallow: /admin/ Disallow: /cart/ Disallow: /checkout/

注意最后一段：User-agent: *的 disallow 只针对隐私目录，不针对 AI 爬虫，这样既保护了敏感路径，又对 AI 保持开放。

3.2 结构化数据：让 Agent"读懂"内容语义

如果说 robots.txt 是"大门"，那结构化数据就是"门牌"。Agent 面对一个 HTML 页面，要理解"这个页面在讲什么、关键信息是什么、和我当前的任务有没有关系"，结构化数据是最直接的信号。

目前最主流的结构化数据规范是Schema.org，它提供了 Article、Product、Event、FAQPage、HowTo、BreadcrumbList 等丰富的类型定义。你要做的是为关键页面添加对应的 JSON-LD 标记。比如一篇技术博文，你可以这样标记：

{ "@context": "https://schema.org", "@type": "TechArticle", "headline": "怎样构建一个 Agent-friendly 的网站", "author": { "@type": "Person", "name": "作者名" }, "datePublished": "2026-01-15", "dateModified": "2026-01-20", "mainEntityOfPage": "https://example.com/agent-friendly-website", "publisher": { "@type": "Organization", "name": "站点名" }, "description": "本文系统讲解 Agent-friendly 网站的核心要点与实操方法" }

这个 JSON-LD 做两件事：一是告诉 Agent 这个页面的类型和主题，二是提供了作者、时间、描述等元信息，Agent 可以直接提取，不必从正文里猜测。实测下来，加了结构化数据的页面在 AI 搜索里被引用的概率明显更高。

除了 JSON-LD，HTML 语义化也非常关键。<article>、<main>、<nav>、<h1>-<h6>、<time>这些标签的正确使用，能让 Agent 的提取器快速定位正文区域，而不是在 div 的海洋里游泳。我审计过很多站点，发现一个高频问题：h1 标签堆了七八个，正文没有用 article 包裹，时间信息放在一个无意义的 span 里——这种页面人和搜索引擎都能忍，但 Agent 真的会读得很费劲。

3.3 页面渲染方式：SSR 优先，CSR 谨慎

页面是服务端渲染（SSR）还是客户端渲染（CSR），对 Agent 的友好度差异巨大。原因不复杂：Agent 抓取页面的默认方式就是发一个 HTTP 请求拿 HTML，如果你的页面全靠 JS 在浏览器里渲染，Agent 拿到的是一个空壳骨架，正文内容根本不存在。

很多用 Vue、React 做成的 SPA 站点都有这个问题。你在浏览器里看一切正常，但 curl 一下就露馅了——返回的 HTML 里只有<div id="app"></div>。这种站点对 Agent 来说就是一堵白墙。

解决方案有几个：一是改 SSR，让服务端直接输出渲染后的 HTML；二是用静态生成，在构建阶段就把页面打成静态 HTML；三是做动态渲染，对 AI 爬虫的 User-Agent 返回预渲染版本，对普通用户返回 SPA。第三种方案在过渡期很实用，我建议中小企业优先考虑。

这里要特别提醒：不要指望"Agent 会执行 JS"来兜底。确实有一部分 Agent 框架内置了浏览器工具，可以等 JS 执行完再读取内容，但这是以牺牲速度和 token 为代价的。如果你的站点能直接在 HTML 里把内容给全，Agent 会更愿意以低成本方式和你打交道。

3.4 内容可提取性：正文纯净度与格式友好

Agent 把页面抓回去后，通常会做一步"正文提取"。这一步的质量决定了后续大模型的理解效果。你可以在站内自查几个问题：正文区的 HTML 代码是不是干净、有没有夹杂大量非正文元素？关键信息是以文本形式存在，还是藏在了图片、视频、PDF 里？页面的正文有没有被截断或分页？

我见过最典型的反面案例是：一个教程网站的所有步骤说明都是截图，文字信息全靠图片里的字；还有的网站把核心数据放在 PDF 附件里，页面正文只有一句"详情见附件"。这种内容人类访问没问题，但 Agent 处理起来非常吃力——图片 OCR 有误差、PDF 解析有兼容性问题、token 消耗还大。

所以我的建议是：核心内容一律以文本形式呈现，图片和 PDF 只作为辅助。如果实在需要放表格，用 HTML<table>而不是嵌一张图片。如果内容很长，不要用"阅读全文"这种强制加载机制挡住 Agent，至少要让首屏或者 HTML 源码里包含完整信息。

另外，LLM.txt值得重点关注。这是社区在 2025 年开始流行的一个约定：在站点根目录放一个llms.txt文件，用 Markdown 格式列出站点的主要页面、简介和链接，相当于给 Agent 一个"站点地图的 Markdown 版"。它的好处是 Agent 拿到这个文件后，可以快速了解站点结构，再决定要抓哪些具体页面。我自己的站点已经部署了这个文件，实测下来 Agent 访问的路径清晰了很多。

一个简单的 llms.txt 长这样：

# Example.com > 站点一句话简介 ## 核心内容 - [怎样构建一个 Agent-friendly 的网站](https://example.com/agent-friendly-website): 系统讲解 Agent 友好站点的构建方法 - [Agent 开发学习路线](https://example.com/agent-roadmap): 从零到一学习 Agent 开发的路线图 - [主流 Agent 框架对比](https://example.com/agent-frameworks): 对比当前主流 Agent 框架的选型建议 ## 关于本站 本站主要分享 AI Agent 开发、Web 工程化相关的内容...

3.5 性能与稳定性：Agent 的耐心比人更少

最后是性能和稳定性。人访问一个慢网站，可能会等一等；但 Agent 访问一个慢网站，超时就是超时，抓不到就是抓不到。很多 Agent 框架对 HTTP 请求都有超时设置，比如 10 秒、15 秒，你的页面如果 3 秒还没返回完整 HTML，Agent 就会放弃。

有几个指标值得重点关注：TTFB（首字节时间）最好控制在 1 秒以内；HTML 文档体积不要过大，我见过有些页面光 HTML 就 1MB 多，里面塞了大量内联脚本和样式，Agent 抓回去之后上下文直接爆炸；服务可用性要达到 99.9% 以上，因为 Agent 可能在凌晨三点来访问你的站点，如果你的服务在凌晨做定时重启，恰好撞上 Agent 的请求，一次 503 就能让它认为这个站点不可用。

性能优化是个老话题，这里就不展开讲缓存、CDN 这些了。只强调一点：面向 Agent 的页面，HTML 体积和响应速度比过去任何时候都重要，因为你的"用户"没有耐心，也没有视觉补偿机制。

4. 实操：把普通网站改造成 Agent-friendly 的六步流程

前面讲的是理论和维度，这一节我们进入实操。我把改造流程拆成六步，你跟着做就行。以我自己的一个技术博客站点为例，从开始改造到跑通完整链路，大概花了两个周末。

4.1 第一步：审计站点当前的 Agent 可读性

动手之前先体检。你需要从 AI 爬虫的视角审视自己的站点。我常用的方法是：

# 用 curl 模拟抓取，看返回的 HTML 里有没有正文 curl -s -A "Mozilla/5.0" https://example.com/article-page | grep -c "<article" # 查看 HTML 里的正文文本量 curl -s -A "Mozilla/5.0" https://example.com/article-page | python3 -c " import sys, re html = sys.stdin.read() text = re.sub(r'<[^>]+>', '', html) text = re.sub(r'\s+', ' ', text).strip() print('正文长度:', len(text)) print('正文前500字:', text[:500]) "

这一步能快速暴露问题：页面返回的 HTML 里有没有正文？正文区域有没有被语义化标签包裹？总文本量和你在浏览器里看到的是否一致？不一致的话，说明动态渲染或内容截断的问题存在。

同时，你可以用现成的工具辅助审计。比如 Cloudflare AI Audit 、 Rankology 的 AI 友好度检测 这些，能直接分析页面被 AI 抓取的可读性评分。我习惯混合用——手工 curl 看细节，在线工具看整体评分。

4.2 第二步：配置机器人规则与站点地图

审计完，先做最基础的机器人规则配置。这一步的核心是：把你想让 Agent 看到的内容完全开放，不想让 Agent 看到的内容彻底隔离。

我建议你维护一份专门的"AI 爬虫白名单"配置，参考我前面给的模板，可以进一步细化。比如你的站点有多个内容分区，有的分区质量高、适合被 Agent 引用，有的分区是用户生成内容、质量参差不齐，你就可以在 robots.txt 里对 AI 爬虫做更细粒度的控制。

同时，站点地图（sitemap.xml）必须同步更新。Agent 拿到 sitemap 后，能够快速了解站点的内容全貌和更新频率。注意 sitemap 里的 URL 必须是可直接访问的最终地址，不要有重定向链。我见过一个站点，sitemap 里的 URL 重定向了两次才到最终页面，Agent 跟着走一遍，超时风险大增。

还有个细节：如果站点有多语言版本，记得在 sitemap 里标注hreflang。Agent 在回答多语言用户问题时，需要知道哪个页面对应哪种语言，这个信息如果缺失，它可能把中文页面的内容当成英文答案的来源。

4.3 第三步：为关键页面添加结构化数据

机器人规则配好后，下一步是内容层面的"语义标记"。我建议按优先级推进：文章页 > 产品页 > FAQ页 > 聚合页。

文章页用TechArticle或BlogPosting，产品页用Product，FAQ 页用FAQPage。不要试图一个页面塞太多 schema 类型，一个页面有一个主导的 schema 类型就够。如果你一个页面既标了 Article 又标了 Product 还标了 Event，Agent 反而会困惑这个页面到底是干嘛的。

这里有个实操技巧：把结构化数据集中放在一个 JSON-LD 块里，放在<head>中，而不是分散在页面各处。原因有两个：一是提取器通常优先扫描<head>区域的 JSON-LD；二是集中放置便于维护。

<head> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "怎样构建一个 Agent-friendly 的网站", "author": { "@type": "Person", "name": "作者名" }, "datePublished": "2026-01-15", "dateModified": "2026-01-20", "image": "https://example.com/cover.jpg", "mainEntityOfPage": "https://example.com/agent-friendly-website", "wordCount": 3200, "inLanguage": "zh-CN" } </script> </head>

加wordCount和inLanguage是我后来补充的，前者让 Agent 在决定"是否值得抓取"时有更准确的判断依据，后者避免语言识别错误。

4.4 第四步：输出 llms.txt 与机器可读内容端点

这是"锦上添花但非常有效"的一步。llms.txt 放在站点根目录，内容就是站点的 Markdown 版导航，我在前面已经给了模板。配置完之后，建议你测试一下：用任何大模型工具或 Agent 框架，直接让它访问你的站点根路径，看它会不会自动发现 llms.txt。

如果你有技术实力，还可以更进一步：提供一个llms-full.txt，把所有核心内容的完整 Markdown 一次性输出。这主要用于小型站点或者内容量可控的场景，让 Agent 一次抓取全部内容，避免多次请求。比如你的站点有 20 篇文章，每篇文章 2000 字，合计 4 万字，完全可以在一个文件里完整输出，Agent 一次拿全，体验极好。内容量太大的站点不建议这么做，你会把 Agent 的上下文窗口塞爆。

另外，如果你的业务是 SaaS 或者有数据产品，开放 API 端点是 Agent-friendly 的终极形态。你可以设计几个专门给 Agent 用的只读端点，返回 JSON 或 Markdown 格式的数据。注意给这些端点加上鉴权机制和限流策略，防止被滥用。

4.5 第五步：性能优化与稳定性保障

这一步服务于"Agent 能连得上、连连快"这个目标。性价比最高的几件事：

开启 CDN 和页面缓存。让 HTML 和静态资源尽可能靠近用户和 Agent，TTFB 能从几百毫秒降到几十毫秒。国内站点用又拍云、阿里云 CDN，海外用 Cloudflare，都行。

压缩 HTML 输出。很多框架默认输出的 HTML 有大量空格和换行，开启 Gzip/Brotli 压缩后，传输体积能减少 70% 以上。Agent 抓取的网络开销小了，超时概率也就低了。

审查第三方脚本。广告脚本、统计脚本、聊天插件如果放在<head>里且是阻塞加载的，会拖慢首屏。建议把非关键脚本全部改成异步加载，并给 AI 爬虫流量单独走一个不含第三方脚本的版本。这个可以用我之前提到的动态渲染方案实现。

设置监控告警。对你的站点做 uptime 监控，告警阈值设低一点。Agent 访问站点的高峰往往是你睡觉的时候，如果凌晨 3 点站点挂了 10 分钟，你可能根本不知道，但那些凌晨做任务编排的 Agent 会默默记你一笔"不可用"。我用 UptimeRobot 和自建的探活脚本双重监控，HTTP 状态码非 200 就立刻告警。

4.6 第六步：验证与迭代

改造完成后，验证是最后一道工序。我喜欢用一个简单粗暴的方式：直接用 Claude、ChatGPT 或各类 Agent 框架访问你的站点，然后问它"根据这个网站，总结一下 XXX"，看看它能拿到多少有效信息、回答得准不准。这个测试比任何技术指标都直观。

还有一个验证思路：模拟 Agent 的抓取逻辑，提取页面正文后，数一下正文里有多少是"有用信息"，多少是"噪声信息"。如果噪声占比超过 30%，说明站点对 Agent 的"信噪比"太低，需要进一步清理页面布局。

我建议把"Agent 友好度检查"加入你的常规发布流程。每次发新文章、改版页面，都跑一遍 curl 检查和 llms.txt 更新。这不是一次性工程，而是持续维护的运营动作。

5. 常见问题与排查技巧实录

做 Agent-friendly 改造的过程中，我整理了 5 个最高频的问题，附上排查思路，方便你遇到类似情况时直接对照。

5.1 Agent 拿到的正文不完整

现象：Agent 生成的回答里缺了文章后半部分或某些关键段落。

排查路径：先 curl 页面看返回的 HTML 里有没有完整正文。如果 HTML 是完整的，问题出在内容折叠——比如分页、懒加载、"阅读全文"按钮，Agent 的提取逻辑没触发后续的内容加载。如果 HTML 本身就不完整，问题出在动态渲染——页面内容依赖 JS 加载，Agent 直接抓取时只能拿到骨架。

解决：对于内容折叠，把完整正文直接输出在 HTML 里，隐藏的内容用 CSS 控制展示，而不是通过 JS 插入；对于动态渲染，做 SSR 或对 AI 爬虫的 User-Agent 返回预渲染版本。

5.2 Agent 请求把服务器打挂

现象：某个 Agent 框架在短时间内发出大量请求，服务器 CPU 飙高，带宽被占满。

解决：第一道防线是 robots.txt 的Crawl-delay指令，但它不是强约束，只是约定。第二道防线放在服务器层面，用 Nginx 按 User-Agent 做限流。第三道防线是在应用层面加缓存，如果页面是动态生成的，Agent 的每次访问都会触发一次完整渲染，开销很大；设置了 HTML 缓存后，同一个 URL 的重复请求直接走缓存，压力大幅下降。

这里有个技巧：给 AI 爬虫的 User-Agent 单独开一个低配缓存池。比如普通用户的缓存 TTL 是 60 秒，给 AI 爬虫的缓存 TTL 可以设成 300 秒，让 Agent 的重复请求尽量命中缓存。

5.3 Agent 只去首页，不去详情页

现象：Agent 拿到你的站点后，只在首页和部分聚合页停留，访问不到深层的详情页。

排查路径：检查首页的链接布局。Agent 在浏览网站时，会沿着页面里的链接往外爬。如果你的详情页没有从首页或者其他聚合页的链接链路上触达，Agent 就容易迷路。另外一个常见原因是：详情页链接用了 JS 事件而不是真正的<a href>，Agent 的提取器识别不到。

解决：内容页的链接一律用真正的<a href="...">，不要用<div onclick="...">；确保首页、分类页、标签页、sitemap 都能覆盖到主要内容路径；如果页面层级过深，增加面包屑导航，它既是用户体验优化，也是 Agent 理解站点结构的辅助信息。

5.4 Agent 把广告和弹窗当成正文

现象：Agent 生成的回答里出现了你页面上的广告文案或弹窗提示，甚至把这些当成你的核心信息。

原因：你的页面正文区域太"脏"，广告位、推荐位、登录弹窗混在正文的 HTML 结构里。Agent 的正文提取器不够聪明，把整个<main>里的内容都提取出来了。

解决：重构页面的 HTML 结构，让正文区只包含正文。广告位放到<aside>或用独立的容器，并且用 CSS 控制位置，而不是嵌在<article>里。另外，建议对 AI 爬虫单独渲染一个"纯净版"页面模板，去掉广告、推荐文章、弹窗这些干扰元素，只保留正文和必要的导航。这就是前面提到的动态渲染方案里的"降级版本"，实测下来 Agent 的提炼准确率提升非常明显。

5.5 Agent 无法处理登录墙后面的内容

现象：你的核心内容需要登录才能看，Agent 抓取时只能拿到登录提示页。

这是一个产品决策问题，不是纯技术问题。如果你希望内容被 Agent 索引和引用，就需要开放部分内容的免登录访问；如果是商业内容必须登录，那你要考虑的是如何为 Agent 提供一个"注册版"的访问机制，比如为 AI 爬虫单独签发只读凭证。

从技术角度看，我建议用"摘要公开 + 全文登录"的混合模式。页面 HTML 里包含完整的摘要和关键结论，全文部分放在登录墙后。这样 Agent 至少能获取到核心要点，如果它需要完整数据，会触发你的 API 鉴权流程——前提是你提供了 Agent 接入的官方通道。

6. 工具链与生态：Agent 框架、MCP 与网站的协同

做 Agent-friendly 网站，不能只盯着"让 Agent 抓取"这一个动作。整个 2025 年在 Agent 生态里最重要的变化是MCP（Model Context Protocol）的兴起，它改变了很多 Agent 与网站交互的方式。传统的 Agent 通过"抓取页面"理解网站，而 MCP 模式则是让网站或者第三方服务直接把"工具"暴露给 Agent。两者可以并行，但侧重点不同。

6.1 主流的 Agent 框架如何消费网站内容

大部分 Agent 框架对网站内容的消费方式可以归为两类：搜索型消费和提取型消费。

搜索型消费是指 Agent 不直接访问你的站点，而是通过搜索服务间接获取你的内容。比如 Agent 调用搜索 API，搜索 API 返回你的页面摘要，Agent 基于摘要决定是否访问原文。这种模式下，你在搜索引擎里的排名和摘要质量就变得非常关键。所以你会发现，传统的 SEO 工作在 Agent 时代并没有失效，只是评判标准从"排名"变成了"是否被 Agent 选择和引用"。

提取型消费是指 Agent 直接访问你的站点。比如用户给 Agent 一个 URL，Agent 需要"阅读"这个页面并处理信息。或者 Agent 在执行任务时需要去你的站点找特定数据。这种情况下，前面讲的 HTML 语义化、结构化数据、SSR 渲染这些优化就直接起效。

了解框架的消费方式对你是有用的：如果你的站点主要靠搜索引擎引流，优先优化 SEO 和结构化数据；如果你的站点是工具类、文档类，会被 Agent 频繁直接访问，优先优化静态化、性能和纯净度。

6.2 MCP 服务器与网站的内容对接模式

MCP 的模式是：你的网站服务端可以封装成一个或多个 MCP Server，对外暴露符合 MCP 协议的工具接口。Agent 通过 MCP 客户端连接你的服务器，直接调用工具，而不必再"抓页面猜意思"。

举个例子，你有一个文档站，可以封装一个 MCP Server，里面的工具有search_docs（按关键词搜索文档内容）、get_document（按 ID 获取完整文档）。Agent 连上之后，可以直接调用工具获取结构化内容，比你提供一个普通页面然后让 Agent 自己抓取要高效得多。

现在有不少网站平台开始原生支持 MCP 输出。比如一些知识库产品可以直接生成 MCP 端点，你只需要把 URL 提供给 Agent 的 MCP 配置里即可。如果你的网站是自建的，我建议评估一下封一个 MCP Server 的成本——大部分语言都有现成的 SDK，比如 TypeScript 的@modelcontextprotocol/sdk、Python 的mcp库。

这里有一个实用的思路：先做 llms.txt，再做 MCP。llms.txt 适合内容型站点，Agent 拿到它之后就可以自主浏览；MCP 适合功能型站点，Agent 需要调用具体能力。两个可以共存，互不冲突。

6.3 从网站侧反哺 Agent 生态的经验

当我们讨论"Agent 生态"时，不要忘了网站侧也是生态的一部分。一个对 Agent 友好的网站，本质上是在降低整个生态的"连接成本"。你开放了结构化的内容端点和标准的访问协议，就是在帮助 Agent 更高效地完成用户的任务。最终受益的还是你自己——你的内容会被更多 Agent 引用，你的服务会被更多 Agent 调用，你的品牌也就自然"长"进了 AI 时代的流量入口里。

这个过程中我有一些个人体会：做 Agent-friendly 改造，心态上要像"做开放平台"而不是"做页面优化"。把网站当成一个既是给人看、也是给 Agent 用的信息基础设施，你就会有源源不断的优化灵感，而不是机械地跟着教程打勾。

7. 最后分享一个验证技巧

文章最后，分享一个我一直在用的小技巧，算是给前面内容的补充。每次我做完 Agent 友好度改造，除了技术层面的验证，还会做一个"对话式验收"：在一个支持工具调用的 Agent 对话里，输入这样的指令——"请访问 example.com，并告诉我这个网站主要讲什么，列出三个最有价值的内容链接。如果你发现网站上有 llms.txt，请优先使用它。"

这个验收的价值在于：它会真实暴露一个 Agent 从零开始访问你站的完整路径。如果一切顺利，Agent 会先发现 llms.txt，然后按图索骥访问核心页面，最后给出一个结构化的总结。如果中途卡住了，比如 llms.txt 没被发现、某个页面抓取失败、某个关键信息缺失，你都能从这里看到端倪。

我有个小站就是通过这个方式发现了一个隐蔽问题：站点有个页面在移动端和桌面端显示的内容不一致，后台日志里我也没察觉，但 Agent 在验收时总是漏掉其中一段数据。排查了半天才发现是响应式渲染时对不同端做了内容裁剪。这个 bug 人眼很难发现，但对 Agent 却是致命的信息缺失。

说白了，Agent-friendly 没什么玄学，核心就是一句话：想象你自己是一个没有眼睛、没有鼠标、只有一次 HTTP 请求机会的访客，你能不能从这个网站里拿到最有价值的信息？能，那你的网站就是 Agent-friendly 的。不能，就照着前面说的五个维度，逐个去修。