Кому принадлежит сайт после разработки: домен, код, дизайн, лицензии и аккаунты

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

И вот выясняется, что домен зарегистрирован на директора веб-студии, VPS находится в аккаунте этой же студии, Figma доступна только на просмотр, Elementor Pro активирован с агентской подписки, исходный Git лежит в приватной организации подрядчика, Яндекс Метрика создана на личном аккаунте специалиста, а резервные копии хранятся в облаке, к которому клиент никогда не получал доступа.

При этом сайт исправно работал два года. Компания его оплатила. На всех документах стоит её логотип.

Возникает неприятный, но правильный вопрос:

Компания действительно купила сайт или два года пользовалась цифровой конструкцией, критические части которой контролируют другие люди?

Ответ не сводится к «да» или «нет», потому что сайт — не одна вещь.

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

Поэтому в нормальном проекте нужно отдельно отвечать минимум на три вопроса:

кому принадлежат или на каких условиях используются результаты интеллектуальной деятельности;

кто физически имеет доступ к системам;

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

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

«Сайт мой» — слишком неточная формулировка

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

На бытовом уровне этого достаточно.

На техническом и юридическом — нет.

Возьмём обычный WordPress-проект. За его работой могут стоять доменное имя, DNS, аккаунт регистратора, хостинг или VPS, системный пользователь сервера, база данных, WordPress, индивидуальная тема, несколько собственных PHP-модулей, десяток сторонних плагинов, JavaScript-библиотеки, фотографии, иконки, шрифты, Figma, Git, SMTP, CDN, резервные копии, Яндекс Метрика, Search Console, Яндекс Вебмастер и Google Tag Manager.

У каждой части свой режим.

WordPress распространяется по GPL.

Фотография может использоваться по лицензии фотостока.

Кастомный PHP является самостоятельным результатом разработки.

Elementor Pro существует вместе с подпиской и аккаунтом.

Домен зарегистрирован на конкретное лицо.

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

Поэтому фраза в акте:

«Сайт передан заказчику»

сама по себе отвечает удивительно мало на вопрос о том, что именно произошло.

Право, доступ и контроль — три разные вещи

Это, пожалуй, главное различие всей статьи.

Юридическое право

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

Технический доступ

Это возможность прямо сейчас войти в систему.

Например, компания знает root-пароль сервера.

Административный контроль

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

Три уровня легко расходятся.

Компания может получить пароль от WordPress и считать, что сайт у неё. Но пользователь WordPress не управляет доменом.

Можно иметь SFTP и не иметь кабинета хостинга.

Можно иметь root на VPS, но не иметь возможности продлить сам VPS.

Можно видеть Figma, но не иметь права редактировать исходный файл.

Можно иметь копию PHP-файлов, но не иметь Git и информации о сборке.

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

Именно поэтому я бы оценивал реальное владение сайтом не одной галочкой, а формулой:

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

Домен: сначала смотрим, на кого он зарегистрирован

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

Но факт оплаты регистрации не делает плательщика автоматически лицом, на которое зарегистрирован домен.

С 1 сентября 2026 года в России действует новый официальный порядок регистрации доменных имён. Постановлением Правительства РФ №1119 установлены единые правила, а значимые операции требуют идентификации лица, на которое зарегистрирован домен. Передача права администрирования начинается именно по заявке этого лица.

Для российских национальных доменов ситуация стала ещё практичнее: после 1 сентября 2026 года для значимых операций, включая регистрацию, продление и смену администратора, используется идентификация через ЕСИА. Координационный центр отдельно предупреждает, что без необходимой идентификации продление становится невозможным.

Теперь вернёмся к нашей компании.

Она два года оплачивала company.ru, но домен зарегистрирован на сотрудника старого подрядчика.

С точки зрения бухгалтерии деньги тратила компания.

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

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

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

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

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

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

Хостинг и сервер: root-пароль ещё не делает аккаунт вашим

Следующая типовая ситуация выглядит довольно убедительно.

Подрядчик говорит:

Вот IP сервера, root и пароль. Всё передали.

Для администрирования Linux этого действительно достаточно.

Для контроля услуги — не обязательно.

Допустим, VPS создан в клиентском аккаунте студии. Именно у студии:

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

Компания имеет полный root внутри виртуальной машины, но не контролирует внешнюю оболочку, в которой эта машина существует.

Федеральный закон №149-ФЗ определяет провайдера хостинга как лицо, предоставляющее вычислительную мощность для размещения информации. То есть в типичном VPS-сценарии бизнес не «получает сервер в собственность» — он пользуется инфраструктурной услугой провайдера.

Поэтому root-пароль можно сравнить с ключом от арендованного офиса.

Ключ важен.

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

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

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

Код сайта: здесь начинаются настоящие юридические нюансы

Самая опасная формулировка в подобных материалах звучит так:

Если вы заплатили разработчику, весь код автоматически ваш.

Вторая по опасности:

Если договор ничего не говорит, весь код всегда остаётся разработчику.

Обе слишком категоричны.

Российский ГК действительно содержит специальные правила для произведений, созданных по заказу, но результат зависит от конструкции отношений.

Если создание произведения было предметом договора

Статья 1296 ГК РФ устанавливает: исключительное право на программу для ЭВМ, базу данных или иное произведение, которое было создано по договору именно как заказанный результат, принадлежит заказчику, если договором между подрядчиком и заказчиком не предусмотрено иное.

Это очень важная презумпция.

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

разработать индивидуальный модуль расчёта доставки.

Модуль и есть ожидаемый предмет заказа.

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

Но на этом юридическая история не заканчивается.

Если исполнителем является сам автор

У статьи 1296 есть пункт 5: её правила не распространяются на договоры, где исполнителем является непосредственно автор произведения. Для такого случая Кодекс отсылает к договору авторского заказа.

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

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

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

Если произведение появилось попутно

Есть и противоположная ситуация.

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

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

Именно поэтому фраза:

«по закону всё всегда принадлежит заказчику»

не выдерживает проверки.

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

Автор и правообладатель — не одно лицо по определению

Ещё один популярный источник путаницы — слово «автор».

ГК РФ определяет автором гражданина, творческим трудом которого создан результат. Первоначально исключительное право возникает у автора, но оно может перейти другому лицу по договору или по предусмотренному законом основанию.

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

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

Поэтому юридически корректнее говорить:

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

а не:

компания стала автором дизайна.

Автором остался человек.

Измениться может правообладатель.

А если код написал сотрудник веб-студии

Здесь появляется ещё одно звено.

Разработчик работает в ООО «Веб-студия», а договор на создание сайта компания-заказчик заключает не с программистом, а с ООО.

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

Получается цепочка:

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

На хорошем проекте эта цепочка скучна и незаметна.

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

Исключительное право можно передать — но договор должен это действительно делать

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

Статья 1234 ГК РФ требует письменной формы такого договора. Для возмездного отчуждения важно определить вознаграждение или порядок его определения: при отсутствии этого условия возмездный договор может считаться незаключённым.

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

Фраза:

«разработчик передаёт все права»

лучше, чем отсутствие формулировки.

Но хороший договор всё равно должен отвечать конкретнее:

что именно создано;

какие результаты передаются;

какой режим устанавливается;

когда возникает или переходит исключительное право;

какие компоненты являются сторонними и используются по лицензии;

что получает заказчик после оплаты и приёмки.

Особенно опасно называть «передачей исключительного права» сторонний продукт, исключительное право на который у студии никогда не было.

Например, подрядчик не может передать заказчику исключительное право на WordPress только потому, что установил CMS.

Исходный код и права на код — тоже разные вещи

Теперь представим идеальный договор.

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

Но Git находится у подрядчика.

На production есть только собранный код.

Исходные SCSS, TypeScript, build-конфигурация и история миграций нигде не переданы.

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

Практически новый разработчик получает археологический проект.

Обратная ситуация тоже возможна.

Заказчику отдали ZIP со всеми PHP-файлами и Figma.

Физические копии есть.

Но договор предоставляет лишь ограниченное право использования.

Получить файл и получить исключительное право — не одно действие.

Поэтому в процедуре сдачи проекта я бы отдельно фиксировал два факта:

какие права получил заказчик;

и

какие исходные материалы, репозитории и технические данные фактически ему переданы.

Один пункт не заменяет другой.

Git: обязан ли разработчик передать репозиторий

Универсального правила:

любой разработчик обязан по закону отдать клиенту GitHub с полной историей,

нет.

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

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

Но следующий разработчик потеряет:

• историю изменений;
• branches;
• tags;
• понятные releases;
• CI/CD;
• dependency manifests;
• миграции;
• инструкции сборки;
• возможность понять, зачем конкретный кусок кода вообще появился.

Хорошая организационная модель поэтому довольно проста:

репозиторий создаётся в организации заказчика, а подрядчики получают доступ.

Тогда сменился разработчик — изменились права пользователя Git.

Сам цифровой актив никуда не переезжал.

Компания заплатила 300 000 ₽. Разбираем, что оказалось чужим

Вернёмся к нашему примеру.

Сайт полностью оплачен.

Договор закрыт.

Компания решила сменить исполнителя.

И выяснилось следующее.

Домен находится на физическом лице старой студии.

VPS — в аккаунте агентства.

В GitHub компании нет репозитория.

Figma открывается, но только на просмотр.

Elementor Pro зарегистрирован на подрядчика.

ACF PRO активирован его ключом.

Метрика существует в чужом Яндекс ID.

В Search Console остался подтверждённый владелец студии.

GTM вообще был создан бывшим рекламным специалистом.

SMTP работает через сервис, оплата которого списывается с карты программиста.

Backup действительно есть — в чужом облачном бакете.

Можно ли при этом утверждать, что у бизнеса «вообще нет прав на сайт»?

Не обязательно.

Вполне возможно, что права на кастомную тему или код у него оформлены нормально.

Но операционная независимость проекта крайне низкая.

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

И именно это обычно вскрывается не во время разработки, а в день смены подрядчика.

WordPress: кому принадлежит сама CMS

На WordPress особенно хорошо видно, почему сайт нельзя воспринимать как единое произведение.

WordPress официально распространяется под GNU GPL версии 2 или более поздней. Сам WordPress.org также указывает свою позицию, что производные от WordPress темы и плагины наследуют GPL.

Поэтому после разработки заказчик не становится владельцем исключительного права на WordPress core.

Он использует программу по открытой лицензии.

Это принципиально отличается от индивидуального PHP-модуля, который был специально написан для проекта.

При этом слово «бесплатный» тоже вводит в заблуждение.

GPL — про свободы использования, изучения, изменения и распространения при соблюдении условий лицензии, а не про отсутствие авторского права и не про обязанность любого разработчика работать бесплатно. Сам GNU Project прямо подчёркивает: free software означает свободу, а не нулевую цену; copyleft вообще работает именно потому, что авторское право существует.

Поэтому в одном WordPress-проекте совершенно нормально одновременно иметь:

Компонент	Практический режим
WordPress core	GPL
сторонний бесплатный плагин	его лицензия
коммерческий plugin/service	код + условия лицензии/подписки
кастомная тема	права зависят от происхождения кода и договора
собственный PHP-модуль	права зависят от договора и закона
изображения	собственные или лицензированные
шрифт	отдельная лицензия
тексты	самостоятельные произведения
база данных и пользовательские данные	отдельный правовой и технический контекст

Фраза:

«Сайт сделан на WordPress, значит он весь GPL»

слишком грубая.

Точно так же грубо утверждать:

«Мы заплатили за WordPress-сайт, значит теперь всё его содержимое принадлежит нам на исключительном праве».

Нужно смотреть происхождение каждого компонента.

Elementor, ACF PRO и другие платные плагины: файл есть, подписки может не быть

С коммерческими WordPress-продуктами появляется дополнительный слой: аккаунт и подписка.

Elementor Pro

Elementor связывает активацию Pro с аккаунтом и подпиской. В документации есть отдельная процедура деактивации сайта и переноса лицензии между доменами. В августе 2026 года инструкция также описывает управление переносом подписки через аккаунт.

Теперь представим агентскую лицензию на десятки сайтов.

Студия активировала ваш проект одним своим slot.

Плагин установлен.

Сайт работает.

Но это не означает, что компания автоматически получила аккаунт студии или её подписку.

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

Поэтому вопрос нужно решить заранее:

кто покупает подписку;

кому принадлежит аккаунт;

кто оплачивает продление;

что произойдёт после завершения поддержки.

ACF PRO

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

Следовательно:

файл advanced-custom-fields-pro присутствует на сервере

и:

компания имеет собственную действующую лицензию ACF PRO

— два разных утверждения.

Для поддержки сайта это важно.

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

Дизайн и Figma: «я вижу макет» не значит «исходник передан»

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

Есть минимум три разных вопроса.

Первый — кто является автором дизайна.

Второй — кому принадлежит исключительное право или в каких пределах дизайн разрешено использовать.

Третий — получил ли заказчик технически пригодный исходник.

Допустим, дизайнер прислал ссылку на Figma.

Компания открывает её.

Макет виден.

Но доступ view only.

Компоненты остаются в библиотеке студии.

Переменные и design tokens принадлежат другому workspace.

Следующий дизайнер не способен нормально продолжить работу.

Это не обязательно означает нарушение договора: всё зависит от того, что стороны договорились передать.

Но если бизнес ожидает независимую дальнейшую разработку интерфейса, в результате проекта стоит явно предусмотреть передачу editable source, используемого UI-kit и необходимых assets.

А юридический режим дизайна определить отдельно.

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

Шрифты: файл весит 100 КБ, а проблема может стоить заметно дороже

Шрифты — прекрасный пример того, почему ZIP сайта ничего не доказывает.

В папке темы лежит:

/fonts/brand-font.woff2

Технически файл у компании есть.

Но откуда он появился?

Дизайнер купил desktop-лицензию?

Студия имеет webfont license?

Лицензия ограничивает число доменов или просмотров?

Можно ли передать файл следующему подрядчику?

Можно ли использовать его в мобильном приложении?

Можно ли делать из него рекламные баннеры?

Ответ определяется условиями конкретного правообладателя, а не фактом существования .woff2 на сервере.

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

Это значительно скучнее дизайна главной страницы.

И значительно приятнее, чем восстанавливать происхождение шрифта через четыре года.

Стоковые фотографии, видео и иконки

С изображениями та же логика.

Фотографию можно скопировать на сервер.

Это не означает, что исключительное право на неё перешло компании.

Возможен совершенно нормальный сценарий:

студия приобрела stock asset;

лицензия разрешает использовать его в клиентском проекте;

сайт законно показывает изображение;

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

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

материалы заказчика;

оригинальные материалы, созданные в рамках проекта;

сторонние лицензированные assets.

Сваливать их в одну фразу «графика передана» неудобно и для бизнеса, и для следующего подрядчика.

Яндекс Метрика: счётчик должен жить не в личной жизни подрядчика

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

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

Поэтому архитектура:

счётчик создан на личном Яндекс ID SEO-специалиста, а директору дали просмотр

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

Правильнее:

счётчик находится под корпоративным аккаунтом бизнеса;

специалисты получают нужные роли.

Тогда увольнение, конфликт или потеря личного аккаунта не превращаются в проблему собственности на накопленную аналитику.

Search Console: проверить нужно не только свой доступ, но и старых владельцев

Google Search Console различает владельцев и пользователей.

Владелец имеет полный контроль над property и способен управлять другими пользователями. При этом существуют подтверждённые и делегированные владельцы. Google отдельно рекомендует проверять неизвестных владельцев и удалять их verification tokens при необходимости.

Вот типичная проблема после передачи сайта.

Компания получила owner access.

Все довольны.

Но на сервере остался HTML verification file старой студии.

То есть прежний подрядчик тоже продолжает быть подтверждённым владельцем.

Передача доступа поэтому должна включать не только:

добавили клиента.

Нужно проверить, кто ещё сохранил административное подтверждение.

Яндекс Вебмастер: владелец должен быть у бизнеса

В Яндекс Вебмастере управлять правами других пользователей может пользователь с ролью «Владелец», подтвердивший права на сайт.

Логика та же.

Компания подтверждает сайт своим аккаунтом.

SEO-специалисту выдаётся рабочий доступ.

Закончился договор — доступ специалиста снимается, а сам ресурс остаётся на месте.

Это и есть нормальная модель делегирования.

Google Tag Manager: маленький аккаунт с очень большими возможностями

Tag Manager легко забыть, потому что посетитель сайта его вообще не видит.

А зря.

Через GTM можно управлять большим количеством клиентского JavaScript и аналитических интеграций.

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

Представьте прекрасную передачу сайта.

Домен у клиента.

VPS у клиента.

Git у клиента.

Метрика у клиента.

Но GTM остаётся у бывшего маркетолога с правом Publish.

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

Именно поэтому инвентаризация доступов должна смотреть шире wp-admin.

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

Корпоративная почта, SMTP и формы

Ещё один слой обычно обнаруживается только после поломки.

Компания перенесла сайт к новому разработчику.

Через несколько дней перестали приходить заявки.

Форма открывается.

Кнопка работает.

WordPress ошибок не показывает.

Оказывается, SMTP был настроен через сервис старого подрядчика.

Он закрыл аккаунт — письма перестали доставляться.

Сайт может зависеть от:

• SMTP account;
• transactional email service;
• API key;
• DKIM;
• SPF;
• DMARC;
• recovery email;
• DNS.

Поэтому «почта работает» во время приёмки проекта недостаточно.

Нужно понимать, за счёт какого аккаунта она работает и кто может продлить или восстановить этот аккаунт.

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

Резервная копия существует только тогда, когда её можно восстановить

Фраза:

мы каждый день делаем backup

успокаивает.

До первого восстановления.

Резервная копия может:

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

Для бизнеса нормальный критерий значительно жёстче:

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

Если этого никто никогда не проверял, существует не доказанный backup, а надежда на backup.

Договор: что именно стоит фиксировать

Хороший договор на разработку не обязан превращаться в энциклопедию на 140 страниц.

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

Особенно важно не ограничиваться формулой:

Исполнитель передаёт Заказчику все права на Сайт.

Потому что внутри сайта могут быть результаты, на которые у самого исполнителя нет исключительного права: WordPress, open-source libraries, stock assets, коммерческие шрифты и сторонние плагины.

Практически договор должен позволять ответить на несколько вопросов без гадания:

Вопрос	Что должно быть понятно
Что создаётся?	сайт, тема, модуль, дизайн, тексты, интеграции
Что является оригинальным результатом?	конкретный код, макеты, графика, документация
Какие права получает заказчик?	исключительное право либо конкретный объём использования
Когда возникает/переходит право?	по правилам договора и применимого закона
Какие компоненты сторонние?	CMS, библиотеки, плагины, fonts, stock
Что фактически передаётся?	Git, Figma, assets, база, документация
Какие аккаунты должны принадлежать бизнесу?	домен, hosting, analytics, mail, SaaS
Что остаётся у подрядчика?	только явно оговорённые права и доступы

Если используется отдельная конструкция отчуждения исключительного права, нужно помнить о письменной форме и требованиях статьи 1234 ГК РФ к вознаграждению в возмездном договоре.

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

Почему одной фразы «все права принадлежат заказчику» мало

Представим, что договор действительно очень щедрый:

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

Отлично.

Но через год новый подрядчик спрашивает:

Где Git?

Git нет.

Где Figma?

Есть JPG.

Где лицензия шрифта?

Неизвестно.

Где аккаунт Elementor?

У прошлой студии.

Где root?

Был в Telegram бывшего директора.

Где backup?

«Кажется, на Яндекс Диске у Сергея».

Юридическая формулировка может быть хорошей.

Передача проекта — всё ещё плохая.

Именно поэтому договор и handover checklist решают разные задачи.

Договор определяет правовой режим.

Handover подтверждает, что цифровой актив физически и административно передан.

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

Я бы не строил приёмку вокруг одной папки site-final.

У проекта должно быть восемь зон контроля.

Первая — домен и DNS: организация указана нужным лицом в регистрационной системе, имеет собственный кабинет, восстановление и 2FA.

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

Третья — код и Git: доступен актуальный исходный код, понятны зависимости, deployment и конфигурация.

Четвёртая — данные и backups: база, uploads и резервные копии реально восстанавливаются.

Пятая — дизайн: editable source и необходимые элементы системы интерфейса доступны в оговорённом объёме.

Шестая — licenses/assets: известны сторонние плагины, шрифты, изображения, SaaS и будущие платежи.

Седьмая — аналитика и маркетинг: Метрика, Search Console, Вебмастер, GTM и рекламные системы находятся под контролем бизнеса.

Восьмая — техническая документация и recovery: понятно, какие интеграции работают, где API, webhook, cron, SMTP и как восстановить каждый критичный аккаунт.

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

Для этого не нужен юридический аудит на первом этапе.

Попробуйте мысленно убрать старого разработчика из Telegram.

Не поссориться с ним.

Не попросить помочь последний раз.

Просто представить, что человек недоступен.

И пройти следующий сценарий.

Шаг 1. Продлите домен

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

Шаг 2. Откройте кабинет хостинга

Убедитесь, что компания видит биллинг, тариф, сервер, backup и поддержку.

Шаг 3. Получите чистую копию проекта

Проверьте Git, файлы, базу данных, uploads и инструкции развёртывания.

Шаг 4. Проверьте дизайн

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

Шаг 5. Составьте список платных компонентов

Для каждого плагина, шрифта, SaaS и asset ответьте: чей аккаунт, какая лицензия, кто продлевает и что произойдёт после окончания подписки.

Шаг 6. Проверьте административные аккаунты

Метрика, Search Console, Вебмастер, GTM, SMTP и другие сервисы должны иметь понятного корпоративного владельца и актуальные способы восстановления.

Шаг 7. Проверьте backups

Скачайте копию и убедитесь, что другой специалист способен её восстановить.

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

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

Если на любом критичном шаге появляется:

позвонить Сергею,

вы нашли реальную зависимость.

Можно ли измерить зависимость числом

Юридического стандарта «процент владения сайтом» не существует.

Но для внутреннего аудита можно построить полезную диагностическую модель.

Возьмём 12 критичных активов:

Актив	Компания контролирует самостоятельно?
домен	да / нет
DNS	да / нет
hosting account	да / нет
server/root	да / нет
Git	да / нет
backup	да / нет
Figma/source	да / нет
plugin subscriptions	да / нет
Метрика	да / нет
Search Console / Вебмастер	да / нет
GTM	да / нет
SMTP	да / нет

Допустим, компания полностью контролирует только 4 из 12.

Можно получить:

4 / 12 × 100 = 33,3%

Но это не юридическая оценка права собственности и не отраслевой показатель.

Это всего лишь наглядная внутренняя метрика зависимости.

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

Если домен зарегистрирован на постороннего человека, наличие собственного Google Tag Manager мало утешает.

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

Кто должен владеть аккаунтами: клиент или студия

Для критичных сервисов мне кажется наиболее устойчивой простая архитектура:

бизнес создаёт актив, подрядчик получает доступ.

Компания регистрирует домен.

Компания создаёт аккаунт хостинга.

Компания владеет основной аналитикой.

Компания контролирует Git organization.

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

Тогда сотрудничество заканчивается не миграцией цифровой собственности, а обычным отзывом доступа.

Есть исключения.

У агентства может быть выгодная multisite-лицензия.

У студии может быть собственная серверная инфраструктура как управляемая услуга.

Подрядчик может предоставлять SaaS в составе обслуживания.

В этом нет ничего неправильного.

Неправильно, когда клиент уверен, что актив принадлежит ему и останется у него навсегда, а фактически он существует только пока действует чужая подписка.

Поэтому главное требование здесь не «всё обязательно оформлять только на клиента», а заранее понимать модель.

Что произойдёт после прекращения поддержки

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

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

Нормальный ответ может выглядеть так:

сайт продолжит работать, но прекратятся наша серверная поддержка и лицензия на такой-то сервис; для Elementor клиенту потребуется собственная подписка; ACF уже оформлен на клиента; домен, VPS, Git и аналитика остаются у компании.

Это прозрачная модель.

Плохой ответ:

всё будет нормально.

«Нормально» — плохое название лицензии.

Что делать, если сайт уже сделан и всё оформлено на разработчика

Паниковать и переносить всё за один вечер не нужно.

Сначала составляется inventory.

Что принадлежит компании.

Что находится в аккаунтах подрядчика.

Какие сервисы можно безболезненно передать.

Какие требуют новой подписки.

Какие доступы критичны.

Что может сломаться при отключении.

После этого зависимости убираются в безопасном порядке.

Например, сначала создаётся корпоративный аккаунт хостинга и только потом мигрируется production.

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

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

Домен — вообще отдельная операция, особенно после вступивших в силу 1 сентября 2026 года правил идентификации и передачи администрирования.

Если старый разработчик сотрудничает, такая нормализация обычно является не конфликтом, а обычным техническим handover.

Как принимать новый сайт, чтобы не разбирать это через два года

Проще всего заложить архитектуру владения ещё до разработки.

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

Потом разработчику выдаются права.

Исходный repository сразу размещается там, где он останется после окончания проекта.

Лицензионные компоненты фиксируются в реестре.

В договоре отделяются собственные результаты от сторонних.

В акте перечисляются фактически переданные материалы и доступы.

Перед финальным расчётом проводится контрольный handover.

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

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

Главное

Фраза:

«Мы купили сайт»

слишком короткая для цифровой инфраструктуры.

Можно иметь юридические права на кастомный код и не иметь Git.

Можно получить Git и не получить нужные права на оригинальный дизайн.

Можно контролировать WordPress, но не контролировать домен.

Можно иметь root, но не иметь аккаунта VPS.

Можно получить всю Figma и всё равно зависеть от агентской лицензии Elementor.

Можно забрать сайт на свой сервер, но оставить бывшего подрядчика подтверждённым владельцем Search Console и администратором GTM.

Поэтому вопрос «кому принадлежит сайт?» лучше заменить более практичным:

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

Если да, перед вами действительно самостоятельный цифровой актив бизнеса.

Если нет, не обязательно всё потеряно и не обязательно подрядчик сделал что-то незаконное.

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

право;

исходные материалы;

лицензия;

аккаунт;

восстановление;

инфраструктура.

Именно поэтому качественная передача сайта заканчивается не кнопкой «Опубликовать».

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