Как сменить веб-мастера и не потерять сайт

Смена веб-мастера занимает 10-14 дней и начинается не с поиска нового человека, а со сбора доступов: домен, хостинг, админка, база, репозиторий и почта. Пока доступы у старого подрядчика, любой разговор о переходе ведётся с позиции слабого.

Смена веб-мастера выглядит просто только в теории. На практике в момент разрыва выясняется, что домен оплачен с личной карты бывшего исполнителя, доступ в админку был только у него, а Метрика привязана к корпоративному ящику Gmail, который никто не открывал три года. Эта статья разбирает, как передать сайт новому подрядчику без потерь и без шантажа в духе «верните мне доступ к репозиторию, тогда верну DNS».

Я в этой работе шесть лет, через мои руки прошло порядка 200 проектов, из них в районе 50 пришли как наследство от другого подрядчика. По наблюдениям, в каждом втором случае часть доступов просто отсутствует, а в каждом четвёртом владелец узнаёт о проблеме только в тот момент, когда нужно срочно что-то поправить. Хорошая новость: алгоритм отработан, и при дисциплине вся передача укладывается в 3-5 рабочих дней.

Что собрать ДО первого разговора с новым исполнителем

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

Вот этот список. Он подойдёт почти любому сайту малого бизнеса.

Категория	Что именно	Где обычно лежит
Домен	Личный кабинет регистратора, доступ к контактному email	Reg.ru, Beget, RU-CENTER, Timeweb
Хостинг	ISPmanager / cPanel / панель Beget, SSH или FTP	Письмо хостера на email владельца
База данных	Пароль root или владельца БД, имя БД, доступ к phpMyAdmin	Файл wp-config.php, bitrix/.settings.php, конфиг CMS
Админка CMS	Логин и пароль уровня «администратор», двухфакторка	Внутри сайта
Аналитика	Я.Метрика, Я.Вебмастер, Search Console (если был)	Аккаунт владельца, не подрядчика
Почта домена	Корпоративные ящики, mx-записи	У хостера или у Яндекс 360
Интеграции	СМС-агрегатор, CRM, платёжка, мессенджеры, телефония	Личный кабинет каждого сервиса
Репозиторий	GitHub, GitLab, Bitbucket	Если код вообще лежит в Git

Главное правило при сборе: каждый доступ должен быть оформлен на email владельца бизнеса, а не на подрядчика. Если регистратор домена шлёт уведомления на адрес webmaster@old-agency.ru, при разрыве вы рискуете не получить вовремя письмо о продлении и потерять домен. Это реальный кейс из моей практики, домен ушёл на drop за 8 дней, выкупали через посредника за 35 тысяч.

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

Первая очередь, без которой невозможно ничего: домен, хостинг, БД, админка CMS, корпоративная почта. Вторая очередь, без которой можно жить день-два, но не больше: Метрика, Вебмастер, GSC, CRM, платёжка, СМС, мессенджеры. Я разделяю их специально, потому что блокировать передачу из-за того, что нет доступа к Telegram-боту, это терять время. Договоритесь с новым подрядчиком, что он начнёт работу после получения первой очереди, а вторую вы добавите в течение недели.

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

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

• Регистратор домена: войти, открыть карточку домена, посмотреть дату продления и контактный email. Если email не ваш, тут же сменить.
• Хостинг: войти в панель, открыть файловый менеджер, открыть index.php или любой скрипт сайта, убедиться, что вы видите код. Если файлы только на чтение, выяснить почему.
• БД: открыть phpMyAdmin, выбрать базу сайта, посмотреть таблицу wp_options (для WordPress) или b_option (для Битрикс). Если выпадает Access denied, пароль либо неправильный, либо обрезан в письме.
• Админка CMS: войти, перейти в «Пользователи», убедиться, что у вас роль «Администратор», а не «Редактор». Это разные планеты по правам.
• Метрика: войти, открыть отчёт «Источники трафика», убедиться, что данные за вчера есть. Если 0 визитов, счётчик мог быть переустановлен или передан в другой аккаунт.

Дополнительно я всегда делаю боевую проверку: меняю один незначительный текст на главной (например, телефон в шапке через админку CMS) и смотрю, действительно ли он изменился на сайте. Если нет, значит, есть кеш на CDN, плагин или внешний сервис, о котором вам не сказали. Чтобы вернуть текст обратно, занимает минуту, но защищает от сюрприза в духе «а у нас ещё есть Cloudflare, мы забыли».

Что часто остаётся в руках старого подрядчика

Самая токсичная история. Подрядчик передал админку и хостинг, но не передал то, чем на самом деле управляется проект. Список того, что прячется:

1. Регистратор домена. Домен оформлен на физлицо подрядчика, оплачивается с его карты. Передать в чужой аккаунт можно через push (внутри регистратора) или через трансфер с auth-кодом, оба способа требуют активного действия от подрядчика.
2. DNS-провайдер. Часто домен запаркован у регистратора, но NS-записи указывают на Cloudflare или на NS другого хостинга. Если у вас нет доступа к Cloudflare, вы не сможете направить домен на новый сервер.
3. SSL-сертификат. Если использовался платный сертификат, он привязан к контактному email при выпуске. Бесплатный Let’s Encrypt обычно перевыпускается на новом хостинге без проблем.
4. Корпоративный ящик почты. Если бизнес-почта info@your-domain.ru была заведена в Яндекс 360 на аккаунт подрядчика, вся переписка может уйти вместе с ним.
5. Лицензии. Битрикс, коммерческие плагины WP (Elementor Pro, WP Rocket), темы из ThemeForest, лицензии на скрипты онлайн-чата, шрифты с лицензией. Каждая привязана к учётной записи и часто к домену.
6. Репозиторий и история коммитов. Бывает, что новый подрядчик получает только zip-архив текущего состояния без истории. Это лишает возможности откатиться к стабильной версии за прошлый месяц.
7. Документация архитектуры. Записи о том, какие крон-задачи запускаются, какие внешние API дёргаются, где лежат логи. Без этого новый исполнитель потратит 5-10 часов на разведку, и за эти часы вы заплатите.

С каждым пунктом из списка нужно работать индивидуально. Домен переводят через push в личный кабинет регистратора (мгновенно, бесплатно), либо через трансфер с auth-кодом (5-7 дней, иногда платно). DNS Cloudflare переводят через смену email на аккаунте или через приглашение нового member с ролью Super Administrator. Лицензии Битрикс владелец перевыпускает в личном кабинете, привязав к своему email.

Конкретный пример формулировки запроса

Когда старый подрядчик не торопится отдавать, помогает официальное письмо с конкретными формулировками. Не «верните мне всё», а постатейно. Пример:

Прошу в течение 5 рабочих дней передать следующие материалы:
1. Push домена site.ru в аккаунт my-email@example.com у регистратора Reg.ru.
2. Передать роль Super Administrator на аккаунт Cloudflare для зоны site.ru.
3. Передать архив исходного кода (git-репозиторий с историей) на email
   my-email@example.com или GitHub-аккаунт my-github.
4. Передать список cron-задач со скриптами (можно вывод crontab -l).
5. Передать перечень внешних интеграций с указанием ключей API.
В случае непередачи в указанный срок резервирую право обратиться
к регистратору и хостинг-провайдеру с заявлением об утрате доступа.

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

Риски в первые две недели после смены

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

• Ключи API в коде. Иногда пароли SMTP, токены платёжки или ключи агрегаторов хранятся прямо в файлах темы или в .env, и старый подрядчик помнит их наизусть. Менять надо все ключи без исключения, даже если кажется, что их никто не утянет. Это занимает 1-2 часа и стоит копейки, а уберегает от сценария «через месяц со счёта пропали 20 тысяч за СМС».
• Webhook-и и обратные вызовы. Если на сайт стучится CRM, банк, платёжка по webhook, у них в настройках указан конкретный URL и иногда секрет. После смены инфраструктуры эти URL могут стать невалидными.
• Cron-задачи на стороне. Бывает, что часть задач (например, ночная выгрузка прайса) запускается с внешнего сервера старого подрядчика. После разрыва задачи перестают работать молча, и вы узнаёте об этом через неделю по жалобам клиентов.
• Вторичные админки. Виджеты онлайн-чата, формы захвата, попапы, сервисы рассылок. У каждого свой кабинет, и часть из них могут просто перестать показываться, если истёк аккаунт.
• Бэкапы старого подрядчика. Если он держал ваши бэкапы у себя на S3, после разрыва доступа к этим бэкапам у вас не будет. Новый подрядчик должен сразу настроить независимый бэкап-канал.

Чек-лист первой недели для нового подрядчика

Я обычно прохожу следующий список в первый рабочий день:

# 1. Снять полный бэкап текущего состояния, положить в безопасное место
ssh user@host 'cd ~/site && tar czf ~/backup-$(date +%F).tar.gz . && 
  mysqldump -u dbuser -p dbname > ~/db-$(date +%F).sql'

# 2. Сменить все пароли: SSH, FTP, БД, админка CMS, SMTP
passwd                                # SSH
# через панель хостинга или MySQL для БД
# через админку для CMS

# 3. Поставить файловый монитор изменений
find /home/user/site -type f -newer /tmp/marker -print

# 4. Включить логирование в .htaccess или nginx
# проверить, что error log пишется и доступен

# 5. Поставить мониторинг доступности (UptimeRobot или аналог)
# чтобы получить алерт, если что-то ляжет

После этого 7-10 дней наблюдаем сайт, читаем логи, отвечаем на любые странности. Если за две недели ничего не всплыло, считаем, что передача прошла чисто.

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

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

Первое: оплачивайте до конца месяца перехода, даже если работа уже не идёт. Долг за 5-10 тысяч даёт моральное право подрядчику тянуть с передачей доступов. Эта пятёрка экономит вам потенциально десятки часов суда или разборок.

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

Третье: не критикуйте старого подрядчика при новом. Это правило для обеих сторон. Профессиональный исполнитель не будет говорить «тут такое г… написано», это плохой знак о новом подрядчике. И вы не должны жаловаться «старый ничего не понимал», это даёт новому исполнителю ложное ощущение, что планка низкая.

Четвёртое: оставьте за подрядчиком возможность ответить на 1-2 уточнения после официального завершения. По договору можно зафиксировать «консультация по передаче в течение 30 дней после окончания договора в объёме до 4 часов бесплатно». Эта оговорка снимает 90% страхов с обеих сторон.

Типовые сценарии и сроки

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

Маленький сайт-визитка на WordPress, передача от штатного подрядчика. Доступы есть, документация в Telegram-чате. Передача занимает 1 рабочий день: смена паролей, бэкап, проверка работоспособности. Стоимость на стороне нового подрядчика: 3-5 тысяч.

Корпоративный сайт на Битрикс с интеграциями. Подрядчик ушёл в свободное плавание, передаёт документы по почте. Есть лицензия, есть личный кабинет 1С-Битрикс, нужно перевыпустить ключ. Срок передачи: 5-7 рабочих дней. Затраты на нового подрядчика: 15-25 тысяч за погружение, дальше абонентка.

Магазин на OpenCart с конфликтом. Старый подрядчик не отдаёт доступы. Решение: владелец восстанавливает доступ к домену через регистратора по паспорту, к хостингу через службу поддержки хостера по договору на юрлицо, к БД через хостера. Длительность: 10-14 дней, плюс возможный простой на 1-2 дня при переключении DNS. Затраты: 30-50 тысяч на нового подрядчика, плюс эмоциональные.

Полная катастрофа: домен на физлицо подрядчика, который не выходит на связь. Самый тяжёлый случай. Сценарий: ждать окончания регистрации домена, выкупать на drop через посредника, параллельно собирать сайт заново на новом домене с переадресацией. Срок: 1-3 месяца. Затраты: от 50 тысяч и выше.

Что нужно было сделать ещё вчера

Если вы сейчас читаете эту статью не в момент конфликта, а превентивно, вот короткий список действий на ближайшую неделю. Они не требуют разрыва с текущим подрядчиком и стоят владельцу 1-2 часа.

• Проверить, на чей email оформлен домен у регистратора. Если не на ваш, попросить сменить.
• Проверить, на чьё юрлицо или физлицо оформлен договор с хостером. Должно быть на ваше.
• Проверить, что Метрика и Вебмастер привязаны к вашему аккаунту, а подрядчик в роли «представителя» или «редактора». Не наоборот.
• Запросить у подрядчика список cron-задач и интеграций. Сложить в Notion или в обычный Google-документ.
• Раз в три месяца проверять, что бэкапы делаются и доступны вам, а не только подрядчику.

Эти пять действий снимают 80% риска при будущей смене веб-мастера. Они не требуют доверия к новому подрядчику, не требуют конфликта со старым, не требуют ничего, кроме 2 часов времени владельца.

CTA

Если вы сейчас в процессе передачи сайта и нужен взгляд со стороны на собранный пакет доступов, или нужен новый подрядчик, который примет проект и начнёт работать без раскачки, напишите через форму на /#contact. Я обычно отвечаю в течение 2 часов в рабочее время, бесплатно прохожусь по чек-листу и говорю, чего не хватает. Если ищете формат абонентки на постоянку после передачи, тарифы открыто лежат на /#pricing. Другие материалы по теме поддержки и работы с подрядчиками собраны в рубрике /blog/category/support/.

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

Как сменить веб-мастера и не потерять сайт

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

Что остаётся в руках старого подрядчика чаще всего

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

Сколько времени занимает переход

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

Как расстаться мирно

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