從無名、Xuite、Blogger到 Synology NAS WordPress｜20 年網誌搬家、Docker、Caddy 與SEO修復

我的網誌不是第一次搬家。

從 2003 年開始寫網誌以來，它先後住過無名小站、中華電信隨意窩與 Google Blogger。每一次搬家，我關心的都不只是文章能不能帶走，還包括圖片、留言、發布日期、分類、網址，以及多年後還能不能從搜尋引擎找到它們。

2003–2013：Wretch 無名小站
2013–2023：Xuite 中華電信隨意窩
2023–2026：Google Blogger
2026 至今：Synology NAS＋Docker＋WordPress＋MariaDB＋Caddy

二十多年下來，我逐漸明白：把文章匯入新平台，只是搬家的第一步。真正困難的是，如何讓不同年代累積的圖片、HTML、網址與文章關係，在新網站裡仍然保持正確。

而這一次和以前最大的差別，是我不只是從 Blogger 換到另一套部落格系統。我也沒有單純在 Synology NAS 裡使用現成的 WordPress 架設方式，而是把 WordPress、MariaDB 與其他網站服務放進 Docker 環境，再自行設定 Caddy 與 Caddyfile，統一管理 HTTPS、反向代理與不同網址路徑。

換句話說，WordPress 只是整套網站架構中的其中一個服務，而不是整台 NAS 的網站中心。

這篇文章記錄我為什麼最後離開 Blogger，改在 Synology NAS 自架 WordPress，也整理搬家後實際遇到的圖片錯置、排版損壞、搜尋結果展開全文、網址轉址、索引篩選、分類標籤及手機版面問題，同時分享 Docker、MariaDB、Caddy 在這套架構裡各自扮演什麼角色。

從無名、隨意窩到 Blogger

2003 年開始使用無名小站時，我沒有想過網誌會持續寫二十多年。當時的部落格比較像線上日記，文章、照片、留言與朋友之間的互動，都依附在平台提供的功能上。

後來無名小站結束服務，我把內容搬到中華電信隨意窩；隨意窩結束後，又在 2023 年搬到 Blogger。Blogger 免費、穩定，背後也有 Google 維護，對於只想繼續保存和發布文章的人來說，其實是相當省事的選擇。

但每一次平台停止服務，都會留下相同的問題：平台裡保存的不只是文章本文，還有圖片路徑、留言、日期、分類方式、站內連結及外部網站累積多年的連結。只要其中一部分無法完整帶走，文章雖然還在，原本的脈絡卻可能慢慢消失。

也因為先後經歷無名與隨意窩停止服務，我開始不想再把二十多年累積的內容完全交給下一個第三方平台決定命運。

為什麼離開 Blogger

離開 Blogger 並不是因為它不能寫文章，也不是因為 Blogger 的文章不能被 Google 收錄。Blogger 和 WordPress 都能建立可被搜尋引擎讀取的網站；真正的差異，是我想控制的事情已經超過 Blogger 原本提供的範圍。

Blogger 可以替單篇文章設定英文代稱，但網址通常仍維持「年份／月份／文章名稱.html」的結構。搬到 WordPress 後，我可以依網站內容重新設計網址，例如：

分類目錄不只是讓網址比較好看，也能讓讀者一眼知道文章屬於桌遊、電玩或電腦資訊。除此之外，我還能自行控制 Meta Description、Canonical、XML Sitemap、結構化資料、文章索引狀態、相關文章、搜尋結果、熱門文章與響應式版面。

所以，WordPress 並不是「裝好就會自動得到更好的排名」，而是提供更完整的技術 SEO 控制。網站是否容易被理解與收錄，仍取決於內容品質、網址是否穩定、HTML 是否正確、站內連結是否清楚，以及伺服器能不能正常回應。

為什麼選擇 Synology NAS＋WordPress

既然決定離開 Blogger，我沒有再尋找另一個功能相近的免費部落格平台，而是把 WordPress 部署到自己的 Synology NAS。

這個決定不只發生在網誌，也延伸到我的攝影作品。過去二十年間，照片曾經跟著不同網路相簿平台不斷搬遷；平台停止服務時，照片、說明、分類與分享連結也可能一起失去。

因此，我另外在 Synology NAS 上開發了 Skypray Photography Platform：從攝影者需求出發，自主開發的攝影管理平台，將照片、EXIF、GPS、相簿、搜尋與公開展示掌握在自己手中。

網誌從 Blogger 搬到 WordPress，其實也是同一個想法：不只是換一套發文工具，而是重新取得內容、網址、資料與網站功能的控制權。

自架帶來的優點很明確：

文章、圖片、資料庫與備份由自己管理。
可以依需求開發功能，不必等待平台提供。
網址、搜尋、分類、標籤與 SEO 規則能夠統一。
能與攝影網站、網站分析及其他 NAS 服務整合。
WordPress 可以獨立更新或重建，不必成為整套網站架構唯一核心。
最外層的 HTTPS、網址路由與反向代理也由自己管理。

但自由也有代價。Docker、資料庫、權限、HTTPS、備份、安全、硬碟寫入、反向代理與故障復原，都變成自己需要處理的事情。

第三方平台或現成架站環境替使用者隱藏了很多維護工作；完全自架則是用維護責任交換控制權。

我不是使用現成 WordPress：Docker＋MariaDB＋Caddy 架構

「在 Synology NAS 上架 WordPress」其實可以代表完全不同的架設方式。

比較簡單的作法，可以利用 DSM、Web Station 或圖形化設定完成網站環境，再把 WordPress 當成主要網站。這種模式設定比較直觀，也很適合只需要一個 WordPress 網誌的人。

我的方式則不同：

我先建立自己的網站服務架構，再把 WordPress 放進這套架構裡。

目前網誌相關架構可以簡化成幾個主要角色：

Synology NAS：提供實際主機與儲存空間。
Docker：讓不同網站服務分開執行。
WordPress：負責文章、分類、標籤與管理後台。
MariaDB：負責保存 WordPress 的文章、設定、留言等資料。
Caddy：負責最外層網站入口、HTTPS 與反向代理。
Caddyfile：記錄 Caddy 應該如何處理不同網址與服務的規則。

如果把整台 NAS 想像成一棟房子，可以用更簡單的方式理解：

Synology NAS＝整棟房子。
Docker＝把房子隔成不同房間。
WordPress＝負責經營網誌的工作室。
MariaDB＝工作室裡保存資料的檔案櫃。
Caddy＝站在大門口負責帶路的服務台。
Caddyfile＝服務台手上的導覽規則。

整體概念大致如下：

Internet ↓ Caddy ↓ 依網址分流 ├── /blog/ │ ↓ │ WordPress │ ↓ │ MariaDB │ ├── /photogallery/ │ ↓ │ 攝影網站 │ └── 其他網址 ↓ 其他 Web App

以上服務執行在 Synology NAS 上需要的應用程式則以 Docker 分開管理

讀者打開一篇文章時，實際流程也不是單純「瀏覽器直接找到 WordPress」。

請求先來到 Caddy，Caddy 判斷網址後把它交給 WordPress；WordPress 再向 MariaDB 取得文章內容與相關資料，最後組成網頁回傳給瀏覽器。

Docker 是什麼？把不同服務分開管理

Docker 是一種容器化技術。如果不談太多技術細節，可以把它理解成：讓不同程式各自在自己的環境中執行，而不是把所有東西混在 NAS 同一套系統環境裡。

我的 NAS 不只需要 WordPress，還有資料庫、攝影網站、網站分析與其他 Web App。

如果全部直接安裝在同一個系統環境，久了可能出現：

不同程式需要不同版本的套件。
升級某個服務卻影響另一個服務。
設定與檔案彼此混在一起。
未來換機或重新安裝時，很難重現原本環境。

Docker 的概念就是把它們拆開：

Synology NAS │ └── Docker ├── WordPress ├── MariaDB ├── 攝影網站 ├── 網站分析 └── 其他服務

每項服務都有自己的執行環境，但需要合作時仍然可以透過內部網路互相溝通。

例如 WordPress 能連到 MariaDB，Caddy 能把網誌流量送往 WordPress，但外面的讀者完全不需要知道它們實際跑在哪個容器或使用什麼內部 Port。

為什麼我選擇 Docker？

對我來說，Docker 最大的價值不是「比較進階」，而是不同服務比較容易分開管理。

例如 WordPress 發生問題時，我可以只處理網誌相關服務，不必改動攝影網站；攝影網站更新，也不需要重新設定 WordPress。

另外，Docker 的部署設定可以保存。只要網站資料、設定檔與部署資訊仍然存在，即使未來需要重建服務，也比較容易知道原本環境是怎麼組成的。

當然，Docker 也增加了學習成本。除了 WordPress，還需要理解容器、Volume、網路、更新與備份等概念。

如果只是想要一個單純的 WordPress 網誌，其實不一定需要走到這一層。

MariaDB 是什麼？WordPress 的「資料櫃」

第一次架 WordPress 時，很容易把注意力全部放在 WordPress 本身，卻忽略了背後的資料庫。

WordPress 並不是把所有文章內容直接存在網頁檔案裡。

文章文字、頁面、留言、分類、標籤、使用者資料及大量網站設定，都需要保存到資料庫。

我的 WordPress 使用的資料庫就是 MariaDB。

可以把兩者想成：

WordPress：讓我新增、修改、整理與顯示文章。
MariaDB：在後方真正保存這些結構化資料。

例如我在 WordPress 後台修改一篇文章：

我在 WordPress 編輯文章 ↓ WordPress 將內容寫入 MariaDB ↓ MariaDB 保存文章資料

讀者之後打開文章：

讀者要求開啟文章 ↓ WordPress 向 MariaDB 查詢 ↓ MariaDB 回傳文章資料 ↓ WordPress 組成網頁 ↓ 顯示給讀者

因此，自架 WordPress 的備份不能只備份 WordPress 程式檔案。

MariaDB 資料庫同樣是網站最重要的備份內容之一。

如果 WordPress 程式還在，但資料庫遺失，文章文字、留言與大量網站設定仍可能一起消失。

為什麼 WordPress 和 MariaDB 要分開？

在我的 Docker 架構中，WordPress 與 MariaDB 是不同服務。

這等於把：

負責執行網站的程式
負責保存網站資料的資料庫

分開管理。

未來如果重新建立或更新 WordPress，只要資料庫、媒體檔案與其他持久化資料保存正確，就不需要把整個網站視為一個完全無法拆解的黑盒子。

Caddy 是什麼？網站大門口的「總機」

Docker 解決的是「不同服務怎麼分開執行」，MariaDB 解決的是「WordPress 的資料放在哪裡」。

接下來還有一個問題：

外面的讀者要怎麼找到這些服務？

這就是 Caddy 的工作。

Caddy 是一套 Web Server，也可以作為反向代理（Reverse Proxy）。

如果不談複雜的網路技術，可以把它想像成大樓一樓的服務台或總機。

我的 NAS 裡可以同時存在：

WordPress 網誌
攝影網站
網站分析
其他自行開發的 Web App

外部讀者並不需要知道 WordPress 在哪個 Docker、攝影網站在哪裡，或每項服務實際使用哪個內部 Port。

使用者只需要輸入：

skypray.synology.me/blog/
skypray.synology.me/photogallery/

Caddy 收到網址後，就像服務台查看訪客要去哪裡，再把請求送到正確的服務。

讀者 ↓ skypray.synology.me ↓ Caddy ├── /blog/ → WordPress ├── /photogallery/ → 攝影網站 └── 其他路徑 → 其他 Web App

因此在我的架構裡，WordPress 並不是直接站在 Internet 最前面，而是位在 Caddy 後方。

Caddy 也負責 HTTPS

Caddy 還能處理網站的 HTTPS。

也就是瀏覽器網址前面的 https://。

對一般讀者來說，可以簡單理解成瀏覽器與網站之間的資料傳輸受到加密保護。

我的作法不是讓每個 Docker 服務各自成為 Internet 的入口、各自處理 HTTPS，而是讓 Caddy 位在最外層統一接收連線，再把流量交給後方服務。

Internet ↓ HTTPS ↓ Caddy ↓ 內部服務 ├── WordPress ├── 攝影網站 └── 其他 Web App

Caddyfile 又是什麼？

Caddyfile 就是 Caddy 的設定檔。

如果 Caddy 是大門口的服務人員，Caddyfile 就像他手上的導覽表。

裡面會告訴 Caddy：

看到 /blog/，應該交給 WordPress。
看到 /photogallery/，應該交給攝影網站。
某些舊網址應該 301 轉到哪個新網址。
不同服務的流量應該如何處理。

所以我的網站並不是：

Internet → WordPress

而比較接近：

Internet ↓ Caddy ↓ 不同服務 ├── WordPress ──→ MariaDB ├── 攝影網站 ├── 網站分析 └── 其他 Web App

現成 WordPress 與我的架構有什麼不同？

比較項目	較現成的 Synology／WordPress 架設方式	我的 Docker＋MariaDB＋Caddy 架構
架站方式	以 DSM、Web Station 或圖形化設定為主	自行組合 WordPress、資料庫與網站入口
WordPress 定位	通常就是主要網站	只是整個網站平台中的其中一項服務
程式環境	較依賴 NAS 提供的網站環境	利用 Docker 將服務分開
資料庫	通常由既有安裝流程協助處理	MariaDB 作為獨立服務管理
網站入口	主要由 DSM／Web Station 等功能管理	Caddy 統一接收外部連線
反向代理	可透過圖形化介面設定	自行透過 Caddyfile 控制
HTTPS	由 NAS 既有網站與憑證功能管理	由 Caddy 作為統一入口處理
網址路由	一般網站需求已足夠	可依網址路徑分流不同 Web App
多網站整合	較適合一般網站配置	WordPress、攝影網站、分析與其他 Web App 可共存
更新	部分依套件與圖形介面管理	WordPress、MariaDB、Caddy 等服務可分別管理
備份	主要關注網站檔案與資料庫	還要保存 Docker 部署設定與 Caddyfile
設定難度	較低	較高，需要理解 Docker、資料庫與反向代理
控制程度	一般 WordPress 網誌已非常足夠	可控制網址、Proxy、Header、轉址與多服務分流
適合對象	主要需要一個 WordPress 網誌	同一台 NAS 同時營運多個網站與 Web App

這兩種方式沒有絕對的好壞。

如果需求只是「我想在 NAS 上有一個 WordPress」，較現成的方式設定簡單、維護成本也比較低。

但我的 NAS 不只有 WordPress，還有攝影網站、網站分析以及其他自行開發的 Web App。

對我來說，真正需要的是一套能把不同服務分開管理，又讓它們共享統一網站入口的架構。

為什麼我的 /blog/ 架構需要自行管理路由？

另一個重要原因，是我的網站大量使用同一網域下的不同網址路徑。

一般多網站架構可以把服務拆成不同子網域，例如：

blog.example.com photo.example.com analytics.example.com

這種方式很好理解：不同子網域就是不同服務。

但我的網站比較接近：

example.com/blog/ example.com/photogallery/ example.com/其他服務/

也就是全部先進到同一個網域，再依網址後面的路徑決定要去哪個服務。

使用者輸入的網址	Caddy 判斷後交給
`/blog/`	WordPress
`/photogallery/`	攝影網站
`/其他服務/`	對應的 Web App

這就像同一間醫院只有一個主要入口，但進門之後：

有人要去心臟內科。
有人要去眼科。
有人要去影像醫學部。

Caddy 就像入口服務台，先看你要去哪一科，再把你導向正確的位置。

當然，並不是只有 Caddy 能做到這件事。Nginx、Apache 或其他 Web Server／Reverse Proxy 也能實現類似架構；只是我的網站選擇使用 Caddy，並透過 Caddyfile 統一管理。

為什麼不公開完整 Caddyfile 與 Docker 設定？

實際環境還會涉及 Docker 內部網路、服務名稱、連接埠、環境變數、資料庫設定與檔案路徑。

這篇文章的目的，是分享網站架構為什麼這樣設計，而不是提供一份所有人可以直接複製貼上的 NAS 設定檔。

尤其現在 AI 已經很適合協助產生 Docker Compose、Caddyfile 或其他設定，真正重要的反而是先理解每一層負責什麼。只有理解架構，當 AI 產生的設定不能正常運作時，才知道問題可能出在 WordPress、MariaDB、Docker 還是 Caddy。

如果只用一句話來形容：Synology NAS 是房子，Docker 把服務分成不同房間，WordPress 負責網誌，MariaDB 保存網誌資料，而 Caddy 站在大門口，依照 Caddyfile 把訪客送到正確的服務。

WordPress 可以自訂文章網址嗎？

可以。文章先儲存為草稿後，WordPress 預設的區塊編輯器就能在文章設定中修改網址最後一段，也就是 Slug；文章列表的「快速編輯」同樣可以修改代稱。操作方式可參考 WordPress 官方的文章設定側欄說明。

以我的文章網址為例：

https://skypray.synology.me/blog/computer/blog-migration-blogger-wordpress/

/blog/ 是 WordPress 網站所在路徑。
/computer/ 是文章分類目錄。
/blog-migration-blogger-wordpress/ 是單篇文章的 Slug。

單篇文章編輯器主要控制最後一段 Slug；整個網站要不要加入日期、分類或文章名稱，則由「設定 → 永久連結」決定。WordPress 支援以 %category% 與 %postname% 組成自訂結構，詳細規則可參考 WordPress 永久連結設定。

網址發布後就不應隨意更改。若修改 Slug、分類或整體永久連結結構，必須確認舊網址能永久轉址到新網址。

成功匯入不等於搬家完成

Blogger 可以透過 Google Takeout 匯出文章與留言；Google 的 Blogger 備份與匯入說明也提供相關步驟。

但備份檔能讀取、文章能出現在 WordPress 後台，不代表整個網站已經正確搬完。

匯入後仍然要逐項確認：

圖片是否真的進入 WordPress 媒體庫，而不是繼續引用舊平台網址。
文章日期、留言與作者是否正確。
文章內部連結是否仍指向舊網站。
不同文章是否誤用同一張圖片。
HTML 結構在首頁、分類、搜尋及單篇文章是否都正常。
舊網址是否能到達正確的新文章。
搜尋引擎應該收錄哪些頁面。

我的網誌跨越多個平台與年代，搬家後真正花時間的工作，也正是這些「資料已經進來，但關係不一定正確」的問題。

圖片為什麼跑到錯誤文章

我遇過一個很具體的例子：〈2023 十大桌遊排行與心得〉的第一張圖，其實應該屬於〈路易斯與克拉克的遠征〉文章。

檢查匯入程式後，原因終於確認。兩篇文章的原始圖片都叫做 Snap1.jpg，但內容與來源路徑完全不同。

當時的匯入流程為了避免重複下載，曾使用「圖片檔名」建立本機索引與快取。第二次遇到同名檔案時，程式便誤以為媒體庫裡已經存在同一張圖，直接重用了第一張圖片的 WordPress 網址。

也就是說，問題不是 WordPress 隨機把圖片放錯，而是搬家工具把「同名圖片」錯認成「同一張圖片」。

正確的圖片識別方式不能只看檔名，至少應該使用下列其中一種方式：

完整來源網址。
包含資料夾的原始相對路徑。
圖片內容的雜湊值。
來源網址與文章 ID 的組合。

大量搬移媒體後，也應列出重複檔名，抽查每張圖所在的文章，不能只用「成功下載幾張」判斷結果。

排版為什麼會跑掉

舊文章經過無名、隨意窩、Blogger，再進入 WordPress，等於把不同年代的 HTML 一起帶進新網站。若文章又曾從 Microsoft Word 或其他編輯器複製貼上，結構會更加複雜。

過去隨意窩支援 Word 轉貼，沒想到貼進來的碼如此「不乾淨」；還好到了 AI 時代，可以請 AI 協助重新清理臃腫的 HTML 碼。

我實際整理過的問題包括：

大量空白的 <p> 與 <br>。
多層且跨越段落的 <span style="...">。
用表格控制圖片位置與圖說。
段落標籤互相巢狀。
<li> 沒有放在 <ul> 或 <ol> 裡。
Word 留下的字型、行距與內嵌樣式。
屬性順序錯誤或沒有正常閉合的圖片標籤。
已經不存在的舊平台 CSS 類別。

瀏覽器遇到不合法的 HTML 時，不會直接拒絕顯示，而是嘗試自行修復。

問題在於，瀏覽器推測的結構不一定符合作者原意。同一段舊 HTML 放進單篇文章、搜尋結果或不同版面時，也可能產生完全不同的結果。

因此，清理舊文不能只把空白全部取代掉。比較安全的順序是：先保存原文、解析 HTML 結構、修正標籤階層、比較清理前後的純文字，再檢查圖片與標題數量，最後才覆蓋正式文章。

搜尋結果為什麼意外展開全文

〈動物園之星生涯模式全關卡指南〉曾出現一個很奇怪的問題：直接閱讀文章時大致正常，但從 WordPress 搜尋「動物園之星」，搜尋結果卻把整篇文章內容展開，破壞原本的列表模式。

真正原因藏在文章開頭的目錄。

部分 <li> 直接放在目錄容器中，沒有正確包在 <ul> 或 <ol> 裡；子目錄也沒有正確放入所屬的主項目。

WordPress 的文章搜尋結果本身也是用清單排列。當瀏覽器嘗試修復文章內不合法的清單標籤時，提前結束了外層的文章清單項目，後續正文因而被移到文章卡片之外。

列表模式原本只會隱藏文章卡片內的正文，但已經逃到卡片外面的內容不再受這項規則控制，於是整篇文章便出現在搜尋頁上。

這不是 WordPress 搜尋刻意顯示全文，而是單篇文章的錯誤 HTML 破壞了搜尋結果頁面的 DOM 結構。

最後的修正分成兩層：

把文章目錄改成合法的 <nav> → <ol> → <li> 階層。
首頁、分類、標籤與搜尋頁不再直接輸出舊文章 HTML，而是先轉換成安全的純文字摘要。

第一層修正目前這篇文章，第二層則避免其他尚未發現的舊 HTML 再破壞整個列表。

舊網址與 301 轉址

內容正確搬到 WordPress 後，下一個問題是舊網址怎麼辦。

外部網站、搜尋引擎、社群貼文與讀者書籤記住的是舊網址，不會因為文章搬家就自動知道新位置。

我的處理方式是建立「舊網址 → 新網址」對照表，讓每一篇仍有對應內容的舊文章，使用 301 永久轉址前往新文章，而不是把所有舊網址一律送到首頁。

Google 的網站搬遷說明同樣建議準備 URL 對照、使用伺服器端永久轉址、更新內部連結、提交新 Sitemap，並在 Search Console 觀察新舊網址的變化。

網址搬遷時，我特別注意幾件事：

一個舊網址應直接前往最終新網址，避免形成多層轉址鏈。
找不到對應內容時應回傳真正的 404，不要全部導向首頁。
新文章的 Canonical、Sitemap 與站內連結都應使用新網址。
更改文章分類若會改變網址，也要保存並轉址舊網址。
反向代理層與 WordPress 本身不要建立互相衝突的轉址規則。

無名與隨意窩已停止服務，舊平台網址不一定還有條件設定轉址。

這也是我後來更重視自有網址與資料控制權的原因：只要入口仍由別人掌握，平台關閉時，就可能連轉址的機會一起失去。

不是每篇舊文章都需要被索引

二十多年文章全部搬進 WordPress 後，我並沒有認為每一篇都必須出現在 Google。

部分舊文章可能很短、資訊過時、只有生活片段，或只是當年用來記錄某個連結。

我把文章分成三種狀態：

公開並允許索引：內容完整、仍有閱讀或搜尋價值的文章。
公開但 noindex：保留給知道網址的讀者閱讀，但不希望出現在搜尋結果。
隱藏文章：一般讀者看不到，只有登入管理者能查看，而且一律 noindex。

WordPress 內建有整個網站的「阻止搜尋引擎索引」設定，也有公開、密碼保護與私密等文章可見度，但預設沒有完全符合我需求的單篇索引管理介面。

因此，我另外製作「搜尋索引管理」，顯示文章字數、分類、公開狀態及索引狀態，並支援批次設為 noindex、恢復索引或隱藏文章。

noindex 和隱藏是兩件不同的事。

noindex 只要求搜尋引擎不要把頁面放進搜尋結果，並不會阻止一般讀者開啟網址；真正不想公開的內容，仍要使用登入權限或其他存取控制。

此外，頁面必須允許搜尋引擎抓取，Google 才看得到頁面裡的 noindex。若先用 robots.txt 阻擋，搜尋引擎反而可能無法讀到 noindex 指令。相關原理可參考 Google 的 noindex 說明。

設為 noindex 的文章也不應繼續列在提供給搜尋引擎的正式 XML Sitemap 裡。Sitemap 應集中提供希望出現在搜尋結果的正式網址，而不是單純列出所有資料庫中存在的內容。

重新整理分類與標籤

舊平台的分類方式不一定適合現在的內容。搬到 WordPress 後，我重新整理成電玩、桌遊、動漫世界、生活、旅遊與攝影、電腦資訊及三國等主要分類。

我的使用原則是：

分類：代表文章的主要領域，數量有限，並用在網站導覽及文章網址。
標籤：負責把不同分類中的相關主題橫向串起，例如網站架設、SEO 或同一遊戲系列。

WordPress 的分類可以建立上下層關係，標籤則沒有階層；兩者都會產生自己的彙整頁。

這些頁面能不能真正幫助讀者找到更多內容，比建立多少分類或標籤更重要。

若一個標籤長期只有一篇文章、名稱與分類重複，或無法形成有意義的文章集合，就沒有必要為了關鍵字而建立。

分類或標籤 Slug 修改後，也要檢查彙整頁網址及站內連結是否需要轉址。

手機與電腦版面最佳化

資料搬家完成後，網站仍然需要重新適應今天的閱讀裝置。

二十年前的文章通常以固定寬度、表格和桌面瀏覽器為前提；直接放到現代手機上，容易出現內容過窄、表格溢出、圖片超出畫面及空白過多。

我對 WordPress 前台做了幾項調整：

電腦版充分使用畫面寬度，不再維持和手機一樣狹窄的正文。
首頁、搜尋、分類與標籤頁預設使用列表模式。
每列顯示分類、文章標題、發布日期及瀏覽數。
首頁一次顯示適量文章，避免摘要過長。
分類與標籤按鈕依文字寬度排列，空間不足時自動換行。
表格在小螢幕允許橫向捲動或改用較適合手機的排列。
圖片使用響應式尺寸，手機不必下載與桌機相同的大圖。
搜尋欄、熱門文章及管理入口依不同螢幕重新配置。

響應式設計不是把桌機版整體縮小，而是決定每一種螢幕最需要保留哪些資訊。

電腦版可以呈現更多欄位，手機版則必須優先保留標題、分類、日期與閱讀操作。

搬家完成後的檢查清單

如果再次進行大型部落格搬家，我會依照以下順序檢查：

保存舊平台原始備份、圖片與網址清單。
先在測試環境匯入，不直接覆蓋正式網站。
核對文章數量、日期、作者與留言。
列出圖片下載失敗及重複檔名。
抽查圖片多、表格多及歷史最久的文章。
檢查標題階層、段落、目錄、表格與圖片 HTML。
建立舊網址與新網址的一對一對照。
設定 301，並測試是否直接到達最終網址。
確認 WordPress 的公開網址與實際 /blog/ 路徑一致。
確認 Caddy 與 WordPress 不會產生重複轉址或無限轉址。
確認圖片、CSS、JavaScript 等資源在子路徑下正常載入。
重新整理分類、標籤與英文 Slug。
決定哪些文章 index、noindex 或隱藏。
確認 noindex 文章不列入正式 XML Sitemap。
分別測試單篇、首頁、搜尋、分類及標籤頁。
使用手機與電腦實際閱讀，不只看後台預覽。
提交 Sitemap，持續查看 Search Console 的 404、轉址及索引狀態。
備份 WordPress 媒體與自訂檔案。
備份 MariaDB 資料庫。
保存 Docker 部署設定與必要環境資訊。
保存 Caddyfile 與網址路由規則。
正式上線後仍保留搬家前備份及復原方式。

自架網站真正需要備份的是「重建能力」

對完全自架的網站來說，備份不能只理解成「把 WordPress 資料夾複製一份」。

真正需要保存的至少包括：

文章與媒體資料。
MariaDB 資料庫。
WordPress 自訂程式與佈景設定。
Docker 部署設定。
Caddyfile 與網址路由設定。
必要的環境變數與其他重要設定。

真正理想的備份不是「我還留著一些檔案」，而是：

即使原本的容器與服務全部消失，我仍然知道如何把整個網站重新建立起來。

結語：自由也代表責任

從無名、隨意窩、Blogger 到 WordPress，真正困難的從來不是把文章匯入，而是讓二十多年累積的圖片、網址、排版、分類、留言與搜尋紀錄，在新網站裡仍然保持正確。

而這一次搬家和過去最大的不同，是我不只換了一個內容管理系統。

從 Blogger 搬到 Synology NAS 之後，我開始管理的是從Docker、MariaDB、WordPress、Caddy、HTTPS，一直到公開網址的整條網站路徑。

Blogger 的優點是簡單、免費，而且幾乎不需要維護主機；在 Synology NAS 上使用較現成的 WordPress 架設方式，也能用比較低的技術門檻取得自己的網誌。

我現在採用的 Docker＋MariaDB＋Caddy 架構則更進一步：WordPress 只是其中一項服務，資料庫、執行環境與公開網站入口都可以分開管理。

這並不是對所有人都更好的選擇。

如果只想穩定寫文章，這套架構顯然比 Blogger 或一般 WordPress 主機麻煩得多。

但當同一台 NAS 上已經有攝影平台、網站分析及不同 Web App，統一管理網址、HTTPS、Docker 與反向代理，反而讓長期架構更清楚。

對我來說，「自架」真正的價值也不只是節省主機費，而是下一次需要修改分類、調整 SEO、增加搜尋功能、重新設計網站，甚至將 WordPress 換成其他系統時，我仍然保有選擇權。

過去二十多年，我的文章曾經隨著平台一次又一次搬家。

這一次，我真正想改變的不是「下一次要搬去哪個平台」，而是讓未來即使應用程式改變，文章、圖片、資料、網址與整個網站的入口仍然掌握在自己手中。

延伸閱讀：自架網站與攝影平台學習順序

這篇文章已有 37 次瀏覽