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

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

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

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

Проблема обычно заметна не сразу. Сайт может работать нормально, пока не появляются отложенные публикации, регулярные импорты, резервные копии или плагины с фоновыми очередями. Тогда всплывают типичные симптомы:

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

Если у вас один из этих сценариев, перевод на системный cron обычно дает более предсказуемое поведение. Но сначала стоит понять, что именно запускается и как часто.

Быстрая диагностика

Проверьте, есть ли в wp-config.php уже заданный константный режим cron. Если там стоит define('DISABLE_WP_CRON', true);, WordPress не будет запускать внутренний cron при посещениях. Если константы нет, cron работает по умолчанию.

Посмотреть запланированные события можно через WP-CLI, если он доступен:

wp cron event list

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

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

Самый безопасный путь — не удалять ничего лишнего, а только отключить автоматический запуск cron при веб-запросах. Для этого в wp-config.php добавляют константу:

define('DISABLE_WP_CRON', true);

Размещать ее лучше рядом с другими настройками WordPress, до строки /* That's all, stop editing! Happy publishing. */. После этого WordPress перестанет пытаться запускать cron на каждом хите.

Важно: это не выключает сами задачи. Оно только отключает триггер по посещению сайта. Чтобы задачи продолжили выполняться, нужен системный cron на сервере.

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

На большинстве Linux-серверов достаточно добавить задание в crontab. Самый распространенный вариант — дергать файл wp-cron.php через HTTP или через PHP CLI. Если есть доступ к PHP CLI и путь к WordPress известен, удобнее использовать именно его: меньше зависимостей от веб-сервера и SSL.

Пример для запуска раз в 5 минут через PHP CLI:

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

Если путь к PHP отличается, его нужно уточнить на сервере. На shared-хостингах это часто /usr/local/bin/php или другой путь, который показывает поддержка хостинга.

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

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

Этот вариант проще, но он зависит от доступности сайта по HTTP и может упираться в защиту, редиректы или ограничения на уровне CDN.

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

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

Подход	Плюсы	Минусы
Плагин	Не нужен доступ к серверу, удобно для новичков	Дополнительная нагрузка, зависимость от плагина, не всегда решает проблему полностью
Код в `wp-config.php`	Просто, прозрачно, стандартный способ	Нужен доступ к файлам сайта
Системный cron	Предсказуемый запуск, меньше лишних вызовов на фронтенде	Нужен доступ к cron на сервере

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

Пошаговая настройка без лишних рисков

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

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

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

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

Откройте сайт в браузере несколько раз и посмотрите, не растет ли нагрузка на фоне cron-запросов.
Выполните wp cron event list и убедитесь, что события не зависают в статусе ожидания слишком долго.
Создайте тестовую отложенную запись на ближайшее время и проверьте фактическое время публикации.
Если используете логи сервера, найдите обращения к wp-cron.php и посмотрите, что они идут по расписанию, а не хаотично.

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

wp cron event run --due-now

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

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

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

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

Слишком редкий интервал запуска

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

Неправильный путь к PHP или wp-cron.php

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

HTTP-вызов блокируется защитой

Если вы запускаете cron через URL, его может блокировать basic auth, firewall, WAF или правила безопасности. В таком случае лучше перейти на PHP CLI. Это надежнее и меньше зависит от внешних факторов.

Безопасность и производительность

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

Для безопасности не открывайте wp-cron.php лишним людям и не публикуйте служебные URL в открытом доступе без необходимости. Если используете HTTP-вызов, убедитесь, что сайт корректно отвечает по HTTPS и не уходит в бесконечные редиректы.

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

Когда лучше не отключать WP-Cron

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

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