网站日志，规模扩大后哪些手工活该停掉
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /22af122d9b4c.html
📄
网站日志，规模扩大后哪些手工活该停掉
网站规模扩大后，最该停止手工做的不是“看日志”本身，而是逐条翻阅原始日志、手工统计状态码分布、靠记忆比对旧页面是否仍值得保留。原因很直接：页面和抓取请求的增长速度通常快于人力，手工处理会把判断变成抽查，而抽查很容易漏掉正在退出的旧内容或旧系统留下的抓取入口。更稳妥的做法是把日志处理变成固定流程，人只负责决定保留、重定向还是移除。
一个矛盾现象：日志越看越细，决策反而越慢
规模扩大后常出现这种局面：团队每天花时间打开日志文件，逐条找异常 URL、逐条记下状态码，但真正要决定旧栏目是否下线、旧合作页面是否保留时，却拿不出一份可复用的清单。这不是因为日志没用，而是因为处理方式还停留在小站阶段。
对此通常有两种解释。第一种是日志量已经超过人工浏览的合理范围，继续手工看只会得到零散印象；第二种是团队并没有明确“哪些页面要退出、哪些要保留”，所以无论看多少日志都无法形成结论。前者是处理方式问题，后者是内容决策问题，两者经常同时存在。
能区分两种解释的证据
要判断问题出在哪，可以看三类证据：
- 同一批异常 URL 是否反复出现在多天日志里。如果反复出现，说明不是偶发抓取，而是旧链接、旧系统或旧合作关系仍在持续暴露。
- 手工记录是否只能说出“大概有一些 404”，却给不出按目录、按参数或按来源分组的数量。给不出分组，通常意味着处理方式需要升级。
- 是否已经有人明确列出“保留清单”和“退出清单”。如果没有，日志再细也只能停留在观察层面。
一个假设例子：某站有约两万条 URL，其中一部分来自已停止合作的旧频道。如果连续一周日志里这些旧 URL 仍被反复请求，而团队只能手工挑出其中几十条处理，那么剩下的部分大概率会继续被浪费抓取。此时先停止手工逐条处理，改为按目录和参数聚合，再决定整批重定向或返回 410，会比继续翻日志更有效。这里的数字只用于说明比较方法，不代表任何真实站点数据。
规模扩大后不适合继续手工做的几件事
第一，逐条阅读原始日志。人工适合抽样确认格式和异常类型，不适合作为日常发现问题的唯一方式。更实际的动作是先把日志按状态码、目录、用户代理和请求路径做聚合，再从中挑出需要人工判断的少数条目。这样做的结果是：下一步不再是“继续看日志”，而是针对某个目录决定保留、重定向或移除。
第二，手工统计抓取频次和响应时间。规模变大后，手工统计容易只记住最近一次的印象，忽略趋势。把统计交给固定脚本或日志分析流程，人只需要看聚合结果是否指向同一批 URL。若某类 URL 的抓取量下降，不能直接断定它已被正确处理，也可能只是抓取预算转移、链接减少或临时波动，需要结合页面是否仍被引用、是否仍有入口来判断。
第三，靠记忆维护旧内容退出清单。旧内容、旧系统或旧合作关系退出时，真正有价值的部分往往不是首页，而是仍被外部引用、仍有搜索需求或仍承担跳转职责的页面。手工维护容易漏掉这些例外。更合适的做法是建立一份可更新的映射表，记录每个旧 URL 的去向：保留、301 到新地址、返回 410，还是暂时不动。这个动作的结果会直接影响下一步：如果映射表完整，后续批量处理才有依据；如果不完整，就只能继续零散修补。
哪些部分仍然值得保留人工判断
不是所有手工工作都该停。以下环节仍适合人工介入：
- 决定某个旧栏目是否还有保留价值。这涉及业务判断，日志只能提供抓取和访问线索。
- 确认重定向目标是否语义一致。把旧页面全部指向首页通常不是好做法，人工需要判断最接近的替代页面。
- 处理少量高价值异常 URL。例如仍被外部链接引用、但返回 404 的页面，值得单独确认。
换句话说，手工应该从“逐条处理”转为“处理例外和做决策”。日志负责暴露范围，人负责决定取舍。
一个可执行的分界动作
可以先做一次分界：把日志中出现的 URL 按“仍要保留”“需要退出”“不确定”三组归类，只对“不确定”组继续人工查看。执行后如果发现“不确定”组仍然很大，说明退出规则还不够明确，应先补充规则，而不是继续扩大人工查看量。如果“不确定”组缩小到可处理范围，就可以把前两组交给固定流程执行，人只抽查结果。
这个动作的关键不是追求一次处理完，而是让下一步有明确输入：规则清楚就批量执行，规则不清楚就先补规则。规模扩大后，手工的价值在于定义规则和处理例外，而不在于替代流程。
