Техническая поддержка сайта: что входит и как её организовать

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

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

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

Техническая поддержка — это набор работ, которые сохраняют сайт в рабочем и безопасном состоянии. Её цель не в росте трафика или продаж, а в том, чтобы сайт открывался, формы отправлялись, заказы доходили, а данные не терялись.

В разговоре и договорах встречаются разные названия: техподдержка, техническое сопровождение, обслуживание сайта. Чаще всего под ними понимают одно и то же. Поэтому смотрите не на название услуги, а на список работ в договоре.

Кому она нужна в первую очередь

• Интернет-магазинам — каждый час простоя или сломанная корзина означает потерянные заказы.
• Сайтам на WordPress, 1С-Битрикс, OpenCart, MODX — движок и расширения требуют обновлений, а популярные CMS чаще становятся целью массовых атак.
• Сайтам с интеграциями — выгрузка из 1С, оплата, доставка, CRM. Любое изменение на стороне сервиса может сломать обмен.
• Компаниям, которые продвигают сайт — ошибки, простои и взлом бьют по позициям и рекламе.
• Тем, у кого нет своего разработчика — без подрядчика мелкая поломка превращается в аврал.

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

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

Состав работ зависит от CMS и типа сайта, но базовый набор у всех подрядчиков похож. Ниже — восемь направлений, из которых складывается нормальная техподдержка.

1. Обновления CMS, плагинов и модулей

Обновления закрывают уязвимости и сохраняют совместимость с новыми версиями PHP и браузеров. У WordPress младшие и защитные обновления ядра по умолчанию ставятся автоматически, а крупные релизы и плагины — вручную (документация WordPress). Та же документация советует перед обновлением сделать резервную копию.

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

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

2. Резервные копии

Копия — главная страховка от взлома, неудачного обновления и ошибки сотрудника. Для полного восстановления нужны и файлы, и база данных: одно без другого сайт не вернёт (документация WordPress о резервных копиях).

• Частота — по тому, как часто меняются данные. Магазину с заказами нужны ежедневные копии базы, сайту-визитке хватит еженедельных.
• Хранение — не только на том же сервере. Если сервер взломают или он выйдет из строя, копия рядом с сайтом пропадёт вместе с ним.
• Глубина — несколько точек восстановления. Взлом часто замечают через недели, и вчерашняя копия уже заражена.
• Проверка — периодически восстанавливайте копию на тестовом сервере. Непроверенная копия может оказаться битой.

3. Мониторинг доступности

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

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

4. SSL-сертификат и домен

Просроченный сертификат приводит к тому, что браузер показывает предупреждение вместо сайта. Бесплатные сертификаты Let’s Encrypt по умолчанию действуют 90 дней (FAQ Let’s Encrypt). Поэтому их продление должно быть автоматическим, а мониторинг — сообщать, если продление не сработало.

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

5. Безопасность

• надёжные пароли и отдельные учётные записи для каждого, кто работает с сайтом;
• двухфакторная авторизация в админке, хостинге и почте, к которой привязан домен;
• удаление неиспользуемых плагинов, тем и старых копий сайта на сервере;
• правильные права на файлы и запрет редактирования кода из админки;
• проверка на вредоносный код и отслеживание уведомлений в Яндекс Вебмастере и Google Search Console.

Для WordPress подробный список мер есть в руководстве по защите WordPress. Для других CMS принципы те же: меньше лишнего кода, меньше доступов, всё актуально.

6. Исправление ошибок

Ошибки появляются после обновлений, правок контента, изменений у хостинга или внешних сервисов. Типичные примеры: не уходят письма с формы, «съехала» вёрстка в мобильной версии, не работает фильтр каталога, сломалась выгрузка из 1С, страница отдаёт ошибку 500.

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

7. Мелкие доработки

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

Граница между «мелкой доработкой» и «новым функционалом» должна быть описана в договоре. Иначе споры неизбежны. Частый вариант — ограничение по трудозатратам: всё, что больше оговорённого объёма, оценивается отдельно.

8. Контент-правки

Замена цен, телефонов и адресов, публикация новостей, загрузка товаров, обновление документов и баннеров. Если у компании нет человека, который уверенно работает в админке, эти задачи тоже уходят в поддержку.

Чего техподдержка не делает: отличие от ведения и развития сайта

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

Также обычно не входят в техподдержку:

• редизайн и разработка крупного нового функционала — это отдельный проект с ТЗ и оценкой;
• SEO-продвижение и контекстная реклама — отдельные услуги, хотя технические правки по их задачам поддержка делает;
• оплата хостинга, домена, лицензий CMS и платных плагинов — это расходы владельца сайта;
• создание контента: тексты, фото, дизайн баннеров — если это не оговорено;
• перенос на другой хостинг или CMS — это проект с риском для позиций, его готовят отдельно.

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

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

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

Абонемент

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

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

Почасовая оплата

Вы платите за фактически потраченное время по ставке подрядчика. Отчёт показывает, сколько часов ушло на каждую задачу.

• Плюсы: платите только за сделанное, легко начать.
• Минусы: итоговая сумма заранее неизвестна. Трудно проверить, оправданы ли часы. Плановые работы вроде обновлений легко «забыть», если о них не напоминать.
• Кому подходит: сайтам с редкими и разнородными задачами.

По задачам: «план — отчёт»

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

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

От чего зависит стоимость

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

• CMS и качество кода — самописный сайт без документации обслуживать дороже, чем типовой WordPress;
• размер сайта и число интеграций — 1С, оплата, доставка, CRM;
• требования к скорости реакции — круглосуточная готовность стоит дороже, чем работа в будни;
• частота копий и глубина мониторинга;
• состояние сайта на старте — запущенный проект сначала приводят в порядок, и это отдельные работы.

Ориентиры по нашим услугам — на странице цен.

Кому поручить поддержку: штат, фрилансер или студия

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

Как ставить задачи подрядчику: шаблон

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

Частые ошибки в постановке задач

• «Сайт не работает» без ссылки и описания — подрядчик тратит время на поиск проблемы.
• Несколько разных задач в одном письме — часть теряется, сроки и оценка размываются.
• Задачи в личных сообщениях разным людям — нет истории, нельзя проверить, что сделано.
• Нет критерия готовности — непонятно, когда задача закрыта.
• Пароли открытым текстом в мессенджере — передавайте доступы через менеджер паролей или защищённый канал.

Заведите один канал для заявок: трекер задач, почту или отдельный чат. Главное, чтобы у каждой задачи был статус и история.

SLA и сроки реакции: что прописать в договоре

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

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

Важно различать время реакции и время решения. Реакция — это когда подрядчик взял задачу в работу. Решение — когда проблема устранена. Обещание «реагируем за 15 минут» ничего не говорит о том, когда сайт заработает.

Что ещё прописать в договоре

• Перечень работ — что входит, что нет и где граница «мелкой доработки».
• Регламент плановых работ — частота обновлений, копий и проверок.
• Рабочее время и каналы связи — куда писать в обычном и в аварийном случае.
• Порядок согласования — какие задачи выполняются сразу, какие после оценки.
• Приёмка и отчёт — в каком виде подрядчик отчитывается о сделанном.
• Доступы и права — у кого какие доступы, кто владеет доменом, хостингом и кодом.
• Резервные копии — где хранятся, сколько точек, кто и за какой срок восстанавливает.
• Ответственность — что будет при нарушении сроков и кто отвечает за последствия правок.
• Порядок расставания — передача доступов, документации и копий при окончании работы.

Чек-лист регулярных работ

Список подходит для большинства сайтов на CMS. Для магазина частоту копий и проверок заказов увеличьте.

Ежедневно

• Мониторинг доступности работает, уведомления о падениях приходят.
• Создаётся резервная копия базы данных — для сайтов с заказами и регулярным контентом.
• Проверены заявки и заказы: нет внезапного провала, который говорит о сломанной форме.

Еженедельно

• Полная копия файлов и базы, хранится вне сервера.
• Просмотрены журналы ошибок сервера и CMS.
• Проверены уведомления в Яндекс Вебмастере и Google Search Console.
• Тестовая заявка через главную форму сайта.

Ежемесячно

• Обновлены ядро CMS, плагины, модули и тема — после копии и с проверкой.
• Проверены сроки SSL-сертификата и домена.
• Проверено свободное место на диске и размер базы.
• Удалены неиспользуемые плагины, тестовые файлы и старые копии с сервера.
• Проверена скорость ключевых страниц.
• Подготовлен отчёт о проделанной работе.

Ежеквартально

• Тестовое восстановление из резервной копии.
• Ревизия доступов: удалены учётные записи уволенных сотрудников и бывших подрядчиков.
• Проверка на вредоносный код.
• Проверка битых ссылок и ошибок индексации.

Ежегодно

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

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

Что делать, если сайт упал

Не начинайте с переустановки и «откатов наугад». Сначала поймите масштаб проблемы:

1. Проверьте, что сайт недоступен не только у вас. Откройте его с телефона через мобильный интернет или через сервис проверки доступности.
2. Запишите, что видите. Код ошибки, текст на экране, время. Ошибка 500 и белый экран обычно говорят о проблеме в коде, 502–504 — о сервере, «сайт не найден» — о домене или DNS.
3. Вспомните, что менялось. Обновление плагина, правка темы, смена тарифа хостинга, истёкшая оплата домена или хостинга — самые частые причины.
4. Проверьте оплату домена и хостинга. Банальная неоплата — одна из частых причин внезапного падения.
5. Напишите в поддержку хостинга. Сообщите время и симптомы. Хостинг видит журналы сервера и знает, нет ли у него аварии.
6. Передайте задачу подрядчику по шаблону. Приложите всё, что собрали на предыдущих шагах.
7. Если причина в последнем изменении — откатите его или восстановите сайт из копии, сделанной до изменения. Перед восстановлением сохраните текущее состояние: в нём могут быть свежие заказы.

Короткий простой поисковики переживают спокойно. Если ремонт затягивается, сервер должен отдавать код 503 «Сервис временно недоступен», а не 404 или пустую страницу. Так роботы поймут, что проблема временная.

Что делать, если сайт взломали

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

1. Не паникуйте и зафиксируйте всё. Что видите, когда заметили, что недавно меняли. С этого начинается и инструкция WordPress для взломанных сайтов.
2. Сообщите хостингу. Взлом мог затронуть другие сайты на сервере, а у хостинга есть журналы.
3. Смените все пароли — от админки, хостинга, FTP/SFTP, базы данных и почты. Удалите незнакомых пользователей.
4. Сделайте копию заражённого сайта. Она понадобится, чтобы разобраться, как проникли, и чтобы не потерять свежие данные.
5. Найдите и удалите вредоносный код или восстановите сайт из чистой копии. Ядро CMS и плагины лучше заменить оригинальными файлами той же версии.
6. Закройте уязвимость. Обновите CMS и плагины, удалите заброшенные расширения. Иначе взлом повторится.
7. Ещё раз смените пароли — уже на чистом сайте.
8. Сообщите поисковикам. В Яндекс Вебмастере нарушения и угрозы показаны в разделе «Безопасность и нарушения». После исправления сайт отправляют на проверку (справка Яндекс Вебмастера). В Google — отчёт «Проблемы безопасности» в Search Console, где после очистки запрашивают проверку (справка Search Console).

Как выбрать подрядчика по техподдержке

• Работает с вашей CMS и может показать похожие проекты.
• Предлагает договор с перечнем работ, а не «сделаем всё, что нужно».
• Объясняет, как будет организовано резервное копирование и где хранятся копии.
• Даёт понятные сроки реакции по приоритетам и называет рабочее время.
• Присылает план и оценку до начала работ и отчёт после.
• Не просит перевести на себя домен или хостинг.
• Начинает с аудита: смотрит состояние сайта, версии, доступы и только потом берёт на поддержку.

Хороший признак — когда подрядчик сам задаёт вопросы: где копии, кто владеет доменом, какие интеграции критичны. Плохой — когда соглашается взять сайт «как есть», не заглянув внутрь.

Частые вопросы

Коротко

• Техподдержка держит сайт рабочим и безопасным: обновления, копии, мониторинг, SSL, безопасность, ошибки, мелкие доработки и контент.
• Рост трафика и заявок — задача ведения и развития сайта, а не техподдержки.
• Формат оплаты выбирайте по потоку задач: абонемент — при постоянных задачах, «план — отчёт» и почасовая — при нерегулярных.
• Ставьте задачи по шаблону: где, что происходит, что должно быть, как воспроизвести, срочность.
• В договоре зафиксируйте перечень работ, сроки реакции по приоритетам, копии, доступы и порядок расставания.
• Домен, хостинг и аккаунты поисковых сервисов должны принадлежать владельцу сайта.