WordPress 文章过了预定时间还未公开，先核站点时区、该文章的计划时间和当前状态。若时间其实未到，修正排程；若已到点仍是 future，再查 WP-Cron 事件、站点自身回环请求和主机计划任务。补发前先确认这篇是否已经变成 publish，补发后用未登录页面核同一个 URL；不要因为前台缓存或搜索结果没更新，就另建一篇重复文章。
本文处理“已经排程却没有按时公开”。如何首次在编辑器设置计划时间，可看WordPress 后台基础操作；站点名称和时区等常规设置见WordPress 常规设置。以下用一篇教学文章 ID 2001 演示排查，时间、日志和结果都不是 yaiseo.com 的实际故障记录。
先证明它真的漏发：文章 ID、状态和两种时间
在“文章 → 所有文章”里找原文章，记下编辑链接中的 ID、状态和预定日期。点击编辑，在文章设置中读回“发布”时间，别只凭排期表、日历截图或外部自动化的提交结果判断。WordPress 的文章设置说明把未来日期设为计划发布；后台显示的计划状态与正式公开的 publish 是两种状态。
接着查“设置 → 常规”的站点时区。教学站设为 Asia/Shanghai，文章 2001 预定北京时间 10:00，对应 UTC/GMT 02:00。北京时间 09:55 看到公开页 404 是尚未到点；10:08 后文章仍为 future 才需要继续排查。若后台计划时间是 10:00 但站点设置为 UTC，它会按站点的 10:00 执行，和编辑以为的北京时间差八小时。此时先核时区与文章计划时间，不要改 Cron。
| 教学记录字段 | 10:08 读到的值 | 说明 |
|---|---|---|
| 文章 ID / URL | 2001 / /example-post/ | 后续只操作同一篇，不新建副本 |
| 站点时区 | Asia/Shanghai | 按站点设置解释编辑器时间 |
| 计划时间 | 本地 10:00；GMT 02:00 | 已过计划点 |
| 后台状态 | future | 还没有转成 publish |
| 未登录公开页 | 404 | 与 future 相符；故障层仍待定位 |
如果后台已经是 publish，先用未登录窗口打开文章正式 URL，并查缓存/CDN、密码保护、可见性或重定向。搜索引擎还未展示新文也不等于“定时发布失败”；搜索发现与 WordPress 文章状态是后续两个不同问题。此时反复修改计划时间或再发一篇都可能制造重复。
确认到期仍为 future，再查 WP-Cron
WordPress 的WP-Cron 机制会在页面加载时检查到期任务，计划文章也依赖它；它并不是一直运行的服务器时钟。低流量可能造成延迟，但不能据此认定每次漏发都是访问量问题。先看“工具 → 站点健康”是否报告计划事件或 loopback 异常，再让有主机权限的人检查错误日志与当前调度。WordPress 的loopback 手册说明站点自请求用于触发定时事件；失败可由插件、主题或网络拦截引起。
如果主机有 WP-CLI，先确认命令指向正确站点，再只读列事件：wp cron event list --fields=hook,next_run_gmt,args。在结果中找 publish_future_post 以及参数里的文章 ID 2001。WP-CLI 事件列表文档列出这些字段；WordPress 的核心函数也表明该事件按文章 ID 检查，只有仍为 future 且时间已到才执行发布。多站点环境须指定正确站点；无 SSH/WP-CLI 权限时让主机支持人员提供同等只读事件与日志，不因缺工具就安装多个排障插件。
| 观察 | 更可能在哪一层 | 下一步 |
|---|---|---|
ID 2001 不在未来文章或时间其实未到 | 文章排程 | 回编辑器核日期、时区、状态并重新保存 |
| 已到期且事件还在队列，站点健康报 loopback 失败 | 任务触发/自请求 | 查访问控制、防火墙、插件冲突与主机日志 |
事件显示运行过但文章仍 future | 任务执行或文章状态 | 查 PHP 错误、插件钩子及对应 ID；不要直接认定低流量 |
文章已 publish，公开页还是旧版或 404 | 缓存、权限或路由 | 查未登录响应、缓存/CDN 与正式 URL |
这张表是排查分流，不是由一个站点健康警告自动得出结论。如果事件列表缺 publish_future_post，核编辑器是否真正保存为未来文章、是否被插件改写排程；若事件在而调用失败，先找主机日志里的时间与错误。不要直接在生产站一次运行所有到期任务，因为队列里可能还有邮件、备份或其他插件动作。
恢复这一篇：先读回，再触发或手动补发
恢复前刷新后台与公开页，再记一次 ID 2001 的当前状态。若它已 publish，不再补发；处理前台缓存或访问故障。若仍 future，可让主机管理员修复 Cron/loopback 后观察对应事件是否执行，或在业务上不能再等时，打开同一篇文章，用编辑器的“立即发布”控制完成单篇补发。不同 WordPress 版本和编辑器按钮不同，以确认前后的文章 ID 与状态为准，不创建第二篇。
教学情境里的恢复记录应这样写：10:08 文章 2001 为 future、公开页 404；10:12 修复 loopback 后事件运行，10:13 同一 ID 变 publish；未登录打开 /example-post/ 得到 200，标题、正文与图片可见，公开 URL 与原计划一致。若是人工补发，记录谁在何时操作以及文章实际公开时间。这里是演示填写方式，不是实际执行结果。
后台显示已发布仍不足以完成验收。用未登录网络访问正式 URL，核状态码、标题/正文、图片、站点地图是否给出该正式 URL；再看缓存是否提供旧内容。如果首页列表未马上出现，也要分别检查分类、缓存和文章可见性。搜索收录要在内容公开后另行观察，不能把“还没被 Google 收录”倒推为 Cron 故障。
下一篇怎么验证“准点”，何时改服务器任务
若这次确认为 WP-Cron 未触发，先查主机是否已经配置外部计划任务、任务是否可执行、是否被防火墙或认证挡住。有可靠主机任务能力时，可按WordPress 官方系统任务文档定期请求 wp-cron.php；先建并测试外部触发，再考虑在 wp-config.php 设置 DISABLE_WP_CRON，避免先关掉默认触发而没有替代。频率由发布时效和主机资源决定，不能仅凭一篇漏发稿套固定数值。主机已托管 WordPress Cron 时，先排查现有配置，不再叠加一个未知调度器。
为下一篇低风险测试稿写下 ID、预定站点本地时间、对应 GMT、到点后检查时间、后台状态、公开 URL 响应和主机任务日志。假设下一篇计划 11:00，11:02 后仍 future，保留事件/loopback 证据再交技术负责人；若同一 ID 已 publish、未登录正式 URL 200 且正文可见，这一轮发布链才通过。补发当前文章解决的是当下缺口，只有下一篇受控排程记录才能说明准点问题是否消失。
常见问题
站点流量低，定时文章一定会失败吗？
不一定。默认 WP-Cron 由页面加载触发，低流量可能延迟；主机也可能已设置外部计划任务。先查这篇的时间、状态和任务日志。
可以直接安装定时发布修复插件吗？
先定位故障层。时区填错、文章已发布但缓存未更新、loopback 被挡和外部任务失效，处理方式不同。新增插件本身也会增加一个变量。
到点文章 404 是否说明 Google 不收录？
不说明。先在后台确认是否 publish，再核未登录正式页能否打开；只有公开页面可访问之后，才讨论抓取与索引。