WordPress换主机搬家怎么操作不出错？数据库网址替换与DNS切换执行SOP

WordPress换主机搬家，真正的难点不在“把文件拷过去”，而在两个隐形地雷：一是数据库里的网址藏在序列化数据里，直接用SQL替换会把整个网站改崩；二是DNS切换有生效延迟，处理不好会出现新旧站同时在线、数据两边乱写的分叉惨剧。

保哥这篇是一份纯执行层的搬家SOP：先盘清要搬的家当，再按手动搬家的标准动作一步步走，重点讲清楚为什么网址要用WP-CLI或专用工具替换、换域名和只换主机的差别、DNS怎么灰度切不中断，最后把最容易翻的车一次列全。它和“迁移怎么不掉排名”的SEO策略是两件事，配合着看效果最好。

搬家和“迁移不掉SEO”是两码事，先分清你要解决哪一个？

很多人一说“网站搬家”，脑子里立刻冒出“会不会掉排名”。这俩确实相关，但保哥得先把它们掰开：搬家是技术执行——怎么把数据库、文件、配置原封不动搬到新主机，让站点照常打开；不掉SEO是策略保稳——怎么做重定向、保结构、稳住爬虫和收录。前者答的是“站能不能正常跑起来”，后者答的是“跑起来之后排名稳不稳”。

这篇专攻前者。换主机、换服务器这种技术活，一步错就可能整站打不开、图片全裂、后台进不去，是实打实的执行细节。至于换域名、改版之后怎么用301映射、怎么保住流量不波动，那套SEO保稳的打法保哥在网站迁移为什么总掉流量那篇里专门讲过，两篇是配套的：先用这篇把家稳稳搬过去，再用那篇把排名稳稳接住。

为什么要先分清？因为保哥见过太多人把两件事搅在一起，结果搬家时光顾着想重定向规则，反而把数据库网址、文件权限这些最基础的执行细节搞砸了，站直接白屏。顺序应该是：先保证技术上搬过去能正常跑，再叠SEO的保稳措施。地基没打好就贴瓷砖，纯属本末倒置。

搬家前要先盘清楚哪些家当？

搬家最忌讳的是“以为搬完了，其实漏了一半”。WordPress站点不是一个文件，而是一组互相咬合的部件，盘清楚才搬得干净。保哥按重要性列一遍。

数据库。这是站点的灵魂，文章、页面、用户、设置、评论、订单全在里面。搬家本质上就是把这个数据库完整导出、再到新主机导进去。漏了它，等于把房子搬了、人没搬。

wp-content目录。这是你的家具：主题在themes、插件在plugins、所有上传的图片和附件在uploads。其中uploads往往是体积最大、也最容易被忽略的——很多人搬完发现文章里图片全裂，就是uploads没搬全。这个目录必须一字不差地拷过去。

根目录文件与wp-config.php。根目录下的核心文件一般会随WordPress重装，但wp-config.php是命门——它存着数据库连接信息和安全密钥（盐值）。搬到新主机后，数据库的地址、库名、用户名、密码大概率要改，这个文件改不对，站直接连不上库。

容易漏的隐形家当。域名和DNS解析、SSL证书、服务器上的定时任务（WP-Cron或系统cron）、发信配置（SMTP）、Nginx或Apache的伪静态规则、还有.htaccess。这些不在“文件夹”里，却决定搬完后定时任务跑不跑、邮件发不发、固定链接会不会全404。保哥的习惯是搬家前列一张清单，逐项打钩，别凭记忆。

这里单独提醒wp-config里的“安全密钥”（也就是那一串盐值常量）。它们用来加密登录cookie。如果你搬家时连同wp-config原样搬过去，盐值不变，老用户的登录状态可以延续；要是图省事重新生成了一套盐值，所有人的登录会话会失效、需要重新登录——这本身不是错误，但你得心里有数，别搬完发现全员被登出还以为是搬坏了。对会员站、电商站尤其要注意这个细节。

还有数据库表前缀这个隐形地雷。WordPress默认表前缀是wp_，但很多站出于安全改成了别的。搬家时新库导入后，wp-config里的table_prefix必须和数据库里实际的表前缀完全一致，差一个字符都连不上库。这是手动搬家“数据库连接出错”白屏里仅次于密码填错的高频原因，盘点时务必把旧站真实的表前缀记下来。

WordPress搬家到底有哪几种打法？

条条大路通新主机，关键是选对适合你的那条。保哥按门槛从低到高排。

插件一键迁移。像Duplicator、All-in-One WP Migration这类插件，能把整站打包成一个文件，到新主机解包还原，自动帮你改数据库网址。优点是新手友好、几乎不用碰代码。缺点是大站点（几个G以上）经常卡在打包或上传环节、免费版有体积限制、还得依赖插件本身不出bug。中小站点首选这条。

手动搬家。自己导出数据库、拷贝文件、改配置、替换网址。步骤多、要懂一点命令行和数据库，但胜在可控、不挑站点大小、不依赖第三方插件。大站点、或者插件迁移总失败的情况，老老实实手动搬最稳。这也是保哥下一节要重点拆的标准动作。

主机商迁移服务。很多正规主机商提供免费或付费的代搬服务，你给个旧站凭据，他们的技术团队帮你搬。省心，适合完全不想碰技术的人。缺点是要等排期、对方不熟悉你站点的特殊配置时可能漏东西，搬完自己仍要逐项验收。

WP-CLI命令流。WordPress官方的命令行工具，导库、改网址、刷新固定链接都有对应命令，适合技术团队做可重复、可脚本化的迁移，尤其是要批量搬多个站、或搬完要跑一连串标准化操作时。它处理网址替换还特别稳，原因下面专门讲。

这几种打法也不是非此即彼，实战里经常混搭。保哥常用的一个组合是：文件用rsync手动传（快、可靠、能续传），数据库用WP-CLI导出导入（命令简单），网址替换也用WP-CLI（安全处理序列化）。既保留了手动搬家的可控，又借了命令行工具的省事。新手如果被这么多选择搞晕，记住一句话就行：小站不折腾就上一键插件，大站或想要可控就手动搬，搬完的网址替换无论哪条路都务必用对工具。选哪条路是手段，把站点完整、正确地搬过去才是目的，别在工具选择上纠结太久。

搬家前怎么做准备，把翻车风险压到最低？

保哥见过的搬家事故，七成不是搬的时候手抖，而是事前没准备好。真正老练的做法，是把大半功夫花在动手之前。这几件准备工作，比任何技巧都管用。

选低峰时段，留足窗口。别在白天订单高峰、或者周一上午流量最大的时候搬。挑深夜、周末这种访问最少的时段，给自己留一个完整的、不被打扰的窗口。搬家中途被一通客户电话打断、回来忘了搬到哪一步，是返工的常见诱因。

先在新主机上预演一遍。有条件的话，正式切换前先把整套流程在新主机上完整跑一遍——文件传过去、库导进去、配置改好、用本地hosts指过去预览。这一遍的目的是把所有会卡壳的地方提前暴露：PHP版本对不对、数据库版本兼容不兼容、有没有插件在新环境报错。预演过的搬家，正式切换时心里有底，不会临场手忙脚乱。

写好回滚预案。动手前先想清楚一件事：万一新站起不来，我怎么退回去？答案通常是——旧站先别动、DNS没切之前旧站一直在线，真出问题就是不切DNS、继续用旧站，按下暂停键重新排查。备份在手、旧站不拆，这两条就是你的安全网。带着退路搬家，和裸奔搬家，心态和成功率完全是两回事。

对齐新旧环境。提前确认新主机的PHP版本、数据库版本、必要的扩展，尽量和旧主机对齐或更高。环境差异是搬家后“站点能开但功能报错”的隐形元凶，比如旧站跑在某个PHP版本上，新主机版本太新或太旧，某些老插件直接罢工。这些在预演时就该发现并处理。

手动搬家的标准动作是什么？

保哥把手动搬家拆成五步，这是最通用、最不容易漏的骨架。先在旧站这边做备份导出，再到新主机这边还原配置。

第一步，备份并导出。导出整个数据库（用主机面板的phpMyAdmin导出，或用WP-CLI的导库命令），同时打包整个站点目录，尤其确认wp-content/uploads完整。用命令行的话，导库一句话就够：

wp db export backup.sql
tar -czf wp-files.tar.gz /path/to/wordpress

这一步同时也是你的退路。搬家前的完整备份，是万一新站出问题能回滚的唯一保险。备份这件事的完整方法论，保哥在WordPress备份方案5维对照里讲透了，搬家前务必先有一份能还原的备份在手。

第二步，传文件到新主机。把打包好的站点文件传到新主机的网站根目录解包。文件多用scp或rsync传比FTP快且不易丢文件，rsync还能断点续传，大站点尤其推荐。传完核对文件数量和uploads目录大小，确认没传漏。一个实用的核对办法是分别在新旧主机数一下文件总数和目录总大小，两边对得上才算传全；FTP传几万个小文件时最容易悄悄漏掉几个，事后图片零星裂开，回头找原因特别费劲。能在服务器之间直接rsync的，就别绕道下载到本地再上传，又慢又容易出岔子。

第三步，在新主机建库并导入。在新主机上新建一个空数据库和数据库用户，把第一步导出的SQL导进去。注意记下新库的库名、用户名、密码，第四步要用。

第四步，改wp-config.php。把wp-config里的数据库主机、库名、用户名、密码改成新主机的值。如果新主机数据库表前缀不同，table_prefix也要对应改。改错这里的任何一项，访问站点就是一个“建立数据库连接出错”的白屏。

第五步，替换数据库里的网址。如果换了域名，数据库里到处都嵌着旧网址，必须全部替换成新网址。这一步是最大的坑，绝不能用简单的SQL替换，下一节专门讲为什么。只换主机不换域名的话，这步可以跳过，但仍要确认wp_options表里的siteurl和home指向正确。万一这两个值错了导致后台都进不去，可以临时在wp-config里用WP_SITEURL和WP_HOME两个常量强制指定，先把后台救进去再慢慢处理。这是搬家被锁在后台门外时的一条应急通道，值得记住。

为什么数据库里的网址不能直接用SQL replace？序列化数据是什么坑？

这是整个搬家最反直觉、也最容易团灭的地方，保哥单开一节讲透。换域名时，你会想：网址旧的换新的，不就是一个查找替换吗？直接跑一句SQL的REPLACE不就完了？——千万别。这么干，轻则部分设置丢失，重则整站后台白屏起不来。

根子在序列化数据。WordPress很多设置（主题选项、插件配置、小工具）在数据库里不是普通文本，而是以PHP序列化的格式存的。序列化会把每个字符串的长度数字一起记下来，类似这样：一个10个字符的网址，前面会标着“长度等于10”。你要是把网址从旧的换成新的、长度变了，那个记录长度的数字却没跟着改，PHP一读这条数据，发现“说好10个字符怎么变了”，直接判定数据损坏、反序列化失败，对应的设置就全废了。

正确做法是用“懂序列化”的工具替换，它会在替换字符串的同时，自动把长度数字一并修正。WordPress官方的WP-CLI就内置了这个能力，官方文档明说它能智能处理PHP序列化数据。命令长这样，强烈建议先加--dry-run空跑预览影响范围，确认无误再实跑：

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

不会用命令行也有图形化方案：Better Search Replace、Velvet Blues这类插件同样能正确处理序列化数据，装上在后台点几下就行。记住一个铁律：替换WordPress数据库里的网址，只用专门的搜索替换工具，永远不要用phpMyAdmin里那个简单粗暴的SQL REPLACE。这一条记住了，能帮你避开搬家里最致命的一类事故。

保哥见过一个真实的惨案：一个团队换域名，技术嫌装插件麻烦，图省事直接在phpMyAdmin里跑了一条全库REPLACE把旧域名换成新域名。当时看着挺美，首页能开。可一进后台，整个主题的自定义设置全没了，几个核心插件直接白屏报错，页面布局塌成一团。

排查半天才发现是序列化数据被改坏了，最后只能从备份里把数据库整个还原，重新用WP-CLI规规矩矩替换一遍，白白折腾掉大半夜。这个坑的杀伤力就在于——出问题的不是你替换的那个网址本身，而是一堆看似无关的设置莫名其妙集体失灵，新手往往查到怀疑人生都想不到是替换方式的锅。所以这一步真没有捷径，老老实实用对工具，比事后从备份里捞要省心一百倍。

换域名和只换主机，操作上有什么不同？

搬家分两种情况，难度差一大截，先分清你是哪种。

只换主机、域名不变。这是简单模式。网址没变，数据库里的网址不用动，核心就两件事：把文件和数据库原样搬到新主机，然后把域名的DNS解析从旧服务器IP改指到新服务器IP。等DNS生效，访问者就自动落到新主机了，整个过程对网址零改动，风险最低。

换域名（顺便可能也换主机）。这是困难模式。除了搬文件搬库，还要把数据库里所有旧域名用上一节说的安全方式替换成新域名，确认wp_options表里的siteurl和home更新成新域名，并且——这点和SEO强相关——给旧域名配上指向新域名的301永久重定向，把旧域名攒下的权重和老访客都导过来。

这里要做的是逐页对应的301，让旧域名的每一篇文章精确跳到新域名的同一篇，而不是图省事把旧域名所有页面一股脑全跳到新首页，那样会丢掉绝大部分内页权重，得不偿失。还有一点容易忘：旧域名的解析和续费别立刻停，301重定向得靠旧域名一直在线才生效，至少维持一年以上，让搜索引擎和老用户有充足的过渡期。换域名实质上是搬家加迁移SEO两件事一起干，所以更要小心，建议配合前面提到的迁移保稳那篇一起操作。

保哥提醒一个常被忽略的点：换域名后，谷歌搜索控制台等工具里要做“地址变更”，并重新提交新域名的站点地图，告诉搜索引擎你搬家了。另外，如果旧站后台访问出现登录后不断跳回登录页、或跳到旧域名的怪现象，多半是网址没替换干净或缓存作祟，这个具体故障的修法，WordPress换域名后台跳转修复那篇有逐步排查。

DNS怎么切才能不中断、不让用户看到半截站？

DNS切换是搬家临门一脚，也是最容易出乱子的环节。问题出在DNS有“缓存生效时间”，也就是TTL——你改了解析，全球的DNS服务器不会立刻都知道，要等旧的缓存过期。这段过渡期里，有人访问的还是旧主机、有人已经访问新主机，处理不好就出岔子。

保哥的标准切换流程是这样的。提前降低TTL。计划搬家前一两天，先把域名解析的TTL调小（比如从默认的几小时降到300秒）。这样真正切换时，全球缓存能在几分钟内更新，过渡期最短。这一步要提前做，因为降低TTL本身也要等旧的长TTL过期才生效。

切换前先验证新站。别DNS一切就指望它没问题。可以在自己电脑改本地hosts文件，把新域名临时指向新主机IP，这样只有你自己访问的是新站，全网用户还在旧站。在这个“私人预览”状态下，把新站从头到尾点一遍：首页、文章、图片、后台、表单、支付，全部正常了再动DNS。

这个hosts预览技巧是搬家里最被低估的神器，保哥几乎每次都用。它的妙处是：在不影响任何真实用户的前提下，让你提前用真实域名访问新站，把所有“换了主机才会暴露的问题”全踩一遍。要知道很多bug只有在正式域名下才会现形（比如写死了域名的配置、跨域、SSL），用临时IP或临时域名预览发现不了。改完hosts验证完，记得把hosts那行删掉，否则你自己会一直被定向到新站，DNS真出问题了你还蒙在鼓里。

切换后确认全球生效。正式改了解析，别急着拆旧站。用在线的DNS查询工具看一下不同地区的解析是不是都更新到了新IP，或者本机用查询命令确认。只有当各地都指向新主机、且你确认流量确实落到了新站，才算切换完成。在此之前，旧站要一直备着。

正式切DNS并守住过渡期。验证没问题后，把解析IP正式改到新主机。接下来TTL生效的这段时间，新旧两个站可能同时被访问——这里有个致命坑：如果两边都连着各自能写入的数据库，用户在旧站下的单、发的评论，搬完后就丢了，数据两头分叉。保哥的做法是：切换窗口期内，要么挂维护页、要么让旧站只读，确保只有新主机在写数据。等TTL过完、确认流量全部落到新站，再解除限制。这段“谁在写库”的控制，是DNS切换不丢数据的核心。

搬完家必须验证哪些东西才算真完成？

站能打开，不等于搬家成功。保哥的验收清单，逐项过完才算真完成。

固定链接。到后台“设置—固定链接”里不改任何东西、直接点一次保存，强制重新生成伪静态规则。这是搬家后文章页全404最常见的修法，因为新主机的Nginx或Apache重写规则可能还没配好。

图片和媒体。随机翻几篇老文章，看图片是不是都正常显示。裂图通常是uploads没搬全、或者数据库里图片网址没替换干净。SSL与https。确认新主机装好了SSL证书、全站走https、没有“不安全”警告，也没有页面里夹着http资源导致的混合内容警告。

功能性验证。实测发一封测试邮件确认发信通道通；跑一遍下单、注册、会员登录等核心流程；确认评论、搜索、联系表单都能用。别只在前台扫一眼，凡是涉及和外部对接的（支付网关回调、第三方API、Webhook），都要实测一遍——这些往往绑定了服务器IP或域名白名单，换了主机或域名就可能失联，而且不主动测根本发现不了，等客户投诉付款不到账就晚了。电商和会员站，这一步比什么都重要。

SEO侧收尾。换了域名的，到搜索控制台做地址变更、提交新站点地图；检查robots.txt没有误带“禁止抓取”、页面没有残留的noindex标签——预发环境常设noindex，搬到正式站忘了去掉，会导致整站被搜索引擎踢出去。这一条保哥见过太多人栽，预发时为了不让搜索引擎收录测试站随手加了noindex，搬正式站时一忙就忘了删，结果排名好好的站点几周内被悄悄踢出收录，等发现流量断崖式下跌才回头查，损失已经造成。

性能和速度别忘了对比。搬家有时本身就是为了换更快的主机，那就该验证目标达到没有。搬完用测速工具对比一下新旧站的打开速度、首字节时间，确认新主机确实更快、或至少没变慢。顺便看看新主机的缓存（页面缓存、对象缓存、OPcache）有没有配上，CDN有没有正确指向新站。搬家是个顺手优化性能的好时机，别只满足于“能打开”，要追到“比以前更快”。

持续盯一段时间。搬完别立刻拆旧站。保哥建议旧主机至少再留一两周，一来DNS可能还有零星缓存指向旧站，二来万一新站冒出问题还能临时切回。同时盯一下404和服务器日志，把搬家遗留的死链、报错及时补上。这套“搬完不立刻拆、留好后路”的思路，和灾备演练里强调的可回滚是一脉相承的，保哥在灾备恢复演练那篇里把回滚这件事讲得更系统。

搬家最容易翻的车有哪些？

把前面散落的坑集中成一张事故清单，对着排查，能帮你躲掉绝大多数翻车。

翻车一：uploads没搬全，图片大面积裂。uploads目录往往最大，FTP传输容易中途断、漏文件。用rsync传并核对文件数，传完抽查老文章的图。翻车二：直接SQL替换网址，整站白屏。前面重点讲过，序列化数据被破坏的典型后果，务必用WP-CLI或专用插件替换。

翻车三：wp-config数据库信息或表前缀填错。表现是“建立数据库连接出错”白屏。逐项核对新库的主机、库名、用户、密码、表前缀。翻车四：固定链接没刷新，文章页全404。到固定链接设置里重新保存一次即可。翻车五：混合内容警告。页面里残留http开头的图片或脚本链接，全站搜索替换成https，或确认网址已统一替换。

翻车六：缓存和CDN还指着旧站。搬完清空所有缓存——WordPress缓存插件、服务器缓存、以及CDN的缓存，否则你看到的还是旧站的快照，白白以为搬家失败。翻车七：robots或noindex把新站屏蔽了。预发环境的禁止抓取设置带到了正式站，搜索引擎直接不收录，这是最隐蔽也最伤的坑，搬完第一时间检查。

翻车八：DNS没切干净，新旧站数据分叉。过渡期两边都在写库，订单评论丢失。靠前面说的维护期或只读控制来规避。翻车九：定时任务和邮件没搬。新主机上WP-Cron、备份任务、SMTP发信没重新配，表现为定时发布不触发、找回密码邮件收不到，这些不在文件里，要单独配。

常见问题解答

搬家会不会影响SEO排名？要注意什么？

分情况。只换主机、域名不变，对SEO几乎没影响——只要站点内容和网址结构没变，搬完正常打开、速度别变慢，搜索引擎基本无感。真正影响排名的是换域名：旧域名攒的权重不会自动转移，必须给旧域名配指向新域名的301永久重定向，并在搜索控制台做地址变更、重新提交站点地图，权重才能平稳过渡。另外搬家后务必检查没有误带noindex、固定链接结构保持一致、页面打开速度没退化。完整的迁移保稳打法，建议看站内那篇专讲迁移不掉流量的文章，它和本篇的技术执行是配套的。

用一键迁移插件还是手动搬家好？

看站点大小和你的技术能力。中小站点、不想碰命令行，用Duplicator、All-in-One WP Migration这类一键插件最省事，打包还原一条龙，还自动处理网址替换。但站点体积大（几个G以上）时，插件经常卡在打包或上传，免费版还有体积限制，这时候手动搬家反而更稳、更可控。手动搬不挑大小、不依赖插件，代价是要会一点数据库导入和命令行。保哥的建议：小站优先试插件，插件失败或大站，就老实手动搬。

为什么换域名后不能直接在数据库里用SQL查找替换网址？

因为WordPress很多设置以PHP序列化格式存储，这种格式会把每段字符串的长度数字一起记下来。你用普通SQL替换把网址改了、长度变了，但记录长度的数字没跟着改，PHP读取时发现长度对不上，会判定数据损坏、反序列化失败，导致主题选项、插件配置等设置丢失，严重时整站白屏。正确做法是用懂序列化的工具替换，比如WordPress官方的WP-CLI的search-replace命令，或者Better Search Replace这类插件，它们会在替换的同时自动修正长度数字。这是搬家最致命的坑，务必记牢。

DNS切换大概要多久才能全球生效？这期间网站会断吗？

取决于你设置的TTL。如果搬家前提前把TTL降到比如300秒，正式切换后大多数地区几分钟到几十分钟就能更新；如果TTL还是默认的几小时甚至一天，那就要等那么久才全部生效。这期间网站不会整体中断，但会出现“有人访问新站、有人还在旧站”的过渡状态。所以关键不是怕断，而是要管好这段过渡期：要么挂维护页、要么让旧站只读，确保只有新主机在写数据库，避免两边都写导致订单、评论数据分叉丢失。提前降TTL，就是为了把这段不确定期压到最短。

搬家后文章页全部打不开、显示404，是什么原因？

九成是固定链接的伪静态规则没在新主机生效。最快的解法：登录后台，进“设置—固定链接”，什么都不用改，直接点一次“保存更改”，强制重新生成重写规则，通常文章页立刻就恢复了。如果还不行，检查新主机的Nginx或Apache是否正确配置了WordPress的伪静态规则、Apache的话.htaccess文件有没有搬过来且可写。注意只有首页能开、内页全404，几乎都是这个重写规则的问题，而不是数据库或文件出错。

权威参考资料