网站从几十个页面扩到几百上千个页面后,最先出问题的往往不是技术架构,而是那些靠人工逐条处理的工作。判断一项工作是否该继续手工做,标准不是它麻不麻烦,而是它出错后能否被及时发现、重复执行时结果是否一致、以及单次操作的耗时是否随页面数量线性增长。只要这三条里有一条不满足,就该考虑把它转成可复用、可校验的流程。
挑一个你手头最典型的页面,比如一个刚上线的产品详情页或一篇内容页,把围绕它需要做的维护动作列出来:标题和描述是否需要随内容调整、内链是否需要补、结构化数据是否完整、失效链接是否需要替换、页面是否需要从某个列表移除或加入。然后问自己三个问题。
假设你有一个包含 300 个页面的站点,每次改版后要检查所有页面的内链是否指向已下线的页面。手工点击检查一轮大约需要数小时,而每次内容更新后都要重做一遍。这里的关键不是工时,而是第二轮检查时你会不会因为疲劳而漏掉几个。如果漏掉,用户遇到死链、搜索引擎抓取时遇到无效跳转,都属于可观察的后果,但发现时间取决于你有没有别的监控手段。这个假设说明的是比较方法:把单页动作的耗时乘以页面数,再乘以每月重复次数,就能看出人工是否还成立。
以下四类工作,在样本量小的时候手工完全可行,但页面数量上去之后,人工的边际成本会超过收益。
比如全站页面标题格式调整、为一批页面统一补充或移除某段说明文字、把某个分类下的页面统一加上一段引导语。手工逐页修改的问题在于:改到一半时你无法确认哪些已改、哪些没改,回滚时也没有一致的状态。更稳妥的做法是先把变更规则写成可重复执行的脚本或模板,再在一小批页面上验证结果,确认无误后批量应用。动作本身不复杂,但它决定了你下一步能不能安全地继续扩大站点。
失效链接、错误跳转、指向已删除页面的内链,会随着站点存在时间变长而累积。手工检查一次能发现问题,但无法保证下次更新后不出现新的。把这类检查交给定时任务后,你得到的不是“一次修完”,而是“每次变化后都能重新验证”。这里要注意:抓取工具报告某个链接返回异常,不等于该链接一定需要删除,它也可能是临时超时、访问限制或服务端偶发问题。看到异常数量变化时,先确认是真实失效还是采集误差,再决定是否批量处理。
站点小的时候,你可以凭印象决定某个页面要不要让搜索引擎收录。页面多了之后,凭印象判断会出现前后矛盾:同类页面有的被放行、有的被拦截,而这种不一致往往在搜索表现波动时才被发现。更可靠的方式是把判断条件写清楚,比如“有独立内容且能通过站内导航到达的页面放行,纯筛选参数页拦截”,然后按条件批量执行。抓取、索引、排名是不同环节,批量放行不等于一定被收录,但至少能保证你的处理逻辑是一致的。
改一个页面的标题、合并两个页面、下线一个栏目,都会牵连到内链、导航、站点地图和跳转规则。手工排查依赖记忆,规模一大就不可靠。把“改动后需要检查哪些位置”固定成一份清单,并在每次改动后按清单执行,比事后凭印象补漏更省事。这一步的实际结果是:你能在改动当天就发现遗漏,而不是等用户反馈或搜索表现变化时才回头找原因。
并不是所有工作都适合自动化。以下情况手工或人工审核仍然必要。
换句话说,自动化处理的是“已知规则下的重复执行”,人工处理的是“规则本身需要判断”的部分。把两者混在一起,要么人工被重复劳动拖住,要么机器执行了不该执行的规则。
以“检查全站内链是否指向有效页面”为例,一个可落地的转换过程如下。
这里的关键动作是第四步:小范围验证。如果跳过它直接全站执行,一旦判断标准有偏差,你得到的是几百条需要人工逐条复核的结果,反而比手工检查更费时间。验证通过后再扩大范围,下一步的维护节奏才有依据。
最后要说明适用条件:上述判断成立的前提是站点已有相对稳定的页面结构和内容更新节奏。如果站点仍在频繁改版、栏目结构每月都变,那么先稳定结构再谈自动化更合理,否则规则会一直追着变化跑。规模扩大后真正需要放弃的不是“人工”,而是“没有标准、无法复核、每次重来”的手工做法。