Кому принадлежит сайт: как проверить домен, хостинг, код и доступы
Вопрос «кому принадлежит сайт» обычно возникает не из любопытства, а в неприятный момент: разработчик перестал отвечать, студия закрылась, фрилансер просит «ещё немного денег» за пароли, а домен через месяц истекает. И тут выясняется, что у сайта нет одного владельца. Есть администратор домена, владелец аккаунта у хостера, автор кода, держатель лицензии CMS и хозяин счётчика Метрики — и это могут быть пять разных людей.
Ниже разберём, из чего на деле складывается владение сайтом, как проверить каждый пункт самостоятельно за вечер, что говорит об этом Гражданский кодекс и как по шагам вернуть доступы к сайту, если разработчик не идёт на контакт.
Из чего состоит «владение» сайтом
Юридически и технически сайт — это набор отдельных активов. У каждого свой «владелец», и проверять их нужно по отдельности.
| Актив | Кто считается владельцем | Чем грозит, если он не ваш |
|---|---|---|
| Домен | Администратор доменного имени у регистратора (RU-CENTER, REG.RU, R01 и др.) | Сайт можно «увести» или просто не продлить — адрес достанется другому |
| Хостинг или сервер | Тот, на кого оформлен аккаунт и договор с хостером | Сайт выключат за неоплату, файлы и базу вам не выдадут |
| Исходный код и репозиторий | Правообладатель по договору; технически — владелец репозитория в GitLab/GitHub | Без кода любую доработку придётся начинать с разбора чужого архива или с нуля |
| Админка CMS | Пользователь с правами главного администратора | Бывший подрядчик сохраняет полный доступ к контенту и заявкам |
| Лицензия CMS и модулей | Лицензиат, указанный у вендора (например, в 1С-Битрикс) | Нельзя продлить обновления, получить техподдержку вендора, купить редакцию выше |
| Метрика, Вебмастер, рекламные кабинеты | Владелец счётчика и аккаунта Яндекса | Статистика за годы остаётся у подрядчика, её нельзя перенести задним числом |
| Почта на домене | Аккаунт в Яндекс 360, Mail.ru для бизнеса или на хостинге | Переписка с клиентами и восстановление паролей идут через чужой кабинет |
| Сторонние сервисы | Аккаунты ЮKassa, SMS-шлюза, CRM, карт, капчи, CDN, SSL | Платежи и интеграции перестают работать после смены ключей |
Как проверить, кто владелец сайта: пошагово
1. Домен: кто администратор и где он зарегистрирован
- Откройте WHOIS-сервис регистратора, например nic.ru/whois, или whois.tcinet.ru для зон .RU, .РФ, .SU. Введите домен.
- Поле org покажет название организации-администратора. Если домен оформлен на физлицо, в поле person будет «Private Person» — ФИО скрыто.
- Поле registrar укажет, где обслуживается домен: RU-CENTER-RU, REGRU-RU и т. п. Поле paid-till — до какого числа оплачена регистрация.
- Если видите «Private Person», а вы юрлицо — домен точно не на компании. Если у вас есть логин в кабинет регистратора, проверьте анкету администратора там: ФИО или реквизиты должны быть ваши.
Хороший признак: домен оформлен на ваше юрлицо или ИП, в кабинете регистратора указаны ваши e-mail и телефон, продление в ваших руках. Плохой: домен на ООО студии или на личное имя разработчика.
2. Хостинг: где физически лежит сайт и на кого аккаунт
Узнать хостера можно без доступов. Командой dig A site.ru или любым онлайн-сервисом DNS получите IP-адрес сайта, затем через WHOIS по IP посмотрите, какой провайдер им владеет. NS-записи (dig NS site.ru) покажут, где управляется DNS.
Дальше главный вопрос: кто платит хостеру и на кого заключён договор. Если счета приходят вашей бухгалтерии и в кабинете хостера ваши реквизиты — хостинг ваш. Если «хостинг входит в обслуживание» и оплачивается студии — сайт живёт на чужом аккаунте или на сервере самой студии, и при конфликте его могут просто выключить.
3. Исходный код и репозиторий
Для сайтов на CMS код — это файлы на хостинге плюс база данных. Для проектов на фреймворках (Next.js, Laravel, Django) — ещё и Git-репозиторий, из которого идёт сборка. Попросите показать, где лежит репозиторий, и проверьте, в чьём аккаунте или организации он создан. Правильный вариант — репозиторий в организации вашей компании, а подрядчик приглашён туда участником.
Отдельно выясните, где хранятся секреты: файлы окружения (.env), ключи API, пароли к базе. Без них даже полный код не соберётся и не запустится.
4. Админка CMS и лицензия
Зайдите в админку и откройте список пользователей. У вас должна быть учётная запись с максимальными правами, а лишние администраторы — удалены или понижены. Для 1С-Битрикс проверьте на странице обновления платформы в админке, на кого зарегистрирован лицензионный ключ и до какой даты действуют обновления. Лицензия, купленная на имя студии, формально принадлежит студии. Переоформить её можно только с письменного согласия вендора: по лицензионному соглашению 1С-Битрикс (разд. 5) права можно однократно уступить другому пользователю, запрос подают через техподдержку 1С-Битрикс.
Для WordPress и других open source CMS платной лицензии на ядро нет, но платные темы и плагины обычно привязаны к аккаунту покупателя на маркетплейсе. Если его купил подрядчик, продления и обновления тоже будут у него.
5. Метрика, Вебмастер, реклама
- Яндекс Метрика: в «Настройке → Доступ» видно, кто владелец счётчика и у кого какие права. Владелец может перенести счётчик на другой аккаунт без потери статистики — просите именно перенос, а не гостевой доступ.
- Яндекс Вебмастер: подтвердите права со своего аккаунта (мета-тег, HTML-файл или DNS-запись). Чужие коды подтверждения из кода и DNS после передачи уберите.
- Яндекс Директ: если кампании крутятся в агентском аккаунте подрядчика, это его аккаунт. Историю и настройки можно перенести в ваш кабинет, но это нужно делать до разрыва отношений.
6. Почта и сторонние сервисы
MX-записи домена (dig MX site.ru) покажут, где работает корпоративная почта. Проверьте, у кого доступ к админке почтового сервиса: если у подрядчика, он может читать и сбрасывать почтовые ящики, а через них — пароли от всего остального. Затем пройдитесь по интеграциям сайта: платёжный шлюз, SMS, CRM, выгрузка в 1С, карты, капча, SSL-сертификат. Каждая из них должна быть на аккаунте компании.
Юридическая часть: кому принадлежат права на сайт
Доступы — это техника. Права на сайт определяет Гражданский кодекс, часть четвёртая. Коротко о главном (это не юридическая консультация: выводы по конкретному договору делает юрист):
- Интернет-сайт прямо назван в ГК РФ как составное произведение (п. 2 ст. 1260). Права на подбор и расположение материалов принадлежат составителю, а на отдельные элементы (тексты, фото, дизайн, код) — их авторам или правообладателям.
- Программы для ЭВМ, включая исходный текст и объектный код, охраняются как литературные произведения (ст. 1261). Код сайта — объект авторского права.
- По ст. 1296 исключительное право на программу, базу данных или иное произведение, созданное по договору, предметом которого было его создание (по заказу), принадлежит заказчику, если договором не предусмотрено иное. Подрядчик при этом, если договором не предусмотрено иное, может использовать результат для собственных нужд на условиях безвозмездной простой лицензии.
- Важное исключение (п. 5 ст. 1296): правило не действует, если исполнитель — сам автор, например фрилансер-физлицо или самозанятый. Тогда это договор авторского заказа (ст. 1288), и переход исключительного права к заказчику должен быть прямо предусмотрен договором. Иначе у вас может оказаться лишь право использования в пределах, установленных договором.
- Договор об отчуждении исключительного права заключается в письменной форме, иначе он недействителен (п. 2 ст. 1234).
Что должно быть в договоре и акте приёма-передачи сайта
- Прямое условие: исключительное право на сайт, дизайн, код и базы данных переходит к заказчику в полном объёме с момента подписания акта или оплаты.
- Оговорка о сторонних компонентах: лицензии CMS, шрифтов, фотостоков, модулей — на чьё имя и на каких условиях.
- Обязанность передать исходный код, дампы базы, инструкции по развёртыванию и все доступы.
- Условие о регистрации домена и хостинга на заказчика.
Отдельный акт о переходе исключительного права закон для произведений по заказу не требует. Но акт приёма-передачи сайта с перечнем переданного — кода, доступов, документации — снимает спор о том, что именно и когда вы получили. Если предыдущий подрядчик уже ушёл, а сайт нужно развивать дальше, передачу стоит оформить именно так, даже задним числом. С такой же инвентаризации начинается любой грамотный приём проекта на поддержку после другого разработчика.
Нет доступа к сайту: что делать, если разработчик пропал или не отдаёт доступы
- Зафиксируйте, что у вас есть. Договор, акты, платёжки, переписка, в которой подрядчик подтверждает работу. Сделайте полную копию сайта, если есть хоть какой-то доступ: выгрузку из админки, бэкап через панель хостера, копию из веб-архива как крайний вариант.
- Отправьте письменный запрос. Перечислите конкретные доступы и срок — например, 10 рабочих дней. Запрос по e-mail из договора и заказным письмом с описью.
- Домен на вас — восстанавливайте через регистратора. Если администратор — ваша компания, регистратор восстановит доступ к кабинету по заявлению с документами: для юрлица — на бланке, с подписью уполномоченного лица, копией ИНН, а у ряда регистраторов можно подписать КЭП. Процедуру уточните в справке своего регистратора.
- Домен на разработчике — только его согласие или суд. Смену администратора в .RU и .РФ крупные регистраторы, как правило, проводят бесплатно, но письменную заявку подаёт текущий администратор, а новый заключает договор с тем же регистратором и подтверждает согласие (п. 6.1–6.2 Правил регистрации). По п. 6.5 Правил передать права нельзя, в частности, если срок регистрации истёк, если с момента получения прав от другого лица не прошло 30 дней или если на домен наложены ограничения — досудебные или в связи с судебным спором. Если подрядчик отказывается, остаётся претензия и суд, с обеспечительной мерой — запретом на действия с доменом.
- Хостинг на вашей компании — восстанавливайте через поддержку хостера по документам. На аккаунте подрядчика — хостер доступ вам не даст, файлы придётся получать от подрядчика или по решению суда.
- Претензия и суд. В арбитраже (споры между юрлицами и ИП) по денежным требованиям из договора — возврат оплаты, неустойка — претензия обязательна: в суд можно идти через 30 календарных дней после её направления, если закон или договор не устанавливают иное (ч. 5 ст. 4 АПК РФ). По неденежным требованиям — передать результат работ, доступы, исходный код, переоформить домен — досудебный порядок обязателен, только если он предусмотрен законом или договором. Но письменную претензию стоит направить в любом случае: это доказательство, что вы пытались решить вопрос мирно.
- Параллельно — план Б. Если домен ваш, а код недоступен, сайт восстанавливают на новом хостинге: из бэкапа, из того, что удалось выгрузить, или пересобирают. Когда нужно сменить площадку, поможет перенос сайта на новый хостинг с проверкой, что ничего не потерялось.
Чек-лист передачи сайта: что забрать, где и как проверить
| Что забрать | Где это находится | Как проверить, что передано |
|---|---|---|
| Администрирование домена | Кабинет регистратора | WHOIS: org — ваша компания; в кабинете ваши контакты |
| Аккаунт хостинга или сервера | Панель хостера, VDS | Договор и счета на вас; зашли и сменили пароль |
| SSH/FTP, доступ к базе данных | Панель хостера | Подключились сами, скачали файлы и дамп |
| Исходный код и репозиторий | GitLab, GitHub, архив | Репозиторий в вашей организации; сборка работает по инструкции |
| Секреты (.env, ключи API) | Сервер, CI/CD | Ключи перевыпущены на ваши аккаунты |
| Админка CMS | /bitrix/admin, /wp-admin и т. п. | Вы — главный администратор, лишние учётки удалены |
| Лицензия CMS и модулей | Кабинет вендора или маркетплейса | Лицензиат — ваша компания, срок обновлений виден |
| Метрика, Вебмастер, Директ | Аккаунты Яндекса | Счётчик перенесён на ваш аккаунт; права в Вебмастере подтверждены вами |
| Корпоративная почта | Яндекс 360, хостинг | Админ-доступ у вас, MX указывают на ваш сервис |
| Документы | Договор, акт, инструкция | Есть условие о переходе исключительного права и перечень переданного |
После передачи смените все пароли, отзовите старые SSH-ключи и токены, удалите учётки подрядчика. Если сомневаетесь, что в коде не осталось «закладок» и лишних доступов, разумно провести аудит безопасности сайта.
Типичные ошибки
- «Домен оформим на себя, так удобнее продлевать». Удобнее подрядчику — и так появляются споры через несколько лет.
- Хостинг «в пакете обслуживания» на сервере студии без регулярных бэкапов у заказчика.
- Договор с фрилансером без условия об отчуждении исключительного права. Из-за п. 5 ст. 1296 правило «по умолчанию права у заказчика» здесь не работает.
- Гостевой доступ к Метрике вместо переноса счётчика: при разрыве отношений статистику отзовут.
- Пароли, переданные в мессенджере и ни разу не сменённые.
- Оплата без акта с перечнем переданного — потом нечем доказать, что код и доступы входили в работу.
- Резкая смена подрядчика без инвентаризации: новый разработчик получает сайт, который не может ни собрать, ни обновить. В таких случаях доработка сайта начинается с восстановления окружения, а это лишние недели.
Коротко
- Домен: в WHOIS ваша организация, кабинет регистратора на вашем e-mail.
- Хостинг: договор и оплата от вашей компании, доступы у вас.
- Код и база: свежая копия у вас, репозиторий в вашей организации.
- Админка и лицензия CMS: вы главный администратор и лицензиат.
- Аналитика и реклама: счётчики и кабинеты на ваших аккаунтах Яндекса.
- Документы: договор с условием о переходе исключительного права и акт приёма-передачи сайта.
Если все шесть пунктов закрыты, сайт действительно ваш — и смена подрядчика превращается в рабочую процедуру, а не в кризис.
