把博客开放给 AI：Allow Policy, Readability, 还有 Agent Discovery
前几天在 Cloudflare 面板看了眼流量, 发现 AI 爬虫的请求占比已经不小了. ChatGPT, Perplexity 这些工具都会派爬虫来抓站点, 把内容喂给自己的模型, 用来检索和引用.
这让我认真想了想: 博客内容到底要不要对 AI 开放? 开放了之后, 能不能做点什么, 让它们更好地理解我写了什么?
这篇不聊具体某个博客框架怎么配, 只聊几个通用的常识. 不管用的是 Hugo, 还是 WordPress, 还是自己搭的, 都用得上.
想清楚要不要放行 AI
很多站长第一反应是拒绝. 担心内容被"偷走", 担心 AI 回答抢走自己的流量.
但换个角度想: AI 引用我的内容, 本质上是一种曝光. 别人问一个问题, AI 回答说"可以看看这篇文章", 就多了一个入口. 个人博客的访问量本来就不靠搜索引擎一家, 被 AI 引用是免费的引流.
除非我的内容有付费墙, 或者我明确不想让内容出现在 AI 回答里, 否则放行是划算的. 这个问题值得想清楚, 因为 robots.txt 的默认行为往往已经替我做了决定——大多数博客什么都没配, 等于全部放行.
想清楚了, 后面的事情才有意义.
内容本身要对 AI 友好
AI 读我的博客, 和搜索引擎爬虫不一样. 搜索引擎看重关键词和链接, 而 AI 要的是"能不能读懂".
有几个朴素的原则, 和技术栈无关:
- 开头说清楚这篇讲什么. AI 经常只读开头几段来做摘要. 如果前几行是寒暄和废话, 它给出的内容总结就只能是废话.
- 用平实的语言, 少绕弯子. 故弄玄虚的标题和含糊的表述, 人类能猜出来, AI 猜不准.
- 标题要能概括内容. 一个"XX 踩坑记"式的标题, 不如"怎么解决 XX 问题"来得明确.
这些都不需要会写代码, 只需要有这个意识.
提供一份给 AI 的索引
越来越多的站点会额外提供一份给 AI 看的索引文件, 把"这个站有什么"写成一份清单. 这个方向目前有一个事实标准: llms.txt. 一些 AI 工具在引用一个站点时, 会先请求 https://站点/llms.txt, 拿到一份结构化目录, 再决定要不要深度抓取.
内容本身就有 Markdown 或干净文本的站点做这个最方便——等于顺手给 AI 递了一份目录. 不一定需要自己手动维护, 很多静态博客框架构建的时候就能顺便生成. 就算要手动写, 也只是几行清单.
好处是双向的: AI 拿到清晰目录, 引用我的概率更高; 我的内容也更容易被完整地读到, 而不是被截取开头几段.
顺手把 Agent Discovery 也做了
llms.txt 解决的是"让 AI 读懂内容". 但这两年 AI 产品接入网站的方式已经不限于抓取, 越来越多的 Agent 会先探测站点: 有没有标准入口? 有什么可用的资源? 确认之后才决定怎么接入. 这一批约定俗成的探测点, 统称 “Agent Discovery”.
做法本身和技术栈无关, 我以自己这个 Hugo + Cloudflare Pages 站点为例, 用的全是纯静态手段:
robots.txt里声明 Content-Signal. 一行Content-Signal: ai-train=no, search=yes, ai-input=no, 把对内容使用的偏好明确写出来, 比默认什么都不配要清楚.- 响应头里的
Link头. 用一个_headers文件给每个页面加上Link头, 指向llms.txt、RSS、sitemap 这些机器可读资源. AI 拿到 HTML 的同时, 也就看到了还有哪些结构化入口. /.well-known/标准端点. 放了/.well-known/api-catalog(linkset 格式的资源目录)、/.well-known/agent-skills/index.json(站点技能索引)和auth.md(声明内容全部公开、无需鉴权). 这些位置是社区约定俗成的, agent 会主动来探测.
全程不需要动态服务, 只是几个静态文件和几行配置. 但在 AI 眼里, 我的站点就从"一坨 HTML"变成了"一个有明确接口和文档的对象".
意识比技巧重要
技术方案一直在变, 今天流行的东西明天可能就被替代. 但这几件事是长期不变的:
- 想清楚内容要不要对 AI 开放
- 让内容本身容易被读懂
- 给 AI 一份结构化目录
- 顺手给 Agent 提供 Discovery 入口
它们都不难, 也不需要了解某个具体框架. 难的是知道有这么回事, 并且在建站或写内容的时候想起来.