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