KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

01 · 抓取预算的量化与优化 — keel 龙骨

本章目标：把"抓取预算有限"从一句口号，变成一套可计算、可监控、可优化的资源分配模型。验收标准：能算出你站点的每日可抓取上限、当前浪费占比，并给出优先级改造方案。

本章目标：把"抓取预算有限"从一句口号，变成一套可计算、可监控、可优化的资源分配模型。
验收标准：能算出你站点的每日可抓取上限、当前浪费占比，并给出优先级改造方案。

为什么要量化：基础课讲了"预算 = min(速率上限, 抓取需求)"，但那只是定性。要工程化，你必须回答三个数字：每天最多能被抓多少、实际抓了多少、其中多少是浪费的。没有这三个数字，所有"优化抓取"都是猜。

一、预算的两个变量，各自怎么测

1.1 抓取速率上限（Crawl Rate Limit）

这是服务端视角：爬虫多久来一次、并发多少、响应时间多长。

LOG=/var/log/nginx/learning.access.log

# 近 7 天 Googlebot 的每秒/每分钟请求量（按分钟聚合）
grep -i 'googlebot' $LOG \
  | awk -F'[:[]' '{print $2":"$3":"$4}' | uniq -c | tail -20

# 平均响应时间（若有 rt= 字段）
grep -i 'googlebot' $LOG | grep -oE 'rt=[0-9.]+' | sed 's/rt=//' \
  | awk '{s+=$1; n++} END {printf "avg=%.3fs n=%d\n", s/n, n}'

判据：若你的平均响应时间是 800ms、爬虫并发只有 2，那么理论速率上限 ≈ 2 / 0.8s = 2.5 请求/秒。这个数字就是你的"速率侧天花板"。提高它的唯一办法是降低响应时间（TTFB、动态页缓存、静态化）。

1.2 抓取需求（Crawl Demand）

这是引擎视角：它想不想抓你。需求高 = 频繁来；需求低 = 好几天来一次。

# 近 7 天 Googlebot 每日请求量，看需求是否稳定
grep -i 'googlebot' $LOG | awk '{print $4}' | tr -d '[' | cut -d: -f1 | sort | uniq -c

判据：如果每天的抓取量长期不变、且远小于"站内 URL 数 / 期望刷新周期"，说明需求侧受限——提升方式不是改服务器，而是提升内容新鲜度与重要页面的内链权重。

二、每日可抓取上限的计算

把两个变量合起来，得到一个可用的估算式：

每日可抓取上限 ≈ min( 速率上限 × 86400 , 需求驱动的实际量 )
速率上限(请求/秒) ≈ 爬虫并发 / 平均响应时间(秒)

举例：并发 3、平均响应 0.5s → 速率上限 6 请求/秒 → 理论上限 ≈ 518,400/天。若你实际每天只被抓 800 次，说明瓶颈在需求侧，而不在服务器。

# 一条命令：近 30 天每日 Googlebot 请求量
grep -i 'googlebot' $LOG | awk '{print $4}' | tr -d '[' | awk -F: '{print $1}' \
  | sort | uniq -c | tail -30

先算清瓶颈在哪侧，再决定优化方向。这是本章最重要的一条纪律：在需求侧受限的站上做"降 TTFB"是在浪费工程投入。

三、浪费占比怎么算

真正要治理的不是总量，是被浪费的比例。定义一条"有效抓取"：请求最终 URL 且返回 200 且该 URL 属于可索引集合。

# 爬虫抓取的状态码分布（越多的 3xx/4xx/5xx 越浪费）
grep -i 'googlebot' $LOG | awk '{print $9}' | sort | uniq -c | sort -rn

# 爬虫抓取中，落在参数页/分面页的比例
grep -i 'googlebot' $LOG | grep -E '\?(sort|filter|page|utm)=' | wc -l

浪费类型	日志特征	治理动作
重定向	大量 301/302	sitemap/内链直接指向终址
死链	大量 404/410	清理 sitemap 与内链
服务故障	5xx	修服务，别让爬虫反复重试
参数爆炸	大量带 `?` 的 URL	robots 屏蔽 + canonical
低价值页	抓取集中在标签/归档页	noindex 或降内链权重

分面导航是抓取预算最大的黑洞：颜色 × 尺寸 × 品牌 × 排序 × 分页 的组合可以是天文数字。

4.1 先分类，再决定

分面类型	是否有搜索价值	处理
有独立需求的组合（如"红色大号"）	有	保留，给静态 URL + 独立内容
纯排序/视图切换	无	`noindex` 或 robots 屏蔽
会话/跟踪参数	无	屏蔽
组合爆炸的中长尾	极低	屏蔽或 canonical 到主类目

4.2 三种治理手段的取舍

手段	效果	风险
`robots.txt` 屏蔽	彻底不抓	已收录的 URL 需先 noindex 再屏蔽
`noindex` + `follow`	不索引但传递链接	仍消耗抓取
`rel=canonical` 归一	权重合并	需保证规范页可索引

推荐组合：无价值分面用 robots.txt 屏蔽（但先 noindex 清存量），有价值分面给静态化 URL 并进 sitemap。

# 屏蔽纯排序与视图参数
User-agent: *
Disallow: /*?sort=
Disallow: /*?view=
Disallow: /*?sessionid=

五、抓取优先级设计

当 URL 数远超预算时，你必须主动排序：告诉引擎先抓哪些。

优先级	页面	手段
P0	首页、核心类目、高转化页	首页直达链接 + sitemap 置前
P1	更新频繁的内容页	lastmod 真实更新 + 内链
P2	长尾内容	分类页多跳可达
P3	归档/标签页	降内链权重或 noindex

两条可落地的规则：

重要页面 ≤ 3 跳可达，且从首页有直接入口。
sitemap 分组：把重要 URL 放在独立 sitemap 里并优先提交，用 <lastmod> 告诉引擎"这个真的变了"。

<!-- sitemap 里 lastmod 真实才有效 -->
<url>
  <loc>https://www.xxxxxx.cn/learning/courses/tools/lessons/1/</loc>
  <lastmod>2026-09-30</lastmod>
</url>

六、建立预算看板

把上面的指标做成一张可每周复跑的报表：

#!/usr/bin/env bash
# /usr/local/bin/crawl-budget.sh
LOG=/var/log/nginx/learning.access.log
echo "== 各爬虫近 7 天抓取量 =="
zcat -f $(ls -t ${LOG}* | head -7) 2>/dev/null | \
  grep -oiE 'Googlebot|Bingbot|Baiduspider|Bytespider|GPTBot|ClaudeBot' | \
  sort | uniq -c | sort -rn

echo "== 状态码分布（浪费识别） =="
zcat -f $(ls -t ${LOG}* | head -7) 2>/dev/null | \
  grep -i 'googlebot' | awk '{print $9}' | sort | uniq -c | sort -rn | head

echo "== 参数页占比 =="
zcat -f $(ls -t ${LOG}* | head -7) 2>/dev/null | \
  grep -i 'googlebot' | grep -cE '\?(sort|filter|page|utm)='

七、故障速查

现象	预算层原因	处理
新增页面迟迟不抓	需求侧低 / 无内链	提升内链与 sitemap 分组
抓取量大但收录少	抓的是浪费 URL	屏蔽参数页
爬虫突然降速	响应变慢或 5xx 增多	查 TTFB 与错误率
抓取停了	robots 5xx 或全站 503	恢复服务
老内容不再被重抓	lastmod 不真实	真实维护 lastmod

八、本章验收

算出速率上限（并发/响应时间）与每日实际抓取量
判定瓶颈在速率侧还是需求侧
算出浪费占比（3xx/4xx/5xx/参数页）
对分面导航做了分类治理，无价值分面已屏蔽
重要页面 ≤3 跳可达且进了优先 sitemap
预算看板脚本可复跑

# 本章核心两连
grep -i 'googlebot' $LOG | awk '{print $9}' | sort | uniq -c | sort -rn
grep -i 'googlebot' $LOG | grep -cE '\?(sort|filter|page|utm)='

预算量化完成后，下一步是让日志本身变成可查询、可告警的数据——即下一章的日志诊断工程。

进入 keel 阅读