内部链接优化：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /137d80794db9.html
📄
内部链接优化：搜索需求太分散时先做聚合页还是详情页
先做聚合页还是详情页，取决于分散需求之间是否共享同一个决策场景。若多个查询只是措辞不同、意图指向同一批选项或同一类问题，聚合页能更快建立清晰入口；若每个查询对应不同约束、不同使用条件，强行合并会让页面失焦，此时应先补详情页，再用内部链接把它们组织起来。
矛盾现象：入口分散，但流量并未归零
旧内容、旧系统或旧合作关系退出时，常见现象是：一批页面各自能获得少量访问，却没有一个页面能承接完整需求。此时容易得出两种相反解释。
- 解释一：需求本身分散。用户在不同阶段、不同约束下搜索，彼此并不共享同一决策路径。此时聚合页只能覆盖共同部分，细节仍需详情页承载。
- 解释二：只是入口没有收拢。多个查询本质指向同一类选择，只是页面标题、段落和链接各写各的。此时聚合页能把已有价值集中起来，详情页继续作为支撑材料。
两种解释都成立，但适用条件不同。区分它们不能只看单页访问量，也不能因为某个页面访问下降就判断聚合正确。抓取、索引和排名是不同环节，访问变化还可能来自展示位置、季节波动或外部链接变动。
用三个证据区分：该聚合还是该补详情
证据一：查询之间是否共享同一组决策条件
把分散查询按“用户要做的决定”归类。若多数查询都在问同一件事，例如同一类产品的选择标准、同一流程的先后顺序，只是问法不同，聚合页成立。若查询分别涉及预算上限、使用环境、替代方案、失败处理，这些条件彼此冲突，聚合页会变成泛泛介绍，详情页更合适。
证据二：现有页面是否已经能独立回答一个完整问题
打开旧页面，逐页判断它是否具备独立价值：有明确问题、有可执行步骤、有边界条件。如果多数页面只是片段，聚合页可以把片段组织成完整路径；如果多个页面各自完整，只是入口分散，应保留详情页，用聚合页做导航和筛选，而不是把内容硬拆重写。
证据三：退出旧内容后，哪些链接关系仍然值得保留
旧内容退出时，先列出仍然有价值的页面，再决定链接方向。一个实际动作是：为每个保留页面标注它服务的那类需求，然后检查从聚合页到详情页的链接是否覆盖了这些需求。若链接只能指向聚合页，用户仍要自己寻找细节，说明详情页需要保留；若详情页之间互相竞争同一需求，说明聚合页应先建立。
一个假设例子：两种做法的下一步不同
假设有一组旧页面，分别讨论同一类设备的安装、维护和替换。搜索需求分散在三个方向：安装条件、维护周期、替换时机。
若先做聚合页，把三类需求放在同一页，用户能快速看到全貌，但安装条件中的具体尺寸、维护周期中的环境差异会被压缩。下一步应补充详情页，并从聚合页按条件链接过去。
若先补详情页，每页只回答一个条件，用户进入后容易确认自己该看哪一页，但缺少总入口。下一步应建立聚合页，用简短说明和链接把三页串起来，而不是复制详情页内容。
两种顺序都可行，区别在于：聚合页先解决“我该看哪类问题”，详情页先解决“这个条件是否适用于我”。如果旧系统只能保留少量页面，优先保留能独立回答完整问题的详情页；如果旧合作关系退出后需要快速建立新入口，优先做聚合页，但必须为每个分支保留可链接的详情页。
执行时的取舍：先动链接，再动内容
无论先做哪一类页面，内部链接优化都应先于大规模改写。具体动作是：确定一个主入口页，把仍然有价值的旧页面链接到它；再从主入口页链接回详情页。完成后观察两件事：用户是否还能从入口找到具体条件；详情页是否仍在回答各自的问题。若入口页链接出去后，详情页访问没有明显变化，不能单独证明聚合正确，还要检查索引状态、页面标题与查询意图是否匹配。
当旧内容需要退出时，保留仍然有价值的部分，不是保留所有旧页面。判断标准是：该页面是否仍能独立回答一个具体问题，以及它是否值得从聚合页被链接。满足这两点，就先保留并纳入链接结构；不满足，再考虑合并或退出。
