很多朋友剛建立部落格的時候都是採用國內優秀的部落格系統:Z-BLOG,用一段時間過後很多人都想轉移到 WordPress, 各種轉移原因很多。學朋的主要原因就是 Z-BLOG 官方長時間不對部落格進行維護升級。大家都知道一款免費給別人用的開源系統,隨著時間的推移病毒、漏洞會越來越多,如果失去了官方的維護,這個系統終將會被淘汰。

起初學朋也在網上找了很多轉移方面的案例、資料。最後找到了一些總結下開始轉移,轉移過程中並不像想象的那麼輕鬆,遇到過很多問題,特別是轉移系統過後的 URL 地址失效問題、標題問題,這對 SEO 那是極大的打擊。

轉移準備:

轉移前全站資料備份,最好不要在當前空間上面進行轉移,最好是新購買一個空間,資料複製過去在新的上面轉移。為的就是轉移失敗不影響網站的正常訪問以及轉移失敗後可以多次測試,達到最佳效果。力爭把網站轉移的時間對外看來僅僅是域名重新解析的那 10 分鐘生效時間。

注意:請購買 linux 主機。

Z-BLOG 系統匯出全部資料:

下載外掛:Z-BLOG 完美轉移到 wp-movabletype 轉移工具

Z-BLOG 安裝外掛

進入 Zblog 的後臺——外掛管理——從本地匯入 ZPI 檔案——選擇 (movabletype.zip)——然後提交,如圖所示,安裝完成後啟用外掛。

z-blog完美轉移到WordPress

進入外掛管理——然後單擊 movabletype 外掛右邊的管理,進行內容的匯出,如圖所示:

z-blog完美轉移到WordPress

這裡筆者要重點說明下,資料匯出有講究。

就筆者的部落格而言,欄目頁的格式如 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,發現了幾個缺口,具體連續的文章如下圖所示:

z-blog資料匯出分析

那我就只有分批次匯出了,具體匯出檔案如下:

Z-BLOG連續文章分批次匯出

匯出時可以匯出標籤、評論、內容等,按照自己的需要進行選擇,點選提交就可了,如上圖所示,儲存好檔案。只要匯出的時候沒有報錯那就一定沒問題。

§

WordPress 系統匯入資料:

匯入資料之前請先設定 WP 的固定連結:

由於之前筆者的內容頁地址為:http://www.***.net/post/id.html  那麼現在我只需要這樣設定即可,如圖:

WP設定固定連結

特別注意:請購買 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 中。

WP匯入資料

特別注意:WordPress 在匯入資料之前請確認文章表的自動增量已經到哪裡了。如果你新安裝的 wp 程式已經發布文章那他的自動增量 ID 號就已經不是從 1 開始的了。如果匯入以上資料全部將錯位。怎麼檢視呢?本地安裝 Navicat for MySQL 資料庫客戶端 (百度一下即可找到破解版) 或者直接使用空間商提供的線上資料庫檢視程式。檢視 WP 新資料庫裡面的 wp_posts 表。如圖:

Navicat for MySQL 檢視WordPress的表

如果途中 「自動遞增數值不為 0,那麼需要清理該表自動增量值」 清理 MYSQL 資料庫自動增量值的 SQL 語法如圖,黑色部分是你的資料庫名。寫好後選擇執行即可。

清理MYSQL資料表自動增量語法

實際操作:

以上是全部轉移過程的技術操作,現在就跟隨筆者一起操作下吧。還有一點,WP 的資料庫文章表的自動增量是從編號為 2 開始的。也就是說編號為 1 的系統給佔了。那我們的文章就從 2 開始匯入。

先來看筆者部落格的文章連續程度:

z-blog資料匯出分析

從圖中可以看出 編號為 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 一一對應如此簡單。