收录检查工具，日志中应该核对哪些字段：从抓取到索引的核对清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0db0c95f705c.html
📄
收录检查工具，日志中应该核对哪些字段：从抓取到索引的核对清单
用收录检查工具分析服务器日志时，最该优先核对的是能回答“谁来过、看了什么、结果如何”的字段：请求时间、客户端 IP、User-Agent、请求方法、完整 URL、HTTP 状态码、响应大小、Referer，以及响应时间。它们组合起来才能判断一个 URL 是被正常抓取、被拒绝、被重定向，还是根本没被访问过。单看某一列，结论往往不成立。
先明确交付结果，再决定字段优先级
日志核对的目标不是把字段全部导出，而是产出一份可验收的结论：哪些 URL 已被抓取、哪些被抓取但未收录、哪些从未被抓取、哪些抓取被拦截。围绕这个结果，字段可以分三层使用。
- 身份层：IP 与 User-Agent，用来区分搜索引擎爬虫、普通用户和其他机器人。
- 行为层：请求方法、完整 URL、状态码、响应大小、响应时间，用来判断抓取是否成功、是否浪费。
- 来源层：Referer 与请求时间，用来判断入口页面、抓取频率和时段规律。
如果日志格式允许，还应保留协议版本和主机名。多域名或同时存在 HTTP 与 HTTPS 时，缺少主机名会让 URL 归属判断出错。
每个字段具体核对什么
User-Agent：不要只按包含某个爬虫名称的字符串判断。先确认该 UA 对应的 IP 是否属于搜索引擎官方公布的网段，再判断抓取身份。UA 可以伪造，单看 UA 会误判。
请求方法与完整 URL：核对是否出现带参数的重复 URL、大小写不同的路径、带或不带结尾斜杠的版本。这些变体如果都返回 200，可能造成重复抓取；如果返回 301，要确认跳转目标是否唯一。
HTTP 状态码：这是核对重点。常见判断如下：
- 200：抓取成功，但不代表已收录，还要看页面内容与质量。
- 301/302：确认跳转链是否过长、是否跳到无关页面。
- 304：内容未变，属于正常协商缓存，不必当成错误。
- 403/401：抓取被拒绝，需要检查服务器规则或访问控制。
- 404/410：确认是真实失效还是配置错误导致的误报。
- 429/503：抓取被限流或服务不可用，需要结合响应时间判断。
响应大小与响应时间：响应大小为 0 或极小，通常说明返回的是空内容或错误页。响应时间持续偏高，可能让爬虫降低抓取频率，但这不是唯一原因，需要与服务器负载、页面体积一起看。
Referer：可以辅助判断爬虫是从站点地图、内链还是外链进入。Referer 缺失不代表没有来源，很多请求本身不携带该字段。
用一份可执行清单做核对
假设某页面在收录检查工具中显示“未收录”，日志核对可以按以下步骤执行。以下为假设示例，不是真实项目结论。
- 按完整 URL 过滤日志，统计该 URL 在选定时间段内的请求次数。
- 提取对应的 User-Agent 与 IP，确认是否来自目标搜索引擎的官方网段。
- 查看状态码分布：若全是 404，检查 URL 是否写错或页面已删除；若全是 403，检查是否误拦爬虫。
- 查看响应大小：若长期为 0，检查服务端是否返回空响应。
- 查看是否只有 304：说明爬虫来过且内容未变，问题更可能在内容质量或索引选择，而不是抓取失败。
- 若日志中完全没有该 URL，说明尚未被抓取，应检查内链、站点地图和 robots.txt 是否放行。
验收标准可以设为：每个待查 URL 都能归入“已成功抓取”“被抓取但被拒绝”“被抓取但状态异常”“从未被抓取”四类之一，并附上对应日志行作为依据。
容易误判的边界
robots.txt 的抓取限制不等于可靠的索引移除。被 robots.txt 禁止抓取的 URL 仍可能因外链等原因出现在搜索结果中，只是摘要信息可能受限。站点地图不保证收录，它只提供发现入口。HTTPS 也不保证安全无漏洞或排名提升，它只解决传输加密问题。不同搜索引擎对日志字段、抓取行为和索引规则的支持情况不同，需要分别核查，不能把一家爬虫的日志结论直接套用到另一家。
下一步建议：先固定一个日志时间窗口，把目标 URL 按上述四类归档，再针对“被抓取但状态异常”和“从未被抓取”两类分别处理服务器配置与内链入口，处理后再用同一套字段复查一次。
