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

Автор: Анна Новикова | Опубликовано: 18.09.2026

Если в админке WordPress растёт нагрузка, а в базе появляются десятки однотипных событий, проблема часто не в одном «тяжёлом» плагине, а в фоновых задачах. WP-Cron сам по себе не настоящий системный cron: он запускается на посещениях сайта и легко разрастается, если плагины ставят свои события без контроля.

Типичный сценарий: вы удалили плагин, а его задачи остались в расписании; или поставили SEO/кеш/импорт-плагин, который каждые несколько минут создаёт события, но фактически уже не нужен. Ниже — как найти такие задачи, понять, что можно убрать, и не сломать обновления, отправку писем или очистку кеша.

Когда стоит проверять WP-Cron

Искать лишние cron-задачи имеет смысл, если вы видите хотя бы один из признаков:

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

Что именно искать

Смотрите не только на название события, но и на частоту, источник и аргументы. Одно и то же имя может использоваться разными плагинами, а некоторые задачи создаются динамически. Важно понять, это штатная задача WordPress, задача активного плагина или мусор после удаления.

Диагностика: как увидеть список cron-событий

Самый удобный способ — посмотреть расписание через плагин WP Crontrol или через WP-CLI, если он у вас есть. Для рабочей диагностики это лучше, чем лезть сразу в базу руками.

Вариант 1: через WP-CLI

Команда показывает все запланированные события. Её удобно запускать на staging или в SSH-доступе к серверу:

wp cron event list

Если нужен отбор по конкретному хук-имени, можно использовать фильтрацию в shell:

wp cron event list --fields=hook,next_run,recurrence | grep -i cache

Так вы быстро увидите, какие события повторяются слишком часто или относятся к уже удалённым плагинам.

Вариант 2: через код для точечной проверки

Если SSH нет, можно временно вывести список событий в админке или в лог. Для разовой диагностики подойдёт такой сниппет в functions.php дочерней темы или в mu-plugin:

add_action('admin_init', function () {
    if ( ! current_user_can('manage_options') ) {
        return;
    }

    $crons = _get_cron_array();
    error_log('=== WP Cron list start ===');

    foreach ( $crons as $timestamp => $hooks ) {
        foreach ( $hooks as $hook => $events ) {
            foreach ( $events as $event ) {
                error_log( sprintf(
                    '%s | %s | %s',
                    gmdate('Y-m-d H:i:s', $timestamp),
                    $hook,
                    maybe_serialize( $event['args'] )
                ) );
            }
        }
    }

    error_log('=== WP Cron list end ===');
});

После проверки этот код нужно удалить. Он полезен именно как временный инструмент, а не как постоянное решение.

Как понять, что задачу можно отключить

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

Подход	Когда уместен	Риск
Отключить через плагин	Если задача создаётся конкретным плагином и у него есть настройка расписания	Низкий, если плагин активен и поддерживает настройку
Удалить через код	Если задача точно лишняя и вы понимаете её хук	Средний: можно убрать нужный фоновой процесс
Оставить, но перевести на системный cron	Если сайт посещаемый или WP-Cron срабатывает нестабильно	Низкий при правильной настройке сервера

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

Пошаговое решение: удалить лишнее и не сломать сайт

Шаг 1. Найдите точное имя хука

Допустим, в списке вы увидели событие my_plugin_cleanup_cache. Сначала проверьте, активен ли плагин, который его создаёт, и есть ли у него собственная настройка частоты или отключения фоновой очистки.

Шаг 2. Удалите конкретное событие

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

wp cron event delete my_plugin_cleanup_cache

Если это повторяющееся событие и вы хотите убрать все его экземпляры, удобнее сделать это через код:

function wpset_clear_cron_hook( $hook ) {
    $crons = _get_cron_array();

    foreach ( $crons as $timestamp => $hooks ) {
        if ( empty( $hooks[ $hook ] ) ) {
            continue;
        }

        foreach ( $hooks[ $hook ] as $sig => $event ) {
            wp_unschedule_event( $timestamp, $hook, $event['args'] );
        }
    }
}

wpset_clear_cron_hook( 'my_plugin_cleanup_cache' );

Этот вариант полезен, когда нужно убрать несколько событий с разными аргументами. Но использовать его стоит только после точной проверки, иначе можно снести нужные фоновые процессы.

Шаг 3. Если задача нужна, но слишком частая — измените расписание

Иногда cron не надо удалять, достаточно сделать его реже. Для этого можно зарегистрировать собственный интервал и использовать его в wp_schedule_event():

add_filter('cron_schedules', function ($schedules) {
    $schedules['every_fifteen_minutes'] = [
        'interval' => 15 * 60,
        'display'  => 'Every 15 minutes',
    ];

    return $schedules;
});

if ( ! wp_next_scheduled('my_plugin_cleanup_cache') ) {
    wp_schedule_event(time(), 'every_fifteen_minutes', 'my_plugin_cleanup_cache');
}

Такой подход лучше, чем полностью отключать задачу, если она нужна для очистки кеша, синхронизации или очередей.

Шаг 4. Перенесите WP-Cron на системный cron, если сайт живой

На сайтах с предсказуемой нагрузкой надёжнее отключить запуск WP-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

Это не ускоряет сайт магически, но убирает лишние попытки запуска cron на каждом посещении и делает фоновые задачи стабильнее.

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

После удаления или переноса задач важно не ограничиваться визуальной проверкой. Смотрите на три вещи: список событий, поведение плагинов и логи.

повторно выполните wp cron event list и убедитесь, что лишний хук исчез;
проверьте, не создаётся ли он снова после загрузки сайта или обновления страницы;
посмотрите, работают ли критичные процессы: отправка писем, очистка кеша, автопубликация, синхронизация;
если есть серверные логи или debug.log, проверьте ошибки, связанные с удалённым хук-именем.

Хороший признак — событие исчезло из расписания и не возвращается после нескольких обычных действий на сайте. Если оно появляется снова, значит, его регистрирует активный плагин или тема, и удаление нужно делать не только из cron, но и в настройках источника.

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

Удалили событие, но оно вернулось

Причина обычно в том, что плагин при каждом запросе снова ставит задачу через wp_schedule_event(). Решение — найти код регистрации хука или отключить сам плагин, если задача больше не нужна.

Сломали очистку кеша или очереди писем

Это происходит, когда под «лишний cron» попадает важный фоновой процесс. Перед удалением проверьте назначение хука в коде плагина или в его документации. Если задача нужна, не удаляйте её, а уменьшите частоту.

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

В этом случае фоновые задачи перестанут запускаться вообще. Сайт может не отправлять письма, не выполнять запланированные публикации и не чистить временные данные. После включения DISABLE_WP_CRON обязательно проверьте cron на сервере.

Чистили расписание напрямую в базе

Ручное редактирование wp_options или сериализованного массива cron — плохая идея. Ошибка в одном символе ломает структуру данных, и WordPress начинает вести себя непредсказуемо. Для удаления используйте WP-CLI, wp_unschedule_event() или проверенные инструменты вроде WP Crontrol.

Практические советы по безопасности и производительности

Если вы часто работаете с cron на клиентских проектах, держите проверку задач в чек-листе после установки каждого плагина. Особенно это касается кеширующих, SEO, импортных и интеграционных решений: они чаще других добавляют фоновые события.

Полезно также:

не оставлять в продакшене временные диагностические сниппеты с error_log();
проверять cron после удаления плагина, а не через неделю, когда мусор уже накопился;
на высоконагруженных сайтах переводить WP-Cron на системный cron;
не ставить несколько плагинов, которые делают одно и то же в фоне, например чистят кеш или синхронизируют данные;
сохранять список критичных хуков перед чисткой, чтобы быстро откатиться при проблеме.

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

Главная логика простая: сначала диагностируете источник события, потом удаляете или замедляете только конкретный хук, и только после этого проверяете, что сайт продолжает выполнять нужные фоновые операции. Именно так cron чистится без сюрпризов.