Как найти и отключить лишние cron-задачи WordPress на VDS

Автор: Владимир Петров | Опубликовано: 26.09.2026

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

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

Когда проблема именно в cron, а не в «медленном хостинге»

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

пики нагрузки повторяются через одинаковые интервалы;
админка открывается медленнее обычного, особенно после простоя;
в логах PHP видно много коротких запросов к wp-cron.php;
после отключения тяжёлого плагина сайт заметно разгружается;
на VDS есть доступ к SSH, и в top или htop видно всплески PHP-FPM или nginx в моменты визитов.

Если сайт маленький, а cron-задач много, WP-Cron может запускаться слишком часто. Если сайт посещаемый, он может запускаться параллельно несколькими запросами и создавать лишнюю конкуренцию за ресурсы.

Что именно искать в первую очередь

Обычно лишнюю нагрузку создают не события ядра, а плагины: резервные копии, SEO-сканеры, статистика, рассылки, импорт/экспорт, очистка временных данных, синхронизация с внешними API. У WordPress есть и штатные задачи, но они редко становятся проблемой сами по себе.

Диагностика: какие cron-события сейчас запланированы

Самый удобный способ — посмотреть расписание через WP-CLI, если он установлен на сервере. Команда покажет все события с интервалами и следующими запусками:

wp cron event list --fields=hook,next_run_relative,recurrence,schedule --format=table

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

Дальше смотрите на такие признаки:

одинаковый hook повторяется слишком часто;
событие запланировано, хотя соответствующий плагин уже удалён;
есть десятки однотипных задач с разными метками времени;
следующий запуск стоит «через минуту» у задач, которые не должны быть частыми.

Как понять, какой плагин создал событие

По названию hook это не всегда очевидно, но часто помогает поиск по коду плагинов. На сервере можно быстро найти упоминание hook в каталоге wp-content/plugins:

grep -R "имя_hook" wp-content/plugins -n

Если hook не находится, проверьте mu-plugins и тему:

grep -R "имя_hook" wp-content/mu-plugins wp-content/themes -n

Когда событие создаёт сторонний плагин, важно не просто удалить задачу, а понять, будет ли она создана снова. Иначе cron вернётся после следующего визита на сайт.

Пошаговое решение: как отключить лишнюю задачу безопасно

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

Подход	Когда подходит	Минус
Удалить одно событие	Задача больше не нужна или осталась после удаления плагина	Может появиться снова, если источник не устранён
Отключить задачу в плагине	Плагин нужен, но его фоновая функция лишняя	Не у всех плагинов есть настройка
Перевести cron на системный	Нужна стабильность и предсказуемость на VDS	Требует доступа к планировщику сервера

1. Удалить конкретное событие через WP-CLI

Если вы точно знаете hook, можно удалить все запланированные экземпляры:

wp cron event delete имя_hook

После этого проверьте список ещё раз:

wp cron event list --fields=hook,next_run_relative --format=table

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

2. Отключить повторное создание события в коде

Когда источник известен, иногда проще убрать конкретную регистрацию cron из дочерней темы или небольшого mu-plugin. Например, если сторонний код добавляет событие через wp_schedule_event(), его можно отменить на уровне своего сайта, если вы понимаете последствия.

<?php
add_action('init', function () {
    $timestamp = wp_next_scheduled('my_plugin_cleanup_event');
    if ($timestamp) {
        wp_unschedule_event($timestamp, 'my_plugin_cleanup_event');
    }
});

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

3. Перенести выполнение WP-Cron на системный cron

На VDS это обычно самый правильный вариант. Тогда WordPress перестаёт запускать cron при каждом визите, а задачи выполняются по расписанию сервера. В wp-config.php добавляют:

define('DISABLE_WP_CRON', true);

После этого на сервере настраивают системный cron, например раз в 5 минут:

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

Если сайт закрыт Basic Auth, работает за Cloudflare Access или требует особых заголовков, лучше использовать локальный вызов через PHP или wp-cli, а не внешний HTTP-запрос. Иначе cron будет зависеть от сетевого доступа и защиты на уровне веб-сервера.

Проверка результата после внедрения

После изменений важно не ограничиться тем, что сайт «открылся». Проверка должна быть технической:

в wp cron event list больше нет лишнего hook;
через 10–15 минут событие не появляется снова;
в логах веб-сервера стало меньше обращений к wp-cron.php;
в пиковые часы снизилось число коротких PHP-запросов;
функции, завязанные на cron, продолжают работать: письма уходят, кэш чистится, импорт не ломается.

Если вы перевели cron на системный, полезно вручную проверить запуск:

wp cron event run --due-now

Команда выполнит все просроченные задачи. Это удобный способ убедиться, что расписание не сломалось после отключения WP-Cron в браузере.

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

Удалили событие, но нагрузка не исчезла

Значит, cron был не единственной причиной. Проверьте тяжёлые AJAX-запросы, REST API, поисковые боты, медленные запросы к базе и плагины, которые запускают фоновые очереди не через WP-Cron.

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

Это частая ошибка после правки wp-config.php. В результате перестают выполняться запланированные публикации, очистка временных данных и другие фоновые задачи. Если вы отключили WP-Cron, сразу добавьте системное расписание и проверьте его вручную.

Удалили задачу, а плагин создал её снова

Так бывает, если код плагина регистрирует событие на каждом запросе. В этом случае нужно искать настройку внутри плагина или отключать конкретный модуль. Иногда помогает обновление плагина: разработчики убирают лишнюю частоту или дублирующую регистрацию.

Сломали полезную фоновую функцию

Не стоит удалять всё, что выглядит подозрительно. Перед отключением проверьте, за что отвечает hook. Если это резервное копирование, отправка уведомлений или очистка очереди, лучше сначала снизить частоту, а не удалять событие полностью.

Практические советы для VDS

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

не запускайте WP-Cron при каждом визите, если сайт уже живёт на системном cron;
не ставьте слишком частый интервал для тяжёлых задач;
проверяйте cron после обновления плагинов — они могут добавлять новые события;
держите под рукой список установленных плагинов и их назначение, чтобы быстрее находить источник hook;
если задача нужна, но выполняется долго, выносите её в отдельный процесс или уменьшайте объём работы за один запуск.

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

Главная идея простая: сначала находите конкретный hook, потом источник, и только после этого отключаете. Тогда вы убираете лишнюю нагрузку на VDS без риска сломать запланированные задачи WordPress.

⭐⭐⭐⭐⭐