Запуск сайта — не финальная точка
Когда новый сайт опубликован и начинает принимать посетителей, основная разработка действительно заканчивается. Но сам проект продолжает жить: обновляются WordPress и плагины, меняются браузеры, появляются новые требования бизнеса, заканчиваются сертификаты, меняются сотрудники и рекламные кампании.
Если после запуска сайт годами никто не проверяет, небольшие технические проблемы постепенно накапливаются. Одна форма перестаёт отправлять письмо, другой плагин конфликтует после обновления, старый PHP ограничивает работу новой версии системы, а резервная копия оказывается слишком старой именно тогда, когда она нужна.
Техническая поддержка нужна не для постоянного «ремонта» хорошего сайта. Её задача — сохранять работоспособность проекта и вносить изменения контролируемо.
1. Обновления WordPress, темы и плагинов
Обновления закрывают уязвимости, исправляют ошибки и поддерживают совместимость с современными версиями PHP и браузеров. Но нажимать «обновить всё» без подготовки тоже неправильно.
Перед значимыми обновлениями желательно иметь актуальную резервную копию и понимать, какие компоненты связаны между собой. После установки нужно проверить ключевые страницы, формы, меню и административную часть.
Особенно внимательно стоит относиться к сайтам с кастомной темой, интеграциями и большим количеством сторонних модулей. Чем сложнее проект, тем важнее контролируемый порядок обновлений.
2. Резервные копии и возможность восстановления
Резервная копия полезна только тогда, когда она актуальна и её действительно можно восстановить. Просто видеть архив на сервере недостаточно.
Для обычного корпоративного сайта важны копии файлов и базы данных. Частота зависит от того, как часто меняется информация. Если заявки хранятся в базе, публикуются материалы или работает интернет-магазин, интервалы должны быть короче, чем у статичного сайта-визитки.
Хорошая практика — хранить хотя бы часть копий отдельно от основного хостинга. Тогда сбой сервера не уничтожит одновременно и сайт, и его единственную резервную копию.
3. Контроль безопасности
Безопасность сайта — это не один установленный плагин. Она складывается из обновлений, прав доступа, защищённых паролей, корректной конфигурации сервера, HTTPS, резервных копий и минимального количества лишнего кода.
Во время поддержки полезно отслеживать необычные изменения, массовые ошибки авторизации, подозрительные файлы и устаревшие компоненты. Если сотрудник больше не работает с сайтом, его учётную запись лучше отключить, а не оставлять «на всякий случай».
Для небольшого проекта этого часто достаточно. Более крупным системам могут потребоваться отдельные меры мониторинга и инфраструктурной безопасности.
4. Проверка форм и каналов получения заявок
Форма может выглядеть исправной, но перестать отправлять уведомления после изменения SMTP, настроек домена, API мессенджера или серверной конфигурации. Внешне посетитель увидит сообщение «Спасибо», а бизнес не получит обращение.
Поэтому формы нужно периодически тестировать. Если сайт отправляет заявки одновременно на почту, в Telegram и CRM, имеет смысл проверить каждый канал отдельно.
Также важно следить, чтобы после изменений не пропадали обязательные согласия, UTM-метки и другие данные, которые используются в аналитике.
5. Исправление технических ошибок
Поддержка включает устранение проблем, которые появляются в процессе эксплуатации: неработающих ссылок, ошибок PHP или JavaScript, некорректного отображения блоков, конфликтов после обновлений, проблем с адаптивностью.
Не все ошибки критичны одинаково. Неработающая форма заявки требует немедленной реакции, а небольшой визуальный дефект на редкой странице можно исправить в плановом порядке.
Полезно разделять задачи по приоритету, чтобы срочные проблемы не терялись среди десятков косметических пожеланий.
6. Скорость и стабильность
Сайт со временем может стать медленнее, даже если при запуске работал быстро. Добавляются изображения, аналитические скрипты, новые шрифты, виджеты, плагины и страницы.
Поддержка помогает заметить деградацию раньше, чем она станет очевидной. Иногда достаточно оптимизировать изображения или удалить ненужный модуль, а иногда проблема находится в хостинге или базе данных.
Важно не превращать оптимизацию в погоню за лабораторным баллом. Цель — стабильная реальная загрузка и отсутствие технических препятствий для пользователя.
7. Небольшие изменения контента и интерфейса
После запуска почти всегда появляются практические корректировки: изменить телефон, добавить сотрудника, обновить цену, заменить изображение, скорректировать текст, добавить вопрос в FAQ или изменить кнопку.
Такие задачи логично включать в сопровождение, если они не требуют отдельного проектирования. Это позволяет не искать разработчика каждый раз, когда нужно исправить небольшую деталь.
При этом поддержка не должна превращаться в бесконечный редизайн внутри фиксированного тарифа. Новая крупная страница или переработка целого раздела — уже отдельная задача.
8. Создание новых страниц и развитие сайта
Поддержка может включать развитие проекта: создание новой страницы услуги на существующих компонентах, добавление кейса, публикацию статьи, подключение нового поля или небольшой интеграции.
Здесь важно отличать развитие от обслуживания. Обслуживание сохраняет существующую систему, а развитие расширяет её. В договорённостях лучше заранее определить, какой объём новых работ входит в ежемесячный пакет, а какой оценивается отдельно.
Если сайт был хорошо спроектирован, новые страницы можно собирать в рамках существующей дизайн-системы без постоянного изобретения новых шаблонов.
9. Аналитика и технический контроль после изменений
Даже небольшое изменение может повлиять на аналитику. Замена формы, кнопки или URL иногда ломает цель в Метрике. Новый способ отправки заявки может перестать передавать UTM-метки.
После заметных правок полезно проверить основные цели, формы и ключевые пользовательские сценарии. Это особенно важно для сайтов, на которые идёт платный трафик.
Поддержка не обязана включать полноценное ведение рекламы или сквозную аналитику, но техническая часть измерения должна оставаться рабочей.
10. Контроль домена, SSL и хостинга
Есть инфраструктурные вещи, о которых вспоминают редко: срок оплаты домена, сертификат SSL, место на диске, версия PHP, доступность базы данных, почтовая конфигурация.
Часть провайдеров продлевает сертификаты автоматически, но это не отменяет контроля. Сайт может внезапно перестать открываться не из-за кода, а из-за неоплаченного домена или переполненного диска.
В поддержке полезно заранее зафиксировать, кто отвечает за продление услуг и у кого находятся административные доступы.
Что обычно не относится к технической поддержке
Границы сопровождения лучше определить до начала работы. Обычно в обычную техническую поддержку не входят:
- полный редизайн сайта;
- разработка нового большого раздела с уникальной логикой;
- масштабный перенос на другую CMS;
- создание сложной CRM или личного кабинета;
- полноценное SEO-продвижение;
- ведение рекламных кампаний;
- круглосуточное дежурство, если оно отдельно не предусмотрено.
Эти задачи могут выполняться тем же подрядчиком, но требуют отдельной оценки. Чёткие границы защищают и заказчика, и исполнителя от ситуации, когда под словом «поддержка» понимается вообще любая работа с сайтом.
Разовая поддержка или ежемесячное сопровождение
Разовая модель подходит, если сайт простой, редко меняется и бизнес готов обращаться к специалисту только при необходимости. Минус в том, что проблема обычно обнаруживается уже после того, как она стала заметна.
Ежемесячное сопровождение полезнее для проектов, на которые идёт реклама, регулярно добавляется контент или от сайта напрямую зависят заявки. Подрядчик знает архитектуру и может быстрее разобраться в изменениях.
Оптимальный формат зависит не столько от размера сайта, сколько от его роли в бизнесе и частоты изменений.
Как понять, что текущая поддержка работает
Хорошая поддержка обычно незаметна. Сайт открывается, формы отправляются, резервные копии существуют, обновления не превращаются в аварии, а небольшие изменения выполняются предсказуемо.
Полезно, когда у владельца есть понятный канал для задач, доступы не теряются, а крупные изменения фиксируются. Для сложных проектов дополнительно помогает журнал версий или Git-репозиторий.
Если каждый запрос начинается с поиска паролей и объяснения разработчику, как устроен сайт, сопровождение фактически отсутствует.
Короткий вывод
Техническая поддержка после запуска — это не страховка от всех возможных проблем и не бесконечная разработка по подписке. Это системная работа, которая сохраняет сайт рабочим, безопасным и готовым к изменениям.
В базовый контур обычно входят обновления, резервные копии, контроль безопасности, проверка форм, исправление ошибок и небольшие изменения. Развитие, новые страницы и интеграции могут добавляться в зависимости от формата сотрудничества.
Для проектов earlcoda STUDIO сопровождение можно продолжить после разработки без передачи сайта новому подрядчику. Подробнее — на странице «Техническая поддержка сайтов». Если текущий сайт уже требует не обслуживания, а системной переработки, полезно сначала посмотреть разбор «Когда сайту нужен редизайн».