📍 WDQWDWQD987AAAAA:216.73.217.111
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /566d02c662cb.html
📄

seo分析，怎样判断采集是否遗漏

判断采集是否遗漏，核心不是看总抓取量，而是把“站内实际存在的可访问URL”与“采集记录中成功处理的URL”做集合比对，再对差集逐类核查。若差集里的URL能被正常访问、返回有效内容、没有被robots或登录限制挡住，却始终没有进入采集记录，才可认定为遗漏；否则更可能是重复、屏蔽或抓取失败，而不是漏采。

从一个假设例子看比对流程

假设某站点有1万个商品页，采集记录里只有9200个。先别下结论说漏了800个，因为其中一部分可能是筛选参数页、分页重复或已下架页面。正确做法是分三步。

1. 导出站内URL清单。优先从数据库、sitemap或栏目列表生成，确保每条URL都是真实存在且可访问的页面。
2. 导出采集记录中的URL清单。只保留“已成功获取正文”的记录，抓取失败、超时、被拦截的单独放一列。
3. 做差集。站内有、采集记录没有的URL，进入待核查队列；采集记录有、站内没有的URL，通常是历史页面或参数变体，不影响遗漏判断。

假设这800个差集URL中，有500个返回404，200个是带相同内容的分页参数，只有100个返回200且正文完整。那么真正需要处理的遗漏是100个，不是800个。这一步的意义在于把“数量差”还原为“内容差”。

核查遗漏时先排除三类假遗漏

很多看似遗漏的情况，其实是采集策略或站点状态造成的。逐项检查可以避免把时间花在无效URL上。

• 访问限制：用与采集相同的User-Agent和IP环境请求URL。如果返回403、429或跳转到验证页，说明不是遗漏，而是被拦截。此时应调整抓取频率或请求头，而不是补采。
• robots与meta限制：检查目标URL是否被robots.txt禁止，或页面是否有<meta name="robots" content="noindex">。被明确禁止收录的页面不应计入遗漏。
• 内容重复：如果差集URL与已采集URL正文相似度极高，只是排序或来源参数不同，通常属于重复页。判断标准是正文主体是否提供新信息，而不是URL字符串是否不同。

排除这三类后剩下的URL，才是真正需要补采或修复解析规则的对象。

用可核查的证据链定位原因

确认遗漏后，不要直接批量重抓，先判断遗漏发生在哪一层。常见原因有三层：发现层、抓取层、解析层。

• 发现层：URL没有出现在任何入口列表中。检查sitemap是否包含该URL、栏目分页是否翻到了最后一页、列表是否被JavaScript懒加载截断。判断方法是直接搜索站内链接，看该URL能否从首页通过不超过三次点击到达。
• 抓取层：URL已被发现，但请求失败或超时。查看采集日志中的状态码和响应时间。若大量URL集中在同一时间段失败，可能是并发过高或目标站点限流。
• 解析层：页面已成功抓取，但正文提取为空或字段缺失。此时对比原始HTML与解析结果，检查选择器是否匹配、内容是否在<script>或iframe中。

三层原因对应不同修复动作：发现层补入口，抓取层调频率，解析层改规则。把三者混在一起批量重抓，往往只是重复失败。

时间和人手有限时的处理顺序

如果只能安排一个人半天处理，建议按以下优先级执行。

1. 先跑一次全量差集，得到待核查URL列表，而不是凭感觉抽样。
2. 对待核查URL批量请求，记录状态码和正文长度，自动过滤404、403和空正文。
3. 对剩余URL按栏目分组，优先处理流量集中或转化路径上的栏目，例如商品详情、文章正文。
4. 只对确认可访问且内容唯一的URL执行补采，补采后再次比对，确认差集缩小。

判断修复是否有效的标准是：同一批URL在补采后进入成功记录，且正文长度与页面实际内容一致。如果补采后仍然缺失，说明问题不在采集次数，而在发现或解析环节，需要回到上一层检查。

下一步可以固定一个核对节奏：每次站点更新栏目或模板后，重新导出一次站内URL清单，与最近一次成功采集记录做差集，只处理新增的差集部分。这样比定期全量重抓更省时间，也更容易发现模板改版导致的批量遗漏。