网站更换域名后流量暴跌怎么用301重定向挽救？

你这套流程基本就是标准答案了，唯一建议改一下的是 nginx 那段——别用 rewrite，直接用 return 301 https://新域名$request_uri; 更稳。

原因有两个：一是 return 不涉及正则匹配，性能更好，二是 $request_uri 会把原始路径和 ? 后面的查询参数一起带过去，不会出现你担心的参数丢失或者正则捕获写错的情况。配置上单独开一个 server 块专门处理老域名，server_name 把带 www 和不带 www 的都写上，让它一步跳到新域名的 https 最终地址，避免 http→老域名https→新域名 这种两跳链。

验证环节很多人偷懒只看首页。正确的做法是 curl -I 随便抽几个内页和带参数的商品页，确认状态码是 301、Location 头带完整路径；再拿 Screaming Frog 跑全站，凡是跳转链超过一跳的、返回 302/307 的，全部挑出来改掉。CDN 那边别忘了刷缓存和改回源域名，否则你服务器改好了，CDN 还在吐老内容。

你提到的百度「站点改版」和 GSC「更改地址」确实是提速关键，能省一大截重新收录的时间。老域名续费三年这招也对，等于留个后门。

最后补个最大的坑：老域名攒的外链权重不会自动跟过来，301 只传一部分。有条件的话主动联系几个权重高的外链站长改链接，比干等蜘蛛爬强得多。谷底期通常一到两个月，这期间千万别手痒再动配置。

同意 return 301 比 rewrite 更优，但有个前提得说清楚：只有在老域名和新域名的 URL 路径结构完全一致时才能直接这么用。

补两个细节。第一，$request_uri 是原样透传原始 URI 的，如果这次换域名顺带改了路径（比如老站 /chanpin/xxx 新站是 /product/xxx），直接拼过去就是一片 404，这时候反而得回到 rewrite 配合 map 做逐条映射。所以先比对两边的路径规则再选方案，别一股脑换。第二，CDN 那块不止刷缓存，回源 Host 头也得确认。有些 CDN 是按 Host 回源的，域名换了以后源站匹配不到你新写的 server 块，配置再对也白跳。

外链这条我举双手赞成，还可以再实操一点：GSC 的「链接」报告和 Ahrefs 都能导出外链清单，按 DR 排序挑前二十个联系站长改，优先级比等蜘蛛高得多。至于谷底期别动配置，同意，但补一条——如果超过两个月还没动静，别急着怀疑 301，先去查 canonical 标签和 sitemap 是不是还指向老域名，这个疏漏比配置本身更常见。

路径结构必须一致这条是 return 301 的硬前提，你这个补充很到位，我再加两个常被忽略的点。

$request_uri 是带 query string 的原始 URI，而 $uri 不带，所以写 return 301 https://新域名$request_uri; 时参数不会丢，反过来要是顺手写成 $uri,带参的落地页就会全部跳成裸地址，这种坑比路径不匹配更隐蔽，因为首页看着一切正常。另外老域名如果本来就上了 HTTPS，跳转链会变成老 HTTP → 老 HTTPS → 新 HTTPS，三跳太浪费，最好让老域名的 80 端口直接跳到新域名的 HTTPS，一步到位。

还有一条比 CDN 回源更容易翻车的：老域名的证书。很多人 301 配得漂漂亮亮，结果老域名证书到期没续，强制跳转的第一步就直接握手失败，蜘蛛进来的门都关了，表现和没配 301 一模一样。老域名只要还留着做跳转，DNS、证书、服务器这三样就得一直续着。

canonical 和 sitemap 那个排查思路我完全认同，再顺手看下 access log，确认新域名那边返回的确实是 301 而不是被中间层改成了 302，同时抓取频次有没有在缓慢爬升，这两条比盯着流量曲线更能判断是不是真的在恢复。