Главная страница открывается, меню работает, тексты согласованы — и проект кажется готовым. Но первый рекламный переход может закончиться не созданной заявкой, потерянной UTM-меткой или формой, которая сообщает об успехе, хотя CRM ничего не получила. Поэтому приёмка сайта перед запуском — это не финальный просмотр макетов. Это проверка всей цепочки от клика пользователя до бизнес-результата.
Ниже — порядок, по которому заказчик может принять корпоративный сайт без попытки за один вечер проверить каждую кнопку вручную. Задача проверки — найти критичные дефекты до открытия трафика, зафиксировать доказательства и принять осознанное решение: запускать, запускать с ограничениями или переносить релиз.
Что считать готовым сайтом
Готовность определяется не количеством закрытых задач в трекере, а работоспособностью согласованных сценариев. Для сайта услуг это обычно просмотр ключевой страницы, переход к форме, отправка заявки, создание записи в CRM, уведомление ответственного и фиксация источника. Для каталога добавляются поиск, фильтры и карточки. Для личного кабинета — авторизация, права и операции с данными.
До проверки соберите короткий перечень критичных маршрутов. У каждого должны быть владелец, ожидаемый результат и понятный способ подтвердить результат. Фраза «вроде работает» не годится: подтверждением может быть HTTP-статус, скриншот, запись в CRM, событие аналитики или письмо на контрольный адрес.
| Контур | Что проверяем | Доказательство | Критичность |
|---|---|---|---|
| Пользовательский путь | Переход от страницы услуги к целевому действию | Сценарий пройден на телефоне и компьютере | Высокая |
| Формы и CRM | Отправку, валидацию, согласие, источник и ответственного | Тестовая заявка появилась в нужной сущности CRM | Критическая |
| Аналитика | Просмотры, цели и ключевые события | События видны в отладочном или реальном отчёте | Высокая |
| Поиск | Canonical, robots, sitemap, статусы и метаданные | Автоматический отчёт без блокирующих ошибок | Высокая |
| Эксплуатация | Логи, резервирование и откат | Назначены ответственные и проверен план возврата | Критическая |
Шаг 1. Зафиксировать область релиза
Приёмка быстро превращается в хаос, если параллельно меняются тексты, дизайн и интеграции. Сначала зафиксируйте версию: какой commit или build проверяется, какие страницы входят в релиз, что сознательно отложено и какие внешние системы подключены. Дефект должен относиться к конкретной версии, иначе повторная проверка не докажет, что исправление попало на production.
Сопоставьте результат с техническим заданием и критериями готовности. Для проектов с CRM и 1С полезно свериться с материалом о техническом задании на сайт с интеграциями: в нём особенно важны владельцы данных, правила повторной отправки и обработка ошибок.
Шаг 2. Пройти критичные пользовательские сценарии
Начинайте не со списка браузеров, а с задач посетителя. Откройте сайт как новый пользователь: найдите услугу из меню и поиска, сравните предложение, откройте кейс, вернитесь назад, нажмите CTA, заполните форму, исправьте ошибку в поле и отправьте данные. Повторите ключевой путь на узком мобильном экране.
Проверяйте не только успешный сценарий. Пустая форма должна объяснять ошибку, длинное имя не должно ломать сетку, двойной клик не должен создавать две заявки, а повторная отправка после сетевого сбоя — вести к предсказуемому результату. Ссылки, открывающиеся в новой вкладке, не должны уводить на тестовый домен.
Шаг 3. Проверить формы до конечной системы
Сообщение «Заявка отправлена» подтверждает только состояние интерфейса. Приёмка заканчивается там, где заявка появилась в CRM или другой системе обработки. Для каждой основной формы отправьте отдельный тест с легко узнаваемой пометкой и проверьте сущность, ответственного, телефон, email, страницу отправки, источник и рекламные метки.
Проверьте согласие на обработку данных и ссылку на документ рядом с формой. Не помещайте реальные персональные данные в тест: достаточно нейтральных значений, согласованных для проверки. Убедитесь, что логи не записывают содержимое заявки и секреты интеграции. Если соединение с CRM временно недоступно, система должна вернуть контролируемую ошибку или поставить доставку в предусмотренную очередь, а не молча потерять обращение.
Шаг 4. Убедиться, что аналитика отвечает на бизнес-вопросы
Счётчик на странице ещё не означает корректную аналитику. Проверьте, что ключевые события имеют стабильные названия, не срабатывают дважды и связаны с реальным действием. Отдельно сравните отправку формы, успешное создание заявки и клик по контактному каналу: это разные события и смешивать их в одну «конверсию» неудобно.
Если сайт передаёт UTM-метки в CRM, пройдите тестовый URL с безопасными метками и проверьте их в карточке. Настройка должна переживать переход между страницами и не подменять исходный источник при внутренних переходах. До старта рекламы сохраните контрольный отчёт: после запуска он станет точкой сравнения.
Шаг 5. Проверить мобильную версию и доступность действий
Мобильная проверка — не уменьшенное окно браузера на широком мониторе. Нужны хотя бы реальные или эмулированные ширины для небольшого телефона, современного смартфона, планшета и настольного экрана. Проверьте меню, таблицы, длинные заголовки, формы, модальные окна, cookie-настройки и закреплённые CTA.
Критичный признак готовности — отсутствие горизонтального прокручивания страницы. Кнопки должны быть доступны пальцем, фокус клавиатуры — заметен, подписи полей — понятны, а сообщение об ошибке — связано с конкретным полем. Изображения не должны перекрывать текст или вызывать резкий сдвиг первого экрана.
Шаг 6. Оценить скорость там, где она влияет на сценарий
Один высокий балл в лабораторном тесте не заменяет проверку реального маршрута. Измерьте главную, ключевую услугу, тяжёлую статью и страницу с формой. Смотрите на стабильность первого экрана, задержку реакции после действия и загрузку основного содержимого. Разбор показателей есть в статье про Core Web Vitals корпоративного сайта.
Особенно внимательно проверьте сторонние виджеты, аналитику, карты и защиту форм. Они могут не мешать на тестовом контуре, но замедлять production из-за сетевых запросов. Если необязательный сервис недоступен, основной контент и отправка заявки должны продолжать работать по согласованному сценарию.
Шаг 7. Выполнить поисковую проверку
У каждой индексируемой страницы должны быть уникальные Title и Description, один H1, корректный canonical и ответ 200 без лишней цепочки перенаправлений. Тестовые и служебные маршруты, наоборот, не должны попадать в индекс. Проверьте robots.txt и XML-карту сайта, затем сопоставьте URL в sitemap с каноническими адресами.
Если менялись адреса, составьте явную таблицу «старый URL — новый URL» и настройте постоянные редиректы на релевантные страницы. Не отправляйте десятки старых адресов на главную. После запуска обновите внутренние ссылки и sitemap. Для проектирования набора страниц полезно заранее проверить SEO-структуру корпоративного сайта, а при редизайне — отдельный чек-лист сохранения поисковых сигналов.
Шаг 8. Проверить безопасность и эксплуатацию
Перед релизом убедитесь, что секреты не попали в клиентский JavaScript, репозиторий или публичные логи. Административные маршруты должны требовать авторизацию, формы — ограничивать размер и формат входных данных, а серверные ответы — не раскрывать детали инфраструктуры. Обновления зависимостей и результаты security-тестов фиксируются вместе с версией релиза.
Назначьте ответственных за мониторинг 5xx, недоступность формы и ошибки интеграций. Должен существовать проверяемый способ вернуться на предыдущую стабильную версию. Откат нужен не для каждого косметического дефекта, но команда должна заранее знать, какие события делают его обязательным.
Условный сценарий приёмки
Рассмотрим условный пример. Компания запускает корпоративный сайт с пятью услугами и передачей заявок в CRM. Команда фиксирует build, выбирает три критичных маршрута и отправляет тестовые заявки с разных страниц. Одна заявка создаётся без источника, а мобильное модальное окно нельзя закрыть на узком экране.
Оба дефекта получают высокий приоритет: первый ломает аналитику и распределение, второй блокирует пользователя. Цвет иконки в футере относят к низкому приоритету. После исправлений команда повторяет только затронутые сценарии и короткий регрессионный набор, сохраняет доказательства и открывает трафик по согласованному времени. Такой подход отделяет решение о запуске от субъективного ощущения «сайт выглядит готовым».
Типичные ошибки при приёмке
- Проверять только главную. Основной риск часто находится в форме, интеграции или глубокой посадочной странице.
- Смешивать пожелания и дефекты. Новый блок можно поставить в backlog, а потеря заявки блокирует запуск.
- Тестировать без номера версии. Нельзя доказать, что проверяли именно тот build, который опубликован.
- Использовать только успешные данные. Пустые, длинные и повторные вводы выявляют больше проблем.
- Не готовить откат. Исправление в момент аварии занимает дольше, чем возврат на проверенный release.
- Считать sitemap гарантией индексации. Карта помогает обнаружению URL, но не заменяет доступность, внутренние ссылки и качественный контент.
Чек-лист решения о запуске
- Зафиксированы commit, build и состав релиза.
- Критичные пользовательские маршруты пройдены на desktop и mobile.
- Все основные формы создали корректные тестовые записи в CRM.
- Согласие, ошибки полей и повторная отправка работают предсказуемо.
- Ключевые события аналитики не дублируются.
- Title, Description, H1, canonical, robots и sitemap проверены.
- Внутренние ссылки и перенаправления ведут на конечные живые URL.
- Нет критичных ошибок в browser console и серверных логах.
- Назначены ответственные за мониторинг после запуска.
- Предыдущая стабильная версия доступна для отката.
Частые вопросы
Кто должен принимать сайт?
Техническую часть проверяет разработчик или QA, но бизнес-сценарии должен подтвердить представитель заказчика, который понимает, куда должна попадать заявка и что происходит с ней дальше.
Можно ли принять сайт только по дизайну?
Нет. Макеты подтверждают внешний вид, но не работу форм, CRM, аналитики, поисковых настроек и серверного контура.
Сколько времени занимает приёмка?
Срок зависит от числа уникальных сценариев и интеграций. Планировать лучше не часы «на просмотр», а набор тестов, ответственных и время на повторную проверку исправлений.
Нужно ли проверять все страницы вручную?
Критичные маршруты проверяют вручную, а повторяемые технические признаки — статусы, метаданные, ссылки и sitemap — разумно собирать автоматическими тестами.
Что действительно блокирует запуск?
Потеря заявок, ошибки оплаты или авторизации, утечка данных, массовые 5xx, закрытие важных страниц от индексации и отсутствие безопасного отката.
Нужно ли сразу отправлять новый сайт поисковым системам?
Сначала подтвердите ответы 200, canonical, robots, внутренние ссылки и sitemap. После этого используйте штатные инструменты поисковых систем и уже настроенные механизмы уведомления.
Что проверять в первые сутки после запуска?
Доступность, 5xx, формы, создание заявок, события аналитики, ошибки интеграций, скорость ключевых страниц и неожиданные 404 по реальному трафику.
Когда нужен внешний технический контроль
Независимая проверка полезна, когда сайт связан с CRM, 1С, телефонией или несколькими рекламными источниками, а внутри компании нет одного владельца всего маршрута. CTR1 разрабатывает корпоративные сайты и связывает их с бизнес-системами. Можно обсудить разработку или приёмку сайта, чтобы до запуска проверить не только интерфейс, но и путь заявки до ответственного сотрудника.
