WordPress 使用者權限指南：精準管控角色後台存取

「反正就我自己一個人管網站，帳號開 Administrator 最方便，何必管什麼角色權限？」問題在於，內容人員若同時擁有安裝外掛、修改設定與管理帳號的能力，一旦誤操作或帳號遭入侵，影響範圍就會從單篇內容擴大到整個網站。

WordPress 權限管理的核心，是把後台存取範圍切到完成工作所需的最小程度。單站安裝常見五個預設角色：Administrator、Editor、Author、Contributor 與 Subscriber；啟用 Multisite 後另有可管理整個網路的 Super Admin。每個角色都對應一組 capability（能力）。需要客製時，可用 User Role Editor 等工具複製角色後再微調，避免直接修改預設角色，也不要為了省事把所有人都設為 Administrator。

把 WordPress 後台想成一棟辦公大樓：角色、能力、樓層的對應

很多新手把「角色」當成僅是一個標籤，貼上去就好。這個理解差了一層。換個比喻：你的 WordPress 後台是一棟辦公大樓，角色是一串鑰匙圈，capability 是每一支單獨的鑰匙。Administrator 拿的是「總鑰匙」，可以開每一扇門；Editor 拿的是「內容樓層」的鑰匙；Contributor 拿到的僅是「草稿室」的鑰匙，連按下發佈按鈕的那扇門都打不開。

這個比喻之所以重要，是因為它解釋了 WordPress 權限系統的底層邏輯：真正決定「能做什麼」的，從來不是角色這個名字，而是它背後綁的那一堆 capability。角色僅是一個方便打包的標籤。例如檢查能否編輯別人的文章時，系統會檢查 edit_others_posts 等相關能力；其他動作需要的能力不同。一旦你看懂這一層，後面所有自訂角色的操作都會變直覺。

這也回答了一個常見疑問：為什麼兩個網站的 Editor 看起來能力不一樣？因為外掛可能新增 capability。WooCommerce 安裝後會加入訂單與商品相關能力，SEO 或快取外掛也可能增加各自的設定權限。所以同一個角色名稱，在不同網站確實可能有差異，必須針對實際啟用的外掛稽核。

WordPress 內建六個角色，到底各自能走進哪些房間

WordPress 官方文件的 Roles and Capabilities 章節列出六個預設角色，其中 Super Admin 僅適用於 Multisite。這張表整理各角色的主要差異；實際能力仍可能被外掛或自訂程式調整。

Administrator 和 Super Admin 不是同一件事。Super Admin 僅在 Multisite 模式下存在，一般單站的最高預設角色是 Administrator。Editor 不僅可以編輯別人的文章，也能管理頁面、分類與留言；Author 主要管理自己的文章。Contributor 可撰寫並送交審核，但預設沒有上傳檔案與發佈能力。

如果你才剛起步，還在摸索整個後台介面，建議先回頭把WordPress 後台完全上手看一遍，把後台十個核心區塊的相對位置搞清楚，再回來對照角色權限會更有感覺。

Capability 才是權限系統真正的最小齒輪

WordPress 的權限架構可理解為 User → Role → Capability：使用者被指定角色，角色再包含一組能力。能力名稱通常由動作與對象組成，例如 edit_posts、publish_posts、manage_options、install_plugins 與 edit_theme_options；實際可用項目會隨版本、Multisite 與外掛而變（見 WordPress.org 的 Roles and Capabilities 文件）。

權限問題要問的是「這個人需要哪些 capability」。例如校稿員若要修改其他作者已發佈的文章，除了 edit_posts、upload_files 與 edit_published_posts，通常還需要 edit_others_posts；但不必因此取得發佈、刪除、安裝外掛或修改全站設定的能力。實際組合要用測試帳號驗證。

另一個關鍵概念是 meta capability 與 primitive capability 的差別。edit_post 會依文章作者、狀態與使用者權限，映射到 edit_posts、edit_others_posts、edit_published_posts 等 primitive capability。自訂角色若出現「勾了 edit_posts 卻仍不能改某篇文章」，就要檢查這組映射所需的能力。

角色資料到底存在哪裡：看懂 options table 裡的 user_roles 選項

WordPress 把角色與 capability 對應關係存進網站的 options table。預設資料表前綴下，選項名稱通常是 wp_user_roles；資料表前綴或 Multisite 網站 ID 不同時，名稱也會跟著變。其值是序列化的 PHP 陣列，每個角色底下包含顯示名稱與 capabilities。

講白一點，這代表兩件事。第一，角色定義是存在資料庫裡的，並非寫成靜態檔案。這也是為什麼你搬家、換主機之後，若資料庫跟著搬，角色設定就會原封不動帶過去，不必重新設定。第二，任何對角色的修改，本質上都是在改這個序列化字串。User Role Editor 這類外掛做的，就是幫你安全地讀寫這個欄位；而「手動進 phpMyAdmin 改 user_roles」之所以危險，就是因為序列化字串一個字元錯位（例如長度標記沒跟著改），整個陣列就會解析失敗，所有角色一起失效。

WordPress 透過角色、個別使用者能力與 capability filters 判斷授權，程式通常應用 current_user_can() 檢查實際動作。角色選項也可能來自快取，不能把每次判斷都理解為重新查詢資料庫。後台隱藏按鈕不等於伺服器端已拒絕該操作，兩者都要驗證。

整站備份若涵蓋資料庫，角色設定也會被備份；僅備份 wp-content 則無法還原角色、使用者與內容資料。完整備份要同時涵蓋檔案與資料庫，並實際驗證還原流程。

永遠不要直接改 Administrator：自訂角色的三條安全路線

直接修改 Administrator 會讓最高權限角色偏離 WordPress 與外掛預期，後續除錯也很難分辨哪些能力曾被手動調整。外掛啟用、更新或初始化時也可能新增或調整自己的 capability，因此較安全的做法是保留必要的 Administrator，另建立受限角色。

正確的自訂角色有三條路線，按推薦程度排序：

1. 複製既有角色再微調（Clone and Modify）：這是 User Role Editor 推薦的做法。挑一個最接近你需求的角色（通常是 Editor 或 Author），複製成新角色，例如 editor_lite 或 author_no_delete，然後僅增減少數 capability。好處是繼承了「合理的基線」，你僅需處理差異。
2. 從零打造一個全新角色：從空白開始，一個一個 capability 勾選。適用於極度受限的特殊角色（例如「僅能回覆留言的客服」），但工程量大、容易漏勾，建議搭配下一段的測試流程。
3. 用小型自訂外掛或 MU-plugin 註冊：適合需要版本控制與跨主題保留設定的開發團隊。不要把長期角色定義綁在佈景主題的 functions.php，否則切換主題後程式便不再執行。

這三條路線背後是同一個原則：預設角色當成「唯讀範本」，所有客製都開新角色來做。自訂角色仍可能被外掛或程式碼改動；更新後應保留權限稽核與測試，不能把複製角色當成永遠不變的保證。

User Role Editor 外掛完整操作流程

接下來是實作。User Role Editor 是 WordPress 官方外掛目錄上的一款免費工具，專門用來視覺化地增刪 capability、複製角色。可依目前版本與網站需求評估其功能及相容性。如果你還不熟悉怎麼裝外掛，可以先看WordPress 外掛安裝教學把基礎流程走一遍。

安裝完成後，完整的操作流程是這樣的：

1. 進入設定位置：後台左側選單「使用者 → User Role Editor」。主畫面會顯示目前選中的角色，以及它所有 capability 的勾選狀態。
2. 選擇起點角色：右上角的下拉選單挑一個你要複製的來源角色，例如 Editor。
3. 按下 Add Role 建立副本：輸入新角色 ID（英文小寫加底線，例如 content_editor）和顯示名稱（例如「內容編輯」），勾選「make copy of」並選 Editor。
4. 逐項增減 capability：這是核心步驟。畫面把能力分組（文章、頁面、外掛、佈景主題、使用者管理），用關鍵字搜尋最快。取消勾選代表拿掉能力，勾選代表加上。改完按 Update Role。
5. 把新角色指派給使用者：到「使用者 → 所有使用者」，在「角色」下拉選單切換成新角色。WordPress 核心介面通常僅指派一個角色；若外掛支援多角色，最終能力通常會合併，因此更要注意權限擴張。
6. 馬上驗證：別急著收工，這一步大多數人會跳過，但它是整個流程最重要的收尾。後面我會講怎麼用 User Switching 外掛實際「變身」成新角色來測試。

刪除自訂角色前，要先把使用者移到其他角色。不要直接在資料庫刪除角色；帳號可能因此失去後台權限，但不代表必然出現白畫面。操作前先做資料庫備份並準備還原方式。

角色管理外掛怎麼挑

這篇以 User Role Editor 為例。挑選工具時，不必追逐外掛數量或功能清單，先確認是否能複製角色、搜尋 capability、管理自訂文章類型，並且仍有維護與相容性紀錄。如果你在規劃整站外掛，可以先從 WordPress 外掛清單 看起。

選擇權限工具時，先核對要控制的是後台編輯、選單、單篇內容還是前台閱讀。User Role Editor、Members 等工具各有免費與付費功能；自訂內容類型是否需要升級，應查所用版本，不必一概換工具。避免多套工具同時修改相同權限，新增後以測試帳號驗證。

User Role Editor 還有付費的 Pro 版，主要多了「匯入匯出角色設定」「限制後台選單存取」「依角色限制內容編輯」這類功能。對單一站點的中小網站，免費版通常已經夠用；但如果你管理的是多站台網路、或經常需要把同一套角色設定同步到好幾個客戶網站，Pro 版的匯出匯入能省下大量重複工作。要不要升級，看你「重複設定」的頻率決定，功能清單的長度反而是次要考量。

五種真實團隊劇本的權限藍圖

講了一堆概念，真正落地還是要對應場景。我整理五種最常見的團隊形態，每一種提供一組需要按實際工作驗證的配置起點。這些是依不同規模網站常見需求歸納出的配置版本。

這張表最重要的不是細節，而是背後的判斷邏輯：先列出需要完成的工作，再排除不必要或高風險的 capability。從風險反推，比從功能正推更容易設計出安全的角色。例如「不能刪已發佈文章」「不能裝外掛」「不能改佈景主題檔案」這三條，幾乎是所有非站長角色都該拿掉的紅線。

授權時需要特別核對的七組能力

預設角色裡有些 capability 是地雷，名字看不出危險性，但實際上足以讓整個網站垮掉。我列七個最該警覺的，下列順序不是風險評分，也不代表 Editor 或 Author 預設擁有全部能力：

• edit_themes / edit_plugins：直接在後台改佈景主題或外掛的原始 PHP 程式碼。程式錯誤可能使網站無法正常運作；能否使用內建檔案編輯器還受站台安全設定影響。這個能力預設僅有 Administrator 有，但很多「全權委外的所謂技術顧問」會被開成 Administrator 而順帶擁有它。
• unfiltered_html：允許在文章裡塞 script、iframe 等任何 HTML 標籤，不受 WordPress 的過濾機制保護。單站的 Editor 與 Administrator 預設有此能力，Author 沒有；Multisite 通常限 Super Admin，其他設定或過濾器也可能限制。一旦帳號被盜，攻擊者能直接植入惡意腳本。
• delete_published_posts / delete_published_pages：刪除已上線的內容。Author 對「自己」的文章擁有前一項能力；若帳號遭盜用或人員離職後未停權，已發佈內容就可能被批次刪除。
• manage_options：改 WordPress 全域設定（包含網址、顯示模式）。一個不小心把網站網址改錯，就可能造成前後台無法正常開啟，需要透過主機控制台、WP-CLI 或資料庫修復。這也是為什麼非技術角色不該掛這個能力。
• install_plugins / install_themes：從後台直接安裝新外掛或主題。這是「來路不明外掛變成木馬」這條攻擊鏈的入口。給內容人員這個能力，等於把網站大門鑰匙交給他。
• export（匯出）：透過工具匯出文章、頁面、留言、分類與相關作者資訊。WXR 不是完整資料庫或所有帳號資料的備份，但仍可能包含不應任意帶出的內容。import 匯入能力則可能讓人把髒資料灌進你的網站。
• list_users / promote_users：看到所有使用者帳號、甚至把別人的角色升級。一個被盜的 Editor 帳號若被額外塞了 promote_users，攻擊者可以把自己偷偷升成 Administrator，等你發現時網站早就換人管了。

這七條沒有一條是「外掛裝了才有」的進階功能，全部都是 WordPress 核心內建的 capability。這就是為什麼我一直強調：不要把預設角色當成安全預設值，它僅是「功能預設值」，從資安角度它其實相當寬鬆。搭配網站層級的防護會更穩，例如隱藏登入網址和Wordfence 防火牆設定，把暴力破解和異常登入這一層也補上。

WooCommerce 與會員網站的延伸角色生態

裝了 WooCommerce 之後，角色系統會自動長出兩個新角色：Shop Manager 和 Customer。Shop Manager 本質上是「電商版 Editor」，能管商品、訂單、優惠券，但通常拿不到安裝外掛的權力，這是 WooCommerce 官方刻意設計的安全邊界。Customer 則是訂單系統專用的「消費者身份」，能力極小，通常在顧客於結帳或註冊流程建立帳號時指派；訪客結帳不會因此必然建立帳號。如果你正在架購物網站，WordPress 購物網站架設教學把從零到上線的流程講得很清楚，值得交叉看。

電商場景裡真正要小心的，是「拿掉 Customer 的哪些能力」會破壞結帳流程。Customer 雖然能力少，但其中 read 和它對訂單的讀取能力是結帳、查訂單紀錄的基礎。常見的踩雷情況是：為了「簡化」權限，誤以為 Customer 應有文章編輯能力，或未經測試就調整其帳戶與訂單權限，結果客人下單後看不到自己的訂單，客服信箱被灌爆。所以改 WooCommerce 相關角色之前，先用一個測試帳號完整跑一次「加入購物車、結帳、查訂單」流程，是最保險的驗證方式。自訂角色也能用在前台商業規則：批發站常只讓「批發客」角色看得到價格，其他訪客純瀏覽商品，這種只讓特定角色看得到價格的型錄模式另有完整設定教學。

會員網站則是另一種延伸。如果你做的是「登入才能看內容」的會員制網站，那麼後台角色（這篇的主題）和前台會員瀏覽權限是兩個不同的層次：後台管的是「誰能進 wp-admin」，前台管的是「登入後能看到哪些文章、哪些按鈕」。前台那塊通常用 Ultimate Member、MemberPress、Restrict Content Pro 這類外掛處理，可以與角色管理工具搭配，但仍需測試能力與內容限制是否互相覆寫。要深入了解前台會員瀏覽權限的設定，可以看會員權限控制指南，它專門處理「依角色與登入狀態管控前台內容」的問題，跟我這篇講的後台存取是分工關係。線上課程網站正是這種分工的典型場景：學員依購買的課程取得角色、再解鎖對應內容；想從零把這套流程架起來，可以接著看課程網站的完整架設指南。

SEO 外掛也可能新增 capability，例如控制誰能改 canonical、meta 描述或結構化資料。預設授權範圍依外掛而異；多人共編網站可把必要能力下放給指定角色，但要先用測試帳號確認不會連帶開放全站設定。

權限改完一定要驗證：User Switching 與測試帳號工作流

這一步被漏看的頻率最高，但它能救你一命。改完角色後，你用 Administrator 身份看後台，畫面看起來一切正常，但 Administrator 本來就什麼都看得到，這完全不能證明新角色的設定是對的。你必須實際「變身」成那個新角色，用他的眼睛看一次後台。

最輕量的做法是裝一個叫 User Switching 的免費外掛。它的功能就一件事：在「使用者列表」上，每個帳號旁邊多一個「切換為」連結，點下去你就立刻以那個帳號的身份登入，不需要密碼、不需要登出自己。看完之後再點「切換回原帳號」就好。若需要稽核紀錄，還要確認站上的活動紀錄工具是否會保存這類切換事件。

我自己的標準工作流是這樣：先建一個叫做 test_author、test_editor 的測試帳號（用亂數密碼、寄到獨立測試信箱），指派自訂角色，然後用 User Switching 切換過去，逐項檢查這份清單：

1. 左側選單是不是僅剩「應該出現」的項目？（除了隱藏入口，也測試直接開啟對應網址與執行操作是否被拒絕）
2. 進文章列表，看得到「別人」的草稿嗎？（Author 不該看到）
3. 點進自己的文章，「刪除」和「發佈」按鈕是不是符合預期？（該消失的有沒有消失）
4. 媒體庫看得到哪些檔案？能否刪除或編輯別人上傳的媒體？（實際範圍會受角色能力與外掛影響）
5. 右上角「新增外掛」「自訂佈景主題」這類入口有沒有被擋下？
6. 留言區的管理功能，是僅有讀還是能刪？（視角色而定）

這份清單走一遍不需太久，卻能提早抓出常見的權限配置錯誤。比起等線上出事再回頭除錯，先驗證會省下不少處理時間。

「改了權限卻沒生效」的五個排查方向

這大概是角色設定最常見的疑難雜症：明明在 User Role Editor 把某個能力取消了，使用者的後台卻還是看得到那個按鈕。以下列出五個排查方向，先從測試身分與實際權限查起：

1. 該使用者掛了不僅一個角色。多角色能力通常會合併，但明確拒絕、使用者層設定與 capability filters 也會影響結果。如果你僅取消了新角色的某個能力，但舊角色（例如原本的 Author）還掛著，那個能力就會從舊角色漏過來。排查方式：進使用者編輯頁，確認角色欄位僅有一個，或所有掛著的角色都已經同步處理過。
2. 物件快取（Object Cache）還沒清。標準 WordPress API 更新選項時會更新相關快取；若使用直接資料庫修改或存在快取問題，才檢查對應 object cache。頁面快取與物件快取不同，不應把清除全部快取當成固定修復步驟。
3. 你在用 Administrator 身份測試。Administrator 預設擁有單站管理所需的大多數能力，用它登入通常看不出目標角色的限制。一定要切換成目標角色（用前面講的 User Switching）才能真正驗證。
4. 外掛在程式層級硬塞了 capability。某些外掛會在每次載入時，用程式碼把特定能力加回某個角色（例如 SEO 外掛確保 Editor 一定有 SEO 設定能力）。這種情況下，你在 User Role Editor 取消勾選僅是改資料庫，但外掛執行時又把它加回來了。排查方式：暫時停用可疑外掛，看權限是否就生效了。
5. 瀏覽器或錯誤的快取規則。後台頁面原則上不該被頁面快取；若 CDN 或快取外掛誤把登入狀態頁面納入快取，選單可能顯示舊內容。先強制重新整理，再確認 /wp-admin/ 與登入使用者頁面已排除快取。

這五個方向涵蓋常見的權限異常。排查時先確認測試身份，再看是否有多角色聯集；若仍無法定位，才往外掛、快取與程式碼層級檢查。

還有一個比較少見但很棘手的狀況：你的主題（theme）的 functions.php 裡被前任工程師寫了硬編碼的角色變更，例如反覆呼叫 add_cap 或使用能力過濾器。add_role 不會覆寫已存在的角色；程式造成的能力變更可能在角色介面看得見，但來源仍需檢查程式碼。如果前面五個方向都排查過還是無解，這通常是下一個該懷疑的源頭，也是為什麼複雜網站的權限除錯有時會需要動到程式碼層級的檢查。

角色權限與網站安全的交叉防守

權限系統不是孤立的，它和網站整體安全是同一道防線的兩個面。講白了，角色權限是「假設壞人已經拿到某個帳號」時的最後一道內部防火牆。一個被盜的 Author 帳號，如果沒有 install_plugins 能力，仍可能被用來修改、刪除自己的既有文章或濫用上傳功能；但同樣一個帳號如果是 Administrator，整站就淪陷了。這就是「信任半徑」要盡量小的資安理由。

幾個和權限高度相關的安全建議。第一，Administrator 帳號的數量要嚴格控制，其餘的人能用 Editor 或自訂角色就別給 Admin。第二，登入入口要保護，這跟權限是互補的；更改 wp-admin 登入網址可以減少部分自動化掃描噪音，但不能取代雙因素認證、速率限制與更新。第三，定期稽核閒置帳號，依組織的人員異動與存取政策停用不再需要的帳號。

備份這一環也和權限脫不了關係。如果一個 Editor 擁有 export 能力，他可以把整個網站的內容打包下載，這在員工離職場景裡是常見的資料外洩途徑。把 export 權限留在 Administrator 手上，並且定期用可靠的備份外掛做整站備份，等於從兩個方向同時降低風險：一方面不讓內容被隨意匯出，另一方面即使出事，你較有機會取得可用的還原點；仍要檢查備份範圍、保留週期與實際還原結果。

三個最常被問到的權限問題

實際在做權限設定時，有三個問題幾乎每次都會被問到。以下直接一次回答，免得你卡在同樣的疑惑上。

一、一個帳號可以同時掛兩個角色嗎？WordPress 的資料結構可保存多個角色，但核心後台介面通常僅讓你指派一個；要管理多角色，通常得靠程式碼或外掛。多角色的能力通常會合併，因此若任一角色擁有某個能力，帳號通常就能使用它，不要把第二個角色當成可靠的拒絕機制；明確拒絕、使用者能力與過濾器需一併核對。

二、停用或移除外掛，能力會自動消失嗎？不一定。已儲存的能力會留在資料庫，除非外掛在停用或解除安裝時主動清除。先查該外掛文件與清理行為，確認沒有其他功能依賴後，再移除不再使用的能力。

三、萬一我把自己從 Administrator 鎖出去了，怎麼救？先找仍可用的管理員帳號恢復角色；若沒有，可依主機條件透過 WP-CLI、主機檔案管理器或 SFTP 執行一次性的修復程式碼。也可由熟悉 WordPress 資料結構的人在備份後修正資料庫。修復完成後要立刻移除應急程式碼，並重新檢查角色能力，避免留下可被濫用的入口。

權限稽核清單與行動方案

讀到這裡，你腦裡應該已經有完整的角色權限心智圖了。接下來把它變成你這週就能執行的動作。我把它拆成一個五步行動方案，外加一份可以照著走的稽核清單。

五步行動方案：

1. 盤點現有使用者與角色：到「使用者 → 所有使用者」，把每個帳號目前掛的角色記下來。重點抓出「掛 Administrator 但其實僅在寫文章」的帳號，這些是最該優先降權的。
2. 設計你的自訂角色組合：回頭看前面「五種團隊劇本」那張表，挑最接近你現況的一組當範本，再依實際需求微調。記得原則：複製、不要直接改預設角色。
3. 安裝 User Role Editor，建立新角色：照前面的六步操作流程跑一遍，每建一個新角色，就立刻用 User Switching 切過去驗證。
4. 把使用者逐一遷移到新角色：建議分批做、分批驗證，不要一次全部換掉，這樣萬一有問題能快速回滾到上一批。
5. 依人員異動與網站風險設定複檢排程：權限不是設一次就永遠對。人員異動、外掛增減都會讓角色內容悄悄變化，養成定期複檢的習慣才是長久之計。

稽核清單（照著勾，沒勾到的就是風險點）：

• ☐ 目前網站上有幾個 Administrator？是否每一個都是必要的？
• ☐ 是否存在「直接修改過預設角色」的狀況？（如果有，改成自訂角色）
• ☐ 所有寫手、工讀生帳號，是否都擁有「刪除已發佈文章」的能力？該拿掉的拿掉了嗎？
• ☐ 有沒有任何非 Administrator 帳號擁有 install_plugins、edit_themes、manage_options？
• ☐ 是否有不再需要的帳號？依組織存取政策停用或移除。
• ☐ WooCommerce 網站的 Customer 角色，是否被誤改過？結帳流程實測過嗎？
• ☐ 是否安裝了 User Switching，並用測試帳號驗證過每個自訂角色？
• ☐ 登入入口是否有適當保護，例如雙因素認證與速率限制？隱藏登入網址不是必要或充分條件。
• ☐ 是否有定期整站備份，且備份檔存放在「網站本身以外」的位置？

講白一點，權限管理沒有任何一步是高難度動作，它考驗的是紀律：你願不願意在「順手給 Admin 比較快」和「多花十分鐘設一個受限角色」之間，每一次都選後者。實務上的回報是，這十分鐘的投資，早晚會在某一個你想都沒想過的瞬間，救你一個晚上不用加班救站。

權限規劃應以實際工作為準，先備份並測試受限角色，再逐步指派給團隊。確認每位使用者可完成工作，也無法進行未授權操作，比只調整角色名稱更重要。 相關背景可參考：W3Techs 統計。