Как принять сайт у разработчика: чек-лист для заказчика

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

Начните с согласованного результата

Откройте договор, смету и последнее согласованное техническое задание. Отдельно выпишите:

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

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

1. Проверьте путь реального пользователя

Пройдите сайт так, как это сделает клиент:

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

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

2. Посмотрите мобильную версию и контент

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

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

3. Проверьте интеграции на контрольных данных

Список зависит от проекта, но обычно стоит проверить:

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

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

4. Убедитесь, что бизнес владеет проектом

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

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

5. Проверьте техническую готовность к поиску и измерениям

На приёмке не требуется обещать позиции в поиске. Но должны работать базовые условия, без которых продвижение и аналитика невозможны:

• один понятный H1 на ключевой странице;
• уникальные title и description там, где это предусмотрено;
• корректные canonical, robots.txt и sitemap.xml;
• рабочая страница 404 и корректные коды ответа;
• подключённые счётчики и проверенные цели;
• перенаправления со старых URL, если сайт переносился;
• отсутствие тестовых страниц и демо-контента в индексе.

Попросите показать эти пункты на production, а не только в локальной копии. При переносе отдельной строкой нужен список старых и новых URL с результатом проверки редиректов.

6. Резервная копия, тестовый контур и откат

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

Не путайте наличие архива с готовностью к восстановлению. Важный вопрос: когда копию последний раз восстанавливали и можно ли сделать это без поиска паролей и пропавших доступов.

Таблица приёмки

Что делать, если часть работ не готова

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

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

Для сайта на 1С-Битрикс с накопленными проблемами можно заказать доработку после технической оценки.