权重优化技巧：旧内容退出时，脚本需求怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d407194f9dbe.html
📄
权重优化技巧：旧内容退出时，脚本需求怎样描述例外情况
把人工判断写成脚本需求，例外情况不能只写“特殊情况人工处理”。更可执行的做法是：为每个例外写明触发条件、判定所需字段、处置动作、结束状态，以及退出后保留哪些内容。这样脚本才能稳定执行，人工也只需介入真正需要判断的环节。
先假设一个旧栏目退出的情境
假设一个站点要下线旧栏目，但其中一部分页面仍有访问和外部链接。人工操作时，编辑会逐页判断：有的整页删除，有的保留正文并去掉栏目入口，有的只保留一个说明页。现在要把这套经验写成脚本需求，难点不在正常路径，而在例外路径。
如果需求只写“符合条件就删除，不符合就保留”，脚本遇到边界页时只能停下来。人工经验之所以有效，是因为编辑看到了页面类型、历史链接、访问来源和替代内容是否存在。脚本需求要做的，是把这些判断依据变成可读取的字段和可执行的步骤。
例外描述要拆成五个字段
每个例外至少写清以下五项，缺一项都容易在开发或验收时产生歧义：
- 触发条件：什么情况下进入例外，例如页面仍被外部链接指向，或页面访问量连续一段时间高于同栏目其他页面。
- 判定依据：脚本读取哪些数据来判断，例如链接来源数、页面类型、替代页面是否存在、最后修改时间。
- 处置动作：进入例外后做什么，例如保留正文、移除栏目导航、添加跳转，或转入待人工确认队列。
- 结束状态：处理完成后页面处于什么状态，是保留、重定向、返回 410，还是标记为待复核。
- 保留范围：退出栏目后仍要保留哪些部分，例如正文、图片、外部链接可访问性，或仅保留说明信息。
这五项的作用是让脚本有明确分支。触发条件决定是否进入例外，判定依据决定读取什么，处置动作决定执行什么，结束状态决定后续如何检查，保留范围决定哪些内容不能一起清掉。
用假设例子走一遍决策过程
假设旧栏目有 200 个页面，脚本按规则批量处理。运行后发现 12 个页面被外部链接指向，其中 3 个页面还有替代内容可用，另外 9 个没有合适替代页。此时不能把这 12 个页面统一删除，也不能统一保留。
更合理的需求描述是：
- 当页面存在外部链接且存在替代页时，保留正文，移除栏目入口，并将旧地址指向替代页。
- 当页面存在外部链接但没有替代页时，保留正文，移除栏目入口，结束状态标记为待人工确认。
- 当页面没有外部链接且没有替代页时，按正常退出流程处理。
这个假设例子说明，例外的关键不是“有没有链接”，而是链接与替代内容组合后产生的不同处置。脚本需求写到这一层，开发和验收才有共同依据。
哪些现象不能单独证明处理正确
脚本执行后，如果请求量下降、抓取量减少或某个统计归零，不能直接认定处理正确。请求量下降也可能来自季节变化、搜索需求转移、采集口径调整，或页面本来就在自然衰减。抓取量减少也可能只是站点整体抓取分配变化。
要判断一次改动是否按预期生效，至少比较同一时间窗口内的多个指标，并记录改动前后采集方式是否一致。若只看到单一指标归零，更合理的动作是回到脚本日志，检查例外分支是否被触发、结束状态是否写入、保留范围是否被误删，而不是直接下结论。
写需求时可直接替换的动作
把“特殊情况人工处理”改写成可执行条款，可以按这个顺序做：先列出人工曾经处理过的例外类型，再为每类补上触发条件和判定依据，最后写明处置动作、结束状态和保留范围。完成后让脚本按假设数据跑一遍，检查每个例外是否有明确出口。
如果某个例外无法写出判定依据，说明它还不适合交给脚本，应保留为人工确认队列，并记录人工判断时看了哪些信息。下一次迭代时，再把这些信息转成字段。这样退出旧内容时，脚本负责稳定执行，人工只处理真正需要判断的部分，仍然有价值的内容也不会被一起清掉。
