360收录_日志中应该核对哪些字段
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c50e2dafe768.html
📄
360收录_日志中应该核对哪些字段
排查360收录时，日志里最值得先核对的是抓取时间、请求URL、HTTP状态码、User-Agent、响应字节数、来源IP这几类字段。它们能回答三个问题：360蜘蛛有没有来、来了抓的是什么、抓完得到了什么结果。只看访问量或只看到“有蜘蛛”都不够，必须把字段组合起来判断。
先分清两种日志：服务器访问日志与抓取统计
服务器访问日志由站点自己控制，字段最完整，适合逐条核对；搜索资源平台提供的抓取统计通常是聚合数据，只能看到次数和趋势。两者口径不同，不能互相替代。如果站点使用CDN或反向代理，源站日志可能只记录回源请求，需要在CDN侧开启日志或把真实客户端IP传递到源站，否则来源IP字段会失真。
可执行核对清单
下面每一项都按“查什么、怎么查、结果说明什么”组织。建议先取最近7天日志，用命令行过滤出360相关请求，再逐项核对。
- User-Agent：查蜘蛛身份。用
grep -i "360Spider" access.log过滤。如果完全没有结果，说明360蜘蛛近期未抓取，问题在发现或调度层面，而不是内容质量层面。如果结果存在但很少，需要结合抓取时间看频率是否稳定。注意User-Agent可以被伪造，它只能作为线索，不能单独作为“360蜘蛛已抓取”的证据。 - 抓取时间：查抓取节奏。观察请求集中在哪几天、哪个时段。如果只在发布新内容当天出现，之后不再回访，说明抓取深度有限。如果长期没有任何请求，应优先检查robots.txt是否误封、服务器是否对360蜘蛛返回异常、以及是否有防火墙拦截。
- 请求URL：查抓的是不是目标页面。确认日志中出现的URL与希望被收录的页面是否一致。如果大量请求落在参数页、筛选页、重复页上，说明抓取预算被分散，目标页面获得的机会减少。此时应检查内链、站点地图和URL规范是否把蜘蛛引向了错误入口。
- HTTP状态码：查抓取结果。200表示正常返回；301或302表示跳转，需要确认跳转链是否过长；404表示页面不存在；403表示被拒绝；5xx表示服务器错误。如果360蜘蛛频繁拿到5xx，应先修服务器稳定性，再谈收录。robots.txt的抓取限制不等于可靠的索引移除，它只控制抓取，不保证页面从索引中消失。
- 响应字节数：查返回内容是否完整。字节数为0或明显偏小，可能是超时、被拦截或返回了空页。把字节数与正常访问同一URL时的结果对比，能判断是蜘蛛专属问题还是全站问题。
- 来源IP：查是否经过代理或CDN。如果所有请求都来自同一个内网或CDN回源IP，说明日志记录的不是真实蜘蛛IP，需要检查代理配置和
X-Forwarded-For等头部是否被正确记录。
两种处理方案的适用条件
发现360蜘蛛抓取异常时，常见两种处理方向。方案一是先修可访问性：检查robots.txt、服务器状态码、防火墙和CDN拦截规则，适用于日志中大量出现403、5xx或完全没有蜘蛛请求的情况。方案二是先修内容与链接结构：检查目标页面是否被内链指向、站点地图是否包含、是否存在大量重复或低质页面，适用于蜘蛛能正常抓取但目标页面迟迟不被收录的情况。判断依据是日志中目标URL是否被请求过：没被请求过，优先修可访问性和发现路径；被请求过但状态码异常，优先修服务端；被请求过且返回200，才轮到内容和页面质量层面。
一个假设示例
假设某站点日志中360Spider每天请求约50次，但目标文章页从未出现，请求集中在标签页和分页上。这说明蜘蛛能进来，但内链和站点地图没有把它导向文章页。此时应检查文章页是否有可抓取的入口链接、站点地图是否包含该URL、以及标签页是否产生了大量近似重复内容。反之，如果日志中目标URL返回200但字节数只有几百，应检查页面是否依赖JavaScript渲染、服务端是否对蜘蛛返回了简化版本。
核对时容易踩的坑
站点地图不保证收录，它只是发现入口。HTTPS不保证安全无漏洞，也不保证排名。不同搜索引擎对同一站点的抓取策略不同，360搜索的抓取情况必须用360蜘蛛的日志单独核查，不能拿其他引擎的抓取数据直接推断。日志字段缺失时，先补全日志格式，再谈分析。
下一步：从服务器或CDN导出最近7天原始日志，按User-Agent过滤出360Spider请求，把目标URL、状态码、字节数、抓取时间四列整理成表，再对照上面的清单逐项标记异常项。
