搭建个人博客，页面数量减少时如何保留高价值需求覆盖
📱 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15 (Applebot/0.1; +http://www.apple.com/go/applebot)
🔗 /2ecfedc98ecc.html
📄
搭建个人博客，页面数量减少时如何保留高价值需求覆盖
删页面本身不是问题，问题在于删完之后，原本由这些页面承接的搜索需求是否还有落点。一个可行判断是：先按需求簇而不是按页面数盘点，再决定合并、改写还是保留。下面用一个假设情境把决策过程走一遍。
先确认减少的是页面，还是需求落点
假设你有一个搭建了两年的个人博客，原有约一百二十个页面，其中三十篇是围绕同一主题写成的短问答，每篇只覆盖一个具体问法。现在你打算把站点压缩到六十个页面左右，第一批就准备删掉这三十篇。
此时要区分两件事：页面数量下降，和可被搜索到的需求覆盖下降。前者是结果，后者才是风险。判断方法是把每篇短问答还原成一个需求，例如“某工具在某个版本下能否完成某操作”“某类报错在某种环境下怎么排查”。如果多个页面回答的是同一需求的不同措辞，它们可以合并；如果分别对应不同前置条件，合并后就必须在正文里保留这些条件，否则覆盖会真的丢失。
抓取、索引和排名是不同环节。页面被删除后，如果内链和导航仍指向旧地址，抓取端会先遇到失效链接；即使旧地址还能被索引，用户点进来也看不到内容。因此减少页面前，先确认哪些页面有站内链接、哪些页面只靠搜索进入，处理方式会不同。
用需求簇代替页面清单做取舍
把原页面按需求簇归类，比逐页判断更稳定。可以按下面顺序操作：
- 列出每个页面回答的具体问题，写成一句话，不写标题。
- 把问题指向同一决策的页面放进同一簇，例如“是否值得做”“怎么做”“做错了怎么修”属于同一主题下的不同阶段，不一定属于同一需求。
- 对每个簇标出它服务的是哪类读者：刚接触的人、已经动手的人、遇到故障的人。
- 检查簇内是否已有页面能承接全部问法。若没有，先补一个能承接的页面，再删旧页面。
假设你发现三十篇短问答里，有十八篇其实都在回答“某操作在两种不同前提下分别怎么做”。这时更合理的动作不是删掉十八篇，而是把它们合并成一篇带前提分节的长文，并在原地址做跳转。合并后页面数量减少，但两种前提仍然有落点。
剩下的十二篇如果分别对应不同工具、不同版本或不同使用阶段，就不能简单合并。此时应保留或改写为独立页面，而不是为了压缩数量强行塞进一篇。页面数量减少不是目标，需求覆盖不丢才是目标。
合并之后必须验证三件事
合并或删除后，不要只看页面总数变化。至少要验证：
- 入口是否还在。原页面如果有站内链接，链接应指向新页面或跳转后的地址；如果只靠搜索进入，则要观察新页面是否承接了原来的问法。
- 内容是否仍能回答原问题。把原页面的核心问法逐条对照新页面，缺哪条就补哪条，而不是只保留一个概括段落。
- 是否出现新的空白。合并常会丢掉边界条件，例如“在某种限制下不适用”。这类条件如果被删掉，读者会按错误前提操作，覆盖等于没有保留。
这里要说明一个容易误判的现象：某个旧页面的搜索请求量下降，不能单独证明合并正确。它也可能是季节波动、搜索词迁移、竞争页面变化，或者新页面尚未被充分抓取和索引。反过来，旧页面请求量没有立刻下降，也不能证明它应该保留——可能只是索引和展示存在延迟。把请求量当作唯一证据，容易把“还没生效”误读成“处理正确”。
什么条件下可以继续减少页面
如果验证后满足以下条件，可以继续压缩：新页面能覆盖原簇内全部问法，站内入口已更新，且没有出现新的前提空白。此时减少页面是在提高内容集中度，而不是在牺牲覆盖。
如果出现以下任一情况，应暂停删除：原问法在新页面中没有对应段落；旧地址仍有站内链接未处理；某个需求簇只剩一个页面，而该页面同时承担多个不同前提。此时更稳妥的动作是先补内容或补入口，再继续压缩。
对个人博客来说，页面数量少并不天然更好。真正要保住的是那些能承接具体决策、具体前提和具体故障排查的落点。删页面之前先问一句：这个需求换到新页面后，读者还能不能找到答案。答案是否定的，就先别删。
