很多朋友剛建立博客的時候都是采用國內優秀的博客系統：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，發現了幾個缺口，具體連續的文章如下圖所示：

那我就只有分批次導出了，具體導出文件如下：

導出時可以導出標簽、評論、內容等，按照自己的需要進行選擇，點擊提交就可了，如上圖所示，保存好文件。只要導出的時候沒有報錯那就一定沒問題。

導入數據之前請先設置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一一對應如此簡單。