robots.txt 是站点给爬虫看的第一份说明文件。它不负责收录，也不负责排名，只表达“哪些路径希望被抓取、哪些不希望”。一旦写错，轻则浪费抓取额度，重则让重要栏目长期不被发现。做站点运营时，把它当成门禁规则定期复核，比事后从日志里找原因更省事。
先看文件本身能不能正常访问
在浏览器或命令行访问 https://example.com/robots.txt，确认返回状态码是 200，内容不是空白、不是首页 HTML、也不是服务器默认页。如果返回 404，理论上爬虫会认为没有限制，但很多站长会误以为已经屏蔽。若返回 403 或 5xx，不同爬虫处理方式不一致，最稳妥的做法是先修好访问，再谈规则。
User-agent 匹配：别把全局规则写成只对某个爬虫生效
robots.txt 按 User-agent 分组。常见的错误是：想屏蔽所有爬虫，却只写了 Baiduspider 或 Googlebot；或者想放行搜索蜘蛛，却在 User-agent: * 下写了过宽的 Disallow。复核时把每一组规则对应到实际爬虫名称，确认没有把“只针对某个工具”的规则误写成全局。
Disallow 与 Allow 的顺序和优先级
同一 User-agent 组内，通常更具体的路径规则优先，但不同爬虫实现有差异。不要依赖“后面的规则一定覆盖前面”这种假设。如果既要屏蔽目录又要放行其中某个子目录，建议把 Allow 写在前面或单独分组，并实际测试。例如屏蔽 /search/ 但放行 /search/help/，就需要写清楚，而不是只写一条 Disallow: /search/ 然后期待例外自动生效。
通配符和结尾符不要凭感觉写
* 表示任意字符，$ 表示路径结尾。写 Disallow: /*.pdf$ 可以屏蔽所有 PDF 链接，但要确认是否真的想屏蔽全部 PDF。写 Disallow: /admin 会同时影响 /admin、/admin/ 以及 /admin-notes 这类前缀相同的路径。如果只想限制目录，通常写成 Disallow: /admin/ 更稳。规则越宽，越容易误伤正常栏目和分页。
robots.txt 不能替代 noindex
robots.txt 只控制抓取，不控制索引。如果页面已经被抓取并索引，事后加 Disallow 通常不会让它从搜索结果消失，反而可能因为爬虫看不到页面上的 noindex 而无法更新状态。需要页面级移除时，应优先用 noindex，并确保爬虫能访问该页面。反过来，如果只是不想浪费抓取额度，才用 robots.txt 屏蔽。
一个常见误区是：用 robots.txt 屏蔽后台、测试目录和参数页后，就以为它们不会出现在搜索结果里。实际上，只要外部有链接指向，这些 URL 仍可能被索引。抓取控制和索引控制要分开处理。
和站点地图、canonical 的配合
robots.txt 里可以声明 Sitemap 地址，方便爬虫发现。但如果 Sitemap 中的 URL 又被 robots.txt 屏蔽，就会产生矛盾信号。同样，canonical 指向的地址也不应被 robots.txt 挡住，否则爬虫无法读取确认。复核时把 robots.txt、Sitemap、canonical、noindex 放在一起看，确认没有互相打架。
上线前后的复核清单
- 直接访问 /robots.txt，确认返回 200 且内容完整。
- 逐条检查 User-agent 分组，确认没有把全局规则误写进单爬虫组。
- 检查 Disallow 路径是否过宽，是否误伤栏目、分页、静态资源。
- 确认后台、测试环境、临时目录确实被屏蔽，且没有暴露敏感路径。
- 确认重要栏目和 Sitemap 地址没有被误屏蔽。
- 检查 Sitemap 声明地址是否正确、可访问。
- 用不同 User-agent 测试抓取结果，或查看服务器日志中的蜘蛛访问记录。
- 改版、换域名、调整目录后，重新复核一遍。
日常监控与改动习惯
把 robots.txt 纳入变更记录：谁改的、改了什么、为什么改。上线后观察蜘蛛日志，看重要目录的抓取频次是否异常下降。如果站点使用蜘蛛池或外部引导方式增加 URL 发现机会，更要先确认 robots.txt 没有把目标路径挡在门外，否则引导来的爬虫也只能空手而归。每次修改后，用抓取测试工具或日志验证，不要只靠肉眼觉得“应该没问题”。
最后提醒一句：robots.txt 是公开文件，任何人都能查看。不要在注释里写内部路径、账号规则或临时密钥。运营上的小改动，先小范围测试，再全量生效。