细雨算法，资源有限先处理哪些问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3a480b0690d7.html
📄
细雨算法，资源有限先处理哪些问题
细雨算法不是某个可以查询状态的官方算法名称，而更像是SEO从业者对一类现象的概括：页面能被抓取，却长期只获得很少的索引和展现。资源有限时，先处理影响面最大、最容易验证的问题，而不是同时修改所有页面。假设你负责一个三百页的内容站，团队只有两个人，每周能改二十页。此时应先把页面分成三组：完全没被收录的、被收录但几乎没有展现的、有展现但点击很低的。第一组优先，因为没进索引，后面所有优化都无从谈起。
先确认问题出在抓取、索引还是排名
这三个环节的检查方法不同。抓取看服务器日志里搜索引擎爬虫是否访问过目标URL；索引看站点查询结果中该URL是否存在；排名看具体查询下页面是否出现过。若日志里根本没有访问记录，先查内链和站点地图；若有访问但未收录，先查页面内容是否过薄、是否与已有页面高度重复；若已收录却无展现，再考虑标题、需求和竞争度。把三类问题混在一起改，最容易返工。
假设例子：两个人两周的优先级安排
假设站点有三百页，其中八十页未被收录，一百五十页已收录但近三个月没有展现，七十页有稳定展现。两人团队按下面顺序执行：
- 第一周只处理未被收录的八十页。先按模板归类，若同一模板下大量页面都未收录，优先修模板，而不是逐页改文案。
- 对每类模板选三到五个代表页做检查：是否有独立价值、是否有内部链接指向、是否被 robots 或 meta 误挡。确认原因后再批量修。
- 第二周处理已收录无展现的页面。先看这些页面是否回答了明确需求，标题是否与查询意图一致。只改标题和首段，不动整页结构，便于判断改动是否有效。
- 有展现的七十页暂不处理，除非点击率明显异常。资源有限时，不要为了“统一风格”去改已经能带来流量的页面。
常见错误是反过来做：先优化有流量的页面，因为数据好看；或者平均分配，每类都改一点。前者收益小，后者无法判断哪类改动起了作用。更稳妥的做法是每轮只动一个变量，并记录改动前后的收录与展现变化。
多人协作时怎样减少返工
交付不清是返工的主要来源。每个页面应有一张简短记录，写清：目标查询、当前状态、判断依据、本次改动、复查日期。判断依据要能复核，例如“日志显示爬虫访问过但未收录”，而不是“感觉页面质量不行”。分工上，一人负责归类与判断，一人负责执行修改，复查由执行者之外的人做，避免同一人既改又判。
- 检查项一：未收录页面是否集中在同一模板或同一目录。
- 检查项二：已收录无展现页面是否针对了不存在搜索需求的词。
- 检查项三：改动是否只涉及一个变量，能否在两周后对比。
判断结果与适用条件
如果修完模板后，同类未收录页面开始出现索引，说明方向正确，可以继续处理剩余同类页。如果两周后仍无变化，不要立刻换方法，先确认改动是否真的生效、爬虫是否再次访问。若已收录页面改标题后展现上升，可扩大同类改动；若没有变化，说明问题可能不在标题，而在内容与需求的匹配度。这套顺序适用于页面数量多、人力少、且能查看日志和索引状态的团队；若站点只有十几页，逐页检查反而更快。
下一步：先导出全部URL及其收录状态，按“未收录、已收录无展现、有展现”分成三组，只对第一组做原因归类，再决定本周改哪些页面。
