⚡ Стисла відповідь: Базова підтримка сайту коштує від 100$/місяць, повноцінний пакет із контентом і доробками — від 250$/місяць. Це не забаганка агентств: 91% вразливостей WordPress живуть саме в плагінах, а зловмисники починають масову експлуатацію нової вразливості вже за 5 годин після публікації. Сайт без регулярної підтримки — це не “заощадження”, а відкладений ризик, який рано чи пізно виставить рахунок дорожчий за саму підтримку.
Ми вже писали, що преміум-пакет розробки корпоративного сайту включає 3 місяці технічного супроводу — і саме після завершення цього гарантійного періоду власники найчастіше вперше стикаються з питанням “а скільки це реально коштує далі”. Відповідь залежить не тільки від розміру сайту, а й від того, що конкретно ви очікуєте отримати за ці гроші.
| Пакет | Ціна | Що входить |
|---|---|---|
| Базовий | від 100$/міс | Оновлення CMS, плагінів і теми, резервне копіювання, моніторинг безпеки й доступності |
| Розширений | від 175$/міс | Усе з базового + контентні правки, невеликі структурні зміни, пріоритетна реакція |
| Преміум | від 250$/міс | Усе з розширеного + оновлення текстового й візуального контенту, доробки функціоналу, розширений супровід |
Різниця між пакетами — не в кількості “робіт на місяць”, а в тому, чи підтримка суто технічна, чи включає ще й розвиток сайту. Базовий пакет тримає сайт живим і безпечним. Розширений і преміум додають до цього реальний ріст — новий контент, невеликі доробки, які без окремого пакета довелось би замовляти й оплачувати кожного разу окремо.
Річна вартість базового пакета — трохи більше тисячі доларів. Це звучить як помітна стаття витрат, поки не порахувати вартість одного серйозного інциденту без підтримки: саме лише професійне очищення після зараження стартує від 300$, а глибокі випадки доходять до 3000$ і вище.
За аналізом ринкових пропозицій, повноцінна підтримка складається з п’яти базових груп задач: оновлення ядра CMS, плагінів і теми; резервне копіювання з перевіркою відновлення (backup, який жодного разу не перевіряли на відновлення, — це backup, у якому ви не впевнені); моніторинг вразливостей і реакція на них; контроль часу безвідмовної роботи (uptime) і швидкості; технічна гігієна — биті посилання, чистка бази даних, стеження за терміном дії SSL і домену.
Останній пункт здається дрібницею, поки термін дії сертифіката чи домену не спливає непомітно посеред робочого тижня, і сайт на кілька годин просто перестає відкриватись у браузері з попередженням про небезпеку.
Цифри тут промовисті. За звітом Patchstack, у 2025 році зафіксовано 11334 нові вразливості WordPress — на 42% більше, ніж роком раніше, і 91% з них — саме в плагінах, а не в ядрі системи. Кожен неактивний, застарілий плагін, який просто лежить на сервері “про всяк випадок”, — це відкрита лазівка, навіть якщо ви ним не користуєтесь.
Швидкість, з якою цим користуються зловмисники, теж вражає: медіанний час від публікації вразливості до початку масової експлуатації — 5 годин. 70% активно експлуатується вже на сьомий день. Сайт, який оновлюють раз на квартал “коли є час”, живе з відкритими дверима значно довше, ніж власники зазвичай усвідомлюють.
Вартість прибирання наслідків зазвичай перевищує вартість самої підтримки в рази. Професійне очищення від шкідливого коду коштує 300-800$, а глибокі зараження — 1500-3000$ і більше. З актуальними резервними копіями відновлення займає 2-4 години. Без них — 1-2 дні простою, і саме простій, а не сама чистка, найдорожче обходиться бізнесу, який залежить від сайту як каналу продажів.
Наші цифри вище — нижче середніх по ринку, і це варто пояснити чесно, а не подавати як “магію”. За відкритими прайсами українських студій, базовий пакет підтримки часто починається від 250$/місяць, комплексний — від 500$, а річне обслуговування “оптом” виходить близько 4500$/рік. Різниця не в якості робіт, а в наповненні: дорожчі пакети зазвичай включають фіксовану кількість годин розробки щомісяця (умовні 20 годин), навіть якщо ви їх не витратили.
Ми рахуємо інакше. Базовий пакет покриває саме технічну безпеку й стабільність — оновлення, бекапи, моніторинг, — а години розробки під конкретні доробки або входять у старші пакети, або оплачуються окремо, коли реально потрібні. Для більшості корпоративних сайтів і невеликих магазинів це виходить дешевше, ніж авансом платити за “пакет годин”, який щомісяця згорає невикористаним.
Погодинні ставки різняться залежно від платформи: WordPress — від 15$/год, Laravel — 20-30$/год, Bitrix — від 40$/год за окремі задачі. Ця різниця пояснюється не “жадібністю” підрядника, а тим, наскільки складно й довго шукати фахівця під конкретний технологічний стек — WordPress-розробників на ринку значно більше, ніж вузьких Bitrix-спеціалістів.
Фрілансер на підтримці на папері виглядає дешевше за студію — і часто справді дешевший на щомісячному рахунку. Ризик тут той самий, що й із будь-якою одноосібною підтримкою: якщо людина захворіла, поїхала у відпустку чи просто зникла на два тижні саме тоді, коли сайт ліг, підстрахувати нікому. Студія за визначенням має більше однієї людини, яка знає ваш проєкт, навіть якщо це коштує на 20-30% дорожче за годину фрілансера.
Ми вже розбирали, скільки коштує розробка інтернет-магазину — і саме там варто було б одразу закласти, що підтримка такого сайту коштує помітно дорожче за підтримку звичайного корпоративного сайту, навіть при схожому розмірі. Причина проста: у корпоративного сайту збій на кілька годин — це незручність. У магазину той самий збій — це прямі втрачені замовлення, і рахунок іде не на “трохи неприємно”, а на конкретну суму щогодини простою.
Магазин на WooCommerce чи будь-якій іншій платформі додає до звичайного списку задач ще й моніторинг платіжних інтеграцій (чи справді проходять оплати, чи не “відвалився” тихо один із методів після оновлення), синхронізацію залишків товару з обліковою системою, і перевірку коректності розрахунку доставки після кожного великого оновлення плагінів. Жодна з цих речей не входить у “базовий” пакет підтримки за замовчуванням — і саме тому магазину майже завжди варто одразу брати розширений чи преміум рівень, а не економити на базовому.
Частково — так. Базові оновлення плагінів через адмінку, перевірка, що резервні копії реально створюються (а не тільки налаштовані й забуті), моніторинг терміну дії SSL — усе це технічно доступно власнику без спеціальних навичок, якщо є 2-3 години на місяць і бажання розбиратись.
Складніше — саме реакція на проблему, а не її профілактика. Коли плагін конфліктує з оновленням теми й ламає верстку на мобільних, чи коли сканер безпеки знаходить підозрілий код у файлах, самостійне “розбирання” без досвіду часто закінчується або втратою часу на форумах у пошуках рішення, або, гірше, помилковим виправленням, яке ламає щось інше. Ми в Netloria регулярно бачимо саме такі “самостійно виправлені” сайти на технічному аудиті — і виправляти доводиться вже не одну проблему, а дві.
Найчастіше бачимо один і той самий сценарій: сайт запускають, гарантійний період технічної підтримки минає, і бізнес просто нічого не робить далі — “поки все працює”. Сайт справді може пропрацювати без оновлень кілька місяців без видимих проблем. Проблема в тому, що “видимих” не означає “відсутніх” — вразливість може вже експлуатуватись тихо, без жодних симптомів, поки хтось не помітить дивний трафік у аналітиці чи попередження браузера про небезпечний сайт.
Друга поширена помилка — купити найдешевший пакет “автоматичних” оновлень без реальної людини, яка перевіряє результат. Автоматичне оновлення плагіна, яке зламало сайт посеред ночі, — це не рідкість, а один із найчастіших сценаріїв технічних аудитів, з якими ми стикаємось. Автоматизація корисна для рутини, але без людського контролю за критичними оновленнями вона іноді створює проблему замість того, щоб її запобігти.
У нашій практиці показовий випадок — клієнт, який рік вів магазин без жодного пакета підтримки, “бо все й так працювало”. Проблема виявилась не одразу: плагін для розрахунку доставки тихо перестав коректно рахувати вартість для одного з регіонів після чергового автоматичного оновлення WordPress, і кілька тижнів частина покупців бачила нульову вартість доставки замість реальної. Ніхто цього не помітив, поки бухгалтерія не звернула увагу на розбіжність у звітах — а до того часу сайт устиг “роздати” безкоштовну доставку на суму, що в кілька разів перевищувала річну вартість базового пакета підтримки, якого клієнт намагався уникнути.
| Тип проблеми | Реалістичний час реакції |
|---|---|
| Сайт повністю недоступний | 1-4 години |
| Критична функція не працює (оплата, форма заявки) | 4-12 годин |
| Візуальний баг, не критично для продажів | 1-3 робочі дні |
| Планове оновлення чи дрібна доробка | у межах наступного оновлення за розкладом |
Договір, у якому “час реакції” сформульований як одне загальне число для всіх типів проблем, — це майже завжди ознака, що реальний пріоритет розставляти доведеться вам самим, дзвінками й нагадуваннями, а не системою підрядника. Розділені рівні критичності — навпаки, ознака, що процес реально продуманий, а не написаний для галочки в комерційній пропозиції.
Перед тим як платити за підтримку, варто уточнити п’ять речей: як часто реально перевіряють резервні копії на можливість відновлення, а не тільки створюють їх; хто відповідає, якщо оновлення плагіна зламає сайт — підрядник чи знову ви; який час реакції на критичну проблему (кілька годин чи “протягом тижня”); чи входить моніторинг вразливостей у реальному часі, чи це просто щомісячне оновлення за розкладом; і що саме відбувається, якщо ви вирішите змінити підрядника — чи отримаєте повний доступ і документацію, чи доведеться починати з нуля.
Якщо жодна з цих відповідей не прозора одразу — це вже сигнал, вартий уваги ще до підписання договору.
Шостий пункт, який рідко озвучують самі підрядники, але варто спитати прямо: чи включено тестове відновлення з backup хоча б раз на квартал, а не тільки створення копій. Резервна копія, яку ніколи не пробували відновити, — це теоретична гарантія, а не практична: пошкоджений чи неповний файл бекапу виявляється саме в той момент, коли він реально терміново потрібен, а не заздалегідь, коли ще можна було б спокійно це виправити.
Найбільший ефект від регулярної підтримки помітний не в дорогих інцидентах, яких вдалось уникнути (їх, за визначенням, ніхто не бачить), а в накопиченій технічній чистоті сайту.
Сайт, який регулярно оновлюють і чистять, вантажиться швидше, менше “лагає” на мобільних і рідше видає дивні помилки при оформленні замовлення — а швидкість і стабільність напряму впливають на конверсію й ранжування в пошуку.
Ми вже писали про те, як швидкість і технічна чистота сайту впливають на позиції в Google, у матеріалі про фактори ранжування — регулярна підтримка це та сама технічна робота, тільки розтягнута на постійній основі, а не одноразовий спринт перед запуском.
Якщо ваш сайт уже пережив гарантійний період і залишився без чіткого плану подальшого супроводу — розкажіть нам, що зараз є на сайті, і ми підберемо рівень підтримки під реальний стан справ, а не продамо найдорожчий пакет “про всяк випадок”.
