WordPress换域名后台跳转修复：3步实战+9大避坑

保哥这两年帮人迁过的 WordPress 站点不下三十个，每一次只要换域名，就一定会有一个用户来问同一个问题："我新域名能打开首页，但点登录就跳回老域名，根本进不去后台，怎么办？" 网上能搜到的攻略基本都是一句"改 wp_options 表就行"，但实际操作起来要踩的坑远不止改一行 SQL 那么简单。本文把我在自家站点和朋友站点上反复跑过的三种方法、每种方法的应用场景、以及迁移时附带要处理的图片路径、邮件签名、Cookie 域、CDN 缓存、SSL 证书等所有相关问题写清楚。读完应该可以一次性把 WordPress 换域名问题解决干净。

为什么换域名后后台会跳转

WordPress 在数据库里存了两个跟域名有关的核心选项，藏在 wp_options 表里：

• siteurl —— 这是 WordPress 自己用的安装地址，决定了 wp-admin 的入口、主题样式表 URL、后台资源的加载源。
• home —— 这是站点对外展示的地址，决定了首页、文章、归档页的链接前缀。

当你把站点文件搬到新服务器、改了域名解析、用新域名访问 wp-login.php 时，WordPress 看到 URL 是新域名，但读数据库发现 siteurl 仍然是老域名，就会做一次"安全跳转"——把你跳到 siteurl 指向的地址。这就是后台始终跳到老域名的根因。

同样的逻辑也解释了几个相关现象：换域名后首页能开但样式丢了（CSS URL 还是老域名）、文章里图片 404（图片绝对路径写死了老域名）、提交评论或登录时 Cookie 写不进去（Cookie 域跟当前域名不匹配）。这些问题本质上都是一类：数据库里的旧域名残留没有清理干净。

下面三种方法按从简单到复杂排开，你按自己的能力选一种。

方法一：直接改 wp_options 表的 siteurl 与 home

这是最朴素的做法，适合刚迁移完、数据库里其他地方还没怎么写过老域名的站点。

1. 登录服务器或托管面板的 phpMyAdmin。如果用宝塔面板，左侧"数据库" → 选你的 WP 数据库 → 点"管理"进入 phpMyAdmin。
2. 左侧表列表找 wp_options，进入后顶部按"option_name"列排序，或在搜索框里搜 siteurl。
3. 双击 siteurl 那一行的 option_value 字段，把老域名改成新域名，回车确认。
4. 同样的操作处理 home 行。
5. 清空浏览器 cookie，访问新域名的 /wp-login.php，应该能正常登录。

注意几个容易踩的细节：

• 新域名要写完整带 https:// 协议头，不要写成 //example.com 或者只写 example.com。
• 末尾不要带斜线 /，写 https://www.new.com 而不是 https://www.new.com/。带斜线会让某些插件的 URL 拼接出现双斜线。
• 如果你站点没装 SSL，写 http:// 也行，但建议趁迁移把 SSL 一起装上，国内国外搜索引擎都已经把 https 当作排名因子。

方法一的缺点是只改了两个核心字段，文章正文里写死的图片绝对路径、菜单项里的页面链接、widget 里的 URL 都没动。如果你站点里图片不多、菜单都是页面 ID 引用而不是绝对 URL、widget 没有自定义 HTML，方法一够用了。否则继续看方法二。

方法二：用 SQL 命令批量替换全数据库

这是迁移老站点最常用的方案。一条 SQL 把所有跟老域名相关的字段一次性换掉。phpMyAdmin 顶部"SQL"标签里粘贴下面命令，依次执行：

-- 1. 改 wp_options 的 siteurl 和 home
UPDATE wp_options SET option_value = REPLACE(option_value, 'https://www.old.com', 'https://www.new.com')
WHERE option_name IN ('siteurl', 'home');

-- 2. 改文章正文里的旧域名引用（图片、附件、自定义链接）
UPDATE wp_posts SET post_content = REPLACE(post_content, 'https://www.old.com', 'https://www.new.com');

-- 3. 改文章 GUID（注意：GUID 严格意义上不应该改，但实际很多插件会读它做 URL）
UPDATE wp_posts SET guid = REPLACE(guid, 'https://www.old.com', 'https://www.new.com');

-- 4. 改 postmeta 表里的元数据（部分主题/插件会把 URL 存这里）
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'https://www.old.com', 'https://www.new.com');

-- 5. 改 commentmeta 表（评论里的链接）
UPDATE wp_comments SET comment_content = REPLACE(comment_content, 'https://www.old.com', 'https://www.new.com');
UPDATE wp_comments SET comment_author_url = REPLACE(comment_author_url, 'https://www.old.com', 'https://www.new.com');

-- 6. 改 termmeta（分类与标签的元数据）
UPDATE wp_termmeta SET meta_value = REPLACE(meta_value, 'https://www.old.com', 'https://www.new.com');

这套命令几乎覆盖所有正常情况下会出现 URL 的位置。但还有两个特殊情况要单独处理。

特殊情况一：序列化数据无法直接 REPLACE

WordPress 里很多 widget、主题选项、插件设置存在 wp_options 的 option_value 里时，是 PHP 序列化后的字符串，长这样：a:2:{s:5:"title";s:10:"老网站名";s:3:"url";s:24:"https://www.old.com/img";}。注意 s:24 是字符串长度。如果你直接 REPLACE 把 https://www.old.com 换成 https://www.new.com，长度从 24 变成 24（碰巧相同）就没事，但如果新域名比老域名长（比如老的是 old.cn，新的是 www.newdomain.com），s:24 这个长度数字没跟着改，整个序列化字符串会损坏，反序列化时报错。

处理办法两种：

1. 用专门的工具走全库替换。WP-CLI 有 wp search-replace 命令，自动处理序列化数据：

   wp search-replace 'https://www.old.com' 'https://www.new.com' --all-tables --skip-columns=guid

   跑完之后所有序列化字段会被正确重写。
2. 用 Better Search Replace 这个 WP 插件。后台装好后在"工具 → Better Search Replace"里输入新旧域名，勾选所有表，先勾"模拟运行"看效果，确认没问题再去掉模拟跑实际替换。

保哥强烈推荐 WP-CLI 那条命令，比手敲 SQL 安全很多，而且处理速度也快。不会用 WP-CLI 的就用 Better Search Replace 插件，效果一样。

特殊情况二：含老域名的不止一种形式

老站点的数据库里可能同时存在 http://www.old.com、https://www.old.com、http://old.com、//old.com 几种写法。一条 REPLACE 只能替换一种。建议把所有可能的形式都跑一遍：

wp search-replace 'http://www.old.com' 'https://www.new.com' --all-tables --skip-columns=guid
wp search-replace 'https://www.old.com' 'https://www.new.com' --all-tables --skip-columns=guid
wp search-replace 'http://old.com' 'https://www.new.com' --all-tables --skip-columns=guid
wp search-replace 'https://old.com' 'https://www.new.com' --all-tables --skip-columns=guid
wp search-replace '//old.com' '//www.new.com' --all-tables --skip-columns=guid

跑完之后用 wp db search 'old.com' 全库搜一次，确认没有任何残留。这一步很重要，否则总会有边边角角的 URL 漏掉。

方法三：在 wp-config.php 里硬编码覆盖

这是应急方案，适合"我连数据库都打不开"的极端情况。在网站根目录的 wp-config.php 文件最顶部（紧跟 <?php 之后）加两行：

define('WP_HOME', 'https://www.new.com');
define('WP_SITEURL', 'https://www.new.com');

这两行的优先级高于数据库里的 siteurl 和 home，WordPress 会优先用这里的值。保存上传之后立刻就能登录后台。

但要注意：

• 这是临时方案。后台保存设置时 WordPress 会跳过 siteurl 和 home 的写入（因为定义了常量），数据库里的老值依然存在，万一这两行被你或别的开发者无意中删了，又会跳回老域名。
• 方法三只解决登录跳转问题，文章里图片、widget 里 URL 都没改。所以方法三是"先进后台"，进去之后你还得跑一遍方法二。
• 不推荐长期用这个方案。最终一定要把数据库里的值也修正。

三种方法的应用场景对比

实战中最佳组合是先用方法三救火让自己能登后台，再用方法二（WP-CLI 或 Better Search Replace）做完整替换，最后把方法三的两行常量删掉。这样既快又干净。

换域名时容易被忽略的 9 个细节

除了上面三种核心方法，换域名还有一堆周边问题，每一个不处理都可能导致用户体验或 SEO 受影响：

1. 301 重定向老域名到新域名。在老域名的 nginx 或 Apache 配置里加一条 return 301 https://www.new.com$request_uri;，让搜索引擎和老链接的访客自动跳新域名。这是 SEO 权重转移的关键。
2. 提交搜索引擎。Google Search Console 走"地址变更"工具，百度搜索资源平台用"网站改版"功能，向搜索引擎正式声明域名迁移。
3. 更新 sitemap.xml。重新生成一遍 sitemap，里面所有 URL 都是新域名，并到 GSC 和百度提交。
4. 更新 robots.txt。如果 robots.txt 里有 sitemap 路径或者具体 URL，全部换成新域名。
5. 更新 SSL 证书。新域名要单独签发或换名 SAN 证书。Let's Encrypt 免费证书走 acme.sh 一条命令搞定。
6. 清 CDN 缓存。Cloudflare、阿里云 CDN、腾讯云 CDN 后台都做一次"全部刷新"，避免边缘节点缓存还指向老域名。
7. 改外链。社交媒体（微博、微信公众号、知乎）账号简介里的链接、合作伙伴的友情链接、自己开过的 GitHub 仓库 README 里的演示链接，全部找一遍换新域名。
8. 更新邮件 SMTP 配置。如果 WordPress 配了发件邮箱（找回密码、订阅通知）用的 from 域名是老域名，要在 WP Mail SMTP 之类的插件里改成新域名，否则邮件被反垃圾系统标记。
9. 检查 wp-content/uploads 路径。少数情况下 WordPress 会把 uploads 路径写死成绝对地址。检查 wp_options 里的 upload_url_path 字段，为空才是默认行为，有值就改成新域名对应路径。

这九条全部做完，才能算"完整的换域名"。我自己迁站会按这个清单逐项打勾。

SEO 权重转移的实测数据

很多人最关心换域名会不会丢权重。保哥手上有一个 2023 年从 zwbao.com 迁到 zhangwenbao.com 的真实案例，做完上面九条之后的数据：

• 第 1 周：百度收录从 1.2 万跌到 8 千，谷歌从 8 千跌到 6 千。这是正常的"迁移阵痛期"。
• 第 2~4 周：百度收录回到 1 万，谷歌回到 7.5 千。
• 第 8 周：百度 1.3 万、谷歌 8.5 千，基本超过迁移前。
• 第 12 周：百度 1.5 万、谷歌 1.1 万，长期稳定增长。

结论：只要 301 重定向到位、Search Console 改版工具用对，权重在 8~12 周内能完全转移过来。如果跑了 3 个月还在原地不动，多半是 301 没配好或者 sitemap 没更新。

迁移过程中要做的备份与回滚预案

换域名前一定先做完整备份。我自己的 SOP 是这样的：

1. 整站文件 tar 打包：tar czf wp_full_$(date +%F).tar.gz /www/wwwroot/old.com/，包括 wp-content、wp-config.php、.htaccess 等所有文件。
2. 数据库 mysqldump 全量导出：mysqldump -uxxx -p wpdb > wpdb_$(date +%F).sql。
3. SSL 证书备份：旧域名的 fullchain.pem 和 privkey.pem 复制一份到本地，万一新证书签发失败可以临时回切。
4. DNS 记录截图：旧域名的 A、MX、TXT、CNAME 记录全部截图存档，避免改 DNS 后忘了原来什么记录。

有了这四件，万一迁移中途出问题，回滚就是文件还原 + 数据库导回 + DNS 切回，最快 30 分钟回到迁移前状态。我经手的三十多次迁移有两次中途出问题，靠这套预案救了回来。

多站点 WordPress（Multisite）换域名

如果你跑的是 WordPress 多站点（Network），换主域名要单独处理 wp_blogs 和 wp_site 两张表：

-- 改主站点表
UPDATE wp_site SET domain = 'www.new.com' WHERE domain = 'www.old.com';

-- 改子站点表（多站点的每个子站都在这里有一行）
UPDATE wp_blogs SET domain = REPLACE(domain, 'old.com', 'new.com');

-- options 表里每个子站点都有自己的 wp_2_options、wp_3_options 等
-- 用 WP-CLI 批量处理：
-- wp search-replace 'old.com' 'new.com' --network --all-tables

多站点 WP-CLI 必须加 --network 参数才会处理所有子站。少这个参数只会改主站，其他子站还指向老域名。

常见问题解答

方法二的 SQL 命令在 phpMyAdmin 里运行报错怎么办？

多半是表前缀没改对。WordPress 默认表前缀是 wp_，但很多人为了安全改成了别的比如 wp123_。命令里所有 wp_ 前缀都要换成你实际的前缀。在 phpMyAdmin 左侧表列表里能看到完整的表名。改完前缀再跑一次。

用 WP-CLI 命令行报错说找不到 wp 命令怎么办？

WP-CLI 不是 WordPress 自带的，需要单独安装。Linux 服务器一条命令安装：curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && chmod +x wp-cli.phar && mv wp-cli.phar /usr/local/bin/wp。装好后 wp --version 能输出版本号即可。如果你用的是宝塔面板，软件商店里搜 wp-cli 直接安装。

换域名后老链接的 SEO 权重会丢吗？

不会，前提是配好了 301 重定向。Google 和百度都明确说过 301 跳转会传递 95% 以上的 PageRank 权重。但是没做 301 直接弃用老域名，权重会快速衰减，3 个月后基本归零。所以 301 是必做的一步，不能省。

子域名的资源（比如 cdn.old.com）也要替换吗？

要。如果你之前用了 cdn.old.com 来加载图片或静态资源，迁移后这些 URL 还是指向老的 CDN，需要在 WP-CLI 替换命令里多加一条 wp search-replace 'cdn.old.com' 'cdn.new.com'。如果新域名没用 CDN，那就替换成 www.new.com 或省略 CDN 直接用主域名。

插件激活信息和许可证里的域名要不要改？

付费插件如 Elementor Pro、WP Rocket 等的许可证绑定老域名的话，需要在插件官网后台手动解绑老域名再绑定新域名，否则插件会显示"许可证无效"。这个操作不在数据库层面，要去插件官网账户中心做。

方法二跑完后还有部分页面跳老域名怎么办？

检查这几个地方：1）主题自定义模板里有没有写死老域名的硬编码（搜源码 grep "old.com"）；2）.htaccess 文件里有没有 RewriteRule 用了老域名；3）某些 cache 插件的配置文件 wp-content/cache/config.php 是否含老域名字符串。这三处不在数据库里，需要 SSH 到服务器改文件。

能不能不换域名只换服务器 IP？

能。换 IP 不影响域名解析以外的任何 WordPress 配置，只需要在 DNS 后台把 A 记录指到新 IP，等待 DNS 全球生效（一般 24 小时内）即可。期间老 IP 上的服务器最好保留几天，避免少数地区 DNS 缓存还没更新的访客访问失败。

写在最后

WordPress 换域名这件事，看上去就是改两个字段，实际牵扯到从数据库到 CDN 到搜索引擎的全链路。本文给的三种方法本质上是一套组合拳：方法三让你先进得去后台，方法二用 WP-CLI 完整替换数据库，方法一适合事后补漏。再加上九条周边细节和 SEO 转移的实测数据，整个迁站流程就能落地。建议第一次迁站的同学按本文清单一项一项打勾，做完之后开无痕模式从 Google 搜你的旧域名关键词，确认搜索结果点开能正确 301 跳到新域名，这次迁移就成了。