Как передать сайт новому подрядчику и не потерять заявки

Опасный день выглядит совершенно обычно

Старый подрядчик перестал отвечать, а завтра нужно поменять цену, добавить акцию или исправить форму. Владелец просит нового специалиста «зайти на сайт», но оказывается, что домен оформлен на личную почту бывшего сотрудника, хостинг оплачивается с его карты, а письма из формы уходят в неизвестный ящик. Сайт формально существует, но бизнес им не управляет. Прямой ответ: не начинайте передачу с одной учётной записи CMS. Сначала убедитесь, что у компании есть подтверждённый доступ ко всем точкам, от которых зависит работа сайта и получение заявок. Новый подрядчик должен иметь рабочие права для задачи, а владельцем критических аккаунтов должна быть компания — обычно через корпоративную почту и назначенных ответственных. Это разные роли: исполнитель может вносить изменения, но не должен быть единственным человеком, способным продлить домен или восстановить пароль. Начните с простой таблицы. В ней достаточно трёх колонок: что проверяем, кто владелец, как подтверждён доступ. Восемь строк почти всегда важнее длинного перечня паролей: домен, DNS, хостинг, CMS или конструктор, корпоративная почта, формы и чат, аналитика, CRM. Укажите не только ссылку на сервис, но и адрес корпоративной почты, через который восстанавливается доступ. Пароли не пересылайте в этой таблице и в мессенджере: используйте менеджер паролей либо безопасный способ, согласованный внутри компании. Домен и DNS часто путают. Домен — это адрес сайта. DNS — настройки, которые говорят, куда вести этот адрес и куда доставлять почту. Можно знать логин от хостинга, но не суметь подключить новый сервер, если доступ к DNS остался у прошлого исполнителя. Поэтому попросите показать панель регистратора и панель DNS, а не принимать на веру скриншот работающего сайта. Проверьте, что в аккаунте есть корпоративный владелец и как продлевается домен. Далее пройдите путь клиента, а не список сервисов. Откройте сайт с телефона в режиме инкогнито, заполните форму тестовыми данными и отметьте время отправки. Проверьте последовательно: появилась ли страница подтверждения, дошло ли письмо на рабочую почту, создалась ли сделка или обращение в CRM, назначился ли ответственный, увидел ли менеджер уведомление. Если один из шагов не сработал, новый подрядчик не должен сначала «улучшать дизайн»: нужно найти точку разрыва и сохранить результат проверки. Этот тест особенно важен после смены почты, интеграций или DNS. Для аналитики важны права, а не просто ссылка на отчёт. В Google Search Console уровни доступа различаются: владельцы могут управлять пользователями и настройками ресурса, а пользователи с полным или ограниченным доступом — нет. Точные различия описаны в официальной справке Google. Проверьте, что у компании есть хотя бы один подтверждённый владелец, а у подрядчика выданы только нужные права. Такой же принцип применим к рекламным кабинетам, CRM и конструктору сайта. Подготовьте для передачи договоры, счета на продление, список интеграций и контакты ответственных. Это материалы для проверки, а не доказательство того, что доступ уже есть. Если код хранится в репозитории, убедитесь, что компания является владельцем организации или имеет права администратора, а резервная копия может быть развёрнута. Резервная копия без пробного восстановления — лишь предположение. Не нужно немедленно переносить сайт на новый хостинг: сначала зафиксируйте текущую конфигурацию и решите, есть ли реальная причина для миграции. Такой порядок подходит компании с работающим сайтом, несколькими исполнителями или заметным потоком обращений. Он особенно полезен перед расторжением договора, запуском рекламы и передачей поддержки. Он не решит спор о правах на дизайн или код, не заменит юридическую консультацию и не исправит процесс, в котором менеджеры не разбирают обращения. При отсутствии доступа к аккаунту потребуется отдельно пройти восстановление у конкретного сервиса. Если доступы запутаны, начните с малого: отправьте WebFix список того, что известно о домене, хостинге и сайте. В рамках аудита мы вернём понятный перечень недостающих доступов, рисков и проверок маршрута заявки — чтобы решить, достаточно ли корректно выдать права новому подрядчику или действительно нужна миграция.

Атака редко выглядит как сцена из фильма

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

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

Что советуют делать в первую очередь

В Google Search Console владельцы могут управлять пользователями и настройками ресурса, а полный и ограниченный доступ таких прав не даёт. Перед передачей сайта важно проверить, что подтверждённый владелец — компания, а не единственный подрядчик.

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

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

Как проверить проблему без дорогого эксперимента

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

Меняйте одну заметную вещь за раз и заранее выбирайте показатель. Это может быть завершение формы, доля ответов или время выполнения операции. Если переделать всё одновременно, положительный или отрицательный результат будет трудно объяснить. Небольшая проверка даёт больше знаний, чем большой редизайн без исходного замера.

Когда цифровое решение не поможет

Аудит не даст пользы, если выводы никто не превращает в проверяемые изменения. Список замечаний быстро устаревает, а команда продолжает работать по старому правилу. У каждой рекомендации должны быть владелец, срок и понятный способ проверки.

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

Что смотреть после запуска

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

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

Что можно сделать уже на этой неделе

• Создайте карту из домена, DNS, хостинга, CMS, почты, форм, аналитики и CRM.
• Для каждой точки запишите корпоративного владельца, способ входа и ответственного внутри компании.
• Проверьте панель регистратора домена и DNS отдельно от хостинга.
• Выдайте новому подрядчику только права, необходимые для первой задачи; не передавайте единственный владелецкий доступ без необходимости.

Бесплатный инструмент Проверить процессы и доступы

Введите свои данные и получите результат сразу. Регистрация и телефон не нужны.

Открыть расчёт ↗