網站開到一半，某篇文章的標題被改掉、一個外掛被停用、首頁的設定跑掉了，問了一圈，三個有後台權限的人都說不是自己動的。這種「找不到人負責」的場面，在多人共用 WordPress 後台的網站裡幾乎每隔一陣子就會上演一次。問題不在於同事不誠實，而在於 WordPress 預設根本沒有替你把「誰、在什麼時間、改了什麼」記下來，等到出事才回頭追，線索早就消失。
後台活動日誌稽核，講白了就是替網站裝一台行車記錄器。它把每一個登入、每一次內容修改、每一個設定變動都標上時間、帳號與來源 IP，事後要追責、要還原、要交代給客戶或主管時，攤開紀錄就有答案。這篇會把這件事拆清楚：WordPress 內建到底記了什麼、沒記什麼，活動日誌補上哪些缺口，一筆紀錄該怎麼讀，保留多久才合理，以及多人團隊要怎麼把它變成一套真正能用的問責流程，而不只是裝個外掛擺著。
WordPress 內建紀錄到底記了什麼，又漏了什麼
先講結論：WordPress 原生只替「文章與頁面的內容」留了修訂紀錄（Revisions），其餘的帳號、權限、外掛、佈景主題、網站設定，預設一律不留任何軌跡。
修訂紀錄確實好用。打開任何一篇文章的編輯畫面，右側都看得到「修訂版本」，點進去能逐字比對前後差異、看出是哪個帳號在哪個時間存的檔，也能一鍵還原到舊版本。對於「正文被改壞了想救回來」這個場景，它已經夠用。
問題是它的守備範圍非常窄。下面這些動作，修訂紀錄完全不會記：
- 有人停用了某個外掛、或更新了佈景主題
- 有人把一個訂閱者的角色升成了編輯
- 有人改了網站標題、永久連結結構、或佈景主題的自訂設定
- 有人刪掉了一整篇文章（連同它的修訂紀錄一起消失）
- 有人嘗試登入失敗了二十次，或某個帳號從陌生的 IP 登入成功
- 有人改了 WooCommerce 的金流或運費設定
換句話說，內建機制只能回答「這篇文章的字怎麼變的」，沒辦法回答「我的網站整體被誰動過什麼手腳」。多人協作真正會吵起來的，恰恰是後面這一類設定與權限的變動——它們影響整站，卻偏偏是內建工具的盲區。這個缺口，就是活動日誌要補上的地方。
活動日誌會替你記下哪些事
一套完整的活動日誌，目的是把網站後台所有「有後果」的動作都留下一條可查的軌跡。它記錄的範圍遠比修訂紀錄廣，常見會涵蓋以下幾類事件。
內容類：建立、編輯、發佈、刪除文章與頁面，標題、內文、網址、分類、自訂欄位的變更，以及狀態切換（例如從草稿改成發佈、或退回草稿）。
帳號與權限類：新增使用者、刪除使用者、修改角色、變更密碼或電子郵件、變更顯示名稱。這一類最該盯緊，因為惡意者拿到後台後，第一件事往往就是新增一個自己的管理員帳號，或把既有帳號的權限偷偷升級。
登入類：成功登入、登出、登入失敗。同一個 IP 在短時間內出現大量登入失敗，通常是有人在嘗試暴力破解；陌生 IP 登入成功，則可能是帳號已經外洩。
外掛與佈景主題類：安裝、啟用、停用、更新、刪除。網站突然出現相容性問題或白畫面時，先翻這段日誌，往往一眼就能看出是哪個外掛在什麼時間被動過。
系統設定類：WordPress 一般設定、永久連結、佈景主題自訂、選單，以及第三方外掛（如 WooCommerce、Yoast SEO、表單外掛）的設定變更。
每一筆紀錄通常都帶有四個關鍵欄位：操作的帳號（誰）、精確的時間戳記（什麼時候）、動作的描述（做了什麼，好的工具還會標出改動前後的差異），以及來源 IP 位址（從哪裡來，進階版本還能對應到地理位置）。這四項湊齊，才構成一條能拿來追責、能拿來核實的完整軌跡。
一筆日誌紀錄該怎麼讀，才能還原一次事件
光有紀錄不會自己說話，重點是看到一筆紀錄時，你能不能順著它把整件事拼回來。日誌真正的價值不在於「記了」，而在於出事時你能不能在五分鐘內查清楚。
假設某天早上你發現首頁少了一個區塊，這時打開活動日誌，合理的查法是這樣的：先用時間範圍把昨天傍晚到今早的紀錄篩出來，接著用事件類型過濾，只看「頁面編輯」與「佈景主題自訂」這兩類。你會看到一筆紀錄寫著某帳號在昨晚十點修改了首頁、改動了某個區塊的內容。點開那筆紀錄看前後差異，確認就是這個變動造成的，再對照那個帳號當時是從哪個 IP 登入——如果 IP 是同事家裡的固定線路，那多半是一次無心的誤操作，找他確認、用修訂紀錄還原即可；如果 IP 來自完全陌生的地區，那性質就不同了，要立刻改密碼、檢查那個帳號還做了哪些事。
這套「先篩時間、再篩事件類型、然後看改動差異、最後對照來源」的查法，適用於幾乎所有的後台事件追查。多人團隊最常見的爭執——「這不是我改的」——在這套流程下沒有模糊空間：紀錄上掛的是哪個帳號，責任就指向哪個帳號的持有人。它的意義不是為了懲罰誰，而是讓「無心之過」和「有人入侵」這兩種完全不同的狀況，能在第一時間被分辨出來。
活動日誌要保留多久才合理
多數活動日誌外掛預設的保留期限落在三到六個月，這個長度對一般網站夠用，但實際該設多久，取決於你的網站性質與所受的規範。
保留太短，等於白記。等到客戶三個月後才反映某個設定被改錯，紀錄已經被自動清掉，追也追不回。保留太長，紀錄會持續堆進資料庫，量大時可能影響查詢速度，也可能不必要地累積一堆含有個人資料的舊紀錄。常見的拿捏方式是這樣：
- 一般部落格或公司形象站：六個月通常足夠，能涵蓋大部分事後才被發現的問題。
- 電商或會員網站：建議拉長，並考慮把舊紀錄轉存到外部資料庫保管。這類網站涉及交易與個資，一旦發生爭議，往往需要回溯較久之前的紀錄；同時資料量大，留在主資料庫裡會拖累效能，外部存放反而更穩。
- 受合規要求的網站：若業務需遵循特定稽核或資安規範，保留期限就不是自己說了算，得依規範要求設定，這種情況通常會直接導向付費版本提供的長期保留與外部匯出功能。
免費版外掛在這裡會碰到天花板。多數免費版本只提供有限的保留期間與基本的事件類型，要做到不限時長的保留、把紀錄匯出到外部資料庫或專業的日誌管理服務、以及更細的篩選與報表，通常得升級到付費版。先想清楚自己需要追溯多久，再決定免費版夠不夠，比裝了才發現紀錄被清掉要實際得多。
在台灣記錄這些資料，要注意個資與隱私
活動日誌會記下使用者的帳號、電子郵件、來源 IP 位址，這些在台灣《個人資料保護法》的框架下，多半屬於個人資料的範疇，留存與使用都要有正當性，不能無限上綱地蒐集與保存。
這件事在多人協作的網站上尤其要留意。你記錄的不只是外部訪客，還包括有後台權限的同事與合作廠商，他們的登入時間、來源 IP 同樣會被記下來。合理的做法是：把蒐集這些紀錄的目的講清楚（用於資安稽核與問責），讓被記錄的成員知情；保留期限設得有節制，不要為了「以防萬一」就無限期堆著；以及在帳號註銷或合作結束時，依需要清理不再需要的舊紀錄。日誌是為了釐清責任而存在，不是拿來監視個人的工具，分寸抓對了，它才站得住腳。
誰能看這份日誌，又該被即時通知什麼
日誌本身也需要被保護。預設情況下，活動日誌只有管理員角色看得到，這是合理的設計——日誌裡有所有人的操作軌跡與 IP，不該攤開給每個編輯或作者瀏覽。
但「只有管理員能看」在某些情境下要再調整。如果你的網站是一位管理員加多位編輯的結構，這個預設剛好；如果是多人共管、或有外部資安人員需要查閱，就得在外掛設定裡開放特定角色的檢視權限，同時嚴格控制誰有權「清除」日誌——能刪日誌的人，等於能湮滅自己的軌跡，這個權限要握在最少的人手上。
比事後翻查更進一步的，是即時通知。較完整的工具能設定觸發條件，在關鍵事件發生的當下就寄出警示，例如有人新增了管理員帳號、有帳號從陌生 IP 登入成功、或核心檔案被修改。對多人或交給外部廠商短期維護的網站來說，這層通知特別有價值：你不必每天去翻日誌，等真正危險的動作出現，系統會主動拍你肩膀。把該被盯緊的事件設成即時通知，把其餘的留作事後查詢，日誌才從一份靜態紀錄變成一道主動的防線。
把活動日誌變成團隊真正在用的問責流程
裝好外掛只是第一步，真正讓「誰改了什麼」不再變成羅生門的，是圍繞著日誌建立起來的團隊習慣。工具補上的是技術缺口，流程補上的才是人的缺口。
幾個實際可以落地的做法：
- 一人一帳號，禁止共用。日誌是靠帳號來歸責的，如果三個人共用同一組管理員登入，紀錄上只會掛同一個名字，等於白記。每個成員、每個外部廠商都該有自己的帳號，權限給到剛好夠用就好，作者就別給編輯權限。
- 權限按需分配，事後收回。外部廠商來修一次問題，給臨時帳號、做完就停用或刪除，不要讓一堆閒置的高權限帳號長期掛在後台。日誌能告訴你哪些帳號很久沒動了，定期清理。
- 約定好出事時的查法。團隊裡至少要有人知道前面講的那套「篩時間、篩事件、看差異、對照 IP」的查詢流程，出事時才不會手忙腳亂。
- 定期回看，而不只在出事時才看。每隔一段時間掃一遍日誌，看看有沒有非預期的權限變更、陌生 IP、或沒人記得做過的設定改動，很多潛在問題能在釀成大麻煩前就被攔下來。
回到最開頭那個沒人承認改了首頁的場面。有了活動日誌，那場對話會變得很短：打開紀錄，篩出時間區間，改動掛在哪個帳號上一目了然，接著是還原、是改密碼、還是找人確認，路徑都很清楚。它的價值從來不是抓誰的把柄，而是把「猜測與互相指責」換成「攤開紀錄看事實」。多人協作的網站遲早會遇到一次說不清的變動，差別只在於——到時候你手上有沒有那份能說話的紀錄。如果還沒有，現在就是裝上它、把流程訂下來的時候。