Если хостинг заблокировал сайт за превышение лимитов, причину почти всегда можно найти за один-два часа: выясните у хостинга, какой процесс или адрес грузил CPU, сопоставьте время пиков с логами доступа и по очереди отключите подозрительные плагины на копии сайта. Чаще всего виноваты WP-Cron, admin-ajax.php, поисковые и сторонние боты, плагины статистики, резервного копирования и «умных» фильтров каталога.
Типичная картина: утром сайт не открывается, на экране заглушка хостинга или ошибка 503, в почте письмо о превышении лимита процессорного времени. Хостинг по просьбе снимает блокировку, а через три дня все повторяется, потому что источник нагрузки остался на месте.
Почему хостинг блокирует сайт на WordPress за нагрузку
Хостинг блокирует сайт, когда его процессы забирают больше ресурсов сервера, чем позволяет тариф. На виртуальном хостинге на одном физическом сервере живут сотни сайтов, и провайдер ограничивает каждому процессорное время, число одновременных процессов PHP, оперативную память и количество запросов к базе. Превышение лимитов означает, что ваш сайт мешает соседям, и система ограничивает его автоматически: сначала замедляет, потом отдает 503 или полностью отключает аккаунт до разбора.
Высокая нагрузка на CPU у WordPress редко связана с обычными посетителями. Процессор съедают фоновые и служебные запросы: задачи по расписанию, обращения к admin-ajax.php из открытой вкладки админки, импорт товаров, генерация миниатюр, а также боты, которые за час обходят тысячи страниц фильтров. Поэтому полезнее всего сразу выяснить, кто именно и в какое время запускал PHP. Число посетителей тут мало что объясняет.
Что запросить у хостинга в первую очередь
Первым делом попросите у хостинга статистику нагрузки с точным временем пиков и список адресов, которые эту нагрузку создавали. Большинство провайдеров в Казахстане показывают графики CPU и процессов прямо в панели управления, а логи доступа (access log) лежат в папке logs аккаунта или скачиваются из панели.
Что стоит спросить в техподдержке хостинга одним письмом:
- В какие часы были пики и какой лимит превышен: CPU, число процессов, память или запросы к MySQL.
- Какие скрипты чаще всего запускались в эти часы: index.php, wp-cron.php, admin-ajax.php, xmlrpc.php или что-то из папки плагина.
- С каких IP-адресов и с какими User-Agent шли запросы в пиковые минуты.
- Есть ли медленные SQL-запросы в журнале базы данных и к каким таблицам они обращаются.
- Какой лимит у текущего тарифа и сколько сайт потреблял в среднем за последнюю неделю.
Ответ на второй и третий вопрос обычно сразу сужает круг. Если 80% нагрузки дают обращения к wp-cron.php, ищите тяжелую задачу по расписанию. Если admin-ajax.php, смотрите, что в админке или на фронте опрашивает сервер. Если index.php с параметрами вроде ?filter_color= или ?orderby=, а User-Agent принадлежит ботам, сервер перегружает обход страниц фильтров.
Как найти плагин-виновник на WordPress: пошаговая проверка
Плагин-виновник находится методом исключения: отключаете плагины по одному или группами и смотрите, когда нагрузка падает. Делать это на рабочем сайте в разгар дня неудобно и рискованно, поэтому лучше работать на копии (staging) или в часы минимального трафика, предварительно сделав резервную копию файлов и базы.
- Зафиксируйте исходную точку. Запишите текущую нагрузку по графику хостинга и время ответа главной и одной тяжелой страницы (каталог, поиск).
- Установите Query Monitor. Это бесплатный плагин-панель разработчика из каталога wordpress.org. По описанию Query Monitor на wordpress.org он показывает запросы к базе данных, ошибки PHP, хуки, подключаемые скрипты, вызовы HTTP API, Ajax и REST API, и умеет группировать вывод по плагину или теме. Откройте тяжелую страницу и посмотрите, какой компонент дает больше всего запросов и самое долгое время.
- Включите журнал ошибок. В wp-config.php добавьте WP_DEBUG и WP_DEBUG_LOG. Согласно руководству WordPress по отладке, ошибки, предупреждения и уведомления тогда пишутся в файл debug.log в папке wp-content, а на экран не выводятся. Плагин, который сыплет тысячами предупреждений в минуту, тоже грузит сервер.
- Отключайте плагины группами. Разделите список пополам: выключите половину, понаблюдайте 15-30 минут, затем включите обратно и выключите вторую половину. Когда группа найдена, делите ее дальше. Через три-четыре круга остается один-два кандидата.
- Если админка недоступна, отключите все плагины через файловый менеджер или FTP. В разделе решения проблем документации WordPress описан способ: переименовать папку wp-content/plugins, например в plugins.hold, после чего все плагины перестают работать. При наличии SSH то же делает команда WP-CLI wp plugin deactivate —all.
- Проверьте тему. Если после отключения всех плагинов нагрузка остается, временно переключитесь на стандартную тему. Тяжелые темы с конструкторами и встроенными слайдерами тоже бывают источником проблемы.
Нагрузка от фоновых задач и ботов проявляется не сразу, поэтому выводы делайте по графику хостинга за несколько часов.
Какие плагины чаще всего грузят процессор
Чаще всего процессор грузят плагины, которые работают в фоне или обрабатывают каждый запрос: статистика внутри WordPress, резервное копирование, безопасность с подробным журналом, связанные записи, фильтры каталога и генераторы изображений. По нашему опыту на проектах B2BPRO.KZ, в половине случаев виновник оказывается в этом коротком списке, причем сам плагин обычно в порядке, подводит его настройка.
| Тип плагина | Почему грузит сервер | Что проверить |
|---|---|---|
| Статистика и счетчики посещений внутри WordPress | Пишут запись в базу на каждый просмотр страницы, таблицы растут на миллионы строк | Размер таблиц плагина, перенос статистики во внешний сервис (Яндекс Метрика, Google Analytics) |
| Резервное копирование | Архивирует файлы и базу прямо на сервере, часто в рабочие часы | Расписание, исключение кэша и старых архивов из копии, хранение копий вне хостинга |
| Безопасность и файрволы | Сканируют файлы, ведут подробный журнал каждого запроса | Частоту сканирования, срок хранения журнала, время запуска проверок |
| Фильтры каталога и поиск WooCommerce | Каждая комбинация фильтров дает новую страницу, которую обходят боты | Закрытие параметров фильтров от индексации, кэширование результатов |
| Связанные записи, «похожие товары» | Считают похожесть сложными SQL-запросами на каждой странице | Кэширование блока, замену на более простой механизм |
| Оптимизация и генерация изображений | Пересоздают миниатюры и WebP для всей медиатеки разом | Обработку пачками, запуск ночью |
В таблице типичные сценарии: один и тот же плагин на маленьком сайте незаметен, а на большом кладет сервер из-за объема данных. Найдя кандидата, сначала посмотрите его настройки: часто хватает сократить журнал или перенести задачу на ночь.
Отдельная история с базой данных. Если таблицы wp_options и журналы плагинов разрослись, каждый запрос становится тяжелее. Как навести там порядок, подробно описано в статье про оптимизацию базы данных WordPress.
WP-Cron и admin-ajax.php: скрытые источники нагрузки
WP-Cron и admin-ajax.php создают нагрузку, которую не видно глазами при обычном просмотре сайта. WP-Cron это встроенный в WordPress планировщик задач: публикация отложенных записей, проверка обновлений, рассылки, очистка, а также задачи, которые добавляют плагины. По справочнику разработчика WordPress о Cron, WP-Cron проверяет список запланированных задач при каждой загрузке страницы и запускает те, срок которых подошел, прямо во время этой загрузки.
Отсюда два сценария перегрузки. Первый: плагин поставил тяжелую задачу (синхронизацию остатков, импорт, рассылку) слишком часто, и она наслаивается сама на себя. Второй: на сайт приходит много запросов, и проверка расписания запускается постоянно. Посмотреть список задач можно командой WP-CLI wp cron event list или плагином для просмотра cron-событий. Ищите задачи с интервалом в одну-пять минут и незнакомыми названиями: по префиксу обычно понятно, какому плагину они принадлежат.
Решение, которое рекомендует сама документация, такое: отключить запуск WP-Cron на каждой загрузке страницы и вызывать его по расписанию сервера. В инструкции по привязке WP-Cron к системному планировщику для этого в wp-config.php добавляется строка define( ‘DISABLE_WP_CRON’, true );, а на сервере настраивается регулярный запрос к файлу wp-cron.php. В панели почти любого хостинга есть раздел планировщика заданий, где это делается без командной строки.
admin-ajax.php это общий адрес, через который WordPress и плагины обмениваются данными с сервером без перезагрузки страницы. Один из постоянных клиентов этого адреса Heartbeat API. По описанию Heartbeat API в справочнике WordPress, код на странице запускает «тик» с интервалом от 15 до 120 секунд и отправляет данные на сервер. Если пять сотрудников держат открытыми по несколько вкладок админки весь рабочий день, получаются тысячи обращений к PHP, которые никто не видит. Добавьте сюда плагины, которые через admin-ajax.php обновляют корзину, счетчики или формы на фронте, и график CPU растет без единого нового посетителя.
Что делать: закрывать лишние вкладки админки, ограничить частоту Heartbeat и выяснить по логам, какой action вызывается чаще всего. Его название обычно прямо указывает на плагин.
Боты и сканеры: когда виноват не код
Если в логах в пиковые минуты преобладают одни и те же IP-адреса или User-Agent, нагрузку создают боты, и отключение плагинов не поможет. Это могут быть поисковые роботы, которые обходят тысячи страниц фильтров, SEO-сервисы с агрессивным сканированием, парсеры цен конкурентов или подборщики паролей, которые долбят wp-login.php и xmlrpc.php.
Порядок действий здесь другой:
- Отсортируйте строки лога доступа за пиковый час по IP и по User-Agent, найдите первую десятку.
- Проверьте, не являются ли «поисковые роботы» подделкой: настоящие боты Google и Яндекса проверяются обратным DNS-запросом, поддельные просто подставляют название в User-Agent.
- Закройте от обхода бесполезные страницы: параметры фильтров, сортировки, внутренний поиск. Для этого используйте robots.txt и тег noindex, а сами ссылки фильтров по возможности сделайте не индексируемыми.
- Подбор паролей и спам-обращения к xmlrpc.php ограничьте на уровне сервера или плагина безопасности. Базовый набор мер мы собрали в статье о том, как защитить сайт на WordPress от взлома.
- Агрессивные сторонние сканеры блокируйте по User-Agent или IP через .htaccess или панель хостинга.
С поисковыми роботами осторожнее. Блокировать Googlebot целиком нельзя: сайт выпадет из поиска. У Google есть официальный способ временно снизить частоту обхода. Согласно справке Google о снижении частоты сканирования, для срочного снижения на короткий срок (пару часов или один-два дня) можно отвечать роботу кодом 500, 503 или 429 вместо 200. Держать так сайт долго не стоит, иначе страницы начнут выпадать из индекса. Долгосрочно лучше убрать мусорные адреса, которые робот обходит зря.
Чем отличается разовый всплеск нагрузки от постоянной проблемы
Разовый всплеск связан с событием, а постоянная проблема повторяется каждый день примерно в одно время. Если блокировка случилась один раз, после массового импорта товаров, рекламной рассылки или обновления плагина с пересчетом данных, достаточно понять событие и в следующий раз запускать такие операции ночью или пачками. Если пики идут по расписанию, например каждый час или каждую ночь в 3:00, ищите задачу cron или резервное копирование. Если нагрузка ровно высокая весь день, смотрите на ботов и на плагины, которые обрабатывают каждый запрос.
| Как выглядит график | Вероятная причина | С чего начать |
|---|---|---|
| Один пик после конкретного действия | Импорт, массовое обновление, пересоздание миниатюр | Перенести операцию на ночь, разбить на части |
| Пики в одно и то же время | Задача WP-Cron, резервное копирование, сканирование безопасности | Список cron-событий, расписание бэкапов |
| Нагрузка в рабочие часы | Heartbeat и открытые вкладки админки, admin-ajax.php | Логи по admin-ajax.php и action |
| Ровно высокая нагрузка круглые сутки | Боты, обход фильтров, тяжелый плагин на каждом запросе | Логи по IP и User-Agent, Query Monitor |
Как снизить нагрузку после того, как виновник найден
После того как виновник найден, нагрузку снижают тремя способами: настройкой или заменой плагина, кэшированием и, при необходимости, переходом на более подходящий тариф. Порядок важен. Переезд на дорогой тариф без устранения причины часто только отодвигает следующую блокировку.
Кэширование страниц сильнее всего снижает нагрузку от анонимных посетителей и ботов: сервер отдает готовый HTML, не запуская PHP и не обращаясь к базе. Как выбрать и настроить кэш, чтобы не сломать корзину и формы, разобрано в статье про кэширование WordPress. Учтите, что кэш не помогает с admin-ajax.php, задачами cron и запросами залогиненных пользователей, поэтому эти источники нужно лечить отдельно.
Если сайт честно вырос (интернет-магазин на десятки тысяч товаров, интеграция с 1С и CRM, ежедневные выгрузки), виртуальный хостинг может просто перестать подходить. Тогда разумно обсудить VPS или специализированный тариф для WordPress. Критерии выбора мы описывали в материале про хостинг для WordPress в Казахстане.
Когда разбираться с логами, cron и плагинами самому некогда или некому, задачу можно передать подрядчику. Команда B2BPRO.KZ делает такой разбор в рамках разработки и сопровождения сайтов на WordPress: находим источник нагрузки, правим настройки или заменяем проблемный модуль, настраиваем cron по расписанию сервера и кэширование, а потом проверяем по графикам хостинга, что пики ушли.
Пример: интернет-магазин, который блокировали каждую ночь
Ниже обобщенный пример, собранный из типичных ситуаций, без привязки к конкретному клиенту. Интернет-магазин на WooCommerce с каталогом в несколько тысяч позиций получал блокировку от хостинга два-три раза в неделю, всегда ночью. Владелец был уверен, что сайт «атакуют».
Хостинг прислал статистику: пики начинались около двух ночи и длились около часа, основная нагрузка шла от wp-cron.php и от index.php с параметрами фильтров. Список cron-событий показал две задачи: ночную синхронизацию остатков с учетной системой и полное резервное копирование. Обе стояли на одно и то же время. Параллельно в логах нашелся бот SEO-сервиса, который в те же часы обходил тысячи комбинаций фильтров по цвету и размеру.
Исправление заняло один рабочий день. Резервное копирование перенесли на другое время и исключили из него папку кэша. Синхронизацию разбили на пачки. WP-Cron перевели на системный планировщик хостинга. Параметры фильтров закрыли от индексации, а сторонний сканер заблокировали по User-Agent. Блокировки прекратились, и переходить на дорогой тариф не понадобилось.
Причин было три, и удаление первого попавшегося плагина не помогло бы: картину дали только данные хостинга по времени и адресам.
Как не допустить повторной блокировки
Повторную блокировку предотвращает регулярный контроль: раз в месяц смотрите график нагрузки, список задач cron и новые плагины. Несколько привычек, которые снимают большую часть рисков:
- Каждый новый плагин ставьте сначала на копию сайта и проверяйте Query Monitor до и после.
- Тяжелые операции (импорт, рассылки, бэкапы, пересоздание миниатюр) планируйте на ночь и разносите по времени.
- Храните резервные копии вне хостинга, а не в той же папке, где лежит сайт.
- Удаляйте плагины, которыми не пользуетесь: отключенный плагин иногда оставляет задачи в cron и данные в базе.
- Подключите мониторинг доступности, чтобы узнавать о блокировке раньше клиентов. Как это сделать без больших затрат, описано в статье о том, как узнать, что сайт упал, раньше клиентов.
Если нагрузка остается высокой и после всех проверок, посмотрите на сайт целиком: устаревшую тему и десятки плагинов, наслоившихся за годы, часто дешевле переделать, чем латать. Решение принимают по цифрам, сравнивая цену простоев и цену переработки.
Частые вопросы
Можно ли просто попросить хостинг снять блокировку и продолжить работу?
Попросить можно, и обычно хостинг снимает ограничение, но без устранения причины блокировка повторится через несколько дней. Вместе с просьбой о разблокировке запросите статистику нагрузки, время пиков и список самых частых скриптов и IP-адресов. По этим данным причину обычно находят за один-два часа, а потом исправляют настройку или плагин.
Как понять, какой плагин WordPress грузит процессор?
Надежнее всего найти плагин методом исключения на копии сайта: отключите половину плагинов, понаблюдайте график нагрузки 15-30 минут, затем проверьте вторую половину и делите дальше. Параллельно поставьте бесплатный плагин Query Monitor: он показывает запросы к базе, вызовы HTTP API, Ajax и REST и группирует их по плагину или теме, поэтому тяжелый компонент обычно виден сразу.
Что делать, если сайт заблокирован и админка WordPress не открывается?
Если админка не открывается, отключите все плагины через файловый менеджер хостинга или FTP: переименуйте папку wp-content/plugins, например в plugins.hold, и WordPress перестанет загружать плагины. При доступе по SSH то же делает команда wp plugin deactivate —all. После этого верните прежнее имя папки и включайте плагины по одному, наблюдая за нагрузкой.
Стоит ли отключать WP-Cron, если он создает нагрузку?
Полностью отключать задачи нельзя, но запуск WP-Cron на каждой загрузке страницы отключить стоит. Для этого в wp-config.php добавляют define( ‘DISABLE_WP_CRON’, true ), а в планировщике заданий хостинга настраивают регулярный запрос к wp-cron.php. Так задачи по расписанию продолжат выполняться, но перестанут запускаться от каждого визита посетителя или бота.
Поможет ли переход на более дорогой тариф хостинга?
Переход на тариф с большим лимитом помогает, только если сайт действительно вырос: большой каталог, интеграции с 1С и CRM, ежедневные выгрузки. Если нагрузку создают боты, неудачно настроенный плагин или задачи cron, на новом тарифе проблема вернется, просто позже. Поэтому сначала найдите источник нагрузки по логам, а о смене тарифа или переезде на VPS решайте после этого.