Если WordPress начал заметно грузить сайт, а задачи вроде публикации по расписанию, проверки обновлений или отправки писем срабатывают нестабильно, проблема часто не в самом cron, а в wp-cron.php. В WordPress это не настоящий системный cron, а псевдокрон: он запускается при обычных посещениях сайта. На небольших проектах это обычно незаметно, но на нагруженных или редко посещаемых сайтах такой механизм даёт лишние запросы и непредсказуемое время запуска задач.
В таких случаях имеет смысл отключить встроенный псевдокрон и перенести запуск на серверный cron. Тогда задачи WordPress будут выполняться по расписанию операционной системы, а не только когда кто-то открыл страницу сайта.
Когда wp-cron лучше отключить
Отключение оправдано не всегда. Если сайт маленький, посещаемость умеренная и проблем с расписанием нет, трогать ничего не нужно. Но серверный cron обычно полезен, когда:
- сайт получает много посещений, и каждый визит потенциально может триггерить проверку cron-задач;
- хостинг ограничивает ресурсы, а лишние обращения к
wp-cron.phpсоздают нагрузку; - задачи должны запускаться предсказуемо, а не «когда-нибудь при следующем визите»;
- на сайте бывают задержки с публикацией записей по расписанию или с выполнением фоновых задач;
- страница
wp-cron.phpчасто вызывается в логах, хотя пользы от этого немного.
Если у вас есть плагин, который активно использует отложенные события, переход на системный cron обычно делает работу стабильнее. Но перед изменениями стоит понимать, что после отключения встроенного механизма WordPress сам по себе больше не будет запускать cron-задачи на каждом заходе пользователя.
Что именно нужно изменить в WordPress
Схема простая: WordPress перестаёт запускать псевдокрон при посещениях, а сервер по расписанию обращается к файлу wp-cron.php. Для этого в wp-config.php добавляют константу:
define( 'DISABLE_WP_CRON', true );Эту строку обычно вставляют выше строки /* That's all, stop editing! Happy publishing. */. Если у вас уже есть другие define(), добавьте рядом с ними, но не дублируйте одну и ту же константу дважды.
После этого WordPress перестанет пытаться запускать cron при каждом просмотре страниц. Но сами задачи никуда не исчезнут — их просто должен будет вызывать серверный планировщик.
Как настроить нормальный cron на сервере
Дальше нужен cron-задание на стороне сервера. Самый практичный вариант — запускать wp-cron.php раз в 5 минут. Для большинства сайтов этого достаточно, а точный интервал можно подстроить под нагрузку и требования к расписанию.
Команда зависит от того, как именно устроен хостинг. На обычном Linux-сервере часто используют curl или wget. Пример для curl:
*/5 * * * * curl -s https://wp24.ru/wp-cron.php?doing_wp_cron > /dev/null 2>&1Если на сервере удобнее wget, команда будет такой:
*/5 * * * * wget -q -O - https://wp24.ru/wp-cron.php?doing_wp_cron > /dev/null 2>&1Здесь важно заменить https://wp24.ru на реальный адрес вашего сайта, если вы настраиваете это не для домена из примера. Параметр ?doing_wp_cron WordPress использует как служебный маркер, а перенаправление вывода в /dev/null не даёт cron слать лишнюю почту о каждом запуске.
Если у вас есть доступ к панели хостинга, cron обычно настраивается там: в cPanel, Plesk или аналогичном интерфейсе. На VPS и выделенном сервере запись добавляют в crontab пользователя, под которым работает сайт. Важно, чтобы команда выполнялась от имени правильного пользователя и имела доступ к сайту и сети.
Что выбрать: curl, wget или системный PHP
Для большинства сайтов достаточно HTTP-запроса к wp-cron.php. Это самый простой и совместимый вариант. Но на некоторых хостингах надёжнее запускать WordPress через PHP CLI, если он доступен и корректно настроен. Тогда cron вызывает не URL, а скрипт через интерпретатор PHP. Такой вариант встречается реже и требует точного пути к PHP и к файлам сайта, поэтому без необходимости усложнять схему не стоит.
Если вы не уверены, начинайте с curl или wget. Для типового WordPress-сайта этого обычно достаточно.
Как проверить, что всё работает
После настройки не ограничивайтесь тем, что cron-задание «сохранилось в панели». Нужно убедиться, что WordPress действительно получает вызов и выполняет задачи.
Проверьте несколько вещей:
- откройте сайт и убедитесь, что он работает как обычно;
- посмотрите, не появляются ли ошибки в логах сервера или хостинга;
- в админке WordPress проверьте, публикуются ли отложенные записи в нужное время;
- если используете плагины с фоновой обработкой, убедитесь, что их задачи тоже выполняются;
- при необходимости временно откройте
https://ваш-домен/wp-cron.php?doing_wp_cronв браузере и убедитесь, что запрос не даёт ошибки сервера.
Сам по себе ответ страницы wp-cron.php не всегда выглядит «красиво» — это нормально. Важнее, чтобы запрос проходил без 500-й ошибки и задачи в WordPress перестали зависать.
На что обычно спотыкаются при переходе
Самая частая ошибка — отключить wp-cron, но не добавить серверное задание. В этом случае расписание в WordPress просто перестаёт работать: не публикуются записи, не запускаются фоновые процессы, не выполняются отложенные действия плагинов.
Вторая проблема — слишком редкий запуск. Если cron стоит раз в час, а на сайте есть задачи с более коротким интервалом, они будут выполняться с задержкой. Для большинства проектов интервал в 5 минут — разумный стартовый вариант.
Ещё один момент — ограничения хостинга. Некоторые shared-хостинги блокируют исходящие запросы или режут частые обращения к одному и тому же URL. Если cron не срабатывает через curl или wget, проверьте документацию хостинга или попробуйте другой способ запуска, который он поддерживает.
Если сайт работает через несколько доменов, поддоменов или за прокси, убедитесь, что cron обращается именно к тому адресу, который открывает WordPress без редиректов и ошибок SSL. Лишние перенаправления не всегда ломают задачу, но иногда делают запуск менее предсказуемым.
Когда лучше не отключать встроенный cron
Если сайт небольшой, посещаемость низкая, а задачи выполняются без сбоев, переход на серверный cron может быть просто лишней работой. Встроенный механизм удобен тем, что не требует доступа к панели хостинга или SSH. Но как только появляются задержки, лишняя нагрузка или нестабильность, системный cron даёт более управляемое поведение.
Практически это выглядит так: для простого сайта можно оставить всё как есть, а для проекта, где важна предсказуемость, отключить wp-cron и вынести запуск на сервер. Это не «ускорение WordPress» само по себе, а нормализация фоновых задач, которые раньше зависели от посещаемости.
Если после переноса задачи всё равно выполняются с задержкой, проверяйте уже не WordPress, а серверную часть: доступность cron, права пользователя, логи и ограничения хостинга. В большинстве случаев проблема находится именно там, а не в wp-cron.php как таковом.