网站不被收录原因：日志中应该核对哪些字段？
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7af9c899c29f.html
📄
网站不被收录原因：日志中应该核对哪些字段？
要判断网站不被收录原因，日志里最该核对的是搜索引擎爬虫的请求记录：先看它是否来过、抓了哪些URL、返回什么状态码、是否被robots.txt拦截，以及抓取频率和停留特征。日志不能直接证明“为什么不收录”，但能帮你排除“爬虫根本没来”“来了被挡”“抓到的都是错误页”这几类常见问题。
先分清两类日志：访问日志与抓取统计
服务器访问日志（如Nginx、Apache的access log）记录每一次HTTP请求，字段通常包括客户端IP、时间、请求方法、URL、状态码、响应大小和User-Agent。搜索引擎自己提供的抓取统计或抓取错误报告是另一套数据，两者不能互相替代。排查时以访问日志为基础，再用搜索平台的数据交叉验证。
需要先确认日志确实包含搜索引擎爬虫的记录。如果站点用了CDN或反向代理，源站日志可能只看到CDN节点IP，真实爬虫的User-Agent和IP未必完整保留。这种情况下应优先查看CDN侧的日志，而不是直接下结论说“爬虫没来”。
必须核对的字段清单
- User-Agent：识别是否为搜索引擎爬虫。注意UA可以伪造，不能只看UA就断定是官方爬虫，需要结合IP反查验证。
- 请求URL与路径：确认爬虫抓的是目标页面，而不是首页、标签页或大量参数URL。如果只抓首页不深入，说明内链或入口有问题。
- HTTP状态码：200表示正常返回；301/302是跳转；404是页面不存在；403是拒绝访问；429是请求过多被限流；5xx是服务器错误。大量非200会直接影响页面能否进入索引。
- 请求方法：GET通常是正常抓取，HEAD可能只是探测。异常的高频请求方法值得留意。
- 响应大小：返回200但响应体极小（例如接近空内容），可能是渲染失败或返回了空壳页面。
- 时间与频率：看抓取是集中在某几天还是长期稳定。突然停止抓取，可能与服务器波动、robots改动或站点结构变更有关。
- 来源IP：用于验证爬虫真伪，也用于判断是否被错误地限流或封禁。
- Referer（如有）：辅助判断爬虫是从哪个入口发现该URL的。
用状态码和robots记录缩小范围
把日志按状态码分组统计，是成本最低的排查动作。假设某栏目下100个URL中，80个返回200、15个返回404、5个返回403（此为假设示例，非真实项目数据），那么重点应先解决404和403，而不是反复提交站点地图。站点地图不保证收录，它只是提供发现入口。
同时检查robots.txt是否拦截了目标路径。日志中如果出现对robots.txt的请求，可以确认爬虫读取过规则；但robots.txt的抓取限制不等于可靠的索引移除——被robots禁止抓取的URL仍可能因外部链接出现在索引中，只是摘要内容受限。因此看到“被robots拦截”时，要判断这是有意为之还是误配置。
另外注意：HTTPS不保证安全无漏洞，也不保证排名。日志里如果全是HTTPS请求却仍不收录，问题不在协议本身，而应回到状态码、内容质量和入口结构上找。
判断与下一步：按条件决定先修什么
- 先按User-Agent筛出爬虫请求，确认爬虫是否到访。若从未到访，优先检查入口、外链和站点地图提交情况。
- 若已到访，按状态码统计。非200占比高，先修服务器错误、跳转链和404。
- 若状态码正常但只抓少量URL，检查内链深度、分页和参数是否造成抓取浪费。
- 若抓取正常、状态码正常仍不收录，问题更可能在内容质量、重复度或页面价值判断上，此时日志能提供的信息已接近上限。
下一步：导出最近30天的爬虫请求记录，按“URL—状态码—响应大小—时间”四列整理成表，先处理状态码异常和空响应页面，再观察抓取覆盖是否变化。不同搜索引擎的爬虫UA、IP段和支持情况需要分别核查，不要用一份日志推断所有引擎的行为。
