Если в WordPress «зависают» отложенные публикации, не уходят письма из форм, не обновляются фиды или не выполняются фоновые задачи плагинов, в первую очередь стоит смотреть на WP-Cron. Это не системный cron, а механизм, который запускается только при посещениях сайта. На тихих проектах, за прокси, на staging или при агрессивном кешировании он часто работает нестабильно.
Ниже — практический разбор: как понять, что проблема именно в WP-Cron, как быстро проверить конфигурацию, что поменять в wp-config.php и как убедиться, что задачи снова выполняются.
Как понять, что проблема именно в WP-Cron
Симптомы обычно похожи, но причина одна: WordPress не получает триггер на запуск фоновых событий. Чаще всего это видно по таким признакам:
- отложенные записи остаются в статусе
scheduledдольше назначенного времени; - плагины пишут в логи о пропущенных заданиях или таймаутах;
- не отправляются письма, хотя SMTP настроен;
- не обновляются sitemap, кэши, импорт/экспорт, очереди рассылок;
- на сайте мало трафика, а задачи «оживают» только после ручного открытия страниц.
Что проверить в админке и по логам
Начните с простого: откройте список отложенных записей и посмотрите, есть ли просроченные публикации. Затем проверьте логи плагинов, которые завязаны на фоновые задачи. Если у вас включён WP_DEBUG_LOG, полезно заглянуть в wp-content/debug.log. Ошибки вида spawn_cron(), cron, timeout или loopback request failed — хороший повод копать дальше.
Отдельно проверьте, не блокируются ли loopback-запросы. WordPress использует их для запуска фоновых задач. Если хостинг режет запросы на сам себя, WP-Cron может не стартовать даже при наличии трафика.
Диагностика: что именно ломает запуск
У WP-Cron обычно три практические причины отказа: мало посещений, отключённый loopback или конфликт с кешем/безопасностью. Иногда проблема не в самом cron, а в том, что его запуск слишком редкий или слишком дорогой для хостинга.
Проверка через WP-CLI
Если есть доступ к SSH и WP-CLI, это самый быстрый способ увидеть, что происходит с очередью задач. Команда ниже покажет список запланированных событий:
wp cron event list --fields=hook,next_run,recurrence --format=tableЕсли в списке много событий с просроченным next_run, а сайт при этом не выполняет их автоматически, проблема почти наверняка в запуске cron.
Полезно также проверить, не отключён ли WP-Cron в конфигурации:
wp config get DISABLE_WP_CRONЕсли значение true, WordPress не будет запускать cron при посещениях. Это нормально только если вы уже настроили системный cron на сервере.
Проверка через код
Иногда проще временно вывести состояние cron из темы или мини-плагина. Например, можно посмотреть, есть ли вообще ближайшие события:
<?php
$crons = _get_cron_array();
if ( ! empty( $crons ) ) {
foreach ( $crons as $timestamp => $hooks ) {
echo '<p>' . esc_html( date_i18n( 'Y-m-d H:i:s', $timestamp ) ) . '</p>';
break;
}
}Это не инструмент для продакшена, а быстрый способ понять, что очередь задач существует и WordPress её видит.
Пошаговое решение: переводим WP-Cron на системный cron
Если сайт не получает стабильный трафик или вы хотите предсказуемое выполнение задач, лучше отключить псевдокрон WordPress и запускать его по расписанию на сервере. Это стандартный и безопасный подход для большинства проектов.
Шаг 1. Отключите запуск cron на каждом хите
В wp-config.php добавьте:
define( 'DISABLE_WP_CRON', true );После этого WordPress перестанет пытаться запускать cron при каждом открытии страницы. Это снижает лишнюю нагрузку и убирает зависимость от случайных визитов.
Шаг 2. Настройте системный cron
На сервере добавьте задачу, которая будет дергать wp-cron.php раз в 5 минут. Для обычного shared-хостинга часто используют вызов через curl или wget:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Если у вас есть SSH и WP-CLI, надёжнее запускать cron через него:
*/5 * * * * cd /var/www/site/public && wp cron event run --due-now --quietВторой вариант обычно удобнее для диагностики: он сразу покажет ошибки в консоли и не зависит от HTTP-стека сайта.
Шаг 3. Проверьте, не мешает ли кеш
Если используется page cache, исключите wp-cron.php из кеширования. Для некоторых конфигураций важно также не кэшировать ответы на запросы к админке и REST API, если ими пользуются плагины для фоновых задач.
На уровне сервера или CDN убедитесь, что запрос к /wp-cron.php не получает редиректы, защитные страницы или 403. Иначе cron будет «успешно» вызываться, но фактически не выполнится.
Сравнение подходов: что выбрать для проекта
| Подход | Когда подходит | Минус |
|---|---|---|
| Стандартный WP-Cron | Небольшой сайт с регулярным трафиком | Нестабилен на тихих проектах |
| Отключить WP-Cron и использовать системный cron | Продакшен, магазины, контентные сайты, рассылки | Нужен доступ к серверу или панели хостинга |
| Оставить WP-Cron, но добавить внешний пинг | Временное решение без SSH | Зависит от стороннего сервиса и HTTP-доступности |
Если есть доступ к серверу, системный cron почти всегда предпочтительнее. Если доступа нет, можно временно использовать внешний мониторинг или сервис, который раз в несколько минут открывает wp-cron.php, но это компромисс, а не полноценная замена.
Проверка результата после внедрения
После настройки не ограничивайтесь тем, что сайт «открылся без ошибок». Нужно проверить именно выполнение событий.
- создайте тестовую отложенную запись на 5–10 минут вперёд;
- посмотрите, меняется ли статус записи в назначенное время;
- проверьте список cron-событий через
wp cron event list; - посмотрите логи веб-сервера и PHP, нет ли 403/500 на
wp-cron.php; - если используется SMTP или очередь писем, отправьте тестовое письмо и проверьте, не зависает ли оно в очереди.
Для более точной проверки можно вручную запустить cron и сравнить результат до и после:
wp cron event run --due-now --quietЕсли команда отрабатывает, а задачи всё равно не выполняются автоматически, значит проблема не в WordPress, а в расписании системного cron, правах доступа, URL сайта или сетевых ограничениях.
Частые ошибки и как их исправить
Отключили WP-Cron, но не добавили системный cron
Это самая частая ошибка. После define( 'DISABLE_WP_CRON', true ); сайт перестаёт запускать задачи вообще. Если нет серверной задачи, отложенные публикации и фоновые процессы остановятся.
Крон вызывается слишком редко
Если запускать его раз в час, отложенные записи будут публиковаться с заметной задержкой, а очереди плагинов начнут копиться. Для большинства проектов интервал в 5 минут — разумная отправная точка.
Запрос к wp-cron.php блокируется защитой
Иногда WAF, Basic Auth, ограничение по IP или правила в .htaccess не дают cron выполнить запрос. В таком случае в логах видно 401, 403 или 503. Решение — разрешить доступ к wp-cron.php или перейти на запуск через WP-CLI.
Смешали кеширование и фоновые запросы
Если CDN или серверный кеш вмешивается в wp-cron.php, cron может получать кэшированный ответ вместо реального выполнения. Для этого URL нужно сделать исключение на уровне кеша и прокси.
Практические советы по безопасности и производительности
Не оставляйте бесконтрольный запуск cron при каждом хите на нагруженном сайте. Это создаёт лишнюю нагрузку и может провоцировать всплески CPU в моменты пикового трафика. Для продакшена лучше один предсказуемый запуск по расписанию, чем десятки случайных попыток.
Если у вас несколько сайтов на одном сервере, не копируйте одинаковый cron-скрипт без проверки путей и прав. У каждого проекта должен быть свой каталог, свой пользователь и понятный способ логирования ошибок.
Для сайтов, где фоновые задачи критичны, полезно держать отдельный мониторинг: хотя бы проверку, что wp cron event list не содержит сильно просроченных событий. Это проще, чем разбираться с последствиями уже после срыва публикации или рассылки.
Если нужен не только cron, но и чистка технического мусора, дублирующихся мета-данных и лишних запросов, иногда имеет смысл смотреть в сторону инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но сам WP-Cron он не заменяет — это именно вспомогательная оптимизация сайта.