根據 wpdeveloper 與 seahawkmedia 在 2026 年初引用的安全報告，過去一年被入侵的 WordPress 站當中，有超過九成在事發當下都還跑著沒更新的外掛或主題。這個數字不算新鮮，但每年都重新驗證一次，意思很清楚——維護不是技術問題，是節奏問題。

問題是節奏這件事，站長一個人在後台逐項處理，很容易漏。今天記得更新外掛，下週忘了驗證備份；月初測完表單，季底才發現有半年沒清資料庫。WordPress 7.0 在 2026 年 5 月正式釋出後，後台導入了資料視圖（DataViews）與命令選單（Command Palette），介面變得更現代，但維護要做的事一件也沒少，反而因為新的人工智慧連接器與即時協作功能多了幾個檢查點。

與其每次想到才做，不如把固定動作排成週、月、季三層節奏，搭一份可勾選的範本貼在後台或專案管理工具裡，照表操課。一份寫得清楚的 WordPress 維護清單，至少能省掉一半「我上次是不是做過了」的腦力負擔。

為什麼一份寫下來的清單比腦中的待辦有用

維護動作分散在後台不同位置，更新在儀表板、備份在外掛、表單在前台、資料庫在工具列底層，光是切換頁面就會打斷思路。腦中記得「該做的事大概有十幾件」跟「桌上有一份十六項的清單可以一條一條打勾」，完成率的差距很大。

實際運作上，沒有寫下來的維護有三個常見的失敗模式。一是動作頻率混淆，本來該每週做的事拖到每月，每月該做的拖到半年；二是責任邊界模糊，多人共管時誰負責更新、誰負責驗備份講不清；三是事後追溯困難，網站出問題想回頭查上次什麼時候動過什麼，沒有紀錄就只能用猜的。

寫成清單的另一個好處是可以授權。站長本人不必每件事都親自做，把週清單交給行政同事、月清單交給開發外包，季清單留給自己審視，分工才有依據。後面幾節會把這三層攤開來，每一層該做什麼、為什麼這個頻率、判斷標準在哪。

每週要照表跑完的五個固定動作

每週動作大約 20 至 30 分鐘可以做完，重點是頻率穩定，不是單次做得多徹底。挑一個流量相對低的時段（多數中文站台是週二或週三上午），把以下五項列成固定行程。

• 核心與外掛更新檢視：登入後台儀表板看更新中心。WordPress 核心小版本（如 7.0.1、7.0.2）通常含安全修補，可開自動更新；外掛更新一次裝一個，裝完打開前台首頁、文章頁、表單頁各看一眼確認沒壞版面。主題更新若有客製過子主題，先在測試站試完再上正式站。
• 備份驗證：跑備份的人很多，真的去下載備份檔解壓檢查的人很少。每週至少抽一份最近的備份，把資料庫匯出檔（.sql）打開確認檔案大小合理（不是 0 KB 也不是只有空表），再隨機抽一張上傳圖檢查能不能正常開啟。雲端備份要確認本週的檔案有寫進去。
• 垃圾留言與待審清掃：把留言列表與待審佇列清空。垃圾留言外掛（如 Akismet）攔下的不必每則看，掃過寄件者欄位有沒有混到真實使用者誤判即可；聯絡表單收件匣若用 WordPress 內建記錄，也一起檢查有沒有真客戶被當成垃圾。
• 表單與金流送測：自己當客戶填一次主要表單，包含聯絡表單、報名表、購物車結帳（電商站）。送出後確認收信端有收到、自動回覆有寄出、後台訂單或表單記錄有寫入。SMTP 服務商若用第三方（如 SendGrid、Mailgun），順手看一下本週寄送額度與退信率。
• 訪客錯誤頁面巡檢：打開 Google Search Console 的「網頁」報表，看新增的 404 與 410。新出現的 404 若是內部連結手誤打錯，當週就修；若是外部站點連過來的舊網址，評估要不要做 301 轉址。

這五項的優先序若必須砍，更新與備份驗證不能省，其餘三項忙起來可以隔週一次。但隔週的代價是壞掉的表單可能讓客戶兩週聯絡不到，自己權衡。

每月節奏該排在哪個工作日才不會卡到正事

每月動作比每週多花約 45 分鐘到 1 小時，建議排在月底最後一個工作日下午，或月初第二週的週二，避開報表結算與週一的會議高峰。一次做完比拆開做順手，因為很多動作（如資料庫最佳化、效能測速）彼此有前後因果，分開做反而要重複觀察。

資料庫最佳化與瘦身

文章修訂版、自動草稿、過期暫存、孤兒中繼資料每天都在累積。月底用資料庫最佳化外掛（如 WP-Optimize）跑一輪清理，重點清三類資料，分別是超過 90 天的文章修訂版、已標記為垃圾或已刪除的留言、過期的暫存資料表（transients）。

清完之後看一下 WordPress 健康狀態工具（工具 → 網站健康），自動載入資料量若超過 800 KB 會出現警告，這時要回頭找哪個外掛塞了過大的選項到 wp_options 表，常見的元兇是長期未停用的快取或表單外掛留下的舊資料。

速度與核心網頁指標測速

用 Google PageSpeed Insights 或網站健康報告測首頁、最熱門的兩到三個內頁、結帳頁（電商站），記錄行動版的最大內容繪製（LCP）、互動就緒延遲（INP）、累積版面位移（CLS）三項數據，再對比上個月有沒有惡化超過 10%。

惡化的常見原因有圖片沒壓縮、新裝的外掛載入額外的 JavaScript、CDN 設定異動。先觀察一個月再決定要不要動，單月波動不一定是真退步。

外連與內連掃描

整站外連用斷鏈檢查外掛或第三方工具（如 Ahrefs、Screaming Frog 免費版）掃過。失效外連對 SEO 與閱讀體驗都是扣分，發現後依重要性處理，重要參考來源換新連結，次要連結可考慮拿掉。內部連結若有改 slug 沒設 301 的，也在這個階段補上。

安全與惡意程式掃描

用安全外掛（如 Wordfence、Sucuri）跑完整掃描，看本月有沒有檔案被異動、有沒有外部漏洞警告。重點看核心檔案完整性（core file integrity）那一段，被改過就要追為什麼。登入記錄裡看有沒有來自陌生國家的失敗嘗試集中爆量，有的話考慮加裝登入次數限制。

每季要做的深度盤點

季清單一年只跑四次，每次大約半天到一天。動作密度低但深度高，目的是把日常維護摸不到的地方翻一翻。

• 後台帳號與權限審視：把使用者列表攤開，離職員工、過期外包、不再合作的廣告代理商一律降權或刪除。剩下的帳號核對角色，編輯權限只給真的需要編輯的人；管理員帳號控制在三個以內，多餘的改成編輯者。順便檢查每個管理員有沒有開兩階段驗證。
• 外掛瘦身與替代評估：把「啟用中但本季未真正使用」的外掛列出來。長期沒用又佔資源的（如已停用的舊版聯絡表單、過去活動才用的抽獎外掛）刪除而非停用；功能重疊的（同時裝了兩款快取或兩款 SEO）擇一保留。每多一個外掛就多一個攻擊面與更新負擔。
• 主題與版本相容性：核對目前主題與外掛是否支援當前 WordPress 與 PHP 版本。WordPress 7.0 已要求 PHP 8.1 以上，仍跑 7.4 的站要排升級。客製過的子主題每季用程式碼差異工具比對母主題更新，把母主題的安全修補同步進去。
• SEO 結構化資料校對：用 Google 複合式搜尋結果測試工具（Rich Results Test）跑首頁、分類頁、文章頁各兩到三筆。結構化資料（Schema）若報錯，多半是外掛升級後欄位名稱變動或自製樣板沒同步更新。順便看 Search Console 的索引覆蓋率與核心網頁指標季趨勢。
• 災難演練：找一個測試環境（本地、子網域或主機商提供的臨時環境），用上個月的備份檔做一次完整還原，從匯入資料庫、上傳檔案到驗證前台都跑完。沒演練過的備份等於沒有備份，真的出事才發現備份損毀的站長每年都有。

季盤點之後，回頭修一次清單。新出現的外掛、新接手的合作對象、新冒出來的失效流程都要寫進去，下一季才不會重蹈覆轍。

三層節奏一張表看完

把週、月、季三層放在一起對照，比較容易抓住每件事的頻率與所需時間，也方便分配給不同人。

表內所列耗時是中型內容站（百到千篇文章）的參考值，電商站乘 1.5、千篇以上的內容站乘 2。執行者欄位的分工是建議起點，單兵作業的個人站長就全部自己承擔，但至少要知道哪幾件可以在預算允許時外包。

讀這張表的順序建議由上往下，每週做的不能省，每月做的盡量別漏，每季做的就算晚一兩週也沒事，但別跳過一整季。

非技術站長最常漏掉的三個環節

照表操課最容易中斷的，反而不是會被外掛提醒的更新，而是沒人提醒的軟性檢查。最常被漏掉的是備份「驗證」這個動作，跑備份這件事多數人有做，但很少人去開檔案確認內容能還原，直到出事那天才發現備份檔損毀或只備到一半。每週花 5 分鐘下載抽檢，是維護動作裡單位時間報酬最高的一項。

另一個容易忽略的是帳號權限。WordPress 後台預設角色設計得很細，但站長交接、外包異動、員工離職時，多數人只把人移除卻沒處理掉那組帳號還掛在管理員權限上。每季把使用者列表打開掃一次，比裝任何防駭外掛都實際。

最隱形的漏點是表單測試。聯絡表單、報名表、訂單表單一旦壞掉，客戶不會主動告知，他會直接離開。許多站長的表單其實已經壞了好幾個月，是某天客戶打電話進來抱怨才發現。每週送一筆測試資料的成本極低，能擋掉的客訴與生意損失極高。

清單寫完只是第一步，真正能跑得下去的 WordPress 維護清單，是貼在後台看得見的地方、定期被翻閱、每季被修訂的那一份。把節奏建起來，後面就是慣性接手。