Как передать сайт другому подрядчику и ничего не потерять

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

Поэтому передача сайта другому подрядчику требует подготовки.

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

Почему одного доступа к сайту недостаточно

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

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

Но при первой же серьёзной доработке появляются вопросы.

- Где находятся исходные файлы? 

- Кто управляет сервером? 

- Как настроена отправка заявок? 

- Почему после изменения формы обращения перестали поступать менеджерам?

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

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

Сайт может зависеть сразу от нескольких систем:

• хостинга,
• домена,
• электронной почты,
• CRM,
• аналитики,
• внешних сервисов,
• собственного программного кода.

Чтобы другой подрядчик мог отвечать за его работоспособность, необходимо разобраться во всех этих зависимостях.

Какие доступы нужно запросить у прежнего подрядчика

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

Домен и управление DNS

Домен — это адрес сайта, например example.ru. Он регистрируется через специальную компанию — регистратора.

В первую очередь выясните, кто является администратором домена и у кого есть доступ к управлению им.

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

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

Ошибки при изменении DNS могут сделать сайт недоступным или нарушить работу корпоративной почты.

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

Хостинг и сервер

Хостинг — это место, где размещаются файлы сайта, база данных и программное окружение.

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

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

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

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

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

Если сайт работает на WordPress, «1С-Битрикс» или другой CMS, новому подрядчику потребуется учётная запись с правами, необходимыми для обслуживания.

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

Обычного доступа для редактирования страниц часто недостаточно.

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

Исходный код и база данных

Это одна из наиболее значимых частей передачи.

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

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

Если разработка ведётся через Git, уточните, где расположен репозиторий — хранилище истории изменений кода, и каким образом новому подрядчику будет предоставлен доступ.

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

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

Внешние сервисы и интеграции

Даже небольшой корпоративный сайт может взаимодействовать с несколькими сторонними системами.

Например, посетитель отправляет заявку, сайт передаёт её в CRM, менеджеру приходит уведомление, а Яндекс.Метрика фиксирует достижение цели.

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

Запросите список подключённых сервисов, сведения об их владельцах и описание того, за какие функции они отвечают.

В зависимости от проекта это могут быть CRM, почтовые сервисы, онлайн-оплата, доставка, телефония, аналитика, сервисы уведомлений и другие интеграции.

Секретные ключи и пароли не следует пересылать в общих чатах или хранить в открытых документах. Безопаснее предоставить новой команде отдельные учётные записи, а технические секреты передавать защищённым способом или перевыпускать.

Чек-лист передачи сайта новому подрядчику

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

Этот перечень можно использовать как основу для переписки с прежним подрядчиком.

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

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

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

Получить архив с файлами и список паролей — только половина работы.

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

Но проверить содержимое никто не пытался.

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

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

Проверка резервной копии

Наличие резервной копии нужно подтвердить технически.

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

Самая надёжная проверка — восстановление на отдельном тестовом окружении.

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

При этом сама по себе успешная загрузка главной страницы ещё не доказывает, что восстановлены все данные и интеграции.

Проверка доступа к коду

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

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

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

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

Как не потерять заявки во время смены исполнителя

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

Например, после смены технических настроек форма продолжает показывать сообщение «Спасибо, заявка отправлена». Посетитель уверен, что компания получила обращение.

Но письмо не приходит, а в CRM новая заявка не появляется.

Если никто специально не проверяет этот сценарий, проблему можно обнаружить значительно позже.

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

• Куда отправляются заявки с каждой формы.

• Какие уведомления получает клиент.

• Какие данные передаются в CRM.

• Работают ли телефоны, ссылки на мессенджеры и почту.

• Какие события фиксируются системой аналитики.

После передачи эти сценарии необходимо проверить повторно.

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

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

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

Что будет с SEO и поисковыми позициями?

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

Риски появляются, когда вместе со сменой исполнителя непреднамеренно меняются настройки.

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

Или при обновлении файлов перестают работать отдельные страницы, меняются адреса, нарушаются перенаправления.

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

После технических изменений следует проверить доступность сайта, ответы сервера, важные URL, robots.txt, sitemap.xml и корректность работы инструментов вебмастера.

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

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

Если прежний подрядчик не отдаёт доступы

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

Первое, что стоит сделать, — установить, какие ресурсы действительно находятся под вашим контролем.

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

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

Желательно собрать договоры, акты, счета, переписку о передаче проекта и подтверждения оплаты.

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

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

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

Как организовать передачу без лишних расходов

Не всякая смена подрядчика требует сложного технического проекта.

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

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

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

Самый практичный подход — разделить передачу и дальнейшее развитие сайта.

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

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

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

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

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

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

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

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

Такие моменты лучше обозначить сразу.

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

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

С чего начать, если вы решили сменить подрядчика

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

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

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

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

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

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