Если разработчик пропал, это неприятно, но почти никогда не означает, что сайт потерян. В большинстве случаев проект можно принять и продолжить. Главная задача сейчас — не искать виноватого, а сохранить работающую систему и восстановить контроль над её ключевыми частями.
Не обновляй CMS и плагины, не меняй сервер и не выдавай незнакомому специалисту все доступы сразу. Любое резкое действие усложняет диагностику и может окончательно сломать то, что пока работает.
Что сделать в первые часы
Сначала убедись, что сайт действительно доступен посетителям. Открой основные страницы, отправь тестовую заявку, проверь корзину или запись, если они есть. Зафиксируй найденные ошибки скриншотами и коротким описанием.
- Не отключай сайт без причины. Если проблема не связана с утечкой данных или вредоносным кодом, работающий сайт лучше оставить доступным.
- Сохрани переписку и договорённости. В них могут быть названия хостинга, домена, сервисов, ссылки на репозиторий и сведения об интеграциях.
- Сделай резервную копию. Нужны и файлы, и база данных.
- Предупреди команду. Маркетолог, SEO-специалист и менеджеры не должны параллельно менять сайт до завершения первичной проверки.
Какие доступы нужно собрать
Доступ в административную панель — только одна часть проекта. Сайт зависит от домена, DNS, хостинга, базы данных, почты, внешних сервисов и иногда отдельного репозитория с исходным кодом.
Минимальный комплект
- аккаунт регистратора домена и управление DNS
- панель хостинга или доступ к серверу
- административная панель CMS
- файлы сайта по SFTP/SSH и база данных
- репозиторий Git, если разработка велась через него
- корпоративная почта, с которой создавались технические аккаунты
- Яндекс Метрика, Вебмастер, Search Console и системы аналитики
- CRM, телефония, платёжные системы, доставка и другие интеграции
- лицензии CMS, модулей, шрифтов и платных сервисов
Как вернуть контроль, если доступов нет
Начинай с того, что юридически и технически принадлежит компании. Домен обычно можно восстановить через регистратора по данным владельца. Доступ к хостингу — через договор, платёжные документы и корпоративную почту.
Если аккаунт оформлен на личную почту бывшего подрядчика, собери подтверждения оплаты, договор, акты и переписку. Обратись в поддержку сервиса и опиши ситуацию. Не пытайся обходить защиту или получать доступ неофициальным способом.
Контроль над доменом важнее доступа в CMS. Пока домен оформлен на компанию и доступен владельцу, сайт и почту обычно можно восстановить даже после потери сервера.
Что передать новому разработчику
Не нужно сначала самостоятельно составлять идеальное техническое задание. Для первичного знакомства достаточно ссылки на сайт, описания ситуации и того набора доступов, который удалось собрать.
Полезно разделить информацию на три группы:
- Что работает сейчас: продажи, заявки, личные кабинеты, выгрузки и другие критичные сценарии.
- Что сломано или вызывает вопросы: конкретные ошибки, даты появления, затронутые страницы.
- Что планировали сделать: незавершённые задачи, макеты, требования SEO-команды и договорённости с прежним подрядчиком.
Если документации нет, это не повод останавливать проект. При приёмке сайта на техническую поддержку разработчик может восстановить карту системы по коду, конфигурации сервера, базе данных и подключённым сервисам.
Почему работу стоит начать с технической диагностики
Новый специалист не знает историю проекта и не может честно оценить все доработки по одной ссылке. Сначала нужно понять, из чего состоит сайт, как он развёрнут, где хранятся данные и какие изменения опасны.
Во время диагностики проверяют CMS, версию PHP, плагины, логи ошибок, резервные копии, интеграции, фоновые задания, тестовую среду и критичные уязвимости.
Результатом диагностики должен быть не абстрактный аудит, а понятный план: что нужно сделать срочно, что можно отложить и какие задачи безопасно оценивать отдельно.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Чего точно не стоит делать
Сразу переписывать сайт
Новый проект может быть оправдан, но это решение принимают после оценки текущей системы, данных, интеграций и SEO-рисков.
Обновлять всё одной кнопкой
На старом сайте обновление CMS, модулей или PHP без копии и проверки часто создаёт больше проблем, чем решает.
Выдавать один общий пароль
Нельзя понять, кто и что изменил. Отдельные учётные записи безопаснее и упрощают отзыв доступа.
Оценивать по внешнему виду
Аккуратный интерфейс может скрывать плохой код, а старый дизайн — вполне рабочую архитектуру. Нужна проверка изнутри.
Как не зависеть от одного разработчика в будущем
Полностью исключить человеческий фактор невозможно, но бизнес не должен терять сайт вместе с одним контактом. Доступы и основные активы должны принадлежать компании, а изменения — оставлять проверяемый след.
- оформляй домен, хостинг и платные сервисы на компанию;
- храни доступы в корпоративном менеджере паролей;
- используй отдельные аккаунты для подрядчиков;
- держи актуальные резервные копии вне основного сервера;
- храни код в репозитории и фиксируй изменения;
- записывай ключевые интеграции, лицензии и порядок развёртывания;
- не откладывай обновление устаревшего окружения до аварии.
Для нового сложного проекта эти правила лучше закладывать ещё во время разработки сайта под ключ.
Коротко
Пропавший подрядчик — проблема управления, а не приговор сайту
Сохрани текущее состояние, собери доступы, верни компании контроль над доменом и инфраструктурой, а затем передай проект на диагностику. Хороший новый разработчик сначала разберётся в системе и рисках, а не начнёт менять всё в первый день.
Помочь принять проект
Обсуждение
Комментарии 0
Задай вопрос по статье или расскажи о похожей ситуации. Отвечаем по существу и не публикуем контактные данные.