WordPress 網站架構教學｜Theme、Template、頁面結構與檔案用途

WordPress 網站不是「一個頁面對應一個 HTML 檔案」。
使用者開啟網址時，WordPress 會依照頁面類型、Theme 與 Template Hierarchy 找出對應模板，
再從資料庫取得內容，最後輸出成瀏覽器看到的 HTML。
這也是為什麼接手 WordPress 網站、修改版型或處理維護問題時，
常常會看到 header.php、single.php、page.php、functions.php、archive.php 這些檔案。

到了 2026 年，理解 WordPress Theme 架構還多了一個原因：資安。
生成式 AI 正在降低程式碼分析與自動掃描的門檻，
已知漏洞從公布到被大量掃描利用之間的時間可能縮短，
Theme、Plugin 與 WordPress Core 的更新速度比過去更需要被當一回事。

現在的 WordPress 已經不只有傳統 PHP Theme。
隨著 Gutenberg 與 Full Site Editing 發展，WordPress 也加入以 HTML Template、Block 與 theme.json 為核心的 Block Theme（區塊主題）。
這篇文章從網站實際開發與維護角度，
說明 WordPress Theme、Template、Template Hierarchy、Child Theme、Classic Theme 與 Block Theme 的差別，
也整理 2026 年常見的 6 套主流 Theme，以及 Theme 相關的資安風險與防禦作法。

WordPress 網站架構是什麼？

一個典型的 WordPress 網站，可以拆成幾個部分理解：

• WordPress Core：負責文章、頁面、會員、權限、資料庫操作、URL 查詢與網站主要執行流程。
• Theme 佈景主題：決定網站前端的版型、顏色、字體、欄位配置及不同頁面的呈現方式。
• Plugin 外掛：增加網站額外功能，例如聯絡表單、購物車、會員系統、SEO、快取或自訂文章類型。
• Database 資料庫：儲存文章、頁面、選單、設定、會員及其他動態資料。
• Uploads 與網站資源：上傳的圖片、PDF、影片，以及 Theme 使用的 CSS、JavaScript 等檔案。

WordPress Theme 不是整個 WordPress 系統，比較接近網站的「呈現層」。
網站需要會員系統時，會員資料與登入功能最好由 WordPress Core 或 Plugin 處理，
不要全部寫在 Theme 裡，未來更換 Theme 時，會員資料與網站核心功能才不會跟著消失。

WordPress Theme 與 Template 有什麼不同？

這兩個名詞很常被混在一起。

Theme 是整套網站外觀

Theme 是一整套網站前端設計與模板的集合。
傳統 Classic Theme 常見檔案包括 style.css、functions.php、index.php、header.php、footer.php、sidebar.php、single.php、page.php、archive.php、category.php、search.php、404.php。
Theme 可以控制網站版型、字體、色彩、Header、Footer、文章頁、分類頁、搜尋結果、404 頁面與 RWD 顯示方式。

Template 是其中一個頁面模板

Template 是 Theme 裡負責「特定頁面如何顯示」的檔案。

簡單理解：Theme 是整間房子的設計，Template 則是不同房間的配置。

WordPress Template Hierarchy 是什麼？

Template Hierarchy 中文通常稱為「模板階層」，是 WordPress 判斷「這個網址應該使用哪一個 Template」的規則。
使用者打開一個網址時，WordPress 會先判斷這是什麼類型的頁面，再按優先順序尋找最符合條件的 Template；
找不到最精確的模板，就一層一層往下尋找，最後通常回到 index.php，可以視為 Classic Theme 最後的備用模板。

單篇文章的模板選擇

開啟單篇文章時，WordPress 尋找符合文章類型的模板，概念上是：

single-{post-type}-{slug}.php
↓
single-{post-type}.php
↓
single.php
↓
singular.php
↓
index.php

singular.php 接在 single.php、page.php 之後，是單篇內容（文章與 Page）共用的 fallback，
找不到更精確的 single.php 時會先落到這裡，再往下才是 index.php。
如果網站建立了名為 book 的 Custom Post Type，可以另外建立 single-book.php，讓所有「書籍」內容使用自己的版型。

一般 Page 頁面

一般 WordPress 頁面的判斷順序比單篇文章更完整，除了依 slug 尋找的 Template，
還包含頁面自訂的 Page Template 與依 Page ID 尋找的模板：

自訂 Page Template
↓
page-{slug}.php
↓
page-{id}.php
↓
page.php
↓
singular.php
↓
index.php

頁面在後台指定了自訂 Page Template 時，優先順序會排在 page-{slug}.php 之前；
例如 page-about.php 可以為 About 頁面提供不同於其他頁面的版型，而 page-{id}.php 則是依頁面 ID（例如 page-42.php）尋找模板，
通常在 slug 可能變動、但頁面 ID 固定的情況下使用。

Category 分類頁

category-{slug}.php
↓
category.php
↓
archive.php
↓
index.php

網站可以針對特定分類另外製作不同版面，其他分類則使用共用模板。

WordPress 官方 Template Hierarchy 參考

完整的判斷順序以 WordPress 官方 Template Hierarchy 文件為準，
實務上常見的做法是先掌握上面這幾種主要頁面類型的優先順序，
再視需求查閱完整流程圖：
WordPress 官方 Template Hierarchy 文件。

WordPress 常見 Template 檔案用途

實際維護 WordPress 網站時，最常碰到下面這些檔案。

front-page.php　主要負責網站首頁。
網站設定了固定首頁時，可以另外製作 front-page.php，
讓首頁擁有獨立版型。

home.php　和 front-page.php 容易搞混，home.php 主要負責「最新文章列表」。
網站設定一個頁面作為首頁、另一個頁面顯示 Blog 時，Blog 列表通常使用 home.php。

single.php　負責一般單篇文章內容，通常包含文章標題、發佈日期、作者、特色圖片、正文、分類、標籤、上一篇／下一篇文章。

page.php　負責 WordPress 的一般 Page，例如關於我們、公司介紹、服務項目、聯絡我們。沒有建立更精確的 Page Template 時，通常就會使用 page.php。

archive.php　負責文章彙整類型頁面，可作為分類、日期、作者等 Archive 找不到專用 Template 時的備用模板。

category.php　負責 Category 分類頁，例如網站設計、SEO、WordPress、電子商務這類分類列表。

tag.php　負責 Tag 標籤文章列表。author.php　負責作者文章彙整頁。search.php　負責 WordPress 站內搜尋結果。

404.php　網址不存在時顯示 404 頁面。企業網站不建議只顯示一句「找不到網頁」，可以加入回首頁、網站搜尋、熱門文章、主要服務、聯絡方式，減少使用者直接離開網站的機會。

index.php　Template Hierarchy 最後的 fallback，WordPress 找不到更合適的 Template 時就會使用它。

header.php、footer.php 與 sidebar.php 是做什麼的？

網站通常有大量重複內容，例如每一頁都有 Header、選單與 Footer。
每個 Template 都各寫一份，程式碼會大量重複，修改網站選單時也會變得麻煩，
所以 Classic Theme 會把共用區塊拆開。
Template 檔案裡通常會在頁面最上方呼叫 get_header()、中間放頁面主要內容、下方依序呼叫 get_sidebar() 與 get_footer()。

get_header() 會載入 header.php；get_sidebar() 載入 sidebar.php；get_footer() 載入 footer.php。Header 或 Footer 只需要修改一次，全站就能同步更新。

WordPress Loop 是什麼？

WordPress Theme 另一個常見觀念叫 The Loop，負責把 WordPress 查詢到的文章資料一筆一筆輸出。
基本寫法會先用 have_posts() 判斷是否還有文章，再用 while 迴圈搭配 the_post() 依序取出每一篇文章，
接著呼叫 the_title()、the_content() 等函式輸出內容。

WordPress 先找到符合目前查詢條件的資料，再透過 Loop 依序輸出文章。
首頁一次取得 10 篇文章，Loop 就會從第 1 篇輸出到第 10 篇。常見輸出函式包括 the_title()、the_content()、the_excerpt()、the_permalink()，分別取得文章標題、正文、摘要與網址。

functions.php 是做什麼的？

functions.php 不是一般頁面的 Template，比較接近 Theme 的功能設定檔，
常見用途包含啟用特色圖片、設定網頁標題、註冊網站選單、
註冊 Sidebar、載入 CSS、載入 JavaScript、加入 Hooks、設定 Theme 支援功能：

add_action('after_setup_theme', function() {

    add_theme_support('title-tag');

    add_theme_support('post-thumbnails');

    register_nav_menus([
        'primary' => '主要選單',
        'footer'  => '頁尾選單'
    ]);

});

再利用 wp_enqueue_scripts 載入 Theme CSS：

add_action('wp_enqueue_scripts', function() {

    wp_enqueue_style(
        'theme-style',
        get_stylesheet_uri()
    );

});

相較於直接把 CSS 與 JavaScript 路徑寫死在 Template 裡，
透過 WordPress 原生 enqueue 機制管理起來會比較容易，也能與 Plugin 和其他資源正常協作。

get_template_part() 有什麼用途？

需要共用的不是只有 Header 與 Footer。
文章卡片可能同時出現在首頁、分類頁、搜尋頁、作者頁，這時可以拆成 template-parts/content.php，再用 get_template_part('template-parts/content') 載入。
Page 有自己的版本時，可以寫成 get_template_part('template-parts/content', 'page')，對應 template-parts/content-page.php。這種做法能減少重複程式碼，讓 Theme 後續比較容易維護。

Classic Theme 與 Block Theme 有什麼不同？

早期及目前大量 WordPress 網站使用的仍然是 Classic Theme，主要透過 PHP Template 組成網站，
例如 header.php、page.php、single.php、footer.php。
隨著 Gutenberg 與 Full Site Editing 發展，WordPress 也開始使用 Block Theme，
Template 主要是 HTML 檔案：

templates/
├── index.html
├── single.html
├── page.html
└── archive.html

Header、Footer 等 Template Part 通常放在：

parts/
├── header.html
└── footer.html

Block Theme 可以在 Template 中用一段對應 wp:template-part 的 Block 標記載入 Header，
並指定 slug 為 header、tagName 為 header，
用同樣做法載入 Footer，不需要像 Classic Theme 一樣使用 get_header()、get_footer()。

theme.json 是什麼？

Block Theme 另一個重要檔案是 theme.json，
可以集中設定網站與區塊的全域樣式及功能，
例如色彩、字型、字體大小、間距、版面寬度、區塊樣式、編輯器設定。
以前很多設定分散寫在 PHP 與 CSS 裡，現在部分設定可以集中在 theme.json。
接手一個 WordPress 網站時，看到 /templates/、/parts/ 與 theme.json，
通常表示它採用 Block Theme 架構，不是傳統 Classic Theme。

近期版本的 WordPress 也持續在 theme.json 這條路線上加東西，
例如允許在單一 Theme 內切換多種配色與版型的 Style Variations，
以及讓使用者直接在後台上傳、管理字型的 Font Library。
這些功能都建立在 theme.json 的架構上，也是 Block Theme 相較 Classic Theme 比較明顯的現代化方向。

WordPress Child Theme 子主題是什麼？

網站使用現成 Theme 時，不建議直接修改母主題程式。
原因很簡單：
今天修改 page.php、functions.php、style.css，幾個月後 Theme 廠商推出更新，
只要更新母主題，自己修改過的程式就可能被覆蓋。
這也是 Child Theme 存在的原因。

Child Theme 基本結構

母主題名稱為 twentytwentyfour 時，可以建立 wp-content/themes/my-child-theme/，再建立 style.css，內容加入：

/*
Theme Name: 我的子主題
Template: twentytwentyfour
*/

Template: twentytwentyfour 就是指定 Parent Theme。
之後要修改 page.php，可以將自己的版本放在 Child Theme 中，WordPress 便會優先載入 Child Theme 的 Template。

直接修改母主題最常見的問題，就是網站更新後客製功能突然消失。
企業網站常見情況包括 Header 客製修改被還原、CSS 被更新覆蓋、Tracking Code 消失、特殊 Page Template 不見、PHP 客製功能失效。
使用 Child Theme 可以把「原始 Theme」與「網站自己的修改」分開，對後續升級、維護及除錯都比較清楚。

WordPress Theme 常見目錄架構

一個 Classic Theme 可以整理成：

mytheme/
├── style.css
├── index.php
├── functions.php
├── header.php
├── footer.php
├── sidebar.php
├── single.php
├── page.php
├── archive.php
├── 404.php
├── front-page.php
├── home.php
│
├── assets/
│   ├── css/
│   ├── js/
│   └── images/
│
└── template-parts/
    └── content.php

不代表每個 Theme 一定要完全一樣，但把共用 Template、靜態資源與功能適當拆開，能讓網站後續比較容易管理。

WordPress Theme 開發常見錯誤

忘記 wp_head()　Classic Theme 的 header.php 通常應該包含 wp_head()，漏掉的話，Plugin、CSS、JavaScript 或其他 WordPress 功能可能無法正常載入。

忘記 wp_footer()　footer.php 在頁面結尾、body 區塊結束前通常也需要呼叫 wp_footer()，很多 Plugin 的 JavaScript 會透過這個 Hook 輸出，
少了它可能出現表單失效、JavaScript 未載入、Tracking Code 異常、Plugin 前端功能不能運作。

自訂 Query 後沒有重設資料　
Template 使用額外的 WordPress Query 時，執行結束後通常要適當重設 Post Data，避免影響後面的主查詢。

WordPress Theme 也需要注意網站安全

Theme 不是只有畫面好不好看，如果 Theme 包含客製程式，也可能造成安全問題。

輸出內容要適當處理　
不同情境可以使用 esc_html()、esc_attr()、esc_url() 處理準備輸出的資料。
需要允許部分 HTML 時，可以使用 wp_kses_post() 這類 WordPress 內建的內容過濾函式，
依允許的標籤與屬性清單過濾，不要直接輸出未經處理的使用者資料。

SQL 查詢不要直接拼接輸入資料　真的需要使用 $wpdb 執行自行撰寫的 Query，
應使用 $wpdb->prepare()，避免把外部輸入直接拼進 SQL。

表單要驗證操作來源　
Theme 如果包含表單或資料修改操作，可以利用 WordPress nonce 機制確認操作來源，
降低 CSRF 類型風險。企業網站若涉及較完整的 客製化程式開發，
這類輸入驗證機制通常需要一併規劃。

WordPress Theme 效能怎麼改善？

Theme 寫得再漂亮，如果每個頁面載入大量 CSS、JavaScript 與圖片，實際使用體驗還是會很差。

正確管理 CSS 與 JavaScript　
使用 wp_enqueue_style()、wp_enqueue_script() 統一管理資源，
不要在每個 Template 裡重複寫入樣式表與 script 標籤。

圖片最佳化　
圖片應依版面需要準備適當尺寸，避免在手機畫面載入超大型桌機圖片，
也可以搭配瀏覽器原生 Lazy Loading，
減少一開始不需要顯示的圖片載入量。

避免 Loop 中大量 Query　
一個 Loop 每輸出一篇文章又執行多次資料庫查詢，文章數量一多，
網站速度就可能明顯下降，這類資料可以重新設計 Query，
或視需求使用 WordPress Cache、Transient 等方式減少重複運算。
網站速度與版型結構同時牽涉 SEO 表現，是後續調整時值得一併檢視的項目。

2026 常見 WordPress Theme 有哪些？6 個知名 Theme 比較

不打算從零開發 WordPress Theme 時，很多企業網站會從成熟的商業 Theme 或 Theme Framework 開始，
再搭配 Child Theme、Block Editor 或 Page Builder 客製化。
市場上的 WordPress Theme 數量非常多，
實際建置企業官網時，比起版型好不好看，
更應該確認 Theme 是否持續更新、是否支援目前版本的 WordPress、PHP 新版本是否相容、是否有正式開發團隊、發現漏洞後修補速度、是否過度依賴大量附加 Plugin、是否容易做 Child Theme、是否支援 Gutenberg，以及是否會造成嚴重的效能負擔。

1. Astra

Astra 是目前 WordPress 生態系中普及度非常高的輕量型 Theme，
WordPress.org 官方目錄顯示啟用安裝數在 1+ million 等級，
本身偏向「底層 Theme」，通常搭配 Gutenberg、Spectra、Elementor、Beaver Builder 等工具製作網站。
特色包括輕量、Starter Templates 數量多、適合企業官網、WooCommerce 支援、可搭配多種 Page Builder、免費版與 Pro 版並存。
官網：wpastra.com。

2. GeneratePress

GeneratePress 的定位偏向效能與開發彈性，
官方將重點放在速度、穩定性、無障礙與 Gutenberg／GenerateBlocks 整合，
比較像提供一個乾淨的網站基礎，再由設計師往上製作，
適合 SEO 網站、內容型網站、Blog、企業網站與重視 Core Web Vitals 的網站。
Theme 不一定要塞滿幾百個功能，也可以只提供乾淨的網站底層。
官網：generatepress.com。

3. Kadence

Kadence 是近年常見的 Gutenberg／Block Editor 路線 Theme，
WordPress.org 官方目錄顯示啟用安裝數已達 500,000+，
除了 Kadence Theme，也有 Kadence Blocks、Starter Templates 等工具，
比較像一個完整的 WordPress 網站製作生態系，
特色包括 Header／Footer Builder、Gutenberg 整合、全域字型與顏色管理、Starter Templates、WooCommerce 支援。
相較 GeneratePress 偏向乾淨與效能，Kadence 在維持輕量的同時，提供比較多視覺化設定功能。
官網：kadencewp.com。

4. Blocksy（Gutenberg／WooCommerce 現代 Theme）

Blocksy 是另一套以效能與 WooCommerce 為主的現代 WordPress Theme，
官方 WordPress Theme Directory 在 2026 年顯示已有 30 萬以上啟用安裝，
特色包括與 Block Editor 完整相容、WooCommerce 支援、
Header／Footer Builder、Starter Sites、即時 Customizer、免費／Pro 版本。
這裡需要澄清一個容易混淆的地方：
Blocksy 不是 WordPress Full Site Editing 定義下的原生 Block Theme，
它仍大量透過 Customizer、Theme Options、Header Builder 等傳統方式運作，
WordPress.org 官方對它的描述是「與 Block Editor 完整相容」，而不是原生 FSE Block Theme。
Theme 已經從單純「換皮膚」，逐漸變成網站 Design System，Blocksy 是這個方向的例子之一。
官網：creativethemes.com/blocksy。

5. Divi／Elegant Themes

Divi 把 Theme 與 Visual Builder 高度整合，使用者可以直接以視覺化方式拖拉網站版面，
對不熟程式碼的人來說優勢明顯：
Visual Builder、大量 Layout、動畫與視覺效果、不寫程式也能製作複雜版面、Theme Builder、全站模板控制。
開發商為 Elegant Themes。
官網：elegantthemes.com。

6. Avada／ThemeFusion

Avada 是 WordPress 商業 Theme 中歷史相當久的一套產品，
官方目前把自己定位成完整的 WordPress Website Builder，
包含 Avada Builder、Header／Footer／Form Builder、WooCommerce Builder、Dynamic Content、預製網站與大量設計元件，
官方表示有超過 100 萬名網站使用者，
長期是 ThemeForest 銷售量非常高的 WordPress Website Builder。
Avada 也是很適合說明「功能越完整，攻擊面通常也越大」的案例：
2026 年 Avada Builder 就曾陸續揭露多項安全漏洞，
包括 SQL Injection、任意檔案讀取、遠端程式碼執行、權限提升與任意檔案刪除，
並不代表 Avada 不能用，而是說明大型 Theme 生態系不能只更新 WordPress Core，
Theme 附帶的 Builder、Plugin 也必須一起維護。
官網：avada.com。

「維護複雜度」為本文依各 Theme 自帶 Builder、附加元件與網站架構所做的實務分類，
並非官方評分或測試數據，僅供規劃時參考。

選擇 Theme 時不建議只看 Demo 首頁。
Demo 通常會把動畫、Banner、Slider、特效全部開滿，看起來很漂亮，
但正式網站還要考量更新、安全、速度、SEO 與後續維護成本，
這也是 企業官網設計階段建議一併評估的部分。

AI 會讓 WordPress Theme 更容易被攻擊嗎？

AI 本身不會讓 WordPress Theme 自動變得不安全，
真正改變的是找漏洞、分析程式碼、產生 PoC、建立掃描器與大量測試的成本正在降低。
過去攻擊者研究一套 Theme，可能需要人工下載 Theme、
閱讀 PHP 原始碼、找 AJAX Action、檢查權限、找 nonce、
找 SQL Query、找 File Upload、寫測試 Payload。
現在 AI 可以協助快速整理哪些函式接受外部輸入、哪些 AJAX Action 沒有權限檢查、
哪些 SQL 可能沒有 prepare、哪些檔案操作沒有驗證、
哪些 shortcode 可能執行危險內容、哪些 REST API 權限不完整。
資安攻防最明顯的改變，未必是突然多了一種全新的漏洞類型，
而是原本需要幾天才能找出的漏洞，可能被縮短成幾小時，
原本需要人工一個網站一個網站測試，也更容易被自動化。

為什麼 Theme 漏洞常常其實發生在 Builder 或附加 Plugin？

現代商業 Theme 很少只有 /wp-content/themes/ 裡的一套 PHP 檔案。
許多 Theme 會另外安裝 Builder、Theme Core Plugin、Demo Importer、Slider、WooCommerce Extension 等附加元件，
即使 Theme 本身已更新，附帶 Plugin 若仍停留在有漏洞的版本，
網站仍可能暴露在攻擊風險中。

WordPress
   │
   ├── Theme
   │
   ├── Builder Plugin
   │
   ├── Theme Core Plugin
   │
   ├── Demo Importer
   │
   └── Add-ons

檢查一套 Theme 是否安全，不能只看 Theme 本身的版本號，附帶的每一層元件都要一併確認。

WordPress 2026 的漏洞主要不在 Core

依 Patchstack State of WordPress Security in 2026 報告，
2025 年統計到 11,334 個 WordPress 生態系新漏洞，其中 91% 出現在 Plugin，9% 出現在 Theme，WordPress Core 本身僅 6 個漏洞。
企業真正需要留意的通常是「Theme、Builder、Theme 附帶 Plugin 有沒有全部一起更新」，
光確認「WordPress 有沒有更新」並不足夠，這兩件事差別很大。

2026 已經發生哪些 Theme 相關漏洞？

Avada Builder：SQL Injection　
2026 年 Avada Builder 曾出現 CVE-2026-4798，
影響舊版本 Avada Builder，問題屬於 SQL Injection，
可以由未登入攻擊者觸發。
SQL Injection 的危險在於攻擊者可能直接操作網站資料庫查詢，
進一步取得使用者資料、Password Hash、網站設定等敏感資料。

Avada Builder：Remote Code Execution　
Avada Builder 在 2026 年另外出現 CVE-2026-6279，CVSS 評分達到 9.8，
漏洞與 shortcode／AJAX 處理相關，可能造成未登入攻擊者執行 PHP 程式。
Remote Code Execution 是 WordPress 網站最危險的問題之一，
一旦成功，攻擊者可能植入 Webshell、新增管理員、修改 PHP、偷取 wp-config.php、
讀取資料庫帳密、放 SEO Spam、建立後門。

Avada Builder：任意檔案刪除與權限提升　
2026 年另外也揭露 Arbitrary File Deletion、Privilege Escalation、PHP Object Injection、Stored XSS。
「Theme 有沒有漏洞」不能只看 /wp-content/themes/，
很多大型 Theme 都有自己的 Builder Plugin、Core Plugin、Extension、Demo Importer，
出問題的可能是 Theme 周邊任何一層。

資料來源：CVE-2026-4798、CVE-2026-6279，Wordfence Threat Intelligence／Patchstack Vulnerability Database。

其他 Theme 也陸續有漏洞紀錄：
Enfold Theme 曾揭露 Reflected XSS，Malmö Theme 曾出現 Local File Inclusion，
WoodMart 在 2026 年也出現 XSS、PHP Object Injection、Sensitive Data Exposure、Arbitrary Shortcode Execution。
Theme 本身只要包含 PHP、AJAX、Shortcode、REST API、File Handling 等程式，
就跟一般 Plugin 一樣可能出現漏洞。

攻擊者如何鎖定未更新的 Theme

攻擊者可以先掃描 /wp-content/themes/theme-name/ 或 Theme CSS、JavaScript、API 回應等資訊，判斷網站使用哪一套 Theme，
接著比對公開 CVE，自動選擇攻擊方式並大量測試。
網站規模小不代表不會被注意，大量攻擊通常根本不知道目標是誰，
Bot 只是掃到 IP 或網址，看到符合漏洞條件就測試。

資安公司公布 Affected Version、Fixed Version 與漏洞類型後，
攻擊者也可以很快比較新版與舊版程式差異、找出被修改的部分、反推漏洞、
產生測試 Payload、大量掃描未更新網站，「漏洞公布後一兩個月再更新」這種維護習慣，風險會愈來愈高。
真正危險的情況是 Theme 有漏洞、開發商卻已經停止更新，
這比知名 Theme 曾經爆出漏洞本身更值得留意。
7 年沒更新的 Theme、已下架 Theme、已
倒閉開發商的 Theme、破解 Theme、Nulled Theme、來源不明的 Theme，
就算找到漏洞，也可能永遠沒有 Patch。

WordPress Theme 要怎麼防禦？

防禦重點在於做分層防禦，同時處理更新、權限、監控與備份，
單一資安 Plugin 沒辦法涵蓋所有風險。

第一層：WordPress、Theme、Plugin 全部持續更新　
至少要同步管理 WordPress Core、Theme、Child Theme、Theme Builder、Theme Core Plugin、其他 Plugin 與 PHP 版本，特別是 Theme 附帶的 Builder。

第二層：刪除不用的 Theme　
建議只保留目前正在使用的 Theme，以及一套官方預設 Theme 作為除錯備用，其他不用的 Theme 不要只是停用，直接刪除。停用（Inactive）不代表程式碼不存在，Theme 檔案仍放在伺服器上，部分漏洞仍可能被直接利用。

第三層：不要使用來路不明的 Nulled Theme　
「Avada 免費下載」「Divi 破解版」這類 Theme 最大的風險藏在授權以外的地方：根本不知道 ZIP 裡被加了什麼，可能包含 Webshell、後門管理員、外部 JavaScript、SEO Spam、隱藏 Redirect、惡意 Cron、加密 PHP。省下幾十美元 Theme 費用，最後清除 Malware 花上幾萬元，這筆帳不好算。

第四層：使用 Child Theme　
使用第三方 Theme 時不要直接修改 Parent Theme，否則容易陷入「不敢更新，因為一更新網站就壞掉」，最後 Theme 一兩年沒有更新。Child Theme 的價值不只是方便設計修改，也直接影響網站能不能正常做安全更新。

第五層：限制 WordPress 後台權限　
網站不需要大量會員時，不要給每個人 Administrator，能用 Editor、Author、Contributor 就不要給 Administrator。很多 Theme／Builder 漏洞需要 Subscriber 以上、Contributor 以上或 Author 以上的權限才能利用，權限越低，攻擊成功後能做的事情也越少。也可以在 wp-config.php 加入 define('DISALLOW_FILE_EDIT', true);，關閉後台的佈景主題／外掛編輯器，避免攻擊者取得管理員權限後直接在後台修改 PHP 檔案植入後門。

第六層：加入 WAF　
可以在網站前面增加 Cloudflare WAF、主機 WAF、WordPress WAF，在漏洞尚未完全更新前，多提供一層保護，針對 SQL Injection、XSS、Path Traversal、惡意 Bot、異常 POST Request 做阻擋，但 WAF 是第二道門，不是「Theme 永遠不用更新」的理由。

第七層：追蹤漏洞資料庫　
不應等到客戶反映網站好像被駭了才去查漏洞，可以定期檢查 Patchstack Vulnerability Database 與 Wordfence Vulnerability Database。網站用了 Avada、Divi、Astra、Elementor、WooCommerce、Slider Revolution 等元件，就應該掌握目前是否有公開漏洞及安全版本。

第八層：做好備份，但備份不能只有一份　
建議至少有 Production、Daily Backup、Off-site Backup，並保留多個歷史版本。
網站如果已經被放後門 30 天，今天的 Backup 可能也已經有後門。

如果 Theme 漏洞已經被入侵，只更新夠嗎？

不一定，這是企業網站很容易誤解的一點。
漏洞已經被攻擊者利用時，流程通常是漏洞出現、取得權限、植入 Webshell、建立後門。
此時把 Theme 更新到最新版，只代表原來的入口被關起來，不代表已經進來的人被趕出去。
還要檢查 wp-content/uploads、Theme PHP、Plugin PHP、WordPress Core、wp-config.php、.htaccess、管理員帳號、wp_users、wp_usermeta、Cron、SSH Key、Server Process，
必要時甚至要從可信任的入侵前備份重建網站。
網站若涉及較大規模的 主機代管與維運，
這類事後清查與重建流程通常需要有專責團隊處理。

WordPress 網站架構 FAQ

WordPress Theme 最基本需要哪些檔案？

Classic Theme 的基本架構會包含主題資訊、主要 Template 與相關功能檔案，
例如 style.css、index.php、functions.php，實際正式網站通常還會加入 header.php、footer.php、single.php、page.php 等 Template。

single.php 和 page.php 有什麼不同？

single.php 主要處理單篇 Post，
page.php 主要處理 WordPress Page，
兩者都可能輸出標題與正文，但在 Template Hierarchy 裡屬於不同的內容類型。

functions.php 是 Template 嗎？

functions.php 主要用於設定 Theme 功能、
註冊 Hook、載入 CSS／JavaScript、註冊選單與其他 Theme 功能，
不是用來直接顯示某一種頁面的主要 Template。

index.php 為什麼重要？

Classic Theme 的 Template Hierarchy 中，
找不到其他更精確的 Template 時，
WordPress 最後可以回到 index.php，可以視為 Theme 的通用 fallback Template。

Classic Theme 和 Block Theme 哪一種比較好？

沒有哪一種一定比較好。
Classic Theme 使用 PHP Template，開發模式成熟，很多既有網站與客製系統仍然採用這種架構；
Block Theme 更著重 Block、HTML Template、theme.json 與 Site Editor，
讓更多版型與全站樣式可以直接從 WordPress 後台控制。
實際選擇要看網站功能、既有系統、維護方式與客製程度。

修改 WordPress Theme 一定要用 Child Theme 嗎？

只是自己完全控制的客製 Theme，不一定需要；
使用第三方 Theme、未來還需要更新母主題的情況，
通常建議透過 Child Theme 修改，避免更新後客製程式被覆蓋。

企業網站更新後版型跑掉，應該從哪裡開始檢查？

可以先確認問題發生在 Parent Theme、Child Theme 還是 Plugin。
只有文章頁出問題時，先從 single.php 方向檢查；只有分類頁錯誤時，檢查 category.php、archive.php；
Footer 的 JavaScript 沒有載入，則可能是 Theme 缺少 wp_footer()。
了解 Template Hierarchy 後，排查問題通常會比把每個 PHP 檔案全部打開找一遍有效率。

WordPress 是 MVC Framework 嗎？

嚴格來說不是像 Laravel 這類典型 MVC Framework。WordPress 的 Core、Database、Theme 與 Template 確實存在資料、流程與顯示層的分工，
但核心架構不是按照標準 MVC 模式建立，
開發 WordPress 網站時，理解 Hook、Theme、Plugin、Query、Template Hierarchy、WordPress API，
通常比硬把 WordPress 套成 MVC 概念更實用。

WordPress Theme 有漏洞還能繼續用嗎？

可以，
重點是漏洞是否已修補、目前使用版本是否安全，以及開發商是否仍持續維護。
曾經出現漏洞並不代表 Theme 永遠不安全，
真正高風險的情況是 Theme 已停止維護、或者已經有可利用的漏洞卻無法更新。

WordPress Theme 多久應該更新一次？

不建議用固定「每月一次」的思維處理。
一般功能更新可以排程測試後再上線，安全更新則應該依漏洞嚴重度盡快處理；
如果涉及未登入 RCE、SQL Injection、任意檔案上傳等高風險漏洞，
不適合等到下個月例行維護才更新。

停用的 WordPress Theme 還有風險嗎？

有。
停用（Inactive）只代表 WordPress 目前不會載入這套 Theme 的 Template，程式檔案仍然放在伺服器上。
如果 Theme 本身包含可被直接存取的 PHP 檔案、AJAX Action 或 REST API 端點，
部分漏洞不需要 Theme 處於啟用狀態也能被觸發。
建議只保留正在使用的 Theme 與一套官方預設 Theme 作為除錯備用，
其他不用的 Theme 直接刪除，而不是只停用。

WordPress Theme 對一般使用者來說最直觀的是網站設計，但對實際開發與維護來說，
Theme 還牽涉 Template Hierarchy、Plugin 整合、SEO 結構、JavaScript 與 CSS、RWD、網站效能、網站安全、
WordPress 更新、PHP 相容性與後續客製維護。
WordPress 的邏輯是先判斷使用者正在要求什麼內容，再透過 Template Hierarchy 找到最符合的模板，
載入網站共用部件與資料，最後輸出成使用者看到的網頁。
攻擊者的自動化能力正在提升，網站可以延遲更新的安全時間正在縮短，
企業真正要留意的重點，是這個 WordPress 網站有沒有人持續更新、
監控漏洞、備份，以及在漏洞公布後足夠快地處理。

益盛科技 專案經理 Ring