WordPress 網站安全基本功：登入防護、更新策略與被入侵後的處理順序

某天早上打開自己的網站，首頁多了一段看不懂的外語連結；或是 Search Console 突然寄來一封「安全性問題」通知。這種事情通常不是因為有人特別針對你，而是自動化掃描器剛好掃到一個沒更新的外掛。這篇文章把 WordPress 網站安全拆成四個層次來談：登入、更新、權限、邊界，再加上很少有人寫完整的「被入侵之後該按什麼順序處理」。

先看清攻擊面：誰會攻擊一個小網站

「我的網站沒什麼流量，應該沒人想攻擊」是我聽過最多、也最容易付出代價的假設。絕大多數針對 WordPress 站台的攻擊都不是人工挑選目標，而是機器人在整個網際網路上大範圍掃描已知漏洞與弱密碼。WordPress 官方在說明暴力破解時就寫得很直白：這類嘗試是自動化且經常來自分散的殭屍網路，即使沒有成功登入，光是請求量就可能把你的站台拖垮（WordPress 官方：Brute Force Attacks）。

被攻破的網站對攻擊者有價值的地方，通常也不是你的內容。常見用途是掛上導向賭博或成人內容的隱藏連結、寄送垃圾郵件、放釣魚頁面、或把你的主機當成攻擊其他站台的跳板。換句話說，你的網站本身有沒有商業價值，跟它會不會被攻擊沒什麼關係。

WordPress 官方也說明過，正因為這套軟體支撐了超過 43% 的網站，整個生態系（核心、外掛、主題）都會是攻擊者投報率最高的研究對象；官方安全團隊的工作之一，就是針對 OWASP Top Ten 這類威脅把核心軟體加固，並與大型主機商合作發展 WAF 阻擋規則（WordPress.org：Security）。這也意味著：核心本身相對受到照顧，你的風險大部分落在你自己安裝的東西與你自己的設定上。

用威脅發生的順序來排，而不是用功能分類

多數安全教學是按功能分類寫的：密碼一段、外掛一段、防火牆一段。實際遇到事情時，這種排法不太好用。我更習慣按照「威脅實際打進來的順序」來組織，因為它同時告訴你該先修哪一項。

層次	主要威脅	這一層擋得住	這一層擋不住
登入層	暴力破解、憑證填充、被竊取的密碼	猜密碼、重複使用密碼造成的連鎖失守	外掛漏洞造成的直接入侵
更新層	已公開的外掛／主題／核心／PHP 漏洞	絕大多數自動化掃描器使用的已知漏洞	尚未修補的零日、被植入惡意碼的更新
權限層	權限過大、帳號共用、後台檔案編輯	入侵後的擴散範圍與造成的損害	入侵本身
邊界層	惡意流量、已知攻擊模式、機器人	大量低階攻擊，並減輕主機負載	合法憑證登入、應用邏輯層面的錯誤設定

這張表最重要的是右邊那一欄。每一層都有它擋不住的東西，這也是為什麼「裝了某個外掛就安全了」這種說法一定是錯的。如果你才剛決定要自架站、還在評估主機與長期維護成本，可以先看這篇：自架站新手的六個決策：網域、主機、佈景主題與上線後維護該怎麼取捨，安全維護的工作量本來就該算進架站成本裡。

第一層｜登入：暴力破解與憑證填充怎麼防

登入頁是唯一一個「你主動對全世界公開、而且允許重複嘗試」的入口，所以它一定是第一個被打的地方。WordPress 官方把暴力破解描述為最單純的入侵方式：攻擊者不斷嘗試帳號與密碼組合，直到有一組能用。OWASP Top 10:2025 也把這類問題獨立列為 A07 Authentication Failures（OWASP Top 10:2025 A07）。

還有一種比暴力破解更難察覺的情況叫憑證填充：攻擊者拿別的網站洩漏出來的帳密清單，直接來你的站台試。它之所以有效，完全是因為很多人在不同服務用同一組密碼。這種攻擊在你的伺服器紀錄裡看起來就像一次正常的登入，因為它就是一次正常的登入。

密碼：把觀念更新到現在的官方標準

關於密碼，市面上很多教學仍在講「要含大小寫、數字、符號，每三到六個月換一次」。這兩條建議都已經被美國國家標準與技術研究院（NIST）的數位身分指引推翻。NIST SP 800-63B 的規定是：單獨作為驗證因素使用的密碼，長度下限為 15 個字元；若搭配多因素驗證則下限可放寬到 8 個字元；驗證方應允許至少 64 個字元；不得再強制其他組合規則；也不得要求使用者定期更換密碼，只有在有證據顯示該憑證已遭洩漏時才強制變更（NIST SP 800-63B）。

這個轉向的理由很實際：強制組合規則會讓使用者用非常可預測的方式應付它。NIST 在同一份文件裡舉的例子是，本來會選 password 的人，被要求加大寫和數字之後，很可能就變成 Password1。真正有效的是長度與唯一性，而不是符號的花樣。WordPress 官方的建議方向一致：使用長密碼或密語，並使用密碼管理器產生與保存（WordPress 官方：Brute Force Attacks）。

實作上我的做法是：後台管理員帳號的密碼一律由密碼管理器產生，長度拉到 20 字元以上，而且這組密碼只用在這一個地方。因為我自己不需要記它，長度就不再是成本。相對地，我不再設定強制換密碼的排程，改成在收到任何洩漏通知時立刻更換。

兩階段驗證：WordPress 核心不內建，必須自己補

一個很多人不知道的事實：WordPress 核心並不內建兩階段驗證，必須透過外掛或外部身分提供者（SSO／IdP）加上去（WordPress 官方：Two Step Authentication）。官方建議所有管理員與高權限帳號都應啟用，方式可以是 TOTP 驗證器 App、硬體金鑰，或以簡訊作為備援。

官方文件也提到更進一步的選項：passkeys（WebAuthn）可以用 Face ID／Touch ID／Windows Hello 或安全金鑰做到抗釣魚的無密碼登入，並建議每位管理員至少註冊兩個驗證器，以免其中一個遺失就把自己鎖在外面。OWASP 的多因素驗證指引同樣強調要規劃備援與復原途徑，否則 MFA 本身會變成可用性風險（OWASP Multifactor Authentication Cheat Sheet）。

如果你有外部工具需要用 API 存取你的站台（例如自動發文、備份服務、行動 App），官方的建議是使用 WordPress 5.6 開始提供的應用程式密碼（Application Passwords）。它的好處是可以單獨撤銷，不必因為換掉一個整合就重設你的主帳號密碼。

限制登入嘗試：擋在哪一層決定你付多少代價

限制登入嘗試次數是常見做法，但它擋在哪一層差別很大。WordPress 官方明確建議優先在邊緣（CDN／WAF）或網頁伺服器層做速率限制，因為應用層外掛仍然是在 PHP 裡執行，遭到大量攻擊時本身就會消耗你的伺服器資源。官方原文的建議是讓惡意流量在抵達你的伺服器之前就被擋掉。

這件事在小型主機方案上特別有感：一次分散式的登入嘗試風暴，可能不是讓你被入侵，而是讓你的 PHP 處理程序被吃光、網站變成 5xx。也就是說，登入層的防護同時是一個效能問題。

另外一個常被忽略的登入面是 xmlrpc.php。官方指出它是暴力破解的常見目標，尤其是 system.multicall 這個方法；如果你完全不需要用到 XML-RPC，就把它關掉，若因為 Jetpack 或行動 App 而必須保留，則應該以 WAF 規則限制並嚴格做速率限制。

改掉或隱藏登入網址：誠實說它的效果與局限

把 /wp-login.php 改成別的路徑，是台灣很多教學會放在第一條的建議。WordPress 官方對這件事的定位很清楚：隱藏登入網址可以減少雜訊，但不該作為你唯一的防線。我完全同意這個講法，而且會再補三點實際經驗。

1. 它降的是雜訊，不是風險。掃描器打不到預設路徑，你的紀錄會乾淨很多、伺服器負載也會下降，但只要有人真的針對你的站台，路徑本身並不難被推測或從其他線索得知。
2. 它會帶來相容性成本。部分外掛、行動 App、自動化整合仍會呼叫預設路徑；改路徑之後這些功能可能安靜地失效，而你要花時間才會發現。
3. 它會製造自己把自己鎖在外面的風險。新路徑要記在密碼管理器裡，並確保你在只有手機的情況下也能找到它。

所以我的順序是：先做長密碼加兩階段驗證，再做邊緣速率限制，最後才視情況考慮改路徑。把順序倒過來做，是把最省力的一步當成主要防線。順便提醒一個常被忘記的環節：如果你經常在咖啡廳或共享空間用公共網路登入後台，網路端的風險也要一起處理，這部分我整理在在咖啡廳與共享空間工作：選點、設備、公共 Wi-Fi 資安與禮儀全指南。WordPress 官方的加固文件也把「兩端的網路都必須可信」列為前提之一，並直接點名在不加密的網路上傳送密碼的環境不算可信網路（WordPress 官方：Hardening WordPress）。

第二層｜更新：為什麼過時外掛是最大的破口

如果只能做一件事來降低被入侵的機率，我會選「把外掛與主題維持在最新版，並刪掉不用的」。原因是：外掛與主題就是你網站的軟體供應鏈，而供應鏈是目前公認最嚴重的網頁應用風險之一。OWASP Top 10:2025 把「軟體供應鏈失效」列在 A03，並說明它在社群調查中被整整 50% 的受訪者排在第一名；對應的 CWE 包含 CWE-1104「使用未維護的第三方元件」與 CWE-1395「依賴有漏洞的第三方元件」（OWASP Top 10:2025 A03）。

這裡有個容易誤解的地方：漏洞被公開修補的那一刻，反而是風險最高的時候。修補公告會說明問題在哪，掃描器隨即開始尋找還沒更新的站台。所以「等一陣子再更新，比較穩」這個直覺，在安全性更新上是站不住腳的；真正該小心的是功能性大版本更新。

核心、外掛、主題、PHP：四種更新的取捨不同

WordPress 官方安全團隊會為修補版本（bugfix release）發布修正，並且作為額外服務把修正回溯到舊版本，讓舊站也能透過自動更新收到重要安全修正。核心的次要版本自動更新是預設開啟的，也是我唯一建議「無條件全開」的一項。如果你需要調整範圍，官方提供 WP_AUTO_UPDATE_CORE 常數來控制哪些類型的核心更新要自動套用（WordPress 官方：Upgrading WordPress）。

更新對象	建議做法	代價／風險
核心次要版本（安全與修錯）	維持自動更新開啟	幾乎沒有；官方會回溯修正到舊版
核心主要版本	備份後手動更新，或延後數週	可能與舊外掛不相容
外掛（安全性更新）	盡快更新，重要站台先在測試環境跑一次	破版風險；沒有備份就不要在正式站直接試
頁面編輯器等大型外掛	看更新日誌再決定，避開改版初期	版面走位的機率相對高
主題	使用子主題，避免自訂被覆蓋	直接改父主題檔案的站台會遺失修改
PHP 版本	維持在官方仍提供支援的分支	舊外掛可能不相容，切換前需測試

PHP 的支援週期是有明確規則的：每個發布分支自穩定版起有兩年的完整支援，之後再有兩年只處理重大安全問題，總計四年後進入生命週期結束。以官方頁面公告為準，PHP 8.2 的安全性支援截止於 2026 年 12 月 31 日，8.3、8.4、8.5 則分別延後一至三年（PHP：Supported Versions）。跑在已經 EOL 的 PHP 版本上，等於是把一整層系統軟體暴露在沒有修補的狀態。

怎麼判斷一個外掛已經停止維護、該汰換了

「過時」不只是指你沒按更新，也包含作者已經不再維護。判斷的依據不需要猜，WordPress.org 的外掛頁面上就有幾個可查的訊號。官方文件說明外掛的 readme 標頭包含 Requires at least 與 Tested up to，而自 WordPress 5.8 起 Requires PHP 與 Requires at least 改由外掛主程式檔解析（WordPress 官方：Plugin Readmes）。這些欄位會直接反映在目錄頁上，你可以據此判斷作者是否還在跟上核心版本。

1. 看最後更新時間與相容版本標示。長期沒有更新、標示的相容版本落後現行核心好幾個大版本，是明確的警訊。
2. 看支援論壇的回覆狀況。近期問題全部沒有回覆，通常代表作者已經離開。
3. 看外掛頁面是否出現關閉或無法下載的提示。被官方目錄關閉的外掛不會再收到更新，但它仍然留在你的站上執行。
4. 盤點它到底提供什麼功能。很多舊外掛的功能已被核心或你正在用的主題內建，這是最好的汰換機會。
5. 找替代品並在測試環境驗證。先確認資料能不能帶走，再決定停用順序。
6. 停用之後要真的刪除。只停用不刪除，檔案仍然留在伺服器上，這是很多人漏掉的一步。

選主題的時候，維護狀況其實比外觀重要，這點我在WordPress 佈景主題推薦 2026：免費與付費主題怎麼選（含速度考量）裡有比較完整的比較。如果你的站台重度依賴頁面編輯器，更新前務必先確認編輯器與擴充套件的版本搭配，這類組合是最常在更新後出現版面異常的地方；編輯器本身的基本操作可以參考Elementor 新手教學：從安裝到做出第一個頁面的完整步驟。

第三層｜權限：角色、檔案權限與停用檔案編輯器

權限層的價值不在於防止入侵，而在於限制入侵發生後對方能做到什麼程度。同一個被盜的帳號，是管理員還是投稿者，後果差距非常大。

使用者角色：預設就給最小夠用的權限

WordPress 內建的角色由高到低是超級管理員（多站網路才有）、管理員、編輯、作者、投稿者、訂閱者，每個角色對應一組明確的能力清單，例如安裝外掛、切換主題、編輯他人文章都是可以逐項對照的（WordPress 官方：Roles and Capabilities）。實務上的原則很簡單：能用作者權限完成的工作，就不要給管理員。

對象	建議角色	理由
你自己（站主）	管理員	唯一或極少數的管理員帳號，並啟用兩階段驗證
長期合作的內容主編	編輯	可管理所有文章，但不能安裝外掛或改主題
外包寫手	作者或投稿者	只需處理自己的稿件；投稿者不能發布
短期協助的工程師	管理員（結案後立即移除）	用獨立帳號，不要共用你的帳號
只需要看數據的人	不必給後台帳號	用分析工具的檢視權限即可

另外兩個習慣同樣重要：一是不要共用帳號，共用帳號會讓你在事後完全無法判斷是誰做了什麼；二是定期清理使用者清單，把結案的合作對象、離職的同事、測試用帳號刪掉。如果你的站台會給客戶開帳號預覽作品或提案，這件事更該固定做，相關情境我在接案作品集網站怎麼做？沒有大案子也能談到客戶的 Portfolio 實作裡有提到。

檔案權限：官方建議的合理數值

檔案權限的原則是能鎖多緊就鎖多緊，只在真的需要寫入時才放寬。WordPress 官方給的一般原則是：目錄 755 或 750、檔案 644 或 640；官方也說明當 WordPress 執行自動更新時，所有檔案會被設為 0644、所有目錄設為 0755，只有擁有者可寫、其他人（包含網頁伺服器）可讀（WordPress 官方：Changing File Permissions）。

但這裡有一個必須先說清楚的前提：官方同一份文件開頭就註明「權限會因主機而異，本指南只提供一般原則，無法涵蓋所有情況」，並特別點出使用 suexec 的共享主機（很多台灣主機商就是這種架構）適用的規則不同；另外如果 WordPress 是以 FTP 帳號身分執行、需要群組寫入權，官方也說明權限會比預設更寬鬆（例如目錄 775、檔案 664）。所以 755／644 是起點與檢查基準，不是照抄就一定對的答案——如果你沒有遇到權限錯誤，官方甚至直接建議不要去動它；真的要調整之前，先問你的主機商在他們的環境下正確值是什麼。

比較特別的是 wp-config.php。官方建議確保只有你和網頁伺服器能讀取這個檔案，通常意味著 400 或 440 的權限。至於把 wp-config.php 移到網站根目錄之上這個做法，官方文件本身就註明社群意見不一致：有人認為安全效益有限，若處理不當甚至可能引入更嚴重的問題。看到官方文件都寫「有人主張、有人不同意」的做法，就別把它當成必做項目。

另外一個要避開的地雷是 777。任何教學叫你把目錄設成 777 來解決上傳失敗，那都是在用擴大權限掩蓋設定問題，正確做法是處理擁有者與群組的歸屬。

停用後台檔案編輯器：一行設定，價值很高

WordPress 預設允許管理員在後台直接編輯外掛與主題的 PHP 檔案。官方文件對這件事的說法值得完整理解：這往往是攻擊者取得登入權限後使用的第一個工具，因為它允許執行程式碼。這段判斷出自官方的加固文件，原文是「This is often the first tool an attacker will use if able to login, since it allows code execution」。官方提供的關閉方式是在 wp-config.php 加入下面這行，效果等同於移除所有使用者的 edit_themes、edit_plugins、edit_files 能力（見 WordPress 官方：Hardening WordPress 與 WordPress 官方：Editing wp-config.php）：

define( 'DISALLOW_FILE_EDIT', true );

它的代價是你以後要改主題檔案得走 FTP／SFTP 或版本控制。對一個平常不改程式碼的內容站來說，這個代價幾乎是零，而它拿掉的是一條「登入之後直接在後台貼上程式碼」的捷徑。但要照官方的話說完整：這個常數並不會阻止攻擊者用其他方式上傳惡意檔案，它只是移除了後台編輯器這一個入口，所以它是減少手段、不是關上門。如果你的站台完全不需要在後台安裝或更新任何東西，還有更嚴格的 DISALLOW_FILE_MODS 可以考慮，但那會連外掛安裝與更新一起禁掉，除非你有另一套部署流程，否則不建議一般站台使用。

第四層｜邊界：WAF、CDN 與主機層的分工

邊界層是最容易被過度期待的一層。WAF（網頁應用防火牆）的本質是規則比對：它認得已知的惡意模式並攔下來，效率很高，但它不理解你的商業邏輯。WordPress 官方安全團隊確實會與大型主機商與安全廠商合作發展 WAF 阻擋規則，這代表 WAF 在生態系裡是有實質作用的一環，但它的角色是「減少抵達應用層的惡意流量」。

防護位置	擋得住什麼	擋不住什麼	資源消耗
CDN／邊緣 WAF	大量機器人、已知攻擊特徵、登入速率限制	用正確帳密的登入、來源合法的請求	不消耗你的主機資源
主機／伺服器層	IP 封鎖、路徑層級的速率限制、伺服器模組規則	應用層的權限與設定錯誤	消耗伺服器資源但不進 PHP
PHP 安全外掛	檔案變更監控、惡意碼掃描、登入節流、通知	重負載下自身即成為負擔	每一次攔阻都要執行 PHP
應用層設定（權限、角色、常數）	入侵後的損害範圍	入侵本身	幾乎為零

這張表解釋了一件常見的困惑：為什麼裝了安全外掛之後，遇到攻擊時網站反而更慢、甚至掛掉。官方在暴力破解文件裡就寫明，應用層外掛的節流仍然在 PHP 裡執行，重度攻擊下會消耗資源，因此優先選擇邊緣或伺服器層的節流。安全外掛不是沒有用，它的強項是監控與通知，而不是承受流量。

安全外掛能做什麼、不能做什麼

WordPress 官方的「網站被入侵」FAQ 建議同時使用兩類掃描：安裝在站上的應用層掃描器，以及從外部抓取頁面的遠端掃描器。官方的原話是沒有任何單一方案是最好的，但兩者合用能大幅提高發現問題的機會（WordPress 官方：FAQ My site was hacked）。這句話本身就是對「裝一個外掛就安全」最好的反駁。

要說清楚它的極限：掃描器是靠特徵與啟發式判斷，沒掃出東西不等於乾淨；而站台已經被入侵時，站內掃描器本身的判斷也可能已經被干擾。所以掃描結果應該當成線索，不是結論。

HTTPS 防的是什麼、不防什麼

HTTPS 保護的是傳輸過程：它讓連線內容不被沿路竊聽或篡改，包含你登入後台時送出的密碼。WordPress 官方對於後台走 HTTPS 有專門的設定說明（WordPress 官方：Administration Over SSL），憑證則可以使用免費且自動化的方案（Let’s Encrypt：How It Works）。但 HTTPS 完全不會阻止一個已經被植入後門的網站繼續散布惡意內容——加密的是通道，不是內容的乾淨程度。

監控：讓你比訪客更早知道出事

邊界層還有一個常被忽略的功能：偵測。最實用的免費監控來源是 Google Search Console 的安全性問題報告，它會在 Google 判定你的站台被入侵或散布惡意軟體時通知你（Search Console 說明：安全性問題報告）。Google 也提供惡意軟體與非必要軟體的判定說明（Google Search Central：Malware and Unwanted Software Overview）與預防感染的檢查清單（Google Search Central：How To Prevent Malware Infection）。

另外可以隨手查的是 Google 的安全瀏覽網站狀態查詢頁（Google Safe Browsing 網站狀態）。如果你還沒設定 Search Console，先照這篇做完驗證會讓後面所有事情都好處理：Google Search Console 新手完整教學：從驗證網站到找出可優化關鍵字。流量端的異常同樣是訊號：來源國家突然出現大量陌生流量、或出現你從沒發布過的到達網頁，都值得追查，這類報表的看法可以參考Google Analytics 4 新手教學：安裝、看懂報表到追蹤轉換。

備份為什麼算資安的一部分

備份常被歸類在維運，但在資安的框架裡它有一個無可取代的位置：當網站已經被植入後門、而你無法百分之百確定清乾淨時，一份乾淨的備份是唯一可靠的復原手段。WordPress 官方在事後處理流程裡就把「建立備份」放在清理之前，並提醒即使當下的環境已經受感染，也要再拍一份快照，以免清理過程造成不可回復的損壞（WordPress 官方：FAQ My site was hacked）。官方另有專門的備份說明頁面（WordPress 官方：Backups）。

從資安角度只需要記住三件事。第一，備份要能證明可還原——沒有實際還原過一次的備份，你其實不知道它有沒有用。第二，備份不該和網站共用同一組憑證與同一台主機，否則同一次入侵就能把備份一起處理掉。第三，保留多個時間點，因為後門可能在你發現之前就已經存在好幾週，只留最新一份等於只留一份已經被污染的版本。

備份的具體實作（工具選擇、排程頻率、還原演練的步驟）不在本文範圍，這裡只確立一件事：沒有備份的網站，等於沒有復原計畫，那麼前面四層防護的意義就只剩「希望不要出事」。如果你在評估這些維運工作要自己做還是外包，成本結構可以參考網站架設費用全解析 2026：自架、找接案、套版平台三種方案的價格與取捨。

被入侵之後：可以照順序執行的處理流程

這一節是我認為最值得寫、卻最少被完整寫出來的部分。順序錯了會造成兩種常見後果：一是把證據和污染狀態一起覆蓋掉，導致永遠找不到攻擊向量；二是清乾淨之前就上線，被 Google 再次標記。以下流程主要依據 WordPress 官方的「網站被入侵」FAQ 與 Google 的入侵網站復原說明整理（Google web.dev：Help, I think I’ve been hacked）。

先確認這是不是入侵

官方文件把可觀察到的入侵跡象稱為 IoC（Indicators of Compromise），列舉的例子包括：站台被 Google 或 Bing 列入黑名單、主機商停用你的網站、網站被標記為散布惡意軟體、讀者反映防毒軟體對你的站台告警、你被通知網站正被用來攻擊其他站台、出現未經授權的行為（例如自己冒出新使用者），或直接用瀏覽器就能看出網站被改。先確定症狀，比急著動手重要，因為症狀決定了處理路徑。

照這個順序做

1. 保持紀錄，寫下時間軸。官方建議入侵後的第一個實際動作是記錄：你看到什麼、幾點發現、時區、最近做過什麼變更（安裝了什麼外掛、改過什麼主題）。這份文件就是事件報告的基礎，無論你自己處理或委外都會用到。
2. 隔離現場。視情況讓站台進入維護狀態或暫時下線，避免繼續傷害訪客與擴大黑名單影響。同時聯絡主機商——如果你用的是共享主機，這次入侵可能不只影響你一個站，主機商也可能已經在處理。
3. 在清理前先拍一份完整快照。包含檔案與資料庫，即使它是受感染的狀態。官方明確建議在進入清理階段之前再留一份環境快照，萬一清理過程出現災難性失敗，你至少還有這份「壞的副本」可以參照。
4. 重置所有存取憑證，範圍要比你想的大。官方點名的存取點包含 FTP／SFTP、後台、主機控制台（cPanel 或同類面板）以及 MySQL；而且不只你自己的帳號，是所有有權限的使用者。密碼一律改成長、複雜且唯一的。
5. 更換 wp-config 的密鑰與 salt，把所有登入中的 session 踢掉。只改密碼並不會讓已經登入的攻擊者掉出來；官方的做法是到 WordPress 的金鑰產生器取得一組新值，覆蓋 wp-config.php 裡對應的值（WordPress 官方金鑰產生器）。這一步很多人漏掉，結果是清理過程中對方還在裡面。
6. 清查使用者清單與角色。找出你不認識的帳號、被提升為管理員的舊帳號、以及信箱被改掉的帳號。官方也提到可以強制全站使用者密碼重設，特別是管理員。
7. 清查排程任務與常被修改的檔案。官方特別點名 .htaccess 是各類感染中最常被改、且可能同時存在於多個目錄的檔案；另外 index.php、header.php、footer.php、functions.php 這幾個檔案一旦被改，會影響所有頁面請求，因此是高風險目標。WordPress 的排程任務清單也要看，後門常靠排程重複復活。
8. 用官方原始檔重置核心。官方的具體建議是：可以安全替換 /wp-admin 與 /wp-includes 兩個目錄，但要用 FTP／SFTP 覆蓋而不是後台的重新安裝功能——因為安裝程式往往只覆寫既有檔案，而入侵通常會新增檔案。同時務必使用與你網站相同的版本，用更舊或更新的版本會直接讓站台壞掉。wp-content（主題與外掛）則要逐項比對，不能一次覆蓋。
9. 掃描網站，也掃描你自己的電腦。官方建議應用層與遠端掃描器並用；並提醒攻擊的起點很可能在你的本機——木馬會在本機竊取 FTP 與後台的登入資訊，所以本機也要做完整的病毒與惡意程式掃描。
10. 確認乾淨之後才還原與上線，然後再改一次密碼。官方特別強調這點：如果你只在發現入侵時改過密碼，清理完成後要再改一次。必要時連資料庫帳號與密碼一併更換，並同步更新 wp-config.php。
11. 更新到最新版本，補齊防護。官方在流程最後要求把 WordPress 更新到最新版，並實施加固建議，否則你只是回到被入侵前的同一個狀態。
12. 向 Google 申請重新審查。在 Search Console 的安全性問題報告中確認範例網址上的問題已經修好，全部修完之後送出審查請求並描述你做了什麼。Google 說明審查可能需要幾天到幾週，所以清理沒做完就送審只會浪費時間。另外要知道 Google 有重複違規的政策：被判定為重複違規（Repeat Offender）的站台，該狀態會維持 30 天，期間無法再次申請審查，要等 30 天過後才能提出（Google Safe Browsing Repeat Offenders Policy）。
13. 做事後鑑識，找出攻擊向量。官方把這一步稱為 forensics：理解對方是怎麼進來的，才能確保同一條路不會被再用一次。如果你缺少足夠的日誌資料，這一步往往做不到——這也是「平常就要留紀錄」的實際理由。

最後一個誠實的判斷：如果你無法確定後門是否已清除乾淨，最保險的做法是建立一個全新的乾淨環境，只把確認乾淨的內容與媒體搬過去，而不是繼續在被污染的環境裡修。官方也承認「全部清掉重來」在某些情況下並不可行，但在你反覆被重新感染時，重建通常比繼續追著後門跑更省時間。

維護節奏：週、月、季各該檢查什麼

安全不是一次性的設定，而是一組固定重複的動作。我的做法是把它壓縮成一份很短的清單，短到不會找藉口不做。以下是我自己在用的節奏，你可以按站台重要性調整頻率。

頻率	要做的事	大約耗時
每週	套用外掛與主題的更新（先確認備份存在）；看一眼 Search Console 有無安全性問題通知	10 分鐘
每週	檢查是否有非預期的新使用者註冊或角色變動	2 分鐘
每月	盤點停用的外掛與主題並刪除；確認每個外掛最近更新時間與相容版本標示	20 分鐘
每月	確認備份確實有產生，並抽驗一次檔案清單	10 分鐘
每季	實際做一次還原演練到測試環境	1 小時
每季	檢查 PHP 版本是否仍在官方支援期內；檢查管理員帳號數量與兩階段驗證狀態	15 分鐘
每年	重新檢視角色與權限分配、清掉不再需要的整合與應用程式密碼	1 小時

要把話說清楚：沒有任何一份清單、外掛或設定可以保證你的網站不會被入侵。這份清單能做到的是讓你落在「攻擊者要花更多力氣」的那一側，並且在真的出事時，把復原時間從幾週壓到幾小時。這兩件事就是實務上安全投資的全部意義。

常見問題（FAQ）

Q1：我的網站很小，真的會有人攻擊嗎？

會，而且攻擊你的通常不是人，是自動化掃描器。WordPress 官方在說明暴力破解時就指出這類攻擊是自動化且經常由殭屍網路分散發動，目標是整個網際網路上所有暴露登入頁的站台，與站台規模無關。被攻破的小站對攻擊者的價值在於可以掛隱藏連結、寄垃圾郵件、放釣魚頁面，或當成攻擊其他站台的跳板。另外還有一個現實面：即使你不在意排名，被 Google 標記惡意軟體之後，訪客會看到警告頁，主機商也可能直接停用你的空間。

Q2：我裝了知名的安全外掛，是不是就安全了？

不是，而且官方文件本身就不支持這種說法。WordPress 官方在事後處理指引裡明確寫著沒有任何單一掃描方案是最好的，建議應用層與遠端掃描器合用才能提高發現問題的機會。安全外掛的強項是監控、檔案變更偵測與通知；它的弱點是遭到大量攻擊時本身在 PHP 內執行，會消耗你的伺服器資源，因此官方建議速率限制優先放在 CDN 或伺服器層。把外掛當成儀表板而不是盾牌，期待值會比較正確。

Q3：密碼需要每三個月換一次嗎？

不需要，現行的官方標準明確反對強制定期更換。NIST SP 800-63B 規定驗證方不得要求使用者定期更換密碼，只有在有證據顯示該憑證已遭洩漏時才強制變更；同一份文件也規定不得強制大小寫與符號的組合規則，並要求單因素使用的密碼長度下限為 15 個字元。實務上更有效的組合是：用密碼管理器產生一組長且唯一的密碼、對所有管理員帳號啟用兩階段驗證，然後在收到洩漏通知時立即更換。

Q4：把後台登入網址改掉有用嗎？

有用，但它降低的是雜訊而不是風險；WordPress 官方的定位是「可以減少雜訊，但不該是你唯一的防線」。改路徑之後你會看到登入嘗試的紀錄大幅減少、伺服器負載下降，這是真實的好處。但它的代價是相容性問題（部分外掛、行動 App、自動化整合仍會呼叫預設路徑而安靜失效）以及把自己鎖在外面的風險。正確的順序是先做長密碼與兩階段驗證，再做邊緣速率限制，最後才視情況考慮改路徑。

Q5：被 Google 標記為惡意網站，多久可以恢復？

要看清理速度，而 Google 說明審查本身可能需要幾天到幾週。流程是：在 Search Console 的安全性問題報告中確認每一個列出的問題都已修好、在範例網址上驗證，然後送出審查請求並具體描述你做了什麼修正。要特別注意 Google 的重複違規政策：如果站台被判定為重複違規，該狀態會維持 30 天，這段期間無法再次申請審查。所以「先確認真的清乾淨、再送審」不只是嚴謹，而是避免把時間成本放大好幾倍的必要做法。

Q6：免費的 SSL 憑證安全嗎？HTTPS 是不是就等於網站安全？

免費憑證在加密強度上與付費憑證沒有差別，但 HTTPS 和「網站安全」是兩件不同的事。HTTPS 保護的是傳輸過程，讓連線內容（包含你登入後台送出的密碼）不被沿路竊聽或篡改，這也是 WordPress 官方針對後台走 HTTPS 提供專門設定說明的原因。但如果站台已經被植入後門，HTTPS 只會讓惡意內容以加密的方式傳送給訪客。加密的是通道，不是內容的乾淨程度。

延伸閱讀

• 自架站新手的六個決策：網域、主機、佈景主題與上線後維護該怎麼取捨
• WordPress 佈景主題推薦 2026：免費與付費主題怎麼選（含速度考量）
• Google Search Console 新手完整教學：從驗證網站到找出可優化關鍵字
• 網站架設費用全解析 2026：自架、找接案、套版平台三種方案的價格與取捨
• 在咖啡廳與共享空間工作：選點、設備、公共 Wi-Fi 資安與禮儀全指南

💡 延伸閱讀｜安全性有很大一部分取決於主機層提供了什麼（自動更新、WAF、備份保留天數）。挑主機時可以一併對照這份WordPress 虛擬主機推薦 2026：新手架站 5 大主機商比較與選擇指南。