Если на сайте регулярно «плывут» публикации по расписанию, не отправляются письма из форм, не обновляются кэши или зависают фоновые задачи плагинов, часто виноват не сам плагин, а WP-Cron. Это не системный cron, а механизм WordPress, который срабатывает только на входящих запросах. На тихом сайте или при агрессивном кешировании он легко начинает пропускать события.
Ниже — практический разбор: как понять, что проблема именно в WP-Cron, как перевести задачи на системный cron и как проверить, что всё работает после внедрения.
Как понять, что WP-Cron работает нестабильно
Симптомы обычно повторяются изо дня в день. Самый частый сценарий — запланированная запись висит в статусе «Просрочено», хотя в админке всё выглядит нормально. Второй типичный признак — плагины с фоновой обработкой начинают вести себя непредсказуемо: не отправляют отложенные уведомления, не прогоняют очереди, не обновляют индексы.
Что проверить в первую очередь
- Есть ли на сайте публикации со статусом
missed scheduleили просроченные задания в очереди плагинов. - Не стоит ли на сайте агрессивный full-page cache, который почти не даёт живых запросов.
- Не отключён ли WP-Cron через
DISABLE_WP_CRONвwp-config.php. - Нет ли на хостинге ограничений на исходящие HTTP-запросы к самому сайту.
Если сайт посещают редко, WP-Cron может запускаться с большими паузами. Если посещаемость высокая, наоборот, он может срабатывать слишком часто и создавать лишнюю нагрузку. В обоих случаях системный cron обычно предсказуемее.
Диагностика: где именно ломается запуск задач
Перед изменениями полезно посмотреть, какие события вообще запланированы. Для этого удобно использовать WP-CLI, если он доступен на хостинге.
wp cron event listКоманда покажет список событий, время следующего запуска и хук. Если видите много просроченных задач или события, которые не меняют время следующего запуска, это уже повод проверить cron-логи и конфигурацию.
Ещё один полезный тест — открыть сайт с параметром, который принудительно запускает cron-обработчик. В WordPress это внутренний механизм, и напрямую на него обычно не полагаются, но для диагностики можно временно посмотреть, не блокируется ли запрос к wp-cron.php на уровне сервера или безопасности.
Признаки блокировки на стороне сервера
- 403 или 401 на запросы к
/wp-cron.php. - Редиректы, которые уводят cron-запрос в авторизацию или на другую схему URL.
- WAF/ModSecurity, который режет внутренние обращения.
- Кеширующий прокси, который не пропускает служебный запрос как обычный PHP-скрипт.
Если доступ к wp-cron.php ограничен, сначала надо исправить это, а уже потом переводить сайт на системный cron.
Как заменить WP-Cron на системный cron
Смысл решения простой: WordPress перестаёт сам пытаться запускать cron на каждом хите, а сервер по расписанию вызывает отдельный PHP-скрипт. Это надёжнее и обычно дешевле по ресурсам.
Шаг 1. Отключить псевдокрон в WordPress
В wp-config.php добавьте константу:
define( 'DISABLE_WP_CRON', true );После этого WordPress не будет пытаться запускать cron при каждом запросе. Важно: это только половина решения. Если не настроить системный cron, задачи перестанут выполняться совсем.
Шаг 2. Настроить cron на сервере
На большинстве Linux-хостингов достаточно одной записи в crontab. Пример для запуска каждые 5 минут:
*/5 * * * * /usr/bin/php /var/www/site/public_html/wp-cron.php > /dev/null 2>&1Пути /usr/bin/php и /var/www/site/public_html/ нужно заменить на реальные для вашего сервера. Если на хостинге несколько версий PHP, используйте ту, под которой работает сайт.
Некоторые панели предлагают запускать cron через URL. Это рабочий вариант, но для WordPress обычно предпочтительнее запуск PHP-файла напрямую, если хостинг это позволяет.
Шаг 3. Проверить, что cron не конфликтует с кешем
Если сайт стоит за кеширующим слоем, убедитесь, что вызов wp-cron.php не попадает в кеш и не получает HTML-страницу вместо выполнения PHP. Для системного cron это обычно не проблема, но при запуске по URL — частая ошибка.
Сравнение подходов: плагин, код или серверный cron
Иногда задачу можно решить плагином, но для cron это не всегда лучший путь. Ниже — короткое сравнение.
| Подход | Когда подходит | Минусы |
|---|---|---|
| Оставить WP-Cron как есть | Маленький сайт без фоновых задач | Нестабильный запуск, зависимость от трафика |
| Отключить WP-Cron и использовать системный cron | Почта, публикации по расписанию, фоновые очереди | Нужен доступ к панели хостинга или SSH |
| Плагин для управления cron | Когда нужен визуальный контроль задач | Не решает проблему запуска сам по себе |
Если нужен только контроль событий, можно использовать инструменты уровня WP Crontrol, но он не заменяет системный cron. Он помогает увидеть, что именно запланировано, и найти лишние или сломанные события.
Проверка результата после внедрения
После настройки не ограничивайтесь тем, что сайт «вроде бы работает». Проверьте именно cron-задачи.
- Создайте тестовую запись с отложенной публикацией на ближайшие 5–10 минут.
- Посмотрите, меняется ли статус записи в назначенное время.
- Проверьте список cron-событий через
wp cron event list. - Если используете плагины с очередями, убедитесь, что их задания тоже выполняются.
Для более точной проверки можно временно добавить логирование в отдельный mu-plugin или в собственный плагин. Например, если у вас есть собственный cron-хук, можно записывать факт запуска в лог сервера.
add_action( 'my_daily_task', function () {
error_log( 'my_daily_task executed at ' . current_time( 'mysql' ) );
} );Это не нужно держать постоянно, но на этапе проверки помогает понять, что событие реально доходит до обработчика.
Частые ошибки и как их исправить
Отключили WP-Cron, но не настроили системный cron
После добавления DISABLE_WP_CRON сайт перестаёт выполнять задачи вообще. Исправление очевидное: добавить cron-задание на сервере и проверить путь к PHP.
Запускают cron слишком редко
Если cron стоит раз в час, отложенные публикации и фоновые задачи будут заметно запаздывать. Для большинства сайтов интервал в 5 минут — более практичный компромисс, но окончательный выбор зависит от нагрузки и критичности задач.
Используют URL вместо запуска PHP
Это часто ломается из-за кеша, редиректов, защиты от ботов или авторизации. Если есть доступ к SSH или cron-панели, лучше запускать wp-cron.php как PHP-скрипт.
Путают cron WordPress и cron хостинга
WordPress cron — это механизм планирования задач внутри CMS. Системный cron — это планировщик на уровне сервера. Первый лучше не использовать как единственный источник запуска на продакшене, если сайт зависит от регулярных фоновых процессов.
Практические советы по безопасности и производительности
Если сайт большой, не стоит оставлять WP-Cron включённым «на всякий случай». На нагруженных проектах это создаёт лишние обращения к базе и может мешать предсказуемости. Системный cron даёт более ровную нагрузку и проще мониторится.
Ещё один момент — доступ к wp-cron.php. Не надо закрывать его через robots.txt: это не решает техническую задачу и не влияет на серверные вызовы. Если есть необходимость ограничить внешний доступ, делайте это на уровне веб-сервера аккуратно, чтобы не сломать внутренние вызовы WordPress и плагинов.
Если вы управляете сайтом через Git или деплой, проверьте, что wp-config.php не перезаписывается при выкладке. Иначе константа DISABLE_WP_CRON может исчезать после очередного релиза, а проблема вернётся.
Для сайтов, где важна чистка лишних служебных настроек и дублей, иногда полезно посмотреть в сторону инструментов вроде Clearfy Pro: он не заменяет cron, но помогает убрать часть технического шума в WordPress и упростить сопровождение. Использовать такие плагины стоит только там, где они действительно закрывают конкретную задачу, а не ради «оптимизации вообще».
Если после перехода на системный cron задачи всё ещё срываются, проблема уже не в механизме запуска, а в конкретном хуке, плагине или ограничениях хостинга. Тогда имеет смысл смотреть логи PHP, логи веб-сервера и список запланированных событий по одному, а не лечить WordPress целиком.