简介这是一款面向网站运维者与SEO人员的蜘蛛日志在线分析工具源码核心解决手动翻阅网站日志、难以快速定位百度等搜索引擎爬虫抓取行为的问题。使用时将Linux宝塔面板中wwwlogs目录下的访问日志内容粘贴到工具左侧点击分析按钮即可获得爬虫抓取记录操作直观。压缩包内共105个文件其中HTML页面与JS脚本构成主要交互逻辑CSS负责界面样式同时配有大量JPG、GIF、PNG图标素材以及txt说明文档整体仅1.47MB部署轻量适合直接放入个人工具站或本地打开使用。资源目前已有89人学习下载。通过这份源码读者可获得一套可运行的前端日志分析面板也能借鉴其中针对日志文本做正则提取、数据分类与结果展示的编程思路对于想要掌握前端实用工具开发、搭建爬虫监测辅助功能的开发者而言具有不错的参考与二次开发价值。1. 蜘蛛日志在线分析工具把宝塔 wwwlogs 变成一眼能看懂爬虫动作的界面做 SEO 的人每天打开服务器第一件事就是看搜索引擎蜘蛛来没来、抓了多少页、哪些页返回了 404。云服务商的统计后台能看流量但看不到蜘蛛抓取的细节路径。这款蜘蛛日志在线分析工具解决的就是这个把宝塔面板 wwwlogs 目录下的网站访问日志复制进左侧文本框点一下分析藏在几十 MB 日志里的爬虫抓取记录就被筛出来了。它适合三类人用 Linux 宝塔面板的站长、整天和百度蜘蛛 Googlebot 打交道的 SEO 从业者、以及不想装第三方统计、只想在自己服务器上看一眼真实抓取数据的运维。Windows 服务器用户先注意宝塔在 Windows 上的日志机制和 Linux 不一样后面会细说。2. 日志与蜘蛛识别从 wwwlogs 文件到 User-Agent 判定2.1 日志文件在哪wwwlogs 目录与按天切割的历史日志宝塔 Linux 面板装完 Nginx 或者 Apache 后站点访问日志统一放在/www/wwwlogs目录下。默认情况下每个站点会有一个以域名命名的.log文件这就是主日志。比如你的站是example.com那文件就是example.com.log路径是/www/wwwlogs/example.com.log。如果配置了按天切割还会看到example.com-2025-02-18.log这种带日期的历史文件以及example.com.error.log这种错误日志。实操上我一般先确认这个目录里有哪些文件再决定粘哪个进去ls -lh /www/wwwlogs/ tail -n 20 /www/wwwlogs/example.com.logls -lh能看出日志格式和大小tail则是瞄一眼最新几行日志确认格式对不对。很多新手上来就把example.com.error.log当成访问日志粘进工具结果分析出来全是 500 和 404 错误记录。注意蜘蛛抓取记录全部在访问日志里也就是 access log不是 error log。这个工具吃的是wwwlogs里的访问日志原文。宝塔默认的 access log 是 Nginx 的 combined 格式一行一条记录包含了客户端 IP、访问时间、请求方法、请求路径、状态码、页面大小、来源页面和 User-Agent。这些字段正好是这个源码能分析出蜘蛛结果的基础。2.2 User-Agent 是蜘蛛的唯一身份证判断一条日志是不是蜘蛛靠的不是 IP而是日志最后面的 User-Agent简称 UA。百度的蜘蛛 UA 里必然带Baiduspider谷歌的带Googlebot必应带bingbot搜狗带Sogou web spider字节跳动的带Bytespider或bytedance。蜘蛛类型UA 关键字百度Baiduspider谷歌Googlebot必应bingbot搜狗Sogou web spider字节跳动Bytespider360360Spider神马YisouSpider我一般记这些关键字就够了因为这款日志分析工具本质上就是拿这些关键字去和日志里的 UA 字段做匹配。为什么不用 IP 判断搜索引擎蜘蛛的 IP 是动态的同一个蜘蛛今天可能从这个 IP 段来明天就从另一个 IP 段来而且很多站点前面还套了 CDN真实 IP 根本不是客户端的。UA 写在 HTTP 请求头里关键词稳定匹配起来最可靠。有些日志分析工具会做成 IP 反查库的形式那种方案很重还得维护 IP 段数据。这个源码选择了经典的关键词匹配轻量、实用服务器上跑起来没有任何额外依赖。2.3 一行日志怎么读时间、请求、状态码和 UA 的位置拿一条宝塔默认格式的日志举例这是百度蜘蛛真实抓取时留下的记录223.104.67.12 - - [18/Feb/2025:02:15:33 0800] GET /archives/1024.html HTTP/1.1 200 15234 https://www.example.com/archives/ Mozilla/5.0 (compatible; Baiduspider/2.0; http://www.baidu.com/search/spider.html)拆开看223.104.67.12是访问者 IP[18/Feb/2025:02:15:33 0800]是访问时间GET /archives/1024.html HTTP/1.1是请求方法和路径200是状态码15234是返回内容大小https://www.example.com/archives/是来源页面最后那对引号里就是 User-Agent。从这条日志能读出三层信息百度蜘蛛在 2 月 18 日凌晨访问了文章页、服务器正常返回了 200、页面大小 15KB。把所有日志按 UA 关键字一筛再按日期一聚合蜘蛛一天来了多少次、几点来、抓了哪些页面、有没有抓到 404全都清楚了。这个源码做的事情本质上就是把上面这个手读日志的过程自动化。它的解析逻辑并不复杂难点在于日志格式发生变化时还能不能正确匹配这是后面避坑章节的重头戏。3. 部署与使用这套源码文件结构、运行环境与三分钟出结果3.1 源码包里有什么样式表、UI 切图与藏在后面的主脚本压缩包解压之后会看到一批文件和图片比如style.css、2014.css、web_style.css、flash.css是样式表负责页面外观left.gif、r2_c2.gif、ser_r38_c5.gif、ser_r40_c5.gif这些是页面切图包括背景图和按钮图。从这些命名风格能看出来这套东西完全够用但界面设计停留在早期网页模板的观感上不影响功能。真正干活的脚本一般是一个单独的 PHP 文件放在压缩包根目录。这类工具常见结构就是一个入口文件页面框架、日志解析逻辑、结果渲染全在一个文件里完成样式文件只是让页面更好看。要确认哪些是主脚本看文件大小就行通常几 KB 到十几 KB 的 PHP 文件就是图片和 CSS 大多只有几百字节。文件类型作用.css文件控制页面布局、配色、表格样式.gif图片按钮、分隔线、背景等 UI 元素.php主脚本接收日志、匹配 UA、输出分析结果3.2 部署本地跑通最快服务器部署也不难这个工具对运行环境的要求很低一个支持 PHP 的 Web 环境就够了不需要数据库不需要 Composer不需要扩展库。最常见的两种跑法一是本地用 phpstudy 或者 XAMPP 搭个环境把解压后的文件夹丢到网站根目录访问http://localhost/解压目录名/就能打开页面二是直接扔到宝塔面板里新建一个站点把文件放进去访问站点域名即可。我本地调试时习惯用 PHP 内置的开发服务器一条命令就能起服务cd /path/to/spider-log-analyzer php -S 127.0.0.1:8080然后浏览器打开http://127.0.0.1:8080。php -S是 PHP 自带的简单 Web 服务器127.0.0.1:8080表示监听本机 8080 端口适合做功能验证。这个命令不依赖 Nginx 或 Apache也不用配虚拟主机是测试工具类脚本最省事的办法。确认页面能打开后再考虑是不是要挪到正式服务器上。宝塔上部署更简单在 www 目录下新建一个目录上传源码文件然后在新站点或已有站点的根目录里引用这个目录。因为纯 PHP 脚本没有跨域和权限问题访问入口文件就能用。3.3 使用流程粘贴日志、点剖析、读结果工具界面是典型的左右两栏布局。左侧是一个大文本框下面有剖析按钮右侧是结果区展示分析出来的蜘蛛记录。我用过一次就摸清了流程总共三步。第一步把日志拿进文本框。在宝塔文件管理里直接打开wwwlogs下的站点日志全选复制或者用命令行把日志内容读出来cat /www/wwwlogs/example.com.log提示日志文件很大时不要全选复制先用tail -n 1000截取最近一千行这样浏览器不会卡速度也快。第二步粘贴到左侧文本框点击剖析按钮。源码会逐行读取粘贴进来的内容对每行日志做正则匹配。匹配到蜘蛛 UA 的保留下来没匹配到的普通访问直接忽略。第三步读取右侧结果。输出信息大致包括蜘蛛类型、抓取数量、抓取时间、访问的 URL 路径、返回状态码。比如能看到这样一组结果蜘蛛类型抓取次数状态码 200状态码 404Baiduspider1261188Googlebot23230bingbot990这组数据反映的是这段时间内百度蜘蛛来得最勤但抓出了 8 个 404 页面说明站点里存在失效链接需要处理。Google 和必应抓取量不大属于正常收录状态。3.4 核心解析逻辑这类工具背后都在做同一件事拿到工具后想改蜘蛛名单或者想加上对某个新搜索引擎的支持得先明白它的解析逻辑。这类工具的核心代码简化后跟下面这个片段基本一致?php // 蜘蛛类型与 UA 关键词对照按需增删 $spiderRules [ 百度 Baiduspider, 谷歌 Googlebot, 必应 bingbot, 搜狗 Sogou web spider, 字节 Bytespider, 360 360Spider, ]; // 接收前端粘贴的日志按行拆分为数组 $logLines explode(\n, trim($_POST[log])); foreach ($logLines as $line) { // 匹配 UA 字段里的蜘蛛关键词 $isSpider false; foreach ($spiderRules as $name $keyword) { if (strpos($line, $keyword) ! false) { $isSpider true; break; } } if (!$isSpider) { continue; } // 提取时间、请求路径、状态码 preg_match(/\[(\d{2})\/(\w{3})\/\d{4}:(\d{2}:\d{2}:\d{2})/, $line, $timeMatch); preg_match(/[A-Z] ([^]) HTTP/, $line, $pathMatch); preg_match(/ (\d{3}) /, $line, $statusMatch); // 按日期聚合计数 $stat[$timeMatch[3]][$name][count]; if (isset($statusMatch[1])) { $stat[$timeMatch[3]][$name][status][$statusMatch[1]]; } }代码里explode(\n, ...)负责把粘贴进来的日志文本拆成数组一行一个元素。strpos($line, $keyword)是核心判断只要这一行包含任一蜘蛛 UA 关键词就被认定为蜘蛛记录。后面的三个正则分别抽取时间、请求路径和状态码$stat数组按“日期→蜘蛛类型→计数”的层级聚合结果最后在页面上渲染成表格。这段逻辑有两个参数值得留意。第一个是$spiderRules数组以后有新搜索引擎上线在这里追加一行即可。第二个是状态码匹配的正则 (\d{3}) 它依赖日志格式中状态码前后各有一个空格如果日志格式不是标准 combined这个正则就会失效出现一条蜘蛛都分析不出来的情况。遇到这种问题直接检查那三行正则比检查逻辑更重要。4. 避坑与排查从日志复制不全到蜘蛛被误判的四个真实问题4.1 复制日志不全分析结果直接腰斩现象工具能正常出结果但统计出来的蜘蛛抓取数和站点实际流量严重不符有时候一天明明有上百次百度抓取工具只统计出二十几次。原因日志文件大的时候编辑器打开会截断内容或者用鼠标全选复制实际选中的只是屏幕里的部分内容不是全部文件。分析工具吃进去的数据不完整结果自然少。解决用命令行截取日志完全可以避开编辑器这个瓶颈。比如想看最近两千行里蜘蛛的情况tail -n 2000 /www/wwwlogs/example.com.log /tmp/spider_sample.log然后把/tmp/spider_sample.log的内容粘进工具分析。这就是样本大小可控出错概率也小。4.2 UA 被伪装统计里全是“假蜘蛛”现象日志分析结果显示 Googlebot 抓取量爆增一天几万次但站点根本不会有这么多真实收录请求。原因有恶意爬虫伪装成搜索引擎蜘蛛的 UA 来扫站。它们把 UA 改成Mozilla/5.0 (compatible; Googlebot/2.1; http://www.google.com/bot.html)和真蜘蛛长得很像这类工具按关键词匹配肉眼完全看不出来。解决一是看来源 IP 是否来自搜索引擎官方网段。百度蜘蛛 IP 段基本都能反查出baidu.com域名Googlebot 的反查结果会落在googlebot.com。二是看抓取行为真蜘蛛会遵守 robots.txt访问间隔有规律恶意爬虫往往在一秒内连续抓取几十个页面。4.3 日志格式不是默认格式正则全部落空现象粘了一大段日志进去工具一条蜘蛛都识别不出来或者结果里全是乱码。原因站长改过 Nginx 的 log_format日志字段顺序和宝塔默认的 combined 格式不一样。比如有人把日志格式自定义成只保留 IP、时间和请求把最终 UA 放在中间位置或者使用了 JSON 格式日志。工具的解析正则按UA在最后一对引号的默认格式写格式变了匹配不上。解决先看一行日志和默认格式比对tail -n 1 /www/wwwlogs/example.com.log如果日志格式里 UA 仍然存在只是字段顺序打乱那就去修改源码里的三个正则把提取时间和 UA 的匹配逻辑换一下。如果已经完全改成 JSON 格式建议先去宝塔设置里把日志格式改回默认再使用这个工具。4.4 粘贴几十 MB 日志浏览器和服务器双双卡死现象日志文件超过 20MB全选复制粘贴到文本框后浏览器卡住不动或者点剖析后页面长时间白屏。原因文本域渲染超大的纯文本本身就吃浏览器内存PHP 端逐行解析几十万行日志也吃服务器内存。两边同时拉满页面就挂了。解决按天切割日志分批分析。宝塔默认日志不切天的话就用命令行先按日期筛出来grep 18/Feb/2025 /www/wwwlogs/example.com.log /tmp/spider_0218.log这样就只剩 2 月 18 日当天的记录文件体积和行数都小得多粘贴和解析都不会卡。想看整周的数据就多跑几次或者把每天的统计结果自己在表格里汇总一下。5. 验证与进阶用命令行复核结果再把蜘蛛统计变成每天自动跑的日报5.1 用 grep 复核分析结果工具跑出结果后先用最笨的方法验证一遍心里才有底。命令行的 grep 不依赖任何脚本纯字符匹配是最可靠的对照标准。把同一段日志复制出来直接用 grep 统计各类蜘蛛出现次数grep -c Baiduspider /tmp/spider_sample.log grep -c Googlebot /tmp/spider_sample.log-c参数只输出匹配的行数不打印具体内容。如果 grep 统计的百度蜘蛛行数和工具输出的结果一致说明工具解析正常如果差别大优先怀疑工具的正则匹配在日志格式上出了问题而不是怀疑数据本身。还可以进一步看每一种蜘蛛抓了哪些页面、这几个关键字抓了多少次grep -oE Baiduspider|Googlebot|bingbot|Bytespider /tmp/spider_sample.log | sort | uniq -c | sort -rngrep -oE只打印匹配到的关键词本身sort排序后交给uniq -c统计每一类出现的次数最后按数量倒序排列。一条命令就能看到样本日志里哪种蜘蛛最活跃方便和工具结果对照。5.2 把蜘蛛统计变成每天自动跑的日报手工把日志粘进网页只能算是临时看一次。想长期监控蜘蛛抓取变化我的习惯是在服务器上写一个极简脚本按天统计蜘蛛记录然后定时跑每天早晨直接看结果文件就行#!/bin/bash LOG/www/wwwlogs/example.com.log DATE$(date -d yesterday %d/%b/%Y) OUT/www/wwwlogs/spider_report.txt grep $DATE $LOG | grep -oE Baiduspider|Googlebot|bingbot|Sogou web spider|Bytespider | sort | uniq -c | sort -rn $OUT拿到每日统计后再用crontab -e添加一行定时任务每天凌晨 2 点跑一次。这样到的不是某个时间点的快照而是每天固定的抓取报告连续看一周就能发现蜘蛛来你站点的趋势变化也是在没装第三方统计的前提下最轻量的监控手段。5.3 顺手把伪装蜘蛛的恶意请求挡在门外能识别蜘蛛 UA 之后还能把明显伪造 UA 的请求拦在服务器之外。真实搜索引擎 UA 里会带文档说明地址比如百度的 UA 必带http://www.baidu.com/search/spider.html。遇到 UA 写着 Googlebot 但来路明显异常的可以在 Nginx 站点配置里加一层判断if ($http_user_agent ~* Baiduspider|Googlebot|bingbot) { # 这里只做标记不直接 deny避免误杀真实蜘蛛 access_log /www/wwwlogs/fake_spider.log combined; }实际使用中我会先观察一段时间确认哪些 IP 频繁伪装蜘蛛 UA再用防火墙规则单独屏蔽。直接 deny 所有蜘蛛 UA 的做法风险很大真实蜘蛛会被拦截导致搜索收录出问题。第一次配置时记着先在测试站点试玩再搬到正式环境。一台服务器跑久了总会遇到日志分析工具查不出真相的时候。有一回我以为站点被 Googlebot 狂抓兴奋地打开工具想看看抓了哪些页面结果发现全是一个恶意 IP 用假 UA 在扫后台路径。从那以后我每次做蜘蛛分析都把“先 grep 一下 UA 关键字、再看一眼来源 IP”强制走一遍流程先验证再下结论这习惯帮我挡掉了不少误判。希望帮到你。本文还有配套的精品资源点击获取
