Как настроить системный cron вместо WP-Cron, если в WordPress не выполняются отложенные задачи

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

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

Когда проблема действительно в WP-Cron

Сначала стоит убедиться, что речь не о сломанном плагине или ошибке в задаче. WP-Cron чаще всего проявляет себя так:

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

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

Откройте список запланированных событий через плагин WP Crontrol или через WP-CLI, если он доступен. Важно понять, есть ли очередь задач и не копятся ли они в статусе ожидания. Если задачи есть, но не исполняются, это уже хороший кандидат на замену WP-Cron системным cron.

Если есть доступ к серверу, проверьте, не блокирует ли хостинг вызовы к wp-cron.php. Иногда проблема в настройках безопасности, Basic Auth, ограничениях по IP или в том, что сайт отдаёт редиректы и таймауты на внутренний HTTP-запрос.

Почему WP-Cron работает нестабильно

WP-Cron запускается не по таймеру ОС, а при веб-запросе. Это удобно для простого хостинга, но у механизма есть ограничения:

• на сайте без трафика задачи не стартуют вовремя;
• при большом трафике WP-Cron может запускаться слишком часто и создавать лишнюю нагрузку;
• если сайт закрыт кешем на уровне CDN или reverse proxy, внутренний вызов может вести себя непредсказуемо;
• долгие задачи конкурируют друг с другом и иногда запускаются повторно.

Поэтому для продакшена обычно отключают внутренний запуск WP-Cron и ставят системный cron, который дергает wp-cron.php по расписанию.

Пошаговое решение: отключаем WP-Cron и ставим системный cron

Схема простая: WordPress перестаёт сам инициировать cron при каждом запросе, а сервер вызывает нужный файл по расписанию. Это снижает зависимость от трафика и делает запуск предсказуемым.

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

Откройте wp-config.php и добавьте строку выше комментария /* That's all, stop editing! */:

define( 'DISABLE_WP_CRON', true );

Это отключает автоматический запуск WP-Cron при посещении сайта, но не ломает сами запланированные события. Они по-прежнему будут выполняться, если кто-то вызовет wp-cron.php извне.

Шаг 2. Настройте системный cron на сервере

На Linux-сервере обычно используют crontab. Пример команды, которая запускает cron WordPress каждые 5 минут:

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

Если на сервере есть wget, можно использовать его:

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

Для некоторых хостингов безопаснее запускать cron локально через PHP CLI, если доступен путь к интерпретатору и к файлу WordPress:

*/5 * * * * /usr/bin/php /var/www/example.com/public_html/wp-cron.php > /dev/null 2>&1

Какой вариант выбрать, зависит от хостинга. Если сайт за Cloudflare или другой защитой, HTTP-вызов может упираться в правила WAF. Тогда CLI-вариант обычно надёжнее.

Шаг 3. Убедитесь, что cron не блокируется кешем

Если используете HTTP-вызов, проверьте, не отдаёт ли /wp-cron.php кешированную страницу или редирект. Этот URL должен отрабатывать как технический endpoint, а не как обычная страница сайта. На некоторых конфигурациях помогает исключение wp-cron.php из кеша на уровне nginx, CDN или плагина кеширования.

Сравнение подходов: плагин, ручная настройка, серверный cron

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

Подход	Плюсы	Минусы	Когда подходит
Плагин для контроля cron	Быстро увидеть очередь событий	Не решает проблему запуска сам по себе	Диагностика и разовые проверки
Оставить WP-Cron как есть	Ничего не нужно настраивать	Зависит от трафика и кеша	Тестовые сайты и простые проекты
Системный cron	Предсказуемый запуск, меньше сюрпризов	Нужен доступ к серверу или панели хостинга	Продакшен, низкий трафик, фоновые задачи

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

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

• Откройте список cron-событий и убедитесь, что старые зависшие задачи начали уходить в выполненные.
• Создайте тестовую отложенную запись на ближайшие 5–10 минут и проверьте, публикуется ли она вовремя.
• Если используете плагины с фоновыми задачами, посмотрите их внутренние логи или статус очереди.
• Проверьте access log сервера: должен появиться регулярный вызов wp-cron.php по расписанию.

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

wp cron event list

А для ручного запуска всех ожидающих событий:

wp cron event run --due-now

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

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

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

Это самая частая ошибка. После строки define( 'DISABLE_WP_CRON', true ); сайт перестаёт сам запускать задачи. Если серверный cron не настроен, всё фоновые действия просто остановятся. Проверка простая: если через час после настройки очередь не двигается, cron не работает.

Ставят слишком редкий интервал

Запуск раз в час может быть допустим для редкого сайта, но для публикаций по расписанию и фоновых задач это часто слишком медленно. На практике обычно начинают с 5 минут, а потом смотрят на нагрузку и требования проекта.

Используют HTTP-вызов без учёта защиты

Если wp-cron.php закрыт Basic Auth, WAF или геофильтрацией, запросы из cron будут падать. В таком случае нужно либо разрешить доступ для локального вызова, либо перейти на CLI-вариант.

Не исключают cron из кеша

Если CDN или плагин кеширования вмешивается в ответ wp-cron.php, задача может не стартовать корректно. Проверьте правила исключений и убедитесь, что endpoint отдаётся без кеша.

Путают проблему cron с ошибкой плагина

Если конкретная задача не исполняется даже при ручном запуске wp cron event run --due-now, значит дело не в расписании, а в самом обработчике: конфликт хуков, fatal error, отсутствие нужного файла или неверные аргументы события.

Безопасность и производительность: что учесть на живом сайте

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

Для проектов с высокой нагрузкой полезно:

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

Если на сайте много технических дублей, мусорных мета-тегов и лишних скриптов, имеет смысл параллельно провести чистку. Для этого иногда используют Clearfy Pro, но только как инструмент для конкретных задач: удаление дублей, отключение лишнего и упрощение технической обвязки. Это не замена нормальной серверной настройке cron, а отдельный слой оптимизации: https://wpshop.ru/plugins/clearfy?utm_source=wpdesk.ru&utm_medium=article&utm_campaign=wp-cron-ne-zapuskaetsya-kak-nastroit-sistemnyy-cron

Короткий чек-лист перед выкладкой в продакшен

• DISABLE_WP_CRON добавлен в wp-config.php.
• Системный cron настроен на сервере или в панели хостинга.
• wp-cron.php не кешируется и не ломается защитой.
• Проверен запуск через wp cron event list или лог сервера.
• Тестовая отложенная задача отрабатывает в ожидаемое время.
• Нет накопления просроченных cron-событий.

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