WP-Cron в WordPress удобен только до тех пор, пока сайт не начинает жить на реальном трафике, кэше и тяжёлых плагинах. Тогда отложенные задачи — публикация записей, очистка транзиентов, отправка писем, фоновые обновления — начинают зависеть не от расписания, а от того, пришёл ли кто-то на сайт в нужный момент. На низком трафике это даёт задержки, на высоком — лишнюю нагрузку и дублирующиеся запуски.
Если у вас уже есть симптомы вроде «запланированная запись вышла с опозданием», «очистка кэша срабатывает рывками» или «в wp-cron.php видно много обращений», имеет смысл отключить встроенный псевдокрон и перевести задачи на системный cron на сервере.
Когда WP-Cron мешает, а не помогает
WP-Cron — это не настоящий демон. Он запускается при обращении к сайту, если WordPress видит, что есть задачи по расписанию. Из-за этого поведение зависит от условий хостинга и посещаемости. На практике проблемы обычно такие:
- запланированные публикации выходят с задержкой;
- фоновые задачи запускаются несколько раз подряд при одновременных запросах;
- на слабом хостинге
wp-cron.phpсоздаёт лишние пики нагрузки; - кэш или CDN маскируют реальные обращения, и расписание «просыпается» нерегулярно.
Как понять, что проблема именно в WP-Cron
Проверять нужно не по ощущениям, а по фактам. Откройте список запланированных событий через WP-CLI, если он доступен:
wp cron event listЕсли WP-CLI нет, посмотрите в админке поведение конкретных задач: публикации, очистка кэша, отправка очередей, резервные копии. Если они срабатывают только после посещения сайта или с заметной задержкой, это типичный признак зависимости от WP-Cron.
Дополнительно полезно посмотреть логи веб-сервера и убедиться, что wp-cron.php вызывается слишком часто или, наоборот, почти не вызывается. На некоторых сайтах это видно по множеству коротких запросов без полезной нагрузки.
Что меняем: схема с системным cron
Идея простая: WordPress перестаёт сам запускать WP-Cron при каждом визите, а сервер по расписанию обращается к wp-cron.php отдельно. Так вы контролируете частоту запусков и убираете зависимость от трафика.
Есть два рабочих подхода:
| Способ | Что делаем | Плюсы | Минусы |
|---|---|---|---|
| Через код | Отключаем внутренний запуск WP-Cron в wp-config.php | Прозрачно, без лишних плагинов | Нужно иметь доступ к файлам и cron на сервере |
| Через плагин | Используем плагин для управления cron-задачами | Удобно смотреть расписание | Само отключение WP-Cron всё равно делается на уровне конфигурации |
Если задача только в замене механизма запуска, кодовый вариант обычно чище. Если нужно ещё и разбирать список событий, смотреть ошибки и вручную запускать задачи, можно временно подключить инструмент для диагностики, но не путать его с самой настройкой.
Пошаговая настройка
1. Отключите внутренний запуск WP-Cron
Откройте wp-config.php и добавьте строку выше комментария /* That's all, stop editing! */:
define( 'DISABLE_WP_CRON', true );Это отключит автоматический запуск при обычных посещениях сайта. Сам файл wp-cron.php при этом остаётся доступным, и именно его будет вызывать системный cron.
2. Создайте задачу cron на сервере
На большинстве хостингов cron настраивается в панели управления. Если у вас есть доступ к shell, можно использовать обычный crontab. Пример запуска каждые 5 минут:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Замените example.com на ваш домен. Если сайт закрыт базовой авторизацией или ограничен по IP, этот способ может не подойти без дополнительной настройки доступа.
На некоторых серверах надёжнее использовать wget:
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Интервал в 5 минут — распространённый рабочий вариант, но он не универсален. Если у вас много фоновых задач, интервал подбирают по фактической нагрузке и допустимой задержке публикаций. Ставить cron каждую минуту без причины обычно не нужно.
3. Проверьте, что сервер действительно вызывает cron
После настройки откройте список событий и убедитесь, что задачи исполняются по расписанию. Если есть WP-CLI:
wp cron event listСмотрите на столбцы с ближайшим запуском и именем hook. Если задачи зависают в прошлом или не меняют статус после ожидаемого времени, значит вызов не проходит или блокируется.
Если WP-CLI нет, проверьте вручную:
- создайте тестовую запланированную запись на 5–10 минут вперёд;
- дождитесь времени публикации без захода в админку;
- посмотрите, вышла ли запись вовремя;
- проверьте логи сервера на наличие запросов к
wp-cron.php.
Диагностика после внедрения
Самая частая ошибка — отключить WP-Cron и забыть настроить системный cron. В этом случае сайт выглядит нормально, но все фоновые задачи перестают выполняться. Поэтому после внедрения проверяйте не только публикации, но и всё, что завязано на расписание:
- отложенные записи;
- очистку транзиентов и кэша;
- задачи плагинов резервного копирования;
- рассылки и очереди уведомлений;
- автообновления, если они используются.
Если есть доступ к базе и вы хотите понять, какие события вообще зарегистрированы, можно посмотреть их через WP-CLI или через плагины диагностики cron. Но для рабочей проверки обычно достаточно двух вещей: задача видна в расписании и реально исполняется в нужное время.
Частые ошибки и как их исправить
Ставят cron слишком редко
Если запускать wp-cron.php раз в час, запланированные публикации и фоновые задачи будут опаздывать. Для большинства сайтов разумнее начинать с 5 минут и уже потом смотреть на нагрузку и точность.
Оставляют одновременно два механизма
Иногда системный cron настраивают, но DISABLE_WP_CRON не добавляют. Тогда WordPress продолжает запускать задачи при визитах, а сервер — ещё и по расписанию. Результат: дублирующиеся вызовы и лишняя нагрузка.
Используют неправильный URL
Если сайт работает на HTTPS, а cron стучится в HTTP-версию, возможны редиректы и лишние задержки. Если сайт в подкаталоге или за прокси, проверьте, что cron вызывает именно тот адрес, по которому WordPress доступен снаружи.
Блокируют доступ к wp-cron.php на уровне сервера
Иногда из соображений безопасности файл закрывают в .htaccess или правилах nginx, а потом удивляются, что задачи не работают. Полностью запрещать доступ нельзя, если вы всё ещё хотите запускать cron через HTTP. Лучше ограничивать частоту и следить за логами, а не ломать механизм.
Практические советы по безопасности и производительности
Если сайт живёт на нагрузке, cron лучше запускать не через браузерный запрос с длинной цепочкой редиректов, а через прямой вызов конечного URL. Это уменьшает лишние переходы и делает поведение предсказуемее.
Ещё один полезный момент: не ставьте слишком много тяжёлых задач на одну и ту же минуту. Если несколько плагинов одновременно чистят кэш, пересчитывают индексы и отправляют письма, cron может упереться в лимиты PHP или базы. В таких случаях помогает разнести расписание по времени.
Если вы используете плагины, которые активно работают с отложенными задачами, имеет смысл периодически смотреть список cron-событий и удалять лишние записи от удалённых плагинов. Это уменьшает шум в расписании и снижает риск повторных ошибок.
Как проверить, что всё работает стабильно
После настройки не ограничивайтесь одной тестовой публикацией. Проверьте несколько сценариев подряд:
- создайте отложенную запись;
- дождитесь её публикации без ручного захода в админку;
- запустите задачу, которую использует ваш кэширующий или SEO-плагин;
- посмотрите, нет ли ошибок в логах PHP и веб-сервера;
- сравните время запуска до и после перехода на системный cron.
Если всё исполняется без задержек и без повторных запусков, схема настроена правильно. Если задачи всё ещё «засыпают», проблема может быть не в WP-Cron, а в блокировке исходящих запросов, ограничениях хостинга или ошибках в самих плагинах.
Для сайтов, где нужно ещё и чистить дубли, управлять SEO-настройками и убирать лишние системные запросы, иногда удобнее использовать набор инструментов вроде Clearfy Pro, но сам принцип замены WP-Cron на системный cron от этого не меняется: сначала отключаем внутренний запуск, потом даём серверу стабильное расписание.