想像你要住進一個新家，有兩種選擇。一種是自己畫設計圖、找工班照圖施工，牆要開在哪、插座留幾個，你說了算，但每個細節都得自己盯著組裝，這比較接近 WordPress 的區塊主題（block theme）。另一種是直接搬進一間格局已經固定好的精裝套房，家具、動線、收納全部配好，拎包入住，想調整格局卻要另外找人動工，這比較像傳統佈景主題（classic theme）。
兩者的差別不只在體感，而是實際的技術基礎不一樣。區塊主題用 HTML 範本檔搭配 theme.json 組成版面，傳統主題則靠 PHP 範本檔加上 Customizer、外掛拼起來。搞不清楚自己的網站是哪一種、也不了解兩套系統各自的能耐，換版型、找工程師改版面的時候很容易白繞一圈，多花不必要的預算。
區塊主題是什麼？以 theme.json 與 HTML 範本取代 PHP 樣板
WordPress 官方文件把主題分成兩種類型，其中一種是隨全站編輯（Full Site Editing，簡稱 FSE）推出的區塊主題，官方文件直接把它稱為「打造 WordPress 主題的現代做法」，並定調它就是 WordPress 專案的未來方向。跟過去最大的不同，是版面的核心組成從 PHP 範本檔換成了 HTML 範本檔搭配 theme.json，範本本身用區塊標記寫成，開發者跟使用者都能在「網站編輯器」裡直接編輯，連色彩、字體、間距這些全域樣式，也能透過「樣式」介面調整主題預先定義在 theme.json 裡的設定。
想知道自己的網站是哪一種，最快的辦法是打開後台看「外觀」底下有什麼。出現「編輯器」，就是區塊主題；出現「自訂（Customizer）」，就是傳統主題。這個差異背後其實有一整套範本層級，WordPress 官方 Learn 平台把它由小到大拆成五層：最小的區塊（block）是段落、圖片、按鈕這類最小單位；把幾個區塊組合成可重複套用的設計，就是樣板（pattern）；頁首、頁尾這種會在多個版面之間共用的區塊組合，叫範本部件（template part）；決定單篇文章、頁面、彙整頁這類內容型態版面的，是範本（template）；把以上所有層級加上全域樣式打包起來，就是一個完整的主題（theme）。
過去傳統主題把色彩、字體大小這類設定寫死在 functions.php 裡的 add_theme_support()，改一個設定得回頭找程式碼；區塊主題把這些設定統一收進 theme.json 一個檔案管理，後台的「樣式」面板讀的就是這份設定，改動範圍與呈現方式因此更集中，也更容易透過介面而非程式碼調整。
傳統佈景主題依然仰賴 PHP 樣板與外掛建構版面
相對地，傳統主題用的是 PHP 範本系統，像 header.php、footer.php、single.php 這些檔案各自負責版面的一個區塊，樣式設定則分散在 style.css 與「外觀→自訂（Customizer）」裡，小工具（widget）另外管理側邊欄與頁尾的內容區塊。WordPress 官方文件說得很直接，這套系統至今仍受 WordPress 完整支援，之所以還被廣泛使用，是因為它建立在 2005 年 WordPress 1.5 推出以來就存在的主題架構之上。
傳統主題不是被淘汰的舊技術，而是一條路線不同的選擇。它日常操作靠三種介面：Customizer 用來調整整體外觀設定、小工具管理可拖放的內容區塊、視覺化頁面建置外掛則進一步接管單一頁面的排版。要找出哪個範本檔負責顯示什麼內容，WordPress 依循一套由細到粗的範本階層規則。同一篇文章，系統會先找有沒有專屬範本，找不到才退回 single.php，再找不到就用 index.php 兜底，這套邏輯全靠 PHP 條件判斷完成。
官方文件也承認，傳統主題要建立的標準門檻低得多，但相對地，開發者得具備最基本的 PHP、HTML、CSS 知識才動得了它。這不代表傳統主題落伍。目前 WordPress.org 主題目錄裡，傳統主題的數量至今仍占多數，官方也沒有公布任何停止支援的時程，短期內不會被強制淘汰。
改版預算、客製邏輯、維護人力與外掛相容決定選型方向
選區塊主題還是傳統主題，不是喜好問題，而是要看四個實際會牽動成本與工作方式的條件：改一次版要花多少人力和時間、能不能做到複雜的條件式版面邏輯、樣式與版面設定要集中管理還是分散在好幾個地方、現有外掛與頁面建置工具還能不能正常運作。
這四點分別對應維運端最常遇到的四種情境：預算怎麼抓、邏輯做不做得到、樣式歸誰管、外掛還通不通。答案在區塊主題與傳統主題身上並不對稱，得逐項拆開才看得清楚。
版面改版的頻率與預算門檻
區塊主題把版面編輯整合進網站編輯器（Site Editor），改頁首、改頁尾、調整樣板都用點選拖曳完成。WordPress 官方教學舉了一個具體例子：從 6.2 版開始，只要點幾下就能做出黏性頁首（sticky header），換成傳統主題想做同樣的效果，得靠程式碼才能實現。官方教學的說法是，區塊主題讓你不用寫程式就能編輯整個網站的每個部分，理論上不必每次小改版都找工程師介入。
傳統主題的版面異動則要看主題與外掛的品質而定。有的改動只需要調 CSS，有的得動到 PHP 範本檔，或者進到頁面建置外掛自己的樣板系統裡調整，變動成本因主題做得好不好而有很大差異。這裡要誠實說，區塊主題帶來的成本降低是「潛在的」，實際效果仍取決於主題本身的品質，以及團隊熟不熟悉網站編輯器這套新介面，換了架構卻沒人會用，一樣得找人來學。
複雜條件式版面邏輯的可行性
傳統主題靠 PHP 的條件判斷式與掛勾（hook），可以做到「依文章分類顯示不同版面」「依使用者角色隱藏特定區塊」「依裝置類型切換排版」這類條件邏輯，工程師只要在範本檔裡寫一段判斷式就能實現。這類需求在企業站、會員站很常見，也是傳統主題長年被拿來做客製化開發的原因之一。
區塊主題的網站編輯器目前沒有原生的條件式顯示介面。想要「依角色顯示不同區塊」這類邏輯，還是得靠自訂區塊或外掛擴充，不是打開編輯器點幾下就能設定。這是區塊主題現階段公認的限制，不能因為它在版面編輯上更直覺，就以為它已經取代了 PHP 能做到的所有邏輯判斷，需要複雜條件邏輯的網站，這一點必須先想清楚。
維護責任的歸屬與樣式管理方式
區塊主題把色彩、字體、間距這些全域樣式集中在 theme.json 與後台「樣式」面板一處管理，改一次設定就套用到全站每一個範本。傳統主題的樣式設定則常常分散在好幾個地方：Customizer 裡的主題專屬選項、主題自己的設定面板、style.css 裡的自訂 CSS，甚至頁面建置外掛還有它自己的一套全域樣式系統，要改動樣式，得先想清楚這個設定當初是在哪裡設定的。
這種分散管理也反映在換主題這件事上。WordPress 官方教學提醒，換掉傳統主題時，CSS 客製化與主題專屬功能會一併消失，套用在舊主題上的自訂 CSS 也會跟著不見，因為那些樣式設定高度依附著個別主題與外掛，難以整批遷移到新環境。這一點跟區塊主題把全域設定與樣式定義在 theme.json、透過樣式介面調整的做法形成對照，重點在於集中管理與分散管理帶來的維護方式差異，不是誰的網站跑得比較快。
外掛與頁面建置工具的相容現況
這是四個條件裡最貼近日常操作的一個。WooCommerce 官方文件明白指出，這裡的許多細節只適用於網站使用區塊主題的情況，要用它的區塊化商店範本編輯功能（結帳頁、購物車、商品頁都用區塊組成），前提是網站得是區塊主題。如果是傳統 PHP 主題，WooCommerce 官方的說法是區塊支援有限，可以在一般內容頁使用 WooCommerce 區塊，但結帳、購物車這類核心範本仍是 PHP 組成，頁首、頁尾與商品範本也沒有全站編輯功能。也就是說，傳統主題上想用區塊工具排版，範圍僅限在一般內容頁，電商流程的核心頁面碰不到。
Elementor 官方文件則說明它的 Theme Builder 功能透過「Theme Locations API」讓主題開放特定區域（頁首、頁尾、側邊欄）給 Elementor 接管，主題開發者可以選擇支援全部核心位置、只支援部分，甚至自訂專屬位置，這套掛勾機制原本就是為傳統 PHP 主題設計的。區塊主題的頁首頁尾則改由 WordPress 核心的網站編輯器直接管理，屬於範本部件的一部分，跟 Elementor 的接管機制是兩套不同的系統。兩者能夠並存，但這代表換架構前要多想一層，不是單純的「相容」或「不相容」兩個選項，而是原本熟悉的外掛操作方式，換了架構之後可能要重新確認一次適用範圍。
全新架站與重視載入速度的網站適合以較輕的區塊主題起步
要不要把「較快」當成選區塊主題的理由，得先弄清楚衡量標準是什麼。Google 官方的 web.dev 把使用者體驗拆成三個核心網頁體驗指標（Core Web Vitals）：LCP（最大內容繪製）評估頁面感知載入速度，門檻是 2500 毫秒以內算「良好」；INP（互動到下一個繪製）評估操作回應速度，門檻是 200 毫秒以下；CLS（累計版面配置位移）評估畫面穩不穩定，門檻是 0.1 以下。這三項都是拿一個網頁所有真實瀏覽量的第 75 百分位數來判斷達不達標，不是實驗室裡的單次測速。
WordPress 核心效能團隊拿這套標準交叉分析過真實流量。他們用 HTTP Archive 與 Chrome 使用者體驗報告（CrUX）的資料，比對超過 50 萬個 WordPress 首頁網址，發現在某次改版之前，區塊主題網站的 LCP 通過率就已經是 42.8%，同期傳統主題網站是 31.3%，兩者相差超過十個百分點。這個數字比較的是改版前既有的落差，反映區塊主題網站在架構上原本就傾向於更容易通過 LCP 門檻，不是那次改版帶來的效果。
不過這不代表換成區塊主題就保證變快，「較輕」指的是起點比較輕，不是保證值。實際載入速度仍然要看裝了多少外掛、範本堆疊了幾層區塊與樣板，一個塞滿外掛的區塊主題網站，照樣可能比一個精簡的傳統主題網站慢。這個優勢比較適合幾種對象：全新架站、還沒有舊外掛包袱的網站，內容導向的部落格或行銷網站，以及本來就把 Core Web Vitals 排進優先事項的網站，起點輕，後面維持速度會相對省力。
既有 PHP 客製與外掛相依的網站，換架構的風險大於效益
跟前一節「較輕起步」相對的，是另一種常見情境。網站已經跑了好幾年，累積了大量客製 PHP 邏輯，像依分類顯示不同版面、自訂文章型態配專屬範本檔，這類客製化多半靠 PHP 條件判斷寫成，換成區塊主題等於要把這些邏輯重新想過一次要怎麼實現。網站如果重度依賴 Elementor、Divi 這類頁面建置外掛，而且已經用它排完大量頁面內容，換架構代表這些頁面很可能得重新排版，不是換個主題就自動接上。
WordPress 官方教學對換主題這件事講得很直接，因為設計差異，內容顯示的方式可能會改變，有些 WordPress 主題附帶專屬功能，像自訂頁面範本、簡碼或小工具，換到新主題可能會失去這些功能。這句話點出一個常被忽略的風險，不是內容不見，而是支撐內容呈現的那套機制可能整套消失，得重新設定或重建。
官方教學也把「逐一檢查現有外掛相容性」列為換主題之前的必要步驟，原文的意思是不是所有外掛都能在區塊主題底下運作，這點一定要事先檢查測試，並具體點出容易出問題的類型，在區塊主題底下運作不良的外掛，通常是那些仰賴小工具、又沒有對應簡碼版本的外掛。這隱含一個結論，換架構不是每個網站都該做的事。比較適合維持傳統主題的，是這三種對象：網站已經有大量客製 PHP 邏輯、重度依賴頁面建置外掛且已經投入大量頁面內容、團隊已經在這套傳統主題生態裡投入多年、外掛與工作流程都已經穩定運作。對這幾類網站來說，換架構的風險常常大於能拿到的效益。
混合主題保留 PHP 主體並局部導入區塊功能
前面兩節像是「全換」跟「先不換」兩個選項，但 WordPress 官方文件其實還承認一種介於中間的過渡型態，也就是混合主題（hybrid theme）。官方 Theme Handbook 的說法是，還有一種傳統主題的子類型叫混合主題，混合主題就是採用了部分現代區塊相關功能（例如全域設定與樣式，或範本部件）的傳統主題，這是社群普遍認可的說法，但不是一個『正式』的主題類型，說到底，混合主題本質上仍然是傳統主題。
換句話說，混合主題本體還是傳統的 PHP 主題架構，但額外註冊了 theme.json，取得部分區塊功能，例如後台的全域樣式面板，或是局部套用的範本部件，不必把整個網站都搬進網站編輯器裡管理。因為本質仍是傳統主題，混合主題保留了 Customizer 與小工具這兩套原有的編輯介面，外掛相容性因此比整套換成區塊主題更有保障，不用擔心某個仰賴小工具的舊外掛突然失去對應的區塊版本。
這條路比較適合還沒準備好全面換架構、卻想先拿到區塊編輯器部分優點的網站，想先讓色彩字體這類全域樣式集中管理，或想在某幾個範本部件試著用區塊排版，但暫時沒有資源把全站範本重建一遍。混合主題讓這種漸進式導入變得可行，不必一次到位。
換架構前，先盤點外掛相容與備份的具體做法
不管最後決定選哪一種，只要真的要換架構，WordPress 官方教學給的操作順序值得直接照著走：
- 完整備份：先把資料庫、媒體檔案與主題檔案整套備份下來，這是動工前的第一步，也是唯一能讓你隨時退回原狀的保險。
- 搬到測試或暫存環境安裝新主題：不要直接在正式站上安裝、啟用新主題，先在一個跟正式站隔開的環境裡動工，確保出問題不會直接影響訪客看到的畫面。
- 盤點外掛清單，逐一測試相容性：官方教學提醒，在開始使用編輯器工作之前，先檢查現有外掛的相容性是個好主意，尤其要留意仰賴小工具或簡碼、卻沒有對應區塊版本的外掛，這類外掛最容易在新架構底下失效。
- 確認樣式與範本都設定好、測試過主要頁面，才切換正式站：頁首頁尾、單篇頁、彙整頁這些主要範本都排版完成、實際瀏覽測試過沒有問題之後，才把正式站切換過去，切換之後也要持續觀察一段時間，留意有沒有遺漏的頁面或功能。
這套順序把官方教學原本分散的建議收斂成一條可以直接照做的路徑，重點在於先在正式站之外把問題解決掉，而不是切換之後才發現外掛壞了、版面跑掉。
回到一開始蓋房子和精裝套房的比喻。沒有哪一種選擇天生比較好，差別只在於你想把時間花在哪一段。想要親手決定每一面牆怎麼開、日後改版不必每次都找工程師，區塊主題把這份掌控權放在你手上，代價是前期要花更多時間摸熟這套系統；想要拎包入住、不必碰程式碼就能上線，傳統主題把大部分決定權留給主題與外掛，代價是哪天想動到結構層級的改動，還是得回頭找懂 PHP 的人。真正該先問的不是哪一種主題比較新，而是自己的網站現在站在哪一邊，是還沒累積包袱的新站，還是已經跑了好幾年、外掛跟客製邏輯都盤根錯節的舊站，答案通常已經藏在這個問題裡了。