Чтобы принять сайт у разработчика, недостаточно посмотреть главную страницу и убедиться, что кнопки нажимаются. Нужно сверить результат с согласованными требованиями, пройти ключевые сценарии, проверить передачу данных и получить доступы для дальнейшей работы. Приёмка должна отвечать на два вопроса: выполняет ли сайт свои задачи и сможет ли компания им управлять после завершения проекта.
Красивый интерфейс может скрывать неработающую форму, потерянные заказы или ограничения административной панели. Некоторые проблемы обнаруживаются только после переноса на основной домен: перестают приходить письма, не передаются события аналитики, остаётся запрет индексации.
Ниже — последовательный чек-лист проверки сайта перед приёмкой. Его можно адаптировать под лендинг, корпоративный сайт или интернет-магазин. Он помогает организовать проверку, но не заменяет профессиональное тестирование сложных интеграций и безопасности. Порядок оформления приёмки и расчётов нужно отдельно сверять с условиями вашего договора.
1. Подготовьте основу для приёмки
До проверки соберите актуальное техническое задание, согласованные макеты, список функций и письменно зафиксированные изменения. Если в ходе проекта появились дополнительные требования, отделите их от первоначального объёма. Иначе обсуждение ошибок быстро превращается в спор о том, что стороны имели в виду.
Для каждого существенного требования сформулируйте проверяемый результат. Например, вместо «сайт интегрирован с CRM» — «после отправки формы в CRM создаётся обращение с именем, телефоном, выбранной услугой и источником, если его передача предусмотрена ТЗ».
Перед началом согласуйте:
- адрес и версию сайта, которую проверяете;
- состав страниц, функций и интеграций текущего этапа;
- браузеры, устройства и роли пользователей;
- тестовые аккаунты и безопасные данные;
- срок проверки, место регистрации замечаний и ответственных;
- критерии готовности к запуску и перечень проверок после публикации.
Заказчику не нужно искать все ошибки самостоятельно. Попросите разработчика передать результаты внутренних проверок и перечислить известные ограничения. Сотрудникам, которым предстоит работать с сайтом, полезно участвовать в приёмке: менеджер проверит заказ, редактор — публикацию материала, администратор — управление доступами.
2. Сверьте сайт с ТЗ и согласованными макетами
Проверяйте не только главную, но и каждый уникальный тип страницы: услугу, категорию, карточку товара, статью, результаты поиска, личный кабинет, страницу ошибки. Отдельно учитывайте состояния без данных, с длинными названиями и с ошибками заполнения.
- Все согласованные разделы и функции присутствуют.
- Меню и ссылки ведут на нужные страницы, а не на заглушки.
- Общие элементы оформлены последовательно: кнопки, поля, заголовки, уведомления.
- Блоки и их порядок соответствуют утверждённым решениям.
- Нет тестовых текстов, чужих контактов, пустых карточек и изображений-заглушек.
- Предусмотренные ограничения отражены в интерфейсе: например, недоступный товар нельзя заказать обычным способом.
Отличайте несоответствие требованиям от новой идеи. Неработающая согласованная функция — замечание к результату. Дополнительный калькулятор, которого не было в объёме проекта, — отдельный запрос. Статус спорного пункта лучше зафиксировать до оценки сроков и стоимости.
3. Пройдите путь клиента от входа до результата
Функциональная проверка сайта должна подтверждать завершение сценария. Сообщение «Спасибо, заявка отправлена» ещё не означает, что обращение получил менеджер.
Формы обратной связи и заявки
Отправьте тестовое обращение из каждой формы: на странице услуги, в шапке, во всплывающем окне, в квизе. Начните с обычного заполнения, затем проверьте пустые обязательные поля, ошибочный email и допустимые варианты телефона.
Проследите результат на всех этапах:
- Пользователь понимает, какие данные нужны и что произошло после отправки.
- При ошибке получает понятное объяснение и может исправить данные.
- Обращение сохраняется в предусмотренной системе.
- Менеджер получает уведомление и видит нужные поля.
- Аналитика фиксирует согласованное событие без случайного дублирования.
Попросите проверить повторное нажатие кнопки и сбой доставки в CRM. Важно заранее понимать, как система обрабатывает повторную отправку и где остаётся обращение, если внешняя интеграция временно недоступна.
Каталог, корзина и оформление заказа
Для интернет-магазина пройдите полный путь: поиск товара, выбор варианта, добавление в корзину, изменение количества, расчёт доставки и оформление. Проверьте итоговую сумму, состав заказа, контакты покупателя и статусы в административной панели.
Если предусмотрены скидки, промокоды, разные типы покупателей или ограничения остатков, включите их в сценарии. Одного успешного заказа недостаточно: нужны также ситуации с отсутствующим товаром, неподходящим промокодом и недоступным способом доставки.
Оплату сначала проверяют в тестовом режиме платёжного сервиса. Отдельно тестируют отказ и отмену: неоплаченный заказ не должен получать статус оплаченного. Контрольную операцию в рабочем режиме проводят только по заранее согласованному сценарию с ответственными за платёж и его дальнейшую обработку.
Личный кабинет и разграничение доступа
Если эти функции входят в проект, проверьте регистрацию, вход, восстановление доступа, выход и просмотр заказов. Для разных ролей используйте отдельные тестовые аккаунты. Обычный пользователь не должен получать доступ к административным функциям или данным другого клиента.
4. Проверьте мобильную версию и удобство интерфейса
Уменьшение окна на компьютере полезно, но не заменяет проверку на реальном смартфоне. На устройстве по-другому работают экранная клавиатура, прокрутка, автозаполнение и открытие внешних приложений.
- Меню открывается, закрывается и не перекрывает важные действия.
- Кнопки и поля доступны для нажатия, подписи читаются.
- Клавиатура не мешает заполнить и отправить форму.
- Нет обрезанного текста и непреднамеренной горизонтальной прокрутки.
- Всплывающие окна можно закрыть, в том числе на небольшом экране.
- Телефон, почта и ссылки на мессенджеры ведут к ожидаемому действию.
Проведите базовую проверку доступности: пройдите интерфейс клавишей Tab, проверьте видимый фокус, подписи полей и читаемость при увеличении масштаба. Такие проверки входят в рекомендации W3C для первичной оценки доступности, но не подтверждают соответствие всем требованиям доступности.
Набор браузеров и устройств определяйте по аудитории и условиям проекта. Формулировка «работает везде» не заменяет конкретный перечень проверенных сочетаний.
5. Оцените контент и работу административной панели
Сайт может хорошо выглядеть на подготовленных разработчиком данных, но ломаться при обычном редактировании. Поэтому часть приёмки должен выполнить сотрудник, который будет наполнять страницы.
Попросите его самостоятельно:
- создать и отредактировать материал;
- заменить изображение и проверить его отображение;
- изменить цену или характеристики товара, если это предусмотрено;
- добавить ссылку и документ для скачивания;
- сохранить черновик, опубликовать и скрыть запись;
- заполнить SEO-поля, доступные для редактирования.
Используйте реалистичные данные: длинное название, несколько изображений, разные объёмы описания. Проверьте, что вёрстка не нарушается, а опубликованные изменения действительно появляются на сайте.
Отдельно сверьте контакты, реквизиты, цены, условия обслуживания и описание услуг. Содержание документов о работе с пользователями и их данными должно быть согласовано ответственными со стороны бизнеса. Приёмка интерфейса не заменяет проверку этих документов.
6. Проверьте техническую готовность и базовые настройки SEO
Заказчику необязательно разбирать серверную конфигурацию. Но нужно получить понятный отчёт о проверках и убедиться, что основные страницы и сценарии работают на рабочем домене.
Доступность страниц и скорость
Проверьте HTTPS без предупреждений браузера, отсутствие битых внутренних ссылок, корректное отображение изображений и файлов. Несуществующий адрес должен отдавать корректную страницу ошибки, а не маскироваться под обычную успешную страницу.
Попросите измерения скорости для нескольких типов страниц с указанием условий проверки. Один скриншот с высоким баллом не подтверждает качество всего сайта. Объём каталога, сторонние сервисы и характеристики устройств влияют на результат; ориентиры производительности лучше согласовать заранее.
Для более глубокой проверки пригодится отдельный чек-лист технического аудита сайта.
Готовность к индексации
Убедитесь, что у важных страниц есть содержательные Title, Description и основной заголовок, а внутренние ссылки и sitemap ведут на рабочие адреса. Проверьте, что canonical не указывает на тестовый домен или постороннюю страницу.
После запуска на публичных страницах, предназначенных для поиска, не должно оставаться случайного noindex — в метатеге или HTTP-заголовке. При этом служебные страницы могут быть закрыты намеренно. В документации Google отдельно объясняется, что запрет обхода в robots.txt и исключение из индекса — разные механизмы.
Если сайт заменяет предыдущую версию, проверьте сохранение важных страниц и соответствие старых адресов новым. Для изменённых URL нужны подходящие перенаправления, а также обновление внутренних ссылок. Подготовку карты адресов и последующий мониторинг рекомендует Google в руководстве по переезду сайта.
Готовность к индексации не означает немедленного появления в поиске и не гарантирует позиции. Принимают выполненные настройки и проверяемые результаты работ, а не обещание мгновенного выхода в ТОП.
7. Сверьте интеграции и аналитику с реальными действиями
Для каждой внешней системы составьте короткую цепочку: откуда приходят данные, куда передаются, какие поля обязательны и кто замечает ошибку. Это относится к CRM, учётной системе, доставке, оплате, уведомлениям и другим подключённым сервисам.
Проверяйте не только наличие соединения, но и результат. Товар должен получить правильную цену и остаток, заказ — попасть в нужный раздел, уведомление — уйти согласованному получателю. Если обмен выполняется по расписанию, зафиксируйте допустимую задержку.
В аналитике сверьте установленные счётчики, согласованные цели и события. Отправьте тестовую заявку и сопоставьте её с записью в CRM. Клик по кнопке, успешная отправка и оплаченный заказ — разные действия, их нельзя незаметно подменять друг другом.
При приёмке проверьте также переход с меткой рекламного источника, если его передача входит в требования. В отчёты и адреса страниц не должны случайно попадать телефоны, email и другие данные из полей формы. Тестовые события пометьте или учтите при последующем анализе.
8. Проверьте резервные копии и базовую защиту
Попросите подтвердить, что резервные копии охватывают нужные файлы, базу данных и конфигурацию, создаются по согласованному расписанию и доступны ответственному сотруднику. Уточните срок хранения, порядок восстановления и то, где находятся инструкции.
Наличие архива ещё не подтверждает возможность восстановления. Полезно провести контрольное восстановление в отдельной среде: проверить открытие сайта, данные и основные функции. Рабочий сайт для такой проверки не перезаписывают.
В рамках базовой приёмки также проверьте:
- отдельные учётные записи и права для разных сотрудников;
- отсутствие лишних тестовых аккаунтов и публичных резервных копий;
- защиту административного доступа и дополнительные факторы входа там, где они поддерживаются;
- согласованный порядок обновления CMS и компонентов;
- обработку спама без блокировки нормальных обращений.
Это не полноценный аудит безопасности. Если сайт обрабатывает чувствительные данные или имеет сложные роли и интеграции, глубину отдельной проверки определяют по рискам проекта.
9. Получите доступы, материалы и инструкции
Приёмка сайта включает передачу возможностей управления. Компания должна понимать, где размещён проект, кто управляет доменом, какие сервисы оплачиваются и как продолжить работу без участия конкретного сотрудника подрядчика.
| Что передаётся | Что нужно подтвердить |
|---|---|
| Домен и DNS | Компания контролирует управление, восстановление доступа и продление; контакты у регистратора проверены |
| Хостинг или облачная платформа | Известны аккаунт, тариф, владелец оплаты, ограничения и способ получения поддержки |
| CMS и внешние сервисы | Сотрудники входят под собственными аккаунтами с согласованными правами |
| Исходники и дизайн | Переданы предусмотренные договором материалы, актуальная версия кода и доступные исходные макеты |
| Лицензии и подписки | Есть список компонентов, условий использования, сроков и ответственных за продление |
| Документация | Описаны редактирование, запуск, интеграции, резервное копирование и восстановление |
Для конструктора или облачного сервиса состав передаваемых материалов зависит от возможностей платформы. Если исходный код нельзя выгрузить, это ограничение и доступные варианты экспорта данных должны быть известны заранее.
Проверьте вход и восстановление доступа со стороны компании. Секреты передавайте через согласованный защищённый канал, не добавляйте пароли и API-ключи в общую таблицу замечаний. Доступ подрядчика после запуска оставляйте только в согласованном объёме; порядок смены ключей учитывает работающие интеграции.
10. Оформите замечания так, чтобы их можно было исправить
Запись «корзина работает неправильно» не помогает воспроизвести проблему. Для каждого замечания укажите страницу, окружение, шаги, ожидаемый и фактический результат. Приложите скриншот или короткую запись без реальных данных клиентов.
Условный пример замечания:
- Раздел: оформление заказа.
- Окружение: модель устройства, ОС, название и версия браузера.
- Шаги: добавить товар, открыть оформление, заполнить обязательные поля, выбрать доставку, нажать «Оформить заказ».
- Ожидается: заказ создаётся, покупатель получает подтверждение, менеджер видит запись.
- Фактически: кнопка остаётся в состоянии загрузки, запись не появляется.
- Дополнительно: время проверки, тестовый идентификатор, запись экрана.
Для планирования удобно разделить замечания по влиянию:
- Блокируют запуск: потеря заказов, неправильное списание, доступ к чужим данным, недоступность ключевого сценария.
- Требуют приоритетного исправления: заметное нарушение согласованных требований или сценарий с неудобным обходным решением. Влияние оценивают с учётом аудитории.
- Не мешают основным действиям: небольшие визуальные расхождения и отдельные опечатки. Их тоже фиксируют, а порядок исправления согласуют.
У каждого пункта должны быть ответственный, статус и результат повторной проверки. Сообщение разработчика «исправлено» переводит замечание на проверку; закрывают его после воспроизведения сценария на обновлённой версии. После изменения общего компонента проверяют и связанные страницы.
11. Разделите проверку до запуска и после него
На тестовой версии проверяют согласованные функции, интерфейс, контент и работу сотрудников. Перед публикацией согласуют перенос данных, резервную копию, ответственных и условия отката. Для действующего магазина отдельно определяют, как сохранить заказы, поступившие во время переключения.
На рабочем домене повторно проверяют HTTPS, формы, доставку уведомлений, интеграции, аналитику и доступность для поиска. Настройки домена и внешних сервисов могут отличаться от тестовых, поэтому успешная демонстрация не заменяет проверку после запуска.
Зафиксируйте, кто принимает сообщения о сбоях, как различаются исправление ошибок и новые доработки, какие часы поддержки согласованы. Не подменяйте эти условия общим обещанием «будем на связи».
Итог проверки должен содержать версию результата, выполненные сценарии, нерешённые замечания и дальнейшие действия. Документы о приёмке оформляют по согласованному сторонами порядку; в них не стоит описывать непроверенную функцию как проверенную.
Короткий чек-лист приёмки сайта
Перед завершением проверки убедитесь, что каждый применимый пункт подтверждён результатом:
- Требования, макеты и согласованные изменения сопоставлены с реализацией.
- Проверены основные типы страниц, пустые состояния и ошибки.
- Тестовые заявки доходят до предусмотренных получателей и систем.
- Заказы, расчёты и статусы оплаты работают по согласованным сценариям.
- Мобильная версия и выбранные браузеры проверены.
- Сотрудник компании может самостоятельно обновлять контент.
- Контакты, цены и опубликованные материалы согласованы.
- Настройки SEO проверены с учётом запуска или замены старого сайта.
- Интеграции и аналитика сверены с тестовыми действиями.
- Резервное копирование и восстановление проверены в безопасной среде.
- Доступы, материалы, лицензии и документация переданы в согласованном объёме.
- Замечания зафиксированы, исправления перепроверены, порядок поддержки определён.
Если пункт не относится к проекту, отметьте «не применимо» и причину. Если проверка не выполнена, оставьте именно этот статус. Отсутствие замечаний к непроверенной функции не означает, что она работает.
Частые вопросы
Можно ли принять сайт без технического специалиста?
Заказчик может проверить соответствие бизнес-задачам, контент и пользовательские сценарии. Проверку кода, безопасности и сложных интеграций лучше поручить специалисту. Для значимого проекта полезна независимая проверка, особенно если внутри компании нет технической команды.
Сколько времени нужно на приёмку?
Срок зависит от количества сценариев, интеграций, ролей и объёма данных. Планируйте не только первый просмотр, но и исправления с повторной проверкой. Универсальное обещание принять любой сайт за один день не учитывает сложность проекта.
Что делать, если техническое задание неполное?
Соберите согласованные макеты, переписку и демонстрации, затем письменно уточните проверяемые ожидания. Отдельно отметьте спорные требования и новые пожелания. Сам чек-лист не меняет ранее согласованный объём работ.
Нужен ли идеальный балл PageSpeed для приёмки?
Один балл не описывает работоспособность и качество всего проекта. Оценивайте согласованные показатели, условия измерения и удобство ключевых сценариев. Автоматический отчёт полезен для поиска проблем, но не заменяет функциональные проверки.
Нужно ли проверять сайт повторно после исправлений?
Да. Повторите исходный сценарий и проверьте связанные функции, особенно если менялся общий шаблон, форма или интеграция. Результат проверки привязывайте к актуальной версии сайта.
Принимайте работающую систему, а не только внешний вид
Сайт готов к работе, когда согласованные сценарии проверены, существенные проблемы устранены или явно учтены в решении о запуске, а у компании есть необходимые доступы и инструкции. Скриншоты, демонстрация разработчика и список выполненных задач полезны, но не заменяют собственную проверку результата.
Планируете запуск или передачу проекта? Обсудите разработку и доработку сайта с Elegrant. Подготовьте ссылку на проект, согласованные требования и список сомнений — это поможет определить объём проверки и необходимых изменений.