# Как передать сайт на поддержку: доступы, копии и контроль > Что передать новому подрядчику сайта: доступы, резервные копии, лицензии и историю изменений. Чек-лист проверки и шаблон передачи без паролей. - Canonical: https://asgru.com/ru/peredacha-sajta-na-podderzhku/ - Language: ru - Author: writer - Published: 2026-09-25T04:37:38+02:00 - Updated: 2026-09-25T04:37:38+02:00 Чтобы передать сайт новому специалисту, соберите список сервисов и доступов, сохраните пригодную для восстановления копию, опишите важные функции и договоритесь об ответственности. Затем проверьте, что новый исполнитель может выполнять согласованные задачи, а вы сохраняете контроль над сайтом и его оплатой. Одного логина от системы управления обычно недостаточно: заявки могут уходить через отдельный почтовый сервис, домен — продлеваться в другом аккаунте, а код — храниться у прежнего разработчика. Эта памятка поможет собрать всё в одном документе. Она подходит для сайтов на разных CMS, конструкторах и собственной разработке; конкретный способ передачи зависит от платформы. ## Сначала определите, что именно передаёте Передача на поддержку, перенос на другой хостинг и передача прав на домен — разные задачи. Смена исполнителя сама по себе не требует менять сервер или переписывать сайт. Сначала зафиксируйте цель: например, принимать заявки без сбоев, обновлять информацию и устранять ошибки в согласованном объёме. Составьте короткое описание сайта: - Для чего он нужен: заявки, продажи, запись на услуги, публикация материалов. - Какие функции критичны: форма, личный кабинет, корзина, оплата, поиск, языковые версии. - Что сейчас работает неправильно и какие изменения уже начаты. - Кто принимает решения и кто подтверждает результат работ. Если сайт уже недоступен, начните с диагностики сбоя и сохранения текущих данных. Полную передачу можно завершить после восстановления основных функций. Для сбоя именно после обновления WordPress есть отдельная [памятка по первым проверкам](https://asgru.com/ru/wordpress-ne-rabotaet-posle-obnovleniya/). ## Что запросить у прежнего исполнителя Используйте таблицу как перечень для своего сайта. Ненужные строки уберите, неизвестные отметьте «требует проверки». Не подставляйте предположение вместо подтверждённого владельца аккаунта. КомпонентЧто должно быть понятно при передачеДомен и DNSГде зарегистрирован домен, кто управляет аккаунтом и записями DNS, куда приходят уведомления о продлении.Хостинг или платформаГде работает сайт, кто оплачивает услугу, как новый специалист получает доступ в нужном объёме.CMS, код и файлыАдрес входа, роли пользователей; для собственной разработки — репозиторий и инструкция запуска или развёртывания.Резервные копииДата, состав, место хранения, порядок получения и результат проверки восстановления.Формы и почтаКуда должны приходить заявки, какой сервис отправляет письма и кто управляет им.ИнтеграцииCRM, платежи, доставка и другие связи: назначение, ответственные и место управления доступом.Лицензии и подпискиЧто оплачивается отдельно, на кого оформлено и можно ли продолжать использование после смены подрядчика.Аналитика и история работКакие системы подключены, кто имеет доступ, где хранятся задания, изменения и известные ограничения. Отдельно попросите перечень ручных настроек и незавершённых задач. Фраза «всё в админке» не объясняет, откуда берётся резервная копия и почему уведомления зависят от личного аккаунта бывшего сотрудника. ## Сохраните собственный контроль над аккаунтами У владельца бизнеса должен оставаться доступ к ключевым сервисам и возможность восстановить его без участия одного конкретного подрядчика. Проверьте контактную почту, способы восстановления и получение уведомлений о продлении. Для домена полезно свериться с [рекомендациями ICANN по защите аккаунта регистратора](https://www.icann.org/en/groups/ssac/documents/sac-044-en.pdf). Там, где сервис поддерживает отдельных пользователей, предоставляйте исполнителю собственную учётную запись с правами под задачу. Не передавайте личный почтовый аккаунт целиком ради доступа к одному сайту. Пароли, коды восстановления и API-ключи храните отдельно от общего документа передачи; способ предоставления доступа согласуйте заранее. Для важных аккаунтов используйте доступные средства защиты: ключи доступа либо уникальный пароль с двухэтапной проверкой. После завершения передачи пересмотрите доступ прежних исполнителей. Эти меры соответствуют [рекомендациям NCSC по защите рабочих аккаунтов](https://www.ncsc.gov.uk/collection/small-organisations-guide-to-cyber-security/secure-your-important-online-accounts). Если сайт использует общие учётные данные или ключ интеграции, специалист сначала должен выяснить, какие процессы от них зависят. Их замена требует согласованного переключения и проверки: иначе вместе со старым доступом можно отключить отправку заявок. Передачу домена или аккаунта между владельцами выполняйте по правилам конкретного сервиса. ## Проверьте, что резервная копия пригодна Запись «бэкап есть» ещё не описывает, что удастся восстановить. Для сайта с отдельной базой данных уточните, входят ли в копию база, файлы и загруженные материалы. Для конструктора или облачной платформы проверьте доступные способы восстановления и ограничения экспорта: они могут отличаться от копирования обычного хостинга. Попросите зафиксировать дату копии, её состав и результат проверки восстановления в отдельном окружении, если платформа это позволяет. NCSC рекомендует не только делать копии важных данных, но и понимать, как восстановить их и проверить полноту. См. [руководство по резервному копированию](https://www.ncsc.gov.uk/collection/small-organisations-guide-to-cyber-security/backing-up-your-data). Для магазина или сайта с заявками отдельно обсудите данные, появившиеся после последней копии. Передача обслуживания не должна незаметно превратиться в откат, при котором пропадут новые заказы. Резервные копии могут содержать сведения клиентов, поэтому выдавайте к ним доступ только тем, кому он нужен для согласованной работы. ## Договоритесь, кто за что отвечает Зафиксируйте для каждой регулярной задачи исполнителя, срок или условие запуска и способ проверки. Например: - Продление домена и хостинга: кто получает уведомления, оплачивает и контролирует результат. - Резервные копии: кто следит за созданием, хранением и проверкой восстановления. - Обновления и доработки: кто согласует изменения, выполняет их и проверяет важные функции. - Ошибки: куда сообщать, кто принимает обращение и как согласуются срочные работы. - Контент: кто предоставляет факты, редактирует и публикует материалы. Не считайте, что «поддержка сайта» автоматически включает круглосуточный ответ, новые страницы, оплату лицензий или любые интеграции. Эти условия лучше перечислить явно, без догадок с обеих сторон. ## Шаблон передачи сайта Скопируйте этот блок в рабочий документ. Для каждого компонента из таблицы выше добавьте отдельную запись. Самих секретных значений здесь быть не должно. Сайт: Цель передачи: Дата и ответственный со стороны владельца: Новый исполнитель и согласованный объём работ: Компонент или сервис: Адрес сервиса / место документации: Владелец аккаунта: Ответственный за оплату и ближайшее продление: Способ предоставления доступа и нужная роль: Что передано: Что ещё отсутствует: Как проверено и кем: Статус: не начато / передаётся / проверено Резервная копия: дата, состав, где находится: Результат проверки восстановления: Известные ошибки и незавершённые изменения: Важные функции для приёмки: Кто подтверждает завершение передачи: Если данных нет, оставьте конкретную задачу и ответственного: «Выяснить, кто оплачивает сервис отправки писем». Так незакрытый вопрос не потеряется за общей отметкой «доступы получены». ## Как понять, что передача завершена Проверьте рабочий сценарий, ради которого существует сайт. Для сайта услуг это может быть отправка явно помеченной тестовой заявки и её получение нужным человеком. Для магазина — согласованный тест заказа, доставки и оплаты в предусмотренном для этого режиме. Перед закрытием передачи подтвердите: - Владелец контролирует ключевые аккаунты и получает важные уведомления. - Новый исполнитель получил нужные права и документацию. - Критичные функции проверены, обнаруженные ошибки записаны. - Состав и доступность резервных копий понятны; результат проверки восстановления зафиксирован либо отсутствие такой проверки прямо отмечено. - Незавершённые задачи, продления и границы поддержки имеют ответственных. - Ненужные доступы пересмотрены; изменение общих ключей выполнено с проверкой зависимых функций. Условный пример. Компания передаёт небольшой сайт услуг. Новый специалист вошёл в CMS, но тестовая заявка не пришла. Выясняется, что отправка писем зависит от отдельного сервиса, которым управлял прежний подрядчик. Задача передачи остаётся открытой до предоставления нужного доступа и проверки доставки. Это учебный сценарий, а не описание клиентского проекта. ## Частые вопросы ### Нужно ли менять хостинг при смене подрядчика? Не обязательно. Сначала выясните, может ли новый исполнитель работать с текущим размещением и соответствует ли оно задачам сайта. Перенос стоит оценивать как отдельную работу со своими причинами, этапами и проверками. ### Что делать, если прежний разработчик не отвечает? Соберите то, что уже есть у компании: счета, контакты сервисов, собственные учётные записи и документы по проекту. Восстановление доступа обсуждайте с поддержкой соответствующего сервиса; новый подрядчик не может гарантировать получение чужого аккаунта или отсутствующих исходников. Недоступные компоненты внесите в перечень ограничений. ### Достаточно ли передать архив сайта? Архив может быть лишь частью передачи. Нужно понимать его состав, дату, способ запуска и зависимость от внешних сервисов. На некоторых платформах важнее передача роли в аккаунте и документации, чем набор файлов. ### Сколько стоит передача на поддержку? Объём зависит от документации, доступов, количества интеграций и состояния сайта. Для оценки подготовьте URL, цель передачи и список известных ограничений. Если нужна помощь, [пришлите адрес сайта и опишите задачу поддержки](https://asgru.com/ru/tehnicheskaya-podderzhka-sajta/).