Кому на самом деле принадлежит ваш сайт: домен, хостинг, лицензии и доступы

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

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

В такой ситуации вопрос «Кому принадлежит сайт?» не имеет одного ответа. Сайт — это не единый объект, который можно передать одной кнопкой. Это набор связанных активов, договорных прав, аккаунтов и технических доступов. Каждый из них нужно проверять отдельно.

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

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

Короткий ответ: кто должен контролировать сайт

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

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

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

Сайт состоит из нескольких независимых активов

Для начала полезно отказаться от представления, что «сайт» — это только страницы, которые видит посетитель.

Часть сайта	Что даёт фактический контроль	Что должно быть у бизнеса
Домен	Право управлять регистрацией и продлением	Статус администратора или registrant, кабинет регистратора, доступ к контактной почте
DNS	Возможность направить домен на нужный сервер и управлять почтой	Доступ к DNS-зоне и понимание, где она обслуживается
Хостинг или облако	Возможность запускать, переносить и восстанавливать сайт	Аккаунт владельца, биллинг, панель управления, данные договора
CMS	Управление содержимым и настройками	Отдельная учётная запись администратора
Файлы и база данных	Полная рабочая копия сайта	Доступ к файлам, базе, конфигурации и выгрузке
Исходный код	Возможность развивать нестандартные функции	Репозиторий, документация, история версий, права по договору
Дизайн и контент	Законное использование и изменение материалов	Зафиксированные исключительные права или достаточная лицензия
Плагины, темы, шрифты	Законность использования, обновления и поддержка	Перечень лицензий, владельцы аккаунтов, даты продления
Аналитика и реклама	Данные и накопленная история	Роль владельца или администратора в корпоративном аккаунте
Резервные копии	Восстановление после ошибки или конфликта	Копии в независимом от подрядчика хранилище и проверенная процедура восстановления

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

1. Домен: самая важная точка контроля

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

Кто считается администратором домена

Для доменов .RU и .РФ решающим является не тот, кто оплатил счёт, и не тот, чьё название размещено в футере. Координационный центр доменов .RU/.РФ определяет администратора доменного имени как физическое или юридическое лицо, на которое домен зарегистрирован. Именно администратору принадлежат права и обязанности, связанные с использованием домена.

Для международных доменных зон используется близкое понятие registrant, или registered name holder. ICANN рекомендует владельцам регистрации знать своего регистратора, условия продления, восстановления и переноса домена. Для переноса между регистраторами обычно требуется Auth-Code, который регистратор предоставляет держателю регистрации по установленной процедуре. Подробнее это описано в памятке ICANN о переносе доменов.

Это означает, что ни один из следующих фактов сам по себе не подтверждает контроль бизнеса над доменом:

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

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

Как должен быть оформлен домен

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

В аккаунте стоит настроить:

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

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

Что делать, если домен оформлен на подрядчика

Не начинайте с резкой смены паролей или конфликта. Сначала зафиксируйте текущее состояние: регистратора, дату окончания регистрации, администратора, DNS-серверы, контактные данные и связанные договоры. Затем согласуйте смену администратора или registrant и только после этого — передачу аккаунта либо перенос к другому регистратору.

Процедура зависит от доменной зоны и правил конкретного регистратора. Для части международных доменов после изменения данных registrant может действовать 60-дневное ограничение на перенос. ICANN отдельно предупреждает об этом в разъяснении о смене держателя регистрации. Поэтому последовательность действий лучше определить заранее, особенно если одновременно меняются регистратор, владелец и DNS.

2. DNS: доступ, о котором часто забывают

DNS связывает домен с сайтом, почтой и другими сервисами. Через DNS-записи можно:

• направить сайт на другой сервер;
• подключить или отключить корпоративную почту;
• подтвердить домен для Google Search Console и других платформ;
• настроить поддомены;
• управлять защитой и доставляемостью почты;
• подтвердить право использования некоторых облачных сервисов.

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

Бизнесу нужно знать:

1. Где размещена DNS-зона: у регистратора, хостинга, CDN или отдельного провайдера.
2. Кто является владельцем этого аккаунта.
3. Какие пользователи имеют право редактировать записи.
4. Есть ли сохранённый экспорт или документированный список записей.
5. Как восстановить доступ, если основной администратор недоступен.

Перед сменой подрядчика не стоит переносить DNS «для порядка», если в этом нет необходимости. Ошибка в одной записи может отключить сайт, почту или подтверждение стороннего сервиса. Сначала нужно сохранить текущую конфигурацию и понять назначение каждой записи.

3. Хостинг: кто заключил договор и кто может забрать сайт

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

Здесь важно различать три вещи:

• кто указан клиентом в договоре или профиле;
• кто оплачивает услугу;
• у кого есть технический доступ.

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

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

Что проверить по хостингу

• На кого оформлен аккаунт и можно ли изменить его владельца.
• Есть ли у бизнеса полный доступ к панели управления.
• Можно ли отдельно выгрузить файлы и базу данных.
• Кто контролирует SFTP/SSH, базу данных и серверные настройки.
• Где находятся резервные копии и как долго они хранятся.
• Какие ещё сайты расположены в том же аккаунте.
• Кто получает уведомления об оплате, превышении лимитов и технических проблемах.
• Можно ли перенести сайт к другому провайдеру и что входит в процедуру передачи.

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

4. Админка WordPress — это ещё не весь сайт

Учётная запись администратора WordPress позволяет менять страницы, устанавливать плагины и управлять пользователями. Но она не гарантирует доступ:

• к аккаунту регистратора;
• к DNS;
• к хостингу;
• к файлам вне CMS;
• к базе данных напрямую;
• к серверным журналам и настройкам;
• к резервным копиям провайдера;
• к репозиторию с исходным кодом;
• к платным лицензиям;
• к аналитике и рекламным системам.

Более того, WordPress-администратор может потерять доступ после переноса, ошибки в базе или конфликта плагинов. Для восстановления тогда потребуется хостинг или сервер.

Для обычного WordPress-сайта при передаче проекта бизнесу обычно нужны:

• собственная учётная запись администратора CMS;
• доступ к панели хостинга;
• SFTP или другой согласованный доступ к файлам;
• возможность получить дамп базы данных;
• рабочая полная резервная копия;
• список нестандартных настроек, cron-задач и внешних интеграций;
• репозиторий с кастомной темой или плагинами, если он использовался в разработке.

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

5. Файлы сайта, исходный код и резервная копия — не одно и то же

Фраза «мы передали сайт архивом» может означать очень разные вещи.

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

Полный набор зависит от проекта, но обычно включает:

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

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

6. Авторские права: оплата разработки не всегда отвечает на все вопросы

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

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

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

Если заказ заключается непосредственно с автором, применяется статья 1288 ГК РФ. Договор авторского заказа может предусматривать либо отчуждение исключительного права, либо предоставление права использования в определённых пределах. Поэтому формулировка договора и статус исполнителя имеют значение.

На практике сайт может включать много разных объектов:

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

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

Что стоит закрепить в договоре

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

Если сайт уже создан, а договор ограничивается одной строкой «разработка сайта», не стоит пытаться самостоятельно сделать окончательный юридический вывод. Лучше составить перечень реально созданных материалов и проверить документы по каждому существенному объекту.

7. Лицензии на темы и плагины: сайт может работать, но перестать обновляться

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

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

Например, WooCommerce объясняет, что подключение магазина к аккаунту WooCommerce.com используется для установки расширений, получения обновлений и поддержки. Подписки можно назначать сайтам, продлевать, передавать или делиться ими в предусмотренных сервисом режимах. Это видно в документации Woo Marketplace.

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

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

Для каждой платной лицензии зафиксируйте

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

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

8. Аналитика, реклама и внешние сервисы тоже являются активами

За несколько лет Google Analytics, Search Console, рекламные кабинеты и CRM накапливают историю, аудитории, цели, конверсии и настройки. Иногда эти данные ценнее исходного дизайна сайта.

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

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

Что проверить

• Google Analytics и Google Tag Manager;
• Google Search Console;
• Яндекс Метрику и Вебмастер;
• рекламные кабинеты и пиксели;
• CRM и системы коллтрекинга;
• сервисы рассылки и транзакционных писем;
• карты, чаты, виджеты отзывов и формы;
• платёжные системы и онлайн-кассу;
• аккаунты доставки и товарные фиды;
• CDN, защита от атак и мониторинг доступности;
• корпоративную почту;
• репозиторий кода и облачное хранилище документации.

В Google Analytics добавлять и изменять пользователей может только пользователь с ролью Administrator на соответствующем уровне — это прямо указано в справке Google Analytics. В Search Console подтверждённый владелец имеет максимальные разрешения, а Google рекомендует использовать несколько методов подтверждения, чтобы не потерять доступ при удалении одного токена. Подробности приведены в руководстве Search Console.

Практический вывод: отчёт в PDF от агентства не заменяет роль администратора в самом сервисе.

9. Почему один общий логин — плохая идея

Иногда компания и подрядчик используют одну пару логин-пароль «admin». Это кажется удобным, но создаёт сразу несколько проблем:

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

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

После завершения сотрудничества нужно:

1. Убедиться, что у бизнеса есть рабочая учётная запись владельца и собственные администраторы.
2. Создать свежую резервную копию.
3. Проверить контактную почту и способы восстановления.
4. Передать необходимые лицензии и сервисы.
5. Отозвать персональные учётные записи бывшего подрядчика.
6. Сменить общие пароли, если они когда-либо использовались.
7. Обновить ключи API и токены, которые были доступны внешней команде.
8. Проверить задачи автоматизации, вебхуки и интеграции.

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

10. Три модели работы с подрядчиком

Модель 1. Всё оформлено на клиента

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

Плюсы:

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

Минусы:

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

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

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

Плюсы:

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

Минусы:

• выше зависимость от поставщика;
• не все аккаунты и лицензии можно передать;
• условия выхода нужно согласовать заранее.

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

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

Домен, хостинг, аналитика, лицензии и резервные копии оформлены на одного специалиста, а у клиента есть только доступ к админке.

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

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

11. Как проверить контроль над сайтом за один аудит

Шаг 1. Составьте карту активов

Запишите все элементы: домен, DNS, хостинг, CMS, база данных, репозиторий, резервные копии, почта, аналитика, реклама, CRM, платежи, доставка, лицензии и интеграции.

Для каждого элемента укажите:

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

Шаг 2. Проверьте доступ на практике

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

Шаг 3. Сопоставьте техническую карту с договором

Проверьте, совпадает ли фактическая схема с обещанной:

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

Шаг 4. Проведите тест передачи

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

• получить Auth-Code или инициировать нужную процедуру для домена;
• экспортировать DNS-записи;
• скачать файлы и базу;
• открыть резервную копию;
• назначить нового администратора в аналитике;
• получить исходники кастомной разработки;
• увидеть список лицензий и их сроки.

Шаг 5. Закройте критические разрывы

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

12. Чек-лист при приёмке нового сайта

Перед финальным расчётом или подписанием акта проверьте, что получены:

Домен и инфраструктура

• домен зарегистрирован на согласованное лицо;
• корпоративная почта указана как контактная;
• доступен кабинет регистратора;
• известно местонахождение DNS;
• передан аккаунт хостинга или зафиксированы условия управляемого размещения;
• настроены уведомления о продлении и оплате.

Сайт и данные

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

Права и лицензии

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

Сервисы и доступы

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

Документация

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

Что делать, если вы обнаружили проблему

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

Критический риск

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

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

Управляемый риск

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

Организационный недостаток

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

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

Частые вопросы

Если мы полностью оплатили сайт, он автоматически наш?

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

Подрядчик может оставить сайт на своём хостинге?

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

Обязан ли разработчик передать исходники?

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

Можно ли продолжать использовать платный плагин после ухода агентства?

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

Достаточно ли иметь администратора WordPress?

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

Можно ли передать подрядчику пароль от основного аккаунта?

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

Как часто проводить аудит доступов?

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

Настоящее владение сайтом — это возможность продолжать работу

Владение сайтом определяется не количеством паролей и не строкой в футере. Бизнес действительно контролирует цифровой актив, если может:

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

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

Если вы не уверены, кто контролирует отдельные части вашего сайта, начните не с переноса, а с технической карты. Аудит домена, хостинга, WordPress, лицензий, аналитики и резервных копий обычно быстро показывает, где есть реальный риск, а где достаточно просто оформить существующую рабочую схему.