В WordPress термин self-requests (самозапросы) обозначает HTTP-запросы, которые сайт отправляет сам себе. Чаще всего они идут на wp-cron.php, admin-ajax.php или другие внутренние точки входа. Они нужны для выполнения фоновых задач, запланированных действий и обновлений без прямого участия пользователя. При неправильной настройке такие запросы могут негативно повлиять на производительность сайта.
Вместо системного cron WordPress использует псевдокрон WP-Cron, который запускается через самозапросы. Когда посетитель заходит на сайт, WordPress автоматически отправляет запрос к файлу wp-cron.php, чтобы проверить и обработать запланированные задачи. Через этот механизм выполняются:
Такой подход удобен, но у него есть слабое место: если сайт получает мало трафика, задачи могут выполняться с задержкой или вовсе не запускаться вовремя. Для сайтов с высокой нагрузкой ситуация обратная: псевдокрон будет срабатывать слишком часто, создавая лишние запросы при каждом посещении. Подробнее о принципах работы можно прочитать в официальной документации WordPress.
С версии WordPress 3.6 появилась технология Heartbeat API. Это AJAX-запросы между браузером и сервером, которые обеспечивают:
Обычно такие запросы идут каждые несколько секунд на admin-ajax.php при работе в административной панели. На нагруженных сайтах или при большом числе одновременных редакторов это может заметно увеличить нагрузку на сервер.
Если эти функции включены, WordPress использует самозапросы для проверки входящих пингбеков и трекбеков, а также для уведомления других сайтов о том, что вы разместили на них ссылку. На большинстве современных сайтов эти функции не нужны и их рекомендуется отключить.
Многие плагины и темы инициируют self-запросы для получения данных из внешних API, запуска фоновых задач, внутренней синхронизации, обновления кеша или формирования отчётов. Если плагин написан без учёта производительности, он может генерировать десятки лишних запросов в минуту.
Если сайт получает данные из RSS (например, через виджеты или плагины), WordPress может отправлять самозапросы для загрузки и обработки этих данных. В большинстве случаев такие запросы кешируются, но при ошибках конфигурации они повторяются слишком часто.
Хотя self-запросы полезны, чрезмерная их активность может увеличить нагрузку на сервер, замедлить время ответа и снизить эффективность кеширования. Особенно это заметно на виртуальном хостинге с ограниченными ресурсами.
Главная проблема WP-Cron в том, что он не работает по реальному расписанию. Задача запустится только тогда, когда на сайт придёт посетитель, и именно его запрос станет триггером. Это нормально для небольших блогов, но неприемлемо для интернет-магазинов или новостных порталов, где важна точность выполнения задач. Подробный анализ проблем с производительностью собран в базе знаний Kinsta.
Первый и самый эффективный шаг: отключить WP-Cron и настроить системный cron на сервере. Для этого в файл wp-config.php добавляют строку:
define(‘DISABLE_WP_CRON’, true);
После этого задачи WP-Cron не будут запускаться автоматически при посещении сайта. Вместо этого вы вручную добавляете задание в crontab сервера, которое будет вызывать wp-cron.php через заданные промежутки времени. Это позволяет точно контролировать расписание и убирает лишние запросы при обычном трафике. Инструкция по настройке есть в руководстве WordPress для разработчиков.
Для снижения нагрузки от Heartbeat API можно:
Стоит регулярно проверять, какие плагины создают фоновые задачи. Для этого подходит плагин WP Crontrol, который показывает все активные задачи в очереди псевдокрона и позволяет удалять лишние. Если какой-то плагин добавляет десятки задач без видимой необходимости, это повод поискать более легковесную альтернативу. Сам плагин доступен в официальном репозитории WordPress.
Если вы хотите понять, сколько self-запросов реально генерирует ваш сайт, воспользуйтесь логами сервера или инструментами мониторинга. В логах Apache и Nginx каждый запрос к wp-cron.php или admin-ajax.php оставляет след. Если вы видите, что один и тот же файл вызывается сотни раз в час, это сигнал к действию. Хорошим дополнением к серверным логам служит плагин Query Monitor, который показывает все HTTP-запросы, инициированные WordPress на стороне сервера. Он бесплатный и доступен в репозитории WordPress. Такой аудит стоит проводить после каждой крупной установки новых плагинов или обновления темы, потому что именно эти действия чаще всего добавляют новые фоновые задачи без явного предупреждения.
Сами по себе нет. Опасность появляется при уязвимостях в плагинах или темах, которые их обрабатывают. Если злоумышленник найдёт способ инициировать множество запросов к wp-cron.php извне, это может привести к перегрузке сервера.
Часть можно заменить системными задачами. Псевдокрон отключают через wp-config.php и переносят задачи на серверный cron. Heartbeat API можно ограничить или отключить с помощью фильтров или специализированных плагинов.
Напрямую нет, но косвенно да. Если из-за лишних запросов сервер начинает отвечать медленнее, это ухудшает время загрузки страниц, что негативно сказывается на поведенческих факторах и оценке Core Web Vitals. Поисковые системы учитывают скорость сайта при ранжировании, поэтому оптимизация self-запросов в конечном счёте влияет и на позиции в выдаче.
Самый удобный способ: установить плагин WP Crontrol и открыть раздел Инструменты > Cron Events. Там будет список всех запланированных задач с указанием времени следующего запуска и источника (плагин, тема или ядро WordPress). Это позволяет быстро найти задачи, которые запускаются слишком часто или давно устарели.
