Передача сайта от старого подрядчика: чек-лист доступов

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

Когда владелец решает поменять подрядчика, чаще всего всё идёт по схеме: пишут в Telegram «пришлите доступы», в ответ прилетает скриншот с логином-паролем от админки, и вроде бы передача состоялась. А через неделю выясняется, что регистратор домена остался у старого подрядчика, бэкапы лежат на его личном Яндекс.Диске, а почта info@example.ru ходит через его SMTP. И начинается цирк.

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

Почему это вообще проблема

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

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

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

Принцип очерёдности

Доступы делятся на три приоритета.

Первая очередь — то, без чего сайт просто перестаёт работать или принадлежать вам. Сюда домен у регистратора, хостинг, доступ к ядру (FTP/SSH), база данных, админка CMS. Без этого нельзя даже починить простой баг, не говоря о переезде.

Вторая очередь — то, без чего сайт работает, но теряет функции. Метрика, GSC, Я.Вебмастер, корпоративная почта, CRM, SMS-агрегаторы, платёжные шлюзы.

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

Передача без хотя бы первой и второй очереди — это не передача, это иллюзия передачи.

Доступы первой очереди

Домен у регистратора

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

Что забрать: — Логин и пароль личного кабинета регистратора (reg.ru, RU-CENTER, nic.ru, Beget, Timeweb, любой другой). — Привязка домена к контактному лицу. Должна быть на вас или вашу компанию, не на подрядчика. — Доступ к управлению NS-серверами и DNS-записями. — Доступ к настройке TLS/SSL-сертификата у регистратора, если он там выпускался.

Как проверить, что доступ реальный: 1. Войдите в личный кабинет с указанными кредами. 2. Откройте детали домена, посмотрите дату оплаты, NS-серверы, статус. 3. Сделайте whois example.ru и сверьте, что данные администратора совпадают с вашими данными. 4. Попробуйте инициировать смену DNS-записи (например, добавить TXT-запись test) и удалить её. Если кнопка «сохранить» работает — доступ полный.

Если домен оказался зарегистрирован на подрядчика, а не на вас — надо инициировать передачу прав. У RU-CENTER это процедура с заявлением, у reg.ru проще через тикет, у некоторых нужен нотариус. Готовьтесь к тому, что займёт 2-4 недели и потребует подтверждающих документов на компанию.

Хостинг

Аналогично домену, но менее критично с точки зрения юр. собственности (если что, можно перенести на новый хостинг).

Что забрать: — Логин и пароль личного кабинета хостинга. — Доступ к панели управления (cPanel, ISPmanager, Plesk, кастомная панель). — Тариф и срок оплаты. — Список включённых услуг (бэкапы, SSL, дополнительные базы, дополнительные FTP-аккаунты).

Как проверить: 1. Войдите в кабинет. 2. Найдите ваш сайт в списке хостингов. 3. Откройте панель и попробуйте создать тестовый файл test.txt через файловый менеджер. Удалите его. 4. Проверьте, есть ли активные подписки и когда следующее списание.

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

FTP, SSH, файловая система

Доступ к самим файлам сайта.

Что забрать: — FTP-доступ: хост, порт, логин, пароль, тип (FTP/SFTP/FTPS). — SSH-доступ: хост, порт, логин, пароль или SSH-ключ. — Путь к корню сайта (обычно public_html, www, htdocs, иногда нестандартное).

Как проверить:

# FTPS
curl -k --ftp-ssl ftp://example.com:21/ --user login:password

# SSH
ssh -p 22 user@example.com 'pwd && ls -la'

Должны увидеть листинг файлов вашего сайта. Если возвращается ошибка авторизации — кред неверный, требуйте свежий.

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

База данных

Это отдельный доступ, не равный доступу к хостингу.

Что забрать: — Хост БД (часто localhost, но бывает и удалённый сервер). — Имя базы. — Логин и пароль пользователя БД. — Доступ к phpMyAdmin или Adminer через веб-панель.

Как проверить:

mysql -h localhost -u dbuser -p dbname -e "SHOW TABLES;"

Должны увидеть список таблиц вашего сайта. Если получаете Access denied — кред не работает.

Где обычно хранится этот кред: в WordPress в wp-config.php, в Битрикс в bitrix/.settings.php и bitrix/php_interface/dbconn.php, в OpenCart в config.php. Если у вас уже есть FTP-доступ, можно подсмотреть.

Админка CMS

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

Что забрать: — URL админки (wp-admin, bitrix/admin, admin.php, кастомный путь). — Логин и пароль администратора с ролью супер-админа или эквивалентом. — Список всех пользователей с правами администратора (чтобы потом удалить лишних). — Двухфакторная аутентификация: настроена ли, на какой телефон.

Как проверить: 1. Войдите в админку. 2. Откройте список пользователей. 3. Убедитесь, что у вашего аккаунта максимальные права (Administrator, Superuser, Главный администратор). 4. Создайте тестовый пост (черновик) и удалите его. Если всё работает — права полные.

После того как доступ ваш, обязательно: удалите старого администратора-подрядчика, или хотя бы понизьте его до Subscriber/Гостя, или смените ему пароль (но лучше первое). Иначе он остаётся со всеми правами.

Доступы второй очереди

Аналитика: Метрика, GSC, Я.Вебмастер

Что забрать: — Доступ владельца к счётчику Я.Метрики, к свойству GSC, к сайту в Я.Вебмастере. — Не «представитель» и не «наблюдатель», а именно владелец. — Доступ к Google Tag Manager, если используется.

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

Как сделать: — В Я.Метрике: «Настройка» -> «Доступ» -> «Разделение прав», добавить ваш Яндекс.ID как «владельца». Старый владелец в этот момент должен подтвердить, потом он сам себя удалит или вы его. — В GSC: Настройки -> Пользователи и разрешения -> Добавить пользователя с правом «Владелец» (через DNS-верификацию или meta-тег). — В Я.Вебмастере: аналогично, через «Подтверждение прав» в админке.

Если старый подрядчик не подтверждает или пропал, а сайт уже у вас по DNS — можно просто пере-верифицировать GSC и Вебмастер, добавив свой DNS TXT или HTML-файл в корень сайта. История счётчика при этом останется доступна, а владельцем станете вы.

Корпоративная почта

Этот пункт владельцы регулярно забывают, и потом удивляются, почему info@example.ru перестала работать через месяц после расставания.

Что забрать: — Доступ к панели управления почтой (Я.Почта для домена, Mail.ru для бизнеса, собственный SMTP на хостинге). — Список всех почтовых ящиков на домене. — Пароли от ящиков или возможность их сменить. — MX-записи в DNS, кто их настраивал и куда они смотрят.

Как проверить:

dig example.ru MX +short

Видите запись типа 10 mx.yandex.net. — почта настроена на Я.Почта для домена. mx.mail.ru. — на Mail.ru. Что-то другое — либо собственный сервер на хостинге, либо стороннее решение.

Войдите в админку соответствующего сервиса. В Я.Почте для домена это connect.yandex.ru. Если вас там нет в роли владельца — попросите подрядчика добавить или переоформить.

CRM, SMS-агрегаторы, платежи

Если на сайте подключены сторонние сервисы, у каждого свой доступ.

• CRM (amoCRM, Битрикс24, Salesforce, OkoCRM): аккаунт администратора, токены интеграции с сайтом, webhook URLs.
• SMS-агрегаторы (smsc.ru, smsaero, sms.ru, mts-связь): личный кабинет, баланс, API-ключ, шаблоны сообщений.
• Платёжные системы (Юкасса, CloudPayments, Tinkoff Касса, Robokassa): кабинет, настройки магазина, ключи для интеграции, тестовые данные.

Все ключи, токены и API-secrets из этих сервисов часто захардкожены в коде сайта. Если вы их меняете при передаче (что правильно по соображениям безопасности), нужно сразу обновить и в коде сайта.

Email-рассылки и формы

• Mailchimp, Unisender, Sendsay, Sendpulse: аккаунт, API-ключи, шаблоны.
• Сторонние формы (если используются вместо своих): Tilda Forms, JotForm, Typeform.
• Captcha: если стоит reCAPTCHA или альтернатива, secret-ключи и владелец сайт-ключа.

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

Репозиторий кода

Если сайт хоть как-то цивилизованно разрабатывался, должен быть Git-репозиторий: GitHub, GitLab, Bitbucket, локальный Gitea.

Что забрать: — Доступ к репозиторию с правами Owner или Maintainer. — Список всех веток, особенно main/master, develop, staging. — Все приватные SSH-ключи деплоя, привязанные к репозиторию (или сменить их сразу). — CI/CD-конфиги (GitHub Actions, GitLab CI), если они есть.

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

Макеты и дизайн

• Файлы Figma/Sketch/Photoshop с макетами.
• Брендбук, гайдлайн, шрифты, логотипы в исходниках (svg, ai).
• Иконки, фотобанк, авторские картинки.
• Лицензии на коммерческие шрифты и фотографии.

В Figma добавьте себя владельцем команды или хотя бы организации. Доступ «редактор файла» недостаточен: при удалении создателя файл может пропасть.

Договорные материалы

• Договор с подрядчиком, акты, ТЗ, переписка по принятию работ.
• Лицензии CMS (Битрикс, особенно).
• Лицензии плагинов и тем (Yoast Premium, WP Rocket, Elementor Pro — всё именные).
• Договоры со смежниками: SEO-подрядчик, копирайтер, контекстолог.

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

Как проверить, что доступы реально работают

Главное правило: не верьте скриншотам. Подрядчик может прислать скриншот личного кабинета с надписью «вот, всё передал», а кредов не дать или дать неверные. Каждую запись из чек-листа надо реально проверить.

Я делаю так:

1. Получил список доступов в защищённом виде (1Password, Bitwarden, Vaultwarden, в крайнем случае защищённый паролем архив).
2. Прохожу по каждому пункту: вхожу, делаю безобидное изменение (создать черновик/добавить тег/посмотреть статистику), смотрю, есть ли права на сохранение.
3. Каждый успешно проверенный пункт отмечаю галочкой в табличке.
4. Что не работает — пишу подрядчику списком в одно сообщение, не по одному.
5. Когда все галочки проставлены — подписываем акт о передаче (можно неформально, в чате) и рвём отношения.

Шаблон таблицы для отметок:

Доступ	Передан	Проверен	Полные права	Старый удалён
Регистратор домена	да	да	да	да
Хостинг	да	да	да	нет
FTP/SSH	да	да	да	да
База данных	да	да	да	да
Админка CMS	да	да	да	да
Я.Метрика	да	да	да	да
GSC	да	нет	—	—
Я.Вебмастер	да	да	да	да
Почта	нет	—	—	—
Репозиторий	да	да	да	нет

Каждый «нет» — это потенциальная мина.

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

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

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

Сначала разберитесь, на чьём имени какие активы. У большинства всё устроено так:

• Домен зарегистрирован на физлицо подрядчика. Можно через регистратора по заявлению на смену администратора (сложно, до месяца).
• Хостинг оплачен с карты подрядчика. Можно перенести аккаунт по заявлению на смену владельца, но если подрядчик не подпишет, остаётся переезд на новый хостинг с потерей прав на текущий аккаунт (но с сохранением сайта).
• Метрика и Вебмастер можно пере-верифицировать, имея доступ к коду сайта.
• Репозиторий, скорее всего, потеряется, если подрядчик его не передаёт. Но текущий код всегда можно вытянуть с FTP и инициализировать новый Git локально.

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

Если подрядчик активно вредит

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

1. Сразу пишете заявление о неправомерном доступе к информационной системе (ст. 272 УК РФ). Параллельно блокируете все известные доступы со своей стороны.
2. У хостинга через тикет с подтверждением вашего владения сайтом (договор, реквизиты, оплата) запрашиваете восстановление доступа в обход подрядчика.
3. Выгружаете снапшот хостинга на дату, когда сайт был ещё нормальный.
4. Сменяете все пароли на абсолютно новые (а не «поправленные на одну букву»).
5. Дальше уже работаете с новым подрядчиком, который пройдётся по сайту в поисках бэкдоров.

Это тяжёлый сценарий, но он отрабатывается. Главное — не платить шантажисту, потому что после оплаты вы уже сценарий «уходим» не закроете, отношения станут ещё хуже.

Как этого избежать в будущем

• Все ключевые активы регистрировать на себя/компанию, не на подрядчика. На старте отношений.
• Не давать подрядчику единоличный root-доступ. Создавать ему отдельного пользователя с нужными правами, у себя оставлять полный root.
• Регулярно (раз в полгода) делать ревизию: какие у меня доступы, кто туда ходит, что устарело. Менять пароли при подозрениях.
• Иметь свой бэкап хотя бы раз в неделю отдельно от хостинга. Скрипт на 30 строк бэкапит файлы и БД на ваш Я.Диск или S3.

Чек-лист, который можно скачать в голову

• [ ] Регистратор домена: логин, пароль, контакт администратора — на меня.
• [ ] Хостинг: логин, пароль, реквизиты — на меня.
• [ ] FTP/SSH: проверил ssh user@host pwd.
• [ ] База данных: проверил mysql -e "SHOW TABLES;".
• [ ] Админка CMS: вошёл, права супер-админа.
• [ ] Старый админ в CMS удалён или роль понижена.
• [ ] Я.Метрика, GSC, Я.Вебмастер: я владелец.
• [ ] Корпоративная почта: вход в кабинет, MX-записи проверены.
• [ ] CRM, SMS, платежи: ключи и кабинеты переданы.
• [ ] Репозиторий кода: владелец я.
• [ ] Макеты Figma: я в команде с правами.
• [ ] Документы и лицензии: получены файлами.
• [ ] Каждый пункт реально проверен входом, не просто скриншотом.
• [ ] Все пароли сменены сразу после получения.
• [ ] Внешний бэкап сайта снят на дату передачи.

Если у вас сейчас мутная история со сменой подрядчика и не понятно, с чего начать — напишите через форму, пройдём по списку вместе и составим план. Обычно уходит 2-3 встречи на то, чтобы сделать передачу чисто и без потерь. Текущие условия абонентки с приёмкой существующего сайта — в тарифах.

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

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

Какие доступы забирать в первую очередь

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

Как проверить, что доступы рабочие

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

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

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

Что кроме доступов надо получить

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