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

百度新闻收录 - 日志中应该核对哪些字段

要判断百度新闻是否来抓取过、抓到了什么、为什么没收录，最直接的办法是查服务器访问日志。你需要重点核对的字段是：请求时间、客户端 IP、User-Agent、请求方法、请求 URL、HTTP 状态码、响应大小、Referer。这八项能还原一次抓取是否发生、是否成功、是否取到了正文页，其余字段属于辅助信息。

先明确日志要能回答的三个问题

百度新闻收录的排查，本质上是用日志回答三件事：百度来过没有、来的是不是新闻抓取、拿到的结果是否正常。如果日志里连一次来自百度的请求都找不到，那问题在发现和抓取环节，不在内容质量；如果抓到了但状态码异常，问题在服务端响应；如果抓到了 200 却长期不收录，才需要往内容质量和新闻源资质方向查。

因此核对字段的顺序，应该按“先确认身份，再确认结果，最后确认内容”来排，而不是把整行日志从头读到尾。

逐字段核对清单与判断依据

• 请求时间：确认抓取发生的日期和频率。看是否集中在发布后短时间内，还是长期没有新请求。时间字段还能和内容发布时间对齐，判断抓取是否滞后。
• 客户端 IP：用于反向解析验证来源。百度官方公布过抓取 IP 段，可通过反向 DNS 查证是否为 baidu.com 域名。注意 IP 可以被伪造，单看 IP 不足以确认身份，必须和 User-Agent 一起判断。
• User-Agent：这是区分普通用户和抓取程序的关键。百度新闻抓取通常带有明确的蜘蛛标识，与百度网页搜索的 UA 可能不同。核对时要完整看整串，不要只匹配“Baiduspider”就下结论。
• 请求方法：一般是 GET。如果出现大量 HEAD，说明对方只在探测，没有取正文，这时不能算作有效抓取。
• 请求 URL：确认抓到的是新闻正文页、列表页还是参数页。带跟踪参数、会话 ID、排序参数的 URL 被反复抓取，往往意味着规范化没做好，同一内容被当成多个地址。
• HTTP 状态码：200 表示正常返回；301/302 要看跳转目标是否可达；403 常见于被防火墙或防盗链拦截；404 说明链接失效；5xx 是服务端故障。状态码是判断“为什么没收录”的第一分界线。
• 响应大小：返回字节数过小，比如只有几百字节，通常意味着返回的是错误页、验证页或空壳页，而不是正文。把它和状态码结合看，能识别“200 但没内容”的情况。
• Referer：可以看出抓取是从哪个入口跳转过来的，有助于判断抓取路径是站内链接、站点地图还是外部引用。

一个可执行的核对流程

假设你怀疑某篇稿件没有被百度新闻收录，可以按下面步骤操作。以下为方法示例，不涉及任何具体站点数据。

1. 先按 URL 过滤日志，只保留该稿件地址对应的记录。
2. 在结果中筛选 User-Agent 含百度蜘蛛标识的行。如果没有结果，说明该页面没有被抓取，下一步应检查入口链接和站点地图，而不是修改正文。
3. 如果有结果，提取状态码和响应大小。出现 403、5xx 或响应体明显偏小，先修服务端和拦截规则。
4. 状态码为 200 且响应大小正常时，再核对请求 URL 是否为你期望的规范地址，排除参数页被反复抓取的情况。
5. 最后用时间字段对比发布与抓取的时间差，判断抓取频率是否正常。

这些字段不能证明什么

日志能证明抓取行为，但不能证明收录结果。抓取成功不等于进入索引，更不等于出现在新闻搜索结果里。反过来，日志里没有记录也不一定代表百度没来过，可能只是日志被轮转覆盖、CDN 层未回源、或者抓取请求没有落到你的源站日志上。排查前先确认日志采集链路是完整的。

另外，robots.txt 中禁止抓取只能阻止爬虫访问，不能作为可靠的索引移除手段；提交站点地图也不保证收录。这两点在读日志时要分清，不要因为“已经提交了”就默认抓取一定发生。

下一步该做什么

先把最近一段时间的原始日志完整保留下来，确认日志级别记录了 User-Agent 和状态码。如果日志里缺少这两项，先调整服务器或 CDN 的日志格式，再重新观察一个抓取周期。字段齐全之后，再按上面的流程判断问题出在抓取、响应还是内容层面。