Nginx完整301配置修复收录权重流失问题

当网站更换域名、从 HTTP 切换到 HTTPS，或调整了 URL 目录结构时，如果旧地址仍然返回 200 状态码，搜索引擎会认为新旧页面同时存在，导致权重分散、收录停滞。
解决这个问题的标准做法是配置 Nginx 301 跳转，把旧地址永久重定向到新地址，同时把原有权重传递给新页面。
本文用一个完整可运行的 Nginx 配置示例，带零基础用户完成 301 配置、检查常见陷阱，并用命令验证跳转是否生效。

动手前先确认三件事

配置 301 之前，先确认你具备以下条件：

• 服务器已安装 Nginx，并且你拥有配置文件的修改权限，一般通过 SSH 登录服务器操作。
• 知道站点配置文件的位置，常见路径为 /etc/nginx/conf.d/ 或 /etc/nginx/sites-available/，宝塔面板用户可在“网站”选项中找到对应站点配置。
• 明确新旧地址的对应关系，例如旧域名 www.old-domain.com 需要跳转到 www.new-domain.com，还是旧页面 /old-page 需要跳转到 /new-page。

另外，301 是永久重定向，生效后浏览器和搜索引擎都会记住新地址。
如果只是临时测试，请使用 302，不要使用 301。

Nginx 301 完整配置写法

下面以旧域名跳转到新域名并保留路径参数为例，给出一个常见的 Nginx 301 配置片段。
将这段配置放到对应站点的 server 块中，或单独写一个旧的 server 块。

server {
    listen 80;
    listen [::]:80;
    server_name www.old-domain.com old-domain.com;
    return 301 https://www.new-domain.com$request_uri;
}

上面的配置中，return 301 是 Nginx 专门用来返回 301 状态码的指令，$request_uri 会保留用户访问的原始路径和查询参数。
比如用户访问 http://www.old-domain.com/post/123?
id=1，最终会跳转到 https://www.new-domain.com/post/123?
id=1，路径和参数都不会丢失。

如果要把 HTTP 全部跳转到 HTTPS，同时保持域名不变，可以这样写：

server {
    listen 80;
    server_name www.your-domain.com your-domain.com;
    return 301 https://www.your-domain.com$request_uri;
}

如果你的新站点同时开启了 HTTPS，需要确保 443 端口对应的 server 块中正确配置了 SSL 证书。
修改配置文件后，执行以下命令检查语法并重载 Nginx：

nginx -t
nginx -s reload

看到 syntax is ok 和 test is successful 说明配置没有语法错误，nginx -s reload 会平滑重载配置，不会中断现有服务。

目录级 301 跳转的写法

如果只是把某个旧目录迁移到新路径，可以使用 location 块配合 return 301。
例如把 /old-directory/ 下的所有页面跳转到 /new-directory/ 下：

location ^~ /old-directory/ {
    return 301 https://www.your-domain.com/new-directory/$1;
}

这里需要注意，$1 需要配合正则表达式才能正确捕获路径。
更严谨的写法是使用 rewrite：

location ~ ^/old-directory/(.*)$ {
    return 301 https://www.your-domain.com/new-directory/$1;
}

其中 (.*) 会捕获旧路径中 old-directory/ 之后的部分，并通过 $1 拼接到新地址中。
例如旧地址 /old-directory/about 会跳转到 /new-directory/about。

避坑指南：这些细节容易导致权重流失

配置 301 时，以下几个坑最容易造成收录和权重问题：

• 只配了 HTTP 没配 HTTPS。如果旧链接本身是 HTTPS，而你只在 80 端口写了 301，浏览器访问旧 HTTPS 地址时仍然不会跳转。检查时要在 443 端口对应配置中同样处理旧地址。
• 跳转目标不统一。同一个旧页面既跳转到 https://www.new-domain.com 又跳转到 https://new-domain.com，会让搜索引擎看到两个不同的目标地址。建议新站点只保留一个主域名，并把另一个域名也 301 过去。
• 忽略尾部斜杠。Nginx 默认对目录不带斜杠时可能会产生 301 跳转，但如果你自己写规则，要确保新地址格式统一，例如 https://www.your-domain.com/about/ 不要一会儿带斜杠一会儿不带。
• 返回了 302 而不是 301。少数情况下，框架或 CDN 会自动生成 302 跳转，浏览器访问时表现为地址发生了变化，但搜索引擎不会把权重转移到 302 目标地址。可以通过下面的验证方法确认返回码。
• 没有清理旧站 sitemap 和后台地址。完成 301 后，建议更新百度搜索资源平台、Google Search Console 中的站点地图，并删除旧地址的提交记录，避免搜索引擎继续抓取旧链接。

验证 301 是否真正生效

配置完成后，不要只看浏览器是否跳转，还要用命令行确认返回状态码和跳转目标。
在本地电脑或服务器上执行：

curl -I http://www.old-domain.com/post/123

正常结果中应包含以下信息：

HTTP/1.1 301 Moved Permanently
Location: https://www.new-domain.com/post/123

看到 301 Moved Permanently 表示跳转状态正确，Location 后面的地址就是最终跳转目标。
如果看到 302 或 200，说明配置未生效，需要检查是否改错了配置文件，或是否有其他规则先影响了该地址。

对 HTTPS 地址也建议同样检查一次：

curl -I https://www.old-domain.com/post/123

同时，你可以在百度搜索资源平台或 Google Search Console 中提交变更后的 URL，并观察一段时间内的收录和索引情况。
通常 301 生效后，搜索引擎需要一段时间重新抓取旧地址并跟随跳转，权重迁移不会立刻完成，但配置正确是后续恢复的基础。

完成上述 Nginx 完整 301 配置后，建议保留旧链接的访问日志和搜索引擎后台的抓取记录，持续观察 3 到 7 天。
如果旧地址开始逐步消失、新地址收录增加，说明权重正在正常迁移；
如果旧地址仍被大量抓取并返回 200，则需要重新检查是否有其他配置干扰了刚才的跳转规则。