404状态码：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ec987f5ea7e3.html
📄
404状态码：批量页面只有一部分被发现时怎样划分对照组
先给结论：不要按“已发现/未发现”直接分组，而要先按页面是否返回真正的404状态码、是否被站内链接指向、是否在站点地图中列出，把页面切成可解释的层，再在层内做对照。这样做的原因是，发现与否往往同时受链接、站点地图和响应状态影响，直接分组会把原因混在一起，后面无论怎么比较都说不清。
先看矛盾：同一批页面，为什么只有一部分被发现
假设一个站点批量上线了若干页面，其中一部分被正常抓取，另一部分迟迟没有出现。团队里常见两种解释：一种认为未被发现的那批页面本身有问题，比如返回了404状态码；另一种认为页面没问题，只是缺少入口，抓取工具没有理由走到它们。两种解释都成立，但指向的动作完全不同。前者要修状态码，后者要补链接或调整站点地图。如果只统计“发现比例”，无法区分这两种情况，因为两者的表现都是“没被发现”。
这里要先澄清一个事实：站点地图不保证收录，列在里面的页面仍可能不被抓取；robots.txt 里的抓取限制也不等于可靠的索引移除，它只约束抓取行为，不决定页面是否出现在结果中。所以判断分组时，不能把“已提交站点地图”当成“已被发现”的同义词。
把分歧变成可核对的对照维度
要区分上面两种解释，需要三个独立可查的维度，每个维度都能单独核对，不依赖团队成员的记忆或口头判断。
- 响应状态：用抓取工具或命令行请求页面，记录返回的状态码。返回404状态码的页面和返回200的页面必须分开，不能混在一组里比较。
- 站内入口：检查页面是否被其他已抓取页面链接指向。有入口和没有入口，是两种不同的被发现条件。
- 站点地图覆盖：记录页面是否出现在站点地图中。注意这只是提交信号，不是发现证据。
把这三个维度交叉后，会得到若干层。真正有比较价值的是同一响应状态下、入口条件不同的两组，例如“都返回200、都有站内链接”与“都返回200、都没有站内链接”。如果两组被发现比例接近，说明入口不是主因；如果差距明显，入口就更可能是解释变量。
一个注明假设的短例子
假设某批页面共四组，每组条件如下（数字仅用于说明比较方法，不代表真实统计）：
- A组：返回200，有站内链接，在站点地图中。
- B组：返回200，无站内链接，在站点地图中。
- C组：返回404状态码，有站内链接，在站点地图中。
- D组：返回404状态码，无站内链接，不在站点地图中。
如果发现主要集中在A组，B组很少，那么入口比站点地图更能解释差异。此时下一步动作是给B组补站内链接，而不是去改站点地图。如果C组同样很少被发现，而A组正常，那么404状态码本身就是一个需要单独处理的变量，应该先把C组修成正常返回，再重新观察。D组因为多个条件同时不同，不适合作为对照，只能作为待修复清单。
这个例子的关键不是数字，而是动作顺序：先固定响应状态，再比较入口；如果入口解释不了，再回头看状态码。每次只改一个条件，改完后重新核对同一组页面的发现情况，才能知道是哪个条件在起作用。
核对时容易踩的两个坑
第一个坑是用抓取量或请求量的变化直接下结论。某个时间段请求量下降，可能是抓取预算调整、服务器响应变慢、站点结构变化，甚至只是抓取工具的正常波动。请求量归零不能单独证明某个处理正确，需要结合响应状态和入口条件一起看。
第二个坑是把不同搜索引擎的结果混在一起。不同搜索引擎对站点地图、404状态码和链接信号的支持与处理方式并不一致，必须分别核查。如果只看一个来源的数据就推广到全部渠道，对照组的结论会不可靠。
实际操作建议：先导出这批页面的完整清单，逐条标注响应状态、是否有站内入口、是否在站点地图中，然后按“响应状态相同、入口条件不同”的原则分成两组，只对比这两组的发现情况。得到差异后，先改一个条件并重新核对，再决定下一步是补链接、修状态码，还是调整站点地图。这样每一步都有可复查的依据，而不是靠猜。
