Чтобы принять сайт у разработчика, нужно проверить не только внешний вид страниц, но и соответствие техническому заданию, работу пользовательских сценариев, адаптивность, интеграции, базовые SEO-настройки, безопасность доступа и комплект передаваемых материалов. Все замечания следует зафиксировать письменно, распределить по приоритету и повторно проверить после исправления.
Эта инструкция поможет последовательно провести приёмку, не пропустить критичные ошибки и отделить дефекты от новых пожеланий. В конце статьи — краткий чек-лист, правила оформления замечаний и ответы на частые вопросы заказчиков.
Что подготовить до начала приёмки
Объективно принять веб-сайт у разработчика можно только по заранее согласованным требованиям. Формулировка «сайт должен работать хорошо» не задаёт проверяемого результата. Основанием для приёмки обычно служат договор, техническое задание, прототипы, утверждённые макеты, карта страниц, перечень интеграций и другие зафиксированные договорённости.
До проверки соберите в одном месте:
- актуальную версию технического задания и приложений к договору;
- утверждённые дизайн-макеты для предусмотренных разрешений;
- перечень страниц, форм, ролей пользователей и функциональных модулей;
- требования к CMS, интеграциям, аналитике и SEO;
- список поддерживаемых браузеров и устройств, если он был согласован;
- контент, который должен быть размещён к моменту сдачи;
- критерии готовности и порядок устранения замечаний.
Уточните, где проходит проверка: на тестовом домене или на рабочем сайте. Тестовый стенд удобен для поиска ошибок, но финальную приёмку нельзя полностью завершить до проверки рабочего окружения. После переноса могут измениться пути к файлам, настройки сервера, отправка почты, аналитика, сертификат и интеграции.
На время приёмки желательно зафиксировать версию проекта. Если разработчик одновременно добавляет функции и меняет интерфейс, результаты проверки быстро устаревают, а источник новых ошибок становится сложнее определить.
Шаг 1. Проверьте соответствие техническому заданию
Первый этап — сопоставить реализованный сайт с согласованным объёмом работ. Проверять нужно по пунктам, а не по общему впечатлению. Наличие страницы ещё не означает, что выполнены требования к её структуре, содержанию и поведению.
Последовательно сравните с заданием:
- Структуру. Все ли разделы, страницы и типы материалов созданы, правильно ли устроено меню.
- Функции. Реализованы ли формы, поиск, фильтры, личный кабинет, корзина, калькуляторы и другие предусмотренные модули.
- Контент. Размещены ли согласованные тексты, изображения, документы, реквизиты и контакты.
- Интеграции. Подключены ли CRM, платёжные системы, службы доставки, телефония, рассылки или другие внешние сервисы из задания.
- Управление. Можно ли редактировать заявленные элементы через административную панель без обращения к программисту.
Если результат отличается от макета или технического задания, сначала проверьте историю согласований. Иногда изменение было утверждено в переписке, но не попало в основной документ. Такие решения стоит перенести в единый список требований, чтобы у заказчика и подрядчика не было разных версий проекта.
Новая идея, возникшая во время приёмки, не является дефектом. Например, отсутствие фильтра — ошибка, если фильтр был предусмотрен заданием. Если фильтр не согласовывался, речь идёт о дополнительной работе, которую нужно отдельно оценить по срокам и объёму.
Шаг 2. Оцените интерфейс, контент и мобильную версию
Визуальную проверку лучше проводить после сверки состава работ. Откройте основные шаблоны страниц и сравните их с утверждёнными макетами: главную, раздел каталога, карточку товара или услуги, публикацию, контакты, результаты поиска и служебные страницы.
Дизайн и удобство использования
Обратите внимание на единообразие шрифтов, цветов, отступов, кнопок, полей и заголовков. Интерактивные элементы должны выглядеть интерактивными, а пользователь должен понимать, что произойдёт после нажатия.
Проверьте навигацию: логично ли устроено меню, заметен ли текущий раздел, можно ли вернуться на предыдущий уровень, не ведут ли разные пункты на одну страницу без понятной причины. Ключевое действие — отправка заявки, оформление заказа, запись или звонок — не должно теряться среди второстепенных элементов.
Контент
Просмотрите тексты не только на наличие опечаток. Проверьте корректность телефонов, адресов, электронной почты, реквизитов, характеристик, подписей и файлов для скачивания. Убедитесь, что на рабочих страницах не осталось тестовых текстов, временных изображений, пустых блоков и комментариев для команды.
Особое внимание уделите реальному объёму контента. Карточка с коротким тестовым названием может выглядеть аккуратно, а длинное название товара — сломать сетку. Полезно проверить длинные заголовки, несколько абзацев текста, крупные таблицы и изображения разных пропорций.
Адаптивность
Не ограничивайтесь уменьшением окна браузера. Откройте сайт на нескольких доступных смартфонах, планшете и компьютере либо используйте режим эмуляции как дополнительный инструмент.
На разных размерах экрана проверьте:
- не появляется ли горизонтальная прокрутка;
- не перекрываются ли текст, кнопки и всплывающие элементы;
- удобно ли открывать мобильное меню и заполнять формы;
- не обрезаются ли изображения, таблицы и подписи;
- остаются ли кликабельными телефон, почта и элементы управления;
- не мешают ли уведомления и закреплённые панели просмотру страницы.
Полное пиксельное совпадение на каждом экране не всегда возможно и не всегда нужно. Критерий приёмки — соответствие согласованной дизайн-системе, сохранение смысла и удобное выполнение целевых действий.
Шаг 3. Протестируйте функции по пользовательским сценариям
Функциональность следует проверять как последовательность действий реального посетителя. Простого факта, что кнопка нажимается, недостаточно: данные должны корректно обработаться, попасть в нужную систему, а пользователь — получить понятный результат.
Составьте сценарии для каждого типа пользователя. Например: посетитель находит услугу, переходит на нужную страницу, заполняет форму, подтверждает согласие, отправляет данные и видит сообщение об успешной отправке. Менеджер получает заявку с правильными полями и понимает, с какой страницы она пришла.
Для интернет-магазина отдельно проверяют поиск и фильтры, добавление и удаление товаров, изменение количества, промокоды, расчёт стоимости, способы доставки и оплаты, письма и статусы заказа. Для личного кабинета — регистрацию, вход, восстановление пароля, изменение данных, разграничение ролей и выход из учётной записи.
Каждую форму протестируйте в трёх режимах:
- Корректные данные. Форма отправляется, пользователь получает подтверждение, информация приходит получателю.
- Ошибочные данные. Сайт показывает понятную подсказку рядом с проблемным полем и не теряет уже введённую информацию без необходимости.
- Пустые обязательные поля. Отправка блокируется, обязательные поля обозначены однозначно.
Проверьте пограничные случаи: очень короткие и длинные значения, повторное нажатие на кнопку, обновление страницы после отправки, возврат назад, отсутствие результатов поиска, недоступность внешнего сервиса. Ошибка интеграции не должна приводить к пустому экрану или создавать несколько одинаковых заявок.
Административную панель также принимают по сценариям. Попробуйте самостоятельно создать и отредактировать страницу, заменить изображение, изменить метаданные, опубликовать материал и отменить изменение. Если для обычного обновления контента постоянно требуется разработчик, а по заданию управление должно быть доступно редактору, работу нельзя считать полностью принятой.
Шаг 4. Проверьте техническую готовность к запуску
Техническую проверку разумно разделить на обязательные условия запуска и показатели, которые зависят от архитектуры проекта. Не стоит требовать произвольные оценки сервисов без привязки к техническому заданию, типу сайта, серверу и внешним компонентам.
| Область | Что проверить | Признак проблемы |
|---|---|---|
| Адреса страниц | Понятные URL, корректные внутренние ссылки, настроенные перенаправления | Ошибки 404, циклические переходы, дубли адресов |
| Защищённое соединение | Сайт открывается по HTTPS, нет смешанной загрузки ресурсов | Предупреждение браузера, часть файлов загружается небезопасно |
| Индексация | Рабочий сайт доступен для индексации, тестовый закрыт, служебные разделы обработаны по требованиям | Рабочие страницы запрещены или тестовая копия попадает в поиск |
| Метаданные | Для индексируемых шаблонов предусмотрены title, description и основной заголовок | Пустые или одинаковые данные на всех страницах |
| Системные страницы | Настроена страница 404, нет тупиковых переходов | Серверная ошибка или пустая страница |
| Аналитика | Счётчики установлены, цели и события передаются по согласованной схеме | Визиты или ключевые действия не фиксируются |
Проверьте файл robots.txt и карту сайта, если они входят в требования проекта. Убедитесь, что канонические адреса и правила индексации не создают очевидных дублей. Для переноса старого сайта нужен отдельный список перенаправлений со старых востребованных адресов на релевантные новые страницы.
Скорость оценивают на типовых страницах и в условиях, близких к рабочим. На загрузку влияют сервер, изображения, шрифты, сторонние виджеты, аналитика и объём контента. Если в договоре нет конкретных метрик, зафиксируйте фактические проблемы: долгое появление основного содержимого, скачки блоков, зависание интерфейса или задержку реакции на действия.
Проверьте сайт в согласованных браузерах. Особое внимание уделите формам, меню, всплывающим окнам, загрузке файлов и элементам, зависящим от JavaScript. Также полезно пройти основные страницы с клавиатуры: фокус должен быть заметен, а важные действия — доступны без мыши, если соответствующие требования входят в проект.
Перед запуском запросите резервную копию и понятный порядок восстановления. Сам факт наличия механизма резервирования недостаточен, если неизвестно, что именно копируется, где хранится копия и кто отвечает за восстановление.
Шаг 5. Получите доступы, исходники и документацию
Приёмка заканчивается не после исправления визуальных ошибок, а после передачи заказчику контроля над результатом. Состав передаваемых материалов зависит от договора и технологии, поэтому список нужно сверять с условиями конкретного проекта.
Обычно заказчику необходимо получить:
- доступ к домену и подтверждение, на кого он зарегистрирован;
- доступ к хостингу, серверу или облачной инфраструктуре;
- учётную запись администратора CMS;
- доступы к аналитике, панелям для веб-мастеров и подключённым сервисам;
- настройки корпоративной почты, если они входили в работы;
- исходный код и репозиторий в предусмотренном договором объёме;
- базу данных, загруженные файлы и актуальную резервную копию;
- лицензии на CMS, модули, шрифты и другие компоненты, если они приобретались для проекта;
- инструкцию по управлению контентом и описание нестандартных функций;
- контакты и порядок обращения по гарантии или поддержке.
У заказчика должны быть собственные административные учётные записи. Не следует оставлять единственный полный доступ на личной почте сотрудника подрядчика. После передачи проверьте вход под выданными учётными данными, включите доступные меры защиты и договоритесь, какие права останутся у разработчика на период поддержки.
Пароли лучше передавать через согласованный защищённый канал, а не размещать в общей таблице с замечаниями. После завершения работ временные учётные записи и тестовые ключи нужно удалить или заменить.
Как оформить замечания и завершить приёмку
Замечание должно позволять разработчику воспроизвести проблему без дополнительных догадок. Формулировка «форма работает неправильно» бесполезна. Укажите страницу, устройство и браузер, последовательность действий, фактический результат и ожидаемое поведение по требованиям.
Удобная структура записи:
- адрес страницы или название раздела;
- шаги для воспроизведения;
- что произошло;
- что должно происходить;
- скриншот или запись экрана при необходимости;
- приоритет и ссылка на пункт задания.
Не отправляйте одну запись сразу о нескольких несвязанных ошибках. Раздельные задачи проще назначать, исправлять и перепроверять. Дубли объединяйте, а обсуждение новых пожеланий ведите отдельно от дефектов.
Приоритет можно определять по влиянию на запуск:
- Блокирующий дефект — нельзя выполнить ключевое действие, есть риск потери данных или сайт недоступен.
- Существенный дефект — функция работает неверно, но существует обходной путь либо проблема затрагивает отдельный сценарий.
- Незначительный дефект — ошибка не мешает основному действию, однако ухудшает содержание или удобство.
- Косметическое замечание — небольшое визуальное отклонение без влияния на функции.
После исправлений повторите исходный сценарий и выполните регрессионную проверку связанных функций. Например, после изменения формы нужно проверить не только её внешний вид, но и валидацию, отправку писем, передачу данных в CRM и события аналитики.
Финальный документ о приёмке должен соответствовать условиям договора. Если часть некритичных замечаний переносится на период после запуска, зафиксируйте их перечень, ответственных и согласованный порядок выполнения. Не подписывайте документ с формулировкой об отсутствии претензий, если критичные дефекты остаются нерешёнными.
Краткий чек-лист перед подтверждением готовности:
- реализация сверена с актуальным заданием и макетами;
- основные сценарии пройдены на компьютере и мобильных устройствах;
- формы, уведомления и интеграции проверены от начала до конечной системы;
- контент, контакты и документы актуальны;
- нет критичных ошибок, битых ссылок и тестовых элементов;
- рабочий сайт корректно открывается по HTTPS;
- настройки индексации и аналитики проверены;
- доступы, исходники, лицензии и резервная копия переданы;
- замечания исправлены и повторно протестированы;
- порядок поддержки после запуска понятен обеим сторонам.
Частые вопросы
Кто должен принимать сайт со стороны заказчика?
Приёмку лучше поручить ответственному сотруднику, который знает цели проекта и согласованные требования. Руководители направлений могут проверять отдельные функции, но итоговый список замечаний должен собирать один координатор.
Можно ли принять сайт без технического задания?
Можно проверить базовую работоспособность, но доказать несоответствие ожиданиям будет сложнее. Основанием станут договор, макеты, прототипы, переписка и другие зафиксированные договорённости. Перед проверкой их желательно объединить в единый перечень критериев.
Нужно ли привлекать независимого технического специалиста?
Независимая проверка полезна для сложного проекта, нестандартных интеграций или ситуации, когда у заказчика нет собственной технической компетенции. Для небольшого сайта основную часть приёмки можно провести по чек-листу, а специалисту передать проверку кода, инфраструктуры и безопасности.
Когда лучше проверять сайт: до переноса или после?
Основную проверку проводят на тестовом стенде, а после переноса повторяют критичные сценарии на рабочем домене. Финальная проверка должна охватывать HTTPS, формы, почту, аналитику, интеграции, перенаправления и настройки индексации.
Считается ли новое пожелание ошибкой разработчика?
Новое пожелание не считается дефектом, если функция или поведение не были согласованы. Ошибкой является расхождение с зафиксированными требованиями либо некорректная работа реализованной функции.
Можно ли запускать сайт с незначительными замечаниями?
Запуск возможен, если замечания не мешают ключевым сценариям, не создают рисков для данных и не нарушают обязательные требования проекта. Все отложенные исправления нужно письменно зафиксировать и согласовать порядок выполнения.
Если проект ещё не начат или текущий результат требует системной переработки, изучите услугу создания сайтов для бизнеса. До старта работ полезно согласовать не только функции и дизайн, но и критерии будущей приёмки.
