Пост к акции на 9:00, в 9:30 в админке «пропущено по расписанию», на сайте пусто — и страшно трогать wp-config.php. Андрей из доставки обедов в понедельник в 10:00 всё ещё видел меню «запланировано»: ночью на сайт никто не заходил, планировщик не сработал, плюс хостер уже отключил встроенный WP-Cron без замены. Ниже — что проверить сегодня без программиста: часовой пояс, визит на главную, WP Crontrol и текст в поддержку хостинга.
WP-Cron — это не часы на сервере, а очередь задач, которую WordPress проверяет, когда кто-то открывает сайт. Отложенная публикация сработает после первого визита в назначенное время или позже. Надпись «пропущено по расписанию» иногда исчезает через пару минут после захода на главную — это задержка, а не всегда поломка. Но если ночью трафика нет часами, пост так и останется черновиком с просроченным временем, пока вы не «толкнёте» очередь или не настроите вызов wp-cron.php на хостинге.
Сайт не публикует сам — ждёт визита на страницу. Разберём симптомы, быстрый чеклист и когда нужен гайд по системному cron вместо WP-Cron. К концу дня вы сможете получить предсказуемый результат: тестовая отложенная запись выходит без паники, а очередь в WP Crontrol снова двигается.
- Разберите, как WP-Cron запускает отложенные публикации
- Проверьте симптомы и настройки без правки кода
- Откройте очередь задач через WP Crontrol
- Сделайте быстрый тест визитом и wp-cron.php
- Найдите DISABLE_WP_CRON и напишите в поддержку хостинга
- Убедитесь, что следующая акция выйдет по плану
- Избегите типичных ошибок после «исправления»
- Частые вопросы
- Почему не публикуется отложенный пост в WordPress?
- Что делать, если запланированная публикация пропущена?
- Как проверить wp cron в WordPress без SSH?
- Чем WP-Cron отличается от cron на хостинге?
- Как часто вызывать wp-cron.php через задание хостинга?
- Нужно ли ставить плагин WP Missed Schedule?
- Мешает ли кэш или режим обслуживания?
Разберите, как WP-Cron запускает отложенные публикации
Планировщик WordPress (его часто называют WP-Cron) при каждой загрузке страницы смотрит список автозадач по времени. Среди них есть событие publish_future_post — оно и переводит запись из статуса «запланировано» в «опубликовано». Если задача назначена на 14:00, а до 17:00 никто не открыл сайт, выполнение сдвинется на первый визит после 14:00. На малопосещаемом сайте пост к обеду часто «зависает» в списке записей, хотя время в админке уже в прошлом.
Типичная ошибка: считать, что «Запланировать» привязано к часам сервера. На тихом shared-тарифе пост выйдет, когда кто-то откроет главную без админки. Та же очередь тянет бэкапы и письма — зависшая задача плагина задерживает и публикацию.
| Ситуация | Что видите | Что это значит для вас |
|---|---|---|
| Регулярный трафик днём | Пост выходит в течение 15-30 минут после времени | WP-Cron успевает при визитах |
| Ночь, выходные, «тихий» сайт | Статус «пропущено по расписанию» | Очередь не запустили до визита |
| В wp-config стоит DISABLE_WP_CRON | Ничего не публикуется часами | Нужен вызов wp-cron.php с хостинга |
| Более 100 запланированных записей | Новые не ставятся в очередь | Лимит из справки WordPress.com |
Проверьте симптомы и настройки без правки кода
- Статус «Запланировано», не черновик; дата в будущем на момент сохранения.
- Настройки → Общие → часовой пояс вашего города.
- После «пропущено по расписанию» — главная сайта вне админки, через 2-3 минуты обновите записи.
- Не больше 100 запланированных материалов одновременно.
На малом трафике публикация обычно в течение 15-30 минут после времени или после визита на сайт. Используйте этот мини-чеклист перед каждой акцией; не делайте массовое «Запланировать» сотнями постов сразу — упрётесь в лимит очереди.
Откройте очередь задач через WP Crontrol
Если после визита на главную пост всё ещё висит, нужна диагностика за пять минут. Установите бесплатный плагин WP Crontrol из каталога WordPress, откройте Инструменты → Cron Events (или «Запланированные события»). Найдите хук publish_future_post и события с просроченным временем Next Run. В магазинах с WooCommerce загляните и в «Запланированные действия» тяжёлых плагинов — просроченные задачи там иногда блокируют всю очередь, как описывают в тредах wordpress.org про Action Scheduler.
Например, «зависший» хук другого плагина задерживает publish_future_post — так пишут на StackExchange. Run now на тесте покажет, двигается ли очередь; чужие события не удаляйте без скрина для поддержки.
Сделайте быстрый тест визитом и wp-cron.php
Иногда достаточно одного захода на сайт вне панели управления. Альтернатива — один раз открыть в браузере адрес https://ваш-домен.ru/wp-cron.php?doing_wp_cron (пустая страница нормальна). Это тот же вход, который хостинг должен вызывать по расписанию, если встроенный планировщик отключён.
Шаг 1: создайте тестовую запись «на через 20 минут» и не трогайте сайт. Шаг 2: если она не вышла, зафиксируйте скрин WP Crontrol и время — это аргумент для поддержки. Если вышла только после вашего визита — признайте низкий трафик и настройте серверное расписание; пошагово это разобрано в материале про системный cron, без повторения всего чек-листа здесь.
Если в Сервис → Здоровье сайта есть предупреждение про loopback, сайт буквально «не дозванивается» до wp-cron.php. Тогда с хостингом обсуждают ALTERNATE_WP_CRON или PHP-вызов вместо wget — это уже не паника, а конкретный тикет с скрином Site Health.
Найдите DISABLE_WP_CRON и напишите в поддержку хостинга
В wp-config.php ищите define(‘DISABLE_WP_CRON’, true); — часто ставит хостер. Без задания в панели отложенные записи перестают выходить; прямой вызов wp-cron.php по URL при этом возможен. Сначала задание на хостинге, потом отключение встроенного cron (Kinsta, WPShop).
Текст в тикет: добавьте wget/curl на https://мой-домен.ru/wp-cron.php?doing_wp_cron каждые 5-15 минут; в wp-config уже DISABLE_WP_CRON. Расписание */15 * * * * — из документации WordPress.
Если править файлы страшно — опишите симптом в форме на сайте (MAX, VK, WhatsApp, Telegram), без звонков. При сопровождении WordPress мы проверяем расписание и контент вместе — см. услуги по сайту и статьям.
Убедитесь, что следующая акция выйдет по плану
Ориентир результата за вечер: тест «запланировано» выходит в 15-30 минут после времени или после визита; «пропущено» не висит вечно; publish_future_post уходит в WP Crontrol; при DISABLE_WP_CRON вы настроите задание на хостинге и исправите срыв без программиста.
- Тест через 10-15 минут, часовой пояс зафиксирован.
- Не дёргайте сайт каждую минуту.
- Статус «опубликовано», дата по плану.
- Next Run в Crontrol не в прошлом месяце.
- Сверьте автобэкап и кеш с расписанием.
WP Missed Schedule — запасной костыль на разовый срыв; для регулярных постов см. планирование публикаций.
Избегите типичных ошибок после «исправления»
- Отключили встроенный WP-Cron без серверного задания — письма, бэкапы и посты встают без красной ошибки.
- Хостинг блокирует wget с basic auth или режет loopback — cron «настроен», а задачи стоят; смотрите Здоровье сайта.
- Кэш отдаёт wp-cron.php без PHP — см. настройки кеш-плагина и исключения URL.
- Два одинаковых cron-задания каждую минуту — лишняя нагрузка; достаточно 5-15 минут.
- Паника из-за Missed Schedule на минуту — часто исчезает после следующего визита, как пишут на StackExchange.
Когда очередь снова живая, имеет смысл сверить соседние настройки: Heartbeat в админке снижает лишние запросы, а свежие гайды по WordPress собраны в разделе статей.
Материал проверен Андрей Дикий — практика WordPress, SEO/GEO для малого бизнеса.
На что опирались: developer.wordpress.org (WP-Cron), wordpress.com/ru/support/schedule-a-post-or-page/, wpshop.ru (cron-not-working), kinsta.com (disable-wp-cron), WP Crontrol, StackExchange; LSI по SERP 2026-09-22 (Вордстат MCP недоступен).
Частые вопросы
Почему не публикуется отложенный пост в WordPress?
Чаще всего WP-Cron не запустился: на сайт не заходили после назначенного времени, неверный часовой пояс, черновик вместо «Запланировать» или в wp-config отключён встроенный планировщик без задания на хостинге. Сначала визит на главную и проверка часового пояса, затем WP Crontrol.
Что делать, если запланированная публикация пропущена?
Откройте сайт вне админки, подождите 2-3 минуты и обновите список записей. Если статус не сменился — WP Crontrol, Run now на тесте, проверка DISABLE_WP_CRON и письмо в поддержку с просьбой вызывать wp-cron.php каждые 5-15 минут.
Как проверить wp cron в WordPress без SSH?
Установите WP Crontrol, откройте Cron Events, найдите publish_future_post и просроченные Next Run. Ручной Run now показывает, жива ли очередь. Дополнительно один раз откройте wp-cron.php?doing_wp_cron в браузере.
Чем WP-Cron отличается от cron на хостинге?
WP-Cron привязан к визитам на сайт — как официант, который приносит счёт, когда гость зашёл. Cron на хостинге — будильник сервера: дергает wp-cron.php по расписанию, даже если никто не открывал страницы. Подробная настройка — в отдельной статье про системный cron.
Как часто вызывать wp-cron.php через задание хостинга?
Обычно каждые 5-15 минут: в cron это */5 или */15 * * * *. Реже — дольше ждёте публикацию акции; каждую минуту на дешёвом shared-тарифе часто упираетесь в лимиты CPU.
Нужно ли ставить плагин WP Missed Schedule?
Как временный запасной вариант — да, если разовый срыв и вы ещё не настроили серверное расписание. Для регулярного контент-плана надёжнее cron на хостинге и диагностика через WP Crontrol, а не только костыль плагина.
Мешает ли кэш или режим обслуживания?
Да. Агрессивный кэш может не пропускать PHP к wp-cron.php, режим обслуживания режет визиты — очередь не стартует. Проверьте исключения URL в кеш-плагине и отключите maintenance на время теста отложенной записи.
