很多朋友剛建立博客的時候都是採用國內優秀的博客系統：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 一一對應如此簡單。