Кто будет владеть доменом, хостингом и доступами после сдачи сайта?

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

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

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

1. Домен

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

2. Хостинг и инфраструктура

Хостинг может быть оформлен на заказчика или предоставляться подрядчиком как часть сопровождения. Ключевое — чтобы у вас были админ-доступы и возможность переноса.

3. Доступы к сайту

• административная панель CMS;
• FTP/SSH (если применимо);
• доступ к базе данных;
• доступы к репозиторию (если используется);
• доступы к сервисам рассылок, аналитики, CRM-интеграциям.

Типичные риски, если доступы не оформлены

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

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

Как оформить передачу прав и доступов

1. Фиксация в договоре

В договоре должны быть прописаны:

• кто является администратором домена;
• кому принадлежат исходные материалы и контент;
• перечень передаваемых доступов;
• срок передачи и формат (логины, пароли, 2FA, инструкции);
• обязанности по удалению/передаче учётных записей подрядчика.

Если вы ещё на этапе выбора условий, обратите внимание на важные гарантии и условия договора.

2. Передача через корпоративные почты

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

3. Акт передачи

Формальный акт передачи с перечнем доступов и ресурсов снижает риск споров и недопониманий.

Что ещё важно: эксплуатация и поддержка

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

CTA

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

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

Практика передачи домена, хостинга и доступов: сценарии, сравнение моделей и риски

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

Сценарии владения и управления: как бывает на практике

Сценарий 1. Всё оформлено на заказчика (оптимальный для контроля)

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

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

Сценарий 2. Домен — у заказчика, инфраструктура — у подрядчика

Часто встречается при модели «сайт + сопровождение». Домен оформлен на компанию, но хостинг, резервное копирование и часть сервисов ведёт подрядчик.

• Плюс: меньше рутины для бизнеса.
• Минус: нужно заранее прописать порядок переноса и передачу админ-доступов.

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

Сценарий 3. Домен и аккаунты оформлены на подрядчика (высокий риск)

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

• Риск: потеря контроля над доменом и корпоративной почтой.
• Риск: потеря аналитики и данных по лидогенерации.

Какие доступы должны быть переданы в любом случае

• Домен: доступ к регистратору, DNS, подтверждение владельца.
• Хостинг: панель управления, SSH/FTP (если применимо), база данных.
• CMS: админ-доступ, роли пользователей, 2FA.
• Аналитика: доступ администратора к счетчикам и тег-менеджеру.
• Интеграции: CRM, формы, email-рассылки, мессенджеры, телефония.
• Резервные копии: где лежат, как восстановить.

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

Сравнение моделей передачи

Модель	Кому оформлено	Риски	Кому подходит
Полный контроль заказчика	Заказчик	Минимальные	Компании, которые хотят независимость
Сайт как сервис	Домен у заказчика, остальное у подрядчика	Средние	Если важен SLA и нет внутреннего ресурса
«Всё у подрядчика»	Подрядчик	Высокие	Почти никогда не рекомендуется

Юридическая часть: что фиксировать

В договоре и приложениях стоит зафиксировать:

• кто владелец домена и администратор DNS;
• порядок передачи доступов и сроки;
• что является результатом работ (сайт, исходники, база, контент);
• порядок передачи учётных записей и 2FA;
• порядок переноса сайта при расторжении договора.

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

Практический чек-лист передачи проекта

1. Проверить, что домен оформлен на компанию (или уполномоченное лицо).
2. Сменить пароли и включить 2FA на ключевых сервисах.
3. Получить список всех аккаунтов и доступов в одном документе.
4. Получить инструкции по резервному копированию и восстановлению.
5. Проверить доступы аналитики и интеграции (тестовая заявка).
6. Подписать акт передачи с перечнем ресурсов.

CTA

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

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

Специфика владения доменом, хостингом и доступами: как защитить бизнес и не зависеть от подрядчика

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

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

Критические активы, которые должны контролироваться заказчиком

1) Домен и DNS

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

2) Хостинг и серверные доступы

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

3) CMS, репозиторий и базы данных

Админ-доступ к CMS, пользователи и роли, доступ к базе данных (если применимо), а также доступ к репозиторию кода — это гарантии того, что вы сможете продолжать развитие проекта без «привязки к одной команде».

4) Аналитика и рекламные связки

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

Типовые ошибки заказчиков

• Домен зарегистрирован на подрядчика или на личную почту сотрудника, который может уйти.
• Нет перечня доступов — всё «в переписках», без единого документа.
• 2FA завязано на телефон подрядчика, а не на корпоративный механизм.
• Аналитика не передана: нет прав администратора на счётчики, нет Tag Manager.
• Нет акта передачи с перечнем ресурсов и подтверждением доступа.
• Нет регламента переноса при расторжении договора поддержки.

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

Как выбрать модель владения: три уровня зрелости

• Уровень 1 — минимальный контроль: домен у заказчика, всё остальное у подрядчика. Работает только при прозрачном договоре и чётком SLA.
• Уровень 2 — управляемая модель: домен и аналитика у заказчика, хостинг может обслуживать подрядчик, но с переданными админ-доступами и регламентом переноса.
• Уровень 3 — полный контроль: все ключевые сервисы зарегистрированы на компанию, подрядчик работает по ролям (least privilege), доступы выдаются и отзываются централизованно.

В B2B чаще всего оптимален уровень 2 или 3 — так вы снижаете операционные риски и не блокируете развитие проекта.

FAQ: домен, хостинг и доступы после сдачи сайта

1. Домен может быть оформлен на подрядчика «для удобства», это нормально?

Для бизнеса это риск. «Удобство» подрядчика превращается в зависимость заказчика. При конфликте, смене команды или даже просто при человеческом факторе (забыли продлить, потеряли доступ) вы можете лишиться домена и связанных сервисов. Правильная практика — регистрировать домен на юридическое лицо заказчика или уполномоченное лицо компании и хранить доступы в корпоративном контуре. Подрядчик может помогать с настройками, но не быть владельцем.

2. Если подрядчик оплачивает хостинг, кому он принадлежит?

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

3. Какие доступы нужно получить обязательно, чтобы быть независимым?

Минимум: доступ к регистратору домена и DNS, админ-доступ к CMS, доступ к хостингу/серверу (панель, FTP/SSH при необходимости), доступ к базе данных или хотя бы экспорт/дамп, права администратора на аналитику и Tag Manager, доступы к интеграциям (CRM, почта, формы, коллтрекинг). Плюс — документ с перечнем учётных записей и инструкциями. Без аналитики и интеграций вы теряете управляемость маркетинга и лидов.

4. Должны ли нам передать исходники и репозиторий?

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

5. Что делать с 2FA, если она привязана к телефону подрядчика?

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

6. Нужно ли менять пароли после сдачи?

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

7. Что обязательно прописывать в договоре, чтобы не было зависимости?

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

8. Что если у нас нет IT-специалиста внутри компании?

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

9. Нужно ли подписывать акт передачи доступов?

Да, это снижает риск споров. Акт фиксирует перечень ресурсов, доступов и факт работоспособности. В идеале — с контрольными пунктами: доступ к домену, вход в CMS, доступ к аналитике, тестовая заявка с фиксацией в CRM. Если возникнет конфликт, акт становится вашим документальным подтверждением выполнения обязательств.

10. Что важнее: владение доступами или качество поддержки?

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

11. Может ли подрядчик оставить себе права администратора «на всякий случай»?

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

12. Как проверить, что всё реально передано, а не «на словах»?

Проведите приемочные тесты: войти в аккаунт регистратора домена, изменить запись DNS (и вернуть обратно), войти в хостинг-панель, зайти в CMS, посмотреть пользователей и роли, открыть аналитику и Tag Manager с правами администратора, отправить тестовую заявку и проверить попадание в почту/CRM. Также попросите документ с перечнем всех ресурсов и резервных кодов 2FA. Это занимает немного времени, но защищает от серьёзных проблем позже.

Глоссарий

1. Регистратор домена

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

2. DNS

Система записей, которая связывает домен с сервером и сервисами (сайт, почта, поддомены).

3. Хостинг

Инфраструктура, где размещены файлы и база данных сайта.

4. CMS

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

5. Админ-доступ

Права, позволяющие управлять настройками сервиса и пользователями.

6. 2FA

Двухфакторная аутентификация: дополнительная защита при входе.

7. Резервные коды

Коды для восстановления доступа при потере устройства 2FA.

8. Репозиторий

Хранилище исходного кода (например, Git), где ведётся история изменений.

9. Дамп базы данных

Экспорт базы данных для переноса или восстановления.

10. Tag Manager

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

11. Least privilege

Принцип минимальных прав: доступ выдаётся только на необходимые действия.

12. Акт передачи

Документ, фиксирующий переданные ресурсы, доступы и результаты приёмки.

Заключение

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

CTA

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