Вы заплатили за сайт, значит он ваш. Так это выглядит, и обычно никто не врёт.
Только «сайт» — не один предмет. Это семь отдельных вещей, у каждой свой аккаунт и своя процедура. И вопрос, к которому обычно всё сводят — «на кого оформлено?» — это неправильный вопрос. Большинство из них вполне практично держать тому, кто строит и обслуживает сайт, и чаще всего так и лучше.
Полезный вопрос другой: может ли это перейти к вам, каким образом и за сколько?
Это более короткий список и гораздо более конкретный разговор.
Две схемы, обе нормальные
На практике есть два типа клиентов, и неправ ни один.
Одни хотят, чтобы всё было централизовано у разработчика. Домен, хостинг, аккаунты — всё держит фирма, которая обслуживает сайт, платит за это из своего бюджета, а клиент оплачивает одним счётом вместе с поддержкой. Плюс настоящий: не надо следить за шестью продлениями на трёх картах, и ничего не отваливается из-за того, что карта истекла в феврале, а письмо-предупреждение никто не открыл.
Условие ровно одно, и его фиксируют письменно с самого начала: при уходе вы получаете всё, так, чтобы больше ни в чём от них не зависеть.
Другие хотят быть владельцами всего с первого дня и управлять каждым аккаунтом напрямую. Это ровно такой же нормальный выбор. Стоит чуть больше административного внимания, и только.
Что действительно важно — чтобы фирма, с которой вы работаете, была гибкой к обеим схемам. Та, что умеет работать только одним способом — либо «держим всё мы, иначе никак», либо «к вашим аккаунтам мы не притрагиваемся, разбирайтесь сами» — навязывает вам свою модель работы вместо той, которая подходит вам.
Список ниже работает одинаково в обоих случаях. Меняется только то, кто нажимает кнопки каждый день, а не то, что вы должны иметь возможность получить.
Семь пунктов
1. Домен
На практике удобнее всего, когда домен держит фирма, которая делает сайт. Они настраивают DNS, они ловят продление, они общаются с регистратором, когда надо что-то поменять. Домены, которые истекают, — это почти всегда домены, за которыми специально никто не следил.
Безопасной эту схему делает не то, что ключи у вас, а то, что передача домена другому владельцу — обычная операция, которая делается по запросу к регистратору, и делается каждый раз.
Как это происходит, в общих чертах
Есть две разные операции, которые часто путают:
- Смена владельца — домен остаётся у того же регистратора, меняется имя, записанное в реестре.
- Трансфер между регистраторами — владелец тот же, меняется компания, у которой домен обслуживается.
Вам может понадобиться одна, другая или обе.
Механизм в обоих случаях — код авторизации (он же код трансфера, auth code или EPP-код). Текущий владелец запрашивает его в своём кабинете у регистратора и передаёт. Принимающая сторона вводит его у себя, обе почты из карточки домена подтверждают. Всё.
- Для .md реестр — это nic.md, которым управляет Служба информационных технологий и кибербезопасности. Код авторизации запрашивается прямо из личного кабинета на nic.md, а процедура передачи другому владельцу выполняется онлайн.
- Для .com, .net, .org и остальных международных доменов: сначала домен
разблокируется (
unlock), дальше тот же код авторизации. Занимает несколько дней, не недель.
Единственное, что стоит запланировать: после некоторых изменений регистраторы отказывают в новом трансфере какое-то время — обычно 60 дней. Это не проблема, просто повод не менять подрядчика и регистратора на одной и той же неделе.
Что стоит оговорить заранее
Два предложения письменно: что передача делается по запросу и сколько она стоит. Правильная цена — это сбор регистратора плюс немного человеческого времени. Больше ничего.
Единственное, что здесь действительно важно
Домен должен быть оформлен на компанию, а не на личное имя кого-то из неё. Компания может подписать заявление на передачу и через четыре года. Сотрудник, который за это время ушёл и перестал брать трубку, — нет.
2. Хостинг
Та же логика. Сервер, который держит фирма, обслуживающая сайт, — нормальная схема и обычно лучше альтернативы: одна машина, которую они знают, обновляют, мониторят и на которую делают резервные копии, действительно проверенные.
А переезд на ваш сервер, если такой день настанет, — рутинная работа: код, база, файлы, одна DNS-запись. День, из которого большая часть — ожидание распространения.
Значит вопрос не «стоит ли оно на моём сервере». Вопрос — что там работает и воспроизводится ли это в другом месте. Если ответ «стандартная среда исполнения и стандартная база», вы свободны в любой момент. Если «наша платформа, которая больше нигде не ставится», вы купили другое — может быть, хорошее, но договор и цена должны говорить об этом прямо.
Важное исключение: приложения, сделанные на заказ. Собственная CRM, внутренняя ERP, софт, построенный специально под вашу компанию, действительно зависят от конкретного сервера и конкретной среды — они связаны с интеграциями, с фоновыми службами, с базой и с конфигурацией, продуманными вместе с приложением. Это не коммерческая привязка, это природа продукта.
Там вопрос меняется. Не «почему оно не работает где угодно», а задокументирована ли среда и можно ли поднять её заново: что работает, в каких версиях, с какими переменными и с каким объёмом работ. Хороший ответ описывает объём — в днях и шагах. «Больше нигде не заработает» техническим ответом не является.
Всё же спросите, на чьём аккаунте всё стоит и кто платит, чтобы не выяснять это в неподходящий день.
3. Код
Ваш в конце. Не обязательно по ходу — и причина законная.
В рабочей ветке лежат временные пароли, вписанные прямо в код для тестов, ключи, ведущие на тестовые аккаунты, наполовину перенесённые данные. Так быстрее всего проверять. Отдавать это в середине разработки — не прозрачность, а проблема безопасности и источник вопросов, на которые ни у кого нет времени отвечать.
Код работает на сервере — там он и живёт. Что должно быть дополнительно — копия в системе управления версиями, на практике Git, размещённой на внешней платформе: GitHub, GitLab, Bitbucket или собственный экземпляр вроде GitLab или Gitea.
Разница не формальная. Система версий хранит историю каждого изменения, позволяет вернуться к предыдущему состоянию за несколько минут и делает проект независимым от одной машины. Без неё «код» — это текущее содержимое каталога на сервере: без истории, без пути назад и без чего-либо для передачи, кроме архива.
Значит, оговаривается следующее: проект ведётся на такой платформе с самого начала, и при передаче вы получаете к нему доступ, целиком и вычищенным от временных значений.
Как проверить: спросите, на какой платформе управления версиями хранится код и с какого момента. Это технический вопрос, на который есть короткий и проверяемый ответ.
4. Платёжные аккаунты
Договор с банком или платёжным провайдером должен быть на вашу компанию, и деньги должны приходить на ваш счёт. Здесь обычно всё в порядке, потому что банк всё равно требует документы фирмы.
Чаще упускают доступ в кабинет мерчанта — тот, где видны транзакции и делаются возвраты. Бывает, что он остаётся только у разработчика, причём никто такого решения не принимал.
5. Аккаунты измерений
Google Analytics, Search Console, профиль компании, рекламный кабинет.
Их заводят быстро, часто на почту того, кто делает работу, и там они и остаются. Доступ выдаётся легко; не восстанавливается история, если аккаунт придётся создавать заново. Два года данных не возвращаются.
Как проверить: зайдите в каждый и посмотрите, кто владелец, а не у кого есть доступ.
6. Контент
Тексты, фотографии, иллюстрации.
Если фотографии куплены в стоке, лицензия оформлена на кого-то и у неё есть условия. Стоит знать, на кого и какие, особенно если те же снимки понадобятся в буклете или на билборде.
7. Как это запускается
Документ о том, как ставится проект, какие переменные окружения нужны, как выкатывается новая версия. Самая дешёвая вещь, если делать её вовремя, и самая дорогая, если восстанавливать через два года.
Тревожные сигналы
Не «домен держим мы» — это нормальная ситуация. А вот пять других вещей стоят разговора:
- «Передать нельзя» — или ответ, который не может объяснить, как это делается. Это обычная процедура у регистратора. Сигнал не в том, что домен держат они, а в том, что никто не может описать следующий шаг.
- Передача, выставленная как штраф. Переезд — это несколько часов работы и сбор регистратора. Цифра, похожая на выкуп, описывает отношения, а не работу.
- Домен на имя человека, а не компании. Единственный настоящий риск во всей этой статье.
- Код, который работает только на их инфраструктуре — для обычного сайта или магазина. Вот это настоящая зависимость, и это совсем не то же самое, что «пока что сервер их». Исключение — то, что описано в пункте 2: приложение на заказ законно зависит от своей среды, и спрашивать там нужно документацию среды, а не переносимость.
- Только одна возможная схема. Если вы не можете выбрать между «держите всё вы» и «хочу аккаунты на свою компанию», выбор сделали за вас.
Как выглядит полная передача
Одно сообщение, семь пунктов, к каждому ссылка или доказательство:
- Домен — владелец ваша компания либо подтверждённая передача по запросу, с описанной процедурой
- Хостинг — аккаунт, панель, кто платит, что там работает
- Код — доступ к платформе управления версиями, временные значения убраны
- Платежи — договор на вашу компанию, доступ в кабинет мерчанта
- Измерения — владелец ваша компания в каждом аккаунте
- Контент — что куплено и по какой лицензии
- Запуск — документ по установке
Список полезен и до подписания, вместе с остальным, что стоит спросить при выборе исполнителя.
Ответ на вопрос из заголовка скучнее, чем кажется. Сайт ваш с того момента, как каждая из семи вещей может перейти к вам по запросу — а не с того момента, как ключи оказались у вас в руках. У того, кто строит и обслуживает, обычно есть хорошие причины их держать. Чего хорошей причины нет — это не мочь объяснить, как они передаются дальше.