WordPress 网站迁移搬家
数据搬得过去，收录也得跟得上
迁移看着只是把文件和数据挪个地方，实际最容易出事的是三样：序列化数据被改坏、旧链接没接住、图片还指着原来的域名。我们做 WordPress 迁移，从 DedeCMS、Wix、Shopify 到各类老 CMS 都处理过，先盘清数据能拿到什么，再定迁移路径。
迁移的四个阶段
每一步都要能回退
迁移不是一次性动作，而是一条有检查点的流水线。任何一步没有验证通过，都不该往下走。
备份与盘点
旧站整站打包，数据库单独导出；同时统计文章、产品、栏目、图片数量，作为迁移后的核对基准。
搭目标环境
新服务器装好 PHP、数据库、SSL，先跑一个干净的 WordPress，固定链接结构按规划设好。
导入与清洗
内容按类型导入，正文里的旧标签、内联样式、失效图片逐批清洗，图片下载到本地媒体库。
切换与核验
域名解析切到新站，旧地址挂 301，逐项核对数量、链接、表单、支付与统计代码。
最大的坑
用 SQL 直接替换域名
这是 WordPress 迁移里最经典的事故，几乎所有”迁完主题设置全丢”的案例都出自这里。
WordPress 把主题选项、小工具、页面构建器的配置存在数据表里，值是 PHP 序列化后的字符串。序列化格式会在每个字符串前写明长度，例如 s:15:”www.old.com/a” 里的 15 是字节数。如果新域名长度不同，直接执行 UPDATE wp_options SET option_value = REPLACE(option_value,’old.com’,’new.com’)，字符串变长了，但长度标记还是 15，反序列化时就会失败，PHP 拿到的是 false，表现出来就是主题设置空白、小工具消失、页面构建器内容读不出来。
正确做法
- 用 WP-CLI：wp search-replace 旧域 新域 –all-tables –precise –recurse-objects
- 没有命令行环境，用 Better Search Replace 这类会重算长度的插件
- 替换前先导出整库，替换后抽样打开主题设置页确认
- 对象缓存与 CDN 缓存要一并清空，否则前台还是旧值
还有这些细节
- guid 字段不建议改，它是内容的永久标识，改了可能导致订阅源重复
- siteurl 与 home 两个 option 必须同时改，只改一个会后台跳转异常
- 固定链接页保存一次，刷新 rewrite 规则，否则内页全 404
- wp-config.php 里的数据库连接、盐值、调试开关逐项核对
还有一类隐形问题：正文里写死的图片地址和站内链接。数据库替换能覆盖大部分，但 CSS 背景图、内联 style、页面构建器里存的 JSON 要单独检查。上线后用浏览器控制台看混合内容告警，把仍走 http 的资源逐个改掉。
四类来源
难点完全不一样
同样叫迁移，从 WordPress 搬到 WordPress 是最轻松的一种。下面这四类，处理方式差得很远。
从 DedeCMS 迁入
主表 dede_archives 存标题、栏目、发布时间，正文在 dede_addonarticle，栏目在 dede_arctype，标签在 dede_taglist，要按 aid 关联后导出。老站常是 GBK 编码，导出前必须转 UTF-8，否则中文全是乱码。正文里的 {dede:field} 标签、[field:x] 调用要批量清掉，图片路径多为 /uploads/allimg/ 加日期目录，需要整体下载并重写。旧地址形如 /a/202405/123.html，要按 aid 一对一映射到新文章。
从 Wix 迁入
最麻烦的是没有数据库可导。后台只能导出产品、联系人等少数几张表，页面正文没有结构化出口，页面由前端脚本渲染，直接抓源码拿到的往往是空壳。做法是用浏览器渲染后的 DOM 逐页提取，图片从 static.wixstatic.com 按原始尺寸下载再上传媒体库。博客只能靠导出或逐篇复制。会员、订单、表单历史基本无法迁移，只能保留 CSV 存档。旧地址 /post/、/product-page/ 要逐条 301。
从 Shopify 迁入
数据可得性最好：产品、订单、客户、博客都能导 CSV。难点在结构转换——Shopify 一个产品带多个变体，CSV 里是同一 Handle 多行，Option1/2/3 对应颜色尺码，导入 WooCommerce 要拆成可变商品并生成属性。集合分智能集合与手动集合，规则无法直接搬，要重建。产品图在 cdn.shopify.com，需要下载本地化。客户密码用的是另一套哈希，迁不过来，只能群发重置密码邮件。结账流程与已装的支付方式也不能迁，需要重新配置。
从其他 CMS 迁入
Joomla 看 #__content 与 K2 的扩展表，Drupal 看 node、field_data_body、taxonomy_index 三张表关联，Discuz 的帖子与板块结构差别更大。静态 HTML 站点没有数据库，只能用抓取工具把页面拉下来，按目录结构写重定向规则。WordPress.com 托管的站最简单，后台导出 WXR 文件，新站用导入器读取即可，但主题、插件和自定义代码不在导出范围内。
各来源迁移难度对照
先看数据能拿到几成
难度不只看数据量，更看数据结构是否可读、是否有唯一键可对齐。下表按实际项目经验估算。
| 来源系统 | 数据可得性 | 主要难点 | 建议做法 |
|---|---|---|---|
| WordPress 旧站 | 完整 | 域名替换破坏序列化；插件遗留表 | 整库导出，WP-CLI 替换，保留自定义表 |
| DedeCMS | 较完整 | GBK 编码；正文含模板标签；分表关联 | 转码后导出 CSV，清洗标签，按 aid 映射 |
| Wix | 部分 | 无数据库导出；页面脚本渲染；会员订单缺失 | 渲染后抓取 DOM，图片重下，逐页 301 |
| Shopify | 较完整 | 变体拆解；集合规则；客户密码不可迁 | CSV 导入，按 Handle 聚合，群发重置密码 |
| Joomla / Drupal | 完整但结构复杂 | 字段表拆分；分类体系差异 | 写映射脚本，先导栏目再导内容 |
| 静态 HTML 站 | 仅页面 | 无结构化字段；目录层级混乱 | 抓取后重建栏目，按目录批量写 301 |
迁移往往伴随域名或结构调整，这时 301 的规划要按改版的标准来做，可参考 WordPress 网站改版升级 里的 URL 对照表方法。若旧站本来就被人挂过马或留了后门，数据搬过来会把问题一起带过来，建议先做 WordPress 安全加固与木马清理 再导库。
切换之后的一周
决定这次迁移算不算成功
数量核对
文章、产品、栏目、图片四项数量与盘点基准对齐，误差超过 1% 就要查漏。
链接巡检
抽样两百个旧地址，确认全部 301 到内容对应的新页，没有跳到首页的。
功能实测
表单收信、支付下单、会员登录、搜索、多语言切换，逐项走一遍真实流程。
速度基线
新站首字节时间不应高于旧站，高于就查缓存、图片和数据库索引。
提交与监控
重提 sitemap，绑定站长工具，开启 404 与可用性监控，异常当天能发现。
备份策略
切换完成后立即建立每日自动备份，异地存一份，旧站快照保留至少一个月。
迁移常见问题
动手前先问这几句
取决于数据量和来源系统。WordPress 到 WordPress，通常两三小时可以完成切换；DedeCMS 或 Shopify 这类需要清洗和映射的，主体工作在测试环境完成，最后切换本身仍是几小时。切换期间建议挂一个维护提示页，而不是让访客看到报错。
做好一对一 301，绝大多数页面能平稳过渡。掉收录通常发生在三种情况：旧地址直接 404、全部跳到首页、新站内容大幅删减。我们不做排名承诺，但会把映射覆盖率和 404 监控做到可查，出问题能第一时间定位。
订单和客户资料可以导出 CSV 存档，但密码无法迁移，因为加密方式不同。会员需要在新站重新注册或由你群发通知重置。订单历史可以导入 WooCommerce 作参考记录，但支付流水、退款状态这些字段对不上，建议只保留在旧后台备查。
Shopify 产品地址是 /products/句柄，集合是 /collections/句柄。导入时把句柄写进新产品的 slug，就能保持路径语义一致，再对旧前缀做规则重写。变体要按 Handle 聚合，SKU 作为唯一键，导入前先清理重复 SKU，否则后导入的会覆盖先导入的。
常见三种：图片没下载到本地，仍指向原域且原域已停；数据库替换时改坏了序列化字段；服务器没配好防盗链或文件权限。逐项排查的顺序是先看图片地址指向哪里，再看文件是否真实存在，最后查权限与 CDN 缓存。
可以自己管，也可以签 WordPress 托管维护。刚迁完的头一个月建议至少保留技术支持，插件兼容、缓存配置、邮件送达这些问题往往在上线后一两周才暴露。需要重做版式的，另见 WordPress 仿站。
先说清旧站是什么系统，
迁移方案才定得下来
把旧站地址和后台类型发给我们，先出一份数据可得性评估，说明哪些能迁、哪些只能重建。电话/微信 13280692153，邮箱 web@wordpressx.com。