如何做好网站优化：旧栏目下线时，把人工经验写成脚本需求怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dbf18c3c58ad.html
📄
如何做好网站优化：旧栏目下线时，把人工经验写成脚本需求怎样描述例外情况
直接回答：不要只写“保留有价值的页面”，而要把例外写成可判定的条件、可执行的去向和可核对的证据。假设一个情境：某站计划下线一个旧产品栏目，运营凭经验认为“有咨询价值的页面要留下”。如果脚本只收到“保留高价值页面”，它无法判断哪条URL属于例外，最终要么误删，要么全部保留，退出动作等于没做。下面用一个明确标为假设的简短情境，把决策过程写清。
先写清“什么情况下不执行默认动作”
默认动作是：栏目内页面返回410或跳转到上级栏目。例外描述要回答三个问题：触发条件是什么、由谁确认、确认后执行什么。例如不要写“重要页面保留”，而写成：若URL在近180天内有来自站内导航的点击，且页面仍包含可下载的规格文件，则标记为待人工复核，不进入默认下线队列。这里“近180天”“站内导航点击”“可下载规格文件”都是可判定条件。假设运营只凭印象说“这个页面有人问过”，脚本无法验证，就应该把这类描述退回，要求补成可查询的证据。
把例外拆成“保留、改写、转移”三类去向
例外不是只有“留”和“删”。在旧栏目退出场景里，至少可以分成三类：
- 保留：页面仍有独立搜索需求，且内容不需要大改。动作是保留URL，但移除已失效的购买入口。
- 改写：页面主题仍有价值，但信息已过时。动作是合并进新栏目文章，旧URL做301到新位置。
- 转移：页面本身没有独立价值，但其中某段说明仍有参考意义。动作是把该段迁到新页面，旧URL下线。
脚本需求里要分别写出三类的判定条件和输出字段。例如disposition只能取keep、rewrite、redirect、retire四个值，人工复核只能修改这个字段，不能直接改删除队列。这样例外情况有明确出口，不会因为一句“再看一下”卡住整批处理。
用假设例子走一遍决策链
假设旧栏目有120条URL。脚本先按默认规则处理：无站内点击、无外链、无规格文件的页面进入retire；有站内点击但内容已过时的进入rewrite；有站内点击且有规格文件的进入keep待复核。运营复核时发现其中一条URL虽然满足keep条件，但规格文件已经过期，于是把它改成rewrite，并备注“文件需替换后再合并”。这个动作的结果是：该URL没有直接删除，也没有原样保留，而是进入改写队列；下一步内容编辑拿到明确任务，而不是重新判断整批URL。
这里的关键不是规则多复杂，而是每条例外都能回答“为什么它是例外”和“例外之后做什么”。如果只能回答“感觉有用”，就还不适合写成脚本需求。
记录判断依据，避免把现象当成结论
旧内容退出时，常见证据包括站内搜索词、导航点击、外链来源、表单提交和客服记录。要注意：某条URL的点击量归零，不能单独证明它没有价值，也可能是导航入口被移除、统计口径变化或季节需求下降。一次改动前后比较也要考虑季节、搜索需求变化和数据采集差异，不能把短期波动直接当成处理正确的证据。
因此脚本需求里应保留判断依据字段，例如evidence_type、evidence_window、reviewer、review_note。这样后续复查时能知道当时为什么把它列为例外。若证据本身不完整，应把该条URL放入待补证队列，而不是自动保留或自动删除。
交付前做一次例外回放
脚本写完不要只检查正常路径。挑出三到五条已知例外，按需求文档手动走一遍：条件是否命中、去向是否唯一、备注是否足够让下一位执行者接手。假设回放发现两条URL同时满足keep和rewrite，就说明优先级没有写清，需要补充判定顺序，例如先判断是否有独立搜索需求，再判断内容是否过时。回放通过后，再把脚本接入实际队列；如果回放失败，先改需求描述，不要先改脚本代码。
把例外写成条件、去向和证据之后，旧栏目退出就不再依赖某个人的记忆。即使原运营离开，接手者也能根据字段判断哪些页面保留、哪些改写、哪些转移，网站优化中的这次退出动作才算真正可执行、可复查。
