细雨算法：内容与技术如何协作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /229a1727be03.html
📄
细雨算法：内容与技术如何协作
细雨算法并不是一个可以单独配置的开关，而是一类针对低质、拼凑、采集内容的过滤思路。内容与技术协作的核心是：技术侧负责把内容以可抓取、可理解、可验证的方式呈现，内容侧负责确保每一页有独立价值和清晰主题。两者通过统一的页面规范、发布流程和检查清单衔接，而不是各做各的。
先分清抓取、索引与排名，再谈协作分工
抓取是搜索引擎发现并下载页面，索引是判断页面是否值得存入可检索库，排名是在索引基础上对候选页面排序。细雨算法这类质量过滤，主要作用于索引和排名阶段，但前提是页面能被正常抓取。协作中最常见的返工来自把三者混为一谈：内容团队觉得“写了就该有流量”，技术团队觉得“页面能打开就没问题”。
可以按下面的方式划分责任：
- 技术侧：保证服务器可访问、返回正确状态码、页面主体内容不依赖复杂交互才能出现、移动端可读。
- 内容侧：保证标题与正文一致、信息有出处或可验证、不同页面之间不重复堆叠同一段文字。
- 共同侧：确定哪些页面允许被索引，哪些页面应设为不索引，避免低质页被大量收录后稀释整体质量判断。
内容与技术协作的最小交付物
多人协作减少返工的关键，是把口头约定变成可检查的交付物。以下清单适用于内容编辑、前端开发和SEO负责人三方配合的场景：
- 页面主题卡：每篇内容先写清目标主题、目标读者、与已有页面的区别。技术侧据此判断是否需要新建页面，还是合并到已有页面。
- 标题与摘要规范：标题只对应一个主题，摘要说明页面能解决什么。避免多个页面使用高度相似的标题和摘要。
- 正文结构约定：规定正文使用哪些标签层级，例如小节统一用
<h2>，子项用<h3>，正文段落用<p>。技术侧负责检查标签是否正确闭合、层级是否跳级。 - 发布前检查项：页面能否直接访问、正文是否在HTML源码中可见、是否有重复段落、是否误设不索引。
这些交付物的代价是前期多花时间，收益是减少上线后的反复修改。如果团队规模很小、更新频率低，可以只保留主题卡和发布前检查项；如果页面量大、多人同时编辑，则建议全部保留。
遇到质量波动时，按条件排查而不是猜算法
页面流量下降可能有多种解释：抓取异常、索引被移除、排名竞争变化、内容质量被重新评估，也可能是站点整体结构调整。没有定位之前，不要断言是某个算法导致。可以按下面的顺序检查：
- 先看页面是否仍能被访问，返回状态码是否正常。
- 再看页面是否仍在索引中，标题和摘要是否被替换成不相关内容。
- 然后对比同主题页面，检查是否存在大量重复段落或模板化文字。
- 最后检查近期是否有批量发布、批量改版或大量采集内容上线。
判断结果的方式很直接：如果只有个别页面波动，优先查该页面的内容差异和内部链接；如果整站大批页面同时波动，优先查技术配置和发布流程。假设某次改版后，多个栏目页正文被折叠进交互组件，源码中只剩导航文字，这就属于技术呈现问题，而不是内容质量本身的问题。
选择协作方式：先定流程，再定工具
工具不能替代流程。选择协作方式时，先回答三个问题：谁负责最终发布、谁有权修改标题和结构、出现问题时谁先排查。回答清楚后，再决定用文档、表格还是工单系统记录。适用条件是团队有固定发布节奏；如果只是临时更新几篇内容，简单约定即可，不必引入复杂审批。
下一步可以从一篇即将发布的页面开始，让内容侧填写主题卡，技术侧按发布前检查项逐条确认，把发现的问题记录成下一次的检查项。
