Хостинг пишет, что процессор на пределе, а вы не гоняли рекламу: просто сайт услуг на WordPress с бэкапом, SEO и кэшем. Боитесь отключить WP-Cron и потерять отложенные записи и письма с формы? Алексей, мастер по ремонту техники, увидел в WP Crontrol три плагина с проверками каждые 5 минут плюс ядро, которое дёргает фоновые задачи на каждом заходе. За 30–40 минут можно убрать лишний шум, оставить один вызов wp-cron.php по расписанию и не грузить сервер на каждом клике посетителя.
WP-Cron в WordPress — это не часы на сервере, а очередь задач, которую сайт проверяет при загрузке страницы. После переноса на задание хостинга раз в 15 минут официальная документация рекомендует отключить автозапуск при визите: иначе тратите ресурсы дважды. Сначала настройте cron в панели и проверьте отложенную запись, потом добавьте define(‘DISABLE_WP_CRON’, true) в wp-config.php. Константа не удаляет расписание — меняется только то, что запускает очередь.
Ниже — без лекции про Linux: лишние задачи, когда хватит встроенного режима, чек-лист для cPanel, ISPmanager и RU-хостинга. Полная замена cron — в отдельном гайде; здесь нагрузка и «шумные» плагины. Ещё темы WordPress — в разделе статей.
- Разберите, что WP-Cron делает на сайте услуг
- Найдите лишние задачи через WP Crontrol
- Выберите: встроенный WP-Cron или задание хостинга
- Настройте вызов wp-cron.php в панели хостинга
- Отключите автозапуск в wp-config после проверки
- Обойдите типичные ошибки настройки
- Уберите шум от плагинов без ломания сайта
- Проверьте, что всё сработало
- Частые вопросы
- Можно ли полностью отключить WP-Cron и ничего не ставить вместо?
- Чем WP-Cron отличается от cron на хостинге?
- Как часто вызывать wp-cron.php?
- Влияет ли WP-Cron на скорость сайта для клиента?
- Что будет с отложенными публикациями после DISABLE_WP_CRON?
Разберите, что WP-Cron делает на сайте услуг
На каждого гостя в ресепшене включают полную уборку — так при активных плагинах PHP на визите проверяет очередь: пост, письмо, бэкап. Задача на 14:00 сработает только после следующего захода после 14:00 — терпимо для маленького блога с трафиком.
Типичная ошибка владельца услуг: поставить пять плагинов с проверкой каждые 5 минут и не заметить, что хостинг считает сотни обращений к wp-cron.php в сутки. На shared-тарифе при росте посещений такой фон грузит CPU, память и базу данных. Например, кэш отдаёт готовую страницу без PHP — и встроенный cron почти не просыпается, а отложенная акция до пятницы может зависнуть. Тогда без вызова wp-cron.php по расписанию не обойтись.
Схема: посетитель открывает сайт → WordPress смотрит очередь cron → плагины запускают свои проверки → нагрузка растёт. Цель B61: оставить уборку по расписанию хостинга и убрать дубли от плагинов.
Найдите лишние задачи через WP Crontrol
Без SSH список фоновых задач смотрят в админке. Установите бесплатный плагин WP Crontrol из каталога WordPress, откройте Инструменты → Cron Events. Там колонки Hook (имя задачи), Next Run, Recurrence (как часто повторяется).
На что смотреть в первую очередь:
- События чаще, чем раз в час, если бизнесу не нужна такая частота (бэкап, SEO-скан, проверка лицензии).
- Несколько похожих хуков от разных плагинов — дублирующие напоминалки.
- Next Run застывший месяцами — задача не выполнялась (часто из-за кэша или нулевого трафика).
В реальном проекте Алексей отключил в настройках легкого плагина лишнее расписание и оставил ядро WordPress нетронутым. Ручной запуск Run now в Crontrol помогает проверить одну задачу без ожидания 15 минут. Не удаляйте события ядра вслепую — сначала поймите, какому плагину принадлежит хук (подсказка в описании или документации плагина).
Выберите: встроенный WP-Cron или задание хостинга
Не всем сразу нужен перенос. Пройдите короткий чек-лист:
- Хостинг жалуется на CPU или в статистике видны частые вызовы wp-cron.php — переходите на задание в панели.
- Стоит агрессивный кэш или CDN — визиты не доходят до PHP, встроенный cron молчит.
- Нужны ночные бэкапы и отложенные публикации по времени — надёжнее фиксированное расписание.
- Мало плагинов, трафик есть каждый день, жалоб нет — можно временно оставить как есть, но всё равно просмотрите Crontrol на интервал каждые 5 минут.
- Формы и письма должны уходить предсказуемо — системный вызов раз в 15 минут обычно спокойнее, чем надежда на случайного посетителя.
| Симптом | Что сделать |
|---|---|
| CPU на пределе, сайт не рекламировали | Аудит Crontrol + cron хостинга + DISABLE_WP_CRON после проверки |
| Отложенный пост не вышел вовремя | Задание на wp-cron.php; см. также отложенную публикацию и WP-Cron |
| После включения кэша задачи замерли | Не полагаться на визиты; вызов по URL или PHP-CLI из панели |
| Страшно править wp-config | Сначала cron в панели и тестовая отложенная запись; при сомнениях — напишите в поддержку хостинга |
Настройте вызов wp-cron.php в панели хостинга
Ключевой порядок из документации WordPress и практики хостингов: сначала рабочее задание в панели, потом отключение автозапуска при визите. Иначе письма, бэкапы и отложенные посты тихо перестанут выполняться.
Расписание каждые 15 минут в cron пишется как */15 * * * * — компромисс между скоростью публикации и лимитами shared-хостинга (часто нельзя ставить каждую минуту).
- Откройте раздел Cron: cPanel — Cron Jobs, ISPmanager — Планировщик, у многих RU-хостингов — раздел Задания cron или Планировщик.
- Добавьте интервал */15 * * * *.
- В команду подставьте полный https-адрес сайта. Пример из официальной доки: wget —delete-after https://ваш-домен.ru/wp-cron.php — на практике часто добавляют параметр ?doing_wp_cron в конце URL.
- Если wget недоступен — curl с тем же адресом; поддержка NetAngels и аналогов иногда даёт путь вида /usr/local/bin/php …/wp-cron.php.
- Сохраните, подождите 15–20 минут, в WP Crontrol обновите список: у событий должны сдвинуться Next Run.
- Создайте тестовую отложенную запись на время через 20 минут — она должна выйти в пределах одного–двух интервалов cron.
Часто ломается http вместо https и basic auth на тестовом домене. Про кэш и фон — настройка кэширования WordPress.
Отключите автозапуск в wp-config после проверки
Когда убедились, что задание хостинга срабатывает, скачайте копию wp-config.php через файловый менеджер. Перед строкой That’s all, stop editing добавьте одну строку:
define(‘DISABLE_WP_CRON’, true);
После этого при заходе посетителя WordPress больше не пытается сам запускать очередь — но прямой вызов wp-cron.php из cron хостинга продолжает работать. Это не хак, а рекомендуемый шаг после системного расписания: иначе ресурсы тратятся дважды.
Сразу после сохранения снова откройте Cron Events и убедитесь, что события обновляются. В мониторинге хостинга не должно быть всплеска wp-cron.php на каждый клик по сайту.
Обойдите типичные ошибки настройки
Часто ломается порядок шагов: сначала DISABLE_WP_CRON, потом cron в панели — задачи замирают. Другие ловушки: http вместо https, basic auth режет wget, кэш отдаёт HTML вместо PHP. Если нужен разбор только под Missed schedule — см. системный cron вместо WP-Cron.
Уберите шум от плагинов без ломания сайта
Даже с правильным cron лишние задачи грузят сервер при каждом срабатывании. Делайте так:
- В настройках бэкапа — реже полные копии, если бизнесу хватает ежедневного ночного окна; см. автоматический бэкап WordPress.
- Отключите ненужные scan, check update, sync по расписанию, если плагин это позволяет.
- Не ставьте события раз в 1–5 минут без явной нужды — маркетинговому сайту услуг редко нужна проверка чаще, чем раз в 15–60 минут.
- Heartbeat в админке тоже добавляет фоновые запросы — при тормозах редактора смотрите материал про отключение Heartbeat.
Итог: в Crontrol остаётся понятный список, нагрузка предсказуема, отложенные акции выходят вовремя.
Проверьте, что всё сработало
Вы поймёте, что настройка удалась, если одновременно выполняются критерии из чек-листа:
- В WP Crontrol события сдвигают Next Run, а не висят месяцами.
- В wp-config.php стоит DISABLE_WP_CRON true, задание */15 * * * * сохранено в панели.
- Тестовая отложенная запись опубликовалась в пределах 15–20 минут после времени.
- В логах или статистике хостинга нет сотен вызовов wp-cron.php на каждый визит посетителя.
Если панель пугает — напишите через контакты (мессенджер) или в Telegram. Сайт под статьи и стабильный фон — на услугах.
Материал проверен: Андрей Дикий (создаёт сайты и продвигает их статьями (SEO/GEO)).
Достоверность данных: WordPress Plugin Handbook (WP-Cron, системный планировщик, wp-config DISABLE_WP_CRON), Kinsta и NetAngels (порядок шагов, нагрузка, PHP-cron), WP Crontrol на GitHub, cPanel Support (wget); LSI-кластер запросов — SERP 27.09.2026 (Wordstat MCP недоступен, точные показы не подтверждены).
Частые вопросы
Можно ли полностью отключить WP-Cron и ничего не ставить вместо?
Нет. Очередь задач WordPress и плагинов всё равно нужна: отложенные записи, письма, бэкапы. Отключают только автозапуск при визите, а замену делают заданием хостинга на wp-cron.php. Иначе сайт замолчит в фоне без красной ошибки на экране.
Чем WP-Cron отличается от cron на хостинге?
WP-Cron просыпается, когда кто-то открывает страницу (или админку). Cron хостинга — будильник сервера: срабатывает по расписанию независимо от посетителей. Для сайта услуг с кэшем и отложенными акциями второй вариант обычно надёжнее и щадит CPU.
Как часто вызывать wp-cron.php?
Официальный пример — каждые 15 минут (*/15 * * * *). Реже — дольше ждёте публикацию и письма; чаще — рискуете упереться в лимиты shared-хостинга. Подстройте под реальные задачи: если достаточно бэкапа раз в ночь, не гоняйте тяжёлые проверки каждые 5 минут в Crontrol.
Влияет ли WP-Cron на скорость сайта для клиента?
Посетитель может не заметить напрямую, но при каждом визите PHP может тянуть очередь cron — растёт время ответа сервера и нагрузка на тарифе. После переноса на одно задание раз в 15 минут страницы отдаются без лишней фоновой работы на каждый клик.
Что будет с отложенными публикациями после DISABLE_WP_CRON?
Они продолжат работать, если хостинг по расписанию вызывает wp-cron.php. Проверьте тестовым постом сразу после настройки. Если пост завис — смотрите Crontrol и задание в панели, не откатывайте константу вслепую.
