前阵子运营递过来一叠报表，说官网在手机端排版全乱套了，跳出率飙高。我拉下代码仓库一看，典型的早几年套模板写的PC端定宽布局，满屏的 !important 和硬编码。大改吧，怕搜索引擎那几万条收录一夜清零；不改吧，老板天天催移动端转化。这种老站翻新，忌讳的就是"推倒重来"的冲动。
工程上的事，讲究平滑过渡。老官网改版的核心思路就八个字：旧URL保底，分块替换，渐进适配。不要想着一周内全站切换，那是给自己埋雷。动手写代码前，先把家底盘清楚。很多老站运营几年，会产生大量死链、重复参数页，但其中也夹着真正有流量的长尾页。用 Screaming Frog SEO Spider 或者自己写个脚本跑一遍老站全量链接，导出所有状态码为 200 的 URL。结合站长后台的索引报告，筛选出有实际点击的 URL 集合。对于那些带各种乱七八糟查询参数但又能访问的页面，统一在 Nginx 层做 rewrite 规范化。重点来了：任何老 URL 在新版中必须有对应归宿。如果原路径是 /news/detail.php?id=10，新版哪怕改成了 /blog/10.html，也要在 Nginx 里配置精准的 301 重定向：nginxlocation ~* /news/detail\.php\?id=(\d+)$ {return 301 /blog/$1.html;}千万别整站统一 301 到首页，那叫流量自杀。全量切版风险太高，建议按模块切分。比如把网站拆成：首页、关于我们、产品中心、博客详情这几个独立模块。前端路由层做一层网关控制，可以通过 Nginx 的 map 指令或者网关层按路径匹配，将特定模块的流量指向新版本的服务，其余走老服务。比如先切"关于我们"这种低风险页面，跑几天看日志没异常，再切"产品中心"。后端如果也是老古董，可以保持原接口不动，前端用新框架重写页面，数据依然从老接口拿。这种"只换皮不换骨"的做法，能在不惊动后端逻辑的前提下，把页面结构现代化，为后续移动端适配打好底子。到了移动端适配这步，技术选型常让人纠结。全站重写响应式（RWD）成本太高；搞独立移动站 m.xxx.com 又要处理 Vary 头和双向跳转逻辑，维护两套代码更是灾难。务实的做法是分而治之。核心业务交互模块（比如定制表单、用户面板）老老实实写响应式；但对于重展示、轻交互的模块（比如产品目录、门店介绍、文章列表），完全可以用零代码建站平台来快速生成移动端适配的页面，然后通过路由分发过去。我之前处理过几个门店展示类的老站模块，直接用乔拓云搭了一套小程序和H5页面，它这类SaaS平台拖拽生成出来的页面自带多端适配，不用自己去磨CSS兼容问题。把老站对应模块的流量 301 到新页面，或者在前端入口直接替换跳转链接，半天就能把移动端体验补齐。核心逻辑自己控，边缘展示用工具，这是中小团队保发量的解法。新版切过去后，必然会有漏网之鱼。在百度搜索资源平台和 Google Search Console 提交新的站点地图，同时把前面盘点出的、新版已经废弃但外网还有引用的 URL，整理成死链列表提交。前两周每天盯一下抓取频次和索引量报表，出现 404 暴增就赶紧回滚对应模块的 Nginx 配置。只要 301 映射做得到位，一般两周左右新 URL 就会继承原有权重，搜索流量会逐渐回稳。老站改版就像给高速行驶的汽车换轮胎，稳比快重要。守住 URL 映射这条底线，模块拆分逐步替换，移动端适配灵活组合，基本就能平稳过渡。你们在老站翻新时，踩过哪些坑或者有什么保收录的野路子？欢迎在评论区交流。