robots.txt 常被当成一个开关：要么全站放行，要么把某些目录关掉。实际用起来，它更像是给蜘蛛划出的一条路线边界——能挡住一部分 URL，也能给出抓取节奏的提示，但它不保证任何页面被收录。写错的时候，问题往往不是少收录几个页面，而是蜘蛛在整站范围内的抓取行为被改变。
一、robots.txt 不是提交入口
先明确一点：robots.txt 只做限制，不做推荐。把 Sitemap 地址写在 robots.txt 里，是告诉蜘蛛站点地图在哪，方便它找到这份清单；但不代表写进去的 URL 会被优先抓取，更不代表会出现在搜索结果里。同理，没写进 Sitemap 的页面也不会因为 robots.txt 放行而自动获得抓取优先级。
很多人把这两件事混在一起，于是出现一种典型误判：站点地图提交了，robots.txt 也放行了，但新页面还是没动静，就去反复改 robots.txt。真正的原因可能在别处——内链没有指向它、页面返回了非 200 状态、或者服务器响应时间太长，蜘蛛拿不到内容。先分清是发现环节还是抓取环节出了问题，比改规则更有效。
二、Disallow 的匹配方式最容易踩坑
用 Disallow 时，路径是前缀匹配，不是目录精确匹配。这带来几个常见的连锁问题：
- 写 Disallow: /search 会同时挡住 /search、/search-page、/searching 等所有以 /search 开头的路径。
- 通配符和结尾符需要先确认蜘蛛是否支持。主流搜索引擎支持，但不确定时应先用少量路径验证效果，再决定是否大面积使用。
- 顺序问题：不同爬虫对 Allow 与 Disallow 冲突时的处理并不完全一致，稳妥做法是别让两条规则指向同一路径。
还有一种容易被忽略的情况：误伤静态资源目录。页面本身可以抓，但样式和脚本被挡住，蜘蛛拿到的就是一份不完整的页面，内链和正文都可能看不全。
三、Crawl-delay 只能减速，不能提速
有些运营想通过 Crawl-delay 让蜘蛛抓快点，这个方向是反的。这个字段表达的是两次请求之间请等一会，只会拉低频率。它在部分搜索引擎身上不一定生效，而且同一台服务器上如果同时存在多个站，硬性拉长延迟可能让抓取预算消耗在排队上，而不是页面本身。
如果日志里看到蜘蛛请求密集、服务器吃不消，先看的应该是响应时间和错误率，而不是急着写 Crawl-delay。5xx 和超时堆积时，蜘蛛自己就会降速，这是服务器稳定性的问题，不是速度设置的问题。等服务器恢复平稳，再观察抓取节奏是否自然回升。
四、屏蔽之后的连锁反应
被 robots.txt 挡住的 URL，蜘蛛不会去读页面内容，于是会出现几种连带效果：
- 该页面上的出链不再被发现，原本靠它传导的内链路径断掉一截。
- Sitemap 里如果还留着这些 URL，日志会看到蜘蛛反复尝试又反复放弃，形成大量无意义请求。
- 之前已被抓取的页面若突然被屏蔽，索引中的旧版本可能长期保留，内容更新传达不出去。
- 页面在搜索结果中即使仍有展现，用户点进去看到的也可能与摘要不一致，影响后续行为数据。
五、从日志核对的顺序
发现抓取异常时，可以按下面的顺序核对，避免一上来就改规则：
- 确认 robots.txt 可访问、返回 200、内容类型正常，且没有被 CDN 缓存成旧版本。
- 在日志里筛出目标路径，看蜘蛛是没来还是来了被挡。没来时查内链和 Sitemap；来了被挡时，对照规则逐条比对前缀。
- 检查 Sitemap 与 robots.txt 是否互相矛盾：Sitemap 收录的 URL 却被 Disallow 挡住，这是最常见的浪费。
- 确认没有把关键目录误写成全站屏蔽，也确认静态资源目录没有被误伤。
- 改完规则后，观察日志中的请求分布和状态码变化，而不是只看某一天的总量。
robots.txt 是一条边界，不是一个开关。它决定蜘蛛走到哪里为止，不决定蜘蛛会不会喜欢你。边界画错，后面的 Sitemap、内链和抓取节奏都会跟着走偏。
六、写规则时的几个习惯
- 规则尽量少而明确，避免一条通配挡掉一大片路径。
- 测试环境与线上环境的 robots.txt 分开管理，别让测试规则被带上线。
- 改动前先拉一段日志做基线，改动后再对比，判断影响范围。
- 把 robots.txt 纳入上线检查清单，和重定向、Sitemap 一起看。
抓取这件事本身变量很多，robots.txt 只是其中一层。把它写清楚，至少能保证蜘蛛看到的是你希望它看到的入口，而不是在门口就掉头。