Сайт запущен — кто отвечает за него завтра? Чек-лист поддержки для владельца

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

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

Доступы должны принадлежать компании

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

Составьте перечень зависимостей: CMS, плагины, почта, формы, CRM, оплата, аналитика. Для каждого важного сервиса укажите ответственного и порядок продления. Не храните пароли в общедоступной таблице вместе с этим перечнем.

Резервная копия полезна, если из неё можно восстановиться

В документации WordPress отдельно рассматриваются файлы сайта и база данных: для полноценной резервной копии нужны обе части. Одного архива картинок или одной выгрузки базы может оказаться недостаточно.

Источник: WordPress: резервное копирование файлов и базы.

Согласуйте частоту копирования, срок хранения и независимое место хранения. Периодически проверяйте восстановление в тестовой среде. Важно понимать, какие изменения могут быть потеряны между копиями и сколько займёт возврат к работе.

Проверяйте действия, а не только доступность

• Открываются ли ключевые страницы и актуальные языковые версии?
• Принимается ли заявка и попадает ли она ответственному?
• Работают ли поиск, корзина, кабинет и нужные интеграции?
• Правильно ли отображается сайт на телефонах?
• Нет ли ошибок сертификата, загрузки ресурсов и перенаправлений?
• Есть ли ответственный за предупреждения мониторинга?

Обновление — это изменение, которое нужно проверить

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

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

Скорость оценивайте на реальных посетителях

Core Web Vitals включают LCP, INP и CLS — показатели загрузки, отзывчивости и стабильности интерфейса. В web.dev отдельно описано измерение на реальных пользователях. Лабораторный балл полезен для диагностики, но не заменяет наблюдение за сайтом в обычных условиях.

Источник: web.dev: Core Web Vitals.

Что закрепить в договорённостях

Разделите критический сбой, обычную ошибку и новую функцию. Укажите время реакции, часы поддержки, порядок связи и условия дополнительной работы. Время реакции не равнозначно сроку полного исправления — это лучше проговорить заранее.

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