网站返回跳转到新站；3处漏配等于白改

「网站返回跳转到新站3处漏配等于白改」——这话真不是吓唬人。换域名、换程序、两个站合并，收尾那一步基本都落在跳转上。跳转做对了没人夸你，做错一次，前面几个月的活儿全打水漂。最典型的场面是：你在浏览器里敲老域名，地址栏唰一下变成新域名，页面也正常出来了，心里一踏实，收工。可用户从搜索结果点进来的是老站的内页，搜索引擎抓的也是那些内页，这些地址压根没跳过。

网站返回跳转到新站3处漏配等于白改，先看这三处

第一处，只给首页做了跳转。nginx 里 server 块写一行 return 301 https://new.example.com; 看着挺完整，实际上末尾少了 $request_uri，所有老地址都被拍扁到新站首页。用户从一篇老文章点进来，落在首页，找不到内容就退了。正确的写法应该是 return 301 https://new.example.com$request_uri; 老路径原样带过去。Apache 那边 .htaccess 里 RewriteRule ^(.*)$ https://new.example.com/$1 [R=301,L] 也是一个道理，括号里捕获的路径要接上。

第二处，把 302 当 301 用，或者干脆用 JS、meta refresh 糊一下。搜索引擎对 302 的理解是临时挪个地方，权重传递的信号本来就弱；JS 跳转和 meta refresh 在很多抓取场景里压根不算跳转，页面被当成一个还活着的空壳。调试阶段用 302 无所谓，正式切换就该老老实实上 301，别嫌麻烦。

第三处，规则漏了分支。带参数的地址、大小写不同的地址、www 和裸域、http 和 https，这四组乘起来就是八种入口，规则只覆盖一半，剩下那半就是漏网地址。尤其带问号那批，rewrite 里没写 $args 或 $request_uri，参数直接掉，用户打开的是一个内容不匹配的页面。结尾斜杠也一样，/old-page 和 /old-page/ 在某些规则里会被当成两条不同的东西，测试的时候两种都敲一遍。

一条 curl 就能分出真跳假跳

浏览器太宽容，它会替你跑完全部跳转，你看到的是终点，看不到中间发生了什么。用 curl -I 看响应头最直接：状态码是 301 还是 302，Location 指到哪儿，一眼就清楚。多测几条——首页、一条老内页、一条带参数的、一条大写字母的。比如 curl -I https://old.example.com/old-page?id=123，返回 200 就等于没跳，返回 301 并且 Location 里把 /old-page?id=123 完整带过去了，才算过关。这条命令花不了半分钟，能省掉后面一堆扯皮。

老站留下的 sitemap 和 robots，八成没人管

站点换了，老域名根目录下还躺着 sitemap.xml 和 robots.txt，里面写满老地址。抓取程序按图索骥去爬，爬到的要么 404 要么转圈跳，抓取额度白扔，还容易让人误判站点状况。这两份文件在老站上要么改成指向新站，要么干脆一条规则全站跳走。同一类问题还有页面里的内链、canonical 标签、结构化数据里的 URL，一大半还写着老域名。这些严格说不算跳转漏配，但效果一样——你辛苦搬完家，信号还在两头分。

页面能跳，接口和图片不一定跟着走

前端跳转配好了，后台还在往老域名发请求的情况太常见。数据库里存的图片绝对地址、写死在模板里的接口域名、小程序或 APP 里配置的 API 地址，这些不跟着改，页面能打开但图片裂、表单提交失败、登录态莫名其妙掉线。还有一层是缓存：老站挂了 CDN 的话，301 响应可能被缓存住，规则改完半天不生效，得手动刷一下缓存再验证，别一上来就怀疑配置写错。

老域名先别急着撒手

见过切换完第二天就把老域名停掉的，也见过急着去办注销的，这属于自己给自己挖坑。老域名的跳转至少保留几个月，等新站收录和流量稳下来再讨论下一步。DNS、证书、备案这些牵扯主体信息的事，各地各服务商口径不一样，具体以服务商或官方页面的说明为准，别听谁一句「没事」就动手。切换期间盯着老域名的访问日志，能看到还有哪些地址在被人访问、跳到哪儿去了，比拍脑袋靠谱。

真要上手，按这个顺序过一遍：把老站 URL 列全，记得抽几条带参数的样本 → 定 301 规则，首页和内页都覆盖 → 用 curl 逐条验状态码和 Location → 改 sitemap、robots、canonical 和页面内链 → 清 CDN 缓存 → 观察一段时间老域名的访问日志。清单不长，漏掉哪一条，都够你回头重来一遍。