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

SEO监控怎样判断采集是否遗漏：用交付验收倒推检查项

判断采集是否遗漏，不能只看报表里有没有数字，而要看“应采范围”和“实采结果”能否逐项对上。准备交接或验收时，最直接的做法是：要求对方交付一份可复核的采集清单，清单里至少包含目标范围、采集字段、时间粒度、任务记录和异常处理结果；你随机抽取若干条，回到原始页面或原始日志核对，对不上且无法解释的，就属于遗漏。

先明确应采范围，否则无法判断遗漏

遗漏是相对“应采集合”而言的。没有应采范围，任何数量都只能说多或少，不能说漏没漏。验收前先确认三件事：

• 对象范围：要监控的是整站、指定目录、指定栏目，还是某批关键词对应的结果页。范围边界要写成可执行的规则，例如“包含 /news/ 下全部文章页，不含标签聚合页”。
• 字段范围：每条记录要采哪些字段，例如标题、URL、发布时间、收录状态、排名位置、抓取时间。字段缺失和记录缺失是两类问题，要分开查。
• 时间范围：从哪天到哪天、每天几次、每次覆盖多少。日报缺一天和当天少采几条，处理方式不同。

如果对方只给一个总量，你可以要求把范围拆成可枚举的单元，比如按栏目、按日期、按批次列出应采数量，再逐项对照实采数量。这一步是把“感觉漏了”变成“哪一批、哪一类漏了”。

用证据链核对，而不是只看汇总报表

汇总数字最容易掩盖遗漏。判断时要看三层证据能否串起来：

1. 任务层：每次采集是否有任务记录，包括开始时间、结束时间、目标范围、成功与失败条数。没有任务记录，就无法区分“没采”和“采了但没入库”。
2. 记录层：抽取若干应采对象，检查是否在结果中出现。抽查要覆盖不同栏目、不同时间段和边界对象，例如最新一篇、最旧一篇、分页最后一页。
3. 原始层：对抽查不到的记录，回到原始页面或原始日志确认它当时是否存在、是否可访问。原始层不存在，属于范围判断问题；原始层存在但结果没有，才更接近采集遗漏。

这里要区分“可能原因”和“已经定位的原因”。某条记录没出现，可能是页面当时不可访问、被规则排除、解析失败、入库失败或去重误删，不能凭一个现象就断定是采集程序漏抓。只有把任务记录、原始页面和入库结果三方对齐，才能给出确定结论。

验收时可以直接执行的抽查步骤

下面这套步骤适合交接或验收现场使用，不需要对方额外开发功能：

• 让对方导出应采清单和实采清单，两者都带唯一标识，例如 URL 或对象 ID。
• 用表格做一次差集：应采有、实采没有的部分，就是候选遗漏集合。
• 从候选遗漏里随机抽 20 到 30 条，逐条回到原始来源确认。假设某条文章页在采集当天可以正常打开，但实采清单里没有，且任务记录显示该批次成功，那么这条就应记为遗漏并追问原因。
• 对确认遗漏的记录，要求给出分类：范围外、当时不可访问、解析失败、入库失败、去重误删、其他。分类说不清，说明过程不可复核。
• 检查边界样本：每个栏目的第一篇和最后一篇、每天最后一次采集、分页最后一页。遗漏往往集中在边界，而不是中间。

抽查比例没有统一标准，取决于总量和风险。量小可以全查；量大时至少覆盖每个栏目、每个时间段和每类页面模板。判断结果的标准是：候选遗漏能被逐条解释，且解释能回到任务记录或原始来源验证。解释不了的比例偏高，就不能通过验收。

交接资料里必须写清责任和口径

采集是否遗漏，最终要落到“谁负责、按什么口径、多久内修正”。交接文档里建议明确：

• 采集范围的维护责任：范围变更由谁提出、谁确认、多久生效。
• 异常处理责任：发现遗漏后由谁排查、多久给结论、修正后如何补采。
• 口径说明：第三方估算流量、搜索引擎自己给出的报告、站内统计三者口径不同，不能互相替代。验收采集完整性时，应以任务记录和原始来源为准，而不是拿某个流量数字反推。
• 补采规则：确认遗漏后，是补历史数据还是只保证后续不再漏，要写清楚。

如果对方只承诺“以后注意”，没有补采和复核机制，这次遗漏在下次交接时还会以同样方式出现。

下一步怎么做

现在就向对方要两份东西：一份带唯一标识的应采清单，一份对应的实采清单，然后按上面的差集和抽查步骤跑一遍。跑完把无法解释的条目单独列出，作为验收不通过或需要补采的依据。