网站架构规划：网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /31be3f8f4d57.html
📄
网站架构规划：网站规模扩大后哪些工作不适合继续手工做
当页面数量、栏目层级和改版频率同时上升，继续靠人工维护内链、导航、重定向和页面模板，错误率会先于工作量失控。判断分界不看总页数，而看两个条件：结构变更是否每周发生，以及同一规则是否需要跨十个以上页面重复执行。满足其一，就应把这项工作交给规则或脚本；两者都不满足，手工反而更快。
先判断：结构稳定但页面多，和结构频繁变动是两回事
页面多但栏目固定，手工维护的成本主要是一次性的。比如一个已上线多年的企业站，产品分类三年没动，新增内容都挂在既有栏目下，此时人工检查导航和面包屑仍然可行，因为规则没有变化。
真正不适合手工的是第二种情况：栏目要拆分、URL 规则要调整、同一批页面要批量换内链目标。这类工作每次变动都要求全站一致，人工执行时容易漏掉深层页面。判断依据不是“页面有没有超过某个数量”，而是同一规则是否需要反复套用到新页面。如果是，规则本身就该被固化下来，而不是每次重新执行一遍。
内链与导航：规则化之后，改动结果才能被复核
手工加内链在几十个页面内可控，但规模扩大后会出现两个问题：一是同一篇内容被反复链接，二是新页面长期没有入口。把内链规则写成可执行的判断，例如“同栏目文章互相链接”“相关产品按分类自动关联”，可以让每次新增内容自动获得入口。
实际动作可以这样开始：先列出三类必须自动生成的链接关系——栏目到详情、详情到同栏目、详情到上级栏目。把这三类规则交给模板或构建流程处理，人工只负责判断哪些页面不该被链接。做完这一步，下一步的复核成本会明显下降，因为检查对象从“每个页面的每条链接”变成“规则是否覆盖了该覆盖的页面”。
例外是编辑判断类内链，比如把一篇旧文指向新活动页。这类链接数量少、目的明确，保留手工更合适。
重定向与 URL 变更：批量操作必须留下可核对的清单
URL 规则调整时，手工逐条添加重定向几乎必然遗漏。更稳妥的做法是让重定向从一份映射表生成，映射表本身可以被审阅、被比对。假设一次栏目改名涉及 200 个详情页，手工处理需要逐个打开、逐个确认；用映射表则可以先导出旧 URL 与新 URL 的对应关系，再统一生成规则。
这里的假设是：旧 URL 可以从日志或站点地图中获取，新 URL 有明确规则。如果新旧 URL 之间没有稳定对应关系，比如内容被合并或删除，就不能靠批量生成，需要人工判断每条重定向指向哪里。这也是手工仍然成立的条件——映射关系本身不确定时，自动化只会更快地产生错误。
页面模板与元信息：重复字段适合模板，判断字段保留人工
标题、描述、面包屑、结构化数据中的固定字段，属于重复度高的内容，适合由模板按栏目和页面类型生成。人工逐页填写在页面少时可行，页面一多就会出现同一栏目下描述雷同、字段缺失的情况。
但涉及内容判断的字段不应交给模板。例如一篇内容该归入哪个分类、是否应该被索引、是否需要 canonical 指向其他页面，这些取决于内容意图，模板无法替代。可以这样划分：结构字段走模板，意图字段留人工。执行后如果发现某类页面频繁出现判断错误，说明需要补充的是判断标准，而不是把判断也自动化。
什么时候先别自动化
如果结构半年内不会变动，新增页面每月只有个位数，那么引入构建流程和规则维护的成本可能高于手工。另一个不适用的情况是规则本身还没稳定：栏目划分还在讨论、URL 方案还没定，此时把不确定的规则写进模板，后续修改的成本会更高。先让规则跑顺，再决定是否固化。
还有一种情况需要单独看待：抓取和索引异常。页面没有被抓取，可能来自入口不足、规则阻断或站点本身响应问题，不能仅凭抓取量下降就断定是架构问题，也不能因为某次调整后抓取恢复就认定该调整是原因。先确认异常属于哪个环节，再决定是否需要改动结构。
把上述判断落到一次具体动作上：本周先统计哪些维护任务在过去一个月被重复执行了三次以上，再从中挑出一项规则最清晰的任务做自动化试点。试点结果如果显示规则覆盖不全，说明要先补规则；如果显示规则可用，再扩展到同类任务。这样每一步的下一步都有依据，而不是一次性推翻全部手工流程。
