企业官网建设流程全解析

2025 年 AI 基建领域最热闹的标准化动作之一，就是 llms.txt 协议的走红。它被当成“面向大模型的 robots.txt”，让网站可以主动告诉 AI 爬虫：这个站点是什么、哪些页面最重要、内容结构长什么样。坦白说，规范本身很轻、部署成本极低，放到网站根目录一个 txt 文件就可以生效。

但围绕 llms.txt 的争议也来得很快。它到底有没有被主流 AI 爬虫真正消费？你的页面因为放了 llms.txt 就被大模型引用了吗？这个问题目前没有稳定证据。有人用 cats.txt 这种无关的迷你测试文件做过对照验证，折腾一圈之后给出的评价很尖锐：llms.txt 的有效性证据，本质上和目前很多 GEO（生成引擎优化，Generative Engine Optimization）实践一样，属于“占星术”——看不见抓取链路、测不出引用归因，优化动作全是基于猜测的经验法则。

这篇文章就来拆这件事。前半部分说清楚 llms.txt 的技术规格和部署方式，值得花多少成本去配置；后半部分用实验思路和日志证据告诉你怎么验证 AI 爬虫是否真的来抓过，以及为什么很多人认为 GEO 领域的“证据链”目前依然薄弱。你不仅能学会创建和发布 llms.txt，还能获得一套可执行的验证方法，避免在没有任何观测手段的情况下盲目相信 GEO 玄学。

1. llms.txt 核心能力速览

先做一个快速规格表，把 llms.txt 的基本面列清楚，让你 30 秒判断它适不适合你的站点。

从这张表能看出，llms.txt 在设计哲学上延续了早期 Web 的简单粗暴：一个小文件、一段文本、放在公开 URL，谁愿意读就来读。它不像 robots.txt 那样具备“允许/禁止”的强制语义，更像一份主动递出去的名片。

1.1 llms.txt 与 GEO 的关系

GEO 的核心命题是：随着人们越来越多地让 ChatGPT、Gemini、Perplexity 等生成式引擎直接给出答案，传统 SEO 的“关键词排名 + 点击跳转”模式正在被“AI 引用 + 源头推荐”替代。GEO 从业者希望让自己的网站成为 AI 回答中的引用来源。

llms.txt 被普遍视为 GEO 技术栈里的一个基础设施层。因为它的存在可以让 AI 爬虫更准确理解网站结构，降低内容被引用的门槛。但是——这里要注意——从“部署 llms.txt”到“被 AI 回答引用”，中间的链路非常不透明：抓取时机不可控、内容清洗规则不可控、生成引擎的引用决策不可控。所以你看到很多 GEO 指南在谈“证据”，其实证据链是断的。

2. 适用场景与使用边界

llms.txt 不是万金油，不是什么站点都值得配。先看清它的边界，再决定要不要投入。

2.1 适合谁

内容型站点是最典型的适用对象。技术博客、开源文档、个人知识库、企业产品帮助中心、API 文档站，这类站点的内容天然适合被 LLM 引用。你有一个稳定的公开域名，页面之间有清晰的目录关系，那放一个 llms.txt 的成本几乎可以忽略不计。

另一个实用场景是给自己正在训练的 RAG（检索增强生成）应用服务。如果你自建了知识库应用，内部抓取外部站点时，优先找/llms.txt可以显著降低解析成本。这种情况下，llms.txt 的价值不依赖大厂爬虫是否响应，只要你自己公司的 Agent 能访问根路径，它就一定有用。

2.2 不适合谁

如果你的站点是动态内容、用户私有内容、需要登录才能访问的内容，或者页面大量依赖 JavaScript 渲染且无法提供静态摘要，llms.txt 就不合适。AI 爬虫倾向于抓取静态可读文本，你放一个需要执行大量脚本才能看到内容的页面，它就很难被理解。

此外，内容合法合规边界要盯紧。llms.txt 本质是公开索引文件，页面一旦被写入，就等于默认同意 AI 爬虫读取和引用。不希望在生成式 AI 的答案里出现的内容，不要放进 llms.txt，也别指望 robots.txt 能兜底——很多 AGENT 爬虫对 robots.txt 的遵守程度参差不齐。涉及版权素材、肖像、未授权转载内容的站点，必须在写入前做风险复核。

2.3 GEO “占星术”批判的是什么

所谓 “GEO astrology”，本质批评的是缺乏测量闭环的优化动作。传统 SEO 有搜索控制台、有排名工具、有点击漏斗；GEO 目前没有公开的“AI 引用面板”告诉你为什么你的内容被或不被某个答案采用。于是社区里出现了大量经验式建议：提高语言清晰度、增加结构化数据、更新实体链接、添加 llms.txt……每一条听起来都对，但很难归因到具体效果。

因此，看待 llms.txt 的正确姿态是：它属于低成本、低风险的方案，值得做；但如果你指望它带来确定性的流量或引用收益，目前缺少公认可量化的验证手段。这也是 cats.txt 一类实验存在的意义——用最小代价刺破盲目套路的泡沫。

3. 环境准备与前置条件

部署 llms.txt 不需要 Python 环境、不需要深度学习显卡，但前置条件依然要认真核对。

3.1 最小环境清单

给一个通用的命名为例，实际部署时替换成自己的域名即可：https://your-domain.com/llms.txt。推荐把文件放在根路径，因为协议默认爬虫会先去根目录找。你不要把文件放到https://your-domain.com/path/llms.txt，除非你有专门子站且能保证 URL 稳定。

3.2 观察工具的准备工作

如果你想要像后面实验部分那样验证抓取行为，还需要：

• 服务器访问日志功能，或者 CDN 访问日志（要能包含 User-Agent）
• 一个机器人 UA 列表文件，至少包含 GPTBot、ClaudeBot、Google-Extended、PerplexityBot、Bytespider
• 简单的 grep 或日志分析脚本能力

这些工具不需要一次配完，但建议在部署 llms.txt 之前就准备好日志。因为很多关键验证动作都是在已经过了一段时间后，回头翻日志才能看出效果的。如果你先把文件挂上、过了两个星期再想起看日志，而日志恰好被轮转清理了，那验证计划就基本作废。

4. 创建与部署 llms.txt

这一部分直接给实操模板。llms.txt 的内容最好是“人也能看懂”的 Markdown，因为它的受众不止是爬虫。

4.1 标准内容模板

# 你的站点名称 > 一句话描述这个站点是做什么的、内容覆盖什么范围。 Key: https://your-domain.com/ 首页 Key: https://your-domain.com/about 关于我们 Key: https://your-domain.com/topics 内容主题索引 ## 推荐阅读 - [文档总览](https://your-domain.com/docs) - [API 参考](https://your-domain.com/api) - [常见问题](https://your-domain.com/faq) ## 深度内容 - [2025 技术实践](https://your-domain.com/blog/2025-practice) - [架构设计说明](https://your-domain.com/blog/architecture)

关键点说明：

• 第一行必须是#开头的标题，不要写别的。
• >开头的行是摘要，建议 1 到 2 句话。这里的文字会被 LLM 当作对站点的高度概括，直接影响回答里对你的描述。
• Key:前缀的行用来标记最重要的链接，优先级队首。
• 普通链接按主题分区块整理，不要让文件变成一长串无分类的 URL 堆砌。
• 整体文件建议控制在 15KB 以内。大模型上下文有限，把最重要的信息放在开头。

4.2 配合 robots.txt 的设置

需要注意，llms.txt 和 robots.txt 是两个文件、两份逻辑。robots.txt 应对的是“能不能抓”，llms.txt 应对的是“抓完以后怎么理解你的站”。一个谨慎的配置示例如下：

User-agent: GPTBot Allow: / Disallow: /private/ User-agent: ClaudeBot Allow: / Disallow: /private/ User-agent: Google-Extended Allow: / Disallow: /private/ Sitemap: https://your-domain.com/sitemap.xml

然后把 llms.txt 放在根目录，或者你也可以选择在 robots.txt 里显式声明它：

# acceptable_llms_txt Allow: /llms.txt

4.3 验证文件可访问性

部署之后，先用 curl 快速验证 URL 返回状态：

curl -I https://your-domain.com/llms.txt curl https://your-domain.com/llms.txt

预期结果：第一条命令返回HTTP/2 200，Content-Type 建议是text/markdown; charset=utf-8或text/plain; charset=utf-8。第二条命令的响应正文与文件内容一致。注意如果是 CDN 缓存，记得刷新缓存，否则部分是旧版本。

4.4 一个可复用的格式巡检脚本

提供一个 Python 脚本，用于快速检查 llms.txt 是否遵守最基本的格式共识。这里用通用逻辑，不需要依赖第三方大型库。

import requests import sys def check_llms_txt(url: str) -> list[str]: target = url.rstrip("/") + "/llms.txt" problems = [] try: resp = requests.get(target, timeout=10, headers={ "User-Agent": "llms-txt-validator/0.1" }) except requests.exceptions.RequestException as exc: return [f"请求失败: {exc}"] if resp.status_code != 200: problems.append(f"HTTP 状态码非 200: {resp.status_code}") return problems text = resp.text if not text.strip(): problems.append("文件内容为空") lines = text.splitlines() if lines and not lines[0].strip().startswith("#"): problems.append("第一行应当是以 # 开头的站点名标题") if len(text) > 50_000: problems.append("文件过大, 建议控制在 50KB 以内") has_key = any(line.strip().startswith("Key:") for line in lines) if not has_key: problems.append("缺少 Key: 前缀的重要链接, 建议补充") return problems if __name__ == "__main__": url = sys.argv[1] if len(sys.argv) > 1 else "https://example.com" for p in check_llms_txt(url): print(p) print("检查完成")

运行方式：

python3 llms_validator.py https://your-domain.com

如果输出为空，只显示“检查完成”，说明基础格式通过；有输出则按提示逐项修复。

5. 验证实验思路：cats.txt 式的探测方法

“cats.txt”实验的核心意义在于：做一个不带任何 llms.txt 语义的对照组文件，然后观察 AI 爬虫行为。这是当前验证 llms.txt 是否真正被消费的有效思路，比直接宣称“我放了 llms.txt 所以被引用了”要严谨得多。

5.1 实验设计

构造两个同域名的测试文件：

• https://cats.your-domain.com/llms.txt，这是正式的 llms.txt 协议文件，里面写清楚站点有哪些猫相关内容。
• https://cats.your-domain.com/cats.txt，这是对照组，内容随便写几行猫的名称列表，不遵循任何协议约定。

控制变量：两个文件都在同一域名下、同一服务器、同一目录级别。唯一区别是文件名和内容格式。

验证问题：

1. 有规范格式的 llms.txt 是否被知名 AI 爬虫抓取？
2. 毫无协议语义的 cats.txt 是否也会被 AI 爬虫抓取？
3. 如果两者抓取频率相同，说明爬虫的行为更多是“扫描所有 txt 文件”，而不是专门认 llms.txt 协议；如果 llms.txt 明显被优先抓取，则协议价值得到初步证明。

实际测试时需要坚持 7 到 14 天的时间窗口。AI 爬虫不会刚上线就来访问，它们的抓取调度周期较长。多数公开留言中的情况是，llms.txt 上线后一到两周内会有 AI 爬虫访问记录，但没有强制保证。

5.2 怎么观察爬虫访问

用 Nginx 日志作为最直接的证据来源。以下命令可以筛选出常见 AI 爬虫的访问记录：

grep -i -E "GPTBot|ClaudeBot|Google-Extended|PerplexityBot|Bytespider|OAI-SearchBot" /var/log/nginx/access.log | tail -100

如果使用 Cloudflare，则可在日志渠道查看User-Agent字段，并过滤上述 UA 关键词。还需要检查是否有访问/llms.txt的记录：

grep "/llms.txt" /var/log/nginx/access.log | tail -50

对照实验的判断标准：

• 如果/llms.txt有稳定访问，而/cats.txt几乎没有访问，说明爬虫对协议敏感。
• 如果/cats.txt和/llms.txt都被抓，说明爬虫群体的行为更偏向全站抓取所有可达文本文件。
• 如果两者都长时间无访问，说明你的站点权重或发现链路还没有触发爬虫关注，此时 llms.txt 的效果更接近于“先埋线，等待收割”——无法在当时给出有效证据。

5.3 用“人工 AI 问答”做间接验证

除了服务器日志，还可以尝试用生成式对话产品做间接验证。比如你建立了一个小型测试站（cats.example.com），在 llms.txt 里写了一句辨识度极高的句子：“This site is a testbed named Blue Whisker”。过两周后用 AI 助手搜索“Blue Whisker 是什么”，看回答是否出现你的站点信息。

这种验证的问题在于：回答系统是否会实时抓取你的新站点，取决于产品策略、索引更新周期和用户活跃度。它只能给你“有可能被消费”的参考信号，而不是严谨结论。正因为这一点，很多人把这种间接验证批评为“占星术”——观察到的现象是模糊的，你很难排除其他干扰因素。

5.4 如何让验证结果更可信

建议建立一套可重复的观测模板：

建议每两周出一份观察报告，保存原始数据。这才是真正可以沉淀的经验，而不是听完一个 GEO 博主分享就盲目上线动作。

6. llms.txt 与 GEO：为什么被质疑为“占星术”

这一节把争议放到行业维度来讲。为什么一个看似简单有效的文件，会陷入是否被消费的争议？核心在于 GEO 的测量体系极不成熟。

6.1 传统 SEO 与 GEO 的测量断层

传统 SEO 有一套可测量的指标体系：搜索控制台展示点击量、关键词排名、外链构建效果、页面停留时长。做 SEO 的人知道自己做了 A 动作，B 指标在两周后变了。虽然也有噪声，但至少存在一个反馈号角。

GEO 目前没有等效的公共设施。OpenAI 不会公开告诉你“我们每周抓取了哪些 llms.txt 页面、哪些网页被放进了特定知识库的候选池”。Google 的 Google-Extended 虽然有爬虫，但搜索团队也没有向站长达人提供 GEO 专用分析面板。你可以看到“我自己站点有 AI 爬虫来过”，却无法知道“爬虫读完内容后到底把什么拿去用了”。

这种信息断层导致优化动作大量依赖猜测。今天有人宣称“结构化数据里的 FAQ 格式有利于 AI 收录”，明天有人宣称“在页面首段加 Summary 摘要能提高被引用率”，后天又有人强烈推荐“尽快部署 llms.txt”。每一条建议单独看都有道理，但合在一起就把整个优化策略变成了靠星座运势指引的决策过程——这恰恰是标题里 “GEO astrology” 的准确含义。

6.2 llms.txt 证据链的缺失

用一句话概括：达成率（部署了 llms.txt）不等于完成率（被有效消费）。即便你在服务器日志里看到了 GPTBot 的两次访问，仍然无法证明它读过、理解过、并最终影响了某个输出。协议本身没有设计反馈机制，这是目前最薄弱的环节。

从技术角度看，也可能 llms.txt 未来会被集成进更多 Agent 工作流，成为 RAG 应用默认检查的入口之一。但到那时，它会以“内部约定协议”的方式发挥作用，而不是依赖各大模型公开承诺。所以，现在就断言“我部署了 llms.txt，所以我的网站已被 GEO 优化”为时过早。

6.3 如何看待“证据不足，但值得部署”

即使证据链不足，我的判断依然是：llms.txt 值得部署，但不要过度期待。原因很直接：成本低、无副作用、属于一劳永逸的工程准备动作。你花两小时整理一个文件，未来万一主流 Agent 把 llms.txt 作为默认扫描目标，那你就已经提前拿到了入口优势。如果它一直没被大规模消费，损失也不过是两小时和一份静态文本文件。

这种“轻量布局，不赌结果”的姿态，才是工程上对抗 GEO 占星术的正确态度。不要因为别人的文章里写“llms.txt 带来了多少流量”就兴奋，也不要因为某个验证失败就全盘否定协议本身。把它当成一块数字地皮，占上位置，但不要押上经营主业务的时间。

7. 常见问题与排查方法

部署 llms.txt 时遇到的多数问题并不复杂，这里整理成一张排查表，按现象直接对位。

其中频率最高的坑是 robots.txt 的误伤。很多站点把User-agent: *的 Disallow 设置得过于严格，导致 AI 爬虫无法进入目录。建议懒人配置：允许常见 AI 爬虫访问根目录静态文件，只封禁/private/、/admin/这类路径。

8. 最佳实践与使用建议

最后这部分，按工程化视角给一套稳定可执行的操作建议。

8.1 内容清单要精简

llms.txt 的主要消费者是机器，但它代表的是“你希望机器看到的世界”。不要试图把全部 URL 都塞进去，只放管理员认为最重要的 10 到 30 个链接。每一个Key:链接都是你希望在 AI 回答中被推荐的候选入口。普通链接则用于补充主题覆盖范围。

8.2 日志观测要持续

建议把日志观测写成每月一次的任务。不需要天天看，但要把关键事件记录归档，例如第一次发现 GPTBot 访问、第一次发现/llms.txt有 200 响应、AI 回答时段性出现站点引用。保存这些原始观测日志，将来才能判断 llms.txt 是否在你的行业里真的起作用。

8.3 合法合规边界同步处理

发布 llms.txt 之前，确认页面内容拥有可公开传播的权利。如果包含人物肖像、声音、第三方版权素材，必须确认授权状态。尤其注意：llms.txt 不区分“给 LLM 看”和“给人看”，被写入的内容就是公开数据，生成式 AI 一旦引用并对外输出，你的合规责任不会减少。对于内容敏感或者仍在修改中的页面，宁可不上目录。

8.4 不要押注单一优化手段

llms.txt 只是 GEO 大拼图里的一个小块。真正健康的策略是：保证页面原创质量、给出清晰摘要、合理使用语义化 HTML、通过 sitemap 和正常外链提升发现效率，再配合 llms.txt 做 AI 侧的内容地图。几件事同时做、效果分散布局，比单独押注某个协议靠谱。

8.5 测试验证优先级

如果你在同一家公司运维多个站点，先选一个次要子域名做 cats.txt 对照实验，收集 14 天日志和 AI 回答反馈，再决定是否在主站大规模部署。这套小范围灰度思路适合所有新协议引入的评估，不只是 llms.txt。

8.6 接口服务与自动化平台的接入视角

对于那些正在构建 Agent 平台、RAG 系统或企业知识库工具的技术团队，llms.txt 是一个有价值的抓取入口协议。建议在你的爬虫服务里把/llms.txt作为第一优先抓取文件，检测到直接作为站点语义种子；检测不到时回退到页面正文解析。这种服务端统一支持一旦铺开，会反过来倒逼更多内容站去部署 llms.txt，形成真正的协议生态。

9. 现实一点的结论

llms.txt 不是银弹，也不是骗局。它是一个结构清晰、成本很低、设计动机合理的站点元数据协议。在当前阶段，它的最大价值不在于“保证 GEO 效果”，而在于为 AI 内容消费时代提前铺好了一份可读性极强的内容地图。

想真正验证它有没有用，别听别人的成功案例分享，去跑一个 cats.txt 式的对照实验：放一个规范 llms.txt、放一个随机 txt，观察两周服务器日志，再配合 AI 回答测试。看到数据再决定要不要继续加大投入，这比相信任何“GEO 星座运势”都靠谱。

从部署到观察，从部署一个文件到建立自己的证据链，llms.txt 这件事本身就变成了一次很好的工程实践：面对一个不透明的新兴生态，用小成本、可观测、可重复的方法去建立自己的判断体系。这也是在 GEO 占星术盛行的环境里，技术博主能给你的最实在的建议——先把证据拿到手，再谈优化信仰。