Содержание
Сайт открывается, форма отправляется, счёт оплачен. Через полгода нужно продлить домен – и выясняется, что кабинет зарегистрирован на почту исполнителя. Ещё через месяц требуется изменить цену, но исходники лежат на старом ноутбуке. Сам сайт при этом всё это время честно считался «переданным».
У владельца должны остаться собственные права на домен, хостинг и ключевые сервисы; исходники, данные и рабочая резервная копия; список платных зависимостей; короткая инструкция по обычным изменениям и аварии. Передача закончена не тогда, когда прислали пароли, а когда владелец сам проходит один контрольный маршрут.
Небольшому сайту не нужна папка на двести страниц. Часто хватает одного реестра, защищённого хранилища доступов, архива или репозитория и инструкции на две страницы. Важен не вес передачи, а возможность продолжить работу без археологии в переписке.

Запуск не равен передаче сайта
Передача начинается с простого различия. Рабочий доступ позволяет зайти и что-то сделать. Владение позволяет выдавать и отзывать права, менять платёжные данные, восстанавливать аккаунт и назначать нового исполнителя. Аварийный доступ нужен, когда обычный вход потерян или основной человек недоступен.
Если владелец знает пароль от кабинета разработчика, это не превращает аккаунт в актив бизнеса. Пароль могут сменить, восстановление уйдёт на чужую почту, а двухфакторный код – на чужой телефон. Общие учётные записи ещё и не показывают, кто именно менял настройки. Хорошая передача оставляет бизнесу собственную роль владельца, а специалисту – отдельную рабочую роль с необходимыми правами.
Не всякий сервис поддерживает идеальную систему ролей. Тогда хотя бы email восстановления, телефон, резервные коды и плательщик должны быть известны и контролироваться компанией. Это скучная часть запуска. Скука здесь – отличный признак: авария перестаёт быть квестом.
Что здесь важно: проверяйте не наличие логина, а право восстановить аккаунт, изменить оплату и отозвать доступ исполнителя.

Начните с домена, хостинга и ключевых свойств
Домен. У владельца должны быть данные регистратора, имя регистранта, срок продления, способ оплаты, доступ к DNS и восстановлению. ICANN описывает регистранта как человека или организацию, которая заключает договор с регистратором и управляет настройками имени через него. Это не проверяет конкретную запись вашего домена, но даёт правильный вопрос: кто указан стороной отношений и кто способен управлять именем без посредника?
Хостинг и инфраструктура. Нужны владелец аккаунта, плательщик, тариф, срок, регион размещения, способ войти в панель, DNS-записи, сертификат и понятный перечень того, что исчезнет при прекращении оплаты. Для виртуального сервера добавляются доступ администратора, способ обновления, firewall, службы и место резервных копий. Секреты не стоит складывать в обычный документ: в реестре достаточно указать, где они хранятся и кто может восстановить доступ.
Сервисы вокруг сайта. CMS, репозиторий, CDN, почта домена, формы, CRM, аналитика, карты, шрифты, платежи и внешние виджеты могут иметь собственных владельцев и счета. Например, в Search Console только владелец может добавлять и удалять пользователей, а свойство должно иметь хотя бы одного подтверждённого владельца. Поэтому приглашение «полного пользователя» полезно для работы, но не заменяет контроль бизнеса.
Практический вывод: заведите таблицу «сервис → назначение → владелец → рабочие пользователи → продление → восстановление». Пароли храните отдельно.

Какие файлы должны остаться у владельца
Для статического сайта комплект обычно включает исходный код, собранную версию, изображения и шрифты с понятными лицензиями, конфигурацию сборки и перечень переменных окружения без раскрытия секретов. Для CMS добавляются экспорт базы, загруженные медиа, список тем и плагинов, их версии и способ получить законные обновления. Для проекта с интеграциями нужна карта обмена между системами: откуда приходят данные, куда уходят автоматические уведомления, что обрабатывается с задержкой и в каких внешних кабинетах находятся настройки.
Репозиторий удобнее случайного ZIP: он хранит историю и позволяет понять, какая версия была запущена. GitHub отдельно указывает, что mirror clone включает файлы и историю, но Git LFS-объекты нужно выгружать отдельно. И даже полный Git-архив не обязан содержать базу данных, пользовательские загрузки, секреты или настройки внешних сервисов. Поэтому фраза «всё в репозитории» должна раскрываться перечнем.
Отдельно зафиксируйте права на дизайн, тексты, фотографии, шрифты, плагины и другие лицензируемые компоненты. Эта статья не определяет, кому принадлежат исключительные права: ответ лежит в договоре и условиях конкретных лицензий. Практический критерий проще – владелец понимает, что он может менять, переносить и продлевать, а что потребует новой лицензии или согласования.
Промежуточный итог: комплект считается описанным, когда у каждого слоя – код, данные, медиа, конфигурация и лицензии – есть явное место и способ восстановления.

Резервная копия ценна после пробного восстановления
Спросите не только «делаются ли бэкапы», а где они лежат, что включают, как часто создаются, сколько хранятся и кто получает уведомление об ошибке. Копия на том же сервере помогает после неудачного обновления, но может исчезнуть вместе с сервером или аккаунтом. Вторая независимая точка хранения уменьшает этот риск.
Самая важная проверка – восстановить последнюю копию на отдельном домене или локальном контуре, не затрагивая рабочий сайт. Открыть несколько страниц, изображения, форму в тестовом режиме и административный вход. Сверить дату данных. После проверки временный контур безопасно закрыть и удалить тестовые персональные данные, если они там появились.
Такой тест не доказывает, что восстановление всегда пройдёт за одинаковое время и что в backup нет скрытых проблем. Он доказывает более узкую и полезную вещь: конкретная копия на конкретную дату читается, а инструкция не обрывается на третьем шаге.
Практический вывод: приёмка backup – это зафиксированные дата, состав, место хранения и один успешный пробный подъём вне production.

Инструкция должна отвечать на три будущих события
Обычное изменение. Где поменять текст, цену, фотографию и контакт; как увидеть результат до публикации; как вернуть предыдущую версию. Если владельцу не нужен самостоятельный редактор, это нормально – тогда инструкция называет исполнителя, срок реакции и способ передать задачу.
Плановое обслуживание. Что и когда продлевается, кто получает счета, как обновляются CMS и зависимости, кто проверяет форму, сертификат и резервные копии. У полезной инструкции есть даты и ответственные, а не фраза «следить за актуальностью».
Авария или смена исполнителя. Где посмотреть статус домена и сервера, как временно остановить сбор данных, кому сообщить, где последняя проверенная копия и как выдать новому специалисту отдельный доступ. Не нужно учить владельца администрировать Linux за вечер. Нужно убрать единственную точку знания.
Добавьте схему из пяти строк: домен ведёт на DNS, DNS – на хостинг, сайт собирается из такого-то источника, формы уходят туда-то, резервные копии лежат там-то. Это достаточно конкретно, чтобы новый специалист начал с фактов, но не превращает документ в публичную карту секретов.
Что здесь важно: хорошая инструкция переживает отпуск автора и не содержит сами пароли там, где её пересылают по почте.

Передача закончена, когда владелец проходит маршрут сам
Откройте новое устройство или отдельный профиль браузера. Не используйте сохранённую сессию разработчика. Войдите в домен, хостинг, репозиторий или CMS, Search Console и другие ключевые свойства через собственные роли. Проверьте восстановление доступа и наличие резервных кодов. Найдите последний счёт и дату продления.
Затем скачайте или клонируйте комплект, сверьте его состав с реестром и попросите показать успешное восстановление на отдельном контуре. Наконец, выполните одно безопасное изменение: например, исправьте тестовую строку на непубличной версии и верните её обратно. По каждому шагу фиксируйте не впечатление «вроде есть», а наблюдаемый результат и недостающее действие.
Для простой страницы без CMS и интеграций пакет будет коротким. Не нужно покупать сложную инфраструктуру ради чувства серьёзности. Но домен, место публикации, исходник, независимая копия и способ обновить страницу всё равно должны иметь владельца.
Главный вывод: у владельца остаются не россыпь паролей, а управляемая система: права, комплект, восстановление и инструкция, проверенные одним независимым проходом.
Частые вопросы о передаче сайта владельцу
Достаточно получить архив сайта и пароли?
Нет. Нужно проверить, что архив восстанавливается, учётные записи принадлежат владельцу, а инструкции позволяют выполнить обычные действия без обязательного участия прежнего исполнителя.
Может ли подрядчик сохранить доступ?
Да, если это осознанное разрешение владельца для поддержки. Важно, чтобы этот доступ можно было изменить или отозвать, а подрядчик не оставался единственным способом управления.
Какая инструкция действительно полезна?
Та, которая отвечает на будущие события: как изменить информацию, восстановить сайт после сбоя, продлить ключевые услуги и передать работу другому специалисту.
Когда передачу можно считать законченной?
Когда владелец самостоятельно входит в основные сервисы, находит актуальные файлы и копии, выполняет безопасное изменение и понимает путь восстановления.
Кто должен пройти финальную проверку передачи?
Сам владелец или назначенный им человек: войти в ключевые сервисы, найти резервную копию, открыть инструкцию и понять, кому обращаться при сбое.
Инструкции по ключевым контурам
Эти первоисточники помогают отдельно проверить владение доменом, доступ к поисковым данным и резервную копию исходного кода.
- Права и обязанности владельца доменаКто считается регистрантом и какие отношения связывают его с регистратором.ICANN ↗
- Управление владельцами Search ConsoleКак проверяются и меняются права людей, имеющих доступ к данным сайта.Google Search Console ↗
- Резервная копия репозиторияЧто сохраняет зеркальная копия и почему наличие архива ещё нужно проверять восстановлением.GitHub Docs ↗
- Кто обновляет сайт после запуска, чтобы цены, условия и кейсы не устаревали?Практический разбор: как назначить владельцев фактов, порядок изменений и регулярную проверку содержания сайта.Прочитать разбор ↗
- AI собрал сайт: как проверить, что перед вами не ссылка на чужую песочницуГотовый экран в AI-сервисе ещё не доказывает, что владелец может сам управлять сайтом, продолжить работу и передать её другому специалисту.Прочитать разбор ↗