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

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

Типичный сценарий выглядит так: публикации выходят не по расписанию, письма из очереди уходят с опозданием, а в логах видно, что на каждом запросе дергается wp-cron.php. В таких случаях разумнее отключить встроенный запуск и перенести задачи на системный cron сервера.

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

Не стоит трогать планировщик только потому, что он «есть в WordPress». Сначала проверьте симптомы. Если совпадает несколько пунктов, переход на системный cron оправдан.

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

Что именно делает WP-Cron

WordPress хранит расписание событий в базе и пытается запускать их при посещении сайта. Это удобно для простых установок, но плохо предсказуемо. Если трафика мало, задания могут выполняться с опозданием. Если трафика много, запуск может происходить слишком часто и мешать обычным запросам.

Диагностика перед изменениями

Перед отключением встроенного cron полезно посмотреть, какие события вообще запланированы. Для этого можно использовать WP-CLI, если он доступен на хостинге.

wp cron event list

Команда покажет список событий, их расписание и следующую дату запуска. Если в списке много однотипных задач от плагинов, это уже повод проверить, действительно ли они нужны.

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

Как отключить встроенный WP-Cron

Решение состоит из двух частей: отключить автоматический запуск WordPress и добавить системное задание на сервере.

Шаг 1. Добавьте константу в wp-config.php

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

define( 'DISABLE_WP_CRON', true );

После этого WordPress перестанет запускать cron на каждом обычном запросе.

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

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

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

Если на сервере есть доступ к PHP CLI, надежнее вызывать скрипт через PHP, а не через HTTP:

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

Второй вариант зависит от структуры хостинга и пути к PHP. Если не уверены, уточните у поддержки или посмотрите конфигурацию в панели управления.

Что выбрать: HTTP-запрос или PHP CLI

Как проверить, что решение сработало

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

1. Откройте список событий через wp cron event list и посмотрите, обновляется ли поле следующего запуска.
2. Запланируйте тестовую публикацию на ближайшее время и убедитесь, что запись вышла вовремя.
3. Проверьте, не растет ли число обращений к wp-cron.php при обычных визитах на сайт.
4. Если есть кэш или мониторинг, сравните время ответа до и после изменения.

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

wp cron event run --due-now

Если события выполняются, а сайт не делает лишних обращений к wp-cron.php на каждом хите, настройка работает.

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

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

Это самая неприятная ошибка: фоновые задачи перестают запускаться вообще. В результате ломаются отложенные публикации, очистка временных данных, отправка писем и задачи плагинов. Если уже добавили DISABLE_WP_CRON, сразу проверьте расписание на сервере.

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

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

Оставили двойной запуск

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

Хостинг режет исходящие запросы

Если вы используете вариант с curl, некоторые хостинги ограничивают такие обращения или требуют особых настроек безопасности. В этом случае лучше перейти на PHP CLI или уточнить допустимый способ запуска у провайдера.

Практические советы по безопасности и производительности

Если сайт уже обслуживает много фоновых задач, не ограничивайтесь только cron. Посмотрите, какие плагины создают лишнюю активность, и отключите ненужные автозадачи. Иногда проблема не в самом планировщике, а в том, что один плагин создает слишком много событий.

На сайтах с регулярной технической чисткой полезно сочетать перенос cron на сервер с удалением лишних автозагрузок, дублей и мусорных задач. Если нужен инструмент для такой оптимизации, у WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но сам cron он не заменяет — это именно вспомогательный инструмент для чистки и технической оптимизации.

Еще один момент: не ставьте интервал запуска «на глаз». Слишком частый cron тоже вреден, особенно если на сайте тяжелые плагины или медленная база данных. Лучше начать с 5 минут и проверить по логам, хватает ли этого для ваших задач.

Если нужен быстрый чек-лист перед внедрением

• проверить, есть ли запланированные записи и фоновые письма;
• посмотреть список cron-событий через WP-CLI;
• добавить define( 'DISABLE_WP_CRON', true ); в wp-config.php;
• настроить системный cron на сервере;
• проверить публикации, очереди и логи после изменения;
• убедиться, что нет двойного запуска.

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