WP-Cron в WordPress — это встроенный планировщик задач, который запускает отложенные публикации, проверки обновлений, фоновые задачи плагинов, рассылки и часть процессов WooCommerce. На маленьком сайте его можно оставить как есть, но на проекте с трафиком, магазином или важными заявками в 2026 году лучше заменить «виртуальный» WP-Cron на системный cron хостинга или VPS: так задачи выполняются по расписанию, а не случайно после захода посетителя.
Главная проблема WP-Cron в том, что он не является настоящим серверным cron. WordPress проверяет просроченные события во время HTTP-запросов к сайту и при необходимости вызывает wp-cron.php. Если посетителей мало, задача может опоздать. Если трафика много, лишние проверки могут добавлять нагрузку. Поэтому настройка системного cron — один из тех технических шагов, который не виден пользователю, но повышает стабильность сайта.
⚙️ Что делает WP-Cron и почему он иногда подводит
WP-Cron отвечает за всё, что должно происходить «потом»: публикацию запланированных статей, проверку обновлений ядра и плагинов, очистку временных данных, отправку писем, задачи SEO-плагинов, резервное копирование, импорт товаров, генерацию фидов и фоновые действия WooCommerce. Плагины используют WordPress Cron API, чтобы добавлять свои события без отдельного доступа к серверу.
Это удобно для новичков: сайт работает даже на простом хостинге, где пользователь не знает, что такое crontab. Но модель зависит от посещений. Если ночью никто не открывал сайт, отложенная статья может выйти позже. Если магазин получает много запросов, WordPress может часто проверять планировщик. На больших проектах такая схема превращается в источник нестабильности.
Если вы уже настраивали staging-сайт WordPress для безопасных тестов, WP-Cron стоит проверить там же: включить логирование задач, обновить плагины и посмотреть, какие события создают самую большую очередь.
🚦 Когда обычного WP-Cron достаточно
Оставить стандартный WP-Cron можно, если сайт небольшой: блог, визитка, лендинг услуг, портфолио или проект с редкими обновлениями. Для таких сайтов задержка публикации на несколько минут обычно не критична. Также стандартный вариант подходит, если хостинг сам оптимизирует запуск wp-cron.php и в панели уже есть понятная настройка расписания.
Минимальный набор признаков, что всё нормально: отложенные записи выходят вовремя, письма форм приходят без задержек, плагины резервного копирования создают архивы по расписанию, а в админке нет сообщений о пропущенных событиях. Если сайт ещё не разросся, сначала важнее закрыть базу: скорость, безопасность, понятную структуру и регулярные обновления. Например, проверьте связку из кэша и оптимизации по гайду про Core Web Vitals для WordPress.
- Блог публикует 1–2 статьи в неделю — стандартного WP-Cron обычно хватает.
- Сайт услуг получает заявки через простую форму — достаточно периодически проверять доставку писем.
- Нет WooCommerce, импортов, сложных рассылок и тяжёлых фоновых задач — можно не усложнять.
🛒 Когда нужно переходить на системный cron
Системный cron нужен, когда задержки и пропуски задач начинают стоить денег. Первый пример — WooCommerce. Заказы, статусы оплат, письма клиентам, синхронизация остатков, фиды товаров и Action Scheduler завязаны на фоновые процессы. Если очередь висит, покупатель может оплатить товар, но не получить письмо или доступ к цифровому файлу вовремя. Для магазина это уже не техническая мелочь, а риск поддержки и возвратов.
Второй пример — сайт с автопубликацией и SEO-планом. Если статьи должны выходить по расписанию, а индексация и перелинковка строятся вокруг календаря, случайный запуск от посетителя не подходит. Третий пример — проект на VPS, где вы сами отвечаете за производительность. Если вы уже думаете о переходе по признакам из статьи WordPress на VPS в 2026 году, настройка настоящего cron должна быть в первом техническом чеклисте.
- Есть WooCommerce, LMS, подписки, личный кабинет или платный контент.
- Есть регулярные импорты, экспорты, фиды, рассылки или бэкапы.
- Отложенные записи иногда выходят поздно или не выходят вообще.
- Хостинг показывает всплески нагрузки от частых обращений к
wp-cron.php.
🧰 Как настроить системный cron для WordPress
Схема простая: сначала отключаем автоматический запуск WP-Cron при каждом посещении, затем добавляем серверное расписание, которое само вызывает wp-cron.php. Перед изменениями сделайте резервную копию и проверьте доступ к файлам. Если сайт коммерческий, лучше сначала повторить настройку на копии.
- Сделайте бэкап. Сохраните файлы и базу данных, особенно если параллельно обновляете плагины.
- Откройте
wp-config.php. Добавьте строку до комментария про прекращение редактирования:define('DISABLE_WP_CRON', true); - Создайте cron-задачу на хостинге. В панели управления найдите «Cron jobs», «Планировщик» или похожий раздел.
- Выберите интервал. Для обычного сайта часто достаточно 10–15 минут. Для магазина или активных очередей — 5 минут, если хостинг разрешает.
- Добавьте команду. Самый универсальный вариант:
wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1. Замените домен на свой. - Проверьте результат. Создайте тестовую отложенную запись, запустите бэкап по расписанию и убедитесь, что события выполняются.
На VPS можно использовать и WP-CLI: wp cron event run --due-now --path=/var/www/site. Такой способ аккуратнее для администраторов, потому что запускает задачи через CLI, а не через внешний HTTP-запрос. Но он требует правильного пользователя, пути к сайту и окружения PHP.
🔍 Чеклист проверки после настройки
После включения системного cron важно не просто сохранить команду, а убедиться, что сайт действительно выполняет события. Самая частая ошибка — отключить WP-Cron в wp-config.php, но неправильно указать URL, путь или версию PHP в серверной задаче. Тогда фоновые процессы останавливаются, и проблема становится заметна не сразу.
- Тестовая отложенная запись вышла точно в назначенное время.
- Плагин бэкапов создал архив и отправил его во внешнее хранилище.
- WooCommerce-задачи не копятся в очереди Action Scheduler.
- В логах нет постоянных ошибок 403, 404, 500 или таймаутов при вызове
wp-cron.php. - После настройки не выросли показатели нагрузки и время ответа сайта.
Если на сайте уже настроено кэширование, проверьте, что cron-команда обращается напрямую к wp-cron.php, а не к кэшированной странице. Подробную базу по ускорению можно совместить с материалом как настроить кэширование WordPress. А для коммерческих проектов добавьте регламент: кто проверяет логи, как часто тестируется восстановление и что делать при сбое.
Мой практический совет: для обычного сайта ставьте интервал 10 минут, для магазина — 5 минут, а для тяжёлых импортов выносите отдельные задачи на ночное время. Не превращайте cron в мусорную корзину для всего подряд: если плагин создаёт сотни событий, сначала ищите причину, а не просто увеличивайте частоту запусков.
📌 FAQ: частые вопросы про WP-Cron
Нужно ли отключать WP-Cron на каждом сайте?
Нет. Если сайт маленький, задачи выполняются вовремя и нет WooCommerce или тяжёлых фоновых процессов, стандартный WP-Cron можно оставить. Переход нужен там, где важны точность расписания и стабильная нагрузка.
Какой интервал cron выбрать для WordPress?
Для блога и сайта услуг обычно хватает 10–15 минут. Для интернет-магазина, подписок, автопубликаций и частых фоновых задач чаще выбирают 5 минут. Меньший интервал стоит использовать только если хостинг это разрешает и сервер справляется.
Что будет, если отключить WP-Cron, но не добавить системный cron?
Отложенные записи, проверки обновлений, бэкапы и задачи плагинов могут перестать выполняться. Поэтому сначала подготовьте команду в панели хостинга, затем добавляйте DISABLE_WP_CRON и сразу проверяйте тестовое событие.
Можно ли запускать cron через curl вместо wget?
Да. Часто используют curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1. Главное — чтобы команда стабильно выполнялась на вашем сервере и не блокировалась защитой, редиректами или ошибочным URL.
WP-CLI лучше, чем вызов wp-cron.php по URL?
Для VPS и администраторов — часто да, потому что WP-CLI работает внутри серверного окружения и не зависит от внешнего HTTP-запроса. Но новичку проще начать с команды через URL в панели хостинга.
Связан ли WP-Cron с безопасностью WordPress?
Косвенно да. Через cron выполняются обновления, очистки, бэкапы и задачи защитных плагинов. Но сам по себе системный cron не заменяет базовую защиту: обновления, 2FA, резервные копии и аккуратный выбор плагинов. Проверьте также чеклист как защитить WordPress сайт от взлома.
Что делать, если после настройки задачи всё равно не выполняются?
Проверьте URL, SSL, редиректы, блокировки firewall, версию PHP и логи хостинга. Затем временно включите стандартный WP-Cron обратно и сравните поведение. Если проблема в конкретном плагине, проверьте его очередь задач и документацию.
CTA: если у вас WordPress-сайт с заявками, магазином или регулярной автопубликацией, добавьте проверку WP-Cron в ежемесячный технический аудит. Один корректный cron-задачник часто предотвращает десятки мелких сбоев: от пропущенной статьи до зависшего заказа.