网站降权总挑半夜，日志里能翻到证据

降权这件事，结论在搜索引擎那边，过程基本都留在你自己的机器上。网站降权总挑半夜日志里能翻到证据——这话我信了很多年，凡是能完整复盘的案例，时间点几乎都落在深夜某个时段。但别误会，搜索引擎并没有什么夜间模式，更多时候是你自己的服务器到了那个点开始忙别的事。

半夜出问题的，往往是你自己的定时任务

面板装完，计划任务里躺着几条默认项：数据库导出、站点打包备份、日志切割、缓存重建。这些活默认都排在流量最低的时候，也就是深夜。几件事撞在同一小时，磁盘IO先满，接着PHP-FPM的进程池被占满，动态页面开始502、504。爬虫如果正好在这个窗口进来，抓走的就是一屏错误页，不是你的正文。它不会告诉你我待会儿再来，它只记账。

网站降权总挑半夜日志里能翻到证据，先按小时数状态码

别急着翻SEO后台那几条提示，先登机器。Nginx默认combined格式里，$4是带方括号的时间，$9是状态码。按小时聚合先看一眼：awk ‘{print substr($4,2,14)}’ access.log | sort | uniq -c | sort -rn | head。再看状态码分布：awk ‘{print $9}’ access.log | sort | uniq -c | sort -rn。哪一小时5xx突然堆起来，一眼就清楚。历史日志被压成.gz的，前面挂个zcat access.log.1.gz | 就行。命令本身不难，难的是你平时根本没留日志。

爬虫的访问记录，比任何报表都诚实

用UA过滤一下：grep -iE ‘baiduspider|googlebot’ access.log | tail -50。看它来的间隔、抓的路径、拿到的返回码。正常状态是稀疏、分散、以200为主。如果某段时间它连着抓、返回一堆404或503，那多半是站内链接结构变了，或者页面真的打不开。它抓不到东西，索引往下掉是顺理成章的事，用不着往玄学上找原因。

慢日志和 error log 别漏看了

access log只记结果，原因常常在后端。PHP的error log里半夜冒出来的fatal error、数据库慢查询日志里超过阈值的语句、磁盘或inode写满导致的写入失败——这些东西不会显示在网页上，却会让页面在特定时段直接不可用。很多人只盯访问日志，看半天只有超时没有原因，就是漏了这一层。

5xx 和 403 是两种完全不同的坏消息

5xx说明机器扛不住、程序崩了、上游超时；403往往意味着有人主动拦了。深夜某些安全软件会自动跑一轮扫描，规则一收紧，把正常爬虫和扫描器一起挡在门外。看日志时顺手确认一下WAF、CDN、防火墙这几层有没有在夜里改过策略，改动记录一般都有。各家面板的入口和字段不一样，具体以服务商或官方页面说明为准。

时区没对上，事故时间能看反

服务器日志跑UTC，你脑子里装的是北京时间，中间差着8小时。看着像后半夜那波故障，实际对应的可能是晚上八九点的高峰。用date或timedatectl确认一下系统时区，别凭感觉换算。日志格式里带时区的更省心，一眼就知道自己在看哪一段。

日志留不住，事后只能靠猜

logrotate默认只保留几周，过期直接删掉。真出了事再回头找，往往只剩压缩包。建议把原始access log定期同步一份到别的地方，别放在站点目录下面，也别忽略它同样吃磁盘。不用留太久，能覆盖一个完整的流量周期就够了。

一条典型的半夜事故链长什么样

备份任务启动，数据库被锁住一段时间；动态页面请求排队，超时变成503；这时爬虫进来，连续拿到错误页；第二天索引量往下掉，权重跟着松动。链条上每一环在日志里都带着时间戳，你把它们按时间排一遍，因果基本就出来了。真实情况当然更乱，可能还夹着一次改版、一次解析调整，所以顺序别搞反，先后的时间差比内容本身更能说明问题。

找到证据之后，先动这几处

把备份、日志切割、缓存重建的时间错开，别全挤在一个小时里；给关键页面加个简单的可用性拨测，半夜出问题能立刻收到信；确认防火墙和CDN的自动策略有没有误伤爬虫UA；日志保留周期调到能覆盖你发现故障的时间差。这四件事做完，下次再出状况，你手里至少有时间线。

降权报告只会告诉你掉了，不会告诉你为什么掉。答案在机器上，在那份你平时懒得点开的日志里。下回再碰上半夜掉排名，别先改标题、别急着买外链，花二十分钟把那一晚的访问记录拉出来对着看，多半比瞎猜管用。