网站内部链接：页面数量减少时如何保留高价值需求覆盖
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5a1d7596785c.html
📄
网站内部链接：页面数量减少时如何保留高价值需求覆盖
页面减少后，先不要按“删掉多少页”来分配内部链接，而要先确认哪些高价值需求已经分散在多页上。做法是把每个待合并或待删除页面还原成需求记录，再把需求映射到保留页，最后用内部链接把保留页推到可发现位置。只有当某条需求在保留页有明确对应段落、且能从相关页面获得链接时，这次减少才算覆盖住了。
先处理你手里那份待删页面清单
假设你有一份准备下线的页面清单，每行是一个URL。不要直接标注“保留/删除”，先补三列：这条页面承接什么需求、需求是否已由其他页覆盖、覆盖页是哪一个。第三列如果填不出来，说明这个页面不能直接删，只能先合并或改写成保留页的一部分。
判断“已覆盖”的标准不是标题相似，而是用户带着同一意图进入保留页后，能否在首屏或紧随其后的段落找到答案。标题相近但内容角度不同的两页，往往对应不同需求，合并后反而会丢掉其中一条。
这一步的产出是一张需求映射表。它决定了后面内部链接往哪里加，而不是先决定删哪些链接。
区分两类减少：合并同需求与下线低价值
页面数量减少通常来自两种不同动作，内部链接的处理方式也不同。
- 合并同需求页面：多个页面回答同一意图，保留页需要承接全部子问题。此时应把被合并页的入站内部链接改指向保留页，并在保留页内用锚文本区分各子问题。
- 下线低价值页面：页面本身没有独立需求，也没有外部或内部链接价值。此时重点是清理指向它的链接，避免留下断链，同时确认它没有承担导航或转化路径中的中间角色。
两种动作混在一起做，最容易出现的情况是：保留页承接了需求，但原来指向被删页的内部链接没有转移，保留页仍然缺少入口。结果内容还在，可发现性下降。
用内部链接把需求重新分配到保留页
内部链接在这里的作用是告诉用户和搜索引擎：这条需求现在由哪个页面负责。具体动作分三步。
- 找出所有指向待删页的内部链接，按来源页面分类。
- 对每个来源页面，判断它链接过去是为了解决什么问题。
- 如果保留页能解决同一问题，就把链接改指向保留页；如果保留页只覆盖其中一部分，就先补充保留页内容，再改链接。
改链接后，检查保留页是否从至少两个相关页面获得了描述性锚文本。如果所有链接都来自导航或页脚，说明需求覆盖仍停留在形式层面，正文层面的关联没有建立。
一个假设例子：三条需求合并到一页
假设某业务原有三页，分别讲“基础用法”“常见错误”“适用条件”，都指向同一类用户。现在决定合并为一页。合并后，保留页需要包含三个小节，并分别从原来的来源页面获得链接。原来的“常见错误”页如果还有外部链接，可以保留URL并做跳转，但站内链接应统一指向保留页的新小节锚点。
如果只合并内容、不改内部链接，来源页面仍然指向旧URL，用户进入后看到跳转或404，需求覆盖就断在入口处。如果先改链接、后补内容，用户进入保留页找不到对应答案，同样算覆盖失败。两种顺序都会影响下一步：前者需要回查链接，后者需要回补内容。
减少后要复查什么，以及何时停止
减少完成后，复查对象不是页面总数，而是需求映射表里每一条需求是否还有至少一个可访问页面承接，并且该页面能从相关页面获得内部链接。如果某条需求只剩一个孤立页面、没有任何内部链接指向它，应优先补链接，而不是继续删页。
停止减少的条件可以设为：待删清单里每一行都能填出覆盖页，且覆盖页已获得来自相关来源页面的链接。如果填不出覆盖页，说明这条需求还没有新归属，此时继续减少会直接造成覆盖缺口。抓取量或索引量下降本身不能单独证明处理正确，也可能来自抓取预算变化、页面合并后的正常收敛或外部因素，需要结合需求映射表判断。
把这张表留着，下一次调整页面结构时，它可以直接告诉你哪些内部链接需要先动、哪些页面还不能动。
