细雨算法 - 用决策清单建立页面优化清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /749fba83c53f.html
📄
细雨算法 - 用决策清单建立页面优化清单
“细雨算法”在中文SEO语境里，通常指一种针对低质、采集、拼接或体验薄弱页面的质量治理思路。要围绕它建立页面优化清单，关键不是背规则，而是按“先判断风险、再决定投入、最后验证效果”的顺序，把每个页面放进一张可执行、可复查的清单里。
先判断：哪些页面值得放进清单
不是所有页面都需要同等优化。你可以先按以下条件做一次筛选：
- 有流量但停留短：说明用户被吸引进来，但内容没有解决他的问题。
- 有展现但点击低：标题和摘要可能没有准确对应搜索意图。
- 内容重复或拼接明显：同一主题多个页面讲相似内容，容易互相竞争。
- 页面主体信息不足：正文短、缺少数据、步骤、条件或可验证细节。
判断结果可以分成三类：优先改、观察后再改、暂时不动。优先改的是“有获取潜力但质量明显不足”的页面；观察后再改的是数据波动大、还看不清问题的页面；暂时不动的是没有搜索需求或已经完成使命的页面。这样做的代价是需要先花时间做数据筛选，但能避免把精力平均撒在所有页面上。
清单结构：按抓取、索引、内容、体验四层组织
把 SEO 理解为改善用户获取内容与搜索引擎理解页面的过程，抓取、索引、排名是不同环节。页面优化清单也应分层，而不是把所有问题混在一起。
- 抓取层：页面能否被正常访问，是否存在错误状态码、异常跳转或阻止抓取的设置。
- 索引层：页面是否被允许索引，是否有重复版本或规范链接指向不清。
- 内容层：页面是否直接回答目标问题，是否有足够的信息增量，而不是同义改写。
- 体验层：主要信息是否容易看到，移动端是否可读，交互是否干扰阅读。
每一层都写成一个可勾选的动作。例如内容层不要写“提升质量”，而写“补充一个可执行步骤，并说明适用条件”。这样清单才能被不同人重复执行。
比较条件与代价：先改什么，后改什么
建立清单时，常见的选择是“先改全站模板”还是“先改单页内容”。两者条件和代价不同：
- 先改模板：适合大量页面存在相同结构问题，比如正文被大量推荐模块挤到下方。代价是影响面大，改完需要抽查多个页面。
- 先改单页：适合问题集中在少数高潜力页面。代价是见效范围小，但验证快、风险低。
- 先改内容：适合页面已被索引但无法满足搜索意图。代价是需要持续补充真实信息，不能靠一次调整完成。
- 先改技术：适合页面无法被抓取或索引。代价是可能需要开发配合，但它是后续优化的前提。
判断顺序可以简单记为：先排除技术阻断，再处理内容意图，最后微调体验。如果页面根本进不了索引，先改标题和正文的收益很有限。
一个可执行的清单示例
假设你有一个介绍“细雨算法”概念的页面，怀疑它内容太薄。可以按下面步骤处理：
- 检查页面是否返回正常状态，是否允许索引。
- 确认页面主题是否只讲一个核心问题，而不是把算法、建站、推广混在一起。
- 在正文中补充一个判断条件，例如“当页面已有稳定展现但点击率低时，先检查标题与摘要是否对应搜索意图”。
- 删除与主题无关的重复段落，保留可验证的步骤和例子。
- 改完后记录修改日期、修改位置和观察指标，过一段时间再对比。
这里的“例子”是假设场景，不是真实项目结果。它的作用是说明清单如何落地：每条都要有动作、有对象、有判断结果。
检查项：怎样知道清单是否有效
清单写完不等于有效。你可以用以下检查项判断：
- 可执行：另一个人拿到清单，能否知道先做什么、后做什么。
- 可判断：每条是否给出通过或不通过的条件，而不是“尽量优化”。
- 可复查：是否记录修改前后的状态，方便后续对比。
- 有边界：是否说明哪些页面不适用，避免过度修改。
如果一条清单无法判断结果，就把它拆成更小的动作。例如“提升页面质量”可以拆成“补充一个步骤说明”“删除一段重复内容”“检查移动端首屏是否出现核心信息”。
下一步，选一个已有页面，按抓取、索引、内容、体验四层各写一条检查项，先跑完一轮，再决定是否扩展到更多页面。
