很多站点把服务器日志当成出故障时才翻的排错工具，平时任其滚动覆盖。其实日志里藏着搜索蜘蛛最真实的访问记录：它几点来、来过多少次、抓了哪些地址、拿到的是 200 还是 404、响应花了多久。把这些记录定期看一遍，比凭感觉猜抓取情况要靠谱得多。
第一步：先确认日志拿得到、留得住
不同环境的日志位置不一样，先弄清楚自己的：
- Nginx：通常在 /var/log/nginx/ 下，按站点或按域名分文件；
- Apache：access_log 与 error_log 分开，注意虚拟主机配置里的路径；
- 宝塔等面板：一般在网站日志入口，可下载或按天查看；
- 套了 CDN 或反向代理：源站日志可能只有回源请求，蜘蛛的真实访问在 CDN 侧的日志里，需要去那边取。
还要定一个保留周期。日志按天切割、至少留 30 天，才有办法对比“这周和上周有什么变化”。如果磁盘紧张，可以只保留访问日志中的关键字段，或定期导出压缩包另存。
关键字段：先看这几列
日志一行里字段很多，自查阶段不必全看，重点盯这几列：
- 时间：判断抓取是否集中在某个时段；
- UA（User-Agent）：区分不同搜索引擎的蜘蛛，也用来识别伪装爬虫；
- URL 与状态码：抓了什么、结果如何；
- 响应字节数与耗时：大页面、慢接口往往在这里露头。
从记录里能看出什么
状态码分布是否正常
把蜘蛛请求按状态码分组统计。健康情况下以 200 和 304 为主。如果 404 占了很大比例，说明站内还有一批失效地址在持续消耗抓取；如果 5xx 反复出现，先查服务器和应用，别急着改内容；如果出现大量连环跳转，那说明跳转链条需要梳理。
抓取集中在哪些地址
统计被访问次数最多的 URL。常见有两种情况：一种是列表页、筛选页、带参数的搜索页被反复抓，正文页反而很少；另一种是几个栏目页撑起大部分抓取。前一种要考虑给参数页加限制或收敛入口，后一种要检查内容是不是更新太慢、内链是不是没把蜘蛛引向新内容。
重要页面有没有被访问过
把核心栏目和近期新发布的页面整理成一份清单，去日志里搜一遍。如果新页面在发布后较长时间内一次都没出现，问题通常不在内容本身，而在入口：没有内链指向、没有进站点地图、所在目录层级太深，或者被某条规则挡住了。
蜘蛛类型与频次
不同搜索引擎的蜘蛛来访节奏不同。同时要留意两类异常：一是某个 UA 的请求量远超正常水平，可能是采集或压测；二是“自称蜘蛛”但访问路径杂乱、频率机械的请求，可以用反向解析或官方 IP 段核对。核对之后，再决定是限速还是直接拒绝。
几个容易踩的坑
- 只看总量不看结构：总请求数涨了不代表抓取变好，可能是无效地址变多了；
- 用第三方工具替代日志：工具方便，但采样和口径各不相同，遇到争议时还是要回到原始日志；
- 忽略日志体积：大站日志增长很快，提前配好切割和清理，别等磁盘满了才处理；
- 把 IP 当身份：同一 IP 可能承载多种请求，判断身份要结合 UA 与反向解析；
- 忽视合规：日志里含访问者 IP 等信息，导出、共享和保留期限要符合自身合规要求。
把自查变成固定动作
不必每天都细看，可以分两层：每天扫一眼状态码里的 5xx 和突增的 404；每周抽一次完整日志，看看抓取排名前十的地址、新页面有没有被访问、跳转链条有没有变长。记录下每次的结论和改动，下次对比时才有参照。
日志是结果，不是原因。看到异常先问三件事：是不是入口变了、是不是规则拦了、是不是服务器慢了。找到原因再动手，比反复提交地址有效得多。
最后提醒一句，日志自查解决的是“看得见”的问题。它不会让页面自动被收录，也不保证排名，但能帮你把明显浪费抓取、挡路的地方先清理掉，让后续的运营动作更有针对性。