细雨算法应对，目标客户改变后哪些页面可以继续使用
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /360e6bc68e75.html
📄
细雨算法应对，目标客户改变后哪些页面可以继续使用
可以直接继续使用的，是那些“内容主体仍然成立、只是读者换了”的页面；需要改写的，是“结论依赖旧客户身份”的页面；应当停用或合并的，是“只为旧客户定制、对新客户没有独立价值”的页面。判断依据不是页面新旧，而是页面回答的问题是否仍然被新客户需要。
先按内容与客户身份的绑定程度分三类
把现有页面逐条过一遍，问一个具体问题：这个页面的结论，是否只有在“旧客户”这个前提下才成立？按绑定程度可以分成三档。
- 可继续使用：讲的是行业通用流程、基础概念、常见误区。读者从旧客户换成新客户，问题本身没变，页面只需微调措辞和举例。
- 需改写再用：主题仍然相关，但正文里的价格区间、合规前提、渠道选择、案例背景都指向旧客户。骨架留下，论据和例子要换。
- 应停用或合并：页面存在的唯一理由是服务旧客户的特定场景，新客户不会搜索也不会需要。这类页面继续留着，只会让站点主题变得含糊。
这个分法能落地的关键，是每一档都要有可核对的证据，而不是靠感觉。比如“需改写”的页面，证据是正文里出现了旧客户特有的术语、资质或采购方式；“应停用”的页面，证据是新客户在站内找不到任何一条指向它的内链，也没有其他页面需要它作为补充说明。
把分歧转成可以核对的项目
多个角色对“这页还能不能用”有不同理解时，争论往往停在印象层面。有效的做法是把分歧拆成几个能被不同人独立核对的项：
- 页面主标题和首段承诺解决的问题是什么，写下来。
- 这个问题在新客户身上是否仍然存在，由业务侧确认。
- 正文中依赖旧客户身份的段落有哪些，逐段标出。
- 去掉这些段落后，页面是否还有独立可读的主体。
四项都指向“仍然存在且有主体”的，进入可继续使用或轻改写；只剩标题和零散句子的，进入停用或合并。这样处理的好处是，讨论对象从“我觉得”变成“第几段依赖旧身份”，分歧可以被逐条验证。
一个会让结论失效的反例
上述判断有一个前提：新客户与旧客户搜索的是同一类问题，只是身份标签不同。如果目标客户改变的同时，需求本身也换了，那么“内容主体仍然成立”这个结论就不成立。
假设一个页面原本面向个人用户，讲的是“如何自己完成某项操作”；现在目标客户换成企业采购方，他们关心的不是自己动手，而是供应商资质、交付周期和责任划分。此时页面标题可能还沾边，但正文回答的问题已经错位。这种情况下，继续使用只会让新客户进来后立刻离开，正确动作是新建页面承接新问题，把旧页面保留给仍然存在的个人用户，或用它做对比说明。
判断是否落入这个反例，可以看一个信号：新客户在咨询或搜索时使用的核心动词，是否和旧客户不同。动词从“怎么做”变成“怎么选”“怎么验收”，通常意味着需求已经换了，而不只是读者换了。
下一步动作：先改一页，再决定其余
不要一次性重写全部页面。先选一个处于“需改写”档、且业务侧确认新客户仍会关心的页面，只做一件事：把正文中依赖旧客户身份的段落替换为新客户的对应前提，标题和 URL 保持不变。
动作完成后观察两件事：新客户是否能从这一页继续点击到其他相关页面；站内是否还有页面需要引用它作为前置说明。如果内链关系能自然接上，说明这类页面的改写方向可用，可以按同一标准批量处理；如果改完后它变成一座孤岛，既没有入口也没有出口，那它更可能属于应合并或停用的一档，而不是改写对象。这个结果会直接决定你接下来是扩大改写范围，还是先做一轮页面合并。
