搜索引擎蜘蛛爬行日志分析：先看清抓取，再谈优化
搜索引擎蜘蛛爬行日志分析不是看几个访问量数字，而是回答三个问题：谁在抓、抓了哪些 URL、这些抓取是否落在你希望被收录的页面上。本页给出一套从原始日志到结论的完整做法。
服务器访问日志是唯一由你自己掌控、不经过第三方加工的第一手抓取数据。Search Console 的抓取统计通常有 1 到 3 天的延迟，且只覆盖抽样；而 Nginx 或 Apache 的 access.log 记录的是每一次真实请求，包含时间、IP、User-Agent、URL、状态码、响应字节数和耗时。把这两类数据对照起来看，才能判断抓取是否正常。
本页面向已经有一定流量的站点：日抓取请求在几千到几十万次之间，页面数量在数百到数万之间。如果你刚上线、每天只有几十次抓取，日志分析的边际收益很低，优先做站点结构和内链更划算。
阅读顺序建议：先看「为什么看日志」明确目标，再看「日志从哪来」确认数据完整，然后按「清洗流程」逐步处理，最后用「指标对照表」下结论。
日志里常见的爬虫类型
- Googlebot（Smartphone / Desktop）
- Bingbot
- Baiduspider
- Googlebot-Image / 各类资源爬虫
- 搜索引擎渲染队列（Rendering）
- 非搜索类爬虫与伪装爬虫
不同爬虫的抓取目的不同，混在一起统计会得出错误结论，建议在清洗阶段就按类型拆分。
为什么值得花时间做爬行日志分析
日志分析的价值不在报表好看，而在于它能暴露第三方工具看不到的问题。
很多站点在 Search Console 里看到「已发现但未编入索引」的页面数上升，第一反应是内容质量问题。但打开日志一看，往往发现这些页面根本没被请求过——问题出在抓取环节而不是质量环节。日志能把这个区分做出来，避免在错误的方向上改内容。
另一个典型场景是改版。改版后新旧 URL 并存、301 链路过长、内链指向旧地址，这些问题在日志里表现为旧 URL 持续被高频抓取、新 URL 抓取稀少、3xx 响应占比升高。这三个信号同时出现，基本可以确认改版没收干净。
区分「没被抓」和「抓了没收」
把目标页面清单与日志做交集，未出现的页面属于抓取问题，出现的页面属于内容或质量判断问题。两类问题的处理方式完全不同，混淆会浪费数周时间。
发现抓取预算被低价值 URL 吃掉
统计抓取频次最高的前 100 个 URL，若其中参数组合页、筛选页、日历页占比过高，说明爬虫把大量配额花在了不需要收录的地址上，核心页面自然抓得少。
验证 robots.txt 与 meta 标签是否按预期生效
日志里被 Disallow 的路径若仍出现大量请求，说明规则写法有误或存在绕过路径；被 noindex 的页面若持续被抓，说明内链仍在指向它们。
日志从哪里取，取哪几段
数据源不完整会让后面的所有统计失真，先确认这四件事再动手。
Nginx / Apache 访问日志
默认路径通常是 /var/log/nginx/access.log 或 /var/log/httpd/access_log。建议按天切割并保留至少 30 天，覆盖一个完整的抓取周期。
CDN 与反向代理日志
若站点前置了 CDN，源站日志只记录回源请求，会漏掉大量命中缓存的抓取。需要从 CDN 控制台导出边缘日志，或在回源规则里透传真实 UA 与 IP。
负载均衡后的多节点日志
多台后端时，单节点日志只覆盖部分流量。建议在采集阶段就汇总，或统一投递到日志服务后再分析，避免按节点分别统计造成误判。
日志格式是否包含所需字段
至少需要 remote_addr、time_local、request、status、body_bytes_sent、http_user_agent、http_referer。若缺少 UA 字段，需要先调整 log_format 再重新积累数据。
六个必须逐一看的字段
日志行很长，但真正影响判断的就是这几个位置，其余字段用于辅助验证。
IP 与反向 DNS
UA 可以伪造，IP 不能。对 Googlebot 的请求做反向 DNS 解析，结果应以 googlebot.com 或 google.com 结尾，再正向解析回同一 IP 才算可信。批量校验建议用脚本处理，不要人工抽查。
User-Agent 完整字符串
注意区分 Googlebot/2.1 与各类带 Googlebot 字样的第三方 UA。统计时按完整字符串分组，而不是按包含关键词匹配，否则会把工具流量算进搜索爬虫。
请求 URL 与查询参数
保留完整 query string。分析时按路径聚合、按参数拆分，才能看出是哪个参数在制造大量变体地址。
状态码
200 表示正常返回，301/302 表示跳转，404 表示不存在，5xx 表示服务端异常。按天统计各状态码占比，5xx 出现即需排查。
从原始日志到结论的六步流程
每一步都有明确的输入和输出，按顺序做，不要跳步。
下面这套流程适用于单站点、日请求量在百万行以内的场景。用 awk、grep、sort、uniq 这类命令行工具就能完成大部分工作，不必一上来就上大数据平台。若日志量更大，再把同样的逻辑搬到日志服务里跑。
关键原则是：先缩小范围再统计。直接对全量日志做聚合，既慢又容易把无关爬虫混进来。建议第一步就按 UA 和 IP 校验筛出目标爬虫，后续所有分析都基于这份筛选后的数据。
第 1 步：按天切分并去重压缩
用 logrotate 或按日期重命名，保留原始文件。压缩后单日日志通常能缩小到原体积的十分之一，便于长期留存和回溯。
第 2 步：筛出目标爬虫
用 grep 匹配 UA 关键字得到候选集，再对候选 IP 做反向 DNS 校验，剔除伪装流量。输出一份干净的爬虫请求清单。
第 3 步：解析为结构化字段
用 awk 按空格切分，提取 IP、时间、URL、状态码、字节数、UA 六列，输出为 TSV 或 CSV，方便后续导入表格或数据库。
第 4 步：按 URL 聚合抓取次数
对 URL 去参数后排序计数，得到抓取频次分布。重点看前 100 名和长尾部分的差异，判断是否存在抓取集中或过度分散。
第 5 步：与站点 URL 清单做交集
导出 sitemap 中的 URL 列表，与日志中的 URL 做集合运算，分别得到「被抓过的」和「从未被抓的」两份清单，后者是优化重点。
第 6 步：按天对比趋势并下结论
把上述指标按天排成时间序列，观察 7 天和 30 天的变化。单日异常多为波动，连续 3 天以上的偏移才值得作为结论依据。
指标对照表：看到什么数字，判断什么问题
下表给出常见指标的参考区间和处理方向。区间为行业常见经验值，具体站点需结合自身规模调整。
使用这张表时注意两点。第一，所有比例都要基于「已校验的真实爬虫请求」，未校验的数据没有参考意义。第二，指标之间要交叉看：单看 404 占比高可能是站点改版遗留，也可能是爬虫在探测不存在的参数组合，需要结合 URL 样本判断。
| 指标 | 常见参考区间 | 异常时的处理方向 |
|---|---|---|
| 核心页面 7 天抓取覆盖率 | 通常应高于 80% | 低于该值时检查内链层级与 sitemap 是否包含这些 URL |
| 5xx 响应占比 | 一般应低于 1% | 排查数据库慢查询、缓存击穿、限流规则误伤爬虫 |
| 3xx 响应占比 | 一般低于 5% | 检查跳转链是否超过 2 跳、内链是否仍指向旧地址 |
| 404 响应占比 | 一般低于 3% | 区分真实死链与参数变体，前者修链，后者加规则收敛 |
| 参数页抓取占比 | 通常控制在 20% 以内 | 用 canonical、robots.txt 或 URL 规则限制变体扩散 |
| 单 URL 日均抓取次数 | 核心页 1 到 5 次较为常见 | 过高说明页面频繁变动或存在重复入口，需检查更新策略 |
表格里的区间不是标准答案。一个每天更新数百条内容的资讯站，核心页抓取频次天然高于企业站；一个页面总数只有 200 的站点，抓取覆盖率接近 100% 也很正常。判断时应以自身 30 天基线为参照。
四类最常见的误判
这些结论看起来合理，但往往是数据口径出了问题。
把 CDN 命中流量当成没被抓
源站日志里看不到命中缓存的请求，容易得出「抓取量下降」的结论。实际应看 CDN 边缘日志，或对比开启缓存前后的数据口径。
用 UA 关键字匹配代替 IP 校验
大量第三方工具在 UA 里带 Googlebot 字样，只按 UA 统计会把工具流量算成搜索抓取，虚高比例有时超过 30%。
忽略渲染请求的重复计数
同一 URL 在抓取和渲染阶段可能各请求一次，直接计数会高估抓取频次。需要按请求来源或时间间隔做区分。
把单日波动当成趋势
爬虫调度本身有随机性，单日抓取量上下浮动 20% 属于常见现象。至少观察 7 天再判断是否真的下降。
工具选择与落地做法
从命令行到可视化，按数据量和使用频率选择，不必追求最重的方案。
命令行三件套：grep、awk、sort
适合日请求百万行以内的场景。一条 grep 加 awk 的组合就能筛出指定 UA 并按 URL 计数，处理一天日志通常在几十秒内完成，无需额外部署。
日志服务与查询语言
数据量更大或需要多人协作时，把日志投递到日志服务，用类 SQL 的查询语言做聚合。好处是保留原始明细、支持随时改口径重算。
表格工具的透视分析
把清洗后的 CSV 导入表格软件，用数据透视表按状态码、日期、路径分组。适合快速出结论和小范围汇报，处理上限约几十万行。
自建脚本定期跑批
把六步流程写成脚本，每天定时执行并输出固定格式的日报。关键是固定口径，保证不同日期的数据可比较，而不是每次临时写查询。
与 Search Console 数据对照
把日志中的抓取量与 Search Console 的抓取统计放在同一时间轴上对比。两者趋势一致说明数据可信，偏差过大则要检查日志是否完整。
校验 IP 的小工具思路
用 dig -x 对 IP 做反向解析，再用 dig 对得到的域名做正向解析，两次结果一致才认定为真实爬虫。批量处理时加并发控制和结果缓存。
自己做还是外包：三种投入方式
价格为首年常见投入区间，按站点规模和数据量估算，实际以具体需求为准。
一次完整分析的时间安排
以单站点、数据源不超过三个的项目为例，从接入到出结论的典型节奏。
- 第 1 天
确认数据源与字段
确认日志位置、格式、保留周期，检查 UA 与 IP 字段是否完整，确定需要覆盖的时间范围。
- 第 2 到 3 天
采集与清洗
汇总多节点日志，按爬虫类型筛选，完成 IP 校验，输出结构化数据。
- 第 4 到 5 天
基础指标统计
计算抓取覆盖率、状态码分布、参数页占比等核心指标，形成按天的趋势序列。
- 第 6 到 10 天
问题定位与样本核对
对异常指标抽取 URL 样本逐条核对，区分真实问题与统计口径问题，排除误判。
- 第 11 到 14 天
输出结论与整改优先级
整理成可执行清单，按影响面和改动成本排序，标注每项的验证方式与复查时间点。
日志分析最容易犯的错，是先有结论再找数据。看到流量下降就翻日志找「抓取减少」的证据，往往能在噪声里找到想要的数字。更稳的做法是先固定口径、跑完 30 天基线，再让数据自己说话。抓取量下降、抓取量不变但收录下降、抓取量和收录都正常而排名下降，这三种情况对应的原因完全不同，日志只能回答第一种。
常见误区提醒 · 关于抓取数据的一条经验
常见问题
关于数据来源、周期、成本和风险的六个实际疑问。
日志只保留 7 天，还能做分析吗
可以做，但结论范围受限。7 天数据足以判断当前抓取是否正常、状态码是否健康，但无法判断趋势和改版影响。建议至少保留 30 天，若存储紧张可只保留爬虫相关行，体积通常能降到全量的 10% 到 20%。
为什么日志里的抓取量和 Search Console 对不上
两者口径不同。Search Console 统计的是去重后的抓取统计，且有延迟和抽样；日志记录的是每一次请求，包含渲染、资源抓取和重复访问。偏差在 20% 以内通常正常，偏差过大应检查日志是否完整或是否混入了非搜索爬虫。
没有服务器权限，只有 CDN 后台，怎么办
从 CDN 控制台导出边缘访问日志，字段通常包含 IP、UA、URL、状态码，足以完成大部分分析。注意确认导出的时间范围和采样率，部分服务商的免费套餐会做抽样，需要在结论里注明。
分析一次要花多少钱
自行搭建主要是人力成本，首次约 2 到 3 个工作日。使用日志服务按量计费，日请求百万行级别的站点年费通常在数千元区间。外包单次诊断按项目计价，常见区间在 5000 到 30000 元，取决于数据源数量和交付深度。
发现 5xx 占比偏高，应该先改什么
先定位是哪些 URL 触发 5xx，再看是否集中在某类页面或某个时间段。常见原因是数据库慢查询、缓存失效瞬间的并发穿透、以及限流规则误伤爬虫 IP。处理顺序建议先修服务端稳定性，再考虑调整抓取频率相关的配置。
数据安全上需要注意什么
访问日志包含用户 IP 和访问路径，属于需要控制范围的数据。建议分析环境与生产环境隔离，导出文件脱敏后传输，分析完成后按保留策略清理。若交给外部团队处理，应在协议中明确数据用途、保存期限和删除方式。
关于本页与反馈
本页内容基于公开的爬虫行为说明与常见运维实践整理，持续修订。
本页不提供自动化分析服务，也不收集站点日志。所有方法均可使用自有服务器和开源工具复现。文中给出的参考区间来自公开文档与常见实践，不同站点规模和行业差异较大，请以自身 30 天基线为准。
如果你在实践中遇到与文中描述不一致的情况，欢迎通过邮件说明场景：站点日抓取量级、使用的日志来源、观察到的异常指标。描述越具体，越容易判断是口径问题还是真实异常。
- 邮件反馈 [email protected]，通常 3 个工作日内回复。请勿发送包含用户隐私的原始日志。
- 内容修订 指标区间、工具用法、爬虫校验方法会随官方文档更新而调整，修订记录以页面更新时间为准。
- 适用范围 适用于日抓取请求在数千到数十万次之间的站点。规模更小的站点建议优先优化站点结构与内链。