做蜘蛛池的人常把注意力放在域名、IP、入口页数量上，却容易忽略一个最基础的文件：robots.txt。它和页面 head 里的 meta robots、HTTP 响应头里的 X-Robots-Tag 一起，构成了对爬虫的准入说明。配置不当，入口页可能连被访问的机会都没有；配置过度，也可能把真正想引导的路径一起堵死。
三种 robots 指令，管的不是同一件事
- robots.txt：放在域名根目录，按 User-agent 分组，用 Disallow / Allow 控制哪些路径可以被抓取。它只影响抓取行为，不决定内容是否被使用。
- meta robots：写在 HTML 的 head 中，如 noindex、nofollow。前提是页面已经被抓取，爬虫才能读到这条指令。
- X-Robots-Tag：写在 HTTP 响应头里，作用与 meta robots 类似，对非 HTML 文件同样有效。
关键差别在于：Disallow 是别来抓，noindex 是抓了也别用。两者混用，很容易出现自相矛盾的结果。
入口页常见的三类误配
1. 用 Disallow 来藏入口页
有人不希望入口页被人看到，就在 robots.txt 里写 Disallow: /，同时又指望蜘蛛来访问。结果是爬虫在门口就被劝退，页面根本不会被读取，写在页面里的 noindex 自然也无从生效——因为爬虫压根没进来。想不被收录，稳妥做法是允许抓取、用 noindex 表达；想不被抓取，那就别指望它能承担任何发现价值。
2. 通配符把目标路径一起挡住
类似 Disallow: /*? 的写法会命中所有带参数的 URL。如果入口页到目标页的跳转带了跟踪参数，或目标页恰好落在被屏蔽的目录下，蜘蛛就走不到终点。规则上线前，建议按实际 URL 逐条核对，而不是凭感觉写一条通配。
3. 多套环境共用一份 robots.txt
测试环境从生产环境拷配置，把整站 Disallow；或者反向操作，把测试环境里放得很开的规则带到线上。上线前访问一次实际的 robots.txt 看返回内容，成本很低。
入口页该放什么、不该放什么
相对稳妥的思路是默认允许、局部收紧：
- 入口页与目标页所在路径保持可抓取，不加 Disallow；
- 后台、接口、临时目录、无意义的筛选参数，用 Disallow 明确挡掉；
- 需要爬虫跳过跟踪链接时，用 rel="nofollow" 或 nofollow 指令，而不是直接切断抓取路径；
- 在 robots.txt 中写清 Sitemap 地址，方便蜘蛛顺着找。
robots.txt 与 UA 屏蔽不是一回事
有些站点在 Nginx 或 WAF 层按 User-Agent 拦截，同时又希望正常的搜索引擎蜘蛛能进。这两套机制互相独立：robots.txt 属于协议层面的礼貌请求，是否遵守取决于爬虫自身；UA 拦截是服务器层面的硬性拒绝，返回 403 之后，爬虫拿到的只是一段错误响应。排查蜘蛛为什么不来时，这两处都要看日志，只查一处容易误判。
怎么确认配置真的生效
- 直接访问 https://域名/robots.txt，确认返回 200 且内容符合预期，注意区分不同协议与不同子域。
- 用命令行工具带不同 UA 请求入口页，观察是否被拦、返回码是否正常。
- 在服务器日志里按时间和 UA 过滤，看爬虫请求到的路径分布，确认目标页是否有访问记录。
- 如果用了 meta robots 或 X-Robots-Tag，抓取页面源码或响应头逐条核对，别凭记忆判断。
robots 配置属于基础项，它不会让蜘蛛凭空变多，但配置错误足以让一套入口页白做。把它放进部署清单的固定一环，比事后翻日志找原因要省事得多。
最后提醒：不同搜索引擎对 robots 指令的支持细节存在差异，通配符写法和 Allow 的优先级各有实现，写规则时以目标搜索引擎的官方文档为准。同时，任何以影响搜索结果为目标的批量操作都存在平台规则与法律层面的风险，部署前应先评估合规边界。