Обслуговування сайту - це не “іноді оновити плагіни”. Нормальна підтримка знижує три практичні ризики: сайт перестає приймати заявки, сайт зламують, власник втрачає дані чи доступи.
Для малого і середнього бізнесу у Франції це вже не теорія. За даними France Num за 2025 рік, 52% TPE/PME побоюються втрати чи злому даних, а 36% уже стикалися з кіберінцидентом. Тому обслуговування сайту потрібно оцінювати не за гарним словом у договорі, а за конкретними діями.
Що має входити в обслуговування
Хороше обслуговування можна розкласти на зрозумілі блоки.
Резервні копії
Потрібен бекап файлів і бази даних. Не просто “десь на хостингу”, а з зрозумілою частотою, терміном зберігання і можливістю відновити сайт. Для робочого сайту мінімум - регулярна копія бази, копія файлів, зберігання поза основною папкою сайту і періодична перевірка відновлення.
Оновлення
Потрібно оновлювати WordPress, тему, плагіни і іноді версію PHP. Але оновлення не має бути сліпим натисканням кнопки. Нормальний порядок такий: бекап, перевірка сумісності, оновлення, перевірка головних сторінок, форм, меню, кошика чи бронювання.
Форми і пошта
Форма може показувати “повідомлення відправлено”, але лист не дійти. Тому потрібно періодично перевіряти контактні форми, SMTP, службові сповіщення, SPF, DKIM і DMARC. Для бізнесу втрачена заявка часто дорожча за місячну підтримку.
Безпека
Потрібно дивитися користувачів WordPress, зайві адмінські акаунти, слабкі паролі, старі плагіни, підозрілі файли, права доступу і повідомлення хостингу. Якщо сайт на WordPress довго не оновлювався, ризик зазвичай зростає не різко, а поступово.
Аналіз журналів сервера
Це важливий пункт, який часто забувають. Журнали сервера допомагають побачити те, що не видно на сайті: часті помилки 404 і 500, спроби входу, звернення до wp-login.php, xmlrpc.php, admin-ajax.php, підозрілі POST-запити, перевантаження PHP, проблеми з пам’яттю, дивні IP-адреси і масові запити до неіснуючих сторінок.
Регулярний аналіз логів допомагає зрозуміти, чи сайт просто “іноді гальмує”, чи на ньому вже йде підбір паролів, сканування вразливостей, помилка плагіна, проблема з сервером чи спроба спам-атаки.
Швидкість і технічний стан
Потрібно стежити за розміром зображень, кешем, помилками JavaScript, важкими плагінами, навантаженням на сервер, часом відповіді і мобільною версією. Швидкість впливає не тільки на PageSpeed, а й на заявки: якщо сторінка довго відкривається з телефону, частина клієнтів іде.
Контент і актуальність
Обслуговування сайту - це не тільки техніка. Ціни, послуги, години роботи, фотографії, юридичні сторінки, контакти і посилання на соцмережі теж застарівають. Якщо клієнт бачить застарілу інформацію, довіра падає ще до першого дзвінка.
Звіт
Власник має розуміти, що було зроблено: які оновлення пройшли, чи були помилки, коли був бекап, чи перевірялися форми, чи були підозрілі події, що потрібно вирішити пізніше. Без звіту підтримка перетворюється на “ми щось робили”.
Приклад з практики
Уявімо невеликий сайт послуг на WordPress. На сайті є контактна форма, пошта на домені, кілька сторінок послуг і блог. Власник давно не заходив в адмінку: один плагін застарів, резервну копію не перевіряли, журнали сервера ніхто не дивився.
Через вразливість зловмисник отримує доступ до сайту. Ззовні сайт ще виглядає нормально, тому власник не одразу помічає проблему. Але всередині з’являється шкідливий файл, створюються приховані сторінки і запускається розсилка спаму від імені домену.
Далі починається ланцюг наслідків.
- хостинг бачить масову відправку листів і обмежує вихідну пошту;
- домен чи IP потрапляє в спам-бази;
- листи з сайту і робочої пошти починають потрапляти в спам чи взагалі відхиляються;
- контактна форма формально працює, але заявки не доходять;
- Google знаходить зламані чи спамні сторінки;
- у Search Console з’являється попередження про проблеми безпеки;
- у пошуку може з’явитися позначка, що сайт небезпечний чи зламаний;
- частина сторінок втрачає видимість, реклама і заявки просідають.
Тепер проблема вже не “оновити плагін”. Потрібно зупинити розсилку, зберегти докази, зробити технічну копію, знайти точку входу, почистити файли і базу, видалити прихованих користувачів, змінити паролі, оновити ключі, перевірити права доступу, закрити вразливість, видалити спамні сторінки, повернути правильні коди 404 чи 410, відправити сайт на перевірку в Google, відновити поштову репутацію і розбиратися зі спам-базами.
На це можуть піти дні, а іноді тижні. Поки процес триває, бізнес втрачає заявки, довіру і прибуток. Найприкріше, що частина збитків з’являється не в момент злому, а пізніше: листи вже не доходять, Google ще не зняв попередження, клієнти не впевнені, чи можна відкривати сайт.
Що власник може перевірити сам
Перед замовленням підтримки варто поставити конкретні питання.
- Коли був останній бекап файлів і бази даних?
- Де зберігається копія, крім основного сайту?
- Хто перевіряє, що бекап реально можна відновити?
- Як часто оновлюються WordPress, тема і плагіни?
- Що відбувається, якщо після оновлення сайт ламається?
- Чи перевіряються форми і доставка листів?
- Чи налаштовані SPF, DKIM і DMARC для доменної пошти?
- Чи дивиться хтось журнали сервера і помилки PHP?
- Чи є перевірка підозрілих користувачів і файлів?
- Чи є Google Search Console і сповіщення про проблеми безпеки?
- Чи отримує власник короткий звіт про роботи?
Якщо на ці питання немає ясних відповідей, обслуговування по суті немає. Є тільки надія, що сайт не зламається.
Часті помилки в обслуговуванні
Найдорожчі помилки зазвичай виглядають спокійно.
- бекап є, але ніхто жодного разу не пробував відновлення;
- оновлення запускаються без копії сайту;
- форма не тестується місяцями;
- пошта сайту не налаштована через нормальний SMTP;
- власник не знає, хто має адмінський доступ;
- старі плагіни залишаються “бо поки що працює”;
- журнали сервера ніхто не відкриває;
- попередження Search Console ігноруються;
- договір підтримки не каже, що відбувається за термінової проблеми.
Проблема не в тому, що сайт колись зламається. Будь-яка система може дати збій. Проблема в тому, що без процесу власник дізнається про збій від клієнта, від хостингу чи після падіння заявок.
Коли краще делегувати
Делегувати обслуговування варто, якщо сайт приносить заявки, пов’язаний з робочою поштою, рекламою, бронюванням, продажами чи репутацією компанії. Що більше сайт впливає на гроші, то менше сенсу обслуговувати його випадково.
Zen Webmaster може взяти на себе регулярну технічну підтримку: бекапи, оновлення, перевірку форм, базову безпеку, аналіз журналів сервера, контроль помилок, швидкість, дрібні правки і зрозумілий звіт.
Якщо хочете побачити, що входить в обслуговування на практиці, можна подивитися сторінку обслуговування сайту і наші тарифи.
Якщо у власника є час і бажання, частину перевірки можна робити самостійно. Але якщо сайт має працювати як інструмент бізнесу, краще, щоб за ним був зрозумілий регламент і людина, яка відповідає за технічний порядок.
Останні статті
