404错误页面：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /83955a5977a8.html
📄
404错误页面：批量页面只有一部分被发现时怎样划分对照组
结论先说：当一批本应返回404的URL只有一部分被搜索引擎发现时，不要按“被发现”和“未被发现”直接分组对比，而应按URL进入发现路径的方式分层，再在每层内部做对照。因为被发现与否往往由外链、站点地图、站内链接等入口差异决定，直接分组会把入口差异误当成页面处理差异。一个会让这个结论失效的反例是：如果两组URL的入口结构完全一致、仅404响应头配置不同，那么按发现状态直接分组反而更接近真实对照。
先确认“被发现”指的是哪一层
“被发现”至少可以指三种情况：搜索引擎抓取过该URL、抓取后判定为404、以及该404状态被用于后续处理。三者不是一回事。批量页面只有一部分被发现，常见原因是未被发现的那部分没有任何内链、外链或站点地图入口，而另一部分恰好有。此时两组URL的差异在入口，不在404页面本身。
可操作的动作：从服务器日志或抓取记录中，把每个URL标记为“有站内入口”“有站点地图入口”“仅有外链”“无任何入口”四类。做完这一步，你会发现所谓“被发现组”和“未发现组”往往在入口类型上已经分开了。这个标记结果直接决定下一步能不能直接对比，还是必须先配对。
按入口来源分层，而不是按发现结果分层
正确做法是先按入口来源分层，再在层内划分对照组。例如：
- 第一层：有站内链接指向的404 URL。在这一层内，再随机选一半保持当前404页面，另一半改成返回410或自定义404内容，观察抓取频率变化。
- 第二层：仅通过站点地图提交的404 URL。这一层内同样做处理与不处理的对照，但要注意站点地图不保证收录，所以这一层的“被发现”本身就不稳定。
- 第三层：仅有外链的404 URL。这一层不适合与站内入口组直接比较，因为外链的抓取触发机制不同。
分层的依据是入口来源，不是URL数量。每层内再随机分配处理组和对照组，才能让“是否被发现”之外的变量尽量一致。如果某一层URL数量太少，就不要强行做统计对比，改为逐条记录变化。
一个会让上述划分失效的反例
假设你有一批URL，它们的站内入口、外链、站点地图提交方式完全一样，唯一区别是部分URL返回404时带了自定义页面内容，另一部分返回裸404。这种情况下，按入口来源分层反而会把本来可以直接对比的两组拆散。此时更合理的做法是直接按“自定义内容 vs 裸404”分组，因为入口差异已经被控制住了。
判断是否属于这个反例，只需要检查一件事：两组URL的入口来源分布是否一致。如果一致，直接按处理方式分组；如果不一致，先按入口来源分层。这个检查动作本身就会告诉你该用哪种划分方式。
划分后先验证，再决定下一步
划分完对照组后，不要立刻下结论。先做一次小范围验证：从每个层内各选少量URL，记录它们在固定时间窗口内的抓取次数和返回状态。如果处理组和对照组的抓取次数差异只出现在某一层，说明入口来源仍在起作用，需要继续在该层内配对，而不是跨层比较。
验证结果会影响下一步动作：如果分层后层内差异稳定，可以扩大样本继续观察；如果层内差异仍然混乱，说明还有未记录的入口变量，比如内部搜索页、旧版RSS或第三方聚合页，需要先把这些入口补进标记再重新划分。
常见误判与边界条件
不要把robots.txt的抓取限制当成索引移除手段。robots.txt只限制抓取，不保证已抓取的URL从索引中消失。也不要用站点地图提交量来推断收录量，站点地图不保证收录。HTTPS与404处理是否被发现没有直接因果关系，不必把HTTPS状态作为分组变量。
另外，不同搜索引擎对404和410的处理方式不同，支持情况须分别核查。如果你的批量页面涉及多个搜索引擎，划分对照组时应按搜索引擎分别记录，不要合并成一组。
下一步动作
先导出全部目标URL及其入口来源，按“站内入口、站点地图、外链、无入口”四类标记。然后在每一类内部随机划分处理组和对照组，记录固定时间窗口内的抓取次数和返回状态。如果某一类内部入口分布仍然不一致，继续拆分子层，直到层内入口结构基本一致再开始对比。这个动作的结果会直接告诉你：当前差异是来自404处理方式，还是来自URL被发现的路径本身。
