robots txt：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1f1f5a379901.html
📄
robots txt：批量页面只有一部分被发现时怎样划分对照组
先给结论：当一批同构页面的抓取或收录表现不一致时，不要按“已发现”和“未发现”直接分组，而要先按 robots.txt 的生效边界分组——即把“确实被规则放行、且路径结构一致”的页面放在同一组，再在这组内部比较已发现与未发现。否则你比较的可能是两组规则环境不同的页面，结论无法迁移到下一步。
两种做法的取舍：按结果分组，还是按规则环境分组
最常见的直觉做法是按结果分组：把已发现的页面当实验组，未发现的当对照组，然后找两组差异。这在同构批量页面里往往失效，因为未发现的那部分很可能恰好落在某条 Disallow 覆盖的目录、带参数的路径或被通配符命中的命名模式上。此时两组之间的差异不是“内容质量”或“内链多少”，而是规则是否放行。
另一种做法是先按 robots.txt 的规则环境分组：把受同一组 Allow / Disallow 规则约束、URL 形态接近的页面归为一层，再在层内比较发现情况。代价是需要先核对规则与 URL 的匹配关系，前期多花时间；收益是层内比较的变量更少，得出的差异更可能指向真正的原因。
选择条件可以这样定：如果未发现的页面在 URL 路径上呈现明显的目录聚集或参数聚集，优先按规则环境分组；如果未发现页面在路径上均匀散落、与已发现页面混在同一目录且命名模式一致，那么按结果分组、再回查规则是否真的放行了这些 URL，通常更快。
先确认 robots.txt 到底放行了哪些 URL
分组之前要拿到一个明确的事实：这批页面各自的 URL，是否被当前 robots.txt 允许抓取。注意 robots.txt 的抓取限制不等于可靠的索引移除，反过来，被放行也不意味着一定会被抓取或收录。所以这一步只回答“是否被规则挡住”，不回答“为什么没被发现”。
实际操作上，把批量页面的 URL 列表提取出来，逐条与规则做匹配，重点看三件事：
- 路径前缀是否落在某条 Disallow 之下，包括看似无关的上级目录。
- 是否被通配符或结尾符号命中，例如规则里的
*与$改变了匹配范围。 - 规则中是否对特定爬虫单独声明，导致同一 URL 对不同爬虫结果不同。
做完这一步，把 URL 分成三类：明确被挡、明确放行、匹配存在歧义。第三类不要急着归入任何一组，先单独列出，因为歧义本身可能就是发现率不一致的原因之一。这个动作的结果会直接决定下一步：如果大量未发现页面落在“明确被挡”，那问题在规则而非内容，先改规则再谈分组；如果未发现页面几乎都在“明确放行”里，才值得进入层内比较。
在放行层内建立可比较的对照组
确认一批 URL 都被放行后，再划分对照组。可用的分层维度包括：目录层级、URL 命名模式、是否带查询参数、模板是否相同。目标是让组与组之间只差一个你关心的变量，例如“有无站内链接指向”“是否在站点地图中列出”。站点地图不保证收录，所以它可以作为一个比较变量，但不能当作收录的保证或因果证据。
一个假设的例子：某批商品页共 2000 条 URL，全部被 robots.txt 放行。其中 600 条被发现，1400 条未发现。若直接比较这两组，会混入目录、参数、模板等多种差异。改为按目录分层后，假设发现 A 目录发现率明显高于 B 目录，而两个目录的模板与链接结构接近，那么差异更可能来自目录级的链接或规则细节，而不是单页内容。这个例子的数字仅用于说明分组方法，不代表任何真实站点表现。
划分时要保留一个“同规则、同形态”的基准组，作为后续任何改动的对照。没有基准组，改动后的变化无法归因。
例外与边界：这些情况不能照上面的分组走
有几种情况需要单独处理，不要硬套层内比较：
- URL 匹配存在歧义时，先消除歧义，否则分组本身不可靠。
- 不同爬虫对同一规则的解读可能不同，跨爬虫比较前要分别核查各自的支持情况。
- 页面被放行但长期未发现，可能来自抓取预算、链接深度、站点地图提交或内容重复等多种原因，不能只归因于 robots.txt。
- 请求量或抓取量突然归零，不能单独证明是规则处理正确；也可能是抓取调度、服务端响应或外部因素变化，需要结合其他证据判断。
还有一个方向性提醒：robots.txt 只控制抓取，不控制索引。若目标是让页面从索引中消失，仅靠 Disallow 并不可靠，需要配合其他手段。分组分析解决的是“为什么一部分被发现、一部分没有”，不要把它当成索引管理的替代方案。
从分组到下一步动作
完成分组后，选一个层内差异最清晰、改动成本最低的变量先动，例如给未发现组补上站内链接或在站点地图中列出，然后观察该组相对基准组的变化。若变化出现在预期方向，说明该变量值得扩大到其他层；若没有变化，说明该层内还有未识别的差异，回到规则匹配和 URL 形态重新检查。每一步动作都要留下基准组，否则无法区分是改动生效还是外部波动。
把分组依据、匹配结果和改动记录写清楚，下一次遇到批量页面发现率不一致时，可以直接复用同一套分层逻辑，而不必从零猜测原因。
