在蜘蛛池和站点运营中，robots.txt 常被当成一个随手写的“开关”。但入口页和目标 URL 分属不同目录、甚至不同域名时，规则很容易互相打架：入口页允许抓取，目标 URL 却被 Disallow 掉；或者反过来，入口页被屏蔽，链接再多也没人发现。搜索蜘蛛到底听谁的，取决于它当时请求的是哪一个 URL。
抓取决策是按 URL 逐个做的
搜索蜘蛛在请求某个 URL 之前，会先取对应域名的 robots.txt，再用这个 URL 自身的路径去匹配规则。它不区分“入口页”和“目标 URL”，也不会因为入口页允许抓取，就顺带放宽对目标 URL 的限制。入口页的作用是提供链接线索；要不要抓目标 URL，是另一次独立判断。所以出现规则冲突时，不存在“谁压过谁”，只有“这一条请求被放行还是被拦下”。
三种常见的规则冲突
1. 入口页允许，目标 URL 被屏蔽
这是最典型的情况。蜘蛛正常抓取入口页，解析出链接，但在准备请求目标 URL 时命中 Disallow，于是放弃抓取。表现上，入口页日志有访问记录，目标 URL 的日志长期空白。需要留意的是，Disallow 阻止的是抓取，并不等于把页面从索引中移除。此前已经被抓取收录的页面，仍可能留在索引里，只是内容可能逐渐变旧、缺少描述信息。
2. 入口页被屏蔽，目标 URL 允许
这种情况下蜘蛛根本不会请求入口页，也就无从解析里面的链接。目标 URL 即使规则上完全开放，也只是少了一条被发现的路。如果目标 URL 没有其他外链、sitemap 或站内入口，被发现的速度会明显变慢，甚至长期不被发现。日志上的特征是入口页没有任何蜘蛛访问记录。
3. 目录级通配符误伤
像 Disallow: /*? 或 Disallow: /tmp/ 这类写法，本意是屏蔽某一类路径，实际可能连入口页或目标 URL 一起盖住。带参数的链接、多层目录、大小写不同的路径，都容易被顺带命中。规则写得越宽，误伤面越大，而且很难从规则文本上直接看出来。
排查顺序
- 确认目标 URL 实际用的是哪个域名的 robots.txt。跨域、子域、CDN 回源域名可能各有各的规则。
- 把入口页 URL 和目标 URL 分别拿去对照规则，逐个路径匹配，而不是只看规则文件里有没有 Disallow 字样。
- 看抓取日志：入口页有没有被请求？目标 URL 有没有被请求？两边都空，说明问题可能出在更前面，比如 WAF、DNS 或 IP 层面的限制。
- 检查是否存在 Disallow 与 noindex 同时出现的情况。这种组合下蜘蛛不抓页面，也就看不到页面里的 noindex，索引中的旧版本可能长期保留。
- 修改规则后观察一段时间，不要期待立刻见效。抓取节奏本身存在延迟，回访间隔也不是固定值。
几个容易混淆的点
- Disallow 不等于删除：它管的是抓取行为，不直接管索引结果。
- robots.txt 返回 404 或超时：多数引擎会按“允许抓取”处理，但这不代表可以放任不管，规则缺失时误抓的风险更高。
- 403 和 Disallow 的表现不同：Disallow 下蜘蛛通常根本不发请求；403 是发了请求被拒，日志里能看到痕迹。
- Crawl-delay 与 Disallow 是两回事：前者调节抓取速度，后者决定能不能抓。
排查这类问题时先问一句：蜘蛛此刻请求的是哪个 URL？把入口页和目标 URL 分开看，很多看起来像“规则玄学”的现象其实一眼就能对上。
最后提醒一点，robots.txt 是各引擎自愿遵守的约定，不同引擎对通配符、大小写、路径匹配的处理细节并不完全一致。把它当成一份需要定期复核的配置文件，而不是写完就忘的摆设，能省掉不少反复排查的时间。