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

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

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

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

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

這個比喻之所以重要，是因為它解釋了 WordPress 權限系統的底層邏輯：真正決定「能做什麼」的，從來不是角色這個名字，而是它背後綁的那一堆 capability。角色僅是一個方便打包的標籤。當你說「這個帳號是 Editor」，WordPress 真正在檢查的是「這個帳號有沒有 edit_others_posts 這支鑰匙」。一旦你看懂這一層，後面所有自訂角色的操作都會變直覺。

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

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

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

角色	核心定位	能做什麼（摘錄）	最適合誰
Super Admin	多站台總管	所有能力＋管理整個多站台網路（Multisite）	僅在 Multisite 架構下存在，單站用不到
Administrator	單站最高權限	安裝／移除外掛與佈景主題、改核心設定、管理所有使用者	站長本人，或你完全信任的技術窗口
Editor	內容總編	編輯「所有人」的文章、管理分類與標籤、審核留言	內容主管、總編輯
Author	獨立作者	僅管理自己的文章（含發佈），看不到別人的草稿	外部撰稿、固定專欄作者
Contributor	投稿者	僅能寫草稿、無法發佈，需 Editor 以上審核	客座投稿、實習寫手
Subscriber	純會員	僅能登入、改自己的個人資料	前台會員、留言註冊者

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 在每一次頁面載入時，會把這個 user_roles 欄位讀進記憶體，所有「這個使用者能不能做某件事」的判斷，底層都是呼叫同一個函式 current_user_can('能力名稱')。這個函式回傳 true 或 false，就決定了按鈕要不要顯示、動作要不要執行。你看到的「權限沒生效」，本質上多半就是 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 外掛清單 看起。

檢查面向	要確認的事	適用情境
角色與 capability	能否複製角色、搜尋並增減能力	一般後台分工
內容層級限制	是否需要限制特定文章、分類或前台內容	會員站、多部門網站
自訂文章類型	能否辨識外掛新增的 capability	電商、課程或客製系統
維護與回復	最近更新、相容版本、匯出與還原方式	正式站與多站點管理

挑選的原則很簡單：需求驅動，不要為了功能多而裝肥大外掛。如果你的需求就是「給寫手一個受限角色」，User Role Editor 完全夠用；僅有當你需要「文章層級的閱讀權限」或「自訂文章類型的細粒度管控」時，才往上換成 Members 或 Capability Manager Enhanced。裝太多權限類外掛會互相覆寫設定，反而讓除錯變得更難，這是新手最常看漏的地雷。

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

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

講了一堆概念，真正落地還是要對應場景。我整理五種最常見的團隊形態，每一種給你一組可以直接抄的權限藍圖。這些是依不同規模網站常見需求歸納出的配置版本。

團隊形態	角色配置建議	關鍵取捨
一人創業＋遠端虛擬助理	站長 Administrator；助理開自訂角色 content_manager（複製 Editor，拿掉 delete 與 theme、plugin 相關能力）	助理能發文、能回覆留言，但不能刪文章、不能碰外掛主題
內容媒體站（總編＋多位作者）	總編 Editor；專欄作者 Author；客座投稿 Contributor；純讀者 Subscriber	Editor 控審稿節奏，Author 自管自家文章，Contributor 走審稿流程
WooCommerce 電商（老闆＋工讀生＋客服）	老闆 Administrator；出貨工讀生自訂角色 shop_staff（Shop Manager 拿掉外掛管理）；客服開 Shop Manager	訂單處理和商品上架可以授權，但安裝外掛、改付款閘道的權力要留住
接案交付（設計公司交站給客戶）	交付前先建一個 client_admin（複製 Administrator，拿掉 install_plugins 與 edit_themes）	客戶能改內容、改選單，但不會不小心把主題刪了或裝壞外掛
多部門共編（學校、協會網站）	各部門各自一個自訂 Editor 角色，搭配外掛做「分類隔離」	讓 A 部門看不到 B 部門的草稿，這需要 capability 之外再加分類層級的管控

這張表最重要的不是細節，而是背後的判斷邏輯：先盤點「這個人不能做哪些事會出大事」，再回推他需要哪些 capability。從風險反推，比從功能正推更容易設計出安全的角色。例如「不能刪已發佈文章」「不能裝外掛」「不能改佈景主題檔案」這三條，幾乎是所有非站長角色都該拿掉的紅線。

藏在「Editor」與「Author」裡的七個隱形風險

預設角色裡有些 capability 是地雷，名字看不出危險性，但實際上足以讓整個網站垮掉。我列七個最該警覺的，順序大致照殺傷力排：

• edit_themes / edit_plugins：直接在後台改佈景主題或外掛的原始 PHP 程式碼。一個分號打錯，整站立刻出現 500 錯誤白屏。這個能力預設僅有 Administrator 有，但很多「全權委外的所謂技術顧問」會被開成 Administrator 而順帶擁有它。
• unfiltered_html：允許在文章裡塞 script、iframe 等任何 HTML 標籤，不受 WordPress 的過濾機制保護。Author 預設沒有，但 Administrator 有。一旦帳號被盜，攻擊者能直接植入惡意腳本。
• delete_published_posts / delete_published_pages：刪除已上線的內容。Author 對「自己」的文章擁有前一項能力；若帳號遭盜用或人員離職後未停權，已發佈內容就可能被批次刪除。
• manage_options：改 WordPress 全域設定（包含網址、顯示模式）。一個不小心把網站網址改錯，就可能造成前後台無法正常開啟，需要透過主機控制台、WP-CLI 或資料庫修復。這也是為什麼非技術角色不該掛這個能力。
• install_plugins / install_themes：從後台直接安裝新外掛或主題。這是「來路不明外掛變成木馬」這條攻擊鏈的入口。給內容人員這個能力，等於把網站大門鑰匙交給他。
• export（匯出）：把整份網站內容（含使用者資料）打包下載。在外洩場景裡非常危險，一次點擊就能把所有文章、留言、甚至使用者名單帶走。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 的 edit_published_posts 拿掉（這沒問題），但同時誤刪了某個 WooCommerce 關聯能力，結果客人下單後看不到自己的訂單，客服信箱被灌爆。所以改 WooCommerce 相關角色之前，先用一個測試帳號完整跑一次「加入購物車、結帳、查訂單」流程，是最保險的驗證方式。自訂角色也能用在前台商業規則：批發站常只讓「批發客」角色看得到價格，其他訪客純瀏覽商品，這種只讓特定角色看得到價格的型錄模式另有完整設定教學。

會員網站則是另一種延伸。如果你做的是「登入才能看內容」的會員制網站，那麼後台角色（這篇的主題）和前台會員瀏覽權限是兩個不同的層次：後台管的是「誰能進 wp-admin」，前台管的是「登入後能看到哪些文章、哪些按鈕」。前台那塊通常用 Ultimate Member、MemberPress、Restrict Content Pro 這類外掛處理，跟 User Role Editor 互補而不衝突。要深入了解前台會員瀏覽權限的設定，可以看會員權限控制指南，它專門處理「依角色與登入狀態管控前台內容」的問題，跟我這篇講的後台存取是分工關係。

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. 該使用者掛了不僅一個角色。前面提過，多角色的權限取聯集。如果你僅取消了新角色的某個能力，但舊角色（例如原本的 Author）還掛著，那個能力就會從舊角色漏過來。排查方式：進使用者編輯頁，確認角色欄位僅有一個，或所有掛著的角色都已經同步處理過。
2. 物件快取（Object Cache）還沒清。裝了 Redis 或 Memcached 物件快取的網站，capability 對應表會被快取住，改完後可能要等幾分鐘、或手動清除快取才會反映。如果你用了快取外掛，把它「清除全部快取」的按鈕按一下通常就好了。
3. 你在用 Administrator 身份測試。Administrator 預設擁有單站管理所需的大多數能力，用它登入通常看不出目標角色的限制。一定要切換成目標角色（用前面講的 User Switching）才能真正驗證。
4. 外掛在程式層級硬塞了 capability。某些外掛會在每次載入時，用程式碼把特定能力加回某個角色（例如 SEO 外掛確保 Editor 一定有 SEO 設定能力）。這種情況下，你在 User Role Editor 取消勾選僅是改資料庫，但外掛執行時又把它加回來了。排查方式：暫時停用可疑外掛，看權限是否就生效了。
5. 瀏覽器或錯誤的快取規則。後台頁面原則上不該被頁面快取；若 CDN 或快取外掛誤把登入狀態頁面納入快取，選單可能顯示舊內容。先強制重新整理，再確認 /wp-admin/ 與登入使用者頁面已排除快取。

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

還有一個比較少見但很棘手的狀況：你的主題（theme）的 functions.php 裡被前任工程師寫了硬編碼的角色變更，例如直接用 add_role 或 add_cap 在每次載入時強制覆寫。這種設定不會出現在任何外掛介面裡，你僅能透過檢視主題檔案找到它。如果前面五個方向都排查過還是無解，這通常是下一個該懷疑的源頭，也是為什麼複雜網站的權限除錯有時會需要動到程式碼層級的檢查。

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

權限系統不是孤立的，它和網站整體安全是同一道防線的兩個面。講白了，角色權限是「假設壞人已經拿到某個帳號」時的最後一道內部防火牆。一個被盜的 Author 帳號，如果沒有 install_plugins 能力，頂多被拿去發幾篇垃圾文章；但同樣一個帳號如果是 Administrator，整站就淪陷了。這就是「信任半徑」要盡量小的資安理由。

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

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

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

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

一、一個帳號可以同時掛兩個角色嗎？WordPress 的資料結構可保存多個角色，但核心後台介面通常僅讓你指派一個；要管理多角色，通常得靠程式碼或外掛。多角色的能力通常會合併，因此若任一角色擁有某個能力，帳號通常就能使用它，不能用第二個角色去抵銷第一個角色的能力。

二、停用或移除某個外掛之後，它當初加進角色的能力會自動消失嗎？通常不會。外掛把 capability 寫進 user_roles 欄位之後，那條記錄就留在資料庫裡了，停用外掛僅會讓外掛的介面和功能停止運作，已經寫入的能力多半還掛在角色上。這就是為什麼有些網站在移除 SEO 外掛很久之後，Editor 角色裡還看得到一堆 SEO 相關的勾選。清理方式是用 User Role Editor 手動把這些孤兒能力取消勾選，別期待它會自己消失。

三、萬一我把自己從 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 比較快」和「多花十分鐘設一個受限角色」之間，每一次都選後者。實務上的回報是，這十分鐘的投資，早晚會在某一個你想都沒想過的瞬間，救你一個晚上不用加班救站。

WordPress 之所以能撐起全球超過四成的網站（W3Techs 統計），靠的就是這套彈性到近乎任性的權限架構，它把「信任誰、信任到什麼程度」這個本來屬於管理的問題，變成了你可以用幾個勾選框就調控的技術設定。把這個能力用對方向，你的網站就不僅是一個發佈內容的容器，而是一座你真正能掌控、能放心交給團隊共編的數位資產。現在就打開你的後台，先把那個最不該掛 Administrator 的帳號降權吧，這是你今天能做的、風險報酬比最高的一個動作。