页面摘要优化：两个页面争夺同一问题，保留拆分还是合并
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4ada76921a62.html
📄
页面摘要优化：两个页面争夺同一问题，保留拆分还是合并
先给结论：如果两个页面各自还承担着不同的主问题，只是摘要里有一句话重叠，保留拆分；如果去掉重叠那句话后，其中一个页面无法独立回答任何用户问题，合并。判断依据不是“哪篇排名靠前”，而是把两个页面各自能独立回答的问题列出来，看重叠部分去掉后还剩什么。
先把“同一问题”拆成可核对的三层
多个角色对“这两个页面是不是在争同一个问题”经常各说各话。编辑看到的是标题措辞相似，运营看到的是后台查询词重叠，产品看到的是用户从两个入口都能到达。三种理解都不算错，但没法直接拿来决策。把它们转成可以核对的项目，只需要三层：
- 入口层：用户是从哪个入口进入这两个页面的，是站内搜索、导航、还是外部链接。
- 问题层：每个页面正文里能独立回答的问题分别是什么，逐条写出来。
- 出口层：用户读完这个页面后，下一步动作指向哪里，是继续看另一个页面，还是直接完成转化。
三层对齐之后，“争同一个问题”通常会缩水成“入口层重叠，但问题层和出口层不同”。这时候保留拆分是更省成本的选择，因为合并会牺牲掉原本独立成立的出口。
假设情境：两个页面都答了同一句话
下面这个情境是假设的，用来演示判断过程，不代表任何真实站点。某内容站有两个页面，A 页讲“如何选择适合初学者的跑鞋”，B 页讲“跑步新手第一个月的训练安排”。两个页面的摘要里都写了一句“新手应先确认自己的足弓类型”。运营认为这就是两个页面在争同一个问题，主张合并成一篇大文章。
把两个页面能独立回答的问题列出来：A 页能回答预算区间怎么定、缓震和支撑怎么选、试穿时看哪几个点；B 页能回答每周跑几次、每次多久、出现酸痛时怎么调整。重叠的只有足弓类型那一句。
去掉重叠句后，A 页还剩三个问题，B 页还剩三个问题，两边都立得住。所以这个情境下的动作是：保留拆分，把重叠那句处理成一次指向，而不是把两页合并。
合并成立的条件：重叠之外没有独立问题
反过来，如果去掉重叠内容后，B 页只剩一句“具体训练安排见 A 页”，那 B 页就不是一个独立页面，而是一个中转页。这种情况合并成立，因为保留它只会让用户在两个页面之间来回跳。
可以用一个更机械的检验：把两个页面的正文各自删掉所有重叠段落，然后问“剩下的内容还能不能支撑一个完整的回答”。能，就拆；不能，就合。
这里要说明一个容易被误读的现象：如果某个页面的请求量或抓取量下降，不能单独证明它该被合并。抓取频率变化可能来自站内链接调整、页面更新节奏变化，或者抓取预算被其他新页面占用。要判断是否真的在争同一问题，还是得回到问题层和出口层的核对，而不是只看一个流量数字。
保留拆分时，摘要里要做的一个具体动作
保留拆分不等于放任重叠。实际动作是：在重叠那句话出现的位置，把它改成一次明确的分工说明，并给出指向另一页的链接。比如 A 页在提到足弓类型时，写成“足弓类型影响选鞋方向，判断方法和对应鞋型见另一篇；本篇继续讲预算和试穿”。
这个动作的结果是：两页的摘要不再重复同一句结论，而是各自把用户推向自己最擅长回答的部分。下一步可以据此观察两页的出口是否更集中——如果 A 页的读者更多点向试穿部分，B 页的读者更多点向训练安排，说明拆分是有效的。如果两页的读者仍然大量互相跳转且都不完成下一步，那才需要重新考虑合并。
决策清单：按顺序核对，不靠投票
- 逐条写出两个页面能独立回答的问题，不要写主题词，写完整问题。
- 标出重叠部分，删掉重叠段落，再看两边各自还剩几条。
- 两边都剩两条以上独立问题，保留拆分；一边只剩中转说明，合并。
- 保留拆分时，在重叠位置改写成分工说明并加指向链接。
- 观察两页出口是否各自集中，据此决定是否需要下一轮调整。
这套顺序的价值在于，它把“两个页面是不是在争同一个问题”从主观判断变成可核对的项目。多数情况下，真正需要合并的页面比想象中少，需要改写重叠句的页面比想象中多。
