Чтобы передать сайт новому специалисту, соберите список сервисов и доступов, сохраните пригодную для восстановления копию, опишите важные функции и договоритесь об ответственности. Затем проверьте, что новый исполнитель может выполнять согласованные задачи, а вы сохраняете контроль над сайтом и его оплатой.
Одного логина от системы управления обычно недостаточно: заявки могут уходить через отдельный почтовый сервис, домен — продлеваться в другом аккаунте, а код — храниться у прежнего разработчика. Эта памятка поможет собрать всё в одном документе. Она подходит для сайтов на разных CMS, конструкторах и собственной разработке; конкретный способ передачи зависит от платформы.
Сначала определите, что именно передаёте
Передача на поддержку, перенос на другой хостинг и передача прав на домен — разные задачи. Смена исполнителя сама по себе не требует менять сервер или переписывать сайт. Сначала зафиксируйте цель: например, принимать заявки без сбоев, обновлять информацию и устранять ошибки в согласованном объёме.
Составьте короткое описание сайта:
- Для чего он нужен: заявки, продажи, запись на услуги, публикация материалов.
- Какие функции критичны: форма, личный кабинет, корзина, оплата, поиск, языковые версии.
- Что сейчас работает неправильно и какие изменения уже начаты.
- Кто принимает решения и кто подтверждает результат работ.
Если сайт уже недоступен, начните с диагностики сбоя и сохранения текущих данных. Полную передачу можно завершить после восстановления основных функций. Для сбоя именно после обновления WordPress есть отдельная памятка по первым проверкам.
Что запросить у прежнего исполнителя
Используйте таблицу как перечень для своего сайта. Ненужные строки уберите, неизвестные отметьте «требует проверки». Не подставляйте предположение вместо подтверждённого владельца аккаунта.
| Компонент | Что должно быть понятно при передаче |
|---|---|
| Домен и DNS | Где зарегистрирован домен, кто управляет аккаунтом и записями DNS, куда приходят уведомления о продлении. |
| Хостинг или платформа | Где работает сайт, кто оплачивает услугу, как новый специалист получает доступ в нужном объёме. |
| CMS, код и файлы | Адрес входа, роли пользователей; для собственной разработки — репозиторий и инструкция запуска или развёртывания. |
| Резервные копии | Дата, состав, место хранения, порядок получения и результат проверки восстановления. |
| Формы и почта | Куда должны приходить заявки, какой сервис отправляет письма и кто управляет им. |
| Интеграции | CRM, платежи, доставка и другие связи: назначение, ответственные и место управления доступом. |
| Лицензии и подписки | Что оплачивается отдельно, на кого оформлено и можно ли продолжать использование после смены подрядчика. |
| Аналитика и история работ | Какие системы подключены, кто имеет доступ, где хранятся задания, изменения и известные ограничения. |
Отдельно попросите перечень ручных настроек и незавершённых задач. Фраза «всё в админке» не объясняет, откуда берётся резервная копия и почему уведомления зависят от личного аккаунта бывшего сотрудника.
Сохраните собственный контроль над аккаунтами
У владельца бизнеса должен оставаться доступ к ключевым сервисам и возможность восстановить его без участия одного конкретного подрядчика. Проверьте контактную почту, способы восстановления и получение уведомлений о продлении. Для домена полезно свериться с рекомендациями ICANN по защите аккаунта регистратора.
Там, где сервис поддерживает отдельных пользователей, предоставляйте исполнителю собственную учётную запись с правами под задачу. Не передавайте личный почтовый аккаунт целиком ради доступа к одному сайту. Пароли, коды восстановления и API-ключи храните отдельно от общего документа передачи; способ предоставления доступа согласуйте заранее.
Для важных аккаунтов используйте доступные средства защиты: ключи доступа либо уникальный пароль с двухэтапной проверкой. После завершения передачи пересмотрите доступ прежних исполнителей. Эти меры соответствуют рекомендациям NCSC по защите рабочих аккаунтов.
Если сайт использует общие учётные данные или ключ интеграции, специалист сначала должен выяснить, какие процессы от них зависят. Их замена требует согласованного переключения и проверки: иначе вместе со старым доступом можно отключить отправку заявок. Передачу домена или аккаунта между владельцами выполняйте по правилам конкретного сервиса.
Проверьте, что резервная копия пригодна
Запись «бэкап есть» ещё не описывает, что удастся восстановить. Для сайта с отдельной базой данных уточните, входят ли в копию база, файлы и загруженные материалы. Для конструктора или облачной платформы проверьте доступные способы восстановления и ограничения экспорта: они могут отличаться от копирования обычного хостинга.
Попросите зафиксировать дату копии, её состав и результат проверки восстановления в отдельном окружении, если платформа это позволяет. NCSC рекомендует не только делать копии важных данных, но и понимать, как восстановить их и проверить полноту. См. руководство по резервному копированию.
Для магазина или сайта с заявками отдельно обсудите данные, появившиеся после последней копии. Передача обслуживания не должна незаметно превратиться в откат, при котором пропадут новые заказы. Резервные копии могут содержать сведения клиентов, поэтому выдавайте к ним доступ только тем, кому он нужен для согласованной работы.
Договоритесь, кто за что отвечает
Зафиксируйте для каждой регулярной задачи исполнителя, срок или условие запуска и способ проверки. Например:
- Продление домена и хостинга: кто получает уведомления, оплачивает и контролирует результат.
- Резервные копии: кто следит за созданием, хранением и проверкой восстановления.
- Обновления и доработки: кто согласует изменения, выполняет их и проверяет важные функции.
- Ошибки: куда сообщать, кто принимает обращение и как согласуются срочные работы.
- Контент: кто предоставляет факты, редактирует и публикует материалы.
Не считайте, что «поддержка сайта» автоматически включает круглосуточный ответ, новые страницы, оплату лицензий или любые интеграции. Эти условия лучше перечислить явно, без догадок с обеих сторон.
Шаблон передачи сайта
Скопируйте этот блок в рабочий документ. Для каждого компонента из таблицы выше добавьте отдельную запись. Самих секретных значений здесь быть не должно.
Сайт: Цель передачи: Дата и ответственный со стороны владельца: Новый исполнитель и согласованный объём работ: Компонент или сервис: Адрес сервиса / место документации: Владелец аккаунта: Ответственный за оплату и ближайшее продление: Способ предоставления доступа и нужная роль: Что передано: Что ещё отсутствует: Как проверено и кем: Статус: не начато / передаётся / проверено Резервная копия: дата, состав, где находится: Результат проверки восстановления: Известные ошибки и незавершённые изменения: Важные функции для приёмки: Кто подтверждает завершение передачи:
Если данных нет, оставьте конкретную задачу и ответственного: «Выяснить, кто оплачивает сервис отправки писем». Так незакрытый вопрос не потеряется за общей отметкой «доступы получены».
Как понять, что передача завершена
Проверьте рабочий сценарий, ради которого существует сайт. Для сайта услуг это может быть отправка явно помеченной тестовой заявки и её получение нужным человеком. Для магазина — согласованный тест заказа, доставки и оплаты в предусмотренном для этого режиме.
Перед закрытием передачи подтвердите:
- Владелец контролирует ключевые аккаунты и получает важные уведомления.
- Новый исполнитель получил нужные права и документацию.
- Критичные функции проверены, обнаруженные ошибки записаны.
- Состав и доступность резервных копий понятны; результат проверки восстановления зафиксирован либо отсутствие такой проверки прямо отмечено.
- Незавершённые задачи, продления и границы поддержки имеют ответственных.
- Ненужные доступы пересмотрены; изменение общих ключей выполнено с проверкой зависимых функций.
Условный пример. Компания передаёт небольшой сайт услуг. Новый специалист вошёл в CMS, но тестовая заявка не пришла. Выясняется, что отправка писем зависит от отдельного сервиса, которым управлял прежний подрядчик. Задача передачи остаётся открытой до предоставления нужного доступа и проверки доставки. Это учебный сценарий, а не описание клиентского проекта.
Частые вопросы
Нужно ли менять хостинг при смене подрядчика?
Не обязательно. Сначала выясните, может ли новый исполнитель работать с текущим размещением и соответствует ли оно задачам сайта. Перенос стоит оценивать как отдельную работу со своими причинами, этапами и проверками.
Что делать, если прежний разработчик не отвечает?
Соберите то, что уже есть у компании: счета, контакты сервисов, собственные учётные записи и документы по проекту. Восстановление доступа обсуждайте с поддержкой соответствующего сервиса; новый подрядчик не может гарантировать получение чужого аккаунта или отсутствующих исходников. Недоступные компоненты внесите в перечень ограничений.
Достаточно ли передать архив сайта?
Архив может быть лишь частью передачи. Нужно понимать его состав, дату, способ запуска и зависимость от внешних сервисов. На некоторых платформах важнее передача роли в аккаунте и документации, чем набор файлов.
Сколько стоит передача на поддержку?
Объём зависит от документации, доступов, количества интеграций и состояния сайта. Для оценки подготовьте URL, цель передачи и список известных ограничений. Если нужна помощь, пришлите адрес сайта и опишите задачу поддержки.