先分清：robots.txt 管的是抓取，不是收录
robots.txt 是大多数爬虫在正式抓取前会先读取的文件，它回答的问题只有一个：这个 URL 能不能被请求。它不决定索引，不决定排名，也不是保密工具——文件本身是公开的，写进去的路径等于对外公示。蜘蛛池入口页数量多、域名杂，这个文件经常被当成走过场，但因为写错一条规则让整批入口页白做的情况并不少见。
基础写法：明确放行，精准封禁
如果入口页的目标是让爬虫顺畅走完整站，最简写法就是全站放行，再把确实不需要抓的目录单独挡掉。
- 用 User-agent: * 加 Allow: / 明确放行，比只写一个空的 User-agent 段更不容易被误读。
- 后台、站内搜索结果页、购物车、带 session 参数的 URL，逐条 Disallow，不要图省事写一条 Disallow: /。
- 把入口页的 sitemap 地址用 Sitemap 行写出来，方便爬虫顺带发现更多 URL。
规则冲突时，路径更长、更具体的规则优先，这一点各家爬虫的实现基本一致。但通配符 * 和结尾的 $ 属于扩展语法，支持程度不统一，规则写得越复杂，被小众爬虫误读的概率越高。入口页这类需要稳定抓取的站点，规则宜简不宜繁。
Crawl-delay 要不要写
Google 官方并不认 Crawl-delay，Googlebot 的抓取速度主要通过 Search Console 里的抓取频次设置来调整；Yandex、Bing 等对 Crawl-delay 有不同程度的支持。入口页服务器资源紧张时，写一个 Crawl-delay 有一定意义，但别指望它能约束所有爬虫。
更稳妥的做法是把限速放在服务端：按 IP 与 User-Agent 做并发控制，在 Nginx 层限制单 IP 连接数，再从访问日志里观察真实到访节律，反过来决定限速阈值是否需要调整。
多域名、多环境最容易踩的坑
- 测试站复制了线上 robots.txt，里面写着 Disallow: /，上线时忘了删。
- 泛解析域名共用一个 robots.txt：robots.txt 按主机名生效，子域需要各自放一份，共享逻辑在配置层面根本走不通。
- 用脚本按 UA 返回不同内容，短期看似灵活，长期既容易被判定为异常行为，出问题时也极难复现排查。
误封自查顺序
- 直接在浏览器访问 https://域名/robots.txt，确认返回 200，且内容是最新版，而不是 CDN 或缓存里的旧副本。
- 用搜索引擎官方的 robots 测试工具验证目标 URL 到底是被放行还是被拦截。
- 检查是否存在 Disallow: / 之后又被 Allow 覆盖的规则冲突。
- 检查通配符与结尾 $ 的位置，例如 Disallow: /*? 会误伤所有带参数的正常页面。
- 确认文件不是持续返回 5xx：多数爬虫在长时间取不到 robots.txt 时会收紧甚至暂停抓取。
如果只是不想让某些页面被索引，用 meta robots 或 X-Robots-Tag 更直接；robots.txt 解决的是抓取层面的问题，两者不要混着用。
发布前可对照的最小清单
- 根目录静态文件，200 返回，UTF-8 编码，体积控制在几十 KB 以内。
- User-agent: * 明确 Allow，内部目录按路径 Disallow。
- Sitemap 行指向入口页对应的 sitemap 地址。
- 每个独立主机名（含子域）各配置一份，不共用。
- 上线流程里加一步：发布前对比线上 robots.txt 与预期内容的差异。
一个写错的 Disallow 不会立刻报错，只会让抓取量在某天悄悄掉下去。把它放进发布检查清单，成本很低，收益却相当直接。