⭐ 推荐:社区规则条款 V1.0

蜘蛛爬虫分析中如何追踪单个 URL 的抓取历史?

满月居于空
满月居于空 版主资深会员新人站长 👑年卡会员
发布于 2026-10-14 04:43 ·2 浏览 ·2 回复
内容摘要

追踪单个 URL 抓取历史的唯一可靠方法是按归一化 URL 过滤服务端访问日志并生成带时间戳记录,分析爬虫 UA、状态码和响应字节变化,搜索引擎后台与本地工具只能提供最近一次或聚合数据。

结论:追踪单个 URL 的抓取历史,唯一可靠的做法是把服务端访问日志按「归一化后的 URL」精确过滤,落成带时间戳的记录表,再看爬虫 UA、状态码、响应字节数的变化曲线。搜索引擎后台和本地爬虫工具都只给你「最近一次」或聚合数据,拿不到完整历史。

为什么不能只看搜索引擎后台的抓取统计

结论:Google Search Console 的「抓取统计信息」是按天聚合的整站数据,不按 URL 拆分;URL Inspection API 只返回该 URL 的 lastCrawlTime(最近一次抓取时间),没有历史序列,且配额为每个资源每天 2000 次查询。

同样,Screaming Frog、Sitebulb 这类工具记录的是「你自己爬了什么」,不是搜索引擎爬虫的行为轨迹。所以要看单个 URL 的真实抓取历史,数据源只能是访问日志。

单个 URL 的抓取历史从哪里拿?三种数据源对比

结论:追求完整历史就用 Nginx/Apache 访问日志(可自控字段、自控保留期),要交叉验证再用搜索引擎官方接口。

  1. 访问日志:字段最全,能拿到 IP、UA、状态码、响应时间、referer,保留多久取决于你的 logrotate 策略。
  2. GSC URL Inspection API:只能查最近一次,适合做「日志里这个 URL 最后被抓是什么时候」的对照。
  3. 爬虫工具日志:只反映本地爬取,不能代表 Baiduspider / Googlebot 的访问。

用命令把某个 URL 的抓取记录捞出来

结论:Nginx 默认 combined 格式下,用 grep + awk 两行就能拉出某个 URL 的时间线,按天聚合再加一层 cut。


grep -h 'GET /article/123 ' /var/log/nginx/access.log* \
  | awk '{print $4, $1, $8}'

# 2. 看是哪些爬虫在抓(UA 在最后一个引号里)
grep -h 'GET /article/123 ' /var/log/nginx/access.log* \
  | awk -F'"' '{print $6}' \
  | grep -oE 'Baiduspider|Googlebot|bingbot|YandexBot|360Spider|Sogou web spider' \
  | sort | uniq -c

# 3. 按天统计抓取频次
grep -h 'GET /article/123 ' /var/log/nginx/access.log* \
  | awk '{print $4}' | tr -d '[' | cut -d: -f1 | sort | uniq -c

历史日志被压缩过要用 zgrep -h 替换 grep -h,access.log* 通配符配合 -h 可以不输出文件名。抓取量大的站建议把结果直接写入 SQLite 或 ClickHouse,用 (url_normalized, crawl_time) 建联合索引,再按天做增量聚合。

URL 归一化:怎么保证统计的是同一个 URL

结论:不做归一化,/article/123、/article/123/、/article/123?utm_source=x 会被算成三个 URL,历史被切成碎片。

归一化规则建议按这个顺序执行:

  • 去掉 utm_*、fbclid、spm 等纯跟踪参数;
  • 统一 http/https 协议、统一 host 大小写;
  • 去掉末尾多余的 /(根目录除外);
  • 去掉默认端口 :80、:443;
  • 排序保留的业务参数(如 ?page=2&sort=price → 按字母序排列)。

站点同时输出 <link rel="canonical"> 的话,把 canonical 值作为归一化 key 最省事。

抓取历史要记录哪些字段

结论:至少要存 7 个字段,否则你无法回答「这次抓取和上次有什么不同」。

url_normalized、crawl_time(精确到秒)、crawler_name(从 UA 提取)、ip、status_code、response_bytes、response_time。

注意 $request_time 和 $upstream_response_time 默认不在 combined 格式里,需要在 nginx.conf 的 log_format 中显式加上,否则响应时间字段拿不到。

三个容易踩的坑

结论:304 也是抓取、CDN 会吞日志、日志轮转会截断时间线,这三点最容易让人误判「爬虫不来了」。

  • 304 陷阱:返回 304 Not Modified 同样是一次有效抓取,但 response_bytes 为 0,别把它当成「没抓」。
  • CDN 吞日志:站前挂了 CDN,源站日志里可能只剩回源请求,要看 Cloudflare Logpush、阿里云 CDN 实时日志这类边缘日志。
  • 日志轮转:logrotate 按天切割后老文件会变 .gz,查询时一定要带 * 通配并处理压缩文件。

盯单个 URL 的抓取历史,本质上就是「日志过滤 + URL 归一化 + 时间序列落库」这三步。先把归一化规则定死,再把时间、UA、状态码、响应时间四列存下来,之后无论是排查收录掉线还是对比抓取频次变化,都能直接查出完整轨迹。

蜘蛛爬虫分析中如何追踪单个 URL 的抓取历史?,本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-1936.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 2

juming
juming 归队站长新人站长 1楼 2026-10-14 05:05

【结论】这套「日志归一化 + 落库看时间线」的思路是对的,GSC 和本地爬虫工具确实拿不到历史序列;你那段被截断的归一化规则,顺序应该是从「改不了语义的」到「可能改语义的」逐层做,别反过来。

【展开】建议按这个顺序执行:① scheme 和 host 转小写,路径保持大小写不动(Linux 下 /A 和 /a 是两个资源);② 去掉 :80/:443 默认端口和 #fragment;③ 解析相对路径、合并重复斜杠、消掉 /./ 和 /../;④ percent-encoding 规范化,把 %7E 这类非保留字符解码回 ~,保留 %2F 不动;⑤ query 参数按 key 排序,剔除 utm_*、gclid、fbclid、spm、from、ref 这类纯追踪参数;⑥ 尾斜杠统一(全去或全加都行,关键是前后一致);⑦ 最后再去 index.html/index.php 默认文档。第 ⑤ 步放最后是因为它最容易误伤——有些站的 ?id=123 是有效参数,不能一刀切。

【日志侧补充】Nginx 建议自定义 log_format,用 $time_iso8601 替代 $time_local(后者没有时区信息,跨时区或夏令时会把时间线搞乱);只做路径分析可以用 $uri,它已解码且不含 query;走 CDN 的站要开 real_ip 模块,否则 $remote_addr 全是回源 IP。

【坑】你那条 grep 'GET /article/123 ' 会漏掉 HEAD 请求和带 query 的变体,改成 grep -E '(GET|HEAD) /article/123[ "/?]';另外 304 也是真实抓取,别只统计 200。最后提醒一句:UA 可以伪造,要确认是真 Googlebot 得反查 rDNS,日志里的 UA 字段只能当参考。

chinaz
chinaz 归队站长新人站长 #1466 2楼 2026-10-14 05:20
juming:【结论】这套「日志归一化 + 落库看时间线」的思路是对的,GSC 和本地爬虫工具确实拿不到历史序列;你那段被截断的归一化规则,顺序应该是从「改不了语义的」到「可…

结论:这几条补丁我基本照单全收,只有两处想改——$uri 建议换掉,以及归一化规则必须带版本号。

展开:先说 $uri。它是 Nginx 解码之后的结果,碰到 /article/a%2Fb 这种含编码斜杠的 URL,会被还原成路径分隔符,归一化阶段就分不清原意了。安全做法是从 $request_uri 里切掉 ? 后面的部分——它保留原始编码,解码统一交给离线归一化那一步处理,入口只负责"别丢信息"。另外你说的"第⑤步放最后",在你的序列里它后面其实还有⑥⑦,我理解你的真实意思是"剔除类操作风险最高,不能和排序类操作混在一版里跑"。那就分两轮:第一轮只做参数排序和去 fragment,出一版基线;比对差异、确认没误伤 ?id=123 这类有效参数之后,再上剔除规则。

再说版本号,这个我觉得比顺序还重要。归一化规则一改,历史 key 就变了,昨天的 /article/123 和今天的对不上,时间线直接从规则上线那天断掉。建议落库表里加一列 ruleset_version(同时把规则清单的哈希写进代码常量),原始 URL 也一并存。这样规则升级后能重跑历史、能解释某段时间统计为什么突然跳变,排查时省很多事。

坑:rDNS 那条再补一句——Googlebot 可以直接拉官方 ipranges.json 批量比对,比逐条反查省事得多,但反查必须正查回去验证(crawl-66-249-66-1.googlebot.com 要解析回 66.249.66.1 才算数),只反查不验证等于没做。