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

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

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

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

Когда cron в WordPress становится проблемой

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

Типичные признаки лишних задач

в логах много обращений к /wp-cron.php?doing_wp_cron=...;
одни и те же события повторяются каждые несколько минут без понятной причины;
после удаления плагина в расписании остаются его задачи;
на слабом хостинге сайт подвисает в моменты запуска фоновых процессов;
в таблице wp_options раздувается автозагрузка из-за мусорных настроек плагинов, связанных с cron.

Диагностика: где смотреть запланированные события

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

Проверка через WP-CLI

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

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

Проверка через код

Если WP-CLI недоступен, можно временно вывести список событий в админке или в лог. Для точечной диагностики достаточно пройтись по расписанию через wp_get_scheduled_event() и wp_get_schedules(), но удобнее использовать готовый список событий из плагина просмотра cron. Важно не редактировать базу вручную, пока не понятно, какие задачи действительно нужны.

Что отключать, а что оставить

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

Подход	Когда подходит	Минус
Плагин для просмотра cron	Нужно быстро найти лишние события без доступа к серверу	Дополнительный интерфейс и риск удалить не то
WP-CLI	Есть SSH-доступ и нужен точный контроль	Нужны права на сервере
Код в mu-plugin	Нужно убрать конкретный хук на постоянной основе	Требует аккуратности и теста на staging

Пошаговое решение: как отключить лишний cron-хук

Если вы нашли конкретный хук, который больше не нужен, его можно снять через wp_clear_scheduled_hook(). Это безопаснее, чем лезть в сериализованные данные руками. Но сначала проверьте, не создаёт ли этот хук другой плагин заново при каждом запросе.

Снять конкретное событие при деактивации плагина

<?php
/**
 * Plugin Name: Cron Cleanup Helper
 */

register_deactivation_hook(__FILE__, function () {
    wp_clear_scheduled_hook('my_plugin_cleanup_event');
});

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

Отключить повторное создание задачи

Иногда мало удалить событие: код плагина при каждом запуске снова ставит его в очередь. Тогда нужно убрать сам wp_schedule_event() или обернуть его в условие. Пример для собственного кода:

<?php
add_action('init', function () {
    if (!wp_next_scheduled('my_plugin_cleanup_event')) {
        wp_schedule_event(time() + HOUR_IN_SECONDS, 'hourly', 'my_plugin_cleanup_event');
    }
});

add_action('my_plugin_cleanup_event', function () {
    // Фоновая задача.
});

Если вы видите, что задача создаётся без проверки wp_next_scheduled(), это частая причина дублей. Исправление лучше делать в коде, а не только чистить расписание.

Как перевести WP-Cron на системный cron

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

Отключение внутреннего запуска

В wp-config.php добавляют константу:

define('DISABLE_WP_CRON', true);

После этого WordPress перестанет запускать cron на обычных просмотрах страниц. Но сами задачи никуда не денутся — их нужно будет вызывать внешним cron на сервере.

Пример системного cron

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

Интервал подбирают по нагрузке и задачам сайта. Для большинства проектов достаточно запуска раз в 5–15 минут, но это зависит от того, как часто у вас должны срабатывать отложенные действия.

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

После удаления лишних задач важно убедиться, что вы не сломали фоновые процессы. Проверка должна быть не формальной, а по факту.

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

Если вы перенесли cron на сервер, дополнительно проверьте, что системная задача действительно выполняется. Ошибка здесь обычно простая: DISABLE_WP_CRON включили, а серверный cron не добавили.

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

Удаляют событие, но не убирают код, который его создаёт

В итоге задача возвращается после следующего запроса. Нужно найти место, где вызывается wp_schedule_event() или wp_schedule_single_event(), и исправить логику там.

Чистят базу вручную

Удаление записей из wp_options без понимания структуры cron может повредить расписание. Безопаснее использовать API WordPress или WP-CLI.

Снимают все события плагина целиком

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

Отключают WP-Cron без внешнего cron

После этого перестают работать отложенные записи и фоновые задачи. Если сайт на shared-хостинге, сначала проверьте, можно ли настроить cron в панели хостинга.

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

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

Для сайтов с высокой посещаемостью полезно:

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

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