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

Если на сайте регулярно всплывают лишние обращения к wp-cron.php, а в пике нагрузки это начинает мешать обычным запросам, проблема часто не в «плохом хостинге», а в том, что WordPress пытается запускать псевдокрон на каждом хите. Для небольшого сайта это терпимо. Для ресурса с заметным трафиком, очередями задач, рассылками или отложенными публикациями — уже нет.

Ниже разберём рабочую схему: отключаем встроенный WP-Cron, ставим системный cron на сервере, проверяем, что задачи продолжают выполняться, и не ломаем отложенные посты, обновления плагинов и фоновые операции.

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

WP-Cron — это не системная служба, а запуск задач при обращении к сайту. WordPress проверяет расписание, когда приходит посетитель или бот, и при необходимости стартует обработчик. Из-за этого возникают типичные симптомы:

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

Если сайт маленький и cron нужен только для редких задач, иногда достаточно оставить всё как есть. Но если вы уже видите, что wp-cron.php фигурирует в метриках и логах слишком часто, лучше перевести запуск на серверный cron.

Диагностика: что проверить до изменений

Перед правкой wp-config.php и настройкой cron полезно понять, какие задачи вообще висят в очереди. Это помогает не искать проблему вслепую.

Проверьте, есть ли зависшие события

Если у вас есть WP-CLI, посмотрите расписание задач:

wp cron event list

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

Посмотрите, не дергается ли wp-cron.php слишком часто

В access-логах веб-сервера или в аналитике запросов найдите обращения к wp-cron.php. Если они идут почти на каждый визит, это нормальное поведение для встроенного механизма, но именно оно и создаёт лишнюю работу. После отключения WP-Cron таких запросов из браузерного трафика быть не должно.

Как отключить WP-Cron правильно

Самый надёжный способ — добавить константу в wp-config.php до строки /* That's all, stop editing! Happy publishing. */.

define( 'DISABLE_WP_CRON', true );

Эта настройка отключает автоматический запуск cron при обычных посещениях сайта. Важно: она не выключает сами задачи WordPress, а только меняет способ их запуска. События по-прежнему будут выполняться, если их запускать извне.

Когда не стоит включать эту константу

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

Настройка системного cron на сервере

Дальше нужен планировщик на стороне сервера. На Linux-хостинге это обычно cron. Задача простая: раз в минуту вызывать wp-cron.php напрямую или через WP-CLI.

Вариант 1: запуск через HTTP-запрос

Если у вас нет WP-CLI, можно использовать curl или wget. Пример записи для crontab:

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

Это рабочий вариант, но у него есть нюансы: запрос идёт через HTTP, значит, сайт должен быть доступен без редиректов и без лишней авторизации. Если домен редиректит с http на https, используйте сразу конечный URL.

Вариант 2: запуск через WP-CLI

Если на сервере есть WP-CLI, лучше использовать его. Тогда cron не зависит от HTTP-стека и работает предсказуемее:

* * * * * cd /var/www/example.com/public_html && wp cron event run --due-now --quiet

Этот вариант удобен тем, что WordPress запускается в своём окружении, а не через внешний запрос. Но он требует корректного пути к сайту и установленного WP-CLI.

Что выбрать: плагин, код или серверный cron

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

Проверка результата после внедрения

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

• Убедитесь, что в wp-config.php добавлена DISABLE_WP_CRON.
• Проверьте, что cron-задание действительно есть в crontab или панели хостинга.
• Посмотрите, выполняются ли запланированные события через wp cron event list.
• Проверьте отложенную публикацию записи: поставьте пост на ближайшее время и дождитесь публикации.
• Откройте логи сервера и убедитесь, что обращения к wp-cron.php не идут на каждый обычный визит.

Если используете WP-CLI, можно вручную проверить выполнение:

wp cron event run --due-now

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

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

Отключили WP-Cron, но не добавили внешний запуск

Это самая частая ошибка. После define( 'DISABLE_WP_CRON', true ); задачи перестают запускаться автоматически. Если не настроен cron на сервере, сайт не будет выполнять расписание. Решение простое: либо верните старое поведение, либо добавьте системный cron.

Поставили cron раз в 5 минут и получили задержки

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

Используют HTTP-запрос, но сайт отвечает редиректом или 403

Если cron вызывает wp-cron.php через HTTP, а сайт закрыт Basic Auth, WAF или нестандартными правилами безопасности, задача не выполнится. В таком случае лучше перейти на WP-CLI.

Сломали права на файлы при настройке через панель хостинга

Иногда после ручного редактирования wp-config.php или правки cron в панели начинают сыпаться ошибки доступа. Проверьте владельца файлов, права на каталог WordPress и логи PHP. Сам cron тут ни при чём, но проблема проявляется именно после внедрения.

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

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

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

Если вам нужен более широкий аудит технических дублей, мусорных настроек и лишних запросов, в экосистеме WPShop есть Clearfy Pro: он помогает с чисткой сайта и рядом SEO-технических правок. Но для самой задачи с WP-Cron достаточно штатных средств WordPress и сервера.

Мини-чек-лист перед выкладкой на прод

• DISABLE_WP_CRON добавлен в wp-config.php.
• Системный cron настроен и запускается по расписанию.
• Проверен ручной запуск wp cron event run --due-now или HTTP-вызов.
• Отложенная публикация работает.
• В логах нет ошибок доступа и бесконечных редиректов.
• Сторонние плагины не завязаны на нестандартный запуск cron через фронтенд.

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