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

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

Приемка — не поиск поводов отложить оплату. Это управляемая проверка соответствия договору, техническому заданию и реальным задачам пользователя. В профессиональном процессе критерии заранее известны обеим сторонам, дефекты можно воспроизвести, а готовность к запуску не зависит от фразы «у меня всё работает».

Если проект только планируется, включите критерии приемки в объем разработки сайта под ключ. Если сдача уже близко, используйте этот материал как основу совместной проверки с командой.

Что означает «принять сайт»

Приемка подтверждает четыре результата:

1. согласованный объем работ выполнен;
2. критические пользовательские и бизнес-сценарии работают;
3. заказчик контролирует активы и учетные записи;
4. известны ответственные и сроки исправлений после запуска.

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

Не оценивайте готовность только по проценту закрытых задач. Один критический дефект важнее двадцати исправленных отступов.

Шаг 1. Подготовьте проверяемую основу

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

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

Создайте таблицу приемки с полями:

• номер и название проверки;
• URL или экран;
• устройство и браузер;
• ожидаемый результат;
• фактический результат;
• приоритет;
• скриншот или видео;
• ответственный;
• срок повторной проверки;
• статус.

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

Шаг 2. Тестируйте в правильной среде

Основную проверку удобно проводить на staging-версии, закрытой паролем и от индексации. Но финальная приемка требует короткого повторного теста на боевом домене: при переносе меняются DNS, TLS, пути к файлам, кеш, почта, callback URL платежей и редиректы.

Зафиксируйте версию сборки или точное время начала тестирования. Иначе исправления во время проверки не позволят понять, какую версию заказчик фактически принимает.

На production убедитесь, что:

• домен открывает нужную инфраструктуру;
• HTTPS работает без предупреждений;
• ресурсы загружаются безопасно;
• staging недоступен поисковым роботам;
• production не закрыт паролем или оставшимся noindex;
• непосредственно перед переносом создана резервная копия.

Мощность сервера, TLS и резервное копирование следует согласовать вместе с хостингом для сайта, а не после первого инцидента.

Шаг 3. Пройдите полные пользовательские сценарии

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

поиск или реклама → посадочная страница → доказательство доверия → форма → подтверждение → CRM → ответ менеджера

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

Каждый важный сценарий проверьте с:

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

Система должна не только принять правильные данные, но и понятно объяснить ошибку, по возможности сохранив уже введенную информацию.

Шаг 4. Проверьте страницы и навигацию

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

Проверьте:

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

Инструменты BB STUDIO помогут проверить коды ответа, редиректы и данные домена. Автоматический обход полезен, но не заменяет ручного прохождения сценариев.

Шаг 5. Сравните интерфейс с макетами

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

При проверке UI/UX-дизайна сайта оцените:

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

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

Шаг 6. Используйте реальные телефоны и поддерживаемые браузеры

Эмуляция устройств полезна в разработке, однако финальный проход нужен минимум на реальных iPhone и Android. Проверьте актуальные Chrome, Safari, Firefox и Edge согласно согласованной матрице поддержки.

На мобильном отдельно протестируйте:

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

Горизонтальный скролл на одном шаблоне часто указывает на широкую таблицу, фиксированную ширину, длинное слово или сторонний виджет. Зафиксируйте URL и ширину экрана.

Шаг 7. Проследите путь каждой заявки

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

Для каждой формы проверьте:

1. обязательные и необязательные поля;
2. валидацию телефона и email;
3. понятные сообщения об ошибках;
4. защиту от повторной отправки;
5. согласие с политикой конфиденциальности;
6. доставку на правильный ящик;
7. создание лида в CRM;
8. источник, UTM, страницу входа и название формы;
9. назначение ответственного;
10. подтверждение клиенту, если оно предусмотрено.

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

Если обращения поступают только в личную почту или чат разработчика, процесс еще не передан бизнесу.

Шаг 8. Проверьте контент и локализации

Вычитайте не только главную. Включите услуги, политики, автоматические письма, валидацию, 404, поиск, корзину, кабинет и метаданные.

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

Убедитесь, что:

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

Шаг 9. Проверьте готовность к поиску

SEO-ошибки могут быть незаметны посетителю, но мешают поисковикам обходить и понимать сайт. Для каждой индексируемой страницы проверьте уникальные Title, Description, H1, читаемый URL, canonical и ответ 200.

Также проверьте:

• robots.txt не блокирует важные разделы;
• XML sitemap содержит только канонические индексируемые URL;
• staging и параметрические дубли закрыты;
• старые URL перенаправляются без цепочек;
• hreflang взаимный и связывает эквивалентные языковые страницы;
• структурированные данные соответствуют видимому контенту;
• внутренние ссылки не ведут на 404, 5xx и ненужные редиректы;
• фильтры и поиск не создают неконтролируемую индексацию;
• важный контент доступен без действия, которое робот не может выполнить.

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

Шаг 10. Оцените скорость и стабильность

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

Оцените:

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

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

Шаг 11. Закройте базовые риски безопасности и приватности

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

Убедитесь, что:

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

Передавайте доступы через менеджер паролей и смените временные данные после завершения проекта.

Шаг 12. Проверьте аналитику и конверсии

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

Проверьте:

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

Отправьте одну заявку с тестовыми метками и проследите ее в браузере, аналитике и CRM. Такая сквозная проверка часто выявляет разрывы между системами.

Шаг 13. Получите права собственности и документацию

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

Заказчик должен контролировать:

• регистратора домена и DNS;
• хостинг или облако;
• главного администратора CMS;
• репозиторий и историю версий;
• базу и резервные копии;
• аналитику, Search Console и Tag Manager;
• рекламу и CRM;
• корпоративную почту и рассылки;
• платежные, картографические и другие интеграции;
• исходники дизайна, шрифты и лицензии.

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

Шаг 14. Описывайте дефекты воспроизводимо

Фраза «форма не работает» создает лишнюю переписку. Полезный баг-репорт содержит:

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

Пример: «На iPhone 15 в Safari после отправки валидных данных на /contact/ остается бесконечный loader; письмо и лид в CRM не создаются». Это намного полезнее, чем «на телефоне что-то зависает».

Не смешивайте дефект и новую функцию. Если реализация соответствует утвержденному требованию, но желаемая логика изменилась, оформите change request и оцените его отдельно.

Шаг 15. Повторите проверку после публикации

После исправлений тестируйте не только конкретный пункт, но и соседние функции. Изменение валидации может затронуть CRM, редирект — языковые версии, оптимизация скриптов — оплату.

После переноса выполните production smoke test:

1. главная и ключевые посадочные открываются;
2. HTTPS и редиректы корректны;
3. меню и основные кнопки работают;
4. тестовая заявка доходит ответственному;
5. оплата проходит в нужном режиме;
6. аналитика фиксирует событие;
7. production доступен для индексации;
8. sitemap и robots открываются;
9. создана резервная копия после запуска;
10. мониторинг доступности активен.

В первые 72 часа контролируйте 404 и 5xx, ошибки JavaScript, доставку писем, заявки, платежи, ресурсы и индексацию. Канал для срочных инцидентов определите заранее.

Готовый чек-лист заказчика

Объем и доказательства

• Страницы и функции соответствуют договору и ТЗ.
• Изменения после старта зафиксированы.
• Критерии приемки и гарантия известны.
• Дефекты распределены по приоритетам.

Сценарии и контент

• Критические маршруты пройдены от начала до конца.
• Формы, письма, CRM и подтверждения проверены.
• Контакты, цены, условия и тексты актуальны.
• Нет заглушек и битых ссылок.
• Несуществующий URL возвращает 404.

Устройства и качество

• Проверены реальные iPhone и Android.
• Проверены поддерживаемые браузеры.
• Нет перекрытых элементов и лишнего горизонтального скролла.
• Пустые состояния, загрузка и ошибки понятны.

Поиск, данные и безопасность

• Title, H1, canonical, robots и sitemap корректны.
• Редиректы со старых URL проверены.
• События и конверсии доходят до аналитики.
• Production индексируется, staging закрыт.
• HTTPS, роли, резервные копии и формы проверены.

Передача

• Компания контролирует домен, хостинг и CMS.
• Переданы код, база, макеты, лицензии и инструкции.
• Временные пароли изменены.
• Согласованы поддержка, SLA и аварийный контакт.
• Проведен повторный тест на production.

Как принять решение о финальной оплате

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

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

Вывод

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

Лучший формат сдачи — совместная сессия. Подрядчик демонстрирует выполнение, заказчик проходит бизнес-маршруты, а каждое отклонение попадает в единый реестр. Тогда запуск становится управляемым переходом, а не прыжком из тестовой среды в живые продажи.