优化网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b51e7e43667e.html
📄
优化网站规模扩大后哪些工作不适合继续手工做
当页面从几十个增长到几百上千个，最先不该继续手工做的不是内容创作，而是重复性批量检查和跨页面一致性维护。这两类工作手工做会同时出现遗漏和口径不一，而它们恰好是搜索引擎理解站点的前提。
先分清：哪些手工工作还能撑住，哪些会先失控
假设一个情境：站点原本 40 个页面，由一位编辑维护，标题、内链、canonical 都靠人工过一遍。半年后扩展到 600 个页面，新增两名兼职编辑。此时三人对“标题该多长”“哪些页面该加内链”理解不同，问题开始出现。
判断标准不是工作量大小，而是这项工作是否需要逐页判断：
- 需要逐页判断、且判断依据稳定的：标题重写、内容补强、页面合并决策——手工仍然合理，但要有书面口径。
- 不需要逐页判断、只需按规则比对的：canonical 是否自指、是否有重复 title、是否被 robots 误屏蔽、内链是否指向 404——这类一旦超过约 200 个页面，手工就该退出。
原因是：前者的价值在判断，后者的价值在覆盖率。手工做覆盖率，必然漏。
分歧点：三个人对“这页有没有问题”理解不同
继续上面的假设。编辑 A 认为某页“没问题”，因为它能正常打开；编辑 B 认为有问题，因为它的 title 和另外 12 个页面完全相同；编辑 C 认为不算问题，因为那些页面流量都不高。
三种理解对应三个不同环节：可访问、可被区分、值得被索引。把分歧转成可核对的项目，就是把每个人的说法落到一个能验证的事实上：
- “能打开”对应 HTTP 状态码与渲染是否正常。
- “title 相同”对应是否存在重复标题，这是可批量导出的。
- “流量低”对应的是要不要保留该页，属于内容决策，不是技术缺陷。
先确认分歧落在哪个环节，再决定谁来判断。这一步不做，后面所有自动化都是在错误前提上加速。
该交给脚本的信号，和不该交给脚本的判断
适合批量处理的，是那些结果唯一、可枚举的检查项。例如用一段简单逻辑列出全站标题重复的页面：
<a href="..." title="..."> 这类内链写法若缺少可读文本，脚本可以逐页标记，但“这个锚文本该写什么”仍需人来定。
不适合交给脚本的包括：这个页面该不该存在、这段内容是否满足搜索意图、两个近似页面该合并还是保留。这些判断依赖对业务和用户的理解，脚本只能提供候选清单。
一个实际动作是：先把“重复 title”“缺失 canonical”“内链指向 404”三类导出成清单，人工只处理清单，而不是逐页翻看。结果是人工时间从“巡检全站”变成“处理异常项”，下一步才谈得上把规则写进发布流程。
手工退出后，先补口径还是先上工具
顺序上应先补口径。如果三人都没统一“什么算重复标题”，工具跑出来的清单会被三种标准反复推翻，最后没人信任它。
可核对的项目应该写成一句话规则，例如“同一语言下，title 完全相同的页面视为待处理项”，并注明例外（如分页、筛选页）。规则定完再让脚本执行，输出的清单才有争议解决能力。
反过来说，如果站点还停留在几十个页面、只有一人维护，手工完全够用，提前上批量流程反而增加维护成本。规模是触发条件，不是越早越好。
一个可复用的判断顺序
遇到“这活还要不要手工做”时，按下面顺序问：
- 这项工作的输出是唯一答案还是需要权衡？唯一答案优先自动化。
- 出错时是漏一页还是漏一片？会成片漏的优先自动化。
- 多人是否对“合格”有不同理解？有分歧就先统一口径，再自动化。
按这个顺序走，手工被替换的是覆盖率，被保留的是判断力。规模扩大后真正该做的，是让机器负责“有没有”，让人负责“好不好”。
