为您的建站平台添加 llms.txt
llms.txt 是一种提议中的 Markdown 约定，用于呈现简洁的网站概述和精选链接。它不是 robots 策略、许可协议、身份验证控制，也不是通用的 AI 索引要求。以 H1 标题呈现网站名称、提供实用摘要和有条理的 Markdown 链接，有助于读者理解网站。该提案并未强制要求设置名称必须为 Docs 的章节，也没有统一要求摘要为 150 个字符。不同使用方的采用情况各异；不要声称所有主要 AI 爬虫都会读取它。
llms.txt 是一种提议中的 Markdown 约定，用于呈现简洁的网站概述和精选链接。它不是 robots 策略、许可协议、身份验证控制，也不是通用的 AI 索引要求。以 H1 标题呈现网站名称、提供实用摘要和有条理的 Markdown 链接，有助于读者理解网站。该提案并未强制要求设置名称必须为 Docs 的章节，也没有统一要求摘要为 150 个字符。不同使用方的采用情况各异；不要声称所有主要 AI 爬虫都会读取它。
WordPress 默认不直接暴露根目录文件。
英文完整指南Shopify 不允许直接托管静态根目录文件。
英文完整指南Webflow 不支持直接上传任意根目录文件。
英文完整指南Next.js 处理极简单：将文件放入 /public 目录或暴露一个输出纯文本的 route handler 即可。
英文完整指南在 src/routes/llms[.]txt.ts 添加一条服务端路由即可。
英文完整指南Ghost 通过主题服务 /public 文件，但在主题目录中添加路由文件更干净且不受主题更新影响。
英文完整指南Squarespace 不允许直接上传根目录文件。
英文完整指南Wix 不支持自定义根目录文件。
英文完整指南Framer 站点可以通过重定向到托管的文本节点来提供服务，但最规范的做法是在 Framer 域名上层挂载 Cloudflare。
英文完整指南HubSpot 支持通过设计工具（Design Tools）文件管理器上传自定义文件。
英文完整指南Astro 在构建时会原封不动地输出 /public 中的任何文件。
英文完整指南Gatsby 会在构建时自动将 /static 复制到网站根目录。
英文完整指南
llms.txt 能做什么，不能做什么
llms.txt 是一种提议中的 Markdown 约定，用于呈现简洁的网站概述和精选链接。它不是 robots 策略、许可协议、身份验证控制，也不是通用的 AI 索引要求。以 H1 标题呈现网站名称、提供实用摘要和有条理的 Markdown 链接，有助于读者理解网站。该提案并未强制要求设置名称必须为 Docs 的章节，也没有统一要求摘要为 150 个字符。不同使用方的采用情况各异；不要声称所有主要 AI 爬虫都会读取它。
在公共根路径部署，无需改动网站
在 /llms.txt 提供该文件，确保成功响应中包含预期文本，而不是套用网站主题的 HTML 错误页或登录界面。使用 CMS 支持的公共文件功能、静态托管资源，或明确配置的文本响应。如果平台保留了根路径，应先确认官方支持的部署方法，再添加插件或代理。既要检查自定义域名，也要检查托管预览，因为重定向和缓存的表现可能不同。
精选少量实用的目标页面
链接到稳定的规范页面：产品概述、定价、文档、支持政策和重要指南。使用描述性链接标签，并可选配简短上下文，让读者了解各页面涵盖的内容。绝对 HTTPS 链接是一种实用的发布选择，但这并不意味着相对链接会自动触发 HTTP 错误。排除私有控制台、草稿页面、跟踪 URL 和过时内容。及时更新链接指向的信息和译文；不要仅为增加文件篇幅而列出页面。
发布后及重要变更后进行验证
获取已部署的文件，检查响应正文、状态和内容类型；使用 UTF-8 字符集的 text/plain 是合理的默认设置。打开目标链接，确认其公开可访问且内容相关。在使缓存失效后，将线上文件与原计划部署的版本进行比较。验证器可以发现格式和链接问题，但无法证明引擎读取过该文件，也无法证明未来的答案会引用你的网站。
| 检查项 | 需保留的证据 | 行动 |
|---|---|---|
| 文件响应 | /llms.txt 的成功响应和可读的 Markdown | 修复 HTML 回退响应和私有路由问题 |
| 网站身份 | 清晰的 H1 标题和简洁、符合事实的概述 | 删除宣传性或相互矛盾的主张 |
| 内容链接 | 带有实用标签的现行规范页面 | 替换过时或发生重定向的链接 |
| 访问策略 | 独立的 robots.txt 和身份验证设置 | 不要在 llms.txt 中放置 Allow/Disallow 规则 |
| 维护 | 已发布版本和目标页面的变更 | 在产品或 URL 变化时更新 |
实施检查清单
- 确认 CMS 支持所选的公共根路径部署方法。
- 使用 Markdown，而不是照搬 robots.txt 模板。
- 描述网站实际提供的内容。
- 包含稳定的公开 URL 和清晰的标签。
- 部署后测试实际域名。
- 将该文件视为可选上下文，而不是引用保证。
可重复执行的工作流程
- 1建立基线
编辑前保存页面 URL、日期、语言、目标市场和问题原文。记录页面实际表述的内容，以及每个测试答案引用的来源；没有来源链接的提及不算引用。
- 2进行一次目标明确、相互协调的修改
先解决最明确的问题，然后检查已发布的页面，而不只是编辑器中的预览。保留实施日志，避免将无关的改版、营销活动或产品变更误认为是本项工作的效果。
- 3重复测试并比较
部署后重复相同的问题和技术检查。保持引擎与衡量条件一致，报告样本量，并在检查引用的同时检查答案准确性。单次回答不能代表稳定的排名。
常见问题解答
这能保证获得 AI 引用吗？
不能。即使页面可抓取且内容准确，也仍可能未被采用。检索、来源选择和生成的答案会因产品和请求而异；这些检查能改善可用证据，但不能保证入选。
如何判断改进是否有效？
对比同等条件下的检查结果，并保留底层证据。分别跟踪准确的品牌提及、带来源链接的引用，以及符合目标的引荐访问。不要把技术评分称为流量预测，也不要将每一项变化都归因于一次编辑。
在哪里配置抓取限制？
使用 robots.txt 向遵守规则的爬虫传达偏好，并使用身份验证保护私有内容。llms.txt 既不能强制执行抓取限制，也不能授予内容使用权。
相关主题中心
面向特定行业的 GEO 应从真实问题出发，而不是制作包含行业关键词的通用页面。软件采购者可能需要兼容性、安全性和定价详情；患者可能需要了解适用条件、风险和临床医生资质。使用受众的语言，并结合其所在司法管辖区撰写答案，明确适用对象，为每项主张附上来源链接。即使最终答案出现在 AI 界面中，搜索可访问性、实用内容和可信参考资料仍然重要。
SEO、AEO 和 GEO 存在重叠。SEO 包括让页面易于搜索访问、具有相关性并对用户有用；AEO 强调清晰回答问题；GEO 关注在生成式答案中的可见性和准确呈现。它们并非相互排斥的替代方案。应从业务问题出发：你需要更多符合目标的访问、更少被误解的产品答案，还是更清楚地了解引用情况？选择与任务相匹配的衡量方式，而不是断言某一领域在所有情况下都更优。
搜索助手可能在回答时检索来源、使用索引，或不进行浏览而依据模型知识作答。其爬虫控制和训练控制可能彼此独立。应测试你真正关心的功能和问题，而不是假定一条 user-agent 规则就能控制整个产品。这里的引擎指南用于帮助组织调查，并不意味着各厂商公布了相同的排名规则。
本地 AI 可见性取决于准确的商家事实，以及面向实际服务区域的实用答案。仅有一个城市关键词不足以成为再发布一个页面的理由。应说明真实的服务覆盖范围、联系方式、营业时间和特定地点的限制。不要为了让模板显得更充实，而编造办公室、地址、本地合作关系、市场份额统计或引用基准。
AI 搜索术语往往描述的是系统的不同层面。抓取负责获取页面；索引负责组织可用信息；检索负责为问题挑选资料；生成负责产出答案。引用是该答案中的来源标注，并不能证明之前所有步骤都已发生。当定义能帮助你定位问题、选择合适的检查，并避免做出超出证据范围的主张时，它才有实用价值。