改完一篇文章三個月後，你想知道「上次到底動了哪一段、為什麼動」，翻遍後台卻只看到目前這一版——這是內容運營最常見的盲點。文章修訂版本管理就是要解決這件事：WordPress 其實默默幫你存下了每一次儲存的版本，問題在於多數人只把它當成「誤刪救援」，沒拿它來做改動追溯，也沒搭配一套變更說明的習慣，等到要回頭查、要向同事交代改了什麼時，才發現紀錄一片空白。

這篇會把修訂版本從「救命用的後悔藥」升級成「可追溯的內容更新紀錄」。你會學到版本是怎麼產生與儲存的、怎麼比較與還原、怎麼設定保留數量才不會犧牲追溯能力，以及修訂版本本身做不到的事該怎麼用變更說明補起來。

WordPress 修訂版本是什麼，跟自動儲存有什麼差別

修訂版本（Revision）是 WordPress 在你每次按下「儲存草稿」「發佈」「更新」時，自動在資料庫裡留下的一份完整內容快照。它記錄了當下的標題、內文、摘要，以及是「誰」在「什麼時間」做的這次儲存。這份紀錄是永久的，會一直留著，直到你設定的保留上限把舊版本擠掉，或你手動清掉。

很多人會把它跟「自動儲存」（Autosave）搞混，兩者其實是不同機制：

• 自動儲存：你在編輯器裡打字時，WordPress 每隔約 60 秒在背景存一份暫存，目的是瀏覽器當掉、斷網時救回未存的內容。同一篇文章同一時間只會有一份自動儲存，新的會蓋掉舊的，它不是用來追溯歷史的。
• 修訂版本：只在你主動儲存或更新時才產生，每一次都是獨立一筆、不會互相覆蓋，這才是能拿來回溯「這篇文章一路怎麼改過來」的依據。

換句話說，自動儲存是防意外，修訂版本才是內容更新紀錄的本體。理解這個差別很重要，因為當你想追溯三個月前改了什麼，要找的是修訂版本，不是自動儲存。

修訂版本存在資料庫的哪裡，會不會拖慢網站

修訂版本和正式文章一樣，都存在資料庫的 wp_posts 資料表裡，只是每一筆修訂版本會多佔一個資料列（row），它的 post_type 欄位標記為 revision、post_status 標記為 inherit，藉此跟正式發佈的文章區分開來。autosave 則是用 auto-draft 狀態標記。

這帶來一個常被誤解的問題：修訂版本會不會拖慢網站速度？對「前台訪客」來說幾乎不會，因為訪客看到的永遠是正式版本，瀏覽器不會去撈那些 revision 資料列。真正受影響的是資料庫本身的體積與維運。

舉個量級就懂了：假設一個站有 800 篇文章，每篇累積 100 個修訂版本，光修訂版本就是 8 萬筆資料列。這會讓資料庫備份變慢、佔用更多主機儲存空間，全站搜尋與某些後台查詢也可能變鈍。經營越久、改稿越頻繁的站，這個累積越明顯，WooCommerce 商城尤其容易遇到。

所以修訂版本管理的核心矛盾在這裡：留得越多，追溯能力越完整，但資料庫負擔也越重。後面談保留數量設定時，就是在這兩者之間抓平衡，而不是一味地全部刪光。

怎麼查看與比較修訂版本，看懂哪裡被改了

在區塊編輯器（Gutenberg）裡，打開任一篇文章，右側「文章」面板的「修訂版本」會顯示這篇累積了幾個版本，點下去就進入比較畫面。若你還在用經典編輯器，則是在右側「發佈」區塊找到「修訂版本」旁的瀏覽連結，進去之後的比較畫面兩者一樣。

比較畫面的判讀方式很直覺，預設會把相鄰兩個版本並排對照：

• 左欄（紅底、減號）：這次被刪掉或改掉的舊內容
• 右欄（綠底、加號）：這次新增或改成的內容
• 上方時間軸滑桿：拖動它就能在各個版本之間切換瀏覽，也能用「上一個／下一個」按鈕逐筆移動
• 版本資訊：每個版本都標了修改者帳號與時間，多人協作時能看出是誰在何時動的

如果你要比的不是相鄰兩版，而是任意兩個版本（例如比對「兩個月前」和「現在」差多少），勾選上方的「比較任意兩個修訂版本」，滑桿會分成兩個把手，分別拖到你要對照的版本即可。

要留意一個體驗上的小陷阱：比較畫面顯示的是內容的完整 HTML 原始碼，是為了精準呈現差異，但對長文或排版複雜的文章來說，會夾雜一堆標籤，讀起來不算友善。判讀時把注意力放在紅綠標記的文字差異上，標籤的增減多半是排版調整，不必逐字細看。

怎麼還原舊版本，還原後原本的版本會不會不見

還原的操作很簡單，但有幾個關鍵行為要先弄懂，免得手忙腳亂。在比較畫面取消勾選「比較任意兩個修訂版本」，用滑桿移到你想救回的那一版，按下藍色的「還原這個修訂版本」，系統就會把那一版的內容載回編輯器。

幾個一定要知道的細節：

• 還原不會把目前版本弄丟。你按下還原的當下，原本的最新版會被當成一個新的修訂版本存進資料庫，所以還原是可逆的——還原錯了，再從修訂版本把剛剛那版找回來就好。
• 還原沒有二次確認、也沒有成功提示。按下去就生效了，畫面會直接跳回編輯器、不會跳出「還原成功」的訊息，這常讓人以為沒成功而重複點。還原後不需要再按一次「更新」，它已經套用了。
• 媒體與精選圖片不會跟著還原。修訂版本主要追蹤的是編輯器裡的文字與內容，媒體庫的圖檔不在版本控制範圍。還原舊版文字後，目前設定的精選圖片、已上傳的圖片都維持現狀，不會回到舊的。
• 不能只還原其中一段。WordPress 無法逐段挑著還原，要嘛整版蓋過去。如果你只想救回某一段舊文字，實務做法是進入比較畫面，把那段舊內容反白複製，再貼回目前的版本裡。

正因為「還原沒提示、不能逐段、媒體不跟著走」這些限制，重要改版前養成的習慣比工具本身更關鍵，這也是下一節要談的事。

修訂版本當追溯紀錄的三個侷限，怎麼用變更說明補起來

修訂版本能告訴你「改了哪些字」，卻回答不了內容運營真正在意的「為什麼改、改得對不對」。它本質上是逐字差異（diff），不是有脈絡的變更說明。把它當成完整的內容更新紀錄之前，要先認清三個侷限：

第一、沒有變更原因欄位。修訂版本記錄了誰在何時改了什麼，卻沒有地方讓你寫「為什麼改」。三個月後你看到某段被改寫，卻想不起來是因為讀者回報錯字、是配合法規更新、還是純粹潤稿，追溯就斷在這裡。

第二、不是所有內容都進版本。預設的修訂版本只追蹤標準的內容欄位。WooCommerce 商品為了效能會刻意不走修訂版本機制，所以改商品時你常常根本看不到「修訂版本」區塊；自訂欄位（如 Advanced Custom Fields）與部分頁面建構器（page builder）的資料，預設也不一定被納入。換句話說，你以為版本紀錄完整，實際上一部分改動根本沒被記下來。

第三、清掉就回不來，且常與保留上限衝突。為了控制資料庫體積而限制或刪除舊版本時，被擠掉的歷史就永久消失了，追溯能力也跟著消失。

補救的方向不是跟工具硬拗，而是在修訂版本之外，自己維護一份輕量的變更說明。實務上有幾種做法可以疊加：

• 善用儲存時機當斷點：每完成一個有意義的改動段落（例如「更新了價格資訊」）就按一次更新，讓那次改動單獨成為一個版本，而不是改了十處才存一次。版本切得乾淨，事後比對才看得出脈絡。
• 在內文或內部備註區寫一行變更摘要：可以在文章開頭以草稿註解、或用團隊慣用的內部備註欄位，留下「日期＋改了什麼＋為什麼」一行字。這一行就是修訂版本缺的那塊「原因」。
• 替沒進版本的內容另外記錄：WooCommerce 商品、自訂欄位這類不走修訂版本的改動，改版前先自行截圖或備份對應資料，別指望系統幫你留歷史。
• 遇到頁面建構器先查它的版本支援：每個建構器處理版本歷史的方式都不同，動工前先確認它的改動會不會進修訂版本，不會的話就得靠它自帶的歷史功能或手動備份。

該保留幾個版本，怎麼設定才不犧牲追溯能力

WordPress 預設會無上限地保留每篇文章的所有修訂版本（部分主機商會自行設限），這對追溯最友善，但資料庫會持續長大。設定保留數量的目的，是在「夠用的追溯深度」與「可控的資料庫體積」之間取一個平衡，而不是設得越小越好。

調整方式有兩種，依你的技術熟悉度選一個。

手動設定是在網站根目錄的 wp-config.php 檔案裡加一行常數，數字代表每篇文章要保留的版本上限：

define( 'WP_POST_REVISIONS', 10 );

把 10 換成你要的數字即可。若想完全關閉修訂版本，把值設為 false：

define( 'WP_POST_REVISIONS', false );

要提醒的是，動 wp-config.php 之前務必先完整備份網站，這個檔案改錯會讓整站打不開。關閉修訂版本不影響自動儲存，斷網、瀏覽器當掉時的暫存救援仍然有效。

若不想碰程式碼，可以裝外掛來管理。常見的選擇是 WP Revisions Control，安裝後在「設定」的「寫作」頁面，就能針對每一種文章類型分別設定保留數量，也能針對單篇文章清掉版本。對開發者來說，也能用 wp_revisions_to_keep 這個過濾器做更細緻的條件控制（例如不同分類給不同上限）。

至於保留幾個合適，可以照站台性質判斷：

• 單純的部落格、改稿不頻繁：保留 5 到 10 個通常綽綽有餘，足以涵蓋一次完整改版的前後對照。
• 多人協作、內容常翻修的站：建議保留多一些（例如 20 個以上），因為你更需要追溯「誰在哪一次動了什麼」，這正是修訂版本最有價值的場景。
• 大型站或 WooCommerce 商城：與其把上限設得很大，不如設一個合理數字（如 10 到 15），同時搭配定期清理舊版本，並對真正關鍵的改版另外留變更說明。

設定的邏輯始終是：先想清楚你需要回溯多深的歷史，再回推要留幾個版本，不是先求資料庫最小。

怎麼清理累積的舊版本，又不誤刪到正式內容

如果站已經跑了好幾年、累積了大量舊版本，光設保留上限只能管住未來，存量還是得另外清。清理前有一條鐵則：刪除修訂版本是不可逆的，動手前一定先做完整的資料庫備份。

清理本身很安全，它只移除歷史備份版本，不會碰到目前正式發佈、訪客看得到的那一版內容。常見做法有三種：

• 用資料庫優化外掛（最推薦給一般使用者）：像 WP-Optimize 這類外掛，在資料庫優化頁面勾選「清除所有文章修訂版本」再執行即可，清完可以把外掛停用移除。優點是不用碰資料庫、有清楚的勾選介面。
• 用單篇管理外掛逐筆刪：若你只想清掉特定幾篇、保留其他文章的歷史，可用支援單篇刪除的外掛（如 PublishPress Revisions 提供的管理與批次刪除介面），逐筆檢視後再刪，適合需要精細控制的情況。
• 直接在資料庫下指令（僅限熟悉的進階使用者）：透過主機的 phpMyAdmin 進入資料庫，在 SQL 介面執行刪除 post_type 為 revision 的指令。這個方式風險最高，網路上流傳的語法不見得安全，沒把握就別用，務必先備份。

不論用哪種方式，要記得：清掉現有舊版本不會阻止 WordPress 之後繼續產生新的修訂版本。清理是針對存量，控管增量還是得靠前面說的保留上限設定，兩者要搭配著用。

把修訂版本變成可追溯的更新紀錄，下一步怎麼做

修訂版本不該只是出事時才想到的後悔藥。它是 WordPress 內建、不用額外付費就有的內容更新紀錄系統，只要搭配對的習慣，就能回答「上次改了哪一段、誰改的、什麼時候」這些內容運營一定會遇到的問題。

從今天起可以這樣落地：先確認你的站有沒有開啟修訂版本（部分主機商預設關閉），接著依站台性質設一個合理的保留上限——多人協作就留多一點、單純部落格留 5 到 10 個。針對修訂版本記不到原因、WooCommerce 與自訂欄位不入版本這些侷限，補上一行變更說明、必要時自行備份。最後，把累積已久的舊版本在完整備份後清理一次，之後交給保留上限自動控管。

工具一直都在，差別只在你有沒有把它從「誤刪救援」用成「可追溯的改動紀錄」。