人工目录：多个业务争夺同一搜索需求时如何划界
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cacfbc428d19.html
📄
人工目录：多个业务争夺同一搜索需求时如何划界
当两个或更多业务线都声称自己该承接同一个搜索需求时，最省事的做法往往是让它们各写一页、都去争同一个词。但如果这个需求背后是同一批用户、同一类意图，多页并存通常不会带来更多覆盖，只会让内部互相稀释。划界的关键不是谁写得好，而是先判断这个需求应该由一个人工目录式的归属清单来管理，还是干脆合并成一个入口。下面从旧内容、旧系统或旧合作关系退出时常见的一个矛盾现象说起。
矛盾现象：退出旧业务后，搜索需求反而更乱
一个常见情形是：某条旧业务线已经决定收缩，旧页面、旧合作方的落地页、旧系统生成的列表页却还挂在站上。按理说，退出应该让归属更清晰，实际上却常常相反——几个还活着的业务都开始认为这个需求“本来是我的”，于是各自新建页面去接。结果是同一意图下出现多套内容，用户在不同页面看到相近的说明，内部却没人能说清哪一页才是主入口。
这个现象本身不能直接说明谁对谁错，它只是暴露了归属规则缺位。真正要解决的是：在退出发生之后，谁来继承这个需求，其余业务以什么身份存在。
两种解释：是需求本身分裂，还是归属没人管
对同一现象，至少有两种合理解释，处理方式完全相反。
- 解释一：需求确实分裂了。不同业务面对的是不同人群、不同决策阶段或不同使用条件，只是搜索表达相近。这种情况下，多个页面并存是合理的，需要的是把边界写清楚，而不是强行合并。
- 解释二：需求没有分裂，只是归属缺位。用户要的是同一件事，各业务只是从自己的角度重复覆盖。这种情况下，多页并存会互相消耗，应该确定一个主承接方，其余改为指向或补充。
把这两种解释混在一起，就会出现最常见的错误：用“再写一页更好的”来回避归属决策。页面越写越多，问题却一直没被回答。
能区分两种解释的证据
要判断属于哪一种，可以看几类可观察的证据，而不是凭业务方的自我陈述。
看用户任务是否可替换
如果用户在这个需求下，无论从哪个业务进入，完成的任务是同一件事、需要的下一步动作也相同，那么更接近解释二。反之，如果不同业务导向明显不同的后续动作——比如一个导向咨询、一个导向自助查询、一个导向线下办理——那更可能是解释一，需求在意图层面就已经分叉。
看现有页面的实际承接差异
把相关页面按“用户进来后做什么”分组，而不是按“属于哪个业务”分组。如果分组结果高度重叠，说明是归属问题；如果分组结果清晰分离，说明是边界问题。这里要注意，某几个页面的流量下降或归零，不能单独证明归属判断正确，它也可能是季节、改版、外链变化或抓取与索引环节的正常波动。抓取、索引、排名是不同环节，任何一个环节的变化都需要单独确认，不能直接当成归属结论。
看退出后的残留结构
旧业务退出时留下的目录、导航位置、内链入口，会持续影响用户和搜索引擎对归属的理解。如果这些残留还指向已收缩的业务，而新承接方没有对应结构，那么“乱”来自结构惯性，而不是需求真的分裂。
划界动作：先建一份归属清单，再决定去留
人工目录在这里的作用，不是再做一个导航页，而是维护一份“需求—承接方—其余方角色”的清单。具体动作可以这样落地：
- 把争议需求写成一句用户任务描述，不写业务名。
- 列出当前所有声称承接它的页面，逐个标注用户进入后的下一步动作。
- 按下一步动作分组。只有一组，就选一个主承接方；多组且动作不同，就保留多个页面并写明各自适用条件。
- 对不担任主承接方的业务，明确它的角色：是补充说明、是分流入口，还是应当退出。
- 把旧系统、旧合作关系留下的入口按这份清单处理，保留仍然有价值的部分，其余逐步撤下。
这个动作的结果会直接影响下一步：如果分组后只剩一组，接下来的工作是合并内容、统一入口，并处理旧链接的指向；如果分成多组，接下来的工作是给每组写清适用条件，避免用户和内部都误以为它们可以互相替代。
一个假设的短例子
假设某站有“企业服务”和“个人服务”两条线，都认为自己该承接同一个咨询类需求。按用户任务分组后发现：从企业线进入的用户要找的是批量办理条件，从个人线进入的用户要找的是单次办理方式。两者下一步动作不同，属于解释一，应保留两个页面并各自写明适用对象。反过来，如果两组用户进来后都只是想看一份办理说明，那就是解释二，应确定一个主页面，另一个改为指向它。这个例子只用于说明比较方法，具体数字和结论要按实际页面证据判断。
退出时保留什么，撤掉什么
划界完成后，退出决策才有依据。仍然有价值的部分通常是：能独立承接某一组用户任务的页面、被外部引用的稳定入口、以及说明适用条件的少量内容。可以撤掉的是：与主承接方任务重叠、只服务于已收缩业务身份、且没有独立用户价值的页面。
撤下不等于立刻删除。更稳妥的顺序是先确认承接方页面已经能独立回答该需求，再调整旧入口的指向，最后处理残留页面。每一步之后都观察用户路径和索引状态的变化，用后续证据修正清单，而不是一次拍板就不再回看。归属清晰了，多个业务才不必靠重复覆盖来证明自己的存在。
