1. 为什么要在WordPress里自己动手做访问日志很多人用WordPress建站之后第一反应是装个统计插件看流量。但用久了就会发现两个问题一是插件把数据存在自己数据库里页面一多数据库就臃肿得不行二是插件给的数据太加工过了你根本看不到原始请求长什么样。尤其是做SEO或者排查异常流量的时候你真正需要的是服务器级别的原始访问记录——谁在什么时间、用什么方式、请求了哪个URL、返回了什么状态码、用的什么User-Agent。这就是网站访问日志和蜘蛛爬行分析日志要解决的事。前者记录所有访客的请求明细后者专门把搜索引擎爬虫的访问行为单独拎出来分析。两者结合你能回答很多插件答不上来的问题某个栏目页到底被爬了多少次爬虫抓取频率是不是异常404页面是不是被反复请求某个IP是不是在恶意扫描WordPress本身跑在PHP环境里它不像Nginx或Apache那样天然有access log。所以我们要做的事情本质上是在WordPress这一层拦截每一次请求把关键信息写进独立的日志文件。这样做的好处是日志格式完全由你定义想记什么就记什么而且不占用数据库。适合有一定动手能力、愿意折腾服务器、对数据有掌控欲的站长和开发者。下面我把整套方案从原理到落地拆开讲包括我踩过的坑。2. 日志方案的整体设计在哪一层拦截请求最合适2.1 WordPress请求生命周期里的三个可插入点要记录访问日志先得搞清楚一次WordPress请求是怎么走完的。简化来说分三段Web服务器接收请求Nginx/Apache→ PHP初始化并加载WordPress核心 → WordPress执行主题和插件逻辑 → 返回响应。可插入日志逻辑的位置有三个Web服务器层直接改Nginx的access_log配置。优点是性能最好、记录最全连静态文件都记缺点是拿不到WordPress的上下文比如这个请求最终对应哪个文章ID、用户是否登录它不知道。PHP入口层在index.php或wp-config.php最前面加代码。优点是能拿到几乎所有信息且在任何插件加载前就执行缺点是如果PHP本身没跑起来比如502这条请求就记不到。WordPress钩子层用init或wp这类action钩子。优点是能拿到完整的WordPress环境能判断当前是文章页还是分类页缺点是钩子触发时有些早期请求已经被处理了而且钩子执行时机偏晚。我的选择是PHP入口层 WordPress钩子层结合。入口层负责记录最基础的请求信息时间、IP、URL、UA、状态保证不漏钩子层负责补充WordPress上下文文章ID、页面类型、登录用户。这样既保证了完整性又拿到了业务信息。2.2 为什么不用数据库存日志这是很多人会走弯路的地方。我一开始也想过建个自定义表存日志后来放弃了原因有三个第一写入压力。每次请求都往数据库写一条高流量站点数据库连接会被日志写入拖垮。日志是写多读少的场景用数据库是杀鸡用牛刀。第二数据膨胀。一个日访问几千IP的站一个月日志轻松上百万条数据库备份和查询都会变慢。第三分析不便。日志分析往往要用grep、awk这类命令行工具做快速过滤存成文本文件直接就能处理存数据库反而要多写一层查询。所以最终方案是写独立的文本日志文件按天切割格式用管道符或制表符分隔方便后续用脚本解析。2.3 日志文件放哪里才安全日志文件绝对不能放在网站根目录下能被公网访问的地方。我见过有人把access.log放在wp-content里结果被人直接下载走了全部访问记录包括后台登录路径。正确做法是放在Web根目录之外比如/var/log/wp-site/或者站点目录的上一级。如果服务器权限受限只能放在站点目录内那必须在Web服务器配置里显式禁止访问.log后缀文件。Nginx里加一段location ~* \.(log|txt)$ { deny all; }注意日志文件里会包含访客IP和User-Agent属于个人信息范畴不要随意公开分享或长期无期限保存建议定期归档或清理。3. 核心实现把每次请求写进日志文件3.1 入口层拦截代码的写法在WordPress根目录的wp-config.php最顶部?php之后、任何require之前插入日志记录逻辑。为什么放这么靠前因为要保证即使后面WordPress加载出错这次请求也能被记下来。核心思路是拿到$_SERVER里的请求信息拼成一行追加写入文件。关键字段包括时间戳精确到秒访客IP要考虑反向代理的情况请求方法GET/POST请求URIHTTP状态码这个在入口层拿不到需要后续补充User-Agent来源Referer这里有个大坑获取真实IP。如果站点前面有CDN或反向代理$_SERVER[REMOTE_ADDR]拿到的是代理的IP不是访客真实IP。这时候要看HTTP_X_FORWARDED_FOR或HTTP_X_REAL_IP。但这两个头是可以伪造的所以不能无脑信任。我的做法是先判断REMOTE_ADDR是否在可信代理IP段内是的话才取X_FORWARDED_FOR的第一个IP否则直接用REMOTE_ADDR。function get_real_ip() { $trusted_proxies [127.0.0.1, 10.0.0.0/8]; $remote $_SERVER[REMOTE_ADDR] ?? 0.0.0.0; if (isset($_SERVER[HTTP_X_FORWARDED_FOR])) { $ips explode(,, $_SERVER[HTTP_X_FORWARDED_FOR]); $first trim($ips[0]); if (filter_var($first, FILTER_VALIDATE_IP)) { return $first; } } return $remote; }3.2 状态码怎么补用shutdown函数兜底入口层执行时HTTP状态码还没确定因为WordPress后面可能设置404、301等。解决办法是用register_shutdown_function注册一个在脚本结束时执行的回调这时候http_response_code()能拿到最终状态码。但这里有个细节如果日志是在入口层就写好了状态码是空的怎么办我的方案是先写一行占位在shutdown时再补。不过这样会有并发写同一行的问题。更简洁的做法是整个日志写入都放到shutdown函数里入口层只负责把需要的数据存到全局变量。这样一次写入搞定状态码也准。$GLOBALS[wp_log_data] [ time date(Y-m-d H:i:s), ip get_real_ip(), method $_SERVER[REQUEST_METHOD] ?? -, uri $_SERVER[REQUEST_URI] ?? -, ua $_SERVER[HTTP_USER_AGENT] ?? -, ref $_SERVER[HTTP_REFERER] ?? -, ]; register_shutdown_function(function () { $data $GLOBALS[wp_log_data]; $data[status] http_response_code(); $line implode(\t, $data) . \n; $file /var/log/wp-site/access- . date(Y-m-d) . .log; file_put_contents($file, $line, FILE_APPEND | LOCK_EX); });LOCK_EX这个参数很关键高并发下多个请求同时写文件不加锁会出现内容交错、日志行错乱的问题。我早期就吃过这个亏日志里出现半行半行拼接的乱码排查了半天才发现是并发写。3.3 按天切割与自动清理日志文件按天命名access-2025-01-01.log天然实现了切割不需要额外的logrotate。但清理得自己管否则磁盘迟早被撑满。我一般保留30天用一个简单的定时任务处理find /var/log/wp-site/ -name access-*.log -mtime 30 -delete挂到crontab里每天凌晨跑一次。这里要注意-mtime 30是按修改时间算的如果某天的日志文件当天之后就没再写过30天后会被删掉符合预期。提示如果站点流量很大单日日志可能几百MB建议在写入前判断文件大小超过阈值就换一个带序号的文件名避免单个文件过大影响后续分析。4. 蜘蛛爬行日志从访问日志里把爬虫捞出来4.1 识别主流搜索引擎爬虫的UA特征蜘蛛日志本质上不是单独记录的而是从全量访问日志里按User-Agent筛选出来的。所以第一步是搞清楚主流爬虫的UA长什么样。常见的几类爬虫类型UA关键词说明通用搜索Googlebot谷歌搜索通用搜索Bingbot必应搜索通用搜索Baiduspider百度搜索通用搜索YandexBot俄语区搜索社交抓取facebookexternalhit社交平台预览内容聚合Bytespider字节系抓取筛选逻辑很简单用正则匹配UA即可。但这里有个必须注意的坑UA是可以伪造的。有些采集程序会把自己的UA伪装成Googlebot实际行为却是疯狂抓取。所以光看UA不够还要结合反向DNS验证——真正的Googlebot它的IP反查域名应该以.googlebot.com或.google.com结尾。不过反向DNS验证每次请求都做会拖慢速度我的做法是先按UA筛出来再离线批量验证IP。日志分析本来就是事后行为不需要实时验证。4.2 用命令行快速提取蜘蛛日志假设全量日志是制表符分隔的UA在第5列那么提取所有Googlebot的记录awk -F\t $5 ~ /Googlebot/ {print} access-2025-01-01.log spider-google-2025-01-01.log想统计每个爬虫抓了多少次awk -F\t {print $5} access-2025-01-01.log | grep -oE Googlebot|Bingbot|Baiduspider|YandexBot | sort | uniq -c | sort -rn这几条命令我几乎每天都在用比任何插件都快。awk按列处理文本的效率极高几百万行的日志几秒钟就能跑完。4.3 爬行分析真正要看的四个指标把蜘蛛日志单独存下来只是第一步真正有价值的是分析。我通常关注四个维度抓取频次某爬虫一天抓了多少次。如果突然暴涨可能是站点被判定为高价值也可能是被恶意爬取。抓取深度爬虫访问的URL层级分布。如果它只抓首页和列表页不抓详情页说明内链结构有问题。状态码分布爬虫拿到的404、500多不多。404太多说明有大量死链500说明服务器不稳定都会影响收录。抓取时间分布爬虫集中在哪个时段来。如果和你自己的备份、统计任务撞在一起服务器压力会叠加。这四个指标用awk配合sort、uniq就能算出来不需要任何可视化工具。比如统计状态码分布awk -F\t {print $7} spider-google-2025-01-01.log | sort | uniq -c | sort -rn5. 日志分析的实战脚本与常见问题排查5.1 写一个每日汇总脚本手动敲命令太累我写了个汇总脚本每天跑一次输出一份简报。核心逻辑是遍历当天的全量日志分别统计总请求数、独立IP数、爬虫请求数、状态码分布、Top 10 访问URL。#!/bin/bash LOG/var/log/wp-site/access-$(date %F).log echo 总请求数 wc -l $LOG echo 独立IP数 awk -F\t {print $2} $LOG | sort -u | wc -l echo 爬虫请求数 awk -F\t $5 ~ /Googlebot|Bingbot|Baiduspider|YandexBot/ $LOG | wc -l echo 状态码分布 awk -F\t {print $7} $LOG | sort | uniq -c | sort -rn echo Top 10 URL awk -F\t {print $4} $LOG | sort | uniq -c | sort -rn | head -10这个脚本跑完站点当天的健康状况基本一目了然。我把它挂到每天早上输出结果发到自己邮箱不用登录服务器就能掌握情况。5.2 排查日志突然不写了这是最常见的问题。有一次我发现日志停在某个时间点不动了排查过程分享给大家第一步确认PHP是否还在正常执行。随便访问一个页面看是否正常返回。如果页面正常但日志不写说明是日志代码本身的问题。第二步检查文件权限。PHP进程通常是www-data或nginx用户对日志目录必须有写权限。用ls -ld看目录权限用ps aux | grep php看PHP运行用户。权限不对的话file_put_contents会静默失败。第三步检查磁盘空间。df -h看一眼磁盘满了写入自然失败。这个坑很隐蔽因为页面还能正常返回读操作不受影响只有写日志失败。第四步检查是否被open_basedir限制。有些主机环境会限制PHP只能访问特定目录日志目录如果在限制范围外写入会被拒绝。5.3 日志里出现大量异常请求怎么办有段时间我的日志里出现大量请求/wp-login.php和/xmlrpc.php的记录明显是有人在尝试暴力破解。处理思路分三层第一层直接封IP。用awk统计这些请求的来源IP出现频率高的直接加到防火墙黑名单。第二层从入口切断。xmlrpc.php如果不用直接在Nginx里返回403。wp-login.php可以改成自定义登录地址让扫描器找不到入口。第三层加访问频率限制。Nginx的limit_req模块可以对特定路径做限速比如登录页每分钟最多5次请求。location /wp-login.php { limit_req zonelogin burst3 nodelay; include fastcgi_params; fastcgi_pass unix:/run/php/php-fpm.sock; }注意限速阈值不要设得太死否则正常用户也可能被误伤。建议先观察一段时间正常登录的频率再定阈值。6. 几个我踩过的坑和对应经验6.1 日志格式里的分隔符选择一开始我用空格分隔字段结果User-Agent里本身带空格解析时列全乱了。后来改用制表符\t因为UA里几乎不会出现制表符。但即便如此也要注意URI里可能带编码后的空格%20这个不影响。真正要小心的是Referer字段有些来源URL里可能带特殊字符建议在写入前做一次转义或过滤。6.2 别在日志里记录敏感信息我见过有人在日志里把POST请求的完整body也记下来结果用户的登录密码、表单内容全进了日志文件。这是严重的安全隐患。日志只记请求元信息绝不记请求体。如果确实需要排查某个表单问题临时开启排查完立刻关掉。6.3 高并发下的性能影响每次请求都写一次文件理论上会增加I/O。实测下来在日PV十万级别的站点上这个开销可以忽略因为file_put_contents是追加写操作系统有页缓存。但如果你的站点日PV上百万就要考虑用异步写入或者直接交给Web服务器层处理了。我的建议是先用起来遇到瓶颈再优化不要一开始就过度设计。6.4 时区问题导致日志日期错乱PHP默认时区可能是UTC而你看日志时习惯用本地时间结果日志文件名和实际日期对不上。解决办法是在wp-config.php里显式设置时区或者在写日志时用date_default_timezone_set(Asia/Shanghai)。这个坑不大但排查起来很烦因为你会怀疑是不是日志没写其实是写到了昨天的文件里。7. 从日志到决策这些数据到底怎么用日志本身不是目的用它指导决策才是。我举几个真实场景。场景一发现某篇文章的爬虫抓取频次突然下降。对比前后几天的日志发现该文章返回了500错误。顺着状态码去查是文章里嵌入的某个外部资源导致PHP超时。修复后抓取恢复正常。场景二发现大量404请求集中在某个URL模式。比如/old-page-*说明之前改版时旧链接没有做301跳转。根据日志里的Referer还能看出这些死链是从哪些外站引进来的针对性处理。场景三发现某个IP段在非高峰时段高频抓取。UA伪装成普通浏览器但请求间隔极其规律明显是采集程序。直接在防火墙层面封掉整个IP段。这些决策靠统计插件是做不到的只有原始日志才能提供这种颗粒度的信息。所以我的观点很明确统计插件看趋势原始日志做诊断两者互补缺一不可。最后分享一个我自己的习惯每周花十分钟翻一翻蜘蛛日志的Top URL看看爬虫最近在关注什么。有时候它会比你先发现站点里某个页面的异常——比如某个本不该被索引的页面突然被频繁抓取那多半是哪里暴露了内链。这种爬虫视角的巡检比任何SEO工具都直接。
