百度新闻源优化：搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fb62df176e73.html
📄
百度新闻源优化：搜索需求太分散时先做聚合页还是详情页
没有固定答案，但有一条可执行的判断线：如果分散需求共享同一批查询词、同一批来源类型和同一批判断标准，先做聚合页；如果每个需求各自有独立的事实链、时间线和核验对象，先做详情页。选错方向的代价不同——聚合页做早了会稀释每条的独特性，详情页做早了会让用户和搜索引擎都难以看出这些内容属于同一主题。
先看需求之间是“同类”还是“同题”
搜索需求分散，通常有两种形态。一种是同类：用户用不同说法问同一件事，比如“某政策什么时候生效”“某政策执行日期”“某政策实施时间”。这些查询指向同一个事实，只是措辞不同。另一种是同题：用户问的是同一主题下的不同侧面，比如“某政策生效时间”“某政策适用对象”“某政策例外情形”。它们共享主题，但各自需要独立回答。
同类需求适合聚合页。聚合页可以把多种问法收在一处，用同一组事实覆盖，页面主题集中，用户一次就能得到完整答案。同题需求则更适合详情页，因为每个侧面的事实来源、核验方式和更新节奏可能不同，硬塞进一个页面会让每部分都变浅。
可区分证据：把近两周的搜索词列出来，看它们能否用同一段事实回答。如果能，偏聚合；如果必须分别找不同来源、不同时间点或不同责任方，偏详情。
聚合页的成立条件与代价
聚合页成立，需要满足三个条件：第一，多个查询词的核心事实一致；第二，这些内容共享同一批来源，不需要为每个词单独核验；第三，更新时只需改一处，不会牵动其他部分。
代价是独特性被压缩。聚合页往往只能覆盖共同事实，对边缘问题只能一笔带过。如果用户实际在找某个细分答案，聚合页可能让他继续往下翻，反而增加跳出。另一个代价是后续拆分困难：一旦发现某个侧面需要独立成页，原来的聚合页要重新调整结构和内链，工作量并不小。
假设例子：假设你负责一个政务信息栏目，发现“某条例施行日期”“某条例生效时间”“某条例什么时候开始”三类查询都指向同一条时间信息。此时做聚合页，用一段准确的时间说明覆盖三种问法，是合理选择。但如果你同时发现“某条例适用范围”“某条例处罚标准”也在增长，这两者需要独立的事实链，就不应塞进同一聚合页。
详情页的成立条件与代价
详情页成立，需要满足：每个需求有独立的事实主体、独立的核验对象或独立的时间线；用户搜索时带有明确的细分意图；后续更新只影响该页，不牵动其他页面。
代价是入口分散。多个详情页之间如果没有清晰的聚合关系，用户和搜索引擎都可能只看到其中一页，难以理解它们属于同一主题。另一个代价是维护成本：每个详情页都要单独跟踪来源、单独更新，需求越多，维护负担越重。
实际动作：先为每个候选详情页写一句“它回答的唯一问题”。如果写不出来，说明它和别的页面重叠，应该合并；如果写得出来且与其他页面不重复，详情页成立。这个动作的结果直接决定下一步：能写出唯一问题的进入详情页排期，写不出的回到聚合页方案。
一个反例：共享主题不等于应该聚合
有一种情况会让“先做聚合页”的判断失效：多个需求虽然同属一个主题，但它们的答案会随时间分别变化，且变化节奏不同。例如同一主题下，一部分内容涉及最新进展，另一部分涉及历史背景。如果把两者放在同一聚合页，最新进展更新时，历史背景部分会被动跟着改版，容易造成信息混乱。
此时更合理的做法是：先做详情页，把变化节奏不同的部分分开；等各详情页稳定后，再建一个聚合页做导航和摘要。聚合页的角色从“主要答案页”变成“入口页”，而不是把所有内容压在一处。
判断反例是否成立，可以问：这些需求的上游来源是否会在不同时间分别变动？如果会，先详情后聚合；如果不会，先聚合更省力。
下一步动作：用一张对照表决定顺序
把候选需求按下面三项打分，每项只有“是”或“否”：
- 能否用同一段事实回答多个查询词；
- 是否共享同一批来源和核验方式；
- 更新时是否只需改动一处。
三项都为“是”，先做聚合页；有两项为“否”，先做详情页；介于两者之间，先做最小聚合页，只覆盖共同事实，把差异部分留作后续详情页的入口。做完这一步后，下一步不是继续加页面，而是观察这些页面是否被分别抓取和索引——抓取和索引是不同环节，页面被收录不等于它在目标查询下被正确理解，需要回到查询词和页面主题是否对应来检查。
