Підтримка сайту: що входить і як часто потрібна

Сайт не завершується в день запуску. З першого тижня виходять оновлення плагінів, змінюються браузери, наближається кінець строку сертифіката, застаріває контент, а пошукові системи змінюють те, що вони цінують. Сайт, за яким ніхто не стежить, не залишається таким самим. Він поступово стає повільнішим, вразливішим і менш помітним у пошуку, і зазвичай цього ніхто не помічає, поки щось не зламається.

Технічна підтримка сайту — це регулярна робота, яка цьому запобігає. У статті пояснюємо, що входить у підтримку, як часто виконувати кожне завдання, чим відрізняються потреби корпоративного сайту, інтернет-магазину, WordPress і кастомного вебзастосунку, від чого залежить вартість і коли варто тримати підтримку всередині компанії, а коли віддати команді. Ми спираємося на те, як супроводжуємо сайти, створені в межах розробки корпоративних сайтів.

Що таке технічна підтримка сайту і навіщо вона

Технічна підтримка сайту — це регулярний набір технічних, контентних і моніторингових задач, які тримають сайт захищеним, швидким, актуальним і працездатним після запуску. Її ще називають супроводом або обслуговуванням сайту, але мета однакова: сайт має щодня виконувати свою роботу для бізнесу без неприємних сюрпризів.

Що буває без підтримки, передбачувано:

Вразливості. Застарілі ядро CMS, плагіни й бібліотеки — найчастіший вхід для нападників. Більшість атак автоматизовані і шукають відомі вразливості в старих версіях. Сайт без оновлень — саме те, що вони шукають.

Падіння швидкості. Зображення додають без оптимізації, плагіни накопичуються, база даних росте, налаштування кешу «з’їжджають». Кожна зміна дрібна, але за рік сайт може завантажуватися помітно повільніше, ніж на старті, а це б’є і по конверсії, і по Core Web Vitals.

Втрата позицій. Биті посилання, помилки 404 після змін контенту, відсутні редиректи, застарілий sitemap і повільні сторінки посилають пошуковим системам негативні сигнали. Позиції рідко падають за одну ніч. Вони поступово розмиваються.

Простої. Прострочений домен чи SSL-сертифікат, переповнений диск, невдале оновлення. Проблеми з аптаймом часто спричиняють речі, яким легко було запобігти нагадуванням у календарі.

Технічний борг. Кожне відкладене оновлення робить наступне складнішим. Сайту, який пропустив два роки оновлень, може знадобитися часткова перебудова лише для того, щоб повернутися на підтримувану версію.

Добра підтримка здебільшого непомітна. Її цінність видно в тому, чого не стається: немає зламів, немає простоїв, немає повільного падіння трафіку.

Що входить у підтримку сайту

На практиці ми ділимо роботу на шість напрямів. Разом вони складають базовий перелік задач для будь-якого бізнес-сайту.

Технічні оновлення

• Оновлення ядра CMS. WordPress, Drupal чи будь-яка інша CMS регулярно випускає оновлення безпеки і функціональності. Патчі безпеки варто ставити швидко, великі версії — після тестування.

• Плагіни, теми і модулі. Найчастіше джерело вразливостей і конфліктів. Оновлюйте їх регулярно, видаляйте ті, якими більше не користуєтеся.

• Версія PHP. Кожна версія PHP має фіксований строк підтримки. Робота на версії, яка вже не підтримується, означає відсутність виправлень безпеки. Перехід на нову версію потребує перевірки сумісності теми і плагінів.

• Фреймворки і середовища. Для кастомних сайтів і headless-фронтендів це версії Node.js, фреймворки на кшталт Nuxt.js чи Next.js, залежності npm або Composer.

Усі оновлення спочатку йдуть на тестову копію, а не одразу на робочий сайт. Тестова копія (staging) — це закрита копія сайту з тими самими версіями ПЗ. Команда ставить оновлення там, перевіряє ключові сторінки, форми і оформлення замовлення, і лише потім повторює оновлення на живому сайті. Це додає годину до процесу і прибирає більшу частину ризику побачити зламану верстку чи білий екран у понеділок зранку.

Ведіть і журнал версій. Коли щось ламається через два тижні після оновлення, точне знання, який плагін з якої версії на яку змінився, економить години пошуків.

Перевіряйте SEO після кожного суттєвого оновлення. Оновлення теми чи плагіна може непомітно змінити title, прибрати мікророзмітку, додати noindex на сторінки або зламати редиректи. Особливо це стосується багатомовних сайтів: після оновлення плагіна перекладів інколи зникають hreflang чи змінюються адреси мовних версій. Після кожного суттєвого оновлення відкрийте кілька ключових сторінок кожною мовою, перевірте title і статус індексації в Google Search Console і швидко проскануйте найважливіші шаблони. Це займає пів години, а помилку, помічену одразу, виправити набагато простіше, ніж через місяць, коли трафік уже пав.

Безпека і резервні копії

• Бекапи. Автоматичні щоденні резервні копії файлів і бази даних, що зберігаються окремо від основного сервера, з кількома версіями.

• Перевірка на шкідливий код. Регулярне автоматичне сканування на впроваджений код, підозрілі файли і наявність сайту в чорних списках.

• Ревізія доступів. Видаліть колишніх працівників і підрядників, перевірте ролі адміністраторів, переконайтеся, що увімкнено двофакторну автентифікацію.

• Продовження SSL. Сертифікати мають продовжуватися автоматично. З березня 2026 року максимальний строк дії публічних TLS-сертифікатів становить 200 днів, і в найближчі роки він скорочуватиметься далі, тже ручне продовження вже непрактичне.

Пошта і домен. Підтримка сайту часто включає і корпоративну пошту на домені. Перевірте, що для домену налаштовано записи SPF, DKIM і DMARC: вони захищають від підробки листів від вашого імені і допомагають, щоб листи з форм сайту та розсилки не потрапляли в спам. Після зміни хостингу чи поштового сервісу ці записи часто «губляться», і заявки з сайту тихо перестають доходити.

Раз на рік перевіряйте, на кого зареєстровано домен і чи актуальні контактні дані власника: після зміни працівників доступ до домену інколи залишається в людини, яка вже не працює в компанії.

Безпека — велика окрема тема. Детально ми розібрали її в статті безпека сайту: чек-ліст.

Оптимізація швидкості

• Core Web Vitals. Стежте за LCP, INP і CLS у Google Search Console і виправляйте сторінки, що потрапили в зону «потребує покращення» або «погано».

• Кешування. Перевіряйте, що кеш сторінок, браузера і сервера коректно працює після оновлень і змін контенту.

• CDN. Мережа доставки контенту віддає статичні файли з серверів, ближчих до відвідувача. Переглядайте її налаштування і правила кешу, коли змінюється структура сайту.

• Оптимізація зображень. Нові зображення від редакторів часто завеликі. Автоматичне стиснення і сучасні формати WebP чи AVIF тримають сторінки легкими.

Оновлення контенту

• Застарілі сторінки. Старі акції, минулі події, послуги, яких більше немає, згадки минулих років.

• Юридична інформація. Політика конфіденційності, політика cookie та умови користування мають відповідати чинному законодавству та інструментам, якими ви реально користуєтеся.

• Команда і ціни. Контакти, адреси, співробітники, ціни і графік роботи змінюються частіше, ніж про них згадують.

Застарілий контент не просто виглядає недбало. Він створює реальні проблеми, коли клієнт телефонує в закритий офіс або розраховує на ціну, якої вже немає.

Для багатомовних сайтів додайте ще одну перевірку: чи оновили всі мовні версії разом. Часто українська версія отримує новий опис послуги, а англійська чи російська досі показує торішній текст. Пошукові системи і AI‑асистенти можуть цитувати саме застарілу версію тим, хто шукає цією мовою.

SEO-перевірки

• Биті посилання. Внутрішні і зовнішні посилання, що ведуть у нікуди, шкодять і користувачам, і скануванню.

• Помилки 404. Сторінки, які видалили чи перенесли без редиректу. Регулярно переглядайте звіти про індексацію в Google Search Console.

• 301-редиректи. Кожна змінена адреса потребує постійного редиректу на нову. Перевіряйте також ланцюжки і петлі редиректів.

• XML sitemap і robots.txt. Sitemap має містити всі важливі сторінки і нічого, що повертає помилки. Robots.txt не має випадково блокувати важливі розділи, а це трапляється напрочуд часто після оновлень і міграцій.

• Google Search Console. Стежте за індексацією, ручними санкціями, проблемами безпеки і трендами ефективності.

Аналітика і трекінг

• GA4. Перевіряйте, що дані збираються, фільтри працюють, а ключові події записуються.

• Google Tag Manager. Переглядайте теги й тригери після змін на сайті. Оновлена форма чи нова кнопка можуть непомітно зламати відстеження.

• Відстеження форм і конверсій. Тестуйте, що кожна форма справді надсилає заявки куди треба, а конверсії доходять до GA4 і рекламних кабінетів.

Зламаний трекінг — одна з найдорожчих тихих поломок. Маркетингові рішення продовжують ухвалювати на даних, які перестали бути точними кілька тижнів тому.

Документуйте сайт, а не лише задачі. Підтримувати сайт значно простіше, коли існує базова документація. Вона не має бути довгою. Один спільний документ має описувати, де розміщено сайт і на якому тарифі, де репозиторій коду, яка версія CMS, тема і плагіни встановлені і навіщо, які є інтеграції (CRM, форми, оплата, аналітика, служби доставки) і кому належить кожен акаунт, де зберігаються бекапи і як їх відновити, а також відомі особливості, наприклад плагін, який не можна оновлювати без перевірки певної форми. Коли людина, що робила сайт, іде, цей документ вирішує, чи буде передача спокійною, чи команді доведеться тижнями розбиратися в чужому коді.

Резервний контакт. Навіть якщо підтримкою займається одна людина, у вас має бути запасний варіант на випадок її відпустки, хвороби чи звільнення. Документація і доступи, оформлені на компанію, дозволяють швидко залучити іншого фахівця без втрати часу.

Чек-лист підтримки сайту за періодичністю

Це практична частина. Чек-лист нижче ділить задачі за тим, як часто їх виконувати. Адаптуйте його під свій сайт, але зберігайте ритм.

Щотижня

☐ Перевірити, що бекапи успішно створено і збережено поза основним сервером

☐ Переглянути сповіщення моніторингу аптайму і час відповіді сервера

☐ Протестувати ключові форми: зворотний зв’язок, запит комерційної пропозиції, оформлення замовлення, підписка

☐ Переглянути сповіщення безпеки від фаєрвола, плагіна безпеки чи хостингу

☐ Для інтернет-магазину: зробити тестове замовлення і перевірити оплату

Щомісяця

☐ Встановити оновлення CMS, плагінів і залежностей після перевірки на тестовій копії

☐ Просканувати сайт на биті посилання і нові помилки 404

☐ Перевірити швидкість ключових шаблонів: головна, категорія, товар, сторінки послуг

☐ Переглянути аналітику: тренди трафіку, конверсії, різкі падіння

☐ Перевірити Google Search Console на проблеми з індексацією і безпекою

☐ Запустити перевірку на шкідливий код

Щокварталу

☐ Провести ревізію контенту: застарілі сторінки, юридична інформація, ціни, команда, контакти

☐ Зробити SEO-аудит: title, meta description, редиректи, sitemap, внутрішні посилання

☐ Провести аудит доступів: видалити зайві акаунти, переглянути ролі й паролі

☐ Зробити тест відновлення: розгорнути бекап на тестовому середовищі і перевірити, що все працює

☐ Переглянути трекінг: теги, події, конверсії

Щороку

☐ Перевірити продовження домену й автопродовження, підтвердити, що автоматичне продовження SSL працює

☐ Провести UX-огляд: поведінка користувачів, форми, навігація, мобільна версія

☐ Провести аудит доступності за актуальними вимогами WCAG

☐ Зробити огляд стеку: версія CMS, PHP чи Node.js, тариф хостингу, компоненти без підтримки

☐ Переглянути сам план підтримки: що спрацювало, що пропустили, що змінити

Короткий щомісячний звіт від виконавця тримає всіх в одному контексті. Він не має бути довгим: які оновлення встановлено, що знайдено й виправлено, аптайм за місяць, події безпеки, динаміка швидкості й Core Web Vitals, рекомендації на наступний місяць. Якщо одна й та сама проблема з’являється у звіті три місяці поспіль, це сигнал, що її треба виправити по-справжньому, а не латати знову.

Чек-лист працює, лише коли за нього хтось відповідає. Закріпіть кожну задачу за людиною чи підрядником і ведіть простий журнал: що зроблено і коли. Цей журнал стає безцінним, коли щось іде не так і треба зрозуміти, що змінилося.

Перші місяці після запуску. Найбільше питань і дрібних помилок з’являється в перші тижні після запуску нового сайту. Добре, коли команда, яка його робила, залишається на зв’язку в цей період і швидко виправляє знайдене. Обговоріть гарантійний період і його умови ще до старту розробки, а після нього плавно переходьте до регулярної підтримки.

Особливості підтримки для різних типів сайтів

Чек-лист вище стосується будь-якого сайту, але вага кожного напряму залежить від типу сайту.

Корпоративний сайт. Фокус на актуальності контенту, формах заявок, аналітиці та базовій безпеці. Трафік і функціональність зазвичай стабільні, ттож для більшості компаній підходить щомісячний ритм із щоквартальною ревізією контенту. Найбільший ризик у тому, що форми чи трекінг непомітно ламаються, і заявки зникають тижнями.

Інтернет-магазин. Підтримка магазину інтенсивніша. Оформлення замовлення, платіжні інтеграції, синхронізація залишків, способи доставки і товарні фіди мають працювати щодня. Помилки в цінах і каталозі коштують грошей напряму. Магазини мають і суворіші вимоги до безпеки, зокрема PCI DSS для оплати картками, а пікові сезони потребують перевірки швидкодії заздалегідь. Для більшості магазинів мінімум — це щотижнева перевірка сценарію замовлення і негайні оновлення безпеки.

Сайт на WordPress. WordPress працює на великій частині сайтів у світі, тому це головна ціль автоматизованих атак. Для WordPress на першому місці оновлення плагінів, їхній аудит, плагін безпеки, мінімум адміністраторів і вимкнені непотрібні функції на кшталт XML-RPC. Багато проблем WordPress походять від надлишку плагінів, тож переглянути встановлене так само важливо, як оновити. Якщо у вас WordPress і потрібна допомога з оновленнями чи захистом, команда з розробки на WordPress займається і тим, і іншим.

Кастомний вебзастосунок. У кастомних застосунків немає маркетплейсу плагінів, але є залежності: фреймворки, бібліотеки, середовища виконання, серверне ПЗ. Підтримка включає оновлення залежностей, моніторинг, аналіз логів, обслуговування бази даних і перевірку сумісності зі сторонніми API, які змінюються з часом. Кастомний код також потребує розробників, які його знають, тому документація і стабільність команди тут особливо важливі.

Українська специфіка підтримки. Для українського бізнесу до стандартного переліку додаються кілька пунктів. Перший: стійкість до перебоїв з електропостачанням і зв’язком. Хостинг у дата-центрі з резервним живленням або в ЄС, копії поза основною інфраструктурою і моніторинг, що працює незалежно від вашого офісу, — тут не розкіш. Другий: мовні версії. Для компаній, що продають товари й послуги в Україні, закон вимагає, щоб українська версія завантажувалася за замовчуванням для користувачів в Україні і була не меншою за обсягом і змістом, ніж іншомовні. Тож будь-яке оновлення контенту має з’являтися українською не пізніше, ніж іншими мовами. Третій: місцеві інтеграції. Платіжні сервіси, програмні РРО, служби доставки й облікові системи час від часу оновлюють свої API, і після таких оновлень обмін даними з сайтом треба перевіряти. Четвертий: DDoS-атаки, які для українських сайтів залишаються реальністю, тож захист на рівні WAF варто включити в підтримку, а не вмикати поспіхом під час атаки.

Від чого залежить вартість підтримки сайту

Вартість залежить від сайту і від того, скільки відповідальності ви хочете передати. Єдиної ціни немає, але є зрозумілі моделі і фактори.

Моделі оплати:

• Погодинна оплата. Ви платите за фактично витрачені години. Підходить для невеликих сайтів з епізодичними задачами, але ускладнює планування бюджету і зазвичай не гарантує час реакції.

• Абонентське обслуговування. Фіксований щомісячний платіж покриває погоджений обсяг робіт і певну кількість годин. Передбачувано для обох сторін і найпоширеніша модель для бізнес-сайтів.

• Рівні SLA. Угода про рівень сервісу визначає час реакції і виправлення для різних типів проблем, наприклад критичного падіння сайту і дрібної правки контенту. Вищі рівні зі швидшою реакцією дорожчі.

Фактори вартості:

• Платформа і стек: стандартний сайт на WordPress простіше підтримувати, ніж кастомний застосунок з багатьма інтеграціями.

• Розмір і складність: кількість сторінок, шаблонів, мов та інтеграцій.

• Функції магазину: оплата, залишки, доставка і вищі вимоги безпеки.

• Потрібний час реакції: наступного робочого дня чи протягом години цілодобово.

• Поточний стан сайту: сайт з роками відкладених оновлень потребує початкового «прибирання», перш ніж почнеться регулярна підтримка.

• Робота з контентом: чи входять у підтримку регулярні оновлення контенту чи лише технічна робота.

Найточніше оцінити підтримку можна, подивившись на конкретний сайт. Ми аналізуємо платформу, поточні версії, інтеграції та ваші очікування і після брифу пропонуємо обсяг робіт і оцінку, що підходить саме цьому сайту.

Що має містити договір на підтримку. Хто б не виконував роботу, письмовий договір запобігає більшості непорозумінь. Перевірте, що в ньому є:

• Обсяг. Які задачі входять щомісяця, а які оплачуються окремо, наприклад нові сторінки, переробка розділів чи нові інтеграції.

• Час реакції і виправлення. Різний для різних пріоритетів: критичне падіння сайту, зламана форма, дрібна правка контенту.

• Робочі години. Чи реагує команда вночі і на вихідних і як з нею зв’язатися.

• Звітність. Що містить щомісячний звіт і коли ви його отримуєте.

• Доступи і власність. Домен, хостинг, код і акаунти належать вашій компанії, а підрядник працює через персональні доступи.

• Умови завершення. Що підрядник передає, якщо ви припиняєте співпрацю: доступи, документацію, свіжий бекап і список відкритих задач.

Добрий договір захищає обидві сторони і дозволяє легко оцінити, чи працює сервіс.

Штатний розробник чи підрядник

Є три поширені способи організувати підтримку. Кожен може працювати, вибір залежить від сайту і вашої команди.

Малому бізнесу зазвичай найкраще підходить абонентське обслуговування в агенції. Невелика компанія рідко потребує штатного розробника, але їй потрібен хтось, хто швидко зреагує, коли сайт ляже, і хто ставитиме оновлення без нагадувань.

Для великих продуктів межа між підтримкою і розробкою розмивається. Якщо ваш сайт чи застосунок постійно розвивається, виділена команда поєднує підтримку з новими функціями і зберігає тих самих людей на продукті.

Порівнюючи пропозиції, дивіться не лише на ставку. Запитайте, як тестують оновлення, де зберігають бекапи і як часто перевіряють відновлення, хто на зв’язку в неробочий час, як вам повідомляють про інциденти і що буде з доступами й документацією, якщо ви вирішите змінити підрядника. Відповіді скажуть про якість підтримки більше, ніж прайс.

Як передати сайт новій команді підтримки. Зміна підрядника не має бути стрибком у невідоме. Щоб передача пройшла спокійно, зробіть кілька кроків. Спершу зберіть усі доступи: хостинг, домен, DNS, CMS, репозиторій коду, аналітика, пошта, сторонні сервіси. Переконайтеся, що головні акаунти зареєстровані на компанію, а не на конкретну людину. Далі попросіть попереднього виконавця передати документацію, свіжий повний бекап і список відомих проблем та незавершених задач. Нова команда має провести аудит: перевірити версії ПЗ, безпеку, бекапи, швидкість і стан SEO, щоб зафіксувати точку старту. Лише після цього варто змінювати паролі і закривати доступ попередньому виконавцю. І останнє: перші два-три тижні тримайте зв’язок з попередньою командою, бо питання про неочевидні налаштування майже завжди з’являються.

Що робити, коли щось зламалося. Інциденти трапляються навіть на добре підтримуваних сайтах. Важливо, як швидко їх помічають і усувають. Базовий процес такий: моніторинг виявляє проблему і сповіщає відповідального, тей оцінює, критична вона (сайт не працює, оплата зламана, дані під загрозою) чи дрібна, виправляє або відкочує останню зміну, а потім коротко пояснює бізнесу, що сталося і що зроблено, щоб це не повторилося. Заздалегідь домовтеся, хто може ухвалювати рішення вночі чи на вихідних, особливо для інтернет-магазинів, де кожна година простою означає втрачену виручку.

Хоч яку модель ви оберете, зафіксуйте письмово три речі: що входить у роботу, як швидко команда реагує на різні проблеми і кому належать доступи до хостингу, домену, коду і акаунтів.

Використовуйте години підтримки для покращень, а не лише для ремонту. Багато компаній сприймають підтримку лише як захист. Кращий підхід — зарезервувати частину щомісячних годин на невеликі покращення: виправити незрозуміле поле форми, помічене в записах сесій, полегшити важку сторінку, покращити внутрішні посилання на важливу послугу, оновити кейс. Кожна зміна дрібна, але за рік вони складаються в помітно кращий сайт без вартості і ризиків великого редизайну.

Ознаки, що поточна підтримка не працює. Про падіння сайту ви дізнаєтеся від клієнтів, а не з моніторингу. Ніхто не може сказати, коли востаннє перевіряли відновлення з бекапу. Плагіни і CMS відстають на кілька версій. Звітів немає, або щомісяця в них написано «все добре» без деталей. Дрібні запити виконуються тижнями. Якщо впізнаєте два пункти чи більше, перегляньте договір або підрядника, перш ніж щось зламається.

Коли підтримки вже недостатньо

Підтримка тримає сайт здоровим, але не може виправити сайт, який більше не відповідає бізнесу. Ознаки, що час на редизайн або перебудову:

• Застаріла CMS чи стек. Платформа або її версія більше не підтримується, і оновлення все одно означає переписати великі частини сайту.

• Оновлення постійно щось ламають. Кожне оновлення спричиняє конфлікти, і команда витрачає більше часу на виправлення наслідків, ніж на покращення.

• Швидкість не виправити. Core Web Vitals залишаються поганими попри оптимізацію, бо проблема в архітектурі чи темі.

• Бізнес переріс сайт. Нові послуги, ринки, мови чи функції магазину не вкладаються в наявну структуру.

• Дизайн виглядає застарілим. Відвідувачі швидко оцінюють довіру, і старий дизайн підриває її, навіть коли все працює.

• Вартість підтримки постійно росте. Коли ви щороку платите більше, щоб утримати старий сайт, перебудова за кілька років часто обходиться дешевше.

Якщо збігається кілька пунктів, варто планувати редизайн, а не додавати нові латки. Як підготуватися до нього без втрати трафіку, ми пояснили в статті як зробити редизайн сайту.