Документация к сайту: что должен передать разработчик после запуска

Сайт уже работает, заявки идут, доступы у вас на руках, и кажется, что проект можно закрыть. Но через 2-3 месяца выясняется, что нельзя быстро поменять баннер, неясно, где хранятся резервные копии, а подрядчик отвечает только за платные доработки. Именно поэтому документация к сайту после запуска нужна не «для галочки», а чтобы бизнес не зависел от памяти одного человека.

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

Что входит в документацию к сайту после запуска

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

В практике студии RDMN мы рекомендуем фиксировать не только доступы, но и логику, по которой устроен сайт. Например, где меняются тексты, как обновляются товары, кто отвечает за формы, что делать при сбое почты и где лежит резервная копия. Без этого даже простой сайт через месяц превращается в набор загадок.

Базовый комплект передаваемых материалов

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

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

Какие доступы и права нужно передать

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

Если подрядчик оставляет сервисы на своих аккаунтах, попросите перенести их на ваши. Это особенно важно для домена, почты и аналитики. Иначе при конфликте, смене исполнителя или простой технической проблеме вы можете потерять доступ к критичным данным.

Инструкция по управлению сайтом, без неё контент быстро ломается

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

В документации должны быть описаны типовые действия, которые бизнес делает чаще всего. Не нужно писать трактат, достаточно понятной инструкции на 10-20 страниц или набора коротких видео по 1-3 минуты. Это особенно полезно для корпоративных сайтов, каталогов и интернет-магазинов.

Что обязательно описать в инструкции

• как менять тексты на главной и внутренних страницах;
• как добавлять и удалять изображения;
• как создавать новые страницы и карточки товаров;
• как редактировать меню, шапку, подвал и блоки контактов;
• как проверять формы и уведомления;
• как публиковать статьи и новости;
• как действовать, если что-то не сохраняется или отображается некорректно.

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

Описание интеграций и внешних сервисов

Сайт редко живёт сам по себе. Обычно он связан с CRM, почтой, мессенджерами, рекламой, аналитикой, онлайн-оплатой, складом или телефонией. Если не зафиксировать, что и как подключено, через некоторое время никто не вспомнит, почему заявки не доходят до менеджеров или почему перестала работать оплата.

В документации стоит собрать список всех внешних сервисов с указанием аккаунта, назначения и ответственного. Для каждого сервиса нужны хотя бы краткая схема подключения и логика проверки. Это помогает быстро найти точку сбоя и не искать проблему методом перебора.

• CRM и передача заявок;
• почтовые сервисы и уведомления;
• виджеты обратного звонка и чата;
• сервисы онлайн-оплаты;
• карты, схемы проезда, виджеты отзывов;
• рекламные пиксели и счётчики аналитики;
• интеграция с 1С, складом или внешним каталогом.

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

Резервные копии, обновления и безопасность

После запуска сайта важно не только пользоваться им, но и понимать, как он защищён. Часто проблемы появляются не из-за дизайна, а из-за того, что не обновился модуль, закончился срок сертификата, слетела резервная копия или кто-то случайно удалил важный файл. В документации это должно быть описано без сложных терминов, простым языком.

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

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

Что проверить в блоке безопасности

1. сменены ли временные пароли после сдачи проекта;
2. есть ли двухфакторная защита там, где это возможно;
3. кто получает уведомления о сбоях и истечении оплаты;
4. обновляются ли CMS, плагины и шаблоны по регламенту;
5. есть ли инструкция по восстановлению сайта из копии.

Что должно быть в отчётности по запуску и настройке аналитики

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

Если сайт делали под продажи, а не просто «чтобы был», проверьте, видит ли бизнес ключевые действия пользователя: отправку формы, клик по телефону, переход в мессенджер, заказ звонка, добавление товара в корзину. Это основа для оценки эффективности рекламы и SEO. Если этого нет, позже придётся заказывать отдельный SEO-аудит и настройку аналитики, чтобы понять, где теряются заявки.

Сроки, формат и ответственность, как это должно быть оформлено

Хорошая передача сайта после запуска всегда фиксируется письменно. Это может быть отдельный акт, приложение к договору или чек-лист с подписями сторон. Главное, чтобы было понятно, что именно передано, в каком виде и кто за что отвечает дальше.

По рынку передача комплекта документов и доступов обычно занимает от 1 до 5 рабочих дней после финального запуска, если проект не сложный. Для интернет-магазинов, многостраничных сайтов и проектов с интеграциями срок может быть дольше, потому что нужно проверить все сервисы и оформить инструкции без ошибок.

Хороший документ о передаче отвечает на 5 вопросов

• что именно было сделано и сдано;
• какие доступы переданы и кому;
• какие сервисы подключены и кто их администрирует;
• какие действия бизнес может делать сам;
• в каких случаях подключается подрядчик и на каких условиях.

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

Типичные ошибки после запуска сайта

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

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

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

Частые вопросы

Нужна ли документация для простого лендинга?

Да, хотя она будет короче, чем для корпоративного сайта. Минимум, который нужен, это доступы, схема форм, инструкция по редактированию и список подключённых сервисов. Даже у простого лендинга часто есть аналитика, почта и уведомления, которые важно не потерять.

Можно ли принять сайт без инструкции, если всё и так работает?

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

Кто должен готовить документацию, разработчик или заказчик?

Обычно готовит подрядчик, а заказчик проверяет, что всё понятно и полно. Бизнесу не нужно писать технические детали с нуля, но нужно убедиться, что материалы отвечают на его рабочие вопросы: как управлять, куда писать, что делать при сбое.

Нужно ли хранить документацию отдельно от сайта?

Да. Лучше держать копию в облачном хранилище, в корпоративной почте и у ответственного сотрудника. Если всё лежит только в одном кабинете, доступ к которому может пропасть, документ теряет смысл.

Что делать, если подрядчик отказывается передавать часть данных?

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

Сколько времени занимает подготовка нормального комплекта?

Для небольшого сайта это обычно 1-2 дня после завершения работ. Для сложного проекта с каталогом, интеграциями и несколькими ролями пользователей может потребоваться до недели, чтобы всё проверить и описать без пропусков.

Что делать: короткий план

1. Проверьте, что домен, хостинг, почта, аналитика и CMS оформлены на вашу компанию или на доступный вам аккаунт.
2. Попросите полный список сервисов, подключённых к сайту, с указанием логинов, ролей и ответственных.
3. Получите инструкцию по типовым действиям, которые вы будете делать сами: тексты, картинки, страницы, заявки.
4. Уточните, где хранятся резервные копии, как часто они создаются и кто умеет восстановить сайт.
5. Проверьте, настроены ли цели, события и уведомления по заявкам.
6. Сверьте, совпадает ли фактическая передача с договором и актом.
7. Сохраните копию всех материалов в отдельном месте, доступном вам без участия подрядчика.

Если сайт только планируется, обсудите пакет документов ещё на этапе договора, а не после запуска. В этом случае проще зафиксировать состав работ, сроки и формат передачи. А если сайт уже есть, но документации нет или она неполная, разумно заказать разбор и доработку, чтобы закрыть слабые места до того, как они начнут мешать продажам.