404页面，批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /37512b560de6.html
📄
404页面，批量页面只有一部分被发现时怎样划分对照组
先给出结论：不要按“页面是否被收录”分组，而要按“页面在发现问题前是否已具备独立入口”分组，再在每组内对比状态码、内链深度和提交记录。这样划分才能把“抓取没发现”和“发现后判定为404”分开。假设你手上有800个返回404的URL，其中约200个在搜索控制台有展示记录，另外600个完全没有。直觉会认为“有展示=已被发现，无展示=未被发现”，但展示记录只说明曾经有用户看到过结果，不说明爬虫近期重新访问过。更可靠的对照组划分依据是：这些URL是否出现在站内链接、站点地图或历史重定向链中。
为什么按“是否被收录”分组会得出错误结论
“被收录”是一个滞后且不稳定的状态。一个URL可能昨天还在结果页，今天已经消失，但搜索控制台仍保留旧数据；另一个URL可能从未被收录，却因为外链被爬虫访问过多次。如果把这两类混在同一组，你会看到组内状态码分布混乱，进而误判问题出在服务器而不是入口。更麻烦的是，当批量404页面中只有一部分被发现时，常见解释有三种：入口不足导致爬虫没走到、服务器对部分路径返回了不一致的响应、以及robots.txt或站点地图把爬虫引向了错误位置。按收录状态分组无法区分这三者。
可执行的对照组划分方法
把手上这批404 URL先整理成一张表，至少包含四列：URL、发现问题前是否在站内被链接、是否出现在站点地图、最近一次已知的抓取或访问记录。然后按下面顺序分三组，不要跳步。
- 对照组A：有站内链接且有站点地图记录。这组如果仍未被发现，优先怀疑抓取预算或路径被阻断，而不是页面本身。
- 对照组B：无站内链接但站点地图中有记录。这组用于检验站点地图是否被有效读取。注意，站点地图不保证收录，它只提供发现线索。
- 对照组C：既无站内链接也无站点地图记录。这组属于孤立URL，通常只能靠外链或历史日志被发现，不适合用来判断服务器响应是否正确。
划分完成后，对每组各抽10到20个URL，用同一台机器、同一User-Agent请求一次，记录状态码和响应头。动作很简单：把请求结果与分组标签并排写在一张纸上。如果A组大量返回404而C组返回200，说明问题在入口配置而不是页面删除；如果三组状态码一致，下一步才去检查服务器日志中的抓取频率。
一个注明假设的短例子
假设某站点有500个失效商品页，其中120个仍在分类页有链接，380个只在旧版站点地图里。按上面方法分两组后，对每组各请求15个URL。结果：有链接组中14个返回404，站点地图组中9个返回404、6个返回200但内容为空。这个差异说明站点地图组里混入了未被正确处理的软404。下一步不是继续扩大抽样，而是先修正那6个返回200的空页面，再重新请求同一批URL确认状态码是否统一。这个例子中的数字只用于说明分组比较的方法，不代表任何真实站点数据。
哪些证据能区分“没被发现”和“被发现后判为404”
最直接的区分证据是服务器访问日志中的请求方法和响应码组合。如果某个URL在日志中从未出现，它属于未被发现；如果出现过且返回404，它属于被发现后判为404。两者处理方向不同：前者要补入口，后者要确认删除是否有意。robots.txt的抓取限制不等于可靠的索引移除，它只阻止抓取，不保证已有结果消失；同样，把URL提交到站点地图也不保证被收录。因此不要用“已提交”当作“已发现”的证据。
另一个可核对的证据是内链深度。从首页出发，点击不超过三次就能到达的URL，如果仍未被发现，更可能是服务器响应或抓取规则问题；点击超过五次的URL未被发现，则更可能是入口不足。这个判断需要你实际点击一遍，而不是凭感觉估计。
划分对照组后怎样决定下一步
如果A组（有链接有站点地图）未被发现的比例明显高于B组，优先检查全站导航和分类页是否被noindex或robots.txt误伤。如果B组问题更集中，先核对站点地图中的URL是否与线上实际路径一致，注意站点地图不保证收录，它只解决发现问题。如果C组占比最大，说明这批404页面本来就是孤立页面，继续追查抓取记录意义有限，应转向确认这些URL是否还有外链价值，再决定保留410还是设置重定向。
最后提醒一点：请求量或抓取量归零不能单独证明你的分组处理正确，它也可能是服务器临时不可用、日志轮转或爬虫调整频率造成的。把分组结果与至少两个独立证据（日志中的状态码、实际请求返回的响应头）对照后，再进入下一轮处理。这样划分对照组，才能让批量404页面中“只有一部分被发现”这个现象落到可验证的原因上，而不是停留在猜测。
