换服务器、换域名、换主机商，是 WordPress 站长迟早要面对的硬仗。迁移最怕两件事：数据丢、迁移后打不开。只要按「先备份、再搬文件、再搬库、最后搜索替换 URL 」的顺序走，并避开序列化数据和 GUID 两个坑，WordPress 整站迁移可以做到零丢失。本文给一套可照做的实操流程。
迁移前先分清两种情形
迁移难度取决于「域名和数据库名变不变」：
- 同域名同库：只换服务器或目录，把文件和数据库整体复制过去即可，最省事。
- 换域名或换库名：除了搬数据，还要把所有旧 URL 替换成新 URL，这是最容易出问题的环节。
无论哪种，第一步永远是完整备份——文件 + 数据库，各存一份离线副本再动手。
核心步骤：换域名/换服务器的标准顺序
- 下载现有站点文件（含 wp-content 下的主题、插件、上传）。
- 导出数据库（用 mysqldump 或 phpMyAdmin 导出 SQL）。
- 把文件和数据库存入一个安全的新文件夹，作为迁移基准备份。
- 登录原站后台「设置 → 常规」，把 WordPress 地址和站点地址改成新域名并保存（此时前台会暂时 404，属正常）。
- 再次下载站点文件、再次导出数据库——这一步的库里已经带上了新 URL 。
- 编辑
wp-config.php，填入新服务器的数据库名、用户和密码。 - 把文件上传到新服务器对应目录。
- 在新服务器导入数据库。
- 对数据库做安全搜索替换，把残留的旧 URL 全部换成新 URL 。
如果暂时只想换服务器、域名不变，跳过第 4–5 步的改 URL 动作，直接复制文件和库、改 wp-config.php 即可。迁移完成后别忘了重新保存一次固定链接，让 .htaccess 重写规则复位。
两个绝对不能踩的坑
序列化数据不能裸替换
主题、小工具的设置常以「带长度前缀的序列化字符串」存储，例如 s:25:"https://old.com/xxx"。如果你用普通 SQL 把 old.com 直接替换成 new.com，字符串长度变了但前缀还是 25，PHP 反序列化就会失败，表现为小工具丢失、设置错乱。正确做法是使用能识别序列化结构的替换工具，而不是盲目全库文本替换。
GUID 列永远别动
wp_posts 表的 guid 列是全局唯一标识符，供 RSS 阅读器识别文章。官方明确警告：绝不要修改 guid 内容，否则订阅端可能把旧文当成新文重复推送。任何搜索替换都要跳过这一列。
URL 替换的推荐做法：WP-CLI
最稳妥的替换命令是：
wp search-replace 'old.com' 'new.com' --skip-columns=guid
wp option update home 'https://new.com'
wp option update siteurl 'https://new.com'--skip-columns=guid 确保不碰 GUID；若无法用命令行，可在还能进后台时用 Velvet Blues Update URLs 、 Better Search Replace 这类插件完成。需要临时强制指定地址时，也可在 wp-config.php 里加 WP_HOME / WP_SITEURL 常量，但会失去后台修改能力；临时修复还能用 define('RELOCATE',true);，用完务必删掉，避免留下安全隐患。
迁移后检查清单
- 前台首页、文章页、后台均能正常打开。
- 图片、附件能正常加载（上传目录权限正确）。
- 固定链接重新保存，伪静态规则生效。
- 插件、主题、小工具配置完好（没因序列化问题丢失）。
- 旧域名在数据库里已无残留（用搜索替换复查）。
迁移涉及的对象缓存、多站点、媒体库等模块，建议对照 对象缓存配置、多站点设置、媒体库管理 一并核对，避免迁移后局部功能异常。换服务器后也要顺手检查 子主题 与自定义代码是否随文件完整搬过。
- 完整备份：下载全部站点文件并导出数据库，离线存一份基准副本。
- 改地址导出：在后台把站点地址改成新域名，再重新下载文件、重新导出数据库。
- 改配置：编辑 wp-config.php 填入新服务器的数据库名、用户、密码。
- 上传与导入：把文件传到新服务器，把数据库导入新库。
- 安全替换 URL：用 wp search-replace 替换旧域名并跳过 guid 列。
- 复查上线：重存固定链接、检查图片与插件小工具、确认无旧域名残留。
“换表前缀时还要做一步”
如果你在迁移时改了数据库表前缀，除了搬数据，还要更新 wp_usermeta 表里以旧前缀开头的 meta_key，例如把 oldprefix_capabilities 改成 newprefix_capabilities，否则用户权限会丢失。
常见问题
评论 (0)