细雨算法应对 - 改版前怎样保留搜索基础
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2124978b3a80.html
📄
细雨算法应对 - 改版前怎样保留搜索基础
改版前保留搜索基础的核心做法是：先冻结旧版可访问性与页面结构，再按“内容对应关系”做迁移映射，最后用可回滚的灰度上线验证抓取与索引信号。细雨算法应对的关键不在改版后补救，而在改版前把旧页面的价值完整交接给新页面。
先判断你的改版属于哪一类风险
不是所有改版都会伤搜索基础。风险高低取决于旧页面是否被索引、是否有稳定外部链接、是否承载长尾流量。可以按下面三类区分：
- 低风险：只改视觉样式、前端框架，URL、正文、标题、内链都不变。这类改版重点验证渲染后内容是否仍可被抓取。
- 中风险：URL 不变但模板结构、正文位置、导航层级调整。需要检查正文是否被移入需要交互才显示的区域。
- 高风险：URL 规则改变、栏目合并、页面删除、内容重新拆分。必须逐条建立旧 URL 到新 URL 的对应关系。
多人协作时，先让所有人对“本次改版属于哪一类”达成一致，再决定要交付哪些清单，否则返工大多来自对风险等级的判断不一致。
改版前必须交付的三份清单
1. 旧页面价值清单
从站点地图、抓取日志、内链结构三个来源整理旧 URL，至少记录：URL、页面标题、是否被索引、是否有站外链接、是否带来持续访问。判断依据是“这个页面是否已经在搜索结果中承担入口作用”，而不是它在你眼里是否重要。
2. 新旧对应映射表
每条旧 URL 必须落到一个明确结果上，不能留空：
- 保留：URL 与内容都不变。
- 替换：旧 URL 对应到新 URL，且新页面承接同一主题。
- 合并：多个旧 URL 指向一个新页面，新页面需覆盖原有主题。
- 下线：确认无搜索价值后返回合适状态，并给出理由。
映射表要指定负责人和验收人，避免出现“这条还没定”的中间状态上线。
3. 可回滚方案
改版上线前保留旧版可访问路径或备份，明确回滚触发条件，例如新页面大面积无法被抓取、核心入口返回错误。回滚方案要写清由谁在什么信号出现时执行，而不是只写“必要时回滚”。
上线时的检查项与验收信号
以下检查项可直接执行，适用于中高风险改版：
- 随机抽取映射表中的旧 URL，确认访问后到达预期新页面，而不是首页或错误页。
- 检查新页面正文在禁用脚本的情况下是否仍可见，避免内容只存在于交互后才加载的区域。
- 确认新页面的标题与主题和旧页面一致，没有把不同主题的页面合并到同一个标题下。
- 检查内链是否已从旧 URL 更新为新 URL，避免站内仍指向已下线地址。
- 用抓取工具模拟访问，确认返回状态与映射表记录一致。
验收信号分阶段看：上线后先看抓取是否正常、状态码是否正确；再看新 URL 是否进入索引；最后才观察原有关键词入口是否由新页面承接。抓取、索引、排名是不同环节，前一环没通过时，不要用后一环的波动判断改版成败。
多人协作中减少返工的分工方式
把工作拆成三条互不重叠的线：内容线负责映射表与页面主题对应，技术线负责状态码、可抓取性与跳转实现，验证线负责按清单逐条检查并记录结果。每条线只对自己的交付物签字，验证线不参与修改，避免自己检查自己。
如果团队规模小，至少保证“做映射的人”和“验映射的人”不是同一个。改版前把映射表冻结一次，改版中只允许按流程变更，不接受口头临时调整。
下一步：先拉出旧页面价值清单，标出有索引和有站外链接的 URL，再据此确定本次改版的风险等级和必须交付的映射条目数量。
