辛辛苦苦上线新版本，结果搜自己网站，首页跳出来的全是旧模板、老文案、过期功能——不是用户找不到新东西，是搜索引擎压根没认出“这才是最新版”。
这事儿真不怪算法，怪我们总把版本更新当成“换皮肤”，忘了告诉搜索引擎：旧衣服该收柜子了，别再翻出来晾着。
为什么版本更新后，旧页面总像“打不死的小强”？
搜索引擎蜘蛛不是你同事，不会盯着你的发布日历。它上次抓的可能是三天前的旧页面，而你今天刚上线的新版，它还不知道。
更麻烦的是：服务器对旧 URL 没报错，就等于默认“这页还活着”。200 状态码一返回，蜘蛛照常收录；302 重定向一打，它以为只是临时挪个地方；连 canonical 都没写，那它只能靠猜——猜哪个才是你真正想推的版本。
真实案例：一个知识付费平台每季度迭代课程详情页结构。他们直接覆盖了 v1/course.html 文件，但没动 URL，也没做任何跳转。三个月后，搜索“Python 入门课”，前三名里两个是 v1 版本（标题还是“2022 年新版”，封面图里讲师穿的是去年的衬衫），最新版排在第 17 位。流量没涨，咨询量反而下滑，直到查重复收录率，发现近三成索引页内容高度雷同。
三个步骤，从根源切断重复收录
重复收录的本质就一句话：搜索引擎分不清谁才是“正主”。 解决它不需要黑科技，只需要每次发版时，多做三件确定性的事。
第一步：上线前，先把旧 URL 的路堵死
别等新版本跑起来了再回头收拾旧页面。部署前，就把所有旧版本 URL 列出来，在 Nginx/Apache 或云服务商控制台里，统一加 301 重定向到对应的新版地址。
如果是动态参数版本（比如 ?v=1），那就让所有带 v=1 的请求，301 到 ?v=2 或无参主 URL。别指望用户或内部链接会自动更新——它们大概率还指着旧地址。
第二步：给新页面贴一张“身份证”，用 rel=canonical
301 是最有力的指令，但总有漏网之鱼：某个埋在后台的跳转链接没改、某条邮件里的旧 URL 还在传播、甚至缓存 CDN 把旧页又吐了出来……这时候，rel=canonical 就是你最后的托底。
把它加在新版本页面的 <head> 里，值必须是当前页面的绝对 URL。哪怕蜘蛛误入旧页，看到这个标签，也会把权重、排名信号往新地址上归拢。
第三步：用 robots.txt 和 sitemap 做“广播通知”
robots.txt 不是摆设。在里头明确写上：
Disallow: /v1/
Disallow: /?v=1
Disallow: /old/
告诉所有爬虫：“这些路径别来了，我不欢迎。”
同时，只在 sitemap.xml 里提交你认可的最新版本 URL。搜索引擎每天看 sitemap，就像查值班表——你只报新班次，它就不会再去旧工位打卡。
动态参数版本 vs 静态目录版本，处理方式完全不同
别拿一套方案硬套两种结构。它们的技术逻辑和风险点，根本不在一个频道上。
动态参数版本（如 page.html?v=2）
核心问题是：同一个页面，靠参数“变装”出多个 URL。搜索引擎可能认为这是不同内容。国内主流搜索工具对参数识别有限，所以最稳妥的做法是——服务端强制归一：所有带旧参数的请求，一律 301 到无参主 URL 或最新参数版本。然后新页面自己带上 canonical，指向这个归一后的地址。
静态目录版本（如 /v2/page.html）
真正的坑在于“删得太干净”。很多人上线 v2 后，顺手把 /v1/ 整个文件夹删了。结果访问 /v1/page.html 直接 404，大量死链堆积，蜘蛛抓取预算被浪费在报错上，新页面反而难被发现。
正确做法是：保留 /v1/ 目录，但把里面每个页面都 301 到 /v2/ 对应路径；再在 /v1/index.html 里放一句提示：“页面已迁移，请访问新版”，顺便加个跳转 JS（非必须，但对用户友好）。这不是妥协，是给搜索引擎留个台阶下。
案例：一个招聘社区从 /job/v1/ 迁移到 /job/v2/。初期直接删掉 v1，导致站内搜索点击率断崖下跌，GSC 显示“已发现但尚未抓取”的 URL 数暴增。后来补上全量 301，两周内抓取频次回升，新职位曝光速度明显加快。
如何用工具快速揪出隐藏的版本重复页面？
别靠肉眼翻，也别等用户反馈。下面三个方法，十分钟就能摸清底数。
方法一：用 site: 指令直接问搜索引擎
在 Google 或百度搜索框里输入：
site:yourdomain.com inurl:v1
site:yourdomain.com inurl:?ver=
site:yourdomain.com inurl:/old/
看看返回多少页。如果一眼扫过去全是旧版，说明问题已经外溢了。
方法二：用 Screaming Frog 扫一遍站内相似内容
打开工具 → 设置“Content Hash”或“Similarity %”检测（建议阈值设为 90%）→ 导出相似页面列表。重点筛那些 URL 带 v1、old、?ver= 的行，点开对比——八成内容一模一样，只是地址不同。
方法三：翻 Google Search Console 的“索引状况”报告
进「索引」→「页面」→ 点开“为什么未编入索引”。如果一堆带版本号的页面卡在“已抓取但尚未编入索引”，说明蜘蛛正在原地打转：它抓到了，但不确定该不该收。这就是典型重复收录预警。
版本发布后，如何确认重复收录问题已被解决？
发版不是终点，验证才是关键动作。别等一周后看流量，24 小时内就得动手查。
24 小时检查清单：
- 随机选 5 个旧 URL，浏览器里打开，看是否跳转到新版（不是 200，不是 404，是 301）；
- 打开新版页面，右键查看源代码，确认
<link rel="canonical" href="...">的值是当前页完整地址； - 再搜一次
site:yourdomain.com inurl:v1，结果页数应该比发布前少了一半以上。
48 小时检查清单：
- 用 Screaming Frog 重新跑一遍，旧 URL 的状态码列里，200 应该基本清零，变成 301 或 410；
- GSC 的「索引覆盖」报告中，“已排除”类别的页面数是否明显增加（说明旧页正在退出索引）；
- 整体收录量短期可能微降（剔除重复页），但新页面的“已编入索引”数量要开始稳步上升。
真实案例：一个 SaaS 工具官网把帮助中心从 /docs/v1/ 升级到 /docs/v2/。按上述流程操作后，第三天起，v1 页面在 GSC 中的“已排除”数量每天增加 30+；第七天，v2 页面的自然搜索曝光量开始爬升，用户通过搜索进入帮助页的占比两周内提升明显。
团队协作中，版本管理最容易踩的三个坑
技术能修，流程才能防。很多重复收录问题，根子不在代码，而在没人盯住“URL 归属权”。
坑一：前后端各干各的，URL 状态没人兜底
前端改了组件，但没同步更新 canonical；后端加了新 API 参数，却忘了在 Nginx 里配对应的 301 规则。结果就是：页面看着新，搜索引擎眼里还是旧。
解决办法很简单：在每次需求评审文档末尾，加一行固定字段——【URL 处理方案】，写明：哪些旧 URL 要重定向、由谁配置、由谁验收。把它当成和“按钮颜色”“接口字段”同等重要的交付项。
坑二：测试环境 URL 泄露，被蜘蛛当真了
本地开发用 localhost，测试环境却用了 test.yourdomain.com 或 staging.yourdomain.com，而且没加 robots.txt 限制。结果蜘蛛一爬，发现一堆带 test 的页面，还都返回 200……它真信了那是正式版。
解决办法：测试环境必须加两道锁——robots.txt 里写 User-agent: * Disallow: /，再加一层 HTTP Basic Auth 密码保护。宁可开发时多输一次密码，也不能让蜘蛛白忙活。
坑三：上线 checklist 里没有“旧页清理”这一项
产品经理说“新功能上线即闭环”，运维说“服务已重启”，但没人问一句：“v1 目录还在吗？旧参数跳转配好了吗？”
结果就是，新功能光鲜亮丽，旧页面阴魂不散。
解决办法：把“确认旧版本 URL 已全部 301 或屏蔽”写进 CI/CD 发布流水线的最后一个 check 步骤。不通过，就不允许 deploy。
今天就能执行的三个具体操作
别等下次发版，现在打开电脑就能做：
打开浏览器，访问
https://www.google.com/search?q=site%3A你的域名.com+inurl%3Av1（把“你的域名.com”换成你自己的）
看搜索结果有多少页。如果超过 5 页，立刻登录你的服务器或 CDN 控制台，在robots.txt里追加一行Disallow: /v1/，保存并提交 sitemap 更新。打开终端或命令行，运行
curl -I https://你的域名.com/v1/home.html（换成任意一个你知道的旧 URL）
看返回头里有没有HTTP/2 301和Location: https://你的域名.com/v2/home.html。如果没有，马上去 Nginx 配置或云函数里补上这条重定向规则。登录 Google Search Console → 左侧菜单「删除」→ 「临时移除」→ 「网址」
把刚才搜出来的前 10 个旧版 URL 粘贴进去，提交。这能让它们立刻从搜索结果消失（7 天有效），为你争取时间把服务器状态码彻底修好。
版本管理不是 SEO 的附加题，它是每次上线的必答题。当你习惯在 merge request 里附上重定向配置、在 PR 描述里写明 canonical 变更，重复收录，就真的不会再找上门。