当页面从几十个增长到几百上千个,手工逐页改标题、查死链、盯收录,会先耗尽人的时间,再拖慢判断。更实际的分界是:凡是需要“对全站每个URL重复执行、且结果可以用规则判断”的工作,都不该继续手工做;凡是需要理解业务优先级、判断内容价值、决定取舍的工作,仍然要人来做。下面用一个假设情境说明这个分界怎么落地。
假设一个站点从80个页面扩到3000个页面,产品页、分类页和帮助文档混在一起。此时团队仍按老习惯,每周抽一天人工检查:打开若干页面看标题是否重复、用浏览器逐个点内链、把新页面地址复制进表格等待收录。这个做法在80个页面时可行,因为人能记住全貌;到3000个页面时,问题不再是“做不完”,而是“做的结果不可信”——抽查不到的地方会被默认成没问题,而默认本身没有依据。
这时应该先做一个最小动作:从站点地图或站内链接中导出全部URL清单,只保留URL和所在目录两列,不引入任何新工具权限。用这份清单回答一个问题:哪些目录下的页面数量最多、变化最快。假设结果显示帮助文档占了一半以上且每月新增,那么后续的手工检查就应该停止覆盖这部分,转而交给规则处理。这个动作不能推出“其他目录没问题”,它只能告诉你人力该往哪里放。
第一类是批量元信息检查。标题、描述、H1是否缺失或高度雷同,本质是对每个URL套同一组判断条件。手工抽查在页面少时能发现典型问题,页面多时只能发现被抽到的问题。这里可以先用表格函数或脚本对导出的URL清单做一次比对,把重复项标出来,再人工判断哪些重复是业务上合理的(例如同一系列的不同规格页),哪些是疏忽。
第二类是站内链接与死链巡检。内链是否指向已删除页面、重要页面是否缺少入口,这些判断依赖全站关系,不依赖单个页面的观感。人工点击只能覆盖少量路径,且每次改版后都要重来。把它交给定时任务或站点地图比对,结果是一份可复核的清单,而不是“我感觉没问题”。
第三类是抓取与索引状态的常规观察。这里要区分环节:页面能被抓取、被抓取后能否进入索引、进入索引后表现如何,是三件不同的事。手工在搜索框里逐条查,既慢又容易把“没查到”当成“没收录”。更稳的做法是定期导出站点层面的状态数据,看趋势和异常分组,把人工精力留给异常页面的原因分析。
手工并没有被全盘取代。以下工作即使规模变大,也不适合完全交给规则:决定某个分类页是否应该合并、判断一篇旧文档是否还有保留价值、评估两个页面是否在争同一类需求、决定新内容该放在哪个目录。这些判断需要业务上下文,规则只能提供证据,不能替代决定。
可以这样分工:规则负责“找出候选”,人负责“做出决定”。例如批量检查标出20个标题重复的页面,人去判断其中哪几个是真正需要改写的;巡检标出一批无入口页面,人去判断是补内链还是下线。这个分工的好处是,人的时间花在不可替代的判断上,而不是花在打开页面上。
很多团队在规模扩大时并没有完整的数据权限,可能拿不到站点级状态导出,也可能改不了模板。这不构成继续手工逐页处理的理由,但会改变动作顺序。
需要说明的是,缺少权限时得到的结论是有限的。URL清单能说明站点结构和数量分布,不能说明抓取是否顺畅、索引是否正常、排名是否变化。因此不能用“清单看起来整齐”来推断“站点健康”。同样,某次巡检没有发现死链,只说明这次检查覆盖的范围内没有,不等于全站没有。
假设团队按上面的顺序,先把帮助文档目录的元信息检查交给规则,每周产出一份异常清单。接下来要观察的不是“异常数量是否归零”,而是异常的类型是否在变化:如果重复标题集中在少数模板生成的页面,说明问题出在模板;如果分散在不同目录,说明问题出在内容流程。这个区分会直接决定下一步是改模板还是改编辑规范。
同时要接受一个事实:自动化产出的清单需要有人复核,否则规则会积累误报,最终被忽略。比较稳妥的节奏是,规则负责覆盖全量,人负责抽样复核和解释异常。当异常解释清楚后,再决定是调整规则、修改模板,还是把它列为可接受的业务特例。这样,规模扩大带来的不是更多手工,而是更明确的判断依据。