robots.txt：批量页面只有一部分被发现时怎样划分对照组，先确认分歧属于哪一类事实
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3955fad27274.html
📄
robots.txt：批量页面只有一部分被发现时怎样划分对照组，先确认分歧属于哪一类事实
先把“被发现”拆成两个可核对的事实：服务器是否收到过对目标路径的抓取请求，以及已抓取的URL是否进入过索引候选。批量页面只出现一部分时，不要急着改robots.txt，而应把页面按路径、模板、内链位置和抓取记录分成可比较的组，让每组只改变一个变量。对照组的目的不是证明谁对谁错，而是把“我以为被屏蔽了”和“日志显示确实抓过”这两种理解放到同一张核对表上。
先确认分歧属于哪一类事实
多个角色对同一批页面有不同理解，通常来自三种事实混在一起：规则层的事实是robots.txt是否允许抓取某路径；行为层的事实是抓取日志里有没有对应请求；结果层的事实是这些URL是否出现在索引或站点地图报告中。三者不能互相替代。robots.txt禁止抓取，只约束合规爬虫的请求行为，不等于页面会从索引中移除；站点地图提交也不保证收录。因此划分对照组前，先让每个人写下自己依据的是哪一层证据，再决定保留、改写还是退出当前判断。
按路径和模板切出最小对照组
批量页面里“只有一部分被发现”，最有效的切法不是随机抽样，而是按会改变抓取行为的结构切分。可以按以下顺序建立两组：
- 路径组：把同一目录下被发现和未发现的URL分别列出，检查robots.txt中是否有更长前缀的Disallow规则只覆盖了其中一部分。
- 模板组：同一套模板生成的页面，若参数、分页或筛选条件不同，抓取优先级可能不同；把带参数和不带参数的URL分开。
- 内链组：从首页或栏目页到目标页的点击深度不同，先比较被发现组和未发现组的入链来源数量与层级。
- 时间组：按发布时间或最后修改时间排序，观察未发现页面是否集中在某个时间段，避免把时间相关直接当成原因。
每组至少保留一个“已发现”的对照页面，否则无法判断差异来自规则还是来自页面本身。假设某目录下100个页面只有前20个被发现，先不要改规则；把前20个和后80个分别记录抓取日志中的请求次数、首次请求日期和来源URL。如果后80个从未出现任何请求，问题更可能在发现路径；如果出现过请求但未进入索引候选，则要转向内容与重复问题。这个假设只用于说明比较方法，不代表真实项目结果。
保留、改写还是退出：三种取舍的适用前提
保留当前robots.txt规则，适用于日志证明未发现页面本来就被规则允许、且抓取请求已经发生过的情况。此时继续改规则不会增加新信息，下一步应转向内链和站点地图核对。
改写规则，适用于对照组显示未发现页面恰好落在某条Disallow或Allow冲突之下，并且已发现页面不在该规则覆盖范围内。改写时只调整与对照组差异对应的那一行，改完后用同一组URL重新核对日志，而不是立刻扩大到全站。
退出当前判断，适用于两种证据互相矛盾：例如规则显示允许，但日志长期没有任何请求，同时站点地图也没有被读取的迹象。此时应退出“robots.txt导致未发现”的结论，改查服务器响应、内链可达性和站点地图本身的有效性。退出不是放弃，而是把排查对象换到下一层。
用一个可核对的动作收束分歧
把分歧转成项目，最实际的动作是建立一张对照表：每行一个URL，列包括所属路径组、模板类型、robots.txt判定结果、日志中是否有请求、首次请求日期、是否在站点地图中、当前索引状态。填完后先看“规则允许但无请求”和“规则禁止但有请求”这两类异常行。前者指向发现路径，后者说明限制抓取与索引移除不是一回事，需要分别核查。完成这一步后，下一步只选一类异常行做小范围修改，并保留修改前的记录，以便判断变化是否与修改同时出现，而不是把时间上的巧合当成因果。
