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

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

Почему передачу нужно планировать заранее

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

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

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

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

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

Домен. Логин и пароль от регистратора домена — reg.ru, nic.ru, Timeweb, Beget или любого другого. Либо перенос домена на аккаунт нового разработчика. Ключевое: домен должен быть зарегистрирован на вас или вашу компанию. Если он на физлице предыдущего разработчика — это первая проблема, которую нужно решить. Без контроля над доменом вы не контролируете свой сайт.

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

CMS и админка сайта. Логин и пароль администратора WordPress, Битрикса, Joomla или другой CMS. Если админ-аккаунт один — создайте отдельный для нового разработчика, а старый заблокируйте после завершения передачи. Не удаляйте сразу — на случай, если нужно будет уточнить что-то у предыдущего подрядчика.

База данных. Реквизиты подключения к MySQL или PostgreSQL: хост, порт, имя пользователя, пароль, название базы данных. Обычно эти данные есть в конфигурационных файлах CMS — wp-config.php для WordPress, .settings.php для Битрикса.

Исходники дизайна. Макеты в Figma, PSD-файлы, иллюстрации в исходном качестве. Если дизайн делался на заказ и в договоре прописана передача исключительных прав — эти файлы ваши. Если не прописана — формально дизайнер может не отдать исходники. Это одна из самых частых юридических проблем.

Репозиторий кода. Если код хранится в Git — GitHub, GitLab, Bitbucket — предоставьте доступ или перенесите репозиторий на ваш аккаунт. Репозиторий — это не только текущая версия кода, но и вся история изменений, что критически важно для нового разработчика.

Аналитика. Яндекс Метрика — добавьте нового разработчика как пользователя с нужным уровнем доступа. Google Analytics — аналогично. Убедитесь, что счётчик аналитики привязан к вашему аккаунту, а не к аккаунту бывшего подрядчика. Я видел ситуации, когда при смене разработчика терялась вся история аналитики за годы, потому что Метрика была на его аккаунте.

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

Корпоративная почта на домене. Если на домене настроена почта — доступы к Яндекс 360, Mail.ru для бизнеса или другому почтовому сервису. Включая DNS-записи MX, SPF, DKIM.

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

Интеграции и API-ключи. Платёжные системы — ЮKassa, Т-Банк, CloudPayments. CRM — amoCRM, Bitrix24. Сервисы доставки — СДЭК, Boxberry. Сервисы рассылок — Unisender, Sendsay. Все API-ключи и токены.

Что попросить у предыдущего разработчика

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

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

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

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

Список зависимостей — какие версии PHP, Node.js, библиотек и расширений нужны. Если новый хостинг настроен иначе, сайт может не запуститься.

Подводные камни, которые я встречал

Домен зарегистрирован на разработчика. Самая опасная ситуация. Юридически он владелец домена и может отказаться его передавать. Или потребовать за это деньги. У меня был клиент, которому предыдущий подрядчик выставил 200 000 рублей «за передачу домена», хотя домен обошёлся в 500 рублей. Клиенту пришлось платить, потому что на этом домене годами строилась SEO-стратегия, и потеря домена означала потерю всего трафика.

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

Лицензии плагинов и шаблонов. Платные плагины WordPress или лицензия Битрикса могут быть привязаны к аккаунту предыдущего разработчика. После расставания он деактивирует лицензию, и плагины перестают обновляться. Вам придётся покупать лицензии заново.

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

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

Как минимизировать риски с самого начала

Регистрируйте домен на своё юрлицо или ИП. Оплачивайте хостинг со своего аккаунта. Создавайте счётчики аналитики на своих аккаунтах и давайте подрядчику гостевой доступ. Храните все доступы в менеджере паролей — Bitwarden, 1Password, KeePass. Включайте в договор пункт о передаче всех исходников и прав при расторжении. Раз в полгода проверяйте, что все доступы актуальны и вы можете войти в каждый сервис.

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