天津网站诊断：怎样判断采集是否遗漏 - 用对照清单确认抓取缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /72c43b0a4ad3.html
📄
天津网站诊断：怎样判断采集是否遗漏 - 用对照清单确认抓取缺口
判断采集是否遗漏，不能只看“收录量少了”或“日志里抓取次数下降”，而要建立一条可复核的证据链：把网站自己声明的URL集合，与搜索引擎实际抓取、实际建立索引的URL集合逐项对照。三者不一致的部分，才是遗漏的候选范围。对多人协作的天津网站诊断项目来说，先固定对照口径，再分工核查，能避免各人拿不同数据源得出互相矛盾的结论。
先分清三种“遗漏”，否则会误判
最常见的误解是：站内统计显示有大量页面未被索引，就断定采集被遗漏。实际上至少存在三种不同情况。
- 未被发现：搜索引擎还不知道这个URL存在，日志里从未出现该地址的抓取记录。
- 已发现未抓取：URL进入了待抓队列，但日志中没有对应的抓取请求，可能受抓取配额、优先级或站点响应速度影响。
- 已抓取未索引：日志里能看到抓取记录，但索引中没有该页面，这属于索引筛选问题，不是采集遗漏。
把这三类混在一起谈，就会把索引问题当成抓取问题处理，返工往往由此产生。正确的做法是先按日志有无抓取记录做第一层切分，再判断是否属于采集环节。
建立URL对照表是判断遗漏的基础动作
多人协作时，建议用同一份表格作为唯一依据，字段至少包含：URL、页面类型、是否在站内地图中、日志中是否出现抓取、抓取返回状态码、是否在索引中、核查人、核查日期。具体步骤如下：
- 从站点地图、栏目列表和重要内链中导出全部希望被采集的URL，去重后作为基准集合。
- 从服务器访问日志中筛选出搜索引擎爬虫的请求记录，提取被请求的URL。
- 用基准集合减去日志中出现的URL，得到“从未被抓取”的候选清单。
- 对候选清单逐条检查：是否有内链指向、是否被robots规则拦截、是否返回异常状态码、是否在站点地图中正确声明。
这个减法结果才是采集遗漏的直接证据。只凭索引数量倒推，无法区分是没抓还是抓了没收录。
用可核对的检查项定位遗漏原因
对“从未被抓取”的URL，按以下顺序排查，每项都要留下可复查的记录：
- 入口可达性：该页面是否能通过站内链接从首页沿正常路径到达。孤立页面即使写在站点地图里，被发现概率也偏低。
- robots规则：检查robots文件与页面级meta指令，确认没有误拦截爬虫或误设禁止索引。
- 状态码：确认页面返回的是正常内容状态，而不是跳转链、错误页或空内容。
- 站点地图准确性：地图中声明的URL必须与实际可访问地址完全一致，包括协议、大小写和结尾斜杠。
- 抓取压力：如果日志显示爬虫频繁遇到超时或服务端错误，抓取配额会被消耗在无效请求上，正常页面被推迟。
这里要注意：同一现象可能有多个解释。例如某页面未被抓取，可能是没有内链，也可能是robots拦截，还可能是服务器响应过慢。在证据不足时，只能列为“可能原因”，不能写成“已经定位的原因”。
区分采集遗漏与索引筛选，避免错误归因
如果日志中确实出现了抓取记录，但索引中查不到该页面，问题就不在采集环节。此时应转向内容质量、重复度、页面价值等方向核查。把这类页面计入“采集遗漏”会造成两个后果：一是团队把精力花在提交和推送，二是真正的索引问题被长期忽略。
判断口径可以简化为一句：日志无记录，才优先怀疑采集；日志有记录，优先怀疑索引。这条规则适用于大多数常规内容页，但对需要登录、依赖脚本渲染或返回动态内容的页面，需要单独确认爬虫实际获取到的内容版本。
多人协作时的交付与复核建议
要让结论可交付、减少返工，建议固定三件事：统一URL基准表的导出时间、统一日志的时间范围、统一索引查询的入口和日期。每次诊断输出一份对照表加一份原因归类清单，标注每条结论对应的证据来源。复核人只需检查证据是否支持结论，而不必重新跑一遍全流程。对于天津网站诊断这类区域服务场景，如果涉及具体服务商或工具，只核对其公开说明与自身数据口径是否一致，不把第三方估算当作唯一依据。
下一步，可以先从站点地图和栏目页导出基准URL，与最近一段时间的爬虫日志做一次减法，把“从未被抓取”的清单列出来，再按上面的检查项逐条确认。这张清单本身就是后续分工和验收的起点。
