Как восстановить доступ к сайту, если разработчик пропал
Разработчик не отвечает третью неделю, а пароли от админки, хостинга и домена были только у него. Или он на связи, но доступы отдаст «после доплаты». Ситуация неприятная, но почти всегда решаемая: в большинстве случаев восстановить доступ к сайту можно без участия прежнего подрядчика. Вопрос в том, на кого оформлены ключевые активы и насколько последовательно вы действуете.
Ниже — четыре типовых сценария и порядок действий по дням, таблица «какой доступ как восстанавливать» и что делать с кодом, если исходников нет. Юридическую часть (кому принадлежат права, WHOIS, претензия и суд) мы подробно разобрали в статье «Кому принадлежит сайт», здесь — только практический план.
Сначала — инвентаризация: что у вас уже есть
Прежде чем писать разработчику или в поддержку хостера, потратьте час на то, чтобы понять исходную точку. От неё зависит, какой из сценариев ниже ваш.
- Домен. Проверьте WHOIS на сайте регистратора или через сервис Координационного центра: кто регистратор, дата окончания регистрации. Для физлица-администратора данные скрыты, но регистратор и срок видны всегда. Если в поле администратора указано название вашей компании — это лучший из возможных раскладов.
- Хостинг. Найдите в бухгалтерии счета от хостера. Если их нет — значит, хостинг оплачивал разработчик. Узнать провайдера можно по IP сайта: сервисы WHOIS для IP-адресов показывают владельца сети.
- Документы. Договор, акты, платёжки, ТЗ, переписка — соберите в одну папку. Они понадобятся и регистратору, и хостеру, и юристу.
- Что открыто прямо сейчас. Сохранённые пароли в браузере сотрудников, доступ к Метрике, почта на домене, аккаунт в админке с правами редактора. Любой рабочий вход — это возможность сделать резервную копию.
Сценарий 1: разработчик просто молчит
Самый частый случай: человек не ругался, не угрожал — просто перестал отвечать. Причины банальные: болезнь, выгорание, переезд, новая работа. Поэтому первые дни действуйте без резких движений, но с фиксацией каждого шага.
Как фиксировать попытки связи
- Пишите по контактам, указанным в договоре, — прежде всего на e-mail. Мессенджеры тоже используйте, но делайте скриншоты с датами.
- Формулируйте конкретно: какие доступы нужны, к какому сроку и зачем. «Прошу до 10 октября передать логин и пароль от панели хостинга, админки сайта и регистратора домена».
- Звонки фиксируйте короткими письмами-резюме: «Сегодня звонил в 12:00, не дозвонился».
Сколько ждать
Разумный ориентир: 2–3 рабочих дня на ответ в мессенджере, затем официальное письмо с отсрочкой в 5–10 рабочих дней. Если и после этого тишина — направляйте письменную претензию заказным письмом с описью вложения по адресу из договора. Такое письмо — доказательство, что вы пытались решить вопрос мирно, даже если спор до суда не дойдёт.
Сценарий 2: не отдаёт доступы или требует доплату
Здесь важно отделить законное требование от давления. Если по договору остался неоплаченный этап, подрядчик вправе требовать оплату — но удерживать доступы к вашему домену или хостингу как залог это его не оправдывает.
- Долг реальный и подтверждён актами. Предложите встречное исполнение: оплата в день подписания акта приёма-передачи, в котором перечислены все доступы, код и база. Сначала доступы проверяются, потом уходит платёж.
- Доплата «за передачу доступов». Если в договоре такой услуги нет, требование ничем не обосновано. Ответьте письменно со ссылкой на договор и попросите выставить счёт с обоснованием — часто на этом разговор заканчивается.
- Подрядчик готов передать, но «некогда». Предложите сделать всё за один созвон: он делится экраном и меняет владельца в кабинетах, вы сразу меняете пароли.
Если договориться удалось, дальше действуйте по нормальному сценарию передачи — чек-лист есть в статье о том, как передать сайт другому разработчику. Если нет — претензия и, при необходимости, суд; эта часть подробно разобрана в статье о правах на сайт.
Сценарий 3: разработчик исчез, а сайт работает
Это лучший момент для действий: ничего не горит, и вы успеваете подготовиться до того, как что-то сломается. Сайт без присмотра обычно ломается по предсказуемым причинам: истёк домен, закончилась оплата хостинга, не продлился SSL-сертификат, отвалилась интеграция после обновления внешнего API.
- Запишите даты. Окончание регистрации домена (из WHOIS), оплаченный период хостинга, срок лицензии CMS (для 1С-Битрикс — в админке). Поставьте напоминания за месяц.
- Сделайте резервную копию. Если хостинг ваш — архив файлов и дамп базы через панель. Если доступ только к админке — встроенный бэкап CMS (у Битрикса и у WordPress с плагинами он есть).
- Проверьте, куда приходят заявки. Формы могут отправлять письма на личный ящик разработчика или через его SMTP-аккаунт. Отправьте тестовую заявку.
- Возьмите сайт под мониторинг. Бесплатного пинга доступности раз в несколько минут достаточно, чтобы узнать о падении раньше клиентов.
- Восстановите всё, что оформлено на вас — по таблице ниже.
Если нужно передать сайт на обслуживание новой команде, поддержка сайта с мониторингом и регулярными бэкапами решает как раз задачу «никто не следит» — например, в формате абонентской поддержки сайта по SLA.
Сценарий 4: разработчик исчез, и сайт упал
Первое — не паниковать и определить, что именно сломалось. От причины зависит, кто может помочь.
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Браузер не находит сайт, почта на домене тоже не работает | Истекла регистрация домена | WHOIS: статус и дата. Если домен на вас — продлить у регистратора, даже без доступа к кабинету, через поддержку |
| Заглушка хостера «аккаунт заблокирован» | Не оплачен хостинг | Хостинг на вас — оплатить. На разработчике — связаться с хостером: данные после блокировки хранятся ограниченное время |
| Предупреждение браузера о небезопасном соединении | Истёк SSL-сертификат | Перевыпуск в панели хостинга — дело минут при наличии доступа |
| Белый экран, ошибка 500 | Сбой кода, обновление PHP, переполнен диск | Логи ошибок в панели хостинга, откат на резервную копию |
| Посторонний контент, редиректы | Взлом | Изолировать, сменить пароли, лечить по копии; без промедления |
Если домен истёк и оформлен на разработчика, время ограничено: в зонах .RU и .РФ после окончания срока регистрации у прежнего администратора есть 30 дней на преимущественное продление, затем домен освобождается и его может зарегистрировать кто угодно. Продлить в этот период может только администратор, то есть разработчик, — поэтому договаривайтесь с ним или готовьте претензию сразу, а не на 29-й день.
Как восстановить доступ к сайту без разработчика: таблица
Главный вопрос для каждого сервиса — на кого оформлен аккаунт. Если на вашу компанию или на вас лично, почти всё восстанавливается по документам. Если на разработчика — нужно его согласие или решение суда, а пока — обходные пути.
| Доступ | Оформлен на вас | Оформлен на разработчика |
|---|---|---|
| Домен (регистратор) | Заявление в поддержку регистратора: для юрлица — на бланке с подписью руководителя, для физлица — с паспортными данными; у ряда регистраторов можно подписать КЭП | Смену администратора подаёт сам разработчик; без согласия — только претензия и суд |
| Хостинг, VPS | Поддержка хостера по договору: реквизиты, копия паспорта или ИНН, платёжки | Хостер доступ не даст. Файлы — от разработчика или по решению суда; параллельно готовьте новый хостинг |
| Админка CMS | При доступе к хостингу пароль администратора меняется через базу данных или файлы сайта — 15–30 минут работы специалиста | Штатное «Забыли пароль?», если почта администратора ваша; иначе — сначала вернуть хостинг |
| Яндекс Вебмастер, Search Console | Вход в свой аккаунт | Права подтверждаются заново: мета-тег, HTML-файл или DNS-запись. История сайта в сервисе доступна новому подтверждённому владельцу |
| Яндекс Метрика | Вход в свой аккаунт Яндекса — счётчик ваш | Владелец может перенести счётчик на ваш аккаунт сам. Если он недоступен — подтвердите права на сайт в Вебмастере и подайте заявку на перенос через форму Метрики: счётчик перенесут вместе с историей, если он собирает данные только по этому сайту |
| Репозиторий (GitHub, GitLab) | Восстановление через почту аккаунта | Без владельца — никак. Код забирается с сервера (см. ниже) |
Что делать с кодом, если нет исходников
Для типового сайта «исходники» — это файлы на сервере плюс база данных. Если есть доступ к хостингу, копия с сервера — полноценная рабочая версия сайта, с которой можно продолжать работу.
- Скачайте всё: файлы сайта, дамп базы, конфигурацию сервера, задания cron. В Битриксе отдельно проверьте, что забрали папки /local/ и /upload/.
- Поищите папку .git на сервере. Нередко репозиторий лежит прямо там — с историей изменений.
- Для сайтов на фреймворках (Next.js, Vue, собранный фронтенд) на сервере может лежать только собранная версия. С неё сайт работает, но дорабатывать её неудобно: часть фронтенда, возможно, придётся пересобрать.
- Веб-архив — крайний вариант: он сохраняет только внешний вид страниц, без базы, админки и логики.
После копирования смените все секреты, которые знал разработчик: пароли администраторов и FTP, SSH-ключи в authorized_keys, ключи ЮKassa и других платёжных систем, пароли SMTP и обмена с 1С, токены API. Проверьте список пользователей админки и удалите лишних.
Когда нужен аудит перед продолжением работ
Код, доставшийся от пропавшего подрядчика, — это «чёрный ящик»: никто не знает, какие модули дописаны, где правки ядра CMS, что сломается при обновлении. Новый разработчик либо потратит несколько недель на раскопки за ваш счёт, либо сразу предложит «переписать всё с нуля».
Аудит нужен, если сайт приносит заказы, на нём есть интеграции с 1С, CRM или оплатой, CMS давно не обновлялась или новый подрядчик называет пугающую сумму. Независимый технический аудит кода даёт карту рисков: что критично, что можно отложить и во что обойдётся доработка против переписывания. Экспресс-вариант для небольшого сайта обычно занимает 3–5 рабочих дней. Для лендинга без интеграций хватит резервной копии и смены паролей.
Как защититься в будущем
- Всё на своё имя. Домен, хостинг, лицензия CMS, счётчик Метрики, рекламные кабинеты — на компанию или на владельца. Подрядчику — отдельный пользователь с нужными правами.
- Менеджер паролей. Общее хранилище компании, где доступы живут независимо от сотрудников и подрядчиков. Уход человека — это отзыв его доступа, а не поиск паролей.
- Договор. Пункты о передаче исключительных прав на код, перечень передаваемых доступов, обязанность передать всё по первому запросу, в том числе при расторжении.
- Репозиторий у вас. Код хранится в аккаунте компании, разработчик работает в нём как участник.
- Раз в квартал — проверка. Войдите в каждый кабинет сами. Пароль, который никто не проверял год, скорее всего уже не работает.
Итоговый план действий
- Проверили WHOIS домена и выяснили хостера, записали даты окончания
- Собрали договор, акты, платёжки и переписку в одну папку
- Написали разработчику по контактам из договора с конкретным списком доступов и сроком
- Сделали резервную копию сайта через любой рабочий доступ
- Восстановили у регистратора и хостера всё, что оформлено на компанию
- Подтвердили права в Вебмастере и Search Console
- Проверили, куда уходят заявки с форм
- После получения доступов сменили все пароли и ключи
- Направили письменную претензию, если ответа нет 10 рабочих дней
- Решили, нужен ли аудит, прежде чем отдавать сайт новому подрядчику
Коротко
Потерять доступ к сайту неприятно, но обычно поправимо: всё, что оформлено на вас, восстанавливается по документам за несколько дней. Сложно только с тем, что оформлено на разработчика, — и здесь выручают копия с сервера, спокойная письменная переписка и, в крайнем случае, претензия. Главное — не ждать, пока сайт упадёт, и не делать резких движений до резервной копии.