多數人選佈景主題，問的第一句話是「這個多少錢」，好像現成主題便宜、自製主題貴，選擇只是一道價格題。但真正決定這個選擇的，其實不是預算，而是 WordPress 官方自己畫的一條線，規定主題可以做什麼、不可以做什麼。這條線寫在官方佈景主題目錄的審核規範裡，大多數人挑主題的時候卻從沒讀過。
現成主題「功能不夠」常被當成廠商偷懶，自製主題「什麼都能做」則被當成理所當然的優勢。實際上，WordPress.org 的官方審核規範明文把主題的職責限定在設計與呈現這一層，自訂文章類型、聯絡表單、分析追蹤這些功能被劃進外掛的領域，規則上就不准寫進主題本身。這條規則不是隨便訂的，它決定了現成主題天生的天花板在哪裡，也決定了自製主題換來的自由要付出什麼代價。
佈景主題目錄的審核機制決定了現成主題的起點
現成主題快、便宜、裝上去就能用，這幾個印象背後有一套具體的技術原因，不是廠商隨口喊的行銷詞。WordPress.org 官方佈景主題目錄有一套審核規範，每一支想進目錄的免費主題都要先過這一關，規範管的範圍遠比多數人想像得細。
安全性是第一關，所有不可信的資料在寫進資料庫前要先驗證與過濾，輸出到畫面前也要逃逸處理，避免注入攻擊；程式碼不能有 PHP 或 JavaScript 的錯誤、警告或提示訊息。無障礙是第二關，主題要提供跳過連結，讓螢幕報讀器使用者一進頁面就能碰到這個連結，鍵盤焦點移過去時也要看得見；所有控制項與連結都要能用鍵盤操作到，行動裝置與觸控螢幕的版本也要一致。使用者資料與隱私是第三關，任何追蹤與資料蒐集預設都要關閉，採選擇加入，而且要在 readme.txt 裡揭露蒐集方式，最好附上明確的隱私政策；沒有取得使用者同意前，不可以引用外部遠端資源，這是為了符合 GDPR 的規定。
這套審核不是走過場。違規紀錄累積到一定數量，那份主題就會被判定沒過，得修正後重新送審才能上架。但這裡有個容易被忽略的界線，這套審核只管 WordPress.org 官方目錄裡的免費主題，像 ThemeForest 這類商業市集販售的付費主題不必然經過同一套審核流程，不能一概而論。
官方規範把主題限定在設計與呈現層
前面那些檢查項目背後，其實在守同一條界線，主題只能管設計與呈現，功能性的東西歸外掛管。官方審核規範明文列出主題不能包含的功能：自訂文章類型、自訂區塊、自訂角色、自訂使用者聯絡方式、自訂 MIME 類型、Shortcode，以及任何跟設計呈現無關的功能。反過來，分析追蹤、SEO 選項、聯絡表單、非設計用途的中繼方塊、資源快取、社群按讚追蹤分享按鈕，這些全部被歸進外掛的領域，規則上就不該寫進主題。
這不是廠商偷懶留一手，是整個生態系刻意的分工設計。主題保持輕量，才能讓功能獨立於外觀之外被替換，你可以換一支主題，聯絡表單外掛照樣運作；也可以換一支表單外掛，主題外觀完全不受影響。這條界線劃得越清楚，現成主題的可替換性就越高，這正是現成主題生態能長成現在規模的技術基礎。
這一型主題適合架構標準、預算有限的網站
把這條技術限制轉譯成你自己能對照的情境：型錄站、部落格、需求跟同類型網站大同小異的中小企業官網，這幾種站的呈現需求本來就落在主題該管的範圍內，額外功能靠外掛補齊即可，不需要動到主題本身的程式碼。如果你的網站資訊架構標準、預算與時間有限，也沒有工程維運的人力能長期照看，現成主題加上幾支對應的外掛，通常已經是效益最高的組合。
但反過來說，一旦需求跨進主題不該管的那個範疇，自訂文章類型、特殊角色權限、非典型的資料流程，現成主題再怎麼挑、再怎麼比較評價，都補不齊這塊缺口，因為規則本來就不允許主題自己扛。現成主題的天花板不夠高時，自製主題換來的自由，實際上長什麼樣子。
自製主題換來完全貼合，代價是效能與安全都要自己扛
自製主題不受官方目錄那套只能管設計呈現的限制，資訊架構、自訂文章類型、特殊流程都能整合進同一套程式碼裡，這是完全貼合需求真正的技術基礎，不是設計師的主觀偏好或行銷話術。但同時要誠實講一件事，換來的效能與安全優勢不是自動發生的，而是主導權換責任，沒有官方審核當底線，程式碼寫得好不好、安全性顧得周不周全，全部壓在開發團隊自己身上。
HTTP Archive 在《2025 Web Almanac》的 CMS 篇章裡有一句觀察，剛好把「自製一定比較快」這種過度簡化的說法拉回現實。報告指出，即使在同一套 CMS 裡，網站表現從高度優化到嚴重臃腫都有，這說明效能是一種持續的實踐，不是內建的保證。換句話說，自製主題如果沒有紀律地開發，一樣會臃腫；現成主題如果設定得當、外掛數量控制住，也不必然比自製主題慢。自製這個標籤本身，從來不是效能的保證。
沒有審核限制換來功能整合的自由
回頭對照前一節那份主題不可內建的功能清單，自訂文章類型、自訂區塊、自訂角色、自訂 MIME 類型，自製主題正是因為不受這條規則約束，才能把這些功能直接寫進同一套程式碼裡，不必透過外掛拼接。這是自製主題完全貼合需求的真正技術依據。
這一點在頁面範本上看得特別清楚。WordPress 依查詢字串逐層比對範本檔案，找不到符合的檔名就往階層下一層找，最後才落到最通用的 index.php。自製主題可以針對任何一種頁面類型都寫一支專屬範本，特殊列表頁、特殊單篇頁，想多細就能做多細；現成主題的範本階層則多半只覆蓋到主題作者當初設計好的通用情境，超出那個情境，你能動的空間就有限。
沒有官方審核作為底線的自我把關責任
這是前一段的另一面。效能與安全的主導權換到手上了，代價就是失去官方目錄那套審核當底線，驗證輸入、逃逸輸出、無障礙的跳過連結與鍵盤導覽、使用者資料蒐集要預設關閉並公開揭露，這幾項是官方目錄免費主題被迫要做到的事，自製主題沒有人強制檢查，做不做得到全看開發團隊自己的紀律。
長期經營的網站更要留意這件事的持續性。自製主題沒有社群幫忙回報漏洞，也沒有官方推播更新提醒該補哪個安全性缺口，出了問題要自己抓、自己修、自己盯著上線後的表現有沒有慢慢變差。這不是說自製主題天生不安全，而是安全與效能在自製主題身上，從一次性的建置決策，變成一件需要有人長期持續投入的事。
子主題與區塊主題，是現成與自製之間的緩衝地帶
現成整套用、自製整套寫，不是唯二的兩個選項。WordPress 官方本身就提供兩條中間路。子主題（child theme）讓你在不碰原始碼的前提下客製一套現成主題，日後主題本體更新也不會洗掉你的修改；區塊主題（block theme，WP 5.9 起）則讓不少過去要動 PHP 才能改的版面配置，直接搬進網站編輯器用畫面操作完成。
當你的需求超出現成主題的預設值，卻還沒到需要整套從零寫的程度，這條中間路往往才是效益最高的選擇。它不是妥協，是官方自己設計出來、專門對付這種不上不下需求落點的機制。
子主題在不動原始碼的前提下疊加客製
子主題的宣告靠 style.css 檔頭的 Template 欄位，這個欄位要跟父主題的資料夾名稱完全相符，WordPress 才認得這是誰的子主題。至於程式邏輯，子主題的 functions.php 不會覆蓋父主題的 functions.php，兩者都會被載入，而且子主題會先於父主題載入。這代表你可以安全地擴充功能，不需要動到父主題原始碼，父主題更新時你寫的東西也不會被覆蓋掉。
官方文件把子主題的好處歸納得很直接：讓客製可攜、可複製，把客製跟父主題程式碼分開存放，父主題更新時不會遺失客製，只需要寫真正要改的那部分程式碼，省下開發時間。但官方自己也承認這條路有邊界，文件裡明白提醒，在子主題裡做大量客製最終可能變成管理上的頭痛，對這類更大型的專案，通常更好的做法是 fork 原主題、建一套完整的父主題。這句話直接界定了子主題這條中間路能撐到哪裡，小到中量級的客製很適合，客製量一路膨脹上去，就該考慮升級成真正的自製主題。
區塊主題把版面調整搬進畫面直接編輯
區塊主題是 WordPress 5.9 之後出現的新型主題，用區塊構成網站的每個部位，導覽選單、頁首、內容、頁尾都是區塊組成。啟用區塊主題後，你能用網站編輯器編輯全站各部位、在不同範本間切換；用樣式自訂顏色、字體排印與版面；用範本編輯、建立、管理頁面所用的範本；用範本組件組織頁首頁尾這類區塊群組。這幾項工具加起來，讓不少改版型的需求不必寫程式，也不必換掉整支主題。
對照傳統主題（classic theme）的做法，更能看出兩者的差異在哪裡。傳統主題靠 PHP 範本檔、functions.php 搭配小工具（widget）、獨立的選單設定、自訂工具（Customizer）來組成畫面，不支援網站編輯器；同樣的版面調整，傳統主題要嘛動程式碼，要嘛卡在 Customizer 有限的選項裡。區塊主題把這件事整個搬到畫面上直接操作，是另一條不必寫程式碼就能客製現成主題外觀的路。
四個變數決定這個選擇的落點
把前面兩節各適合誰、為什麼收斂成你自己能拿去對照的判準，不是問現成或自製哪個好，是看四個變數各自落在哪裡，需求特殊性、預算、長期維護能力、效能要求。這四個變數不是各自評分加總，而是任何一個變數過線，答案就會被那一個變數決定，比方預算完全不夠，就算需求再特殊，多半也只能先用現成主題加子主題撐著，等預算到位再往下走。判斷順序建議先看需求特殊性，決定客製有沒有必要；再看預算與維護能力，決定客製做不做得起；最後看效能門檻，決定要精緻到什麼程度。
資訊架構的特殊程度決定客製的必要性
呼應前面提到的那條規則，如果網站需要的是自訂文章類型、特殊角色權限、非典型的內容關聯，這些現成主題規則上就不該內建的東西，現成主題再怎麼挑都補不齊。這時候客製，自製主題，或至少客製一支專用外掛，是必要的，不是排場或奢侈的選項。
反過來，如果你的內容結構就是文章、頁面、幾個常見的自訂欄位，這條變數根本沒過線，不必為了感覺比較高級硬選自製。多數型錄站、部落格、服務介紹頁其實都落在這個範圍裡，現成主題原本就足夠應付。
預算要算的不只是建置費用
預算這個變數，最容易被算窄成取得一套主題或請人開發一套主題這一筆一次性的費用。完整的預算要把後續維護也算進去，現成主題有官方或作者持續推播更新，你要負擔的多半是續訂或授權費用；自製主題沒有這層社群或官方把關，安全性更新與相容性維護要另外編列人力或費用，而且是持續發生、不會做完就結束的支出。
這是計算自製主題總成本時最容易被漏算的一塊。建置階段看起來省下的開發費，如果沒有把後續維護算進同一張表裡，很容易在上線幾年後才發現原本估的預算根本不夠用。
長期需要有人接手維護與安全更新
這其實在講同一件事的不同面向。子主題文件那句大量客製最終會變成管理頭痛，提醒的是不管走哪條路，長期都需要有人持續盯著。現成主題需要有人定期更新主題與外掛版本，子主題與區塊主題需要有人在官方主題大改版時檢查客製有沒有跟著壞掉，自製主題則需要有人持續盯安全性與相容性。
沒有這個人、也沒有編這筆預算，不管選現成還是自製，風險都會隨時間累積，差別只在於哪一種風險先浮現。現成主題不更新，風險多半先出在安全性與外掛相容性；自製主題沒人維護，風險則會先累積在效能慢慢變差、卻沒人發現的那個階段。
流量規模與效能門檻決定優先順序
把效能這個變數落到可操作的層次，不是自製一定比較快，而是流量規模與 Core Web Vitals 門檻夠高的時候，把工程資源投入效能優化才划算；流量普通的網站，把現成主題設定好、外掛數量控制住，往往已經足夠。
HTTP Archive《2025 Web Almanac》的數據可以當參考。2025 年只有 54%的網站達到良好的 LCP（最大內容繪製）分數，像 WordPress 這類可高度擴充的 CMS，一年內的進步幅度普遍小於 Wix 這類垂直整合平台，Wix 光是 CWV 良好比例就從 55%成長到 74%，漲幅遠大於 WordPress。報告解釋這是因為改進很難平均分散到允許更多客製與實作差異的生態系裡。另外，約 60%的 WordPress 網站會搭配頁面建置外掛使用，其中 Elementor 採用率最高，其後是 WPBakery 與 Divi，這類工具往往產生更複雜的 DOM 結構與更龐大的 CSS、JavaScript 檔案，拉高大規模運作時的效能風險，較舊的頁面建置工具更容易造成長期的維護與綁定問題。
換賽道的成本，是最常被忽略的第五個變數
多數人比較現成與自製時，只算現在要花多少，卻沒算以後想換賽道要付多少代價。子主題把客製與父主題程式碼分開存放，換主題或父主題更新時風險相對低；但如果現成主題長期搭配頁面建置外掛使用，版面資料往往跟該外掛的格式深度綁定，日後想換掉那個外掛或換主題，重建版面的成本會遠高於當初省下的建置費用。把時間軸拉長之後，才會浮現這筆容易被忽略的成本。
子主題讓換主題的沉沒成本降到最低
子主題這條路徑在以後要換這件事上比較划算，原因很具體。客製寫在子主題裡，跟父主題程式碼分開存放，換掉父主題或升級版本時，子主題那部分的客製不會跟著遺失，也不需要整個重寫，你保留的是自己寫的那部分邏輯，丟掉的只是父主題本身。
這正是官方文件強調客製可攜、可複製，把客製與父主題程式碼分開的實際效益，不只是開發階段省時間，換賽道的那天也省成本。
深度綁定頁面建置外掛的主題脫身成本更高
對照組是另一種常見情境。如果現成主題的客製高度依賴某個頁面建置外掛，版面資料與樣式都存在那支外掛自己的格式裡，日後想換掉那個外掛或換主題，等於要重建整個版面。這正是 HTTP Archive 觀察到較舊的頁面建置工具造成長期維護與綁定問題的實際樣貌，約 60%的 WordPress 網站在用頁面建置外掛，換賽道的成本不會是少數人才會遇到的邊緣情況。
這條變數該在一開始選擇時就納入考量，而不是等到真的要換的那天才發現代價。當初評估現成主題方案時，多問一句這套版面資料離得開這支外掛嗎，往往比事後才想辦法補救更划算。
選現成主題還是自製主題，答案從來不是哪個比較好，而是把手上這幾個變數攤開來看。需求特殊到官方規則管不到的地方，或是預算與維運能力連現成主題的更新都追不上，都會直接把答案往某一邊推。子主題與區塊主題留了一條中間路，讓大多數不上不下的需求不必被迫二選一。真正容易被忽略的，是換賽道那天才會浮現的成本，當初省下的建置費用，可能在換外掛或換主題的那天，加倍討回去。把這幾個變數想清楚，比先問這個多少錢更快找到屬於自己的答案。