用户体验算法：多个业务争同一搜索需求时该保留还是改写页面
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0eca7736f226.html
📄
用户体验算法：多个业务争同一搜索需求时该保留还是改写页面
当两个或更多业务线都盯着同一批搜索词时，先不要急着合并或删页。更稳妥的做法是：用一次可复核的划界测试，判断每个页面究竟是满足了不同的用户任务，还是只是在重复同一任务。如果任务确实不同，保留并各自强化；如果任务相同，改写其中较弱的一版，让它承接另一种意图；只有当某页既无独立任务、又无法改写时，才退出。
先分清“同一搜索需求”的两种含义
搜索需求相同，可能指用户输入了同一批查询词，也可能指用户想完成同一件事。这两者并不等价。一个查询词背后可能藏着购买前的比较、购买后的使用、以及售后求助三种任务。多个业务争的往往不是词，而是词背后的任务归属。
划界的第一步，是把每个候选页面还原成一个用户任务陈述，而不是停留在栏目名称上。例如“账户安全”这个词，可能对应“如何开启双重验证”和“忘记密码怎么办”两个任务。如果两个业务各自只覆盖其中一个，它们并不真正冲突；如果两页都在讲开启步骤，冲突才成立。
这里要接受一个前提：抓取、索引和排名是不同环节。页面被收录不等于它被判定为最合适的答案，排名波动也不单独证明划界失败。判断依据应当来自任务覆盖和用户完成路径，而不是某一天的位次变化。
用一组可核对的证据判断该保留还是改写
不要凭感觉决定谁让路。可以按下面这组证据逐项核对，每项都要求能被第二个人复核：
- 任务动词是否相同。把每页的核心动作写成“用户想做什么”。动词相同，冲突概率高；动词不同，保留的可能性大。
- 完成路径是否可互换。假设用户从A页进入，能否在不返回搜索的情况下完成B页承诺的事。能，说明两页重叠；不能，说明任务边界存在。
- 页面主体是否各自成立。遮住标题后，正文是否仍在回答一个完整问题。若删掉一半内容就不成立，说明它依赖另一页补全，属于可合并对象。
- 站内链接是否互为替代。如果两页互相链接后用户仍不知道下一步去哪，问题不在链接，而在任务没有划清。
这组证据的作用是区分解释。排名同时下滑，可能是两页互相稀释，也可能是外部需求整体转移，还可能是抓取或索引环节出现延迟。只有任务动词和完成路径同时指向重叠，才支持“内部竞争”这一解释。反之，如果两页任务不同却都表现不佳，更可能是各自内容深度不足，而不是需要合并。
保留、改写、退出各自成立的条件
保留适用于两页任务动词不同、完成路径不可互换的情况。此时动作是：给每页补上明确的下一步入口，并在正文里写清它不负责什么。结果是用户和搜索引擎都更容易把两页归到不同任务下，后续观察也应分别记录，而不是合并看一个总数。
改写适用于任务相同、但其中一页有明显更强的内容基础。动作是保留强页的主体结构，把弱页改写成另一种意图的承接页，例如从“操作步骤”转为“故障排查”。改写后要重新检查两页是否仍在回答同一个动词；如果仍是，说明改写没到位，应继续调整而不是直接删除。
退出只适用于某页既没有独立任务、改写后仍与强页重叠、且站内没有其他位置承接它的情况。退出的动作可以是设置跳转或下线，但前提是先确认没有外部链接或用户习惯依赖该地址。若无法确认，先保留并观察，不要为了整齐而仓促处理。
假设有两个业务分别维护“开通指南”和“配置手册”，两者都覆盖同一批查询词。核对后发现：开通指南的任务是“第一次启用”，配置手册的任务是“启用后调整参数”。动词不同，路径不可互换，应保留，并在各自开头写清适用阶段。若核对后发现两页都在讲第一次启用，只是措辞不同，则应改写配置手册，让它承接调整参数的任务；若改写后仍无独立内容，才考虑退出。
划界之后要观察什么，而不是立刻下结论
完成保留或改写后，下一步不是等一个固定见效日期，而是设定观察口径：分别记录每页承接的任务词、用户是否在页内完成该任务、以及站内搜索或跳转是否减少。请求量或抓取量归零不能单独证明处理正确，它也可能是抓取预算调整、站点结构变动或统计口径变化造成的。把这些替代解释一并列出，才能避免把相关当成因果。
如果观察一段时间后，两页的任务词仍在互相渗透，说明边界描述不够具体，应回到任务动词这一步重新核对，而不是继续加内容。划界的终点不是谁赢谁输，而是每个页面都能被清楚回答：它替用户完成哪一件事，以及不完成哪一件事。
