robots.txt 是搜索蜘蛛抓取前的第一道判断。它不决定页面是否被索引，却会直接决定这条 URL 能不能进入抓取路径。不少站点把低频路径、参数页、后台目录一股脑写进 Disallow，几个月后才发现，本该被发现的页面也没被抓到。问题通常不出在“屏蔽”这个动作，而在规则写法和复核方式上。

匹配逻辑：不是从上往下逐行读

主流搜索引擎在处理 robots.txt 时，多采用“最长匹配优先”的思路，而不是简单按出现顺序取第一条命中的规则。也就是说，命中的规则字符串越长、越具体，优先级越高；长度相同时，Allow 一般优于 Disallow。这条规则决定了同一段配置在不同书写方式下会得到完全不同的结果。

• “Disallow: /”配合“Allow: /public/”是可行的，前提是放行路径写得足够具体。
• 通配符“*”代表任意字符序列，“$”代表结尾，两者叠加时容易命中预期外的 URL。
• 路径区分大小写，“/News/”和“/news/”是两条不同规则。

Allow 与 Disallow 冲突时的核对顺序

当两条规则同时命中一个 URL，处理方式可以归纳为三步：先比长度，再比具体程度，最后看其中一方是否为 Allow。实操中容易踩的坑，是把例外写在通配符规则之前，以为顺序能起作用，结果通配符规则更长，仍然把例外覆盖掉了。

比较稳妥的做法是把需要放行的目录单独列出，并保证它的路径长度大于被屏蔽的父目录。例如屏蔽整个参数泛滥的筛选目录，同时放行其中少数确实有内容价值的路径。

三类常见误伤

通配符一刀切

用一条规则屏蔽全部带问号的 URL，是最省事也最容易出问题的写法。排序、筛选、分页参数里往往混着有效入口，一刀切之后这些页面既不会被抓取，也不会进入后续的抓取排期。

屏蔽目录后忘记放行子路径

目录调整、内容迁移之后，旧的屏蔽规则常被保留下来。新内容恰好落在被屏蔽目录下，表现就是“明明加了内链，却迟迟没有抓取记录”。

sitemap 与 robots 互相矛盾

把被屏蔽的 URL 写进 sitemap，等于一边邀请一边关门。蜘蛛读到 sitemap 里的条目，抓取时又被规则拦下，除了浪费一次请求，也会削弱 sitemap 本身的可信度。

被屏蔽不等于不会被发现

URL 的发现和抓取是两件事。外链、sitemap、内链都可能让蜘蛛知道某个 URL 存在，但规则判断发生在请求之前。日志里如果出现“规则中已屏蔽、却仍有请求”的情况，通常要从这几个方向排查：

• 规则文件返回了非 200 状态码，或被 CDN、WAF 改写；
• 请求来自其他爬虫或未声明身份的工具；
• 规则写法存在语法错误，整行被忽略。

复核清单

1. 拉取 robots.txt，逐条列出规则，标出通配符与结尾符的位置。
2. 挑 10 到 20 个有代表性的 URL，包括重要栏目页、深层内容页、参数页，手动推演会命中哪条规则。
3. 对照 sitemap 与内链，确认没有重要 URL 落在屏蔽范围内。
4. 查看日志中目标目录的实际请求量，规则收紧前后各取一段时间做对比。
5. 规则变更后留出观察期，不要在同一天同时改动内链结构和 sitemap。

什么时候该动，什么时候不该动

抓取预算有限时，屏蔽确实是一种收敛手段，但它只适合处理确定没有价值的路径，比如后台、站内搜索结果页、无意义的会话参数。对于仍在观察期的目录，用 noindex 或页面内的规范链接处理，往往比直接屏蔽更可控——屏蔽会让蜘蛛彻底看不到内容，连纠错的机会都没有。

把 robots.txt 当成一次性的配置文件，是抓取问题反复出现的常见原因。它更像一份需要随站点结构同步更新的约定，改版、迁移、目录调整之后都应该重新核对一遍。

规则本身并不复杂，难点在于它影响的是整条抓取路径的第一环。写完之后用少量代表性 URL 推演一遍，比事后从日志里倒查要省事得多。