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

seo监测 - 怎样判断采集是否遗漏：用对账法定位缺失页面的可执行流程

判断采集是否遗漏，核心不是看总量涨跌，而是做一次可复核的“对账”：把同一时间窗口内的站内日志、站点地图与搜索结果报告放到一起比对，找出“有链接但没被抓”“被抓了但没进报告”“报告有但日志没有”三类缺口。只要三类缺口的名单能落到具体URL，遗漏就是可定位、可交付的，而不是靠感觉争论。

先约定对账口径，避免协作返工

多人协作时最大的返工来源是口径不一致。开始前必须写清三件事，并让参与者在同一份记录里确认。

• 时间窗口：统一到同一时区、同一自然日或同一小时段。日志按服务器时间，报告按平台时区，两者不统一时先换算再比。
• URL 规范：是否带 www、是否带结尾斜杠、参数是否保留、大小写是否归一。建议统一转成小写并去掉跟踪参数后再比对，否则会把同一页面算成两条。
• 比对对象：站内可抓取链接集合（来自站点地图或内链爬取）、服务器访问日志中的抓取记录、搜索平台的已收录或已发现报告。三者分别代表“可被抓”“实际被抓”“被收录或被发现”。

口径写进交付文档后，后续任何结论都要能回溯到这份口径。口径变了，之前的名单作废重跑，不要在新旧口径之间做加减。

三类缺口的判断方法与证据

把三个集合做差集，就能得到缺口类型。每一类对应不同的原因方向，不要混在一起下结论。

缺口一：在站点地图或内链里，但日志中没有抓取记录

这通常指向“可发现性”或“抓取预算”问题，但也可能是日志本身不完整。判断步骤：

1. 从站点地图和内链爬取结果中导出全部URL，去重归一。
2. 在日志中按同一时间窗口检索这些URL，标记有记录和无记录。
3. 对无记录的URL，检查是否被 robots.txt 屏蔽、是否返回过 5xx、是否位于需要登录或交互才能到达的位置。
4. 如果日志只覆盖了部分节点或经过采样，先确认日志完整性，再下“没被抓”的结论。

验收信号：能列出具体URL清单，并说明每一条是被屏蔽、不可达，还是仅缺少入口链接。只有清单落到URL级别，才算定位完成。

缺口二：日志中有抓取，但报告里没有

这说明抓取发生过，但结果没有被纳入报告，可能原因包括返回状态码非 200、内容被判为重复、页面被规范标签指向别处，或报告本身有延迟。判断时先看日志中的状态码，再看页面上的规范标签与 meta robots。如果日志显示 200 且无屏蔽，但报告长期缺失，则更可能是内容质量或重复问题，而不是采集遗漏。

注意：搜索引擎报告与站内统计口径不同，报告缺失不等于用户访问为零，也不等于算法判定，只能作为“未被纳入该报告”的证据。

缺口三：报告中有，但日志里找不到

这类缺口常被忽略，却最容易造成误判。可能是日志时间窗口没对齐、日志未记录该来源、或报告中的URL经过改写。处理方式是把报告URL按同一规范转换后重新检索，并确认日志是否覆盖了全部入口。若仍找不到，应记录为“口径待确认”，而不是直接判定为遗漏。

可执行的验收清单

交付前逐项核对，每项都要有对应文件或截图作为证据：

• 时间窗口、时区、URL 规范已写入文档并由协作方确认。
• 三个集合的导出文件齐全，且能说明各自来源与导出时间。
• 三类缺口均有URL清单，每条附状态码或屏蔽原因。
• 对“可能原因”和“已定位原因”分开标注，未验证的写为待查。
• 结论只描述本次对账窗口内的事实，不外推到整体收录或排名。

假设某次对账发现 40 条URL在站点地图中但日志无记录，其中 12 条被 robots.txt 屏蔽、8 条返回 5xx、其余 20 条无入口链接。此时可交付的结论是：屏蔽与错误需先修复，剩余部分需补内链；而不是笼统地说“采集遗漏严重”。

下一步

选定最近一个完整时间窗口，按上述口径跑一次三集合差集，把缺口清单交给负责修复的人，并在下一次对账时复用同一份口径，确认缺口是否收敛。