当站点从几十个页面扩到几百上千个页面时,最先失效的不是策略,而是手工操作的稳定性。判断一项工作是否该转为脚本或批量流程,标准是:它是否依赖对每个页面逐一判断、且判断规则本身已经稳定。规则稳定、样本量大、结果需要可复现的环节,继续手工做会持续消耗时间并引入不一致;规则仍在探索、样本少、需要结合业务语境判断的环节,手工反而更快。下面以你手上的一份页面清单或一批URL为对象,说明怎么逐项决定。
把当前手工在做的事列出来,逐条问两个问题:这条规则在过去一个月里改过几次?如果换一个人按同样规则处理,结果会不会一致?
前一类继续手工做,规模越大越容易漏改、错改;后一类过早自动化,会把错误规则批量放大。这个划分不是永久的,规则一旦稳定下来,就该从手工区移到流程区。
假设你手上有一份500条URL的清单,每条记录了页面标题、目标词、当前收录状态。手工逐条改标题,一天可能只处理几十条,且中途标准容易漂移。可执行的转换步骤是:
这个动作的结果是:人工从“处理全部”变成“处理例外”。如果跑完之后被标记的比例很高,说明规则还没稳定,应回到手工阶段继续打磨,而不是硬推批量处理。
抓取、索引、排名是三个不同环节,处理方式也不同。抓取和索引相关的操作,规则通常最明确:提交站点地图、检查robots规则、处理返回状态码、统一URL规范。这些工作按页面逐一手工做,既慢又容易漏。
需要留意的边界是:某天抓取量或提交量下降,不能单独证明你之前的处理错了。服务器响应变慢、站点结构调整、外部链接变化,都可能造成同样的现象。正确做法是先把抓取日志或状态码分布拉出来,看下降集中在哪些目录,再决定是修规则还是查其他原因。这一步用手工抽样也能做,但样本量小时结论不可靠,所以规模上去后,日志分析更适合交给脚本。
页面该不该保留、两个页面该不该合并、某类内容是否值得继续投入,这些判断依赖对业务和用户意图的理解,规则很难写死。假设你有200个内容页,其中一部分长期没有有效访问,如果直接按“无访问即删除”批量处理,可能误删仍有转化价值或承担内链枢纽作用的页面。
更稳的做法是:先人工判断一小批,记录判断依据,例如是否有转化、是否被其他页面引用、是否覆盖独立需求。等这些依据能写成明确条件后,再把筛选交给脚本,人工只做最终确认。判断依据还没成形时,手工处理虽然慢,但能避免批量误判。
可以用一句话作为操作分界:如果一项工作的判断标准能写成“满足A则做B”,就适合转为脚本或批量流程;如果还需要回答“这样做对业务是否合适”,就保留人工。按这条线把当前工作分完类后,先挑一类规则最稳定的批量处理,观察一轮结果,再决定是否扩大自动化范围。这样每一步都有依据,也不会因为追求效率而把错误规则铺到全站。