Как передать сайт в поддержку: чек-лист для владельца

Передача сайта на поддержку — это не «дайте логин и забудьте». Это процесс который либо защищает бизнес от потери контроля над главным digital-активом, либо оставляет его уязвимым перед первой же технической проблемой. Большинство владельцев бизнеса проходят этот момент хаотично: отправляют пароль в Telegram, говорят «разберитесь сами» и узнают о последствиях только когда что-то ломается в самый неподходящий момент.

Правильно оформленная передача занимает несколько часов но экономит недели нервов и денег в будущем. Вот что нужно подготовить и проверить до того как подрядчик получит доступ к вашему сайту.

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

Прежде чем передавать сайт — стоит понимать что именно вы передаёте и что получите взамен. Между «починить если что-то сломается» и полноценным обслуживанием большая разница.

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

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

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

Это самое частое место где возникает путаница. Подрядчик просит «доступ к сайту» — но на самом деле для полноценной работы нужен доступ к нескольким разным системам:

• Хостинг — панель управления сервером где физически размещён сайт
• Админка CMS — WordPress, OpenCart или другая система управления контентом
• FTP или SSH — для прямого доступа к файлам сайта
• Домен — панель регистратора где настроены DNS-записи
• Google Analytics и Google Search Console — для работы с аналитикой и поисковой оптимизацией
• Рекламные кабинеты — если поддержка включает работу с рекламой

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

Идеальный вариант — не передавать собственные пароли вообще, а создать отдельный аккаунт с необходимыми правами специально для подрядчика.

Что подрядчик должен получить кроме доступов

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

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

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

Как зафиксировать состояние сайта перед передачей

Этот шаг игнорируют почти все — и потом не могут доказать была ли проблема до или после передачи подрядчику.

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

Эта фиксация защищает обе стороны: подрядчик понимает с чем именно он получает сайт, а владелец бизнеса имеет точку отсчёта чтобы оценивать работу в будущем.

Что прописать в договоре чтобы поддержка действительно поддерживала

Устная договорённость «будете следить за сайтом» не даёт никаких гарантий. Договор на поддержку должен содержать конкретные параметры:

1. SLA и время реакции — сколько времени есть у подрядчика чтобы отреагировать на критическую ошибку (сайт недоступен), на обычную ошибку и на запрос на изменения
2. Перечень работ входящих в поддержку — конкретно: обновление ядра CMS, обновление плагинов, резервное копирование с какой частотой, мониторинг доступности
3. Отчётность — как часто и в каком формате подрядчик отчитывается о выполненных работах
4. Лимит часов на изменения — если поддержка включает определённое количество часов на доработки, это должно быть чётко зафиксировано чтобы избежать споров
5. Условия расторжения и возврата доступов — сроки и порядок передачи всех доступов при завершении сотрудничества

Договор без этих пунктов — это не договор на поддержку, а общее пожелание о сотрудничестве.

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