在 Site Editor 裡把「頁面」範本的版型整個改乾淨，按下儲存，切回前台重新整理——這一頁的畫面卻和動手之前一模一樣。這種落差不是個案，是 WordPress 區塊主題最容易讓人找不到方向的地方之一。多數人心裡對「範本」的想像是「整個網站共用同一份」，但 WordPress 實際運作的邏輯完全不是這樣，每個網址被打開的當下都會重新跑一次比對，去挑出這個網址現在該套用哪一份，這套挑選規則就叫做範本階層（template hierarchy）。
不懂這套順序，改對地方或改錯地方純粹是運氣問題，你可能一直在改一份根本贏不了的範本檔案，卻始終抓不到問題出在哪裡。問題往往就出在 Site Editor 按下儲存那一刻，實際發生的動作跟多數人以為的完全不同。
編輯範本卻沒讓前台跟著變的真正原因
先說清楚一個常被忽略的事實，WordPress 從來不是整個網站共用一份範本，而是把每一個網址當成獨立案件，各自跑一次比對挑出該用哪一份。這也是為什麼同一個區塊主題底下，單篇文章、頁面、分類列表看起來可以長得完全不一樣，卻不需要開發者手動指定，階層規則本身就會依網址類型自動分流。
在 Site Editor 裡編輯範本、按下儲存，實際發生的動作跟多數人以為的完全不同。WordPress 並不會去覆寫或刪除主題資料夾裡原本的 .html 檔案，而是把你剛剛改出來的這個分岔版本，另外寫進資料庫裡一個叫做 wp_template 的文章類型。主題原始檔案完全不會被動到，改動只是在資料庫裡多存了一份使用者編輯過的版本。WordPress 官方的 Block Editor Handbook 對這套同步機制說明得很清楚，主題裡尚未被編輯過的範本，在資料庫的狀態預設是「自動草稿（auto-draft）」，一旦被使用者存檔編輯過就轉成「已發布（publish）」，這麼一來，WordPress 之後渲染頁面時只需要查資料庫，不必再回頭讀主題資料夾裡的原始檔案。這正是「直接改主題檔案卻感覺沒生效」最常見的根源，你改的是主題資料夾裡那份原始檔案，但前台實際套用的早就是資料庫裡另一份分岔版本。
這套機制不是某個過渡階段的暫時行為，而是目前仍在運作的規則。WordPress 目前最新版本是 7.1（2026 年 8 月正式發布），範本階層的判斷邏輯自從區塊主題導入以來就沒有結構性改變，後續每一版都沿用同一套順序。換句話說，不論你手上這個站是新裝的還是已經跑了好幾年，接下來要拆解的判斷順序都一體適用。
範本階層的唯一規則是具體命名優先於籠統命名
範本階層的判斷邏輯只有一條，WordPress 不是照時間先後，也不是照人工設定的優先度去挑範本，而是先把這個網址理論上可能對應到的所有檔名，由最具體排到最籠統，列成一串候選清單，再逐一去檢查每個檔名是否真的存在，第一個真的存在的就拿來用。
用一個具體例子把這套抽象規則落地，會清楚很多。假設站上有一個叫做 product 的自訂文章類型，其中一件商品的網址代稱（slug）是 blue-shirt。這種情況下，WordPress 會先找有沒有 single-product-blue-shirt.html 這份專屬檔案，若沒有，退一層找整個 product 類型共用的 single-product.html，兩份都不存在，才會再退回所有單篇文章共用的 single.html。判斷依據永遠只看檔案或資料庫紀錄存不存在，不看其他條件，不管這份範本寫得好不好、多久沒更新，只要它存在，階層就會停在那一格，不會繼續往下找。
index.html 是區塊主題唯一必備的範本檔案，也是所有階層最終的回退點。就算前面提到的每一層都沒做，只要主題有這一份 index.html，WordPress 永遠找得到東西可以顯示，不會出現「沒有範本可用」的狀況。
資料庫裡的自訂版本比主題資料夾的檔案更早被採用
前面提到的「檔案存不存在」只是判斷邏輯的一半，另一半是「去哪裡找這份檔案」。WordPress 官方文件列出範本查找的三層優先順序，第一層是資料庫 wp_template 裡使用者建立或編輯過的版本，第二層是子主題（若有啟用）的 /templates 資料夾，第三層才輪到主題本身的 /templates 資料夾。
這個順序帶出一個實務上很容易忽略的後果，就算直接改了主題的原始 .html 檔案，只要資料庫裡已經有一份對應同一個 slug 的自訂版本，前台顯示的永遠是資料庫那一份。改主題檔案完全不會反映到前台，除非先把資料庫裡那份自訂紀錄清掉。這也呼應前一節提到的同步機制，渲染時只需要查資料庫裡的文章類型紀錄，就能決定該顯示哪一份，不必再回頭直接讀主題資料夾。
單篇文章與頁面的範本命名都是從最精確退到最籠統
把「單篇」與「頁面」這兩條命名序列攤開來看，能直接對照到自己現在遇到的情境，找到眼前這一頁實際套用了哪一份。單篇文章（single）完整的命名序列是 {custom-template}.html 到 single-{post_type}-{post_name}.html 到 single-{post_type}.html 到 single.html 到 singular.html，最後才是 index.html。頁面（page）的序列略有不同，是 {custom-template}.html 到 page-{post_name}.html 到 page-{post_id}.html 到 page.html 到 singular.html，最後才退到 index.html。官方文件舉的範例是網址代稱為 about-me、編號為 200 的一個頁面，完整序列就是 {custom-template}.html、page-about-me.html、page-200.html、page.html、singular.html、index.html 依序比對。
附件頁（attachment）算是這條線的一個特例。它會先比對 {mime_type}-{sub_type}.html，接著是 {sub_type}.html，再來是 {mime_type}.html，最後才是 attachment.html，比對不到才會退回單篇文章的命名序列。這個特例現在比較少被踩到，官方文件也註明，自 WordPress 6.4 起，附件頁在新安裝的網站上預設就已經關閉，但如果手上的站是從舊版本升級沿用，或裝了某些會重新開啟附件頁的外掛，還是可能實際遇到這條規則。
自訂範本一律排在最前面，不論指定給單篇還是整個文章類型
{custom-template}.html 這個位置，在所有單篇類型的命名序列裡都排在最頂端。這代表在文章或頁面編輯畫面右側的「範本」面板裡，只要選擇或新建一個自訂範本並指定給某一篇內容，等於直接把那一篇鎖進特定範本，其他規則全部比不過這個直接指定。
這正是「明明改了共用的 single.html 或 page.html，某一篇卻完全沒變」最常見的第一個原因，那一篇多半在編輯畫面裡被個別指定了一份自訂範本。learn.wordpress.org 的教學就逐步示範過這個實際操作，在 Site Editor 建立一份自訂範本後，回到頁面編輯畫面的「範本」欄位指定給某個特定頁面，前台就會套用該頁專屬的頭尾與版面，其他同類型頁面完全不受影響，維持原本共用的那一份。
文章類型的命名從專屬逐層退到通用
single-{post_type}-{post_name}.html 這組命名，可以拆成兩層在決定要不要有專屬範本。第一層看的是這個特定網址代稱有沒有自己的專屬檔案；沒有的話，退一層看整個文章類型有沒有共用的 single-{post_type}.html；連這個也沒有，才會再退到全站所有單篇內容共用的 single.html 或 singular.html。
實務上，像商品這種自訂文章類型，經營者常常會需要一份專屬於它的範本，而不是跟一般文章共用同一套版面。商品頁通常要放價格、庫存、加入購物車按鈕，這些欄位一般文章根本用不到，這時候就該往 single-product.html 這一層去做，而不是硬把所有邏輯塞進全站共用的 single.html。
頁面靠網址名稱或編號指定範本，跟單篇文章的規則不同
page 系列用的是 page-{post_name}.html 與 page-{post_id}.html 這兩個變數，跟 single 系列不太一樣的地方在於，它沒有多出一層「文章類型」的中間層。原因很直觀，頁面本身就是單一的文章類型，不像自訂文章類型還要再往下分好幾種，自然也就不需要那道中間的判斷。
page.html、singular.html 與 index.html 仍然是這條線最終的回退點，跟單篇文章共用的回退邏輯是同一個道理，只是命名用的變數不同。改對範本卻沒生效時，先確認自己改的是哪一層變數，往往就能少走一大段冤枉路。
分類與標籤的範本命名比自訂分類法多一層特例
歸檔頁（archive）這個大家族裡，分類（category）與標籤（tag）是 WordPress 內建的兩個分類法，各自有專屬的命名序列，並不會走一般自訂分類法（taxonomy）那一套規則。分類的完整序列是 category-{slug}.html 到 category-{id}.html 到 category.html，退到 archive.html，最後才是 index.html；官方範例是網址代稱為 news、編號為 123 的分類。標籤的序列邏輯一樣，只是換成 tag-{slug}.html 到 tag-{id}.html 到 tag.html，官方範例是網址代稱 flowers、編號 456。
使用者自己建立的分類法，例如產品分類，才是套用 taxonomy-{taxonomy_slug}-{term_slug}.html 到 taxonomy-{taxonomy_slug}.html 到 taxonomy.html 這一組命名，退回去一樣是先到 archive.html，最後才是 index.html。作者、日期、搜尋、404 這幾種查詢類型也各自有自己的層序，作者是 author-{user_nicename}.html 到 author-{user_id}.html 到 author.html；日期是 date.html；搜尋是 search.html；404 則是 404.html。自訂文章類型如果有自己的封存頁，命名是 archive-{post_type}.html。這幾種查詢類型除了 404 與搜尋比較單純，其餘全部一路退回 archive.html，再退到 index.html，這正是這一整群類型共同的回退終點。
分類與標籤各自有專屬的命名優先權
一個常見的誤區是以為只要做一份 taxonomy.html，就能同時管到內建的分類頁與標籤頁。實際上分類頁早就被更前面的 category.html 接住了，taxonomy.html 根本輪不到出場。WordPress 官方文件對這件事講得很直接，內建的 category 與 post_tag 這兩個分類法，並不會套用自訂分類法慣用的詞彙範本（term template），要調整分類頁或標籤頁的樣式，得直接改 category.html 或 tag.html 這兩份專屬命名的範本，不是在 taxonomy.html 裡找答案。
這個分野之所以容易讓人誤判，是因為「分類法」聽起來像一個籠統的大分類，直覺會以為理所當然涵蓋分類跟標籤。實際上內建的這兩種是特例，跟使用者自建的分類法完全是兩條不同的命名軌道，要分開處理，別想著用一份 taxonomy.html 一次管到底。
作者與日期歸檔頁，最後都退回同一份 archive 範本
作者、日期這類依「後設資料」分組的歸檔頁，跟依分類法分組的歸檔頁，終點其實是同一個，都是 archive.html 退到 index.html。如果沒有特別做一份 author.html 或 date.html，網站上所有作者頁、每個月的歸檔頁看起來都會長得一模一樣，因為它們共用同一份回退範本。
這不是設計上的疏漏，而是機制本身如此運作。想讓作者頁跟月份歸檔頁各自有專屬版面，主動去做 author.html 或 date.html 就好，這跟前面談單篇文章、頁面時「主動建立更具體命名」的邏輯是同一套道理，只是套用在歸檔頁這個家族上。
前台首頁背後其實藏著兩份不同的範本
這一節是整套規則裡最容易讓人誤判的地方。front-page.html 跟 home.html 是兩份完全不同的範本，切換的依據是後台「設定 > 閱讀」裡「網站首頁顯示」這項設定。很多人改了 home.html，卻發現首頁的畫面完全沒變，原因就在於首頁實際套用的其實是 front-page.html，根本不是 home.html。
WordPress 官方文件把這件事講得很明確，front-page.html 一律優先於「網站首頁顯示」這項設定，不論設定值是什麼，只有階層裡排在它後面的範本才會受這項設定影響。換句話說，front-page.html 只要存在，永遠是首頁第一個被檢查、也最常直接被套用的檔案。
最新文章當首頁與指定靜態頁當首頁，套用的範本不一樣
「網站首頁顯示」這項設定有兩種選項，對應到完全不一樣的範本套用結果。設定成「最新文章」時，首頁走的是 front-page.html，若這份檔案不存在，才會退到 Home 這條序列，也就是 home.html 退到 index.html。
設定成「靜態頁面」而且另外指定了一個「文章頁」時，情況就不一樣了。Home 這條序列這時候套用在被指定的那個「文章頁」上，而不是首頁本身；首頁本身仍然走 front-page.html，若不存在就退回頁面（Page）那條序列。這代表在這兩種情境下，Home 範本實際管到的網址其實不一樣，一種情況它管的是首頁本身，另一種情況它管的是被另外指定為文章頁的那一頁，兩者不能混為一談。
名稱看起來像首頁的範本其實管的是文章列表頁
home.html 這個命名，其實是從 WordPress 早期只有部落格功能的年代延續下來的。當時網站首頁能顯示的只有文章清單，「home」這個詞被保留下來，一路沿用來指稱文章列表這條序列，並不是字面上「首頁」的意思。
這段命名歷史帶出一個實務上常踩的雷，如果網站首頁設定成「靜態頁面」，home.html 這份範本根本不會用在首頁上，而是用在被指定為「文章頁」的那個頁面。改錯範本、看錯畫面，是這整套機制裡最常見的誤解，很多人直覺以為名字裡有「home」就等於管首頁，實際上完全不是這麼一回事。
確認頁面實際套用的範本其實不必用猜的
前面拆解的命名序列雖然完整，但真的遇到問題時，不必對照文件自己重算一次階層。WordPress 後台本身就有兩個地方能直接看到目前套用哪一份範本，不需要靠猜的。
文章編輯畫面的範本面板，直接顯示目前套用的版本
打開任何一篇文章或頁面的編輯畫面，側邊欄設定裡有一個「範本」欄位，直接顯示目前指定的範本名稱。點進去可以編輯這份範本本身，也可以另外建立或指定一份自訂範本給這一篇內容。
這是確認這一篇現在實際套用哪一份範本最快的方法，不必回頭去翻檔名對照規則，也不用擔心自己漏算了某一層。learn.wordpress.org 的教學逐步示範過這個流程，從打開頁面、到側邊欄設定、到範本欄位、再到編輯或指定自訂範本，也示範了針對不同分類各自指定專屬範本的實際案例。
範本列表上的清除自訂選項，代表資料庫版本已經蓋過主題檔案
到 Site Editor 的範本管理列表（外觀 > 編輯器 > 範本），逐一檢查每一份範本旁邊有沒有出現「清除自訂」這個選項。出現了，就代表這份範本已經不是主題原始檔案在運作，而是資料庫裡編輯過的版本在運作。
這正是「主題檔案怎麼改，前台都沒變」的關鍵檢查點。learn.wordpress.org 官方教學也明講，只要對區塊主題內建的範本做過修改，之後在「外觀 > 編輯器 > 範本」查看所有範本時，就會看到清除自訂這個選項。對照前面談過的三層優先順序，就能直接理解為什麼會這樣，資料庫裡那份編輯過的版本，優先權本來就排在主題檔案前面。
找到問題之後就能讓改動真正套用到對的頁面
找到問題出在哪一種狀況，接下來要處理的事情就很明確，多半是把攔在前面的更具體版本排除掉，或是把資料庫裡蓋過主題檔案的自訂版本清乾淨；如果目的不是排除問題，而是想主動做出專屬設計，一樣有對應的做法。
先排查有沒有更精確的範本正在攔截這個頁面
對照前面幾節列出的完整命名序列，從最具體的檔名往下找，看看有沒有一個更具體的版本已經先一步被選中，可能是某一篇被個別指定了自訂範本，也可能是某個 page-{slug} 或 single-{post_type}-{post_name} 這類專屬命名的檔案本來就存在。先把那個更具體的版本改掉或移除，籠統版本才會真的有機會出場。
這一步不需要另外的工具，純粹是把前面談過的命名規則拿來對照眼前這一頁，一格一格往下比對，找出是哪一層先被攔住。
清除自訂，讓主題檔案重新生效
如果排查後確定是資料庫自訂版本蓋過主題檔案的情形，操作路徑是回到 Site Editor 的範本管理列表，找到出現「清除自訂」的那一項，點開三點選單清除。清除之後，這份範本會重新讀取主題資料夾裡的原始檔案，之前直接改主題檔案卻沒生效的狀況就會解除。
官方教學示範的是逐一範本操作，並沒有提到一次整批清除所有自訂版本的做法，需要一份一份確認清楚，才不會不小心把其他還在正常使用的自訂版本一起清掉。
想讓某一類內容套用專屬設計，主動建立更精確命名的範本
如果目的不是修復問題，而是想讓某個分類、某篇文章或某個文章類型有自己專屬的樣子，正確做法不是去改籠統版本讓所有頁面一起變，而是主動新增一份命名更具體、或指定專屬自訂範本的版本，只對到那個特定範圍。
learn.wordpress.org 官方教學示範過一個實際案例，分別為書評與影評兩種內容各建立一份自訂範本，各自搭配專屬的橫幅與依分類篩選的文章列表區塊，再指定給對應頁面，其餘頁面完全不受影響，維持原本共用的那一份。這樣的做法既不影響其他頁面，也完全符合範本階層具體優先的設計，是這套機制被設計出來就是要拿來用的方式，不是需要迴避的變數。
外掛也能插進範本階層，跟主題檔案互搶優先權
前面談的都是主題資料夾跟資料庫自訂版本這兩層，但範本階層其實還有一個容易被忽略的第三個變數，外掛本身也能透過 WordPress 核心提供的 API 註冊自己的區塊範本。
自 WordPress 6.7 起，開發者可以用 register_block_template() 這個核心函式，直接從外掛裡註冊一份區塊範本，不必再侷限於只有主題才能建立自訂範本。這對會自帶版面配置的外掛特別實用，例如管理自訂文章類型、自訂分類法或虛擬頁面的外掛，都可以透過這個 API 提供一份預設版面，而不必依賴主題事先準備好對應的範本。
規則其實很單純，只要主題的 /templates 資料夾裡有同名檔案，主題永遠優先，外掛註冊的版本只有在主題完全沒提供對應範本時才會被使用。WordPress 官方部落格對這件事講得很直接，主題作者如果想覆蓋外掛預設的範本內容，只要把同名的範本加進主題自己的 /templates 資料夾，用自己想要的區塊內容取代即可。如果手上的網站裝了會自帶版面配置的外掛，例如電商或表單類外掛，遇到「改了主題範本卻沒生效」的狀況，這會是除了前面兩種以外，第三個該排查的方向。
範本階層看起來規則很多，但拆開來看只有一件事，具體命名永遠贏過籠統命名，資料庫裡編輯過的版本永遠贏過主題檔案，而外掛註冊的版本則排在主題之後。搞懂這套順序之後，範本階層就不只是拿來排除故障，也可以主動拿來用，需要專屬設計時就往更具體的命名去做，不需要每次都動到全站共用的那一份，改壞或改亂其他頁面的風險自然也跟著降低。