简介：这是一款面向网站运维者与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.log

ls -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 字段做匹配。为什么不用 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 大多只有几百字节。

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 路径、返回状态码。比如能看到这样一组结果：

这组数据反映的是：这段时间内百度蜘蛛来得最勤，但抓出了 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 -rn

grep -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”强制走一遍流程，先验证再下结论，这习惯帮我挡掉了不少误判。希望帮到你。

本文还有配套的精品资源，点击获取