网页打开慢：站点变大后，哪些手工活该保留、改写或退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /543e39b773b1.html
📄
网页打开慢：站点变大后，哪些手工活该保留、改写或退出
站点规模扩大后，最先出问题的往往不是技术，而是“人肉流程”的边际成本。手工检查页面、手工登记改动、手工核对跳转，在几十个页面时可靠，到几千个页面时就会变成瓶颈。判断标准不是“能不能手工做”，而是“手工做一次需要多久、遗漏后谁来发现、下次是否还要重做”。如果一项工作每次都靠记忆和临时沟通完成，它就该被改写为可重复的流程；如果它只在站点结构发生根本变化时才需要判断，保留人工反而更划算。
先分清三类工作：保留、改写、退出
保留的前提是这项工作依赖人的判断，且频率低、影响面小。例如首页标题措辞、核心栏目的信息架构，改一次会影响大量页面，机器很难替你决定“这句话是否符合品牌语气”。这类工作适合保留人工，但要留下改动记录，避免下次换人后重新讨论。
改写的前提是工作本身有明确规则，只是过去靠人执行。例如检查页面标题是否为空、描述是否重复、内链是否指向已删除的页面。这些判断可以写成规则，交给脚本或站点工具批量跑，人只看异常结果。改写不是把工作全部交给机器，而是把“逐页看”变成“看报告并处理例外”。
退出的前提是这项工作已经不再产生决策价值。例如每天手工记录某几个页面的打开速度，但记录完从不触发任何改动；或者手工统计每个栏目有多少页面，而栏目结构半年没变。这类工作应直接停掉，把时间让给真正影响抓取、索引和排名的环节。
手工检查页面质量：适合改写成抽样加规则
站点小的时候，逐页检查标题、正文、图片替代文本是可行的。规模扩大后，继续逐页看会带来两个代价：一是耗时随页面数线性增长，二是检查者注意力下降后，漏检反而更难被发现。更合理的做法是把检查拆成两层。
第一层是规则检查：用脚本或站点工具找出标题缺失、标题重复、正文过短、图片没有替代文本、内链指向 404 的页面。这些是确定性问题，不需要人逐页判断。第二层是抽样检查：从不同模板、不同栏目、不同更新频率的页面中各抽若干条，人工看内容是否真正回答了用户问题、是否与页面标题一致。
这样改写的代价是：规则需要维护，模板改版后选择器可能失效；抽样会漏掉长尾问题。但如果站点已经超过人工能稳定覆盖的范围，抽样加规则比“假装全量检查”更诚实。动作上，可以先跑一次全站规则检查，把结果按模板分组。如果某个模板集中出现同类问题，下一步应改模板或批量修正，而不是逐页改。
手工登记改动与跳转：适合退出或并入发布流程
很多团队用表格记录“哪个页面改过标题”“哪个旧链接跳到哪里”。在页面数量少、改动少的时候，表格能帮人回忆。站点扩大后，表格会迅速与真实页面脱节，因为发布流程不会自动更新它。此时继续手工维护，成本高且不可信。
更合适的做法是把登记并入发布流程：标题、描述、跳转规则随页面配置一起提交，由流程自动记录变更时间和操作者。人不再单独维护一份“改动台账”。退出手工登记的前提是发布流程本身可追溯；如果发布仍然靠手工上传文件，那么先解决发布方式，再谈退出表格。
需要保留人工判断的是跳转目标的选择。旧页面应该跳到最相关的新页面，还是跳到栏目页，这取决于用户意图和内容对应关系，不能只靠规则批量决定。可以批量找出失效链接，但跳转目标由人确认，确认后写入配置，后续由流程执行。
手工监控打开慢：从逐次记录改为阈值告警
打开慢的排查在站点扩大后容易变成两种极端：要么每天手工打开几个页面凭感觉判断，要么完全不管。更可行的是设定少量关键页面和关键指标，用工具持续记录，只在超过阈值时通知人。人处理的不是“今天快不快”，而是“哪个模板或哪类资源在变慢”。
这里要区分相关与因果。某个统计显示抓取量下降，不能单独证明是打开慢造成的；服务器错误、内容更新减少、外部链接变化都可能有影响。阈值告警的作用是缩小排查范围，不是直接给出结论。假设某栏目页面在改版后打开时间上升，同时该栏目抓取量下降，可以先检查改版是否增加了阻塞渲染的资源，再决定回退、拆分还是继续观察。这个例子只说明比较方法，不代表真实项目结果。
判断保留还是退出的三个问题
- 这项工作多久做一次？如果每周都要做，且规则明确，优先改写；如果半年才做一次且依赖判断，可以保留。
- 漏做之后谁会先发现？如果只能靠用户投诉或搜索流量下滑才发现，说明需要改成自动检查或告警。
- 下次是否还要重新做？如果每次都要重新收集、重新讨论，说明缺少可复用的配置或记录，应先补流程再退出人工。
规模扩大后的取舍不是“全部自动化”，而是把人的时间从重复核对转移到规则设计、例外处理和内容判断上。先选一项每周都在做、规则又相对明确的手工活，把它改成脚本检查或流程记录，观察异常是否更容易被发现；如果异常确实减少，再处理下一项。这样每一步都有依据，也不会因为一次改动过大而失去控制。
