Постійне завантаження CPU на 100% означає, що сайт майже безперервно використовує весь доступний процесорний ресурс хостингу. Наслідки помітні швидко: сторінки відкриваються повільно, адмінпанель зависає, з’являються помилки 503 або 504, а хостер надсилає попередження про перевищення лімітів. Купівля дорожчого тарифу може тимчасово приховати симптом, але без діагностики проблема часто повертається.
Як визначити джерело навантаження
Почніть із часу виникнення піків. У панелі хостингу подивіться графіки CPU, кількість процесів, звернень до PHP та бази даних. Якщо навантаження зростає в однакові години, причина може бути в запланованому завданні. Раптові нерегулярні піки частіше пов’язані з ботами, атаками, імпортом даних або проблемним плагіном.
Важливо відокремити реальний трафік від внутрішньої роботи WordPress. Порівняйте час піків із журналами відвідувань і діями в адмінпанелі. Якщо користувачів мало, а процесор перевантажений, потрібна технічна перевірка коду, запитів до бази та фонових операцій. За складних випадків доречно залучити вебексперта з WordPress, який зможе зіставити кілька джерел даних, а не лише оцінити графік.
Плагіни, cron і боти
Найчастіше CPU перевантажують плагіни резервного копіювання, сканування безпеки, статистики, імпорту та синхронізації. Не вимикайте все навмання на робочому сайті. Краще перевірити активність на тестовій копії або поетапно відключати підозрілі компоненти в безпечний час, фіксуючи зміни навантаження.
Окрема причина — WP-Cron. Якщо завдання запускаються при кожному відвідуванні, накопичилися в черзі або виконуються надто часто, вони можуть створити постійний фон навантаження. Боти також здатні тисячі разів відкривати пошук, фільтри, сторінки авторизації чи неіснуючі URL. У цьому разі потрібні обмеження на рівні сервера, CDN або захисного сервісу.
Аналіз журналів хостингу
Журнали доступу показують, які адреси запитували найчастіше, з яких IP і якими методами. PHP error log допомагає знайти повторювані помилки, а slow query log — важкі запити до бази даних. Один запис не завжди доводить причину, тому шукайте повторюваність і збіг у часі з піками CPU.
Особливу увагу зверніть на admin-ajax.php, wp-cron.php, xmlrpc.php, REST API та сторінки з динамічними фільтрами. Вони можуть бути легітимними, але надмірна кількість звернень потребує пояснення. Якщо після редизайну або оновлення сайт став повільним, корисно окремо перевірити, чому Core Web Vitals стали червоними.
Як запобігти повторним зупинкам сайту
Після усунення причини налаштуйте кешування, реальний системний cron, обмеження для агресивних ботів і моніторинг доступності. Оновіть WordPress, тему та плагіни, але спершу створіть резервну копію й перевірте сумісність. Видаліть непотрібні компоненти, оптимізуйте важкі запити та узгодьте ресурси тарифу з фактичним навантаженням.
Корисно мати визначений порядок реакції: хто отримує сповіщення, де зберігаються резервні копії та хто має доступи. Це частина системної підтримки; повний орієнтир дає матеріал про те, що входить у технічну підтримку сайту. Коли CPU знову почне зростати, команда зможе реагувати за фактами, а не чекати чергової зупинки.