1. SSL-сертифікат дійсний і автоматично продовжується
Відкрийте сайт і перевірте значок замка в адресному рядку браузера. Якщо є попередження — сертифікат прострочений або налаштований неправильно. Детально про те, як це працює і чому важливо саме автопродовження, — у статті навіщо сайту SSL і як його увімкнути.
2. CMS і плагіни/теми оновлені до актуальних версій
Зайдіть в адмінку й перевірте розділ оновлень. Застарілі версії WordPress, плагінів чи тем — головна причина автоматизованих зламів: боти сканують інтернет саме в пошуках відомих вразливостей у старих версіях.
3. Немає «тестових» чи забутих облікових записів адміністратора
Перевірте список користувачів з правами адміністратора в CMS. Часто лишаються акаунти, створені для підрядника чи тестування, про які всі забули, — це зайва точка входу для зловмисника.
4. Паролі до адмінки й FTP/панелі не змінювались роками
Якщо не пам'ятаєте, коли востаннє змінювали пароль до адмінки сайту чи до панелі хостингу, — саме час це зробити. Складний унікальний пароль, який не використовується більше ніде, — базовий, але дуже дієвий захист.
5. Бекапи справді відбуваються і їх можна відновити
Перевірте не тільки факт наявності бекапів, а спробуйте (чи попросіть підтримку) підтвердити, що останній бекап справді можна відновити. Механіка бекапів на Meridaro — в статті як улаштовані щоденні бекапи поза сервером.
6. Форми на сайті не є відкритим каналом для спаму
Перевірте, чи є на формах (контакти, коментарі) хоч якийсь захист від автоматичного спаму — капча чи аналог. Незахищена форма — джерело як спаму, так і потенційного вектора атаки.
7. Домен не близький до закінчення реєстрації
Прострочений домен — це не про хостинг, але про безпеку в широкому сенсі: сайт стає повністю недоступним, а домен ризикує потрапити в чужі руки. Перевірте дату закінчення реєстрації в кабінеті реєстратора.
8. Є моніторинг доступності
Перевірте, чи повідомляє щось (хостинг чи окремий сервіс) про падіння сайту автоматично. Чому це важливо і як порахувати реальну вартість простою — у статті скільки коштує простій сайту для бізнесу.
9. Захист від DDoS увімкнений
Перевірте, чи проходить трафік сайту через захист (Cloudflare чи аналог). Як розпізнати атаку й що конкретно дає такий захист — у статті DDoS-атака на сайт: як розпізнати і що дає Cloudflare.
10. Резервні адміністратори мають доступ
Перевірте, чи є щонайменше двоє людей з доступом до критичних систем (хостинг, домен, CMS) — якщо єдина людина з доступом недоступна саме в момент проблеми, це затримує будь-яке вирішення.
11. Немає підозрілих файлів чи змінених дат модифікації
Через файловий менеджер панелі перегляньте кореневу директорію сайту — чи немає файлів з дивними назвами або з датою модифікації, яка не збігається з вашими останніми діями.
12. Є документ із планом дій на випадок аварії
Контакти підтримки, доступи, хто приймає рішення — все зібране заздалегідь, а не «якось розберемось у моменті». Повний шаблон такого плану — у статті аварійне відновлення сайту: план дій до того, як щось трапилось.
Як часто повторювати перевірку
Раз на квартал достатньо для більшості сайтів малого й середнього бізнесу — це не займає багато часу, але суттєво знижує ризик найпоширеніших сценаріїв проблем.
Бонусні пункти для тих, хто хоче піти глибше
Якщо базовий чек-лист вище пройдено й хочеться закрити ще трохи ризиків, ось додаткові пункти, які вже вимагають трохи більше технічних знань або допомоги підтримки:
- Двофакторна автентифікація для адмінки — якщо CMS чи панель хостингу підтримує 2FA, увімкнення суттєво ускладнює доступ навіть при витоку пароля.
- Обмеження доступу до адмінки за IP — якщо команда працює з відносно стабільних адрес (офіс, певний перелік місць), можна обмежити доступ до адмін-панелі лише з дозволених IP.
- Перевірка заголовків безпеки сайту — існують безкоштовні онлайн-сервіси, що перевіряють базові HTTP-заголовки безпеки (наприклад, чи коректно налаштований HSTS для SSL).
- Журнал дій адміністраторів — якщо CMS підтримує логування дій (хто, що і коли змінив в адмінці), це корисно і для безпеки, і для розслідування інцидентів.
Чому саме 15 хвилин, а не "коли буде час"
Конкретна цифра — 15 хвилин — навмисно взята невеликою: досвід показує, що завдання без чіткої оцінки часу відкладаються на невизначений термін, тоді як завдання з зрозумілими межами ("це займе чверть години") значно частіше виконуються реально, а не залишаються в списку "колись потрібно зробити". Якщо перша спроба пройти чек-лист виявить, що якийсь пункт вимагає більше часу (наприклад, потрібно спершу розібратися з доступами), це нормально — головне почати з того, що можна перевірити швидко, і поступово закрити решту.
Хто в команді має відповідати за кожен пункт
Чек-лист корисний, тільки якщо за кожним пунктом закріплена конкретна людина, а не абстрактне "хтось перевірить". Наприклад, оновлення CMS і плагінів логічно закріпити за тим, хто веде сайт технічно (розробник чи агентство), а перевірку доступів адміністраторів — за власником бізнесу чи керівником проєкту. Розподіл відповідальності перетворює чек-лист із теоретичного списку на процес, який реально виконується раз на квартал, а не забувається до першого інциденту.
Автоматизація частини перевірок
Частину пунктів можна частково автоматизувати замість ручної щоквартальної перевірки: сучасні CMS часто дозволяють увімкнути автоматичні оновлення для мінорних версій і плагінів безпеки, сервіси моніторингу самі сповіщають про закінчення SSL чи домену. Автоматизація не скасовує потребу в періодичній ручній перевірці повністю, але суттєво знижує шанси щось пропустити між перевірками.
Чому чек-лист варто пройти самостійно, а не тільки покластися на хостинг
Хостинг відповідає за інфраструктурний рівень захисту — сервер, мережу, бекапи. Але більшість пунктів цього чек-листа (оновлення CMS, паролі, форми, документ із планом дій) — на рівні самого сайту, і жоден хостинг не може проконтролювати це за вас. Регулярна самостійна перевірка — це та частина відповідальності, яка залишається за власником сайту незалежно від якості обраного хостингу.
Роздрукований варіант: чому це не жарт
Здається старомодним у 2026 році, але роздрукований аркуш із цим чек-листом, приколотий біля робочого місця відповідального за сайт співробітника, працює на практиці краще за документ, похований у папці серед сотень інших файлів на диску. Візуальне нагадування, яке трапляється на очі регулярно, значно частіше доводить справу до реальної щоквартальної перевірки, ніж файл, про існування якого згадують лише раз на рік.