Стоимость поддержки сайта 2026: состав работ и бюджет

Короткий ответ: какой бюджет закладывать компании

Ориентиры сильно расходятся по регионам и уровням обслуживания. Ниже - примеры из открытых источников, собранные в сентябре 2026 года. Это не среднерыночные значения, а диапазоны конкретных поставщиков: они показывают порядок цифр и помогают понять разброс.

Таблица 1. Ориентиры стоимости поддержки сайта по регионам (сентябрь 2026)

Примеры провайдеров: Pixel Plus (Россия) указывает базовый пакет поддержки от 29 000 руб./мес. и постоплату 3 800 руб./час (данные на сентябрь 2026). Rheinspace (Германия) публикует пакеты 119, 229 и 399 EUR/мес., верхний уровень включает SLA и выделенного специалиста. OuterBox (США) называет диапазон 100-2 500 USD/мес. и ставку разработки 200 USD/час. Все три - примеры тарифов конкретных компаний, а не рыночные нормы.

Цены в разных регионах не конвертируются напрямую: состав пакетов, уровень команды, scope и SLA различаются. Для точной оценки нужно сравнивать не цифры, а то, что входит в каждый пакет.

Что именно компания покупает: Wartung, support, development или marketing

Одна из главных причин, по которой цены на «поддержку сайта» расходятся в разы, - поставщики используют одно слово для четырёх принципиально разных категорий работ. Пакет за 30 000 рублей и пакет за 100 000 рублей могут называться одинаково, но покрывать совершенно разный объём. То же касается услуг интернет-маркетинга: это отдельная статья бюджета со своими показателями.

Таблица 2. Четыре категории работ под брендом «поддержка сайта»

Смешивание этих категорий в одном пакете затрудняет сравнение: когда в одно предложение включены мониторинг, обновления, SEO и ведение рекламы, невозможно понять, сколько стоит каждая часть и что произойдёт, если вы захотите сменить подрядчика по одному направлению. Задавайте вопрос напрямую: «Что из этого списка входит в пакет, а что оплачивается дополнительно?» Маркетинговые работы, например сео продвижение сайтов, лучше выносить в отдельный договор с собственными KPI.

Что входит в профессиональную техническую поддержку сайта

Профессиональная техническая поддержка - это не просто «мониторинг и обновления». Это управление работающей бизнес-системой с предсказуемым результатом. Вот что должно быть включено в любой серьёзный пакет.

Мониторинг сайта, форм, checkout и ключевых интеграций

Проверка HTTP-кода ответа и SSL-сертификата - это минимально необходимый, но недостаточный мониторинг для B2B-сайта. Сайт может возвращать 200 OK, пока форма захвата лидов молча отправляет данные в никуда.

Для бизнес-критичных сайтов мониторинг должен охватывать:

• Все лид-формы и их интеграцию с CRM
• Checkout и платёжный процессор
• Синхронизацию каталога с ERP или PIM
• Передачу данных в аналитику и call tracking
• Ключевые пользовательские сценарии (через синтетический мониторинг)
• SSL и домен - с достаточным запасом до истечения срока

Хорошая команда поддержки настраивает мониторинг бизнес-функций, а не только инфраструктурный аптайм. Это различие особенно важно при работе с магазинами, лидогенерирующими сайтами и порталами.

Обновления CMS, модулей и зависимостей через staging

Устаревшие компоненты - один из наиболее распространённых векторов атак. OWASP Top 10:2025 выделяет уязвимые и устаревшие компоненты как отдельную категорию рисков, а безопасная конфигурация и контроль зависимостей входят в базовые требования к эксплуатации веб-приложений.

WordPress Advanced Administration Handbook: Security подробно описывает обновления, hardening и monitoring как части стандартной эксплуатации WordPress - не опциональные, а обязательные процессы.

Обновления без staging-среды создают прямой риск: плагин или CMS-ядро может конфликтовать с кастомным кодом или другим модулем. Профессиональный процесс выглядит так:

1. Обновление разворачивается на staging
2. Проводится QA - ключевые сценарии, формы, интеграции
3. После подтверждения - перенос на production
4. Мониторинг первые 24-48 часов

Пакеты без staging экономят деньги подрядчика, но перекладывают риск инцидента на клиента.

Резервное копирование, проверка восстановления и rollback

WordPress Advanced Administration Handbook: Backups прямо указывает: для полного восстановления сайта необходимо резервировать как файлы, так и базу данных. Только один из двух компонентов не позволит восстановить работоспособную систему.

Ещё важнее - периодически проверять, что автоматизированный backup-процесс действительно работает. Резервная копия, которую никто не проверял, может оказаться повреждённой или неполной именно в момент инцидента.

Хорошая стратегия резервирования включает:

• Ежедневные инкрементные копии и еженедельные полные
• Хранение в минимум двух физически разных местах
• Регулярные restore tests с фиксацией результата
• Возможность rollback к предыдущей версии после неудачного обновления
• Документированное RTO - плановое время восстановления

Безопасность, устранение ошибок и контроль производительности

OWASP Vulnerability Management Guide рассматривает управление уязвимостями как непрерывный организационный процесс, а не разовое сканирование. Одного автоматического инструмента недостаточно: требуются оценка рисков, расстановка приоритетов, исправление и контроль.

Безопасность в рамках поддержки включает:

• Регулярное сканирование уязвимостей с оценкой критичности
• Контроль доступов и привилегий
• Мониторинг подозрительной активности
• Проверку целостности файлов ядра
• Отслеживание и устранение ошибок из логов

Производительность - отдельная область контроля. Core Web Vitals, время загрузки страниц, ошибки 404, битые ссылки и деградация скорости влияют на конверсию и индексацию. Поддержка должна включать периодический мониторинг этих показателей и фиксацию отклонений.

Документация, отчётность и небольшой объём доработок

Прозрачность - не опция для профессиональной поддержки, а базовое требование. Клиент должен знать, что было сделано, сколько часов использовано и что планируется в следующем месяце.

Кроме отчётности, большинство managed-пакетов включают небольшой объём доработок в рамках часов контракта: правки текстов, обновление баннеров, небольшие изменения в формах или контенте. Важно зафиксировать в договоре, что именно считается «небольшой доработкой», а что требует отдельного согласования.

Что обычно оплачивается отдельно

Прежде чем сравнивать предложения, уточните, что в них не входит. Типичные позиции, которые оплачиваются поверх пакета:

SEO, реклама, редизайн. Поисковая оптимизация, запуск и ведение рекламных кампаний, разработка нового дизайна - это самостоятельные направления с отдельными специалистами и бюджетом. Если они появляются в «пакете поддержки» без разграничения, это повод уточнить состав.

Крупные разработки и новый функционал. Добавление нового раздела сайта, интеграция с новой CRM, разработка личного кабинета - всё, что выходит за рамки текущего scope, оплачивается отдельно: по часам или как отдельный проект.

Первичный аудит при смене подрядчика. Новая команда не может взять сайт на поддержку без изучения его состояния. Аудит включает инвентаризацию CMS и модулей, проверку кодовой базы, интеграций и доступов. Это разовая работа, которая оплачивается до начала ежемесячного обслуживания.

Onboarding: staging, monitoring, устранение критического технического долга. Настройка staging-среды с нуля, подключение системы мониторинга, исправление критических уязвимостей, найденных при аудите, - эти задачи часто выполняются единожды и не входят в ежемесячный пакет.

Перевод и локализация контента. Для мультиязычных сайтов переводы и адаптация контента - отдельная статья бюджета.

Из чего складывается стоимость поддержки

Цена поддержки не вычисляется по типу сайта. Два «корпоративных сайта» могут стоить в обслуживании в 5 раз по-разному, если у одного три формы и статичный каталог, а у другого - интеграция с SAP, ERP-синхронизация и нужна реакция в ночь под воскресенье.

Таблица 3. Факторы стоимости поддержки сайта

CMS, технологический стек и технический долг

WordPress с популярными плагинами дешевле в обслуживании, чем кастомная система на нишевом фреймворке, - просто потому что для первой проще найти специалиста и автоматизировать часть проверок. Кастомный PHP-монолит десятилетней давности или проект на устаревшей версии CMS с большим объёмом кастомного кода увеличивают трудозатраты и риски.

Технический долг напрямую влияет на стоимость: сайт с устаревшими зависимостями требует больше времени на тестирование каждого обновления, а при инциденте диагностика занимает дольше. Хороший подрядчик фиксирует это в отчёте и предлагает план поэтапного устранения.

Количество сайтов, брендов и языковых версий

Каждый домен, каждая CMS-инсталляция и каждая языковая версия - это отдельная область обслуживания. Компания с тремя сайтами на разных платформах не может рассчитывать на цену «одного сайта», умноженную на коэффициент 1.2.

Мультиязычность добавляет сложности не только контентную, но и техническую: hreflang-теги, проверка форм в каждой локали, мониторинг каждой языковой версии отдельно.

CRM, ERP, PIM, платёжные и другие интеграции

Интеграции - главный фактор, который недооценивают при расчёте бюджета поддержки. Каждое внешнее подключение - это дополнительная точка отказа и дополнительная область мониторинга. Если CRM обновилась и изменила API, заявки с сайта могут перестать поступать в воронку, а это не сразу заметно.

Для корректной оценки подрядчику нужно знать: какие системы подключены, насколько критична каждая интеграция, кто отвечает за обновление API на стороне внешней системы.

Бизнес-критичность, трафик и частота изменений

Сайт, через который приходит 80% лидов компании, требует другого уровня готовности, чем информационный ресурс с несколькими страницами. Бизнес-критичность влияет на целевой аптайм, требуемое время реакции и необходимость дежурства вне рабочих часов. Это касается и небольших локальных компаний: если разработка сайта для салона красоты делалась ради онлайн-записи, такой сайт по критичности ближе к первому случаю, чем кажется по числу страниц.

Высокий трафик увеличивает нагрузку на мониторинг и серьёзность последствий инцидентов. Частые правки и обновления контента требуют больше QA-циклов и выше риск регрессии.

Service window, SLA и необходимое время реакции

Поддержка в рабочие часы (например, 9:00-18:00 по местному времени) значительно дешевле поддержки 24/7. Если ваш сайт обслуживает клиентов в разных часовых поясах или критичен в выходные дни, это нужно фиксировать в техническом задании с самого начала. То же относится к бизнесу с пиком заявок в выходные: например, разработка сайта по ремонту техники обычно сразу предполагает мониторинг форм и в субботу, и в воскресенье.

Целевое время первого отклика и целевое время восстановления - разные параметры (об этом подробнее в разделе про SLA). Оба влияют на цену: команда, которая обещает реакцию за 15 минут в любое время суток, резервирует под это ресурс, и эта готовность стоит денег.

Модели оплаты: по факту, пакет часов, retainer или выделенная команда

Модель оплаты определяет не только то, как вы платите, но и то, как ведёт себя подрядчик: насколько он мотивирован проявлять инициативу, держать ли команду в резерве и какова предсказуемость бюджета с вашей стороны.

Таблица 4. Модели оплаты за поддержку сайта

Большинство B2B-компаний с постоянным сайтом выбирают retainer или пакет часов. Retainer даёт предсказуемость и зарезервированную команду; пакет часов - гибкость при нерегулярных задачах. Выделенная команда обоснована при высокой критичности, сложных интеграциях и постоянном потоке изменений.

Как меняется бюджет по типу веб-проекта

Тип проекта - один из двух факторов расчёта бюджета. Второй - требуемый уровень обслуживания. Ниже - ориентиры, которые помогут понять порядок цифр. Конкретная цена определяется после аудита.

Корпоративный сайт и B2B lead-generation website

Корпоративный сайт с функцией лидогенерации - наиболее распространённый случай. Основная ценность такого сайта - непрерывный поток заявок, поэтому мониторинг форм, CRM-интеграции и аналитики критичен. Часть заявок сегодня приходит через AI-поиск, поэтому некоторые компании закладывают в бюджет продвижение в AI наряду с классическим SEO.

При умеренном трафике, 1-3 интеграциях и регулярном, но не ежедневном потоке правок - базовый managed support покрывает большинство потребностей. Бюджет на уровне managed-пакетов из Таблицы 1 плюс резерв на экстренные доработки. Если в планах редизайн, заранее договоритесь, кто поддерживает сайт, пока идёт работа над новым дизайном сайта.

Многоязычный продуктовый каталог

Многоязычный каталог добавляет к стандартному обслуживанию несколько измерений: мониторинг каждой языковой версии, проверку hreflang и языковых переключателей, QA обновлений в каждой локали. Если каталог синхронизируется с PIM - это ещё одна точка мониторинга.

Ориентировочная надбавка к базовой стоимости - 20-40% за каждую дополнительную языковую версию (зависит от степени изоляции контента и CMS-архитектуры).

Интернет-магазин

E-commerce требует наиболее тщательного мониторинга: checkout, платёжный процессор, уведомления о заказах, остатки, интеграция с ERP или складом. Любой сбой в этой цепочке - прямые потери выручки.

Дополнительные требования: регулярное нагрузочное тестирование перед пиковыми периодами (акции, сезонность), более строгое SLA, мониторинг производительности как бизнес-метрики. Бюджет на поддержку e-commerce обычно выше, чем для информационного сайта аналогичного масштаба.

Клиентский или партнёрский портал

Порталы - наиболее сложный класс с точки зрения поддержки. Авторизация, ролевая модель, интеграции с backend-системами, персонализированный контент, часто - нестандартный стек. Здесь важны не только аптайм, но и корректность бизнес-логики: неверный расчёт скидки или неправильные права доступа - это инциденты уровня S1.

Для порталов часто обоснована модель выделенной команды или расширенный retainer с явно зафиксированным scope и severity-матрицей.

Кастомная веб-платформа

Кастомные платформы - наибольший разброс в стоимости. Здесь поддержка может быть дешевле, если код хорошо структурирован и документирован, или значительно дороже, если это «исторический монолит» без тестов и документации.

Ключевой вопрос при принятии такой платформы на поддержку - стоимость onboarding-аудита и объём технического долга, который нужно устранить до начала стабильного обслуживания.

Почему самый дешёвый пакет может оказаться дороже

Базовый пакет за минимальную стоимость - разумный выбор для некритичного информационного сайта. Но для B2B-сайта, который генерирует лиды или выручку, экономия на поддержке создаёт риски, которые легко перекрывают разницу в цене.

Типичные сценарии скрытых затрат:

Нет staging - каждое обновление идёт напрямую в production. Конфликт плагина роняет форму захвата лидов. За 2 дня до следующего рабочего дня инженера теряются заявки, которые не восстановить.

Нет ручного QA - автоматика не проверяет бизнес-сценарии. Сайт «доступен» по HTTP-мониторингу, но форма отправляет данные в никуда из-за изменения API CRM.

Нет документированного SLA - время реакции нигде не зафиксировано. При инциденте у подрядчика нет формальных обязательств. Реакция - «в ближайшее время».

Экстренные работы оплачиваются по повышенному тарифу. Некоторые пакеты покрывают только плановые задачи. Любой инцидент - по ставке «срочно», которая может быть в 1.5-2 раза выше обычной.

Onboarding не был учтён. Принятие сайта на поддержку требовало аудита и устранения критического долга. Всё это выставили отдельно, и итоговый бюджет первого полугодия оказался выше managed-пакета.

Прежде чем выбирать по цене, ответьте на вопрос: какова цена 3 дней простоя вашего сайта или потери 100 лидов?

SLA без маркетинговых обещаний: что в нём проверять

SLA - это не набор красивых цифр в коммерческом предложении. Это документированные измеримые обязательства, которые можно проверить по отчёту. Google Site Reliability Workbook: Implementing SLOs описывает принцип: хороший SLA строится на SLO (Service Level Objectives) - конкретных измеримых целях, которые определяют, что значит «нормальная работа системы».

Severity levels и часы покрытия

Профессиональный SLA разделяет инциденты по severity - уровню критичности. Типичная модель:

• S1 (критический): сайт полностью недоступен или нарушена бизнес-критичная функция (checkout, основная форма)
• S2 (высокий): значительное ухудшение работы, часть функций недоступна
• S3 (средний): некритичная ошибка, есть workaround
• S4 (низкий): косметическая проблема, задача планируется

Для каждого уровня фиксируется: часы покрытия (рабочие часы, расширенные или 24/7) и соответствующие targets. Уточняйте заранее: покрывает ли пакет инциденты S1 в нерабочее время и выходные дни.

Response time, workaround time и resolution target

Это три разных понятия, которые часто путают в коммерческих предложениях:

Response time - время от подачи заявки до первого осмысленного ответа подрядчика (не автоответ). Это подтверждение получения и первичная диагностика.

Workaround time - время до предоставления временного решения, которое восстанавливает бизнес-функцию даже если корневая причина ещё не устранена.

Resolution target - время до полного устранения проблемы, включая корневую причину.

Обещание «реакция за 20 минут» означает только response time. Спрашивайте отдельно про workaround и resolution. DORA-метрики дополняют эту картину: DORA: A History of Software Delivery Metrics фиксирует время восстановления после инцидента (failed deployment recovery time) как один из ключевых показателей зрелости команды.

Эскалация, коммуникация и ответственность сторон

SLA должен описывать не только цифры, но и процесс:

• Кто контактное лицо на стороне подрядчика и что происходит при его отсутствии
• Через какой канал подаётся заявка и как фиксируется время
• Как выглядит эскалация при превышении SLA
• Что попадает в зону ответственности подрядчика, а что - в зону клиента (например, доступы к внешним API)

Зона ответственности - критически важный пункт. Если причина инцидента в стороннем сервисе (платёжная система, CDN, API партнёра), targets могут не применяться. Это должно быть явно зафиксировано.

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

Получив несколько коммерческих предложений, сравнивайте не итоговые суммы, а состав. Две одинаковые цифры могут скрывать принципиально разный scope и уровень гарантий.

Таблица 5. Чек-лист сравнения предложений подрядчиков

Рекомендуется запросить у подрядчика шаблон ежемесячного отчёта. Если такого шаблона нет - это сигнал о зрелости процессов.

Что должно быть в ежемесячном отчёте

Ежемесячный отчёт - основной инструмент прозрачности между клиентом и подрядчиком. Он должен давать ответ на три вопроса: что произошло, что было сделано и что планируется.

Таблица 6. Структура ежемесячного отчёта по поддержке сайта

Отчёт не должен быть длинным - важна конкретность. Дата инцидента, время реакции, время восстановления, root cause - это полезная информация. «В этом месяце всё было в порядке» - нет.

Как рассчитать годовой бюджет и TCO сайта

Стоимость владения сайтом (TCO - Total Cost of Ownership) всегда выше стоимости ежемесячного пакета поддержки. Планирование только абонентской платы оставляет за кадром несколько существенных статей расходов.

Формула TCO и пример расчёта для B2B-компании

Годовой TCO сайта складывается из:

Годовой TCO = хостинг и инфраструктура
            + лицензии (CMS, плагины, сторонние сервисы)
            + ежемесячная поддержка × 12
            + плановые доработки (backlog)
            + первоначальный аудит / onboarding (если есть)
            + резерв на крупные инциденты и технический долг

Пример для B2B lead-generation сайта (упрощённый):

• Хостинг и инфраструктура: 18 000 руб./год
• Лицензии плагинов: 24 000 руб./год
• Managed support retainer: 45 000 руб./мес. × 12 = 540 000 руб./год
• Плановые доработки (backlog): 120 000 руб./год
• Резерв (10% от обслуживания + доработок): 66 000 руб./год
• Итого TCO: ~768 000 руб./год

Стоимость простоя или потери лидов в этом примере не учитывается как фиксированная цифра - она зависит от конкретного бизнеса и должна оцениваться отдельно при расчёте обоснования бюджета.

Первоначальный аудит и стоимость принятия чужого сайта

Если сайт создавался другим подрядчиком или не обслуживался профессионально, первый шаг - технический аудит. Он позволяет оценить состояние кодовой базы, актуальность версий, наличие уязвимостей и объём технического долга.

Типичный onboarding включает:

• Инвентаризацию CMS, плагинов, зависимостей и их версий
• Проверку доступов (хостинг, домен, аналитика, CRM)
• Аудит интеграций и их документации
• Оценку технического долга
• Создание staging-среды с нуля
• Настройку мониторинга и системы бэкапов

Стоимость onboarding оценивается отдельно и зависит от состояния сайта. Это разовая инвестиция, которая впоследствии снижает риски и стоимость ежемесячного обслуживания.

Резерв на крупные доработки и устранение технического долга

Технический долг не устраняется автоматически. Каждый месяц без планового обновления архаичных компонентов - это накопленный риск, который при реализации потребует непропорционально больших вложений.

Разумный подход - выделить 10-15% от годового бюджета на поддержку в качестве резерва. Часть резерва расходуется на технический долг по плану (постепенное обновление устаревшего кода, миграции), часть - на непредвиденные инциденты.

Когда достаточно базового обслуживания, а когда нужна команда развития

Уровень поддержки должен соответствовать бизнес-роли сайта. Переплачивать за enterprise-уровень для статичного сайта-визитки нецелесообразно; экономить на managed support для revenue-critical системы - рискованно. В этом случае бюджет смещается от обслуживания к постоянной разработке сайтов, и договор должен это отражать.

Базовое обслуживание достаточно, если:

• Сайт информационный, не генерирует заявки и выручку напрямую
• Трафик небольшой, интеграций нет или они некритичны
• Обновления контента редкие (раз в несколько недель)
• Простой на 1-2 дня не имеет значимых бизнес-последствий

Managed support нужен, если:

• Сайт генерирует лиды или является точкой продаж
• Есть интеграции с CRM, ERP или платёжными системами
• Обновления и правки происходят регулярно (еженедельно и чаще)
• Требуется документированное время реакции на инциденты

Команда развития нужна, если:

• Сайт активно развивается: новые функции, A/B-тесты, интеграции
• Высокая критичность и постоянный поток изменений
• Сложная архитектура (портал, кастомная платформа, e-commerce с большим каталогом)
• Скорость внедрения изменений является конкурентным преимуществом

Как Webdelo организует поддержку B2B-сайтов

Webdelo - международная B2B IT-компания, основанная в 2006 году, с присутствием в США, Германии и СНГ. За 15+ лет и 200+ проектов компания сформировала подход к поддержке, при котором сайт рассматривается как работающая бизнес-система, а не просто набор файлов на сервере.

Для B2B-клиентов Webdelo предлагает:

Аудит перед началом обслуживания. Перед подписанием retainer-договора проводится технический аудит: состояние кодовой базы, версии компонентов, доступы, интеграции, наличие и качество документации. Аудит даёт честную картину и позволяет согласовать scope без скрытых рисков.

Прозрачный SLA с severity-матрицей. Команда работает по модели S1-S4. Типовое целевое время первого ответа по критичным инцидентам в рабочие часы - около 20 минут. Целевое время восстановления для S1 - до 4 часов, если причина в зоне ответственности команды. Итоговые targets фиксируются в SOW индивидуально для каждого клиента.

Staging и QA как стандарт. Обновления тестируются на staging до переноса в production. Ключевые бизнес-сценарии проверяются вручную после каждого значимого изменения.

Ежемесячная отчётность. Клиент получает отчёт по структуре, близкой к Таблице 6: аптайм, инциденты, обновления, безопасность, использование часов и roadmap.

Поддержка и развитие как единый процесс. Webdelo не разделяет «поддержку» и «разработку» искусственно: в рамках retainer-договора команда может как обслуживать сайт, так и реализовывать плановые улучшения из согласованного backlog.

Для компаний, которые рассматривают смену подрядчика или впервые планируют системную поддержку, Webdelo предлагает бесплатный аудит текущего сайта и расчёт плана поддержки с прозрачным SLA. Это позволяет получить честную оценку до принятия решения.

FAQ

Сколько в среднем стоит поддержка сайта в месяц?

Диапазон слишком широк, чтобы называть «среднее» значение. По открытым данным отдельных провайдеров (сентябрь 2026): в России managed-пакеты начинаются от 30 000-80 000 руб./мес., в Германии - от 300-800 EUR/мес., в США - от 500-2 000 USD/мес. Базовые пакеты дешевле, но с существенными ограничениями по scope и SLA. Точная цена определяется после аудита конкретного сайта.

Что входит в абонентское обслуживание сайта?

Стандартный managed-пакет включает: обновления CMS и модулей через staging, резервное копирование с restore tests, мониторинг аптайма и бизнес-функций, исправление ошибок, базовую безопасность и ежемесячный отчёт. Развитие функционала, SEO, реклама и контент-маркетинг - отдельные услуги.

Чем отличается поддержка от технической поддержки и сопровождения?

На рынке эти термины используются непоследовательно. Обслуживание (Wartung) обычно означает технические задачи: обновления, бэкапы, мониторинг. Сопровождение (Betreuung) - более широкий уровень, который включает коммуникацию, изменения и развитие. Правильный вопрос - не как называется услуга, а что в неё входит.

Зачем нужен staging, если обновления и так обычно проходят нормально?

Обновления проходят нормально до тех пор, пока не перестают. Конфликт плагина, обновление ядра, изменение PHP-версии - всё это может сломать форму или раздел сайта. Staging позволяет выявить проблему до того, как её увидят посетители. Для B2B-сайта, который генерирует заявки, час простоя формы может стоить больше, чем стоимость staging-среды за год.

Что значит SLA, и как понять, хороший ли он в предложении подрядчика?

SLA (Service Level Agreement) - это документированные обязательства по уровню сервиса: время реакции, время восстановления, аптайм. Хороший SLA содержит severity-матрицу, разные targets для рабочих и нерабочих часов, описание процесса эскалации и чёткие исключения. Если в предложении написано «быстро реагируем» без цифр - это не SLA.

Как понять, что нам нужна поддержка с развитием, а не просто обслуживание?

Если ваш сайт регулярно дополняется новыми функциями, разделами или интеграциями, если у вас есть постоянный backlog улучшений и вы хотите, чтобы команда знала продукт изнутри - вам нужна модель с включённым развитием. Если сайт стабильный и правки редкие - managed support, скорее всего, достаточен.

Нужен ли аудит при смене подрядчика?

Да, и это в ваших интересах. Без аудита новая команда принимает на себя неизвестные риски, что обычно отражается на цене или на качестве обслуживания. Аудит даёт исходное состояние: версии компонентов, уязвимости, доступы, документация, технический долг. На основе аудита формируется корректный scope и реалистичные SLA.