内部链接优化：产品停用后原有页面保留还是退役
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /35fb32139856.html
📄
内部链接优化：产品停用后原有页面保留还是退役
结论取决于两个可验证条件：该页面是否仍能独立满足一部分搜索需求，以及它现在承接的内链是否还有更合适的落点。两者都成立时保留并改造；只要内链落点已经明确、页面本身不再满足需求，退役更干净。下面给出判断依据、反例和下一步动作。
先分清“停用产品”与“停用页面”是两件事
产品停用不等于页面必须消失。搜索引擎对页面的处理分抓取、索引、排名几个环节，一个页面被保留、被索引、被排在某个位置，是三件不同的事。产品停用后，原页面通常处于四种状态之一：
- 仍在被搜索需求命中，只是转化对象变了；
- 不再被命中，但仍被大量内链指向，承担着链接枢纽作用；
- 既不被命中，也没有独特内链价值，只是历史遗留；
- 被外部链接引用，但站内已经没有任何合理入口。
保留还是退役，针对的是这四种状态，而不是“产品是否还在卖”。把产品状态直接等同于页面状态，是这类决策最常见的误判来源。
保留成立的条件：页面还能独立满足一类需求
如果停用产品的页面仍在承接明确需求，保留并改造通常优于退役。判断标准不是“还有没有流量”，而是：用户带着某个意图进入这个页面时，页面能否在不依赖已停用产品的情况下给出完整答案。
典型可保留的情形包括：该页面是某类问题的解释页、对比页、替代方案页，或是一个仍被引用的历史节点。此时改造动作是：把页面主题从“某产品”调整为“某问题的解决方式”，保留原有可继承的标题语义和站内入口，把指向它的内链改为指向改造后的同一地址，而不是新建一个页面再重新积累。
这里有一个可执行动作：先列出当前指向该页面的站内链接来源，逐个判断这些链接的上下文是否还成立。如果多数来源的上下文仍然成立，说明页面的语义位置还在，保留改造的代价更低；如果多数来源的上下文已经失效，说明它只是被惯性引用，退役更合理。这个动作的结果直接决定下一步是改造还是清理。
退役成立的条件：内链落点已有更合适的承接页
退役不是删除，而是把页面承担的职责转移出去。它成立的前提是：站内已经存在一个更贴合当前需求的页面，可以接收原页面的内链和外部引用。
具体做法是先确定接收页，再改内链，最后处理原地址。顺序不能颠倒：如果先让原地址失效，再回头找落点，内链会在一段时间内指向无效目标，用户和抓取都会遇到断点。接收页确定后，把原页面上的站内链接逐一改指接收页，同时把指向原页面的内链也改指接收页，让链接关系保持连续。
退役的代价是：原地址上积累的外部引用不会自动转移，站内也需要一段时间让新落点被重新理解。因此只有在接收页确实更合适、且原页面没有独立需求时才值得做。如果接收页只是“差不多相关”，退役会把原本清晰的语义打散。
一个会让上述结论失效的反例
假设某页面停用后既没有搜索需求，也没有外部引用，按上面的标准应当退役。但如果这个页面是站内多个页面的唯一共同入口，退役后这些页面之间的链接关系会断裂，原本可以通过它互相发现的内容变成孤岛。这种情况下，页面本身没有需求，却承担了结构职责，退役的代价被低估了。
反过来也成立：一个页面看起来还有搜索需求，但如果这些需求已经由另一个页面更好地满足，保留它就是制造重复。此时正确的动作不是改造，而是合并——把独有信息并入接收页，再退役原页面。
所以判断顺序应当是：先看结构职责，再看需求归属，最后才看流量表现。只看流量会同时误判这两种情况。
下一步：用一次内链盘点替代直觉判断
具体动作是导出指向该页面的站内链接清单，按来源页面的主题分组，逐组回答两个问题：这组链接的上下文是否仍然成立；如果不成立，站内是否有页面能接住它。分组结果会自然分成三类：继续指向原页面、改指接收页、直接移除。
完成这次盘点后，保留还是退役就不再是一个立场问题，而是清单上三类链接各自的数量对比。数量对比明确之后，再决定是改造原页面还是执行退役，并把改链和地址处理放在同一次改动里完成，避免中间状态停留过久。这一步做完，页面状态和内链结构就同时有了确定答案。
