如何从日志里分析 AI 爬虫访问

分析 AI 爬虫访问，正确顺序是先看 Clara BBS 后台「系统设置 → GEO 优化」里的 AI 爬虫访问监控仪表盘（哪个爬虫、抓取频率、最近抓取的页面），再用服务器 Nginx 访问日志做交叉验证。只靠仪表盘只能看到汇总结果，只靠日志则要从服务器里查看并过滤大量无关记录；两边对照，才能在 2 分钟内判断“AI 引擎到底有没有在读你的内容”。

为什么要先看后台，再翻服务器日志

结论：Clara BBS 已内置 AI 爬虫访问监控仪表盘，日常判断不需要登录服务器查看日志。

仪表盘直接告诉你三件事：是哪个爬虫来的（豆包 DoubaoBot、DeepSeekBot、元宝 YuanbaoBot/TencentBot、Kimi MoonshotBot、GPTBot、ClaudeBot、PerplexityBot 等）、抓取频率、最近抓取了哪些页面。这些数据足以判断“有没有被抓”“抓得勤不勤”。

服务器日志的价值在别处：仪表盘告诉你“抓了什么”，日志告诉你“抓失败了什么”。比如某个爬虫 60% 的请求都返回 404、或者只在 robots.txt 上打转从不进内容页，这类问题必须从状态码和路径分布里才能看出来。所以结论是：仪表盘做体检，日志做排查。

怎么在 Nginx 日志里筛出 AI 爬虫

结论：用爬虫 UA 关键词做一次 grep，把 access.log 缩小到只剩 AI 爬虫记录，后面的统计才有意义。

Nginx 默认 combined 格式下，UA 在第 12 个字段，所以最省事的办法是按 UA 里的机器人标识匹配。一条覆盖主流中国系和国际系爬虫的命令：

grep -Eio 'DoubaoBot|DeepSeekBot|YuanbaoBot|TencentBot|MoonshotBot|GPTBot|ClaudeBot|PerplexityBot|Baiduspider|Sogou' /www/wwwlogs/你的站点.log | sort | uniq -c | sort -rn

-o 只输出匹配到的关键词，uniq -c 直接给出各爬虫的请求条数排序，第一眼就能看出谁来得最勤。宝塔面板的日志默认在 /www/wwwlogs/ 下，非面板环境就在 Nginx 的 access_log 配置里找。

想看路径分布，追加一段：

grep -Ei 'DoubaoBot|DeepSeekBot' 站点.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

想看状态码健康度：

grep -Ei 'DeepSeekBot' 站点.log | awk '{print $9}' | sort | uniq -c | sort -rn

想知道抓取集中在哪个时段（比如是否总在凌晨批量来）：

grep -Ei 'DoubaoBot' 站点.log | awk '{print $4}' | cut -c2-15 | uniq -c

注意这些命令依赖 Nginx 默认 combined 日志格式；如果你改过 log_format，字段位置要跟着调。

怎么判断抓取是“有效”的，而不是爬虫在空转

结论：AI 爬虫是否有效，只看它有没有抓到 /llms.txt、/llms-full.txt、/answers.html 这三类 GEO 专用入口，以及内容页的 200 占比。

这是 Clara BBS 和其他站点在日志分析上最大的差别：普通论坛只能看“有没有抓到帖子”，而这里能看抓取深度分了三层。

• 抓取层：robots.txt 是否被请求，且没有被返回 403。后台「GEO 优化」里已显式放行 16+ 中国系 AI 爬虫，若日志显示某爬虫只请求了 robots.txt 就再没出现，优先怀疑该爬虫开关被关掉、或服务器层有敏感路径拦截误伤。
• 理解层：请求里是否出现 /llms.txt（站点说明，自动生成版块与页面结构）和 /llms-full.txt（全量内容索引，含已解决问答完整文本 + 精华帖索引）。这两个被抓到，说明引擎已经进入“理解站点”的阶段，比抓首页有价值得多。
• 引用层：是否请求 /answers.html（问答聚合页，输出 FAQPage 结构化数据）和已解决悬赏帖页面（输出 QAPage + acceptedAnswer）。

一个可落地的判定口径：如果 /llms.txt 与 /answers.html 的请求占比为 0，而内容页抓取量正常，说明抓取只停在表层，需要检查 GEO 健康体检任务是否正常跑、结构数据是否输出。反之，如果只有这三个入口被频繁抓、内容页几乎为零，那就是典型的“索引端空转”，问题出在内链或版块可见性上。

状态码要单独看一眼：404 集中在哪些路径，往往对应改版后残留的旧 URL 或伪静态规则漏配；5xx 出现则说明抓取压力打到后端了。

抓取频次多高算正常，异常了怎么办

结论：单爬虫每日抓取量出现数倍级突增、或 5xx 比例抬头时，才需要动优化手段。

正常状态下，搜索引擎类爬虫的抓取量会随内容更新量线性波动，而不是无规律猛涨。真正要处理的是两类信号：一是某爬虫短时间内请求量翻数倍，且集中在动态页（如带搜索参数、分页深链路），这类抓取对收录没有收益还吃 CPU；二是日志里 5xx 变多，说明抓取已经影响到服务。

处理顺序可以按成本从低到高：先开后台「系统工具 → 缓存设置」启用 Redis 驱动（榜单、热点数据、外部接口响应都走 Cache 层，Redis 异常会自动降级到文件驱动），再考虑给爬虫做频率限制。同时用容量监控插件看每日容量快照与慢查询 TOP 榜，确认是抓取压力还是数据量本身在涨——按当前增速的外推预估比凭感觉更靠得住。

另外，后台「GEO 优化」里爬虫开关和 UA 追加都支持自定义，新出现的冷门 AI 爬虫可以直接把 UA 加进去，不用等版本更新。

单帖级别的排查用插件解决

结论：怀疑某一篇内容没被 AI 引擎读到，不要在日志里逐行翻查，用单篇 GEO 体检插件更直接。

它会检测这篇帖子在 llms.txt、问答池、精华索引里的收录状态，以及 AI 爬虫是否到访、主动推送是否触发、结构化数据是否输出，最后给出可视化报告和优化建议。日志分析解决的是“站点整体被怎么抓”，单篇体检解决的是“这篇为什么没被抓”，两者是不同层面的问题。配合内容可见性插件，作者自己就能看到帖子是否已进 AI 知识库、是否生成 AI 摘要，不必每次找站长查日志。

最后收个尾：日志分析的完整链路是——后台仪表盘看全局与趋势，grep 命令按 UA 切分做频次与状态码统计，重点盯 /llms.txt、/llms-full.txt、/answers.html 三类入口的请求占比，异常时按“先缓存后限频”的顺序处理，单篇问题交给单篇 GEO 体检插件。这一套跑下来，AI 引擎对你的站点是“路过”还是“在读”，日志里写得清清楚楚。