细雨算法应对怎样避免重复建设页面：先查重叠再决定合并或改写
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b60139ae5c8d.html
📄
细雨算法应对怎样避免重复建设页面：先查重叠再决定合并或改写
避免重复建设页面的核心不是继续加新页，而是先确认哪些页面在回答同一类需求。做法是：把现有页面按主题、意图和主要关键词分组，找出内容重叠、互相竞争入口的页面，再决定保留、合并、改写或删除。只有在现有页面无法覆盖某个明确需求时，才新建页面。
先观察：哪些页面可能属于重复建设
重复建设不一定表现为文字完全一样。以下情况都值得排查：
- 两个以上页面标题不同，但都在回答同一个问题，例如“怎么选”“如何挑选”“选择方法”。
- 同一产品、同一服务、同一地点分别建了多篇介绍，内容只是换了说法。
- 列表页与详情页、栏目页与文章页之间，正文主体高度相似。
- 页面由模板批量生成，只替换了城市名、型号名或年份，其余内容基本一致。
- 旧页面已经能覆盖需求，又新建了一篇“新版”“完整版”“必看版”。
观察时不要只看字数。要问：用户搜索这个问题时，是否只需要一个答案？如果多个页面给出的是同一个答案，它们就在争抢同一个位置。
判断：重叠到什么程度才需要处理
可以先做一张简单表格，每行一个页面，列出主要关键词、搜索意图、核心结论、主要段落结构。判断依据如下：
- 意图相同、结论相同：属于明显重复，应合并或保留一个，其余设置跳转或删除。
- 意图相同、结论不同：先确认差异是否有事实依据。若只是角度不同，仍应合并成一页，用小节区分。
- 意图不同、结论不同：可以保留为两个页面，但要确保标题、描述和正文各自指向不同需求。
- 主词相同、长尾不同：不必急着拆页。如果长尾需求可以在同一页内用一个小节讲清，优先扩写原页，而不是新建。
判断结果只有三种：合并、改写、保留。新建应当是最后选项，而不是默认动作。
处理：合并、改写与新建的适用条件
合并适用于两个页面覆盖同一需求，且各自都有少量有效信息。做法是把有价值的内容并入保留页，补充缺失的小节，然后处理被合并页面的入口。若旧页面已有外部链接或用户收藏，设置跳转比直接删除更稳妥。
改写适用于页面主题正确，但内容与其他页面区分不足。改写不是换同义词，而是补充具体信息：适用条件、操作步骤、对比依据、常见失败情况。例如原页只写“要定期检查”，改写后应写清检查哪些项、多久检查一次、出现什么结果时停止。
新建只适用于现有页面无法承载的新需求。判断条件是：新需求有独立的搜索意图，且强行并入原页会让原页主题变得模糊。假设一个页面讲“如何选择”，另一个需求是“已经选错后如何调整”，后者属于不同阶段，可以考虑独立成页。
处理时还要注意内链。重复页面往往互相链接，形成循环。合并后应把内链指向保留页，避免用户和搜索引擎继续进入已废弃入口。
复查：改完后如何确认没有留下新的重复
复查分三步。第一步，重新列出所有相关页面的标题和主要关键词，确认没有两个页面指向同一意图。第二步，逐页检查正文开头，确认每页第一段回答的是不同问题。第三步，从站内搜索、导航和文章内链进入，确认用户不会同时看到两个内容相近的入口。
复查时可以使用一个短例子：假设你原有三页，分别叫“A方法介绍”“A方法怎么用”“A方法注意事项”。如果三页都在讲同一套步骤，就合并为一页，用<h2>分成“适用条件”“操作步骤”“注意事项”。如果“注意事项”里包含独立的风险判断，且内容足够支撑一个独立问题，再考虑单独保留。判断结果以用户是否需要分开查找为准，而不是以页面数量为准。
下一步：从现有页面清单开始处理
先导出站点主要页面，按主题分组，每组只保留一个主页面。对重叠页面执行合并或改写，对确实不同的需求再新建。完成一轮后，隔一段时间复查索引与站内入口，确认旧页面没有继续被用户和内部链接当作主入口使用。这样处理，重复建设会逐步减少，原有页面也能承担更清晰的获取任务。
