Коли клієнт запитує "а чи безпечний буде мій сайт" — відповідь залежить від того на чому він побудований. Це не маркетинг і не перебільшення. Ми двічі відновлювали зламані WordPress-сайти для клієнтів що прийшли до нас після інцидентів. Обидва рази причина — вразливий плагін. Обидва рази переробляли на чистий код. Після цього — жодного інциденту.

Нижче — не страшилки, а реальна технічна картина: чому статичний сайт захищений самою своєю природою, і що саме вразливе у WordPress.

Найчастіша помилка власників бізнесу — думати що захист сайту це турбота розробника. "Розробник встановив Wordfence — значить захищені." Ні. Wordfence це як замок на дверях картонного будинку. Він щось робить, але якщо в стінах діри — замок не врятує. Єдиний справді захищений варіант — коли нема чого ламати. Статичний HTML саме такий.
V
VGRB Expert Solutions
Розробка захищених сайтів на чистому коді з 2023 року

Реальна статистика: хто і як ламає сайти

Більшість зломів — автоматизовані. Бот сканує інтернет, знаходить WordPress-сайти, перевіряє відомі вразливості, намагається увійти. Без жодної участі людини. Ці боти не "вибирають жертву" — вони просто сканують всіх підряд.

WordPress-сайти серед зламаних96.2%
Злами через вразливі плагіни61.2%
Злами через brute force /wp-admin16.1%
Злами через застаріле ядро WP13.4%
Чисті HTML-сайти серед зламаних<0.5%

Дані: Sucuri Website Threat Research Report 2025

Вектори атак на WordPress яких немає у статичних сайтах

💉

SQL-ін'єкції через плагіни

Вразливий плагін не очищує вхідні дані → зловмисник вставляє SQL-запит у форму → отримує доступ до бази даних з усіма паролями та контентом. У статичного HTML немає бази даних — немає і ін'єкції.

🔑

Brute Force на /wp-admin

Автоматизовані боти перебирають паролі до стандартної адреси адмінки WordPress. Мільйони спроб за годину. На HTML-сайті /wp-admin не існує — атакувати нічого.

🦠

Malware через скомпрометовані плагіни

Розробник залишив плагін без підтримки, хакери знайшли вразливість — всі сайти з цим плагіном інфіковані. Класичний приклад: Popup Builder (2024, 5M+ інсталяцій). Без плагінів — немає цього вектора.

📜

XSS через вразливі теми та плагіни

Зловмисник вставляє шкідливий JavaScript через незахищені форми або коментарі — скрипт виконується у браузерах відвідувачів. Статичний HTML без серверної обробки форм — мінімальний ризик XSS.

🛡️

Чистий HTML — жоден з цих векторів не працює

Немає PHP → немає виконання серверного коду. Немає бази → немає SQL. Немає плагінів → немає сторонніх вразливостей. Немає /wp-admin → brute force неможливий. Зловмисник бачить набір статичних файлів — і йде далі.

Як виглядав реальний злом: хронологія інциденту

⚠️ Реальний кейс: злом WordPress-сайту клієнта через вразливий плагін
День 1
Плагін Contact Form 7 Datepicker отримав критичну вразливість. Розробник більше не підтримував плагін — оновлення не було.
День 3
Автоматизований бот просканував 2.3 мільйони WordPress-сайтів за 6 годин. Знайшов 140 000 з вразливою версією плагіну.
День 4
На сайт клієнта завантажено PHP-шелл через форму. Зловмисник отримав доступ до всіх файлів хостингу.
День 5
Сайт почав перенаправляти відвідувачів на фішинговий ресурс. Google внес сайт до списку небезпечних — трафік впав до нуля.
День 8
Клієнт звернувся до нас. Відновлення WordPress зайняло 2 дні і $200. Рішення: перенесли на чистий HTML. За наступні 18 місяців — жодного інциденту.

Порівняння рівня захисту: що є і чого немає

❌
WordPress — вразливістьPHP-код виконується на сервері при кожному запиті
✅
Чистий HTML — захистНемає серверного коду — немає виконання
❌
WordPress — вразливістьБаза даних MySQL з паролями та контентом
✅
Чистий HTML — захистНемає бази даних — немає SQL-ін'єкцій
❌
WordPress — вразливістьДесятки плагінів від різних розробників
✅
Чистий HTML — захистНемає плагінів — немає сторонніх вразливостей
❌
WordPress — вразливістьСтандартна адреса /wp-admin для всіх
✅
Чистий HTML — захистНемає адмін-панелі за стандартною адресою
❌
WordPress — вразливістьНові вразливості виходять щотижня
✅
Чистий HTML — захистПісля розробки код не "застаріває" у плані безпеки

⚠️ Не означає що HTML-сайт невразливий взагалі: якщо є PHP-форми, необхідна валідація та захист від спаму. Якщо є хостинг — важлива безпека самого сервера. Але загальна поверхня атаки — в десятки разів менша ніж у WordPress.

Мене часто запитують: "А якщо я встановлю на WordPress всі захисні плагіни — він буде таким же безпечним?" Відповідь чесна: ні. Захисний плагін сам може стати вразливістю. Це не гіпотеза — у 2024 році плагін безпеки Really Simple SSL (4 мільйони інсталяцій) мав критичну вразливість що дозволяла обійти авторизацію. Парадокс? Ні — просто математика: більше коду → більша поверхня атаки.
V
VGRB Expert Solutions
Відновлення зламаних сайтів та перехід на захищену архітектуру

Що робити якщо ваш сайт вже на WordPress

Не завжди є можливість одразу переїхати. Якщо залишаєтесь на WordPress — ось мінімум що необхідно:

  1. Оновлюйте ядро та всі плагіни щотижня — більшість зломів відбувається через відомі вразливості у застарілих версіях
  2. Видаліть невикористовувані плагіни — навіть вимкнений плагін залишається кодом на сервері
  3. Змініть стандартну адресу адмінки — /wp-login.php замість /wp-admin зменшує brute force на 80%
  4. Увімкніть двофакторну авторизацію — навіть якщо зловмисник дізнається пароль, без телефону не зайде
  5. Автоматичні резервні копії щодня — якщо злом стався, відновитись за 1 годину замість 2 днів

✅ Найкращий захист — це архітектура, а не плагіни. Кожен наш сайт на чистому HTML/CSS/JS фізично не має вразливостей PHP/SQL класу. Це не набір захисних заходів — це відсутність самих векторів атаки.

Часті запитання

Чому сайт на чистому коді захищеніший за WordPress?
Немає PHP → немає SQL-ін'єкцій. Немає бази даних → немає витоку паролів. Немає плагінів → немає вразливостей третіх сторін. Немає /wp-admin → brute force неможливий. 96.2% зламаних сайтів — WordPress. Серед HTML-сайтів — менше 0.5%.
Як захистити WordPress-сайт від злому?
Мінімум: оновлювати ядро та плагіни щотижня, видалити невикористовувані плагіни, змінити стандартну адресу /wp-admin, увімкнути двофакторну авторизацію, налаштувати автоматичні резервні копії щодня. Але навіть при всьому цьому ризик вразливого плагіну залишається.
Чи може HTML-сайт бути зламаний?
Теоретично — так, через вразливість сервера або PHP-форм якщо вони є. Але типові автоматизовані атаки на WordPress (SQL-ін'єкції, brute force, вразливі плагіни) — фізично неможливі на статичному HTML. Поверхня атаки в десятки разів менша.
🔒 Захищений сайт — це архітектура, не плагіни

Сайт на чистому коді: максимальний захист за замовчуванням

HTML/CSS/JS без WordPress, без PHP, без плагінів. Немає вразливостей — немає зломів. Від $149 одноразово.

🔒 Замовити захищений сайт → Читати: сайт без WordPress
✅ Без PHP · Без бази даних · Без плагінів · PageSpeed 95+ · Від $149
📖 Кластер Сайти без CMS
🏛️ Сайт без WordPress: повний гайд WordPress vs HTML: порівняння Швидкість сайту та SEO 💻 Розробка сайтів VGRB