Почему WP-Cron не запускается по расписанию и как перевести его на системный cron

Если в WordPress «ломается» отложенная публикация, не приходят письма из плагинов, не обновляются фиды или не срабатывают фоновые задачи, часто проблема не в самом плагине, а в WP-Cron. Это не системный cron, а механизм, который запускается только при посещениях сайта. На небольшом трафике он легко начинает опаздывать, а на нагруженном сайте может, наоборот, создавать лишнюю нагрузку.

Ниже разберём, как понять, что именно WP-Cron мешает, как отключить его внутренний запуск и перенести расписание на нормальный cron на сервере без лишнего риска.

Как понять, что проблема именно в WP-Cron

Симптомы обычно похожи друг на друга, но у них есть общая логика: задача должна была выполниться по расписанию, а фактически срабатывает позже или не срабатывает вовсе. Это касается отложенных постов, очистки кеша, отправки очередей писем, импорта данных и любых задач, которые завязаны на wp-cron.php.

Типичные признаки

• отложенные записи остаются в статусе «Запланировано» дольше нужного времени;
• плагины пишут в логах о пропущенных событиях или таймаутах;
• очереди действий в админке растут, но не обрабатываются;
• на сайте с низким трафиком задачи выполняются только после ручного открытия страниц;
• на сайте с высоким трафиком заметны лишние обращения к wp-cron.php.

Что проверить в первую очередь

Начните с простых вещей: не блокируется ли wp-cron.php на уровне сервера, не отключён ли WP-Cron в wp-config.php, не стоит ли поверх него ещё один плагин для планировщика. Если есть доступ к логам веб-сервера, посмотрите, как часто вызывается /wp-cron.php и нет ли там 403, 500 или долгих ответов.

Полезно также открыть список запланированных событий через WP-CLI, если он доступен:

wp cron event list

Команда покажет, какие события стоят в очереди, когда они должны были выполниться и есть ли явные просрочки. Если WP-CLI недоступен, можно использовать плагин для просмотра cron-событий, но для постоянной диагностики удобнее именно консоль.

Почему WP-Cron ведёт себя нестабильно

У WP-Cron есть архитектурная особенность: он не живёт отдельно от трафика. WordPress проверяет расписание при загрузке страниц и, если видит просроченные события, пытается запустить их в фоне. Это удобно на обычном хостинге, но плохо предсказуемо.

На практике проблемы возникают в трёх сценариях:

• низкий трафик — событие ждёт первого посетителя;
• высокий трафик — несколько запросов могут одновременно попытаться запустить cron;
• ограничения хостинга — loopback-запросы к самому себе блокируются, и cron не доходит до выполнения.

Если сайт использует тяжёлые плагины, фоновые задачи начинают конкурировать за ресурсы с обычными запросами. В этом случае перевод на системный cron обычно даёт более предсказуемое поведение.

Как перевести WP-Cron на системный cron

Схема стандартная: отключаем внутренний запуск WP-Cron и создаём задачу на сервере, которая будет вызывать wp-cron.php по расписанию. Это не отменяет сам механизм WordPress, а только меняет способ его запуска.

Шаг 1. Отключить автоматический запуск WP-Cron

В wp-config.php добавьте константу:

define('DISABLE_WP_CRON', true);

Важно: это отключает только автоматический запуск при посещении сайта. Сам файл wp-cron.php продолжит работать, если его вызывать вручную или через системный cron.

Шаг 2. Добавить задачу в cron на сервере

Самый простой вариант — вызывать wp-cron.php раз в 5 минут. Пример для crontab:

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Если на сервере есть WP-CLI и доступ к файловой системе сайта, лучше использовать его: так меньше зависимость от HTTP и SSL-настроек.

*/5 * * * * cd /var/www/example.com/public_html && wp cron event run --due-now --quiet

Второй вариант обычно удобнее для VPS и выделенных серверов. На shared-хостинге чаще остаётся HTTP-вызов, потому что WP-CLI может быть недоступен или ограничен.

Шаг 3. Проверить, что задача действительно запускается

После настройки не ограничивайтесь тем, что «ошибок нет». Нужно проверить фактическое выполнение.

• Посмотрите, исчезают ли просроченные события из wp cron event list.
• Создайте тестовое событие через плагин или код и убедитесь, что оно выполняется в нужное время.
• Проверьте логи веб-сервера или cron-логи на предмет ошибок доступа и таймаутов.
• Если сайт использует кеш, убедитесь, что cron не упирается в редиректы, авторизацию или защиту от ботов.

Когда лучше использовать код, а когда плагин

Если задача только в том, чтобы стабилизировать расписание, код и системный cron — самый прозрачный вариант. Плагин имеет смысл, когда нужно ещё и наблюдать за очередью событий, не заходя на сервер.

Если на сайте уже есть проблемы с дублями, мусорными мета-данными и лишними запросами, имеет смысл сначала почистить технический слой. В таких случаях полезны инструменты вроде Clearfy Pro, но только если вы понимаете, какие опции включаете и что именно отключаете.

Проверка результата после внедрения

После перевода на системный cron важно убедиться, что WordPress действительно перестал полагаться на посещения страниц. Проверка должна быть практической, а не формальной.

Что должно измениться

• запланированные записи публикуются без задержек;
• фоновые задачи выполняются даже при отсутствии посетителей;
• в логах нет регулярных ошибок на wp-cron.php;
• нагрузка от cron не возникает на каждом открытии страницы;
• очередь событий не копится неделями.

Если используете WP-CLI, сравните список событий до и после настройки. Если cron работает, просроченные задачи должны уходить после запуска команды wp cron event run --due-now. Если нет — ищите проблему в правах доступа, DNS, SSL или в самом плагине, который регистрирует событие.

Частые ошибки и как их исправить

Отключили WP-Cron, но не добавили системный cron

Это самая частая ошибка. В результате все задачи WordPress просто перестают запускаться. Если после правки wp-config.php сайт начал «молчать», проверьте наличие записи в crontab и её синтаксис.

Используют слишком редкий интервал

Если cron стоит раз в час, отложенные публикации и очереди писем будут заметно запаздывать. Для большинства сайтов разумнее начать с интервала в 5 минут, а потом уже смотреть по нагрузке и критичности задач.

Вызывают wp-cron.php через браузер, а не из cron

Ручной заход в URL не заменяет системный запуск. Он зависит от сессии, редиректов, кеша и защиты от ботов. Для диагностики это допустимо, но не как постоянное решение.

Не учитывают блокировки loopback-запросов

Некоторые плагины и сам WordPress используют loopback для фоновых операций. Если сервер режет такие запросы, cron может стартовать, но не завершаться. В этом случае смотрите настройки firewall, mod_security, basic auth и защиту панели хостинга.

Безопасность и производительность

Если сайт работает на общем хостинге, не стоит оставлять открытый доступ к тяжёлым фоновых задачам без контроля. Системный cron уменьшает случайные запуски, но не отменяет необходимость следить за логами и временем выполнения.

Практически полезные меры:

• не ставьте слишком частый запуск без необходимости;
• не запускайте cron через публичный URL чаще, чем нужно;
• используйте отдельного пользователя сервера, если это возможно;
• проверяйте, не создаёт ли конкретный плагин собственные тяжёлые события;
• после обновлений плагинов периодически смотрите список cron-событий.

Если на сайте много технического мусора — дубли архивов, лишние таксономии, ненужные автособытия — сначала разберитесь с источником нагрузки, а уже потом настраивайте расписание. Иначе cron будет исправно запускать то, что не должно было создаваться вообще.

Мини-чек-лист перед запуском в продакшен

• DISABLE_WP_CRON добавлен в wp-config.php;
• в crontab есть рабочая команда;
• команда выполняется от правильного пользователя;
• URL сайта открывается без лишних редиректов и ошибок SSL;
• в логах нет 403/500 на wp-cron.php;
• тестовое событие выполняется в ожидаемое время;
• очередь cron не растёт после нескольких часов работы.

Если после всех проверок задачи всё равно не выполняются, проблема, скорее всего, уже не в самом WP-Cron. Тогда нужно смотреть конкретный плагин, который регистрирует событие, или ограничения хостинга на фоновые процессы.