WordPress更换域名教程：6步实测换域名不丢数据

本站部分链接为联盟推广链接。通过这些链接购买，我可能获得佣金...

这不仅不会增加您的实际费用，通常还能让您享受到专属折扣。所有上榜推荐均基于真实项目环境下的自费实测，排名完全由客观测评数据决定。详细规则请查阅《免责声明》。

wordpress-change-domain

WordPress网站换域名，说简单也简单，后台改两个网址就行；说麻烦也麻烦，改完以后图片不显示、页面样式乱了、旧域名的流量全断了，这些问题往往要过几天才冒出来。

网上流传的教程大多停在”后台改网址 + 装个替换插件”这一步。我在本地搭了一套 WordPress 7.1，把换域名的每一步都跑了一遍，测出好几处教程里没写的坑：

  • 直接写 SQL 替换，会把插件设置读成 false；
  • WordPress 不会自动把旧域名跳转到新域名；
  • Elementor 页面里的网址，普通的查找替换根本找不到。

下面按实际操作顺序讲，每一步都附测试结果。测试环境在文末。

wordpress general settings site url

第一步：备份，再把新域名准备好

动手之前做两件事，顺序不能反。

先备份整个网站。 数据库和文件都要备份。后面的数据库替换一旦出错，没有备份就只能干瞪眼。

再让新域名能正常访问。 很多人是倒着做的：先在后台改网址，再去解析新域名，结果改完就进不去后台了。具体原因在第二步实测里会看到。正确的顺序是：

  1. 新域名添加 A 记录，指向服务器 IP；
  2. 在主机面板里把新域名绑定到这个站点；
  3. 给新域名配好 SSL 证书。

解析怎么做，可以看域名注册与解析指南。用宝塔的话，绑定站点和申请 Let’s Encrypt 证书的操作，在宝塔面板安装 WordPress 教程里都有。

检查方法很简单：浏览器访问 https://新域名/wp-login.php，能看到登录页，就说明准备好了。

new domain wp login https ready

第二步：修改站点地址（三种方法）

方法 A：后台修改（能进后台时用）

进入”设置 → 常规”，把”WordPress 地址（URL）”和”站点地址（URL）”都改成新域名，然后保存。

我实测时，点保存后 WordPress 先在旧域名下跳了两次 302，然后直接把我带到了新域名的登录页，地址里带着 reauth=1。原因是登录状态绑定在旧域名上，到了新域名必须重新登录。

这也说明了第一步为什么要先把新域名准备好。如果新域名还没解析，保存之后浏览器会打开一个打不开的地址，后台就进不去了。

方法 B：WP-CLI（有 SSH 时最省事）

bash

wp option update home 'https://www.新域名.com'
wp option update siteurl 'https://www.新域名.com'

用 root 账号执行的话，要在命令后面加 --allow-root。

方法 C：phpMyAdmin（后台进不去时的补救办法）

在 wp_options 表里找到 siteurl 和 home 两行，把值改成新地址。也可以直接执行 SQL：

sql

UPDATE wp_options SET option_value = 'https://www.新域名.com'
WHERE option_name IN ('siteurl', 'home');

表前缀不一定是 wp_，以 wp-config.php 里的 $table_prefix 为准。这两项存的是普通字符串，直接改是安全的。第三步会讲到，换成别的数据就不能这样改了。

两个”应急常量”，用之前要知道它们的局限

官方文档还提到可以在 wp-config.php 里写 WP_HOME 和 WP_SITEURL。我测了一下：加上常量后，get_option('home') 返回的是新地址，但数据库里存的还是旧地址。删掉常量后，网站立刻又变回旧域名。WordPress 核心代码是通过 option_home 和 option_siteurl 过滤器覆盖读取结果的，并不会写进数据库。另外，加了这两个常量后，”设置 → 常规”里对应的输入框会变成灰色，不能编辑。

所以它适合在进不去后台时临时救急。救完之后，还是要用方法 B 或 C 把数据库里的值改掉。

官方文档里另一个常量 RELOCATE，我不推荐。我看了 wp-login.php 的源码，它只会更新 siteurl，不会更新 home。官方文档也明确说，把它留在 wp-config.php 里是不安全的。

phpmyadmin wp options siteurl home

第三步：替换数据库里的旧域名，千万别直接写 SQL

改完站点地址，文章固定链接、canonical 标签都会跟着变成新域名，这一点我在测试里确认过。但文章正文里写死的图片地址、插件设置里存的网址，仍然是旧域名。很多人”换完域名图片不显示”，就是这个原因。

最直觉的做法是写一条 UPDATE ... REPLACE() 一次替换全库。我实际试了一下：做了一个模拟插件设置的选项，存的是一个数组，里面有一个旧域名地址，然后用 SQL 把旧域名换成长度不同的新域名。

结果，数据库里那串数据的长度标记还是 s:49，实际字符串长度已经变了。再用 get_option() 读取时，原本的数组直接变成了 false。也就是说，这条插件设置等于丢了。

WordPress 官方迁移文档也警告过：对整个数据库做查找替换会破坏序列化数据，因为有些主题和小工具会存储字符串长度。

正确的工具有两个。

用 WP-CLI 的 search-replace

官方文档的说明是，它能”智能处理 PHP 序列化数据”。我用同样的数据测试，替换后读出来的仍然是完整数组，网址已经更新。推荐的用法：

bash

# 先预览，不写入数据库
wp search-replace 'https://www.旧域名.com' 'https://www.新域名.com' --skip-columns=guid --all-tables-with-prefix --dry-run

# 确认无误后，去掉 --dry-run 正式执行
wp search-replace 'https://www.旧域名.com' 'https://www.新域名.com' --skip-columns=guid --all-tables-with-prefix

这两个参数各有用处：

  • --skip-columns=guid： 官方文档原话是”永远、永远不要修改 GUID 列的内容”。GUID 是文章的唯一标识，改了以后，RSS 阅读器会把旧文章当成新文章重新推送。
  • --all-tables-with-prefix： search-replace 默认只处理在 $wpdb 里注册过的表。我建了一张模拟插件自建表（wp_demo_redirects），默认预览时根本没有列出它，加上这个参数后才被计入。SEO 插件的重定向、表单插件的提交记录，经常存在这种自建表里。

如果网站以前同时用过 http 和 https，或者带不带 www 都用过，每种写法都要预览一次，确保没有漏掉的。

不会命令行，就用 Better Search Replace

这个插件在官方插件库里，我 11 月 2 日核实过：版本 1.4.11，已测试到 WordPress 7.1.4，活跃安装量超过 100 万，要求 PHP 8.1 及以上。插件介绍里写着支持所有表的序列化数据。

wp-Better-Search-Replace

装好后在”工具”菜单下找到 Better Search Replace，安装方法可以参考插件安装教程。我看了它的源码，有两个默认设置对换域名很友好：

  • Run as dry run 默认是勾选的，第一次点只预览，不写库；
  • Replace GUIDs 默认不勾，界面说明是”不勾选时会跳过所有名为 guid 的列”。

表格用 Ctrl（Mac 用 Cmd）多选，自建表也会显示在列表里，记得一起选上。

better search replace dry run settings

第四步：别漏了”转义过的网址”（Elementor 用户必看）

这一步是我测出来的，参考教程里完全没提。

Elementor 把页面数据以 JSON 格式存在 _elementor_data 里，网址中的斜杠会被转义，写成 https:\/\/www.旧域名.com\/... 这样。我用第三步的命令替换明文网址后，这条数据一个字都没变，因为字符串根本对不上。任何按字符串查找的工具都会碰到这个问题。

块编辑器没有这个问题。我查了 WordPress 7.1 的源码，区块属性是用 JSON_UNESCAPED_SLASHES 保存的，斜杠不转义，第三步就能覆盖。

处理方法有两种。

用转义写法再替换一次。 下面这条命令我实测过，替换后 JSON 解析出来的地址是正确的新域名：

bash

wp search-replace 'https:\/\/www.旧域名.com' 'https:\/\/www.新域名.com' --skip-columns=guid --all-tables-with-prefix

一定要用单引号包住网址，否则反斜杠会被命令行吃掉。

用 Elementor 自带的 Replace URL 工具。 后台访问 wp-admin/admin.php?page=elementor-tools，切到 Replace URL 标签，填入旧地址和新地址。我看了 Elementor 当前的源码，这个工具做的事就是把两个地址转义后，在 _elementor_data 里替换，然后清除 Elementor 生成的 CSS 缓存文件。命令行版本是：

bash

wp elementor replace-urls https://www.旧域名.com https://www.新域名.com

Elementor 的工具只管它自己的数据。其他插件如果也存了转义网址，还得靠上面那条通用命令。两种方法一起用也没问题：先跑通用命令，再用 Elementor 工具。这时它可能显示影响 0 行，但缓存照样会清掉。

elementor tools replace url

第五步：旧域名必须做 301，WordPress 不会帮你跳

很多人以为后台改完网址，访问旧域名就会自动跳到新域名。我实测的结果是：旧域名只要还解析到同一台服务器、还绑定着这个站点，访问首页、文章页、RSS、REST API，返回的都是 200，没有任何跳转。只有 wp-admin 会 302 到新域名的登录页。页面里的 canonical 标签虽然已经指向新域名，但对用户和搜索引擎来说，这就是两个域名同时在线的重复站点。

原因写在 WordPress 的 canonical.php 里：规范化跳转只处理”带 www 和不带 www”之间的切换，其他域名差异一律保留原样，不会跳转。

所以 301 必须在服务器层面做。下面两份配置都对照了 Nginx 和 Apache 的官方文档。

Nginx（宝塔、aaPanel 默认）： 把旧域名从原站点的 server_name 里删掉，单独写一个 server 块：

nginx

server {
    listen 80;
    listen 443 ssl;
    server_name 旧域名.com www.旧域名.com;

    ssl_certificate     /path/to/旧域名/fullchain.pem;
    ssl_certificate_key /path/to/旧域名/privkey.pem;

    return 301 https://www.新域名.com$request_uri;
}

Nginx 文档对 $request_uri 的定义是”完整的原始请求 URI（带参数）”，所以路径和查询参数都会原样带过去。注意，旧域名的 SSL 证书不能删。浏览器访问 https://旧域名 时，要先完成 HTTPS 握手才能收到跳转，没有证书就会直接报错。

Apache（共享主机、cPanel 常见）： 新旧域名指向同一个目录时，不能直接写 Redirect，否则新域名也会被跳转，陷入死循环。要在 .htaccess 最上方（# BEGIN WordPress 之前）加上带域名判断的规则：

apache

RewriteEngine On
RewriteCond "%{HTTP_HOST}" "^(www\.)?旧域名\.com$" [NC]
RewriteRule "^/?(.*)" "https://www.新域名.com/$1" [L,R=301,NE]

这里 Apache 文档里有两点可以作为依据。一是在 .htaccess 里，匹配的路径”永远不带开头的斜杠”，所以写成 ^/?(.*)。二是”默认情况下查询字符串会原样传递”，参数不会丢。

配置好以后，用命令自己检查一遍。返回 301，并且 Location 指向新域名的对应页面，就说明成功了：

bash

curl -I https://旧域名.com/任意一篇文章.html

参考教程建议 301″至少保留 3 个月”，这个时间偏短。Google 的 Change of Address 文档要求至少保留 180 天，网站迁移文档的建议是”尽可能长，一般至少 1 年”。所以旧域名至少要续费到那个时候。

第六步：在 Google Search Console 提交改址

做外贸站，Google 的排名是命根子，这一步不能省。还没用过 Search Console 的，可以先看 Google SEO 教程里的工具部分。

用 Change of Address（地址更改）工具前，官方列出的前提条件是：

  • 两边都要验证： 你必须同时是旧网站和新网站这两个资源的所有者，新域名要先添加并完成验证；
  • 首页要先做好 301： 旧首页要已经 301 到新首页，第五步做完就满足了；
  • 只能用于域名级资源，且不会自动带上子域名： 包括 www 在内的子域名都不会一起迁移。旧站带 www 和不带 www 都用过的话，每个版本都要单独提交一次。

提交以后，官方说相关提示会显示 180 天。另外，在新资源里提交新的 sitemap，帮助 Google 尽快认识新网址。Google 文档也说了，迁移期间排名出现暂时波动是正常的，一般会慢慢稳定下来。

这个工具不适用于 http 换 https，也不适用于同一域名内 www 和不带 www 之间的切换，这两种情况 Google 会自己处理，或者用 canonical 和重定向解决。

search console change of address

换完之后，再查这几个地方

数据库替换只管数据库，下面这些它管不到：

  • 缓存和 CDN： 缓存插件、服务器缓存、Cloudflare 缓存都清一遍，不然有些访客看到的还是旧地址的页面。
  • 主题和插件文件里写死的网址： 比如子主题的 functions.php、自定义代码片段，要手动搜一遍旧域名。
  • 第三方服务的回调地址： PayPal、Stripe 等支付通知地址，第三方登录的回调地址，表单和邮件服务的白名单，统计工具里的网站地址，都要改成新域名。
  • 外链： 联系给你做过友情链接、经常引用你的网站，请对方更新链接。Google 文档也说，跳转会拖慢用户访问，能直接改成新链接最好。

如果你是搬家换主机，顺便换域名，正好借这个机会比较一下主机。可以参考我自费测试过的 WordPress 主机推荐。

多站点（Multisite）的域名更换涉及 wp_blogs 等网络表，流程不同，这篇文章没有覆盖。

这篇文章的测试环境

  • WordPress： 官方 GitHub 镜像的 7.1 分支（7.1.5-alpha，正式版为 7.1.4）
  • PHP： 8.3.6
  • WP-CLI： 2.12.0
  • 数据库： 官方 SQLite Database Integration 插件
  • 服务器： PHP 内置服务器，用 127.0.0.1 和 localhost 模拟新旧两个域名
  • 浏览器： 无头 Chromium，用 Playwright 记录后台改网址后的跳转链路
  • 插件源码： Elementor（官方 GitHub 当前版本 4.5.0）和 Better Search Replace（官方 GitHub 1.4.11）都是直接读的源码
  • 测试日期： 2026 年 11 月 3 日

SQLite 毕竟不是 MySQL。我测试时发现，SQLite 环境下 search-replace 正式执行报告的”替换数量”不准（数据本身是正确的），所以文中没有引用任何替换数量。文中写到的结论，包括序列化损坏、转义网址匹配不到、自建表默认被跳过、常量不写库、旧域名不会自动跳转，都是由 PHP 和 WordPress 的代码逻辑决定的，换成 MySQL 结果也一样。

相关文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注


快捷菜单
WordPress 主机
VPS 主机
最新优惠
正版授权
VPS 补货监控