Как принимать сайт: сценарии и доказательства вместо «всё готово»

Главная ошибка приёмки — впервые обсуждать смысл слова «готово», когда сайт уже собран. До старта выпишите несколько действий, ради которых проект существует: найти подходящую услугу, получить информацию о товаре, отправить запрос, обновить условия в CMS. У каждого действия должны быть исходные условия, ожидаемый результат и ответственный за проверку.

Учебный пример строки: «Новый посетитель открывает услугу с телефона, выбирает тип проекта и отправляет корректный контакт. Рабочая система подтверждает получение; посетитель видит согласованный текст, менеджер получает контекст». Результат зависит от выбранного контракта доставки.

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

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

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

Для каталога важны пустая категория, длинное название, отсутствующее фото и снятая с продажи позиция. В опубликованном кейсе Milerd есть каталог, варианты товара, корзина и панель управления: эти разные сценарии показывают, почему «страница выглядит правильно» — лишь часть приёмки.

Согласуйте браузеры, устройства и ширины до тестирования. Пройдите основной сценарий на телефоне, с экранной клавиатурой и только клавишами Tab, Shift+Tab и Enter. Проверьте видимость фокуса, закрытие диалогов, длинный текст и поведение при уменьшении анимации. Автоматический отчёт не заменяет этот проход.

Для скорости сохраните условия лабораторного замера: страницу, устройство, сеть и версию сайта. Core Web Vitals различают лабораторные и полевые данные. Хороший результат одного запуска не подтверждает опыт всех посетителей; отсутствие полевых данных означает недостаток измерений, а не идеальную скорость.

Если это редизайн, составьте таблицу старых адресов и их новых эквивалентов. Проверяйте важные услуги, кейсы и статьи, а не только главную. Не перенаправляйте несвязанные страницы в один раздел ради отсутствия 404: Google предупреждает, что такие перенаправления могут восприниматься как soft 404.

В приёмке отделите HTTP-доступность, canonical, языковые версии и отсутствие случайного noindex от фактического попадания в индекс. Индексация и поисковые позиции не становятся гарантированным результатом релиза. Доступ к Search Console и Вебмастеру позволяет наблюдать следующий этап, но не отменяет это ограничение.

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

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