Почему приёмка — самый критичный момент всего проекта
Пока проект в работе, у заказчика есть рычаг влияния: не подписан акт — не закрыт этап — не переведена оплата. В момент подписания акта этот рычаг исчезает: юридически подрядчик считается выполнившим обязательства в полном объёме, и любые недоделки, обнаруженные после, приходится доказывать и добиваться исправления уже не как часть согласованной работы, а как отдельную претензию — часто платную и с меньшей охотой со стороны подрядчика. Именно поэтому проверка перед подписью должна быть не формальным пролистыванием сайта на десять минут, а системным прогоном по конкретному списку пунктов. Многие заказчики ограничиваются визуальным осмотром — открыли главную страницу, убедились, что дизайн совпадает с макетом, и на этом сочли приёмку завершённой. Но большинство реальных проблем скрыто не в дизайне, который и так виден на этапе согласования макетов, а в том, что происходит под капотом: как ведёт себя сайт при реальном использовании, а не при беглом просмотре.
Функциональная проверка
Первое, что нужно проверить, — работает ли сайт так, как задумано, а не просто выглядит рабочим на первый взгляд. Все формы на сайте — заявка, обратный звонок, подписка, форма в футере — должны быть протестированы отправкой реальных тестовых данных с проверкой, что письмо действительно приходит на нужный адрес или заявка появляется в CRM. Если на сайте есть корзина и оформление заказа, нужно пройти весь путь от добавления товара до оформления с реальным (тестовым) платежом или хотя бы до экрана подтверждения, проверив, что сумма считается верно с учётом скидок и доставки. Личный кабинет стоит проверять не на пустой демо-учётке, а с реальными данными — регистрацией нового пользователя, входом, восстановлением пароля. Стоит также пройтись по второстепенным, но частым сценариям: работает ли поиск по сайту и возвращает ли он релевантные результаты, корректно ли работают фильтры и сортировка в каталоге, отправляются ли уведомления на email после оформления заказа или заявки. Такие сценарии редко попадают в демонстрацию сайта подрядчиком именно потому, что о них проще забыть, если специально не проверять.
Техническая проверка
Вторая группа проверок касается того, как сайт ведёт себя технически, а не только функционально.
- Адаптивность на реальных устройствах. Не только в режиме эмуляции в браузере, а на нескольких настоящих смартфонах и планшетах разных производителей — верстка может по-разному ломаться на iOS и Android.
- Скорость загрузки. Проверка через PageSpeed Insights или аналогичный инструмент — как минимум по главной странице и одной-двум типовым внутренним.
- Ошибки в консоли браузера. Открыть консоль разработчика на нескольких ключевых страницах и убедиться, что там нет красных ошибок JavaScript — они часто не влияют на видимую картинку, но говорят о нестабильности кода.
- HTTPS. Сертификат установлен, весь сайт открывается по защищённому протоколу без предупреждений браузера о смешанном содержимом.
SEO- и аналитика-проверка
Эта часть приёмки легко пропускается, потому что не видна на глаз, но именно её отсутствие потом дороже всего исправлять постфактум. Нужно проверить, что мета-теги — заголовок и описание — заполнены не просто на паре страниц для демонстрации, а по всем типовым шаблонам: карточка товара, статья блога, страница услуги. Счётчики Яндекс.Метрики и GA4 должны быть установлены и реально фиксировать события, а не просто присутствовать в коде страницы — это стоит проверить через отчёт в реальном времени, зайдя на сайт с другого устройства. Файлы robots.txt и sitemap.xml должны существовать, не блокировать нужные разделы и быть отправлены в панели вебмастеров. Если сайт заменяет собой старый, отдельно проверяются редиректы со старых адресов на новые — без них сайт после переезда теряет накопленный трафик и позиции.
Доступы и документация
Отдельный источник проблем, который всплывает уже после приёмки, — доступы. Формально сайт может быть полностью готов, но если заказчику передан временный тестовый доступ, а не реальные логины и пароли от хостинга, домена и административной панели CMS, то фактическое владение сайтом остаётся у подрядчика. Перед подписанием акта нужно убедиться, что переданы: доступ к панели управления хостингом, доступ к регистратору домена или подтверждение, что домен оформлен на заказчика, полноценный админ-доступ в CMS с правами администратора, а не ограниченного редактора, и хотя бы краткая документация — что и где настроено, какие интеграции подключены. Хорошая практика — сразу после получения доступов сменить пароли на новые, известные только заказчику, и убедиться, что после этой смены сайт и панель управления по-прежнему работают: так проверяется, что переданные доступы действительно полноценные, а не резервные с ограниченными правами.
Что делать, если во время проверки нашли проблему
Найти недочёт — не повод паниковать, если правильно на него отреагировать: нельзя ни игнорировать проблему и подписывать акт «как есть» на словах «доделаем потом», ни превращать несогласие в конфликт без документа. Правильный путь — зафиксировать найденное письменно в приложении к акту приёма-передачи с конкретным описанием проблемы и согласованным сроком устранения, и подписывать основной акт только после того, как это приложение согласовано обеими сторонами. Устные обещания «поправим на следующей неделе» без письменной фиксации юридически не значат ничего и легко забываются в текучке.
Если вам нужен структурированный список для приёмки именно вашего сайта или для других этапов работы с подрядчиком — у нас в блоге есть и другие чек-листы Evaris, которые можно использовать как основу. А если вы сейчас проходите приёмку сайта и не уверены, на что обратить особое внимание в вашем случае, — можем провести независимый технический аудит перед подписанием акта.