Финал проекта — момент противоречивый. С одной стороны, хочется скорее запуститься, с другой — есть тревога: работа вроде сделана, но как убедиться, что сайт действительно готов, а не просто «нормально открывается на моём ноутбуке»? Приёмка — это не бюрократия и не попытка выжать из подрядчика лишнее. Это последняя точка контроля, где результат сверяется с договорённостями, а риски закрываются до того, как проект уйдёт в поддержку.
Приёмка — это процесс, а не один день
Худший сценарий — увидеть сайт впервые за день до финального созвона. Тогда любая правка превращается в спор: заказчик считает, что «так не договаривались», подрядчик ссылается на согласованные макеты и ТЗ. Избежать этого помогает поэтапная приёмка.
Прототип, дизайн-макеты, вёрстка ключевых страниц — каждый из этих этапов стоит принимать отдельно, письменно фиксируя, что согласовано. К финалу останется проверить рабочую сборку целиком, а не пересматривать концепцию.
Что подготовить заранее
- Техническое задание со всеми допсоглашениями и перепиской, где что-то уточнялось.
- Согласованные прототипы, макеты, брендбук.
- Список браузеров и устройств, на которых сайт должен работать.
- Перечень интеграций: CRM, платёжные системы, 1С, сервисы рассылок.
- Тестовые данные для проверки форм, оплаты и личного кабинета.
Если это всё собрано в одном месте, приёмка проходит в разы быстрее.
Чек-лист: что проверять
Контент и навигация
- Все тексты на месте, без «рыбы» и заглушек вроде Lorem ipsum.
- Заголовки, цены, контакты, реквизиты и адреса актуальны.
- Меню и хлебные крошки работают, нет битых ссылок и страниц-сирот.
- Страница 404 оформлена и возвращает пользователя на сайт.
- Изображения подгружаются, подписи и alt-тексты заполнены.
Вёрстка и адаптивность
- Сайт корректно выглядит на мобильных, планшетах и десктопе.
- Проверены актуальные версии Chrome, Safari, Firefox, Edge и мобильный Safari.
- Ничего не «разъезжается» при увеличении шрифта и на нестандартных разрешениях.
- Кликабельные зоны удобны для пальца, кнопки не слипаются.
Функциональность и формы
- Каждая форма отправляется и приходит на нужную почту или в CRM.
- Есть валидация полей и понятные сообщения об ошибках.
- Письма-уведомления приходят и не попадают в спам.
- Оплата, личный кабинет, поиск по сайту, фильтры — работают по сценарию пользователя.
- Заявки не дублируются при повторной отправке.
Админка, скорость, SEO
- Через админку можно добавить страницу, товар, новость, баннер без разработчика.
- Права ролей настроены: редактор не должен ломать структуру сайта.
- Страницы открываются быстро, изображения сжаты, кэш и минификация включены.
- Заполнены title, description, заголовки h1, настроены ЧПУ и карта сайта.
- Подключены robots.txt и sitemap.xml, тестовый режим закрыт от индексации.
Безопасность, аналитика, документы
- Сайт работает по HTTPS, сертификат действует, есть редирект с http.
- Резервное копирование настроено и хотя бы раз проверено восстановлением.
- Аналитика и цели установлены, тестовые визиты не засоряют статистику.
- Все доступы переданы вам: хостинг, домен, админка, аналитика, репозиторий.
- Есть инструкция для контент-менеджера и список выполненных работ.
Как оформлять замечания
Спор «мне не нравится» и «всё по ТЗ» решается формой подачи. Заведите простую таблицу: страница, описание проблемы, шаги воспроизведения, скриншот, приоритет. Приоритеты лучше договорить заранее — например, блокирующие, важные и косметические.
Блокирующие правки закрываются до подписания акта, косметические можно вынести в отдельный список и спокойно доделать. Такой подход экономит нервы обеим сторонам и делает разговор предметным.
Типичные ошибки заказчика на приёмке
- Проверять только главную страницу, забывая о внутренних разделах и мобильной версии.
- Не тестировать формы — письма могут уходить в спам или на старый адрес.
- Придумывать новые требования на финале: это уже не приёмка, а новый этап работ.
- Забирать файлы, но не доступы — без хостинга, домена и админки сайт вам не принадлежит по факту.
- Подписывать акт до получения доступов и инструкций.
Коротко
Хорошая приёмка — это скучно и предсказуемо: список, таблица замечаний, спокойное закрытие пунктов. Зато после неё у вас остаётся работающий сайт, полный набор доступов и понятная документация. А это и есть та самая точка, с которой начинается нормальная эксплуатация, а не бесконечное «доделываем после запуска».

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