~/blog/wordpress-cron-job-ultimate-guide.md
WordPress 開發與技巧 · 2025 / 12 / 05

WordPress 排程總是在「等風來」？ Cron Job 改造指南，讓網站自動化準時上工！

Eric — 浪花科技創辦人 / AI 架構師
Eric
浪花科技創辦人 · AI 架構師
WordPress 排程總是在「等風來」？ Cron Job 改造指南，讓網站自動化準時上工！
☰ 目錄 table-of-contents.md

快速結論：為什麼你的 WordPress 排程不準時，以及怎麼修

WordPress 內建的 WP-Cron 並不是真正的系統排程，它只在「有訪客載入頁面」時才被觸發。流量低的網站排程會延遲，流量高的網站則可能因為重複觸發而拖慢伺服器。要讓排程準時又可靠，正解只有兩步：在 wp-config.php 加入 define('DISABLE_WP_CRON', true); 停用內建機制，再用主機真正的 Cron Job（cPanel 排程任務或 crontab 搭配 WP-CLI）每 5 到 15 分鐘觸發一次排程。

下面我會拆解 WP-Cron 的運作原理、它為什麼不可靠，並手把手帶你完成改造與驗證。

身為一個每天在程式碼和伺服器之間打滾的工程師，我看過太多網站效能不彰、功能失常的疑難雜症。其中一個最常見、卻也最容易被忽略的元兇，就是 WordPress 內建的排程系統 — WP-Cron。它就像個有點兩光的員工，心情好、有客人來訪時才工作，一旦網站沒人逛，它就跟著放假去了，這怎麼行！

你是否遇過預定發佈的文章到了時間卻沒動靜？或是備份外掛總是出現「錯過排程 (Missed schedule)」？這些問題很可能就是 WP-Cron 在跟你開玩笑。今天，我就要帶你徹底拆解這個「偽排程」系統，並教你如何用真正的伺服器 Cron Job 取代它，讓你的 WordPress Cron Job 自動排程設定從此準時又可靠，不再看訪客臉色辦事。

什麼是 WP-Cron？它和系統 Cron Job 不一樣

首先，我們得搞清楚 WP-Cron 到底是什麼。很多 WordPress 使用者，甚至一些有經驗的開發者，都以為它跟 Linux 系統裡的 Cron Job 是同一件事。嗯…這真是個美麗的誤會。

傳統的 Cron Job（或稱 cron daemon）是作業系統層級的任務排程器，它會像鬧鐘一樣，在指定的時間精準地執行任務，不管有沒有人正在使用這台機器。而 WP-Cron 並不是常駐的背景程序，它只是 WordPress 程式碼裡的一段邏輯。

WordPress 的創始者們考量到絕大多數使用者都在無法設定系統層級 Cron Job 的共享主機（Shared Hosting）上運作，為了讓排程功能在任何環境都能用，於是發明了這個權宜之計。它的運作機制是：

每當有訪客載入你網站的任何一個頁面時，WordPress 就會檢查目前是否有「到期待辦」的排程任務，有的話就觸發一個對 wp-cron.php 的請求去執行它。

這個設計在當年確實是個聰明的解法，它讓 WordPress 在各種主機環境下都能執行基本的排程任務，例如：

  • 定時發佈文章
  • 檢查 WordPress 核心、佈景主題、外掛的更新
  • 執行備份外掛的排程備份
  • WooCommerce 的定期任務（如取消未付款訂單、處理訂閱扣款）
  • 快取外掛的預先快取頁面任務

聽起來不錯，對吧？但問題就出在它的觸發機制 —它依賴訪客流量。這也為後續的效能與可靠性問題埋下了不定時炸彈。

WP-Cron 為什麼不可靠？低流量與高流量都中招

依賴流量的設計，會對兩種極端的網站造成困擾：流量太低的網站，和流量太高的網站。沒錯，不管高低，通通有獎，只是獎品你不會想要。

低流量網站：排程任務的無盡等待

想像一下，你設定了一篇重要公告要在凌晨三點準時發佈。但你的網站是個小眾部落格，半夜根本沒人會來逛。結果呢？WP-Cron 就跟著睡大覺了。直到隔天早上九點，第一位訪客進站，這個排程才被觸發，你的「凌晨三點公告」硬生生變成了「早上九點的馬後炮」。對於需要準時執行的任務，像是每晚的資料庫備份，這簡直是場災難。

高流量網站：效能的疊羅漢效應

如果你的網站流量很高，每秒都有好幾位訪客，情況會更糟。每次頁面載入都會觸發 WordPress 檢查排程，這本身就是額外的處理成本。當大量請求在短時間內同時嘗試執行 wp-cron.php 時，就可能形成所謂的「Cron Stampede」（排程踩踏）：多個請求重複執行同一批任務，導致伺服器 CPU 負載瞬間飆高、網站回應變慢，嚴重時甚至造成資料庫鎖死，讓整個網站癱瘓。這就像一家餐廳門口只有一個服務生，卻有一百個客人同時進來都要他帶位一樣，場面絕對是一片混亂。

所以，無論你的網站流量高低，把網站自動化的心臟交給這麼不靠譜的機制，都不是明智的選擇。

如何把 WP-Cron 換成可靠的伺服器 Cron Job？

說了這麼多，該來動手解決問題了。目標很明確：關掉 WordPress 那個愛打混的 WP-Cron，再設定一個真正的「鬧鐘」，讓伺服器自己準時去叫 WordPress 工作。整個過程只需要兩大步驟。

步驟一：停用內建的 WP-Cron

這是最關鍵的一步。我們必須先告訴 WordPress：「好了，你不用再自己檢查排程了，我會叫人來通知你。」

請透過 FTP 或主機的檔案管理員，找到你網站根目錄下的 wp-config.php 檔案。打開它，並在 /* That's all, stop editing! Happy publishing. */ 這行註解的上方，加入以下這行程式碼：

define('DISABLE_WP_CRON', true);

儲存檔案，就這樣！為什麼要加在這行註解上方？因為這行以下的程式碼會載入 WordPress 核心，常數必須在那之前就定義好才會生效。完成後，你的網站不會再因為訪客載入頁面而自動觸發 wp-cron.php，可以有效減輕高流量下的伺服器負擔。

但別忘了，這也代表所有排程任務目前都停止了，直到我們完成下一步。所以兩個步驟務必一起做完。

步驟二：設定真正的伺服器 Cron Job

現在，我們要設定一個真正的鬧鐘。這需要在你的主機控制台或伺服器上進行。常見的方式有兩種，依你的主機環境選擇即可。

方法一：使用 cPanel 等主機控制面板（最常見）

這是大多數虛擬主機用戶會使用的方式，非常直觀。

  1. 登入你的 cPanel 主機管理後台。
  2. 在「進階 (Advanced)」區塊找到名為「Cron Jobs」或「排程任務」的圖示，點進去。
  3. 在「新增 Cron Job」的區塊設定執行頻率。一個通用的建議是每 5 到 15 分鐘執行一次；你可以在「通用設定」中選擇「Once Per Five Minutes (*/5 * * * *)」之類的選項。
  4. 在「指令 (Command)」欄位中填入以下指令（記得把 yourdomain.com 換成你的網域名稱）： 
    wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
    這個指令是讓伺服器透過 wget 工具安靜地（-q）在背景訪問 wp-cron.php，並把所有輸出丟到垃圾桶（>/dev/null 2>&1），避免產生一堆無用的日誌。你也可以用 curl 取代 wget： 
    curl -s https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
  5. 點擊「新增 Cron Job」，大功告成！

這裡補充一個常被忽略的細節：網址後面帶的 doing_wp_cron 參數，是為了明確告訴 WordPress「這是一次主動觸發的排程執行」。由於我們已經在步驟一停用了訪客觸發機制，這個由外部 Cron Job 發起的請求，就成了唯一負責喚醒排程的角色。

方法二：在 VPS／專屬主機使用 WP-CLI（工程師推薦）

如果你使用的是 VPS 或更專業的主機環境，我強烈推薦用 WP-CLI 這個 WordPress 的命令列工具來觸發排程。為什麼？因為它直接透過 PHP 在伺服器本機執行，繞過了網頁伺服器（Nginx／Apache）與 HTTP 這一層，執行效率更高，也更不容易因為 HTTP 請求超時而失敗。

  1. 透過 SSH 連線到你的伺服器。
  2. 輸入 crontab -e 來編輯你的 cron 排程列表。
  3. 在檔案中加入一行，設定每 15 分鐘執行一次（記得把 /path/to/your/wordpress/root 換成你網站的實際路徑，並確認 wp 指令的實際路徑）： 
    */15 * * * * cd /path/to/your/wordpress/root; /usr/local/bin/wp cron event run --due-now >/dev/null 2>&1
    這行指令會先切換到 WordPress 根目錄，再執行 wp cron event run --due-now，它會聰明地只執行「目前已經到期」的任務，而不會把未來的排程一次全部跑掉。
  4. 儲存並離開編輯器。你的伺服器現在就是最可靠的排程管理員了。

小提醒：crontab 的執行環境通常很精簡，wp 可能不在預設 PATH 裡，所以建議像上面一樣寫出完整路徑；你可以先在 SSH 中用 which wp 確認它的位置再填入。

如何驗證新的 Cron Job 設定是否成功？

改完設定後，總得確認它有沒有正常運作吧？最簡單的方式是安裝名為 WP Crontrol 的外掛。啟用後，到「工具」>「Cron Events」，就能看到所有已排程的任務列表。

驗證的步驟很單純：

  1. 記下目前某個排程任務的「下次執行 (Next Run)」時間。
  2. 等待你設定的間隔時間（例如 15 分鐘）過去。
  3. 重新整理 Cron Events 頁面。

如果一切正常，你會看到到期任務已經被執行、「下次執行」的時間也被正確地往後推移了。反之，如果時間沒有更新，甚至出現「Missed schedule」的警告，那很可能是第二步的伺服器 Cron Job 指令或設定有誤，需要回去仔細檢查（網域、路徑、指令拼字）。

結語：奪回網站自動化的主導權

我知道，對於非技術背景的使用者來說，修改 wp-config.php 或設定 Cron Job 可能聽起來有點嚇人。但相信我，這絕對是你為網站做的最值得的投資之一。你等於為網站的心臟做了一次升級手術，從此擺脫不可靠的訪客觸發機制，換來穩定、高效且準時的自動化系統。

從今天起，別再讓你的 WordPress 排程任務繼續「等風來」。動手改造你的 Cron Job，讓你的網站真正成為一個 24 小時全年無休的自動化機器。這才是專業網站該有的樣子！

延伸閱讀

如果你在設定過程中遇到任何困難，或是有更複雜的網站架構、效能優化需求，別忘了浪花科技的團隊隨時都在這裡。歡迎填寫表單與我們聯繫，讓我們為你的網站進行一次徹底的健檢與升級！

// FAQ

常見問題

WP-Cron 和 Linux 系統的 Cron Job 一樣嗎？
不一樣。系統 Cron Job 是作業系統層級的排程器，會像鬧鐘一樣在指定時間精準執行，不論有沒有人使用機器。WP-Cron 並非常駐背景程序，只是 WordPress 程式碼中的一段邏輯，僅在有訪客載入頁面時才會被觸發檢查排程。
為什麼 WordPress 的排程文章或備份常常不準時？
因為 WP-Cron 依賴訪客流量觸發。低流量網站在沒人造訪時排程會一直延遲，例如設定凌晨三點發佈的文章，可能要等到隔天有訪客才執行；高流量網站則可能因大量請求同時觸發 wp-cron.php 形成「Cron Stampede」，導致伺服器負載飆高甚至資料庫鎖死。
如何讓 WordPress 排程準時可靠？
分兩步：先在 wp-config.php 的「That's all, stop editing!」註解上方加入 define('DISABLE_WP_CRON', true); 停用內建機制；再用主機真正的 Cron Job（cPanel 排程任務，或 crontab 搭配 WP-CLI）每 5 到 15 分鐘觸發一次排程。兩個步驟必須一起完成，否則排程會完全停止。
為什麼 DISABLE_WP_CRON 要加在 wp-config.php 的特定註解上方？
因為「That's all, stop editing! Happy publishing.」這行註解以下的程式碼會載入 WordPress 核心，而這個常數必須在核心載入之前就定義好才會生效，所以要加在該行的上方。
在 VPS 上用 WP-CLI 觸發排程比用 wget／curl 好在哪？
WP-CLI 直接透過 PHP 在伺服器本機執行（例如 wp cron event run --due-now），繞過網頁伺服器與 HTTP 這一層，執行效率更高，也較不會因 HTTP 請求超時而失敗。--due-now 只會執行目前已到期的任務，不會把未來排程一次跑完。
~/roamer-tech/newsletter // FREE
// newsletter

訂閱免費電子報

把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。

$
// final.exec()

準備好讓你的網站開始為你工作了嗎？

免費 30 分鐘諮詢 → 看作品