Доступы к сайту у владельца бизнеса: чек-лист на 2026 год

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

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

Когда домен зарегистрирован на аккаунт разработчика, а хостинг оплачивается с его карты, юридически сайт вам не принадлежит - вы им просто пользуетесь, пока с исполнителем хорошие отношения. Я видел три похожих кейса за последний год: в одном домен просрочили, потому что бывший подрядчик не продлил оплату и не предупредил, сайт упал на 4 дня в разгар распродажи. В другом собственник хотел сменить студию поддержки, но получил отказ передавать доступы под предлогом «еще не все доработки закрыты» - фактически сайт держали в заложниках.
Проблема решается один раз: все ключевые сервисы регистрируются на почту и юрлицо владельца, а подрядчик получает права как приглашенный пользователь с возможностью их отозвать в любой момент.

Домен и DNS - фундамент, который чаще всего упускают

Домен должен быть зарегистрирован на владельца бизнеса напрямую у регистратора (reg.ru, timeweb, nic.ru), а не через панель управления подрядчика. Проверить легко: зайти на сайт регистратора, ввести домен через whois и посмотреть, кто указан администратором.
Что обязательно нужно контролировать:

• логин и пароль от личного кабинета регистратора, привязанные к почте владельца;
• доступ к управлению DNS-записями - это критично для настройки почты, интеграций с CRM и подключения поддоменов;
• дату продления домена и способ оплаты - лучше привязать карту компании, а не личную карту сотрудника;
• доступ к трансфер-коду (EPP-код) на случай переноса домена к другому регистратору.

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

Хостинг, сервер и панель управления

Второй критичный блок - доступы к серверу, на котором физически лежит сайт. Для сайтов на WordPress это обычно хостинг-панель (cPanel, ISPmanager) плюс FTP или SSH-доступ, для проектов на Tilda - личный кабинет платформы, для кастомных веб-сервисов - доступ к облачному провайдеру (VPS, Timeweb Cloud, Selectel) и панели деплоя.
Минимальный набор, который должен быть у владельца:

• логин и пароль от хостинг-панели или облачной консоли;
• доступ к базе данных (для WordPress это отдельный логин phpMyAdmin);
• FTP/SFTP или SSH-ключи для доступа к файлам сайта;
• данные о тарифе и дате продления хостинга.

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

Административная панель CMS: WordPress, Tilda и кастомные сервисы

Доступ в саму систему управления сайтом - то, с чем сталкивается владелец чаще всего в повседневной работе: правка текстов, добавление товаров, публикация акций.

Отдельно замечу по Tilda: платформа удобна тем, что не требует хостинга, но все доработки - кастомные скрипты, интеграции с оплатой или доставкой - обычно живут в HTML-блоках самого проекта. Если их писал сторонний разработчик под NDA или без документации, разобраться в них следующему исполнителю бывает сложнее, чем написать заново. Я обычно оставляю клиенту комментарии в коде и краткое описание, что за что отвечает.

Платежные системы, CRM и доставка

Это блок, где цена ошибки выше всего, потому что через него идут деньги клиентов. Доступ к личному кабинету эквайринга (T‑Bank, Сбербанк, ЮKassa) должен быть оформлен на юрлицо владельца - иначе при смене подрядчика можно потерять историю платежей и настройки фискализации. На практике для интернет-магазинов на WooCommerce я подключаю эквайринг T‑Bank напрямую к аккаунту клиента и только потом настраиваю плагин - так владелец сразу видит все транзакции в своем личном кабинете банка, а не через посредника.
То же самое касается:

• CRM-системы (amoCRM, Bitrix24) - доступ администратора должен быть у собственника, права сотрудников и подрядчиков настраиваются отдельно;
• личного кабинета СДЭК или другой службы доставки, если на сайте настроен расчет стоимости и трек-номеров;
• Telegram-бота, если через него идут заявки или оплата - токен бота и доступ к серверу, где он развернут, должны быть задокументированы, иначе после ухода разработчика бот просто перестанет отвечать;
• сценариев автоматизации в n8n, если через них построена цепочка «заявка с сайта → CRM → уведомление в Telegram» - доступ к воркфлоу нужен, чтобы не переписывать логику с нуля при смене исполнителя.

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

Аналитика, почта и социальные сети

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

• Яндекс Метрика и Google Analytics - доступ администратора, а не только «просмотр отчетов»;
• Яндекс Вебмастер и Google Search Console - без них нельзя отследить индексацию и технические ошибки;
• корпоративная почта на домене компании - если ящики регистрировал подрядчик на свою почту-администратор, после разрыва отношений можно потерять доступ ко всей переписке;
• аккаунты в соцсетях и мессенджерах, привязанные к сайту через виджеты обратной связи или чат-боты.

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

Как правильно хранить и передавать доступы

Хранить пароли в переписке с фрилансером или в файле «пароли.txt» на рабочем столе - плохая идея с точки зрения безопасности и учета. На практике для клиентов работает простая схема:

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

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

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

Что делать, если сайт уже сделан, а доступов у меня нет?

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

Может ли подрядчик отказаться передавать доступы после оплаты работ?

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

Нужно ли давать доступы штатному маркетологу или таргетологу?

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

Как часто нужно проверять, что все доступы актуальны?

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