很多朋友刚建立博客的时候都是采用国内优秀的博客系统：Z-BLOG，用一段时间过后很多人都想转移到 WordPress, 各种转移原因很多。学朋的主要原因就是 Z-BLOG 官方长时间不对博客进行维护升级。大家都知道一款免费给别人用的开源系统，随着时间的推移病毒、漏洞会越来越多，如果失去了官方的维护，这个系统终将会被淘汰。
起初学朋也在网上找了很多转移方面的案例、资料。最后找到了一些总结下开始转移，转移过程中并不像想象的那么轻松，遇到过很多问题，特别是转移系统过后的 URL 地址失效问题、标题问题，这对 SEO 那是极大的打击。
转移准备：
转移前全站数据备份，最好不要在当前空间上面进行转移，最好是新购买一个空间，数据复制过去在新的上面转移。为的就是转移失败不影响网站的正常访问以及转移失败后可以多次测试，达到最佳效果。力争把网站转移的时间对外看来仅仅是域名重新解析的那 10 分钟生效时间。
注意：请购买 linux 主机。
Z-BLOG 系统导出全部数据：
下载插件：Z-BLOG 完美转移到 wp-movabletype 转移工具
Z-BLOG 安装插件
进入 Zblog 的后台——插件管理——从本地导入 ZPI 文件——选择 (movabletype.zip)——然后提交，如图所示，安装完成后启用插件。
进入插件管理——然后单击 movabletype 插件右边的管理，进行内容的导出，如图所示：
这里笔者要重点说明下，数据导出有讲究。
就笔者的博客而言，栏目页的格式如 http://www.***.net/seo/
内页的格式如：http://www.***.net/post/123.html
栏目页的根式可以轻松的在 WP 程序后台设置，但是内页格式要想一一对应那就比较困难了。如 Z-BLOG 时候的 http://www.***.net/post/123.html 地址在转移过后对于改篇文章是否还是这个地址。之前 Z-BLOG 时期内页的根式为：
http://www.***.net/post/id.html ，该 ID 是数据库后台自动生成的文章编号 （连续的，但是如果中途发布的文章并删除了文章，该 ID 不会自动减少，如果遇到删除的文章那么这个 ID 号就空了，如果直接用工具全部导出，那势必全是连续的，导入到 WP 过后很明显会错位）
在导出数据上我查看了之前的所有数据文件的 ID，发现了几个缺口，具体连续的文章如下图所示：
那我就只有分批次导出了，具体导出文件如下：
导出时可以导出标签、评论、内容等，按照自己的需要进行选择，点击提交就可了，如上图所示，保存好文件。只要导出的时候没有报错那就一定没问题。
§
WordPress 系统导入数据：
导入数据之前请先设置 WP 的固定链接：
由于之前笔者的内容页地址为：http://www.***.net/post/id.html 那么现在我只需要这样设置即可，如图：
特别注意：请购买 linux 主机，如果是 Windows 主机 WP 系统会自动在地址前面加上栏目名 category，相对于优化当前情况就有点难了。除非更改 WP 的这项功能。如：www.***.net/category/post/123.html . 安装插件去掉 category, 插件名」WP No Category Base – WPML compatible」
进入 WordPress 后台——工具——导入——Movable Type and TypePad——选择刚才生成好的 「*.asp「，然后单击上传文件并导入，如图所示。
注意：这里提示文件的大小最大为 20M（根据不同的空间限制，大小不同），如果 Zblog 文章过多，生成的文件过大，那么我们可以分为多次操作 (分批次注意上面断开的缺口)，比如文章共有 100 篇，总大小为 30M，那么我们可以先生成前 50 篇，再生成后 50 篇。将体积控制下 15M 内，然后再上传到 WordPress 中。
特别注意：WordPress 在导入数据之前请确认文章表的自动增量已经到哪里了。如果你新安装的 wp 程序已经发布文章那他的自动增量 ID 号就已经不是从 1 开始的了。如果导入以上数据全部将错位。怎么查看呢？本地安装 Navicat for MySQL 数据库客户端 （百度一下即可找到破解版） 或者直接使用空间商提供的在线数据库查看程序。查看 WP 新数据库里面的 wp_posts 表。如图：
如果途中 「自动递增数值不为 0，那么需要清理该表自动增量值」 清理 MYSQL 数据库自动增量值的 SQL 语法如图，黑色部分是你的数据库名。写好后选择执行即可。
实际操作：
以上是全部转移过程的技术操作，现在就跟随笔者一起操作下吧。还有一点，WP 的数据库文章表的自动增量是从编号为 2 开始的。也就是说编号为 1 的系统给占了。那我们的文章就从 2 开始导入。
先来看笔者博客的文章连续程度：
从图中可以看出 编号为 1 系统会保留，2-5 连续，7-18 连续，20-30 连续，32-37 连续 等等，笔者就拿前面的几个作为例子来讲解，后面的和前面的操作步骤一样。具体可以得出：ID 为 1 的保留 ID 为 6 的没的 ID 为 19 的没的 ID 为 31 的没的。
步骤：那我们直接把之前导出的文件导入进入 WP 。首先导入 2-5.asp 文件，我们测试下，所有文章一一对应之前 Z-BLOG 的地址，并没有错位。如果你的出现错位了，那么需要你重新清理 MYSQL 数据库表的自动增量，清理方式上文中已经提到。然后分析原因重新来。
特别注意：WordPress 在安装完成后不要点击发布文章，原因是 WP 有自动保存草稿的功能，他会占用你的 ID 号。
如果以上 2-5 导入成功，实现了 URL 一一对应那我们来说 6 这个 ID 怎么被占用。以上说了 WP 有自动保存草稿的功能，他会自动占用 ID 号，如果你采用发布一篇文章的做法想占用 ID 为 6 的号码那就错了，因为在你发布这文章过程中每隔一段时间 WP 程序会自动保存草稿，如果你写这文章的时间长了不只是 ID 为 6 的被占用，有可能 7，8，9 等等也会被占用，所以不能采用 WP 的发布文章系统发布文章。除非你关闭了 WP 的自动保存草稿的功能。。那就只能从原来 Z-BLOG 系统上面导出一个 1 篇帖子的文件，在 WP 上面再导入，这样即可完美占用 ID 为 6 的位置。
我们继续导入 7-18.asp, 导入完成后理解查看是否和之前的 URL 一一对应，然后再导入一篇文章继续导入 20-30.asp，依次类推，每次导入完成都需要立即检查是否一一对应，查找原因。如果没有对应那就清理数据库自动增量从新来过。
结语：以上是 Z-BLOG 完美导入 WordPress 之 URL 篇的全部过程，不需要你做大量的 301，不需要你去监控每一个页面 URL 是否出现问题。换程序实现 URL 一一对应如此简单。