报错是这么冒出来的。站点两万页面每天被蜘蛛请求五万次，日志里 304 占 92%，新文章一天只被抓二十条，抓取预算看着被这些没有变化的请求吃掉了。
中间走过弯路，把「sitemap 的 lastmod 每天全量刷新，诱导蜘蛛重抓」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。列表页每小时更新但正文没变，蜘蛛反复回访只拿到 304。也可能是Last-Modified 按渲染时间生成，每次请求都不同，校验失效。
少数情况下是最新文章模块让每个页面都带上了当天时间。
算 304 的占比和 URL 分布
awk '$9==304 {print $7}' access.log | sort | uniq -c | sort -rn | head再往下检查响应里的缓存校验头
curl -sI https://www.example.com/a/1 | grep -Ei 'last-modified|etag'然后把 Last-Modified 固定为内容修改时间
add_header Last-Modified "$date_gmt";等前面都确认过，再确认 sitemap 只输出有变更的页面
curl -s https://www.example.com/sitemap.xml | grep -c lastmod怎么算真的好了，看的是同一批现象。304 占比降到五成以下，新文章当天被抓取的比例提升，日志里同一 URL 的重复请求明显减少。
304 本身不是坏事，说明缓存有效，问题是占比过高时抓取预算都花在确认没变上。这类问题最好一次改到位，反复小改反而容易把原因搅混。