文章已经设置了定时发布，却没有发出去，后台还显示“已计划”“future”，有些站点甚至会出现Missed Schedule。这个问题很容易被误会成文章没保存好，其实多数时候是WordPress的计划任务没有被可靠触发。如果你的网站需要稳定定时发布文章，只靠默认WP-Cron有时并不够。尤其是访问量不高、缓存规则比较重、或者安全插件比较严格的网站，更容易出现到点不发布的情况。
搞清楚：WordPress定时发布靠什么触发
WordPress的定时发布不是系统后台一直守着时间点。默认情况下，它依赖WP-Cron：当有人访问网站时，WordPress顺便检查有没有该执行的计划任务。
这就带来一个现实问题：
- 网站访问少，任务可能没人触发
- 页面缓存太强，触发机会可能变少
- 安全插件拦截wp-cron.php，任务可能跑不起来
- 主机资源紧张，任务执行可能超时
所以，定时发布失败不一定是编辑器问题，更多时候是计划任务链路不稳定。
1.先确认文章是不是真的还没发布
不要只看前台有没有出现文章，先进后台确认文章状态。重点看这几项：
- 状态是否仍是“计划”或future
- 计划时间是否已经过去
- 时区是否正确
- 是否被插件改成了草稿或待审核
- 文章URL是否只是被缓存没刷新
如果文章状态已经是publish，但前台列表没出现，那更可能是页面缓存或列表缓存问题。
如果状态仍是future，才继续按WP-Cron方向查。
2.检查站点时区是否设置错了
很多定时发布问题，其实是时区造成的误判。
进入“设置→常规”，确认站点时区是否是目标地区。例如你要按北京时间发，就不要让站点停在UTC；如果要按欧洲时间发，也要确认时间显示和计划时间一致。
建议检查：
- WordPress后台显示的当前时间
- 服务器时间
- 文章计划发布时间
- 定时发布插件或自动化工具使用的时区
时区没对齐时，看起来像“没有按时发布”，实际可能是还没到WordPress认为的时间。
3.看DISABLE_WP_CRON是否被打开
有些站点为了性能，会在wp-config.php里加入：
这行代码本身不是坏事，但前提是你已经配置了服务器真实cron。
如果你禁用了WP-Cron，却没有让服务器定时访问wp-cron.php，那定时发布、自动更新、邮件任务、插件计划任务都可能受影响。
这是很多“定时发布失败”的核心原因。
4.低流量站点不要完全依赖访问触发
如果网站访问量不高，默认WP-Cron就可能不够稳定。
比如文章设置在凌晨或工作日冷门时段发布，但那段时间没人访问网站，任务就可能延后触发。等有人打开网站时，WordPress才发现“这个任务早就该执行了”。
这种情况下，最稳的做法是配置服务器cron，例如每5分钟触发一次：
有些站点为了性能，会在wp-config.php里加入：
或者用主机面板里的Cron Jobs定时访问wp-cron.php。
如果你的网站后台本来就慢，也建议一起看这篇：WordPress后台打开很慢但前台正常？先按这7步排查。后台慢和计划任务堆积有时会同时出现。
5.排查缓存、CDN和安全插件拦截
定时发布依赖后台任务，缓存和安全策略不应该拦截它。重点检查：
- CDN是否拦截wp-cron.php
- 安全插件是否限制后台请求
- WAF是否把cron请求当成异常访问
- 缓存插件是否对后台任务做了过度优化
- 主机防火墙是否限制本机回环请求
如果你使用了Cloudflare、LiteSpeed Cache、WP Rocket、安全防火墙插件，要特别留意这些规则。
如果你不确定Heartbeat和后台请求之间的关系，可以先看：Heartbeat是什么？为什么会让WordPress后台变慢、CPU飙升。它不是WP-Cron，但两者都属于后台动态任务，排查思路有相似之处。
6.检查是否有任务执行超时
有些站点不是任务没触发，而是触发后执行失败。常见原因包括：
- PHP执行时间太短
- 内存不足
- 数据库响应慢
- 插件任务太多
- 备份、扫描、同步任务同时运行
如果计划任务队列里堆了很多失败任务，定时发布也可能被拖慢。
这类问题不要只盯着文章本身，要看整个WordPress任务队列是否健康。
7.最稳方案：禁用访问触发，改用服务器真实cron
对需要稳定定时发布的网站，我更建议使用服务器真实cron。基本思路是：
- 在wp-config.php中关闭默认访问触发
- 在服务器或主机面板里添加定时任务
- 每5分钟访问一次wp-cron.php
- 定期检查计划任务是否正常执行
推荐文章：
(本文由美国主机侦探原创，转载请注明出处“美国主机侦探”和原文地址！)
微信扫码加好友进群
主机优惠码及时掌握
QQ群号：164393063
主机优惠发布与交流
