WordPress 使用者權限完全指南：用 User Role Editor 精準管控每個角色的後台存取範圍

這張表裡最該小心的是編輯，原因比管理員更值得說明。管理員的危險大家都知道，所以不會亂開。編輯看起來只管內容、很無害，卻握有 delete_published_posts 與 delete_published_pages，等於能把你已上線的成果一次清空。WordPress 的權限模型不會問你「確定要交出刪除權嗎」，它只認角色，網站內容的安全性完全取決於你派了什麼角色給對方，而頁面與文章的差別也會影響你能刪除什麼，可先看 WordPress 頁面建立與編輯釐清兩者。

投稿者是預設角色裡最安全的一個，它連發佈權限都沒有，寫完只能存草稿，必須等有發佈權限的人按核可才會上線。這對需要全程審核的外部寫手其實很合用。而作者只能管自己的文章，碰不到別人的，對單人寫手來說也算安全。記住一個判斷原則：權限愈靠近「發佈」「刪除」「設定」這三個動作，風險愈高。要配一個安全的角色，就想辦法讓它離這三個動作愈遠愈好。

把角色想成「權限套餐」，capability 想成「單點」

要把角色權限設定真正內化，可以用一個餐廳的比喻：預設角色就像六種固定套餐，每種套餐裡的菜色已經配好、不能單點替換；capability 則是菜單上的每一道單點菜。WordPress 預設只給你選套餐，沒辦法跟它說「我要編輯套餐，但把刪除這道菜換掉」。權限外掛做的，就是把套餐拆成單點，讓你逐道挑選，重新組合成一份剛好夠吃、不浪費也不會撐壞的套餐。

capability 還可以再細分兩類，這個區分在排查問題時很關鍵。一類是 primitive capability（原始權限），像是 edit_posts、delete_posts，它直接對應某個動作能不能做。另一類是 meta capability（後設權限），像是 edit_post（單數）、delete_post（單數），它不直接放行，而是 WordPress 在執行時根據當下那篇文章的作者、狀態，動態換算成對應的原始權限再比對。所以當你發現某個角色「能編輯自己的文章，卻不能編輯別人的」，背後就是 meta capability 在做條件判斷。理解這層機制，日後排查「為什麼他改不了這篇」這類問題時，才不會只在 capability 清單上盲找。

WordPress 的角色資料存在資料庫的 wp_options 表裡，索引是 wp_user_roles 這個 option；個別使用者被賦予哪個角色，則記在 wp_usermeta 裡、meta key 為 wp_capabilities。這意味著角色的設定是全域的、所有使用者共用同一份定義，單一使用者的覆寫則獨立存在他自己的 usermeta。也因為資料落在資料庫，前面才會一再強調備份，畢竟改錯了不會跳出確認框，按下去就直接寫進去了。把這條資料流向記住，你會更明白為什麼權限設定值得當成一件嚴肅的維護工作來看待。

WooCommerce 與其他外掛如何改變 capability 地圖

WordPress 原生的 capability 只涵蓋文章、頁面、媒體、佈景、外掛、使用者這幾類核心物件。每裝一個大型外掛，它往往會向系統註冊一整套自己的 capability，讓角色清單瞬間膨脹。WooCommerce 就是最好的例子：裝完之後，User Role Editor 的清單會多出 edit_product、publish_product、edit_shop_orders、view_woocommerce_reports 這一整排商品、訂單、報表相關權限。對於同時經營內容與電商的站長，這份變長的清單既是彈性的來源，也是出錯的溫床。

電商網站的權限風險結構與純內容站不同。在內容站，刪除一篇頂多損失一篇文章；在電商站，誤開 edit_shop_orders 或退款相關權限，可能直接牽動金流與顧客資料。所以配電商角色時，判斷次序要倒過來想：先問「哪些動作碰得到錢與個資」，把這些 capability 全部預設關閉，再逐一開放給真正需要的人。商品上架、補貨、圖片維護這類低風險操作可以給得寬鬆；訂單狀態變更、退款、報表匯出、顧客資料檢視，則應該全部鎖在管理員層級。若你的電商角色分工較複雜，WooCommerce 購物網站架設提供了整體的設定脈絡可一併參考。

User Role Editor：比其他權限外掛更適合中小網站的選擇

User Role Editor 是一款免費的 WordPress 角色權限外掛，能讓你新增、複製、刪除角色，並把每個角色的 capability 用清單逐項勾選。它最大的優勢是能「複製既有角色再微調」，比從零開始設定快很多，也支援針對單一使用者覆寫權限，這在實務上比你想像的常用。

這款外掛在 WordPress.org 上線多年，累積安裝次數達數十萬次。它走的是純權限管理的路線，不牽扯會員制、不綁訂閱付費牆，對只想管好後台權限的站長來說剛剛好。如果你之後需要的是會員等級、內容付費解鎖那類功能，那是 Member Press、Members 這類外掛的戰場，定位完全不同。硬要用會員外掛來管角色權限，設定只會變得更複雜、網站也更重。

具體能力涵蓋新增角色、複製角色、逐項勾選 capability 與刪除多餘角色，全部在後台視覺化操作；其中最被看重的一項，是可針對單一使用者覆寫權限，不必為了一個資深員工另開新角色。進階設定還能把 edit_posts、delete_published_pages 這類英文代碼轉成中文說明，降低勾選出錯的機率。免費版就足以應付多數中小網站的分工需求。

市面上能做角色權限的外掛不少，但很多都把權限管理塞進更大的會員或電商框架裡，對單純想「少給一點權限」的站長是負擔。User Role Editor 的價值在於它只做一件事、把這件事做好，這也是它能穩定存在這麼多年的原因。若你連外掛都不想裝太多，可先看 怎麼用 AI 挑 WordPress 外掛，把工具數量控在合理範圍。

安裝與基本設定：啟用後的第一個關鍵動作

安裝啟用後，立刻到「設定 > User Role Editor」勾選「以人類可讀的格式顯示權限」。這個設定不開，後面你看到的全是 edit_posts、delete_published_pages 這種英文代碼，很容易勾錯，而權限勾錯的後果是網站某些功能莫名其妙不能用，或某個人突然拿到了他不該有的權力。

1. 後台左側「外掛 > 安裝外掛」，搜尋 User Role Editor，找到後按安裝、再啟用。不熟外掛安裝流程的話，可先參考 WordPress 外掛安裝三種方法。
2. 啟用後到「設定 > User Role Editor」，把「以人類可讀的格式顯示權限」打勾後儲存，之後 capability 清單會出現中文說明。
3. 到「使用者 > User Role Editor」認識主要操作入口，這裡是新增、複製、編輯角色的地方；「設定」則是偏好設定，兩者別搞混。
4. 動權限前先備份網站。權限設定錯誤有可能讓角色功能異常、甚至讓你自己進不去後台，備份是保命步驟。
5. 檢查目前網站有哪些既有角色與其權限狀態，建立基準線，這樣改完才知道到底動了什麼。

備份這一步不能省。WordPress 權限資料存在資料庫的 wp_options 與 wp_usermeta 裡，改錯了不會跳出確認視窗，改完按更新就生效。建議在動任何角色設定前，先用 WordPress 備份外掛做一次完整備份，或至少跑一次 UpdraftPlus 備份還原教學裡的手動備份流程。這花不了五分鐘，卻能在你把自己鎖在外面時救回來。若連備份與還原觀念都還沒建立，先看過 WordPress 備份與還原指南再回來動權限會踏實很多。

新增角色並分配權限，從一個「文案寫手」走完整個流程

到「使用者 > User Role Editor > 新增使用者角色」，設定英文 ID 與中文名稱，複製來源選「編輯」，接著移除所有 delete_ 開頭的權限、關閉頁面編輯、關閉發佈權限。關掉發佈後，這個角色的所有修改都會變成「送交審閱」，必須管理員核可才會上線，這正是你想要的外包寫手配置。

為什麼要從「編輯」複製再刪減，不直接從「無」開始往上加？因為編輯已經綁好了一整套與內容相關的 capability，從這裡開始你只要做減法，動作少、出錯率低。但要注意，編輯裡也藏了三個必移除的高危權限，少移除一個就等於留了一個漏洞。

1. 名稱 ID 用英文（例如 copywriter），顯示名稱用中文「文案寫手」，複製來源選「編輯」。英文 ID 是給系統讀的，中文是給人看的，別用中文當 ID。
2. 移除所有 delete_ 開頭的權限，尤其是 delete_published_posts 與 delete_pages，這兩個是多數網站出事前最常被忽略的單一設定。
3. 關閉 edit_pages 與頁面相關權限，讓這個角色完全碰不到頁面，只能編輯文章。
4. 關閉「發佈文章」「發佈頁面」。關掉後，這個角色的編輯器裡「發佈」按鈕會自動變成「送交審閱」，所有修改都進審核佇列。
5. 如果裝了 WooCommerce 等外掛，capability 清單會額外出現商品、訂單相關項目，依需求勾選即可。
6. 確認無誤後按「更新」儲存，這個新角色就建立在資料庫裡了。

這裡有一個觀念值得單獨講：很多人以為設定權限的核心是「新增角色」，其實真正的關鍵是「移除危險 capability」。拿一個權限最小的角色當底，再逐一補進你確認過的權限，這樣的做加法思路，永遠比拿「編輯」當底再砍更安全，因為做加法時你清楚知道每一個權限是怎麼進來的；做減法時你永遠怕漏了一個。如果你這個角色要拿來接的是 SEO 文案，也可以順手把 WordPress SEO 外掛裡的「編輯 SEO 資訊」權限納入考量，免得寫手誤動排名設定。要配電商小幫手角色的話，商品相關的 capability 路徑可參考 WooCommerce 購物網站架設的說明。

至於要不要順便讓這個角色回覆訪客留言，要看留言量。留言不多就別開，多到需要分工再開「審閱留言」這項權限。常見的失誤是站長為了省事，把所有看起來無害的權限一次勾好，結果寫手連表單、側邊欄小工具都能動，方便當場變成失控。配權限的原則永遠是：先給最少，不夠再加；先給太多、出事再刪的做法，幾乎都來不及。連選單設定、分類排序這類會影響全站結構的功能，都不該出現在外包角色身上。

設定成果驗證：用文案寫手帳號登入該看到的三個變化

新增一個測試使用者套用新角色，登入後會看到三個明顯變化：文章列表的「刪除」選項消失、編輯文章時的「發佈」變成「送交審閱」、側邊欄的「頁面」整個不見。這三個現象同時出現，就代表最小權限原則真的生效了，設定沒有只停在表面。

1. 到「使用者 > 新增使用者」，角色選剛建好的「文案寫手」，填入測試帳號資料後建立。
2. 驗證點一：用測試帳號進「文章 > 全部文章」，每一篇文章列上「刪除」連結應該全部消失，只剩「編輯」。
3. 驗證點二：點進任一篇文章，編輯器右上角的「發佈」按鈕變成「送交審閱」，按下去後文章狀態變成「待審核」。
4. 驗證點三：看後台左側欄，「頁面」選項整個被隱藏，這個角色根本不知道頁面的存在。
5. 建議用無痕視窗或另一個瀏覽器同時登入管理員與測試帳號，兩邊對照最清楚。

為什麼要這樣逐一驗證？因為權限設定的「成功率」很容易被錯覺矇騙。勾選清單按了更新，不代表每個 capability 都照你想的作用。實務上有一種情況值得留意：刪除權限移除了，但某個 區塊編輯器的外掛又偷偷把刪除按鈕塞回來，最後是靠實際登入測試帳號才發現的。所以請務必用測試帳號親自走一遍：寫一篇草稿、送交審閱、切回管理員帳號看「待審核」佇列、核可發佈。走完這個迴圈，你才知道整個 文章與頁面的權限鏈是通的。

這個驗證習慣也適用在其他改動上。例如你之後動了 登入頁面、隱藏登入網址，或裝了 Akismet 防垃圾留言，都該用低權限帳號實測一次，確認沒有把功能改壞或意外開了門。驗證的成本永遠低於事後救火的成本。

針對單一使用者覆寫權限：不另開角色的進階做法

到「使用者 > 全部使用者」，在指定使用者列上點「權限」，這裡的設定只覆寫這一個人，不影響他原本所屬的角色。同一個「文案寫手」角色下，你可以只給 A 同事額外開啟「發佈文章」與「刪除自己的文章」，B 同事維持送審，兩人共用同一個角色卻有不同權限。

這個功能實務上比你想像的常用。團隊裡總有一兩個資深成員，你信任他、想給他多一點權力，但又不到值得為他另開一個全新角色的程度。這時個別覆寫就是最輕量的解法：不用新增角色、不用改動既有角色的設定，只在那一個人的層級多開幾個 capability。改完之後若反悔，取消勾選就回到角色預設，完全可逆。不過要提醒一點，個別覆寫累積太多會造成權限管理混亂，超過三個人就要回頭檢視是不是該新增一個角色，覆寫只該當成例外。

舉個會比較好懂的情境：團隊有兩個文案寫手 A 與 B，都掛在同一個「文案寫手」角色下。A 是核心成員，你想給他發佈與刪除自己文章的權限；B 是剛合作的接案，維持送審就好。你不用為 A 新建一個「資深文案寫手」角色，只要在 A 的個人權限頁面多勾兩個 capability，B 的設定一字不改。兩個人用同一個角色，卻走不同的工作流程。這對需要彈性分工、又不想角色爆炸的站長來說，是很實用的設計。如果你連會員登入後的選單都想依身分切換，可以再搭 依登入狀態切換會員選單一起做；若網站已搬到正式主機上，搭配 WordPress 主機比較與 WordPress 搬家到新主機的觀念，能把多站管理也一併考量進去。

角色擴張決策矩陣：什麼時候該開新角色、什麼時候用覆寫

隨著團隊長大，站長遲早會面對一個抉擇：某個同事的需求跟現有角色對不上時，到底該另開一個新角色，還是用個別覆寫解決？開太多角色會讓後台角色清單變長、難以維護；覆寫太多又會讓同一個角色下每個人的權限都不一樣，盤點時更頭痛。底下這個二維矩陣用兩個維度來判斷：橫軸是「這類需求會不會重複出現在人數上」，縱軸是「需求的權限與現有角色差距多大」。

這張矩陣的核心判斷只有一句話：會重複出現的需求用角色，只出現一次的例外用覆寫。當你發現自己為了同一種需求反覆覆寫不同人，那就是訊號，代表這個需求已經穩定到值得獨立成一個角色。反過來說，如果只是因為某一個臨時專案要開權限，硬開一個「專案臨時角色」，專案結束後它就會變成孤兒角色，躺在清單裡佔位、增加未來盤點的負擔。

角色清單的整潔度會直接影響你日後維護的意願。一個網站累積到八、九個角色，每個又各自有覆寫，盤點時幾乎不可能一次看清楚全貌。實務上比較健康的數量是「能對應到團隊裡一個真實職務的角色」加一兩個。每多一個角色，都應該能在腦裡對應到「這個角色代表哪一種人、做哪些事」，對應不出來的角色，就是該合併或刪除的候選。

以這類同時經營內容與少量電商的中型網站為例，常見的狀況是這樣演變的：剛開始只有站長一人，預設角色就夠用；接著加入約 2 到 4 名接案寫手，這時多半會建一個「文案寫手」角色，把發佈與刪除權限關掉、改走送審；等到團隊長到約 6 到 10 人，又陸續出現上架員、客服、社群小編這類職務，角色數量往往跟著增加到約 5 到 8 個，個別覆寫也開始零星出現。依這類站的典型表現，真正出問題的轉折點通常落在角色數量超過約 8 到 10 個、或單一角色的覆寫人數累積到約 4 到 6 人之後：這時已經沒有人能一次說清楚「誰到底能做什麼」，離職帳號忘了停權、某個覆寫開了卻沒記錄，都會在這個階段浮現。角色整理這件事並沒有自動化的捷徑，一旦清單已經失控，多半只能靠人工逐帳號、逐角色重新盤點，沒有外掛能幫你判斷哪些覆寫是必要的、哪些該收斂成獨立角色。比較務實的決策角度是：與其等到失控再整理，不如在角色數量逼近約 8 個之前就先凍結新增，強迫自己用覆寫或合併既有角色來吸收新需求，把「能不能對應到一個真實職務」當作新增角色的唯一門檻，門檻過不去就用覆寫撐著。

權限設定故障排除：被鎖在後台與其他常見故障

權限設定最嚴重的故障，發生在自己不小心移除了管理員帳號的 manage_options 或更關鍵的 capability，結果連後台都進不去。這種狀況不會給你任何提示，點登入後直接看到權限不足的畫面，前一刻還能用的後台瞬間變成禁止進入。遇到時不要慌，因為角色資料存在資料庫裡，你可以繞過 WordPress 介面直接修復。

1. 確定你還有一個管理員等級帳號：用另一個瀏覽器或無痕視窗嘗試登入，確認是否所有管理員都被波及，還是只有單一帳號出問題。
2. 透過資料庫工具還原角色：使用主機面板提供的 phpMyAdmin 或 WP-CLI，把 wp_user_roles 這個 option 還原到備份版本；若沒有備份，可透過外掛暫時重新定義預設角色。
3. 暫時停用權限外掛測試：把 User Role Editor 先停用，看角色是否回到預設狀態，藉此判斷問題是出在外掛的覆寫還是資料庫本身的定義。
4. 檢查主題 functions.php 是否寫入了角色變更：有些佈景或自訂程式碼會在載入時覆寫角色，停用佈景換成預設主題可排除這個變因。
5. 修復後立刻補一次備份：問題解決當下就把正確的狀態備份下來，這份備份就是你未來再次出錯時的保險。

另一種常見的隱性故障是「capability 看起來設對了，前台卻沒生效」。原因經常出在快取。權限檢查的結果有時會被快取外掛或伺服器端快取層暫存，導致你改了權限，使用者的實際體驗還停留在舊狀態。排查時先清除網站快取、CDN 快取，再請使用者登出重新登入測試。如果問題還在，再用一個乾淨的無痕視窗驗證，排除瀏覽器本身快取的干擾。處理快取與權限互動的細節，可參考 WordPress 快取外掛裡關於快取失效時機的說明。

還有一類故障與外掛衝突有關。某些區塊編輯器擴充或頁面建立器會自行註冊 capability，或在更新時重新定義角色，把你的自訂設定覆蓋掉。症狀通常是「明明沒動設定，某天卻發現權限跑掉了」。追查方法是把最近更新過的外掛逐一停用比對，找出是哪一個在角色定義上動手腳。找到之後，可以選擇換掉該外掛，或在更新前先匯出角色設定、更新後再匯入還原。

把權限當成會長大的資產來管

回顧整件事的核心：WordPress 預設的六種角色綁定一整包 capability，真正能保護網站的，是有沒有在動手前先想清楚「這個人到底需要做哪些動作」，裝哪款外掛反而是次要的。權限設計的重點一直在「移除危險 capability」，尤其 delete_published_posts、edit_theme_options、manage_options 這三個。把這幾個權限從外包角色身上拿掉，網站的安全性會立刻升一級。

權限其實是一種會隨團隊成長而變複雜的資產。今天兩個人的團隊，預設角色加一點微調就夠；等團隊長到十個人、角色超過五六種，個別覆寫就開始失控，這時該做的是回頭重新盤點角色，把架構整理清楚，別再繼續疊床架屋。建議每隔半年把全站角色與 capability 清單拉出來審一次，把不再需要的角色刪掉、把權限給得過大的角色收斂回來，這比任何外掛都更能維持網站安全。

每半年該跑一次的權限審核清單

權限就像網站的呼吸，平時不自覺，一旦失調才會有感。把下列檢查項目排進定期維護流程，能讓你在出事之前就先把漏洞補上。這份清單設計成可以在半小時內走完一遍，搭配 網站維護費用的整體維護觀念一起執行最有效率。

• 盤點使用者清單：逐一確認每個帳號是否仍屬於現職人員，離職、約滿、合作結束的帳號一律停用或刪除，避免幽靈帳號長期保留權限。
• 檢查每個角色的高危權限：特別留意 delete_published_posts、edit_theme_options、manage_options、edit_users 這幾個，確認它們只出現在管理員層級。
• 清點個別覆寫：把所有單一使用者覆寫拉出來看，超過三個人的覆寫就評估是否該升級成一個獨立角色。
• 核對管理員帳號數量：管理員應該維持在最少人數，凡是能換成編輯或更低權限的，就降級，降低最高權限帳號被盜的衝擊面。
• 確認備份可還原：隨機抽一次最近的備份實際跑還原測試，確認它真的能用，而不是只是一份沒驗證過的檔案。
• 檢視外掛註冊的新 capability：最近半年若有裝新外掛，確認它新增的 capability 有沒有意外落到不該擁有的角色上。
• 更新密碼與登入安全：順手把高權限帳號的密碼更新一輪，並確認雙因素驗證仍開啟，搭配 登入頁面與 隱藏登入網址的防護一起檢視。

這份清單的重點在於「定期」兩個字。多數網站的權限事故，回頭看都會發現是某個該做的檢查拖了半年沒做，漏洞就一直留著。把權限審核變成一個跟備份一樣固定的維護項目，出事的機率會比任何單次補強都低得多。若你把整個網站的維護當成專案在管理，從主機到 WordPress 的建站指南與 技術 SEO 指南能提供更全面的維護框架。

最後給一個實際的行動建議：今天就用一個測試帳號，把自己常用的外包角色重新配一遍，從「投稿者」開始只往上加你確實需要的權限，然後登入測試帳號走完一次投稿、送審、核可的流程。走完這一輪，你會很清楚看到「最小權限」與「預設角色」在實際操作上的差別。權限設定只要動手做過一次就會熟練，但拖著不做，風險會一直留在那裡。把這項基本功練好，之後不論是搭配 電商設定、部落格，還是處理更複雜的 內容結構與 網站設計，分工都會更順手；長期經營也要顧好 網站維護費用與 永久連結設定，這些項目和權限分工彼此相關。分工觀念也適用到網站之外，例如團隊同時經營多個廣告帳戶時，理解 Google Ads MCC 管理員帳戶的集中管理邏輯，能讓跨帳戶的權限派發與這裡的角色設定保持同一套思路。

FAQ：WordPress 使用者角色與權限常見疑問

Q1. 同一個人可以擁有多個角色嗎？權限怎麼計算？可以，而且權限會取聯集，也就是「只增不減」。A 角色沒有的權限，只要 B 角色有，這個人就擁有。給太多角色等於把權限愈疊愈大，反而更危險，要給多重角色前最好先想清楚為什麼非這樣不可。

Q2. 停用或刪除權限外掛後，自訂角色會消失嗎？停用外掛後多數情況角色與設定仍保留，只是無法再透過外掛介面編輯；但若直接刪除外掛、或資料庫被清理過，自訂角色就可能跟著不見，所以重要的角色設定最好留一份設定紀錄。

Q3. WordPress 搬家時自訂角色會跟著搬過去嗎？角色資料存在資料庫的 wp_options 裡，只要連資料庫一起搬移，自訂角色就會保留。但搬家同時若換了外掛、或新主機上的 WordPress 路徑不同，capability 對應可能出現落差，搬完務必用測試帳號逐項驗證一次。

Q4. 多站網路模式下的超級管理員跟單站管理員差在哪？超級管理員只存在於多站網路模式，能跨所有子站管理使用者、佈景、外掛與設定；單一站點的管理員權限只及於自己那個站。多站架構下若把一般管理員誤當超級管理員使用，可能讓單站管理員意外拿到跨站權限，這是大型網路最需要小心的設定。

Q5. 可以限制某個角色只能看特定分類嗎？單靠 User Role Editor 做不到分類層級的內容隔離，這需要內容權限類外掛或自訂程式碼。若確實需要「只能改某一個分類」，已超出角色權限的範疇，得換另一種工具處理；多數中小網站把角色配到「只能編輯文章、不能發佈、不能刪除」就夠用。