Как принимать сайт у разработчика: чек-лист приёмки работ

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

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

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

Что означает приёмка сайта и почему нельзя ограничиваться главной страницей

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

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

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

С чего начать: соберите документы и доступы

Не начинайте с замечаний по цвету кнопки. Сначала соберите материалы, по которым можно объективно оценить результат. Если технического задания нет, используйте переписку, утверждённые макеты, коммерческое предложение и список работ в договоре. Устные договорённости сложно предъявить как обязательство.

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

Что должно быть у заказчика до подписания акта

Договор, приложение с составом работ и утверждённое техническое задание.
Ссылка на рабочую версию сайта или адрес опубликованного сайта.
Макеты дизайна для компьютера и телефона, если дизайн утверждался отдельно.
Учётные данные владельца домена, хостинга, системы управления сайтом, корпоративной почты и аналитики.
Перечень сторонних сервисов: CRM, платёжная система, онлайн-чат, служба доставки, телефония, рассылки.
Инструкция по управлению сайтом или запись обучения, если это предусмотрено договором.

Логины лучше получать не в виде одной таблицы с паролями. Владелец бизнеса или назначенный сотрудник должен быть главным владельцем аккаунтов, а исполнителю можно выдать отдельный доступ. Тогда смена подрядчика не станет технической проблемой.

Проверьте соответствие структуре, содержанию и макетам

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

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

Как проверять текст и материалы

Сверьте названия услуг, цены, контакты, реквизиты, условия доставки и гарантии с актуальными данными бизнеса. Частая проблема, когда на тестовой версии остались старые телефоны, временные фотографии, шаблонные отзывы и тексты-заглушки. Такие материалы вредят доверию и могут привести к обращениям не по адресу.

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

Как проверять дизайн без субъективных споров

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

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

Проверьте пользовательские сценарии, а не отдельные кнопки

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

Для корпоративного сайта достаточно подготовить 5-7 основных сценариев. Для интернет-магазина их обычно больше: поиск товара, фильтрация, добавление в корзину, оформление заказа, применение промокода, выбор доставки, оплата, письмо покупателю и получение заказа в административной части.

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

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

В практике студии RDMN особенно часто встречается ситуация, когда форма визуально работает, но письмо попадает в спам или не приходит из-за неверной настройки отправки. Такой дефект критичен: красивый сайт без заявок не решает задачу бизнеса.

Проверьте сайт на телефоне, в браузерах и при разных условиях

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

Минимальная проверка включает актуальные версии Chrome и Яндекс Браузера на компьютере, Safari на iPhone или iPad, Chrome на Android. Не нужно искусственно поддерживать очень старые браузеры, если этого нет в договоре. Но сайт не должен ломаться у большинства текущих пользователей.

На что смотреть в мобильной версии

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

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

Доступы, управление и техническая независимость

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

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

Область проверки	Что принять у исполнителя	Признак проблемы
Домен и хостинг	Доступ владельца к личным кабинетам, сведения об оплате и продлении	Аккаунт оформлен на исполнителя, заказчик не может восстановить пароль
Система управления	Администраторский доступ, инструкция, демонстрация изменений	Можно только смотреть сайт, а редактора или владельца нет
Исходные материалы	Макеты, фотографии, тексты, файлы логотипа в оговорённом формате	У заказчика есть лишь ссылка на опубликованный сайт
Интеграции	Доступы или порядок передачи, описание настроек и ответственных	Заявки приходят, но никто не знает, где изменить получателя
Резервные копии	Порядок создания копий и способ восстановления	Копия существует только на компьютере разработчика

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

Если проект передан без нужных прав или без возможности исправить ошибки, это основание не торопиться с окончательной приёмкой. Когда нужен уже готовому сайту новый функционал, исправление ошибок или передача на другое сопровождение, оценить объём поможет услуга доработки сайта.

Как фиксировать замечания, чтобы их действительно исправили

Список «сделайте красиво» почти гарантированно приводит к спору. Каждое замечание должно содержать страницу, действие, фактический результат, ожидаемый результат и при возможности скриншот или короткую запись экрана. Это помогает исполнителю быстро воспроизвести проблему и сокращает число уточнений.

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

Пример корректного замечания

Плохо: «На телефоне каталог работает неправильно». Хорошо: «Страница /catalog/, Android, Chrome. При выборе фильтра “в наличии” кнопка применения оказывается за нижней границей экрана, прокрутки внутри блока нет. Ожидаемый результат: пользователь может применить фильтр без изменения масштаба страницы».

Согласуйте срок повторной проверки. Для 3-10 мелких замечаний по рынку обычно требуется 1-5 рабочих дней, если не затронута сложная интеграция. Существенные изменения логики, новые страницы или функции, которых не было в техническом задании, могут стать отдельной задачей. Не смешивайте ошибки исполнителя и новые пожелания: это сохраняет деловой тон и делает расчёт прозрачным.

Типичные ошибки заказчика при приёмке сайта

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

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

Третья ошибка, оставлять замечания в разных каналах: часть в мессенджере, часть по телефону, часть в комментариях к макету. В результате невозможно понять, что исправлено и какие пункты были согласованы. Нужен один сводный список с версиями и статусами.

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

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

Что подписывать после проверки

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

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

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

Частые вопросы

Можно ли принять сайт, если остались небольшие замечания?

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

Сколько времени закладывать на приёмку?

Для лендинга обычно достаточно 1-2 рабочих дней при наличии подготовленного списка требований. Корпоративный сайт с формами и каталогом разумно проверять 3-5 рабочих дней. Интернет-магазину с оплатой, доставкой и интеграциями может потребоваться 5-10 рабочих дней, особенно если тестированием занимаются несколько подразделений.

Нужно ли привлекать независимого специалиста?

Для простого сайта руководитель или маркетолог справится по чек-листу. Независимая проверка полезна для интернет-магазина, сложного личного кабинета, интеграций с CRM и учётными системами, а также при споре о качестве. Специалист проверит технические аспекты, но бизнес всё равно должен принять тексты, цены, логику продаж и удобство работы менеджеров.

Что делать, если разработчик говорит, что ошибка не входит в договор?

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

Нужно ли проверять SEO при приёмке?

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

Что делать: короткий план

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

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