Если WordPress начал заметно притормаживать или фоновые задачи выполняются с задержками, часто проблема не в теме и не в плагинах, а в механизме wp-cron. По умолчанию WordPress не использует настоящий системный планировщик: он пытается запускать задачи при обычных обращениях к сайту. На небольшом проекте это терпимо, но на нагруженном сайте такой подход даёт лишнюю нагрузку и делает выполнение задач менее предсказуемым.
Решение практическое: отключить встроенный псевдокрон и перенести запуск на системный cron на сервере. Тогда WordPress будет обрабатывать запланированные публикации, обновления и другие фоновые события по расписанию, а не только когда кто-то открыл страницу.
Когда wp-cron действительно мешает
Псевдокрон запускается не по таймеру, а при запросах к сайту. Это значит, что при редких посещениях задачи могут выполняться с опозданием, а при высокой посещаемости WordPress может пытаться проверять очередь слишком часто. В результате появляются лишние обращения к файлу wp-cron.php, а на некоторых хостингах это заметно по нагрузке на CPU и количеству запросов.
Обычно переход на системный cron имеет смысл, если вы видите хотя бы один из признаков:
- запланированные записи публикуются не вовремя;
- резервные копии, очистка кэша, рассылки или другие фоновые задачи стартуют нестабильно;
- в логах или статистике хостинга видно много обращений к
wp-cron.php; - сайт получает достаточно трафика, и лишние фоновые проверки уже создают заметную нагрузку.
Если сайт маленький и проблем нет, ломать рабочую схему ради принципа не нужно. Но если вы уже ищете способ сделать выполнение задач предсказуемым, системный cron — правильный вариант.
Что нужно сделать перед отключением wp-cron
Перед изменениями проверьте два момента. Во-первых, у вас должен быть доступ к панели хостинга или SSH, чтобы создать задание cron. Во-вторых, убедитесь, что хостинг вообще поддерживает cron-задачи. На большинстве нормальных тарифов это есть, но формат настройки отличается: где-то доступен удобный интерфейс, где-то нужно писать команду вручную.
Если у вас есть доступ только к админке WordPress без панели хостинга, полностью перенести запуск задач на серверный cron не получится. В таком случае можно только частично снизить проблему, но это уже не то решение, которое требуется для стабильной работы.
Перед правкой файла wp-config.php сделайте резервную копию. Ошибка в этом файле может временно положить сайт, поэтому лучше не редактировать его «на живую» без бэкапа.
Отключаем встроенный псевдокрон WordPress
Чтобы WordPress перестал запускать задачи при каждом посещении сайта, в файл wp-config.php добавляют константу DISABLE_WP_CRON. Её нужно вставить до строки /* That's all, stop editing! Happy publishing. */.
Добавьте такую строку:
define('DISABLE_WP_CRON', true);После этого WordPress больше не будет сам инициировать запуск фоновых задач при обычных запросах. Но это только половина настройки: если на этом остановиться, запланированные действия просто перестанут выполняться. Поэтому сразу после отключения нужно создать системное задание cron.
Настраиваем системный cron для запуска wp-cron.php
Суть настройки простая: сервер по расписанию обращается к файлу wp-cron.php, а WordPress обрабатывает очередь задач уже в этот момент. Интервал обычно ставят 5 или 10 минут. Для большинства сайтов этого достаточно, но конкретный шаг зависит от того, насколько критично для вас точное время выполнения.
Вариант через cron на хостинге
Если в панели хостинга есть раздел Cron Jobs, создайте новое задание и укажите команду, которая обращается к wp-cron.php. Универсальный вариант для Linux-хостинга выглядит так:
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Замените https://example.com на адрес вашего сайта. Команда запускается каждые 5 минут. Параметр ?doing_wp_cron обычно добавляют для корректного вызова, а вывод отправляют в /dev/null, чтобы cron не засорял почту и логи лишним текстом.
Если на хостинге не работает wget, часто доступен curl:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Оба варианта рабочие, но конкретная команда зависит от того, какие утилиты разрешены на сервере. На shared-хостинге это лучше уточнить в документации или поддержке.
Вариант через SSH и crontab
Если у вас есть SSH-доступ, можно добавить задание в пользовательский crontab. Для этого обычно используют команду crontab -e и добавляют строку с нужным интервалом. Пример тот же:
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1Этот способ удобен тем, что вы управляете задачей напрямую, без панели хостинга. Но если вы не уверены в синтаксисе cron, лучше не экспериментировать на боевом сайте: ошибка в расписании или URL приведёт к тому, что задачи не будут запускаться.
Как выбрать интервал запуска
Слишком частый запуск не нужен. Если вы ставите cron каждую минуту, это не делает WordPress «быстрее», но создаёт лишние обращения к серверу. Для большинства сайтов разумный стартовый интервал — 5 минут. Если на сайте много критичных фоновых задач, можно уменьшить интервал до 1–2 минут, но только если это действительно оправдано.
Ориентируйтесь на сценарий:
- обычный корпоративный сайт или блог — 5 минут обычно достаточно;
- сайт с частыми публикациями и автоматическими задачами — 1–5 минут;
- небольшой сайт без срочных фоновых процессов — 10 минут тоже допустимо, если задержка не критична.
Главное — не путать частоту проверки с качеством работы. Если задача должна выполниться в конкретный момент, системный cron делает это стабильнее, но не превращает WordPress в realtime-систему.
Как проверить, что всё работает
После настройки не полагайтесь только на то, что сайт открывается без ошибок. Нужно убедиться, что cron реально запускается и WordPress получает выполнение задач.
Проверка обычно состоит из трёх шагов:
- Откройте сайт и убедитесь, что в
wp-config.phpдействительно добавлена строкаdefine('DISABLE_WP_CRON', true);. - Проверьте в панели хостинга или в
crontab -l, что задание создано и активно. - Посмотрите, выполняются ли запланированные действия WordPress: публикация отложенной записи, запуск резервного копирования, очистка кэша или другая фоновая задача, которая у вас уже настроена.
Если у вас есть доступ к логам сервера, можно дополнительно проверить, что cron-задание отрабатывает без ошибок. Но для обычной практической проверки достаточно убедиться, что отложенные задачи больше не «зависают» и выполняются в ожидаемое время.
Что часто идёт не так
Самая частая ошибка — отключить wp-cron, но не создать системное задание. В этом случае фоновые задачи просто перестают запускаться, и проблема становится хуже, чем была.
Ещё одна типичная ситуация — неверный URL сайта в команде cron. Если домен указан с ошибкой, с http вместо https там, где нужен https, или сайт работает в подкаталоге, запрос уйдёт не туда. Для мультисайта и нестандартной структуры адрес нужно проверять особенно внимательно.
Иногда хостинг блокирует исходящие HTTP-запросы или не даёт использовать нужную утилиту. Тогда команда с wget или curl может не сработать, и придётся использовать тот способ, который разрешён на конкретной площадке. Это уже вопрос возможностей хостинга, а не WordPress.
Если после настройки задачи всё равно выполняются с задержкой, проверьте, не кэширует ли хостинг сам запрос к wp-cron.php, и не отключено ли задание в панели. На некоторых серверах проблема не в WordPress, а в том, как именно настроен cron на стороне хостинга.
Когда псевдокрон отключён и серверный cron настроен корректно, WordPress начинает работать предсказуемее: фоновые задачи запускаются по расписанию, а сайт меньше зависит от случайных посещений. Для сайтов, где важны стабильность и контроль нагрузки, это обычно лучший вариант.