Если на сайте регулярно срываются запланированные публикации, письма из плагинов уходят с задержкой, а wp-cron.php срабатывает только при посещениях, проблема часто не в самом WordPress, а в его псевдокроне. На небольших сайтах это терпимо, но на проектах с редкими визитами или высоким трафиком лучше вынести запуск задач в системный планировщик сервера.
Ниже — рабочая схема: отключаем внутренний запуск cron в WordPress, настраиваем системный cron и проверяем, что задачи действительно выполняются вовремя.
Когда WordPress Cron начинает мешать
WordPress Cron — это не настоящий демон. Он запускается при обращении к сайту, проверяет очередь задач и выполняет то, что просрочено. Из-за этого возникают типовые симптомы:
- запланированные записи публикуются с опозданием;
- плагины резервного копирования стартуют не по расписанию;
- на страницах с высокой нагрузкой видно лишние обращения к
wp-cron.php; - на сайте с низким трафиком задачи могут не запускаться часами.
Диагностика проблемы
Сначала проверьте, есть ли вообще зависшие события. Удобнее всего это делать через WP-CLI, если он доступен:
wp cron event listВ списке смотрите на просроченные события и повторяющиеся задачи. Если WP-CLI нет, можно временно поставить плагин для просмотра cron-событий, но для постоянной работы лучше не держать лишний админский инструмент без необходимости.
Еще один признак — частые запросы к /wp-cron.php?doing_wp_cron=... в логах веб-сервера. Если они идут почти на каждый визит, WordPress сам себя дергает слишком часто.
Как правильно отключить встроенный запуск cron
Отключение делается через wp-config.php. Это безопаснее, чем править ядро или пытаться отключать cron через случайные плагины.
define( 'DISABLE_WP_CRON', true );Строку добавляют до комментария /* That's all, stop editing! Happy publishing. */. После этого WordPress перестанет запускать cron при каждом посещении сайта.
Важно: эта константа не отключает сами задания. Она только убирает автоматический запуск через HTTP. Очередь событий останется, но выполнять ее будет уже серверный планировщик.
Настройка системного cron на сервере
Дальше нужен cron-запуск, который будет дергать wp-cron.php по расписанию. Частота зависит от сайта: для новостного проекта обычно ставят чаще, для корпоративного — реже. Универсального значения нет, но запуск раз в 5 минут — распространенная рабочая схема.
Вариант через wget
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1Если на сервере нет wget, можно использовать curl:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Для сайтов с HTTPS и нормальным сертификатом этого достаточно. Если сайт защищен базовой авторизацией, staging-окружением или нестандартным доступом, URL нужно адаптировать под реальную схему доступа.
Что лучше: плагин, код или серверный cron
| Подход | Плюсы | Минусы |
|---|---|---|
| Плагин для cron | Просто включить | Лишняя зависимость, не всегда прозрачно работает |
Только DISABLE_WP_CRON | Убирает лишние HTTP-запуски | Без серверного cron задачи не выполнятся |
| Системный cron | Предсказуемое расписание, меньше нагрузки на сайт | Нужен доступ к панели хостинга или SSH |
Пошаговая схема внедрения
- Проверьте текущие cron-события через WP-CLI или админский инструмент.
- Добавьте
define( 'DISABLE_WP_CRON', true );вwp-config.php. - Настройте cron на сервере с интервалом, который соответствует задачам сайта.
- Откройте логи и убедитесь, что запросы к
wp-cron.phpидут по расписанию, а не при каждом посещении. - Проверьте плагины, которые завязаны на расписание: бэкапы, рассылки, очистку, публикации.
Как проверить, что решение сработало
Проверка должна быть не формальной, а практической. Сначала создайте тестовое событие. Например, можно запланировать публикацию записи на ближайшие 5–10 минут или включить тестовую задачу в плагине, который использует cron.
Затем проверьте три вещи:
- в
wp cron event listнет зависших просроченных задач; - в логах сервера cron-запросы идут по расписанию;
- запланированная запись публикуется без ручного обновления сайта.
Если используете WP-CLI, полезно дополнительно посмотреть конкретные события:
wp cron event list --fields=hook,next_run,recurrenceТак проще увидеть, какие хуки живут по расписанию и не застревают ли они в очереди.
Частые ошибки и как их исправить
Cron отключили, но серверный запуск не настроили
Это самая неприятная ошибка: сайт выглядит рабочим, но задачи перестают выполняться. После включения DISABLE_WP_CRON обязательно проверьте, что cron в панели хостинга или в crontab реально создан.
Слишком частый запуск
Если дергать wp-cron.php каждую минуту без необходимости, можно получить лишнюю нагрузку. Для большинства сайтов достаточно интервала в несколько минут. Если задач мало, не стоит превращать cron в постоянный фоновой шум.
Неверный URL сайта
На multisite, staging-доменах и сайтах с редиректами иногда указывают не тот адрес. В результате cron-запросы уходят, но WordPress их не обрабатывает как надо. Проверьте именно тот домен, который обслуживает сайт в продакшене.
Плагины с собственной логикой расписания
Некоторые плагины запускают тяжелые задачи через cron и при этом не показывают явных ошибок. Если после переноса на системный cron что-то ломается, смотрите журнал ошибок PHP и логи самого плагина, если они есть.
Безопасность и производительность
Системный cron обычно лучше для производительности, потому что убирает лишние обращения к сайту от случайных посетителей. Но есть и нюанс: URL wp-cron.php становится предсказуемой точкой входа для фонового запуска. Это нормально, если сайт защищен стандартно и не содержит лишних открытых механизмов.
Если у вас высокий трафик, полезно дополнительно следить за тем, чтобы cron-задачи не выполняли тяжелые операции в пиковые часы. Для этого уже нужно смотреть на конкретные плагины и их расписание, а не только на сам WordPress Cron.
Для сайтов, где важна чистота технической части, иногда имеет смысл дополнительно проверить лишние задачи, дубли и автозапуски в админке. Если нужен инструмент для технической уборки и SEO-гигиены, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Что делать, если cron все равно не отрабатывает
Если после настройки задачи продолжают зависать, проверьте по порядку:
- доступен ли сайт по указанному URL без редиректов и ошибок авторизации;
- не блокирует ли хостинг исходящие HTTP-запросы;
- не отключен ли
wp-cron.phpна уровне безопасности или WAF; - нет ли фатальных ошибок в плагинах, которые выполняются по расписанию.
В сложных случаях удобнее временно вернуть встроенный запуск cron, чтобы локализовать проблему. Если с ним задачи начинают работать, значит дело в серверной настройке, а не в WordPress-логике.