手机指数：页面数量减少时如何保留高价值需求覆盖
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d5fb195dcc71.html
📄
手机指数：页面数量减少时如何保留高价值需求覆盖
页面减少本身不会自动伤害需求覆盖，真正决定结果的是：被删页面承载的需求是否还有别的页面能承接，以及承接页能否在移动端被快速理解。若两个页面描述同一类需求，合并后保留一个更完整的页面通常可行；若两个页面各自覆盖不同决策阶段，硬删就会留下空洞。下面用一个假设情境说明取舍。
先分清“重复页面”和“不同需求页面”
假设某站点做手机参数与选购内容，原先有 80 个页面，计划压缩到 45 个。运营者发现其中 20 个页面标题都围绕同一款机型的“值不值得买”，只是按颜色、存储版本、发布时间拆开。这类页面在移动端往往给出近似答案，用户需求也接近，合并成一篇覆盖版本差异、适用人群和取舍条件的页面，通常比保留 20 个薄页面更容易被理解。
但另外 15 个页面看似也围绕同一机型，实际分别回答“拍照对比”“续航测试”“游戏帧率”“系统更新注意事项”。这些需求发生在不同决策阶段，用户搜索意图也不同。把它们全部塞进一篇长文，可能让每个问题都只得到一小段，反而降低页面与具体需求的匹配度。此时减少页面数量的正确动作不是合并，而是保留关键页面，把次要页面改为站内锚点或模块。
用需求覆盖表判断哪些页面不能删
在删除前，先做一张需求覆盖表，而不是只看页面浏览量。表的每一行写一个用户需求，列写当前由哪个页面承接、该页面在移动端的核心答案是什么、删除后由谁承接。判断标准可以简化为三条：
- 有独立决策价值：用户看完这个页面后，会做出不同选择，例如“买标准版还是 Pro 版”。
- 有独立证据或数据：页面包含其他页面没有的测试条件、对比维度或限制说明。
- 有独立入口需求：用户会直接用不同说法搜索，且现有承接页无法自然覆盖该说法。
三条都不满足的页面，优先合并；满足两条以上的页面，优先保留或改造成模块。这个动作的结果会直接影响下一步：如果一张页面被判定为可合并，下一步是检查承接页的标题、首屏摘要和内部链接是否真的能接住原需求；如果判定为保留，下一步才是优化移动端加载和可读性。
两种做法成立的条件不同
做法一：合并同类页面，保留一个主页面。成立条件是需求高度重叠，且主页面能在首屏给出足够具体的答案。代价是原页面积累的内部链接和外部提及可能分散，需要手动把链接指向新页面。若合并后主页面只做简单拼接，用户仍要滚动很久才能找到答案，移动端体验会变差。
做法二：保留少量高价值页面，删除其余页面并设置跳转。成立条件是保留页确实覆盖了核心决策需求，且删除页没有独立搜索入口。代价是短期可能出现抓取和索引波动，部分长尾需求暂时没有专门页面承接。这里要强调：抓取量或索引量下降不能单独证明删对了，也可能只是搜索引擎尚未重新评估站点结构。合理做法是观察需求覆盖表是否仍有空洞，而不是只盯数量变化。
一个假设例子：从 80 页压到 45 页
假设上述站点最终保留 12 个机型主页面、8 个对比页面、10 个选购指南、10 个常见问题页、5 个品牌汇总页，共 45 页。执行时先处理 20 个重复的“值不值得买”页面，合并为 5 个机型决策页；再把 15 个不同测试维度页面中的 8 个保留为独立页，其余 7 个改为决策页里的模块，并保留原 URL 跳转到最相关模块所在页面。
完成后检查三件事：第一，每个高价值需求是否仍有一个页面能在移动端首屏给出答案；第二，原页面的内部链接是否都指向了正确承接页；第三，搜索结果中出现的旧标题是否逐渐被新页面替代。若第二项没做好，用户和搜索引擎仍可能走到已删除页面，覆盖就会断掉。这个检查结果决定下一步是继续合并，还是暂停并修复链接。
移动端还要看答案是否在首屏出现
页面数量减少后，留下来的页面往往承担更多需求。移动端屏幕小，若核心答案藏在长文后半段，用户会认为页面没有回答他的问题。一个实际动作是：把每个保留页面的首屏写成“结论 + 适用条件 + 下一步”，例如先说明该机型适合谁，再给出不适合的情况，最后链接到对比页。这个动作的结果是，用户不需要滚动多次就能判断是否继续阅读，搜索引擎也更容易从首屏提取页面主题。
如果首屏仍然只是导语和目录，说明承接页没有真正接住合并过来的需求，下一步应调整内容顺序，而不是继续删页面。页面减少的目标不是数字变小，而是让每个留下的页面更明确地对应一类高价值需求。
