KNOWLEDGE / 09LAYER 2下一阶段

抓取预算与日志分析

Crawl Budget & Log Analysis

先判断规模与更新频率是否真的构成抓取约束,再用服务器日志观察搜索爬虫实际请求,避免用模拟爬取代替现实。

先修知识站点架构与发现路径XML Sitemap 治理robots.txt 与 noindex 控制边界
解锁能力SEO 迁移控制系统
默认基础无需额外背景
本页目录 · 11 个学习环节
01

学习契约与正确模型

先明确为什么学、学完能做什么,以及如何证明自己真的掌握。

为什么现在要学

大型文档和程序化 B2B 站可能把抓取耗在参数、重复与错误 URL 上,使新品与文档更新发现更慢。

完成本页后,你应能
  • 能区分 crawl capacity 与 demand
  • 能清洗并聚合爬虫日志
  • 能按模板、状态和新鲜度治理抓取
建议节奏

精读 32 分钟 → 引导练习 20 分钟 → 实战任务 90 分钟。实战时间单列,不再把浏览页面和项目操作混成一个数字。

它是什么
抓取预算近似由站点可承载能力和搜索系统抓取需求共同决定;日志记录真实请求。
为什么重要
抓取资源有限且需保护服务器,重复空间、慢响应和低价值 URL 会消耗机会。
什么时候使用
数十万 URL、频繁更新、无限参数、发现延迟或迁移高峰时。
什么时候不要套用
小站收录差通常不是预算问题,应先查链接、质量和索引控制。
边界与不确定性
日志证明被请求,不证明渲染、索引或排名;user-agent 还需验证。
02

机制精讲

先读完整因果链,再看每个环节留下什么可观察信号。

抓取预算不是所有网站都需要优先解决的问题。公开概念通常把可抓取容量与抓取需求分开:服务器是否能稳定承载请求是一类约束,搜索系统对 URL 的已知价值、更新与陈旧程度形成另一类需求。对几百个页面的小站,页面未收录更常见的原因可能是缺少链接、响应异常、重复或内容资格;只有当 URL 空间、更新速度和实际爬虫请求构成可测瓶颈时,预算分析才值得投入。

服务器访问日志是这类分析的核心一手证据,因为模拟爬虫只能说明“我们能访问什么”,日志才记录搜索机器人“实际请求了什么”。完整工作需要验证机器人身份、统一 URL、区分机器人类型、按模板和状态聚合,并把请求占比与业务价值、新鲜度和索引需求连接。日志趋势可以支持治理决策,却不能披露搜索引擎内部的固定配额或保证减少低价值 URL 后排名上升。

01

容量与需求共同约束

高延迟和 5xx 会压缩站点可承载抓取;大量陈旧、重复或低价值 URL 会改变请求分布。两者必须分开测量,不能把每日请求数当作唯一预算。

观察什么结合响应时延、5xx、抓取统计与日志中的请求模板和日期。
02

日志代表实际行为

日志行记录请求时间、路径、状态、User-Agent 等;机器人验证还需反向与正向 DNS 或可靠边缘标识,不能仅相信包含 Googlebot 的字符串。

观察什么保存验证方法、原始样本、排除规则和无法识别的请求比例。
03

URL 空间治理

参数组合、站内搜索、分页陷阱和重复文件可能扩大可发现空间。治理动作应分别处理链接产生、允许抓取和索引,不用 canonical 代替发现控制。

观察什么按标准化规则聚合参数族,并对治理前后请求、新品发现和错误率做同口径比较。
03

关键概念

掌握术语之间的关系,才能迁移到不同网站、行业和工具。

01

容量与需求

服务器健康影响容量,受欢迎度、陈旧度和重复性影响需求。

02

日志事实

按已验证爬虫、模板、状态、响应时间和日期聚合实际请求。

03

空间治理

减少无穷参数、重复导航和错误内链,比手动追求抓取率更可控。

04

完整示范

跟随一次“输入 → 分析 → 中间产物 → 结论”,看见专家是怎样做判断的。

WORKED EXAMPLE

百万级零件目录的日志诊断

教学用合成数据:站点有 80 万个规范产品页,30 天日志中验证后的搜索机器人请求 600 万次,其中 62% 落在排序与会话参数,重要新品从发布到首次抓取中位 9 天。

前提与样例口径
  • 日志覆盖所有主要源站和 CDN
  • 参数页无独立搜索价值且可由规范列表完成任务
  1. 清洗请求

    输入
    时间、主机、路径、查询串、状态、User-Agent、响应时长。
    分析
    验证机器人,统一协议主机和编码,保留原始 URL,同时生成模板与参数分类;明确日志缺口而不是静默删除。
    输出
    可复跑的清洗规则与带质量统计的请求表。
  2. 建立分布基线

    输入
    清洗表与 URL 库存。
    分析
    按模板、状态、参数族、新旧 URL 与响应时延统计请求数、唯一 URL、重抓间隔;单纯请求多不等于浪费,要和页面价值及变化频率比较。
    输出
    抓取分布、错误率和新品发现时延基线。
  3. 定位产生机制

    输入
    高请求参数样本与站点爬取。
    分析
    追踪参数链接来自筛选器、模板、脚本还是外部引用,检查 robots、canonical 与 sitemap 当前行为;优先修复内部无限产生源。
    输出
    参数族—来源模板—可控动作矩阵。
  4. 小范围治理并复测

    输入
    一个低风险目录和发布计划。
    分析
    先停止生成无价值 href,必要时配置抓取规则,监控 5xx 与核心页访问;用相同 30 天窗口比较参数占比和新品首次抓取。
    输出
    前后对照与扩大、停止或回滚决定。

结论:证据支持的问题是“实际抓取集中在无价值参数,同时新品发现慢”,而不是抽象的“预算不足”。优先从链接产生源治理,能让实验可逆;是否改善索引和业务结果仍需更长窗口观察。

迁移到真实项目:同样方法适用于电商筛选、程序化落地页、文档版本和日历陷阱,但每类 URL 的业务价值与更新需求必须重新定义。

05

决策规则与证据边界

把“看到什么、意味着什么、下一步做什么”连起来,同时区分公开事实、实践推断和未知项。

信号解释行动限制
规模小、日志健康且重要页很快被抓取当前没有明显抓取容量或分布瓶颈。把精力转向链接、索引资格、需求和页面质量。以后规模或发布频率改变时再复测。
验证机器人请求大量集中在可控参数族URL 产生机制可能消耗请求与分析注意力。先修模板链接源,再选择适当抓取与索引治理。确认这些参数确实没有独立用户价值。
5xx 与高延迟和抓取下降同时间出现站点承载能力可能成为约束。与工程排查源站/CDN,降低错误并建立容量监控。时间相关不等于唯一因果,要控制发布和流量事件。
可确认
  • 服务器日志可证明已记录请求的时间、URL、状态与客户端标识;Google 公开区分 crawl capacity 与 crawl demand。
工作推断
  • 参数治理后请求可能转向重要模板,需要同口径前后日志验证。
不要声称已知
  • 不存在可由站长精确读取的固定每日 Google 抓取配额或公开调度权重。
06

引导练习

先独立完成,再按提示修正,最后展开参考解法并用 0–4 级量规评分。

YOUR TURN

分析教学用合成数据:某文档站 14 天有 100 万次验证机器人请求,旧版本 45%、站内搜索 25%、现行文档 25%、其他 5%;新品首次抓取中位 36 小时,5xx 为 0.1%。

给定材料

  • 旧版本仍从每页版本选择器以 href 链出,canonical 指向现行版,但内容可抓取。
  • 站内搜索结果由导航表单生成可跟随参数链接;业务确认其无独立搜索价值。
需要提示时再展开
  1. canonical 解决代表页选择,不等于阻止发现或抓取。
  2. 写出先改什么、如何小范围发布、用什么领先指标判断。
完成后核对参考解法

先不要声称已证实“预算耗尽”,因为新品仍在 36 小时内被抓取且 5xx 很低;但请求结构显示明显可治理空间。应从内部链接产生源入手:版本选择器只为需要公开的版本保留可抓取关系,旧版本按产品政策决定归档、迁移或保留;站内搜索表单不应批量输出无价值参数 href。选择一个目录小范围修改,记录旧版本和搜索参数请求占比、现行文档重抓、新品首次抓取、5xx 与用户任务。canonical 可继续表达代表页,但不能被当作抓取控制。若治理后分布未改变,应检查外部发现、缓存和观察窗口,而不是编造固定配额。

自评分量规

0 级仅建议提高抓取预算或反复提交 sitemap。
1 级看到旧版与搜索参数异常,但混淆 canonical 和抓取控制。
2 级提出修复链接源并比较请求分布。
3 级加入机器人验证、分模板基线、小范围发布和多个领先指标。
4 级明确尚未证实容量瓶颈,并设计反证、回滚和后续索引观察。
07

真实项目实战

把理解变成一个可以检查、复核和复用的工作产物。

FIELD LAB

诊断百万级目录的抓取浪费

新集成页平均两周才首次抓取,日志显示大量筛选和排序 URL。

  1. 取得 30–60 天去敏日志
  2. 验证搜索爬虫身份
  3. 按模板、状态和参数聚合
  4. 比较 Sitemap 新 URL 首抓延迟
  5. 治理后建立前后基线
需要交付抓取分配报告,含爬虫占比、浪费模式、发现延迟与行动。

验收条件

  • 爬虫身份经过 DNS 或官方 IP 验证
  • 高价值模板抓取份额可量化
  • 动作指向可控根因
  • 复测窗口和成功阈值明确
08

诊断练习

目标不是猜中答案,而是提出竞争假设并选择能区分它们的证据。

SCENARIO

GSC 抓取请求下降,新内容也延迟出现。

竞争假设

  1. 服务器变慢或出错
  2. 新 URL 无内链和 Sitemap
  3. 重复参数占据需求
  4. 更新时间信号不可信

应该检查的证据

  1. GSC 抓取统计和响应时间
  2. 日志中的模板请求与 5xx
  3. 首次内链到首次抓取时间
  4. lastmod 与发布记录

常见陷阱:把桌面爬虫的 URL 分布直接当 Googlebot 分布。

完成后用本页决策规则复核
  1. 若观察到:规模小、日志健康且重要页很快被抓取
    应优先:把精力转向链接、索引资格、需求和页面质量。
    以后规模或发布频率改变时再复测。
  2. 若观察到:验证机器人请求大量集中在可控参数族
    应优先:先修模板链接源,再选择适当抓取与索引治理。
    确认这些参数确实没有独立用户价值。
  3. 若观察到:5xx 与高延迟和抓取下降同时间出现
    应优先:与工程排查源站/CDN,降低错误并建立容量监控。
    时间相关不等于唯一因果,要控制发布和流量事件。
09

自测与误区

先口头回答,再展开检查。无法给出例外与证据,说明还没真正掌握。

你应该能回答

1. 规模和更新速度是否构成约束?

参考答案:先看 URL 规模、更新频率、重要页首次抓取/重抓时延、5xx 与服务器承载;如果小站重要页很快抓取,就不应优先谈预算。

为什么:预算问题必须表现为可测约束,而不是页面不收录的通用标签。

2. 真实爬虫请求花在哪?

参考答案:在验证身份后的服务器/CDN 日志中按模板、参数、状态和新鲜度聚合请求,并与 URL 业务分类连接。

为什么:模拟爬虫不能替代搜索机器人已经发出的真实请求。

3. 治理后哪个领先指标先改善?

参考答案:最先可看无价值请求占比、重要模板请求、首次抓取时延、重抓间隔和 5xx;索引与流量属于更滞后的结果。

为什么:这些指标与治理动作距离更近,也更快暴露副作用。

需要避开的误区

  • 每个网站都有严重预算问题
  • 频繁提交 URL 可长期解决延迟
  • robots 屏蔽参数会自动移除索引
10

术语与复盘

用自己的话复述术语和结论;如果只能认出、不能解释,就还没有形成可调用的知识。

Crawl capacity
站点响应能力与搜索系统资源共同形成的可承载抓取范围。
Crawl demand
已知价值、变化与陈旧等因素形成的抓取需求概念。
访问日志
服务器或边缘层记录每次实际请求的原始事件。
URL 参数族
由筛选、排序、会话等相同机制生成的一组查询串地址。
首次抓取时延
URL 发布到日志首次记录目标机器人请求之间的时间。

离开本页前记住

  1. 先证明存在约束,再研究预算。
  2. 日志回答真实请求,爬虫回答理论可达。
  3. 验证机器人身份是分析前提。
  4. 优先关闭无价值 URL 的产生源。
  5. 分布改善不等于排名因果,需继续观察。
11

资料与证据

优先采用官方和一手资料。实践材料用于补充工作方法,不替代机制证据。