关键字分析 - 用短横线副题判断采集是否遗漏
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0fe3b1bdb6dc.html
📄
关键字分析 - 用短横线副题判断采集是否遗漏
判断采集是否遗漏，核心不是看总量，而是看“应采集合集”与“实际采集合集”的差集。做法是：先根据站内链接、sitemap、分页和筛选规则列出理论上应该被采集的URL清单，再与采集日志或数据库中的URL清单做比对，差集部分就是遗漏候选。只看采集总数增长，无法证明没有遗漏。
先定义“应该采集”的范围
遗漏是相对目标范围而言的。没有范围，就无法判断遗漏。建议先固定三类来源：
- 站内导航与正文中出现的链接，包括分页、标签页、地区切换等入口。
- sitemap或站点地图文件中声明的URL。
- 数据库或后台中已发布、状态为正常的记录。
把这三类合并去重，得到应采集合集。适用条件是：页面状态明确、链接可抓取、没有登录或验证码拦截。如果目标页面本身需要登录，采集遗漏的判断要改为在登录态下导出链接清单。
用差集定位遗漏，而不是用总量估算
假设某项目后台有1200条已发布记录，sitemap声明1180条，采集库中有1150条。不能直接说遗漏50条，因为三个集合口径不同。正确做法是：以“已发布且可公开访问”的记录为主键，逐条在采集库中查找。查不到的主键，才是遗漏候选。
可执行的比对步骤：
- 从后台导出已发布记录的URL或唯一ID，保存为清单A。
- 从采集库导出已采集URL或唯一ID，保存为清单B。
- 用表格工具或脚本做差集，得到A减B的结果。
- 对差集中的每条URL，手动访问一次，确认是404、跳转、拦截，还是确实未采集。
判断结果：如果手动访问正常且内容存在，但采集库中没有，属于真实遗漏；如果手动访问返回404或跳转，属于清单本身过期，不是采集遗漏。
分页、筛选和动态加载是最常见的遗漏来源
列表页只采集第一页、筛选条件生成的URL未被发现、滚动加载的内容未触发，都会造成遗漏。检查时不要只看列表页总数，要检查：
- 分页链接是否被完整跟踪，最后一页是否可达。
- 筛选参数组合是否被纳入采集范围，还是只采集了默认排序。
- 动态加载内容是否需要额外请求接口，采集器是否执行了脚本。
适用条件：这类遗漏通常出现在列表型、电商型或内容聚合型页面。判断方法是对比“页面实际可见条目数”和“采集库中来自该列表的条目数”。如果页面显示200条，采集库只新增80条，且手动翻页能看到剩余条目，则遗漏可能来自分页或加载方式。
用日志和状态码区分“没采到”与“采了但没入库”
采集遗漏不一定发生在抓取阶段。可能已经请求成功，但解析失败、字段映射错误或入库去重规则过严，导致数据没有进入最终库。排查时按证据链走：
- 查采集日志中该URL是否有请求记录。
- 有请求记录，查返回状态码和响应体长度。
- 响应正常，查解析规则是否匹配当前页面结构。
- 解析有结果，查入库去重或过滤条件是否将其排除。
判断结果：日志无请求，属于发现阶段遗漏；有请求但状态码异常，属于抓取阶段失败；响应正常但无解析结果，属于解析阶段遗漏；解析有结果但库中无记录，属于入库阶段遗漏。不同阶段对应不同修复动作，不要混为一谈。
选择修复顺序：先补高价值遗漏，再改采集规则
发现遗漏后，不必一次性重采全部。按影响面排序：先补被其他页面链接引用最多、或属于核心分类的URL；再补分页和筛选产生的长尾URL。代价是，前者需要人工确认优先级，后者更适合用规则批量重跑。
下一步：从后台导出最近一批已发布记录的URL，与采集库做一次差集比对，把差集中的URL逐条手动访问，记录状态码和页面是否存在。这份记录就是后续修复采集规则的依据。
