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

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

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

Шаг 1. Определите цель смены подрядчика и границы передачи

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

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

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

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

Шаг 2. Проверьте контроль компании над доступами

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

• Домен и DNS: регистратор, администратор домена, срок продления, управление записями и контакты для восстановления доступа.
• Хостинг и инфраструктура: панель управления, сервер, CDN, SSL-сертификаты, резервные копии и плательщик.
• Сайт: CMS, исходный код и репозиторий, база данных, лицензии, модули и документация по доработкам.
• Аналитика: Яндекс Метрика, Яндекс Вебмастер, Google Analytics и Google Search Console, если они используются.
• Интеграции: CRM, 1С, почтовые уведомления, телефония, оплата, доставка и рассылки.

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

Для облачных платформ, например Tilda, состав передачи отличается от сайта на собственном сервере. Обычно нужно передать проект, права управления, доменные настройки и подключенные сервисы. Не требуйте SSH-доступ или выгрузку базы данных, если платформа их не предоставляет; уточните доступные способы копирования и восстановления.

Шаг 3. Выберите принимающую команду и согласуйте переход

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

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

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

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

Шаг 4. Проверьте резервную копию и возможность восстановления

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

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

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

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

Подробнее о составе резервной копии на примере WordPress: официальная документация по резервному копированию.

Шаг 5. Зафиксируйте состояние сайта до передачи

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

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

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

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

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

Шаг 6. Проверьте заявки и интеграции от начала до конца

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

Проверьте, что происходит после сообщения об успешной отправке. Заявка должна появиться в нужной CRM или почтовом ящике, содержать корректные данные и поступить ответственному менеджеру. Событие должно фиксироваться в аналитике; источник обращения — передаваться там, где это предусмотрено настройками.

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

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

Шаг 7. Оформите приемку и завершите передачу доступов

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

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

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

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

Шаг 8. Проведите контрольный период и составьте план развития

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

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

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

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

Как начать работу с Пиксель Плюс

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

Состав услуги и условия сопровождения: поддержка и развитие сайтов.

Подробнее о первом этапе: с чего начать работы по технической поддержке.

Вопросы о смене подрядчика

Можно ли передать сайт без остановки работы

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

Обязательно ли переносить сайт на другой хостинг

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

Что делать, если прежний подрядчик не передает доступы

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

Сколько времени занимает передача сайта

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

Нужно ли исправить все старые ошибки до приемки

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

Почему после смены подрядчика стало меньше заявок

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

Автор

Владислав Иванов