WPTOOLBEAR網站工具熊WP-Cron 排程失效：修復預約發文與自動任務的排查流程
預約發文的排程文章時間已過，狀態卻停在「排程中」或顯示 missed schedule，通常不是文章內容出了問題，而是預設的 WP-Cron 沒有透過網站流量準時觸發。這也會造成備份延遲、寄信任務堆積、電商同步異常，以及外掛背景工作卡住。
處理這類問題，先確認觸發機制，以及網站流量、回圈請求或伺服器設定是否正常，再決定是否改用外部 Cron。直接刪除排程事件或反覆重發文章，往往只會掩蓋真正原因。
重點摘要
- 先確認 WP-Cron 是否有排程事件堆積，再觀察預約文章、背景任務與錯誤紀錄。
- 網站流量不足時，排程可能延後；高流量環境則需檢查背景工作是否重複啟動。
- 釐清
DISABLE_WP_CRON的作用，再決定是否交由系統 Cron 定期執行。 - 搬家或更換主機後，依序檢查網域、絕對路徑、權限、防火牆與主機控制台設定。
- 外掛與 WordPress 核心的自動更新，可能重新影響備份、寄信等佇列與重試任務。修改設定前先備份，並在低風險時段測試。
- 修復後驗證測試文章、執行紀錄與備份結果，不要只看後台警告是否消失。
先辨識排程失效的症狀
不同症狀可能指向不同層級的問題。先記下異常首次發生時間、最近的外掛更新、搬家紀錄與主機設定變動。
預約文章沒有發布或出現 missed schedule
文章到了指定時間仍停留在「排程」狀態，代表 WordPress 沒有在到期時執行發布事件。低流量企業網站最常遇到這種情況，因為長時間沒有真實請求進入 WordPress。
若出現 missed schedule，也就是錯過排程，通常表示 WP-Cron 沒有及時觸發任務。先確認後台「設定」中的時區是否正確，時區錯誤會造成看似延遲的假象。
外掛任務、備份或寄信工作延遲
WooCommerce 庫存同步、表單通知、電子報寄送、資料匯入與備份外掛，都可能由排程事件帶動。若多種工作同時延遲，問題通常不在單一外掛，而在共用排程佇列、重試狀態或伺服器資源。
同一時間出現預約發文失敗與備份延遲時，先檢查整個排程系統、佇列與重試狀態，不要急著逐一重裝外掛。
WP-Cron 與系統 Cron 的差別
網站可透過 wp_schedule_event() 登記重複事件，但事件到期後，仍需要觸發程序執行。這正是許多網站排程延遲的常見原因。
WP-Cron 依賴請求，不會自行持續執行
預設情況下，訪客進行頁面加載時，網站會嘗試啟動 wp-cron.php。WP-Cron 仰賴網站流量觸發，不是持續運作的背景服務。低流量站可能因長時間沒有訪客而錯過排程；流量突然增加時，則可能有多個請求同時處理背景工作。
WordPress 官方的系統排程說明也指出，WP-Cron 並非持續運作的排程服務，可改由外部系統定時請求或執行。
快取與回圈請求也可能中斷觸發
全頁快取、CDN、Basic Auth、防火牆規則或安全外掛，可能讓前台請求停留在快取層，或阻擋回圈請求。此時，即使網站有訪客，這些回圈請求仍未真正進入核心系統，WP-Cron 也可能不會如預期啟動。
WP-Cron 四步排查流程
先在正式站觀察與驗證，避免一開始就改設定。若網站有測試站，優先在測試環境複製問題並確認修復方式。
檢查事件、設定檔與時區
安裝 WP Crontrol 後，可查看哪些排程事件逾期、下一次執行時間與對應 hook。請記錄可疑 hook 名稱，但不要直接刪除，因為刪除後可能造成備份、訂單同步或外掛清理工作永久漏跑。
接著開啟 wp-config.php，搜尋 DISABLE_WP_CRON。若它已設為 true，但主機端沒有 Cron Job，所有排程都會停止。也要確認 WP-Cron 時區、伺服器時間與預約發文時間是否一致。
用網站健康與紀錄交叉驗證
後台「工具」中的 WordPress Site Health 的「網站健康」檢查，若顯示 Loopback request 錯誤，代表背景的回圈請求可能受阻。不過，Site Health 的 loopback 檢查機制只是診斷訊號，不能單獨證明排程已故障。
請依序查看主機錯誤日誌、wp-cron.php 回應碼與外掛紀錄，確認是否受到快取層、防火牆或安全外掛影響。重點檢查是否出現 403、401、429 或 500 回應。高流量站若後台變慢，可用 Query Monitor 找出效能問題 ，確認是否有外掛在每次執行時發出大量資料庫查詢或外部 API 請求。
搬家後與不同主機環境的處理方式
主機搬遷後的排程問題，經常來自舊路徑、舊網域或控制台設定沒有同步。伺服器 Cron 也可能仍指向舊網域、舊路徑或舊 PHP 執行檔。
共享主機與 cPanel 控制台
虛擬主機通常可在 cPanel、Plesk 或自家控制台建立 Cron Job。不同控制台的設定介面與可用功能可能不同，建立前先確認主機是否限制最短執行頻率、支援 WP-CLI，以及 Cron 輸出的錯誤信寄到哪個信箱。
如果控制台要求填寫執行命令，不要直接複製其他網站的 PHP 路徑。每個網站的執行環境都可能不同，包含 WordPress 根目錄、PHP 執行檔、帳號權限與工作目錄。應向主機商取得正確格式。
管理型 WordPress 主機
部分管理型 WordPress 平台已有內建排程，或限制自訂 Cron。先查看主機文件或詢問技術支援，確認平台是否已接管 wp-cron.php。
未確認前，不要額外新增第二組 Cron Job。兩個觸發來源同時執行，可能讓匯入、寄信或訂單同步工作重複進行。
VPS 與自管伺服器
VPS 可使用系統 Cron，但也要檢查執行帳號、檔案權限、PHP 版本、工作目錄與錯誤日誌。若使用 Nginx 或 Apache 快取規則，應排除對排程入口的不當封鎖。
客製外掛或伺服器腳本要先放進 Git 版本控管，於本機與測試站驗證。不要讓自動化工具直接修改正式站設定，也不要把 API 金鑰、資料庫備份或環境變數提交到公開版本庫。
安全改用系統 Cron 或 WP-CLI
伺服器 Cron 能固定時間觸發排程，適合有預約發文、電商訂單、備份或內容自動化流程的網站。
先建立外部觸發，再停用內建觸發
修改前先完成 WordPress 備份安全檢查，並確認資料庫與網站檔案都可還原。建立主機端 Cron 後，才在 wp-config.php 的「停止編輯」註解前加入：
define( 'DISABLE_WP_CRON', true );
DISABLE_WP_CRON 只會停止頁面加載時的 WP-Cron 觸發，不會刪除既有排程事件。因此，系統 Cron、外部請求或 WP-CLI 必須持續執行。不使用 WP-CLI 時，也可由外部服務請求 wp-cron.php。
WP-CLI 適合可管理命令列的環境
若主機支援這項工具，可由系統 Cron 在正確的 WordPress 目錄、帳號與 PHP 執行環境中執行：
wp cron event run --due-now
這個指令只執行目前已到期的事件，不會提前執行未來任務。可參考 WP-CLI 官方開發資源，先在測試站確認外掛相容性與命令權限。
排程頻率要依任務需求設定。若每五分鐘才執行一次，預約文章最久可能延後接近五分鐘。大量任務累積在佇列時，先檢查到期排程事件與失敗任務，確認是否需要重試，再分批測試，避免一次寄出大量郵件、重複同步或執行備份。
修復後要驗證，也要持續監控
排程恢復一次，不代表之後永遠正常。網站更新、主機搬遷、快取調整與外掛升級，都可能再次影響背景工作。WordPress 或外掛自動更新後，也應重新觀察排程。
用測試文章驗證完整流程
建立一篇測試文章，排在未來 10 至 15 分鐘發布。接著檢查文章狀態，並比對 WP-Cron 執行紀錄、WP Crontrol 中的下一次排程事件時間，以及主機 Cron 輸出，確認修復前後是否仍有錯過排程。
若網站依賴自動備份，也要確認備份檔確實產生，並能實際還原。排程成功通知只能證明任務被啟動，不能證明整個備份流程可用。
建立失敗告警與例行檢查
將 Cron 執行錯誤導向私有日誌或通知信箱，並定期檢查逾期事件、失敗佇列與反覆重試的背景工作。網站營運較重要時，可依照 WP-Cron 與網站異常監測方式 設定 uptime、5xx 與排程告警。
常見問題
低流量或高流量網站，如何辨識排程問題？
低流量網站容易錯過排程，因為預設 WP-Cron 依賴網站請求觸發。沒有訪客時，頁面加載不會帶動到期事件執行。高流量網站則應留意重複觸發、慢查詢與外掛任務耗用資源。
WordPress Site Health 出現「Loopback request」錯誤，該怎麼查？
先檢查 wp-cron.php 的回應碼，再確認快取、防火牆與安全外掛設定。接著查看主機日誌，別把 loopback 訊息直接視為唯一故障原因。網站健康檢查結果仍需搭配實際執行紀錄判斷。
設定 DISABLE_WP_CRON 後，為什麼任務仍然沒有執行？
先確認設定檔中的 DISABLE_WP_CRON 是否為 true，再確認唯一的系統 Cron 或伺服器排程是否實際執行。不要只建立 Cron Job，卻遺漏停用後所需的外部觸發。
搬家後已設 Cron，為什麼仍然失效？
先確認排程是否仍指向舊網站路徑或舊網域，也要檢查新主機的權限、防火牆、PHP 版本與 WordPress 根目錄。搬家時最容易遺漏的是控制台外部設定，而非資料庫本身。
修復後要如何確認排程恢復正常？
可建立未來 10 至 15 分鐘執行的測試文章，並檢查執行紀錄與備份檔還原結果。若排程事件仍形成「佇列」或持續「重試」，就要回到日誌與主機資源檢查。
讓排程回到可預期的運作方式
預約發文失敗不只是內容問題，也可能是背景工作缺少可靠觸發來源。先確認網站流量能否觸發 WP-Cron，並檢查目前狀態，再依主機環境選擇系統 Cron 或 WP-CLI。更新、搬家或調整快取後，也要重新驗證自動更新與排程結果。
只要有固定觸發、可查閱紀錄，並透過測試文章驗證結果，WP-Cron 排程失效就不會等到重要發布、備份或訂單任務發生後才被發現。