Если на сайте регулярно появляются лишние обращения к wp-cron.php, а в пиковые моменты это заметно по нагрузке, проблема часто не в «тяжёлом» плагине, а в том, как WordPress запускает фоновые задачи. По умолчанию WP-Cron срабатывает на обычных посещениях сайта. Для небольших проектов это терпимо, но на нагруженных сайтах, в админке с большим числом плагинов и на хостингах с ограничениями по CPU такой механизм даёт лишние запросы и плохо предсказуемое выполнение задач.
Ниже — рабочая схема: как отключить внутренний запуск WP-Cron, перенести выполнение на системный cron и проверить, что расписания не сломались.
Когда WP-Cron становится проблемой
Симптомы обычно довольно приземлённые. В логах видно частые обращения к /wp-cron.php?doing_wp_cron=..., на страницах с высокой посещаемостью появляются короткие всплески нагрузки, а запланированные задачи то выполняются с задержкой, то запускаются пачкой после простоя сайта. Это особенно заметно, если на сайте есть:
- плагины рассылок и уведомлений;
- планировщики публикаций и отложенных действий;
- регулярные синхронизации с внешними API;
- тяжёлые фоновые задачи в админке.
Важно понимать: WP-Cron — это не настоящий системный демон. Он запускается только когда приходит запрос к сайту. Поэтому на сайте с низким трафиком расписание может «опаздывать», а на сайте с высоким — создавать лишнюю конкуренцию за ресурсы.
Как быстро диагностировать источник нагрузки
Сначала проверьте, действительно ли сайт часто обращается к wp-cron.php. Если есть доступ к логам веб-сервера, ищите строки с этим файлом. Если логов нет, можно временно поставить плагин для мониторинга запросов или посмотреть отчёты хостинга. Дополнительно полезно проверить список запланированных событий через WP-CLI:
wp cron event listЕсли WP-CLI недоступен, можно хотя бы оценить, нет ли у сайта десятков повторяющихся задач от одних и тех же плагинов. Это уже хороший признак того, что внутренний запуск cron лучше вынести наружу.
Что именно нужно изменить
Схема состоит из двух частей. Сначала WordPress перестаёт сам запускать cron при каждом посещении. Затем вы настраиваете системный cron на сервере, который будет вызывать wp-cron.php по расписанию. Так вы убираете случайный запуск по трафику и получаете предсказуемый интервал выполнения задач.
| Подход | Когда подходит | Минус |
|---|---|---|
| Оставить WP-Cron как есть | Небольшой сайт без критичных расписаний | Непредсказуемый запуск и лишние обращения |
| Отключить WP-Cron и использовать системный cron | Сайт с нагрузкой, регулярными задачами и доступом к cron на сервере | Нужно один раз настроить сервер |
| Поставить плагин-обёртку для cron | Если нужен интерфейс для контроля задач | Дополнительный слой и зависимость от плагина |
Пошаговое решение через код и сервер
1. Отключите внутренний запуск WP-Cron
Откройте wp-config.php и добавьте константу до строки /* That's all, stop editing! */:
define( 'DISABLE_WP_CRON', true );Эта настройка запрещает WordPress запускать cron при обычных запросах. Сами события при этом не удаляются — они просто перестают стартовать автоматически от посещений.
2. Настройте системный cron на сервере
Дальше нужен реальный cron в панели хостинга или в crontab. Самый простой вариант — запускать wp-cron.php раз в 5 минут. Для большинства сайтов этого достаточно, но интервал можно подобрать под свои задачи.
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Если на сервере есть WP-CLI и вы хотите избежать HTTP-запроса к сайту, можно использовать более надёжный вариант:
*/5 * * * * cd /var/www/example.com/public_html && wp cron event run --due-now --quietВторой способ обычно удобнее для серверов, где WP-CLI уже установлен и сайт размещён в понятном каталоге. Но если доступа к консоли нет, HTTP-вызов тоже рабочий.
3. Проверьте права и доступность сайта
Если cron запускается через curl, убедитесь, что сайт отвечает без редиректов, которые ломают вызов, и что сервер не блокирует запросы к самому себе. На некоторых хостингах лучше использовать wget -q -O - вместо curl, но принцип тот же: задача должна вызывать wp-cron.php без участия посетителей.
Проверка результата после внедрения
После настройки не ограничивайтесь тем, что «ошибок не видно». Проверьте несколько конкретных вещей.
- В логах веб-сервера больше не должно быть частых обращений к
wp-cron.phpот обычных посетителей. - Запланированные публикации должны выходить вовремя.
- Плагины, которые завязаны на cron, должны продолжать выполнять свои задачи.
- Команда
wp cron event listдолжна показывать события без явных зависших задач.
Если есть WP-CLI, полезно вручную запустить ближайшие события и посмотреть, нет ли ошибок:
wp cron event run --due-nowПосле этого откройте несколько страниц сайта, подождите интервал cron и снова проверьте логи. Если обращения к wp-cron.php исчезли из пользовательского трафика, а задачи продолжают выполняться, схема работает.
Частые ошибки и как их исправить
Отключили WP-Cron, но системный cron не настроили
Это самая неприятная ошибка: сайт перестаёт выполнять отложенные задачи вообще. В результате зависают публикации, не уходят письма, не обновляются кэши и не выполняются фоновые синхронизации. Если уже поставили DISABLE_WP_CRON, сразу проверьте, что внешний cron действительно создан и активен.
Слишком редкий интервал запуска
Иногда cron ставят раз в час, чтобы «не грузить сервер». Для сайта с отложенными публикациями и интеграциями это может быть слишком редко. В результате задачи начинают выполняться с заметной задержкой. Чаще всего разумнее стартовать с 5 минут и уже потом смотреть на нагрузку и требования плагинов.
Запуск через HTTP упирается в редиректы или защиту
Если curl получает 301/302, Basic Auth, WAF-ограничение или блокировку по User-Agent, cron может не сработать. В таком случае лучше перейти на WP-CLI или настроить вызов через локальный путь на сервере, если хостинг это позволяет.
Путают WP-Cron и системный cron
WP-Cron — это механизм WordPress, а системный cron — задача на уровне сервера. Отключение первого не отменяет второго. Если после правки в wp-config.php сайт стал «молчать», проблема почти всегда в том, что внешний cron не был создан или не имеет доступа к файлам сайта.
Что ещё стоит проверить на производительном сайте
Если вы уже трогаете фоновые задачи, имеет смысл посмотреть, нет ли у сайта лишних cron-событий от старых плагинов. Иногда после удаления расширения его задачи остаются в расписании и продолжают запускаться. Для таких случаев полезно просмотреть список событий и убрать мусор вручную, но делать это нужно аккуратно: сначала понять, какой плагин создал событие, и только потом удалять его.
Также не стоит забывать про кэширование. Если сайт активно использует объектный кэш или page cache, cron-задачи могут влиять на прогрев и обновление кэша. После переноса cron на сервер проверьте, не изменилось ли поведение кэширующих плагинов и не стали ли они обновлять данные с задержкой.
Когда лучше не отключать WP-Cron полностью
Если у вас маленький сайт без доступа к cron на сервере, а задачи редкие и не критичные, иногда проще оставить всё как есть. Но даже в этом случае полезно хотя бы понимать, что WP-Cron зависит от посещаемости. Если сайт низкотрафиковый, отложенные действия могут выполняться не по расписанию, а «когда кто-то зайдёт».
Для проектов, где важна предсказуемость, внешний cron почти всегда надёжнее. Это не магическая оптимизация, а нормализация механизма, который WordPress изначально реализует через посещения.
Если нужен более широкий контроль над технической чисткой сайта, дублями и служебными настройками, иногда удобнее закрывать такие задачи через набор инструментов вроде Clearfy Pro, но сам принцип с WP-Cron от этого не меняется: сначала отключаем внутренний запуск, потом даём серверу выполнять расписание по таймеру.