当页面从几十个涨到几百上千个,最先崩掉的不是策略,而是手工操作的核对能力。手工适合判断和决策,不适合对全站重复执行;一旦某个动作需要逐页复制、逐条比对、逐次记录,就应该转为规则加脚本或模板,手工只保留抽样验收。判断标准很简单:如果这项工作需要你在两周后重做一遍,且每次结果都应一致,它就不该继续靠人记忆完成。
拿你手上的一份全站页面清单或抓取结果,逐行标注它属于哪一类。
分类之后你会发现,真正需要人做的判断类工作占比很小,而消耗时间的往往是核对和搬运。把这两类交出去,人才有时间处理判断类问题。
假设你怀疑产品列表页的分页序列存在重复内容问题。手工做法是逐页打开、逐页看 canonical,页面一多就无法覆盖。
改成规则化处理:先明确期望状态,例如“第 2 页及之后的分页 URL 的 canonical 指向自身,而不是指向第 1 页”。然后写一段脚本或使用站点级抓取,把每个分页 URL 及其 canonical 输出成两列,再筛选出不满足期望的行。
这一步的实际动作是产出一份例外清单,而不是一份全量清单。结果如何影响下一步:如果例外集中在某几个栏目,说明问题出在模板,改模板即可覆盖全部页面;如果例外分散、无规律,说明存在手工录入的残留,需要先统一数据来源再谈修复。两种结论对应完全不同的工作量,这正是规则化核对的价值。
规模扩大后常见的一种内耗是:运营认为某批页面“没被收录”,技术认为“服务器日志里明明有抓取”。双方各说各话,因为看的不是同一件事。
把分歧拆成三个可分别核对的项目:
抓取、索引、排名是不同环节,一个环节的现象不能直接推断另一个环节的结论。请求量下降可能来自抓取预算重新分配、URL 结构变更、robots 规则调整,也可能是站点整体流量波动,不能只凭一个数字就断定处理正确或错误。把三项分开记录,争论就变成了对同一张表的核对。
不是所有事情都该自动化。以下情况手工反而更合适:
换句话说,手工负责定义规则和验收结果,脚本负责执行规则和产出例外。当一项工作既需要重复执行、又要求结果一致时,继续手工就是在给自己制造未来的返工。
如果你现在就要动手,按这个顺序处理你手上的清单:先挑出所有“两周后还要再做一遍”的工作,把它们归入核对类或搬运类;为其中影响面最大的一项写出期望状态,产出例外清单;根据例外是集中还是分散,决定改模板还是改数据源。做完这一轮,你会得到一份可持续复用的检查规则,而不是一次性的手工结果。规模越大,这份规则的价值越高于任何单次修复。