Как передаются доступы после сдачи лендинга: домен, хостинг, исходники

Почему тема доступов важнее, чем кажется

Вопрос “что я получу после сдачи лендинга” заказчики задают на стадии подписания договора в 3 случаях из 10. В остальных 7 случаях выясняется это после приёмки, когда уже поздно. Типичный сценарий: разработчик сделал лендинг на своих аккаунтах хостинга и домена, через полгода отключил связь с клиентом, клиент остался без сайта.

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

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

Минимальный пакет доступов

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

1. Домен. Передача прав на домен в вашем личном кабинете регистратора. Если домен куплен на разработчика, процедура Transfer code для переноса на ваш аккаунт.
2. Хостинг. Логин и пароль от панели управления хостингом, либо FTP-доступ, либо и то и другое. Если хостинг оформлен на разработчика, возможность переоформить аккаунт на ваше имя.
3. Исходники сайта. Папка со всеми файлами лендинга в актуальном состоянии. Для HTML это папка со всеми HTML, CSS, JS, картинками. Для Astro или Next - репозиторий Git.
4. Аналитика. Права администратора в Яндекс.Метрике, Google Analytics (если используется). Без этого вы не видите данных по трафику.
5. Рекламные кабинеты. Если разработчик настроил Директ или другие кампании, полный доступ в личные кабинеты.
6. CMS или панель контента. Если используется Pages CMS, WordPress, Kirby - ваш логин с правами администратора.
7. Почтовые адреса. Если на домене настроена почта, логины и пароли от всех ящиков.

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

Расширенный пакет

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

• Документация по структуре. Краткое описание того, что где лежит. 2-3 страницы текста достаточно.
• Бриф со всеми материалами. Исходные тексты, фото, логотипы. На случай переделки.
• Список использованных плагинов и библиотек. Чтобы новый разработчик знал, что установлено.
• Доступы к сторонним сервисам. Платформы рассылок, онлайн-записи, чат-ботов, коллтрекинг.
• Договор и акты. Копии всех документов для бухгалтерии.

Эти элементы обычно передают в zip-архиве или через облачное хранилище вместе с основными доступами.

Форма передачи

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

Документ отправляется через защищённый канал: зашифрованный архив, пароль отдельным сообщением. Либо через сервис типа PrivateBin, Bitwarden Send.

Типичные проблемы

По опыту аудитов я встречал 5 характерных провалов в передаче.

Проблема 1: домен оформлен на разработчика

Самая опасная ситуация. Разработчик покупает домен на свой аккаунт, потому что “так быстрее”. Через год разработчик исчезает, домен не продлевается, сайт отваливается. Клиент не имеет доступа к домену и не может перевести его.

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

Проблема 2: хостинг на общем аккаунте

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

Решение. Ваш сайт на вашем аккаунте хостинга с самого начала. Разработчик получает временный FTP-доступ.

Проблема 3: нет исходников

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

Решение. Для Tilda - аккаунт на ваше имя. Для кастомной разработки - репозиторий Git с полной историей.

Проблема 4: размытые пароли

“Пароль от Метрики примерно такой, попробуйте”. Вы не можете войти, разработчик не помнит точно, реcет пароля через email, который тоже не у вас.

Решение. Все пароли в табличке одного документа. Сменены после передачи. Менеджер паролей на вашей стороне.

Проблема 5: доступ только “по необходимости”

“Я вам доступ дам, когда понадобится”. Это не передача. Это зависимость. В какой-то момент разработчик перестаёт отвечать, и доступ “когда понадобится” становится “никогда”.

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

Чек-лист приёмки по доступам

Перед подписанием акта выполненных работ пройдите 8 пунктов.

1. Я залогинился лично в регистратор домена и вижу домен в своём списке.
2. Я залогинился в панель хостинга. Сайт лежит в моём аккаунте.
3. Я имею FTP-доступ. Скачал для теста один файл.
4. У меня есть полная папка со всеми исходниками в актуальном состоянии.
5. Я зашёл в Яндекс.Метрику, вижу статистику своего счётчика.
6. В Метрике я имею роль “представитель владельца” или “владелец”.
7. У меня есть логин и пароль от CMS или админки сайта, если она используется.
8. Все пароли я сменил и записал в менеджер паролей на своей стороне.

Пока не прошли все 8 пунктов, сдача не завершена. Акт не подписан, финальная оплата не сделана.

Что делать, если разработчик уже пропал

Не редкая ситуация. У вас лендинг, а доступов нет. Последовательность действий.

1. Попробовать восстановить пароль через email. Если email оформлен на вас, это сработает для большинства сервисов.
2. Написать регистратору домена. Если домен оформлен на ваши данные (паспорт), регистратор вернёт доступ. Если на разработчика - сложнее, но возможно через суд.
3. Написать хостингу. Аналогично. Если вы платите с вашей карты, хостинг может передать управление.
4. Если ничего не работает - новый сайт на новом домене и хостинге. Редирект со старого, если он под вашим контролем. Потеря SEO-позиций, но бизнес продолжит работать.

Чтобы избежать этой ситуации, приёмка по чек-листу выше обязательна. Это 30 минут работы, которые спасают от недель разборок.

Сколько хранить доступы после сдачи

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

Храните в зашифрованном виде (менеджер паролей, зашифрованный архив). Бэкапьте на облако и локальный диск.

Мой подход на своих проектах

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

• Домен клиент покупает сам на свой регистратор. Я присылаю инструкцию.
• Хостинг клиент оформляет сам. Я присылаю рекомендации по тарифу.
• Я получаю временный FTP и разрабатываю лендинг.
• После сдачи удаляю свой FTP-доступ, передаю клиенту актуальные исходники в zip.
• Метрика оформляется на аккаунт клиента, я получаю роль “редактор” на время настройки, потом удаляюсь.
• При приёмке клиент проходит чек-лист, подписывает акт.

Такой подход занимает на 30-40 минут больше времени, чем “сделать всё на своих аккаунтах”. Но исключает 99% проблем с доступами в будущем.

Вывод

Передача доступов после сдачи лендинга это не формальность, а критическая часть приёмки. Минимальный пакет: домен, хостинг, исходники, аналитика, рекламные кабинеты, CMS, почта. Всё передаётся в едином документе с таблицей, через защищённый канал. Перед подписанием акта проходите чек-лист из 8 пунктов. Домен и хостинг должны быть оформлены на вас, не на разработчика.

Смежные материалы: Чек-лист приёмки готового лендинга, Что входит в разработку лендинга под ключ и Этапы разработки лендинга.