蓝天算法：页面数量减少时如何保留高价值需求覆盖
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cbe232d5e8a8.html
📄
蓝天算法：页面数量减少时如何保留高价值需求覆盖
答案取决于一个判断：你要削减的是页面，还是需求覆盖。蓝天算法针对的是低质、拼接、采集和模板化页面，页面被清理后，如果同一需求仍由少数更扎实的页面承接，覆盖可以保留；如果被删的恰好是唯一能回答某个问题的页面，覆盖就会断掉。下面用一个假设情境说明如何区分这两种情况。
假设情境：一个旧站从八百页缩到三百页
假设某站运营多年，积累了约八百个页面，其中一部分来自已停止合作的供应商，一部分是早期批量生成的模板页。现在决定只保留三百页。此时不要按“哪些页面还有流量”直接排序，而要先按需求分组。
把原有页面逐一归入一个需求组，例如“某类问题的解决步骤”“某类产品的选型条件”“某类故障的排查”。同一需求组里可能有多个页面，它们互为替代。删掉组内重复页，需求覆盖不受影响；删掉组内唯一页，覆盖就出现缺口。
这一步的实际动作是：为每个待删页面标注它所属的需求组，以及组内是否还有其他页面。这个标注结果直接决定下一步是删除、合并，还是保留并改写。
先判断页面减少是否触及唯一覆盖
判断依据不是页面数量，而是需求与页面的对应关系。可以用以下证据区分：
- 组内还有两个以上页面能完整回答同一问题，且内容不互相矛盾，删除其中较弱的页面通常不影响覆盖。
- 组内只有一个页面能回答该问题，其余只是提到相关词，删除后该需求没有承接页。
- 组内页面各自覆盖该需求的不同分支，例如分别处理不同前提条件，删除任一分支都会留下盲区。
- 组内页面内容高度相似，只是标题或段落顺序不同，这类页面正是模板化清理的常见对象。
如果某个需求组的页面全部符合最后一种情况，保留其中质量最高的一页并重写，其余可以退出。如果符合前三种中的任意一种，需要先处理覆盖问题，再谈删除。
把退出动作拆成删除、合并、改写三种
页面数量减少不等于只能删除。三种动作对应不同条件：
- 删除：该需求组内已有更强页面完整承接，且被删页面没有独立的外部链接或历史入口价值。
- 合并：多个页面各覆盖需求的一部分，单独看都不完整。把有效内容并入一个主页面，保留主页面地址。
- 改写：该需求确实有价值，但现有页面质量不足，无法通过合并解决。保留地址，重写内容使其能独立回答该需求。
选择合并时，要确认被合并页面的独有信息真的进入了主页面，而不是只做跳转。跳转能传递访问者，但不能保证原页面承载的那部分需求描述仍然存在。选择改写时，先确认该需求在减少页面后仍有人需要，再投入改写成本。
用一个小检查表决定哪些需求必须保留
在批量执行前，对每个需求组回答三个问题：
- 这个需求是否与站点当前仍要服务的业务方向一致？
- 减少页面后，是否至少有一个页面能完整回答它，而不是只出现相关词？
- 这个页面是否可以被搜索引擎正常抓取和理解，而不是依赖复杂交互才能看到内容？
三个问题都答“是”，该需求可以保留在较少的页面上。任一答“否”，要么补一个承接页，要么明确放弃该需求，而不是留着低质页面假装覆盖。
抓取、索引和排名是不同环节。页面减少后，如果抓取量或索引量下降，不能单独证明处理正确，也不能单独证明处理错误。可能的原因包括：被删页面本来就不被索引、站点整体抓取预算变化、内链结构改变、或者剩余页面尚未被重新评估。要结合需求覆盖情况判断，而不是只看数量指标。
执行顺序与结果如何影响下一步
建议顺序是：先完成需求分组，再标记唯一覆盖页，然后对重复组执行删除或合并，对唯一覆盖但质量不足的页面执行改写，最后检查剩余页面的内链是否能到达这些承接页。
一个假设例子：某站原有五个页面都在讲同一类问题的解决步骤，内容互相重复。删除其中四个，保留并重写一个。结果是该需求仍有一个页面承接，站点页面总数减少四页。下一步应观察该保留页是否被正常抓取和索引；如果没有，优先检查内链和入口，而不是恢复已删页面。
反过来，如果某个需求只有一个页面，且该页面来自旧合作关系、内容已过时，直接删除会让该需求失去承接。此时应先把仍然成立的部分改写进一个自有页面，再让旧页面退出。这个顺序决定了页面减少之后，高价值需求是否还有落点。
