飓风算法，页面数量减少时如何保留高价值需求覆盖
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d6426c317f44.html
📄
飓风算法，页面数量减少时如何保留高价值需求覆盖
页面数量减少本身不等于覆盖变差，真正要判断的是：被删掉的是重复表达，还是某类用户需求的唯一入口。保留、改写、退出三种取舍各有前提，先按需求类型分组，再决定动作，比按URL数量一刀切更可靠。
先分清“需求覆盖”与“页面数量”不是一回事
覆盖指的是用户带着某类意图进来时，站内是否存在一个能被理解、能给出答案的页面。多个页面写同一件事，属于表达冗余；一个页面同时承接几种意图，属于聚合。数量下降后，如果每个意图仍能找到对应落点，覆盖就没有丢。
判断时可以做一个假设例子：某站原有十页都在讲同一类操作方法，只换了措辞和举例顺序。把它们合并成一页后，页面数从十变一，但该意图仍有一个稳定落点，这种情况属于表达收敛，不是覆盖丢失。反过来，如果十页里有一页专门回答“旧版本还能不能用”，而其余九页都在讲新版本，删掉那一页就等于放弃了一类需求。这个比较方法只用于说明区分逻辑，不构成任何真实站点的结论。
保留、改写、退出各自的适用前提
三种动作对应三种不同的证据状态，先看证据再选动作。
- 保留：该页面是某类意图的唯一落点，且内容能独立回答完整问题。前提是需求本身仍然存在，且没有其他页面能替代。保留时要确认它没有被并入一个更泛的页面后变得难以定位。
- 改写：多页指向相近意图，但各自带有一部分独有信息。前提是这些独有信息对用户有实际价值。改写不是把几段话拼在一起，而是重新确定一个主意图，把其余内容降为支撑。
- 退出：页面只是同一意图的另一种说法，没有独有信息，也没有独立入口价值。前提是已经确认该意图在其他页面有更完整的承接。退出前要记录它原本承接的意图，避免退出后无人接手。
这里的关键动作是：为每个准备处理的页面写一行“它承接哪类需求、是否有独有信息”。这一行记录会直接决定下一步是保留还是改写；如果没有这行记录就动手删，后续很难判断覆盖是否真的缺了一块。
用可核对的分歧记录代替角色之间的口头判断
编辑、技术、运营对同一页面常有不同理解：编辑觉得内容重复，技术觉得它还有抓取入口，运营觉得它带来过咨询。分歧本身不是问题，问题是没有可核对的记录。
可以建一张最小字段表，每个页面一行，字段包括：承接的需求描述、是否有独有信息、是否有其他页面能替代、拟处理动作。填写时只写可观察的事实，不写“感觉重要”这类判断。填完后，分歧会集中在具体字段上，例如“是否有独有信息”这一栏两人填得不一样，就可以回到页面内容本身核对，而不是继续争论要不要删。
这个动作的结果会改变下一步：如果某页在“是否有替代”一栏被填成“有”，它才进入退出候选；如果被填成“无”，即使内容看起来单薄，也应先改写而不是直接退出。
数量下降后，怎么确认高价值需求没有断档
处理完成后，不要只看总页面数，而要看需求清单是否仍有落点。做法是把处理前的需求描述列出来，逐条确认现在由哪个页面承接。出现以下情况时，说明覆盖可能断档：某条需求找不到对应页面；多个页面都声称承接同一需求但内容都不完整；原本的入口页面退出后，替代页面在结构上离该需求很远。
需要说明的是，抓取量、索引量或某类请求下降，不能单独证明处理正确。它们下降还有其他合理解释，例如入口链接减少、页面合并后结构变化、外部引用变化。要判断覆盖是否保留，仍应回到需求清单与页面内容的对应关系上，而不是把某项统计的下降直接当成结论。
一个可执行的取舍顺序
- 先列出准备减少的页面，逐页标注承接的需求。
- 把需求相同的页面归为一组，确认组内是否有独有信息。
- 有独有信息的组，选一个主页面改写，其余退出或转为支撑内容。
- 没有独有信息的组，保留最完整的一页，其余退出。
- 处理完后，用需求清单反查是否每条需求仍有落点。
这个顺序的价值在于：它把“删多少页”换成“哪些需求必须有落点”。只要需求清单完整，页面数量减少可以是收敛；一旦某条需求失去落点，减少就变成了覆盖缺口。
