Если на сайте периодически всплывают задержки в админке, а в логах видно частые обращения к wp-cron.php, проблема часто не в «медленном хостинге», а в том, как WordPress запускает фоновые задачи. По умолчанию cron в WordPress не является настоящим системным планировщиком: он срабатывает на обычных HTTP-запросах. На небольшом сайте это незаметно, но на посещаемом проекте или на сайте с тяжёлыми плагинами такая схема может создавать лишнюю нагрузку и запускать задачи не в тот момент, когда это удобно серверу.
Когда WordPress Cron становится проблемой
Сценарий обычно узнаваемый: на сайте есть отложенные публикации, отправка писем, очистка кэша, синхронизация с внешними сервисами или задачи плагинов безопасности. Всё это висит на WP-Cron. Если трафик неровный, задачи могут запускаться с задержкой. Если трафик высокий, wp-cron.php может дергаться слишком часто и создавать лишние запросы к базе.
Как понять, что дело именно в cron
Проверять стоит не по ощущениям, а по симптомам:
- отложенные записи публикуются с опозданием;
- в панели задач плагинов видно, что события «застревают»;
- в логах веб-сервера много запросов к
/wp-cron.php?doing_wp_cron=...; - на слабом хостинге растёт время ответа в моменты фоновых задач;
- после очистки кэша или массовых изменений в админке сайт кратковременно тормозит.
Если у вас есть доступ к логам, полезно посмотреть частоту обращений к wp-cron.php. Если запросы идут почти на каждый визит, а сайт при этом не нуждается в запуске фоновых задач именно от посетителей, имеет смысл перенести cron на системный уровень.
Что именно меняем: сравнение вариантов
Есть три рабочих подхода. Выбор зависит от того, есть ли доступ к панели хостинга или SSH, и насколько критична точность расписания.
| Вариант | Когда подходит | Минус |
|---|---|---|
| Оставить WP-Cron как есть | Небольшой сайт, редкие задачи, нет доступа к серверу | Зависит от трафика, возможны задержки |
| Отключить WP-Cron и запускать через системный cron | Нужна стабильность и предсказуемость | Требуется доступ к cron на сервере |
| Использовать внешний cron-сервис | Нет доступа к серверному cron, но можно дергать URL по расписанию | Нужно следить за доступностью внешнего сервиса |
Для большинства сайтов на WordPress лучше второй вариант: отключить внутренний запуск и повесить вызов на системный cron. Это не ускоряет сайт магически, но убирает случайные срабатывания на фронтенде и делает выполнение задач более предсказуемым.
Пошаговое решение: отключаем WP-Cron и включаем системный cron
Шаг 1. Отключите встроенный запуск cron
Откройте wp-config.php и добавьте строку выше комментария /* That's all, stop editing! */:
define( 'DISABLE_WP_CRON', true );После этого WordPress перестанет запускать cron при обычных посещениях сайта. Но сами задачи никуда не исчезнут — их теперь должен запускать внешний планировщик.
Шаг 2. Создайте системную задачу на сервере
Если у вас есть SSH и обычный Linux-cron, добавьте задачу, которая будет вызывать wp-cron.php по расписанию. Часто достаточно интервала раз в 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Важно: подставьте реальный домен сайта. Если сайт работает по HTTPS с корректным сертификатом, используйте именно HTTPS, а не HTTP.
Шаг 3. Проверьте, не блокирует ли хостинг запросы
Некоторые хостинги режут исходящие HTTP-запросы с самого же сервера или ограничивают частоту обращений. Если cron не срабатывает, проверьте:
- открывается ли
/wp-cron.phpв браузере без редиректов и ошибок; - не закрыт ли доступ к файлу правилами безопасности;
- не требует ли сайт авторизации, нестандартного домена или защиты по IP;
- не ломает ли запрос WAF или модуль защиты от ботов.
Шаг 4. Если нужен более надёжный запуск, используйте PHP CLI
На части серверов удобнее запускать cron не через HTTP, а напрямую через PHP CLI. Тогда не участвует веб-сервер, и задача меньше зависит от сетевого стека.
*/5 * * * * /usr/bin/php -q /var/www/example.com/public_html/wp-cron.php > /dev/null 2>&1Путь к PHP и к файлу сайта нужно брать из конфигурации вашего хостинга. Не копируйте команду вслепую: на разных серверах путь к бинарнику PHP отличается.
Как проверить, что решение сработало
Проверка нужна не только после настройки, но и через несколько часов работы. Иначе легко пропустить ситуацию, когда cron формально включён, но задачи всё равно не исполняются.
- Откройте
wp-admin/tools.php?page=site-healthи посмотрите, нет ли предупреждений о cron. - Проверьте публикацию отложенной записи: она должна выйти в назначенное время или с минимальным отклонением.
- Посмотрите логи веб-сервера: запросов к
wp-cron.phpот обычных посетителей должно стать меньше. - Если используете плагины с собственными очередями задач, проверьте их статус после нескольких циклов cron.
Для более точной диагностики можно временно добавить небольшой лог в отдельный mu-plugin или в functions.php темы, чтобы увидеть, вызывается ли cron вообще. Но не оставляйте такой код на постоянной основе в продакшене.
<?php
add_action( 'init', function () {
if ( defined( 'DOING_CRON' ) && DOING_CRON ) {
error_log( 'WordPress cron is running: ' . gmdate( 'c' ) );
}
} );Этот пример нужен только для проверки. Если логирование включено постоянно, следите за размером лог-файла и не пишите туда лишнее.
Частые ошибки и как их исправить
Отключили WP-Cron, но системный cron не добавили
Это самая неприятная ошибка: сайт перестаёт выполнять фоновые задачи вообще. Отложенные публикации зависают, письма не уходят, очистка кэша не происходит. Если уже добавили DISABLE_WP_CRON, сразу же проверьте наличие внешней задачи на сервере.
Ставят слишком редкий интервал
Если cron запускается раз в час, а на сайте часто есть отложенные публикации или очередь уведомлений, задачи будут заметно опаздывать. Для большинства сайтов разумнее начать с 5 минут и потом смотреть по нагрузке и фактическим задержкам.
Используют неправильный путь к PHP
Команда в cron может не выполняться просто потому, что /usr/bin/php на сервере отсутствует. Проверяйте путь через панель хостинга или по SSH командой which php. Если доступа к SSH нет, ищите документацию хостинга.
Запускают cron через URL, который закрыт защитой
Если на сайте включены жёсткие правила безопасности, basic auth или ограничение по IP, запрос к wp-cron.php может получать 401/403. В таком случае либо настраивайте исключение, либо используйте запуск через PHP CLI.
Что учесть по безопасности и производительности
С точки зрения безопасности сам по себе системный cron не опасен. Опасно другое: оставлять открытый и часто вызываемый wp-cron.php на сайте с высокой посещаемостью, если фоновых задач много и они тяжёлые. В этом случае нагрузка может расти неравномерно, а часть задач будет выполняться в момент пиковой активности пользователей.
Если сайт большой, полезно дополнительно посмотреть, какие плагины создают больше всего cron-событий. Иногда проблема не в WordPress, а в одном плагине, который планирует слишком много повторяющихся задач. Тогда имеет смысл:
- отключить ненужные фоновые функции плагина;
- сократить частоту его задач, если это допускает настройка;
- заменить тяжёлый плагин на более лёгкий аналог;
- перенести массовые операции в отдельный серверный скрипт, если это ваш код.
Если вы регулярно чистите сайт от технического мусора, дубликатов и лишних скриптов, полезно держать под рукой инструменты вроде Clearfy Pro. Но сам cron он не заменяет: задача всё равно остаётся серверной.
Когда лучше не отключать WP-Cron
Есть случаи, где трогать схему запуска не стоит без необходимости. Например, если сайт живёт на простом shared-хостинге без доступа к cron, а фоновые задачи редкие и не мешают работе. В такой конфигурации лучше оставить всё как есть, чем сломать расписание из-за неудачной настройки.
Также не стоит отключать WP-Cron, если вы не понимаете, какие плагины на нём завязаны. Сначала посмотрите, как ведут себя отложенные публикации, резервные копии, очереди отправки писем и интеграции с внешними сервисами. Потом уже переносите запуск на серверный уровень.
Практический критерий простой: если сайт должен выполнять задачи предсказуемо, а не «когда кто-то зашёл», системный cron почти всегда удобнее. Если же доступов к серверу нет, лучше не усложнять схему без необходимости и ограничиться мониторингом расписания в админке и логах.
