Главная / ПриёмкаПриёмка

Что проверить перед запуском сайта

Проверка пути клиента, ошибок, содержимого и передачи проекта на фактическом домене.

Коротко

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

Макет сайта проверяют вместе с телефоном, конвертом заявки и архивной копией.
Редакционная иллюстрация OBSION.

Определите, что считается готовым результатом

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

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

Пройдите путь обращения до места обработки

Отправьте заявку с безопасными тестовыми данными и найдите её в согласованной системе: CRM, панели или другом рабочем канале. Проверьте услугу, контакт и комментарий. Убедитесь, что ответственному сотруднику понятно следующее действие. Если уведомление приходит отдельно от хранилища, проверьте оба результата. Потеря уведомления и потеря самой записи требуют разных мер, и их нельзя смешивать одним сообщением на экране.

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

Пять уровней проверки запуска. Путь клиента — Конкретная задача от входа до результата; Ошибки — Неверный ввод, повтор, потеря сети; Телефон — Клавиатура, меню, длинный контент; Публичный домен — Форма, ссылки и поисковый режим; Передача — Доступы, инструкция, восстановление.
Пять уровней проверки запуска. Практическая схема OBSION.

Проверьте неудобные ситуации

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

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

Откройте сайт на настоящем телефоне

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

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

Что доказательство подтверждает. Красивый экран — Только внешний вид состояния; Сборка прошла — Код собрался в данном окружении; Появилось «отправлено» — Интерфейс показал сообщение; Заявка у сотрудника — Проверен результат этого сценария.
Что доказательство подтверждает. Практическая схема OBSION.

Сверьте содержание, ссылки и поисковый режим

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

После согласованного открытия поиска используйте инструменты вебмастеров для наблюдения за доступностью страниц. Google описывает работу Search Console как способ проверки поискового состояния, а не гарантию индексации каждого URL. Не обещайте моментальное появление всех страниц или определённые позиции. Отдельно согласуйте аналитику и обработку данных: наличие счётчика в коде ещё не означает, что весь путь события и выбранные условия его работы проверены.

Получите проект и план дальнейшей работы

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

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

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

Что проверить в своей задаче

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

Источники и документация

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

Редакция OBSION

Практические материалы студии о сайтах, ботах и развитии цифровых продуктов.

Разборы на YouTube

Разобрать вашу ситуацию

Пришлите сайт или опишите идею. Начнём с бесплатного разбора.

Написать в OBSION ↗
← Все статьи блога
Начнём с разговора

Расскажите задачу.
Разберём по делу.

Не нужно готовить подробное ТЗ. Достаточно описать идею, проблему или прислать ссылку на текущий сайт.

Можно сразу в Telegram ↗Без менеджера между нами

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