网站安全测试：多个业务争同一搜索需求时如何划界
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e86632c422d8.html
📄
网站安全测试：多个业务争同一搜索需求时如何划界
结论先行：只有当各业务能拿出不同的“交付物”和不同的“验证动作”时，划界才成立；如果两个业务最终提供的是同一份报告、同一套扫描流程、同一类整改建议，那么再精细的页面分工也只是内部重复。判断能不能划界，不看谁先提需求，而看用户拿到结果后下一步做什么是否不同。
先看交付物，而不是先看业务名
很多团队习惯按部门名称分页面：A业务做“网站安全测试”，B业务做“渗透测试”，C业务做“漏洞扫描”。这种分法在样本阶段看起来成立，因为每个词都能找到对应页面，但规模化后会立刻出现例外：同一用户可能在三个页面间来回跳，最后仍然不知道该选哪个。
更稳的判断依据是交付物。假设一个业务交付的是“测试报告加风险等级”，另一个交付的是“测试报告加修复后的复测确认”，第三个交付的是“测试过程记录加合规留档”。这三者的用户下一步动作不同：有人要拿去内部排期，有人要拿去验收，有人要拿去应对外部检查。交付物不同，页面边界才有意义。
如果两个业务的交付物都是“一份报告”，区别只是销售话术或行业称呼，那么它们争夺的其实是同一个搜索需求。此时划界不应靠新建页面，而应先合并入口，再在页面内部用条件说明区分适用对象。
一个反例：样本成立，规模化后失效
假设某团队发现“网站安全测试”这个词带来的用户，有一部分在咨询时问的是“测试完能不能帮我改”，另一部分问的是“测试完能不能给我一份证明”。于是他们拆出两个页面：一个讲整改配合，一个讲报告留档。小流量时，两个页面各自都有咨询，看起来划界成功。
但规模化后出现例外：同一批用户里，有人既需要整改又需要留档，而且他们并不认为自己属于两个需求。更麻烦的是，搜索引擎在理解页面时，可能把两个页面都判定为同一主题的近似内容，导致其中一个页面难以获得独立展现。此时原来的划界依据——“咨询问题不同”——就失效了，因为咨询问题可以同时存在，而页面只能服务一个主要意图。
这个反例说明：不能直接照搬的边界是“用户口头问题不同”。口头问题可以叠加，页面意图不能叠加。真正能支撑划界的，是用户完成动作后产出的文件、记录或状态变化不同，并且这些产出在流程上互斥或前后依赖。
用一组可区分原因的证据来定边界
要判断两个业务是否在争同一需求，可以收集三类证据，而不是只看关键词重合度：
- 入口证据：用户从哪个页面进入后，停留并继续访问了哪个页面。如果两个页面的用户最终都流向同一个咨询或同一个下载，说明需求未分开。
- 动作证据：用户在同一页面内点击的是“预约测试”还是“下载模板”还是“查看复测说明”。动作不同，才可能对应不同交付物。
- 结果证据：用户拿到结果后，下一步是内部排期、外部提交还是再次测试。下一步不同，页面边界才稳定。
如果三类证据里有两类指向同一动作，就应视为同一需求。此时正确的动作不是继续拆页面，而是把两个业务的内容合并到一个页面，用<h2>分段说明不同条件下的交付差异。合并后观察咨询问题是否更集中；如果更集中，说明之前的分裂是人为的。
划界后的实际动作与下一步
当确认两个业务确实对应不同交付物时，划界动作应落在页面标题、首段和主要行动按钮上，而不是只改导航文字。具体做法：为每个页面写一句“适合谁、拿到什么、下一步做什么”的首段，并让主要按钮指向不同的后续动作，例如一个指向测试说明，一个指向复测条件说明。
执行后看两个信号：第一，两个页面的跳出率是否出现明显分化；第二，咨询中是否还有大量用户把两个页面混着问。如果分化不明显，或者混问比例没有下降，说明交付物差异不足以支撑独立页面，应回到合并方案。这个判断不需要等到排名变化，因为抓取和索引只是前置环节，用户动作才是划界是否成立的直接反馈。
最后给一个可执行的检查：把两个业务各自的交付物写成一句话，如果这两句话的主语和宾语完全相同，只是形容词不同，就不要拆页面；如果一句话的宾语是“报告”，另一句话的宾语是“复测确认”，才可以考虑分开，并在页面上明确写出适用条件。
