WordPress 迁移到新域名后总是跳回旧域名：原因拆解与排查顺序

一、问题背景说明

很多人在把 WordPress 网站从旧域名迁移到新域名后，会遇到一个典型现象：
访问新域名时，浏览器会自动重定向回旧域名，甚至后台登录也会被强行带回旧域名，导致迁移看似完成但站点"回跳"。

从系统角度看，这不是 WordPress "迁移失败"，而是站点的某些"权威地址来源"仍然指向旧域名。WordPress 会在多个位置保存站点 URL，一旦其中某一处优先级更高，就会触发跳转。

二、为什么会出现这种跳转回旧域名？

WordPress 的站点地址并不是只存在一个地方。迁移时如果只改了部分配置，就会出现这种情况：

浏览器访问新域名
服务器/应用层读取到"旧域名是站点主地址"
于是返回 301/302 跳转到旧域名（或者 PHP 运行时强制 wp_redirect()）

核心逻辑是：
谁"更权威"谁说了算。而 WordPress 的权威来源可能来自后台设置、数据库、配置文件、插件、服务器规则、缓存/CDN 等多个层面。

三、常见原因分析（分点列出）

下面按"优先级 + 发生频率"排序，便于你按顺序排查。

1）后台站点地址未更新（最常见）

在 WordPress 后台：
设置 → 常规 → WordPress 地址 / 站点地址

如果仍是旧域名，访问新域名时往往会被带回旧域名。

2）数据库中仍残留旧域名（迁移只改表面会中招）

即使后台改了地址，数据库里仍可能存在旧域名，例如：

wp_options（或你的自定义前缀表）里的 siteurl / home
文章内容、短代码、菜单、构建器数据、序列化字段

这些内容会在渲染或跳转逻辑里继续引用旧域名。

你之前的站点数据库前缀是 0164JQlP ，实际表名会是类似 0164JQlP_options 这种（排查时不要误用默认 wp_）。

3）wp-config.php 或自定义代码强制定义旧域名

如果 wp-config.php 中定义了：

WP_HOME
WP_SITEURL

那么后台设置会被覆盖，你怎么改都没用。

4）服务器重写规则（.htaccess / Nginx）仍指向旧域名

典型情况：

.htaccess 里写了旧域名 301
Nginx server 块写了 return 301 https://old.com$request_uri;
面板/站点模板残留旧站点域名规则

这类属于"服务器层强制跳转"，优先级高于 WordPress。

5）缓存 / CDN / 反向代理还在缓存旧跳转

例如：

CDN 缓存了 301（浏览器也会记住）
Redis/对象缓存、页面缓存插件缓存了旧跳转
Cloudflare/加速层仍把新域名回源到旧域名配置

这类会让你"明明改对了但还是跳"，属于常见干扰项。

6）插件或安全组件做了重定向

常见插件行为：

SEO 插件强制 canonical
重定向插件仍有旧规则
安全插件根据 Host/Header 做跳转校正

四、解决与判断方法（分步骤提供方案）

我建议按"最快定位责任层"的顺序排查：先判断是谁在跳转，再去改对应位置。

Step 1：先确认跳转是 301 还是 302（判断是否缓存/规则）

在本地执行：

curl -I http://newdomain.com

curl -I https://newdomain.com

你要看的重点：

HTTP/1.1 301 还是 302
Location: https://olddomain.com/... 是谁返回的

判断逻辑：

301 更可能是服务器规则/CDN/浏览器缓存
302 更可能是 WordPress/PHP/插件逻辑跳转

Step 2：检查 wp-config.php 是否写死旧域名（最高优先级）

打开站点根目录 wp-config.php，搜索：

WP_HOME
WP_SITEURL

如果存在，改为新域名，例如：

define('WP_HOME', 'https://newdomain.com');

define('WP_SITEURL', 'https://newdomain.com');

注意事项：

如果你不希望写死域名，可以删除这两行，让后台/数据库生效
修改前建议备份文件，避免语法错误导致白屏

Step 3：修正数据库 options 表的 siteurl/home（最核心）

进入数据库执行（注意替换表前缀）：

SELECT option_name, option_value

FROM 0164JQlP_options

WHERE option_name IN ('siteurl','home');

如果显示旧域名，更新为新域名：

UPDATE 0164JQlP_options

SET option_value='https://newdomain.com'

WHERE option_name IN ('siteurl','home');

判断逻辑：

siteurl/home 是 WordPress 站点"自我认知"的核心来源之一
如果这里不对，几乎一定会产生跳转或资源引用错误

Step 4：排查服务器层重定向规则（.htaccess / Nginx）

Apache（.htaccess）

检查站点根目录 .htaccess 是否包含旧域名 301 规则。

如果你看到类似：

RewriteRule ^(.*) $https://olddomain.com/$ 1 [R=301,L]

就需要删除或改为新域名。

Nginx

检查 server block 里是否存在 return 301 或 rewrite 指向旧域名，例如：

return 301 https://olddomain.com$request_uri;

改为新域名或移除。

注意：

修改 Nginx 配置后需 reload：nginx -t && systemctl reload nginx
Apache 规则错误可能导致 500，修改前建议备份

Step 5：清理缓存（避免"你改对了但还在跳"）

你需要同时考虑三层缓存：

浏览器缓存：301 会被浏览器长期记住
- 用无痕窗口测试
CDN 缓存：清理缓存、检查 Page Rules/Redirect Rules
WordPress 缓存插件：清理页面缓存、对象缓存（Redis）

判断逻辑：

如果你用 curl -I 已经不跳了，但浏览器还跳，通常是浏览器缓存 301
如果不同地区/不同网络表现不同，优先怀疑 CDN

Step 6：检查插件重定向与 canonical 设置

临时快速验证方式：

将 wp-content/plugins 改名为 plugins.off（临时停用全部插件）
再测试新域名是否仍跳转

如果不跳了，说明是插件层导致，再逐个恢复定位。

注意：

改目录名不会删除插件数据，但会让站点短暂失去插件功能
对生产站点操作建议选择低峰期

五、风险提醒或注意事项

不要只改后台地址：后台只是其中一个来源，且可能被 wp-config 覆盖
不要盲目全库替换：尤其含序列化数据时，粗暴 replace 可能破坏数据结构
遇到 301 必须考虑缓存：否则你会一直以为"改了没生效"
先定位责任层再动手：服务器规则 / wp-config / 数据库 / 插件的优先级不同，乱改会扩大影响面

六、总结归纳

WordPress 迁移后"新域名跳回旧域名"，本质上是：
某个更高优先级的配置源仍在声明旧域名是主站地址。

推荐的理性排查顺序是：

curl -I 看跳转类型与返回源
检查 wp-config.php 是否写死 WP_HOME/WP_SITEURL
修正数据库 siteurl/home（注意你的表前缀）
排查 .htaccess/Nginx 的旧域名重写
清理浏览器/CDN/WP 缓存
插件逐个定位重定向来源