robots.txt 完整指南从基础语法到生产级配置Front-End-Checklist 源码实践【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist导读robots.txt 是爬虫访问网站时获取的第一个文件其配置正确与否直接决定搜索引擎能否抓取并索引你的内容。本文以 Front-End-Checklist 仓库中seo/technical类目的robots-txt规则为骨架系统讲解该文件的语法、常见致命错误、生产级配置实践与验证方法并结合仓库内 apps/web/app/robots.ts 的真实实现与 packages/content/rules/en/seo/robots-txt.mdx 的结构化规则定义帮助你掌握从能跑到可靠的 robots.txt 落地能力。规则背景这条规则在检查什么在 Front-End-Checklist 中robots-txt是一条优先级为high、难度为beginner、预计耗时10 分钟的技术性 SEO 检查规则。其官方定义是Checks if robots.txt exists at the root, is accessible, and contains valid directives.也就是说它同时检查三件事存在性生产域名根路径下是否存在robots.txt可访问性该文件是否以 HTTP 200 正常返回有效性文件内的User-agent/Disallow/Allow/Sitemap指令是否符合协议。这条规则的完整元数据定义在 packages/content/rules/en/seo/robots-txt.mdx其中还给出了面向 AI 的审计提示prompts.check/fix/explain/codeReview以及四条关联规则sitemap、indexability-conflicts、noindex-in-sitemap、robots-meta-conflict——这提示我们robots.txt 从来不是孤立存在它必须与站点地图、索引信号、noindex 指令放在一起综合评估。robots.txt 是什么爬虫抓取的第一份文件robots.txt是放置于域名根目录的一个纯文本文件用来告诉搜索引擎爬虫哪些路径允许访问、哪些路径禁止访问。所有主流搜索引擎都会在抓取任何其他资源之前先读取它。它对应的行业标准是Robots Exclusion ProtocolRFC 9309同时 Google 的官方文档Google: robots.txt introduction是 Googlebot 具体行为的事实依据。这两份标准也是规则中Standards一节要求实现必须对照校验的基准。一个最基础的示例文件如下User-agent: * Disallow: /admin/ Disallow: /private/ Allow: / Sitemap: https://www.example.com/sitemap.xml它表达的含义是允许所有爬虫抓取根路径及公开内容但禁止访问/admin/与/private/并声明站点地图的位置。为什么它至关重要robots.txt 是爬虫抓取的第一个文件——配置错误的指令可能悄无声息地阻止搜索引擎抓取你的整个站点直接扼杀自然搜索流量。与meta namerobots或X-Robots-Tag等页面级指令不同robots.txt 是站点级的抓取控制层一旦写错影响面是整个域名。同时需要厘清一个概念边界robots.txt 控制的是抓取crawl而不是索引index。禁止抓取不等于页面不存在但在绝大多数情况下抓取被阻断的页面也无法被索引——这正是它与robots-meta-conflict、indexability-conflicts等规则需要联合审查的原因。常见错误三种典型配置对比❌ 错误一整站屏蔽User-agent: * Disallow: /Disallow: /意味着禁止任何页面被爬取和索引。这是生产站点上最危险的配置之一——它不会返回错误页而是静默地让整站从搜索结果中消失。线上环境应删除该规则或替换为具体的路径。❌ 错误二屏蔽 CSS 与 JavaScriptUser-agent: Googlebot Disallow: /assets/现代搜索引擎尤其是 Googlebot会使用真实的浏览器渲染页面依赖 CSS 和 JavaScript 来理解实际内容。屏蔽/assets/会导致渲染型索引失效爬虫看到的是一片空白或残缺页面。凡是渲染页面所必需的资源路径一律不得出现在 Disallow 中。✅ 正确实践仅屏蔽后台与内部路径User-agent: * Disallow: /admin/ Disallow: /cart/ Disallow: /checkout/ Allow: / User-agent: Googlebot-Image Disallow: /images/internal/ Sitemap: https://www.example.com/sitemap.xml这个示例展示了两个进阶要点按爬虫类型精细化控制User-agent: Googlebot-Image单独限制图片爬虫避免其抓取仅供站内使用的内部图片目录Allow: /兜底放行显式声明根路径允许抓取与后续具体的Disallow规则形成默认放行、例外屏蔽的清晰格局。核心规则速查规则说明文件位置必须精确位于生产域名的/robots.txtHTTP 状态必须返回 HTTP 200404 或其他 4xx 会让 Google 认为无任何限制即默认放行5xx 则会直接阻断抓取User-agent: *匹配所有爬虫针对特定爬虫应使用具体 bot 名称空值Disallow:等价于允许一切这是协议默认行为Sitemap:必须是绝对 URL如https://www.example.com/sitemap.xml特别值得注意第一条状态码规则的反直觉之处返回 404 并不会保护你的站点反而等同于告诉爬虫没有任何抓取限制。而 5xx 才是真正的灾难——它会阻断抓取。因此验证时不仅要确认文件存在更要确认返回的是 200。仓库中的真实实现Next.js 元数据路由实战Front-End-Checklist 的 Web 应用apps/web本身就是该规则的一个落地范本。它在 apps/web/app/robots.ts 中通过 Next.js 的MetadataRoute.Robots路由处理器动态生成/robots.txtimport { SITE_URL } from repo/config import type { MetadataRoute } from next export default function robots(): MetadataRoute.Robots { return { rules: [ { userAgent: *, allow: /, disallow: [/api/, /_next/, /static/] } ], sitemap: ${SITE_URL}/sitemap.xml, host: SITE_URL } }对照上面的规则速查表这段实现精确符合每一项要求位置Next.js App Router 约定app/robots.ts默认挂载在根路径/robots.txtHTTP 200由应用服务器直接响应天然返回 200User-agent: * 具体路径 Disallow对*声明规则仅屏蔽/api/、/_next/、/static/这些非内容资源——它们不需要被搜索引擎抓取但也绝不触碰任何渲染页面所需的资源Allow: /显式放行与规则中的推荐示例完全一致Sitemap:绝对 URL由SITE_URL常量拼接出完整的https://domain/sitemap.xmlhost:声明额外提供规范化域名提示。代码注释还提到该站点同时提供/llms.txt与/llms-full.txt——这是为 LLM 优化的内容文件与 robots.txt 一样属于爬虫入口类资源可在配置时一并规划放行策略。与站点地图的联动robots.txt 中的Sitemap:指令指向的正是 apps/web/app/sitemap.ts 生成的/sitemap.xml。该文件从content-collections读取全部规则与指南数据动态生成静态页面、分类页与内容页的条目。这两个文件共同构成爬虫的导航地图robots.txt 划定可抓取边界sitemap.xml 提供需要抓取的 URL 清单。这也是规则中将sitemap列为关联规则、建议一并审查的原因。页面级 robots 指令的配合robots.txt 是站点级控制层页面级的抓取/索引信号则由 apps/web/lib/seo-metadata.ts 中的元数据统一管理。该文件为每个页面定义robots元数据index/follow及 Googlebot 专属的max-video-preview、max-image-preview、max-snippet等指令并在noIndex场景下关闭索引robots: noIndex ? { index: false, follow: false } : baseMetadata.robots,这正好呼应规则中 Exceptions 一节的核心原则当重定向、canonical、robots 指令或索引信号相互冲突时应先修复最强的最终信号而不是把每个下游症状都当作独立问题上报。robots.txt 与页面级 meta robots 是两层不同的信号审查时应当区分抓取层与索引层各自的问题。验证方法自动化检查Google Search Console进入 Settings → Robots.txt tester提交当前文件并测试各规则的匹配行为浏览器直取在生产域名直接访问https://your-domain/robots.txt确认文件内容原样返回curl 状态码检查对线上主机执行curl -I $ORIGIN/robots.txt确认返回 HTTP 200curl -I https://www.example.com/robots.txt预期响应首行应为HTTP/2 200随后是Content-Type: text/plain等相关头。手动检查人工抽查有代表性的线上页面确认不存在会改变预期 SEO 结果的更强冲突信号如意外的 noindex、canonical 指向错误、重定向链等对照 RFC 9309 与 Google robots.txt 介绍文档逐条核验最终交付给搜索引擎的 HTML、元数据与抓取行为是否符合标准。特例与边界情况规则中的 Exceptions 部分给出了三类允许偏离的场景审查时应加以区分本就不参与排名的页面staging、工具类、登录、账户、站内搜索等页面可以有意采用不同的抓取或索引信号临时迁移状态迁移期间的中间信号会有噪音应标记线上生产 URL 的稳定模式而不是对一次性过渡产物逐个上报问题信号冲突时的优先级重定向、canonical、robots 指令与索引性信号冲突时先修复最强的最终信号避免把下游症状当成独立阻断点。总结把 robots.txt 从写一个文件升级为一套可靠的抓取控制策略需要抓住四个要点位置与状态必须位于/robots.txt且返回 HTTP 200404/5xx 都是危险状态默认放行、例外屏蔽使用Allow: /兜底仅对/admin/等内部路径使用Disallow严禁整站屏蔽或屏蔽渲染资源声明 Sitemap用绝对 URL 指向站点地图并保证其真实存在、可抓取分层验证自动化工具Search Console、curl 人工抽查结合并与页面级 robots 元数据、noindex 指令、canonical 等信号联合评估。在 Front-End-Checklist 仓库中你可以直接对照 apps/web/app/robots.ts 的生产实现、packages/content/rules/en/seo/robots-txt.mdx 的规则定义以及关联的 sitemap、robots-meta-conflict、noindex-in-sitemap 等规则构建一套完整的抓取与索引健康检查流程。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考