За даними W3Techs, понад 43% усіх сайтів у світі працюють на WordPress. Але ось факт, який не афішують на лендингах хостингів: за даними Sucuri, 90% усіх зламаних сайтів у 2023 році — це сайти на WordPress.
І це не через «погану платформу». Це через неробочі оновлення, діри в безпеці, конфліктуючі плагіни та застарілі версії PHP. Те, що можна легко діагностувати — але більшість власників сайтів навіть не знають, де це подивитися.
Якщо ви — підприємець, керівник або штатний маркетолог, вам, швидше за все, знайомі ці тривоги:
Чому сайт став повільніше працювати?
Чому реклама вливає трафік, а заявок немає?
Чому з’явилися помилки після чергового оновлення?
Хто і коли останній раз перевіряв, чи все в порядку з сайтом?
І ось тут на сцену виходить функція, про яку мало хто говорить — «Здоров’я сайту» в WordPress. Я, як засновник веб-студії BUSINESS SITE, яка з 2011 року допомагає бізнесу залучати клієнтів через інтернет, можу сказати прямо: сайт може виглядати відмінно і навіть продавати, але при цьому бути «технічно хворим» і з кожним днем втрачати потенціал.
У цій статті я розповім:
Що саме показує функція Site Health.
Які помилки вона допомагає знаходити.
Чому без неї не можна працювати «в довгу».
І як її використовувати як інструмент контролю ефективності та безпеки.
Якщо ваш сайт — це бізнес-інструмент, цей матеріал обов’язковий до прочитання.
Що таке здоров’я сайту в WordPress?
Функція Site Health — це вбудований у WordPress системний інструмент діагностики, що з’явився у версії 5.2. Його завдання — допомогти власникам сайтів і розробникам своєчасно виявляти і усувати технічні проблеми, які можуть вплинути на безпеку, продуктивність і стабільність ресурсу.
Знайти її можна в адміністративній панелі WordPress за шляхом: Інструменти → Здоров’я сайту (Site Health).
При відкритті ви побачите два ключові розділи:
Вкладка «Стан» (Status)
Це зведення всіх актуальних зауважень до вашого сайту, розділене за рівнем важливості:
Критичні проблеми (Critical issues):
Наприклад, ваш сайт працює на застарілій версії PHP (нижче 7.4), відсутній SSL-сертифікат або порушена робота REST API. Це може призвести до:
Уразливостей в безпеці.
Некоректної роботи плагінів.
Помилок у відправці форм чи оновленнях.
Приклад: Один з сайтів клієнта у сфері логістики почав «давати збої» — форми заявки то відправлялися, то ні. Перевірка Site Health показала відключений REST API через налаштування firewall на сервері. Після правки API запрацював — і потік лідів відновився.
Рекомендації (Recommended improvements):
Це менш критичні, але важливі для довгострокової стабільності пропозиції. Наприклад:
Вимкніть невикористовувані плагіни.
Перевірте, чи ввімкнено захист REST API.
Перевірте, чи активний cron (планувальник завдань).
Оновіть тему, якщо вона застаріла.
Приклад: У маркетингового агентства сайт показував у Site Health рекомендацію ввімкнути cron. Виявилося, автоматичні завдання, включаючи перевірку оновлень і публікацій відкладених постів, не працювали. Після ввімкнення cron кампанія з запуску блог-контенту заробила вчасно.
Пройдені тести:
Всі параметри, які вже налаштовані коректно, тут відзначаються зеленим. Це «здорові» ділянки сайту.
Вкладка «Інформація» (Info)
Цей розділ — технічний паспорт вашого сайту. Тут зібрана системна інформація, яку важливо знати при техпідтримці або передачі проекту на аудит:
Версії WordPress, PHP, MySQL.
Стан тем і плагінів.
Налаштування сервера та шляхів (wp-content, wp-uploads і т.д.).
Стан безпеки (SSL, REST API, захист XML-RPC).
Встановлені модулі PHP і параметри сервера.
Приклад використання: При передачі клієнтського сайту на SEO-просування ми завжди просимо експорт цієї вкладки. Це дозволяє відразу побачити: Чи підходить сервер під сучасні вимоги. Які плагіни можуть бути потенційною загрозою. Чи потрібно посилювати захист або продуктивність.
Site Health — це не просто «ще один пункт меню». Це ваш помічник по техобслуговуванню сайту. Аналогія з реального бізнесу: як в автомобілі — індикатори на панелі. Якщо горить “чек”, ви не ігноруєте його. Ось і Site Health — ваша панель стану WordPress.
Навіщо стежити за здоров’ям сайту?
Більшість власників сайтів не заглядають в «Здоров’я сайту» доки не почнуть втрачати гроші. Але правда в тому, що саме цей інструмент часто першим подає сигнал, що сайт «хворий»: завантажується повільно, не індексується, або, що гірше — стає уразливим для атак.
Якщо нехтувати регулярною перевіркою, наслідки можуть бути критичними:
Сайт перестає відображатися в пошуку.
Користувачі бачать помилки або порожню сторінку.
Онлайн-форма не відправляє заявки.
Падає швидкість завантаження — і користувачі йдуть.
Виникають діри в безпеці — і сайт можуть зламати.
Реальний кейс з практики: Один з клієнтів — власник сайту у сфері освітніх послуг — звернувся зі скаргою: за 2 тижні трафік з Google впав на 60%, дзвінки з сайту практично припинилися. При цьому зовні все працювало. Перше, що ми зробили — зайшли в Site Health. Результат: Сайт працював на PHP 5.6, підтримка якого завершилася 3 роки тому. Cron-завдання не виконувались, через що сайт не відправляв sitemap у пошукові системи. Частина плагінів не оновлювалась більше року, що провокувало конфлікти на бекенді. Після переводу сайту на PHP 8.0, оптимізації плагінів і налаштування cron — позиції у Google відновилися, і вже через місяць конверсія зросла на 19%. Бізнес ожив — без редизайну, без вкладань у рекламу.
До нас звернувся логістичний оператор, чий сайт просто перестав обробляти форми зворотного зв’язку. При цьому CRM нічого не показувала — начебто заявок просто немає. Перевірка Site Health виявила: Проблеми з loopback-запитами — внутрішні звернення сайту до себе блокувались хостингом. REST API повертав помилки, і відправка заявок “падала”. Після правки конфігурації сервера і налаштування правил брандмауера заявки знову почали надходити, і клієнт повернув нормальний рівень лідогенерації.
У проектах команди BUSINESS SITE ми вбудували перевірку «здоров’я сайту» у регламентну підтримку. Чому? Тому що:
Це допомагає запобігати падінню трафіку до того, як вони трапляються.
Це дозволяє знаходити помилки, які не видно оку, але впливають на результат.
Це економить гроші клієнта на відновлення сайту, репутації та рекламних кампаній.
Щомісяця — швидка перевірка Site Health. Займає 5 хвилин. Але може заощадити сотні або тисячі доларів.
Типові помилки та як їх виправити
❌ Застаріла версія PHP Одна з найчастіших причин падіння продуктивності та уразливостей. Рекомендовано використовувати версію не нижче 8.0. Якщо ваш хостинг не підтримує її — змінюйте хостинг.
❌ REST API не працює Це може вплинути на роботу плагінів або відправку форм. Зазвичай проблема криється в конфігурації сервера.
❌ Проблеми з loopback-запитами Loopback використовується для внутрішньої роботи WordPress. Його блокують деякі хостинги. Вирішується через налаштування сервера або .htaccess.
❌ Неактивні плагіни Мертвий вантаж, який: уповільнює сайт, відкриває діри в безпеці, заважає оновленням. Видаляйте їх без жалю.
Висновок
Кожна з цих помилок на перший погляд може здаватися дрібницею. Але в умовах сучасної конкуренції будь-яка технічна недоробка перетворюється в втрату трафіку, клієнтів і грошей. Саме тому важливо не просто «мати сайт», а утримувати його в робочому і безпечному стані.
Інструмент Site Health — це не заміна розробнику, але він допомагає на ранньому етапі зрозуміти, де саме «болить» ваш сайт. А знаючи діагноз — вже можна швидко вжити заходів: самостійно або з залученням команди, як у нас у BUSINESS SITE. Своєчасна реакція — це завжди дешевше, ніж екстрене відновлення після “техногенної аварії”.