Приёмка сайта у разработчика: как проверить работу перед оплатой

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

Зачем нужна формальная приёмка, если разработчик уже показал демо на созвоне?

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

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

С чего начать проверку — что смотреть в первую очередь?

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

Отдельно стоит проверить админ-панель: сможете ли вы сами, без разработчика, добавить новость, товар или страницу. Именно от этого зависит, насколько сайт будет удобен в повседневной эксплуатации после сдачи проекта.

Как проверить, что сайт корректно работает на разных устройствах и в браузерах?

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

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

На что обратить внимание в части безопасности и хранения данных?

Убедитесь, что на сайте установлен SSL-сертификат и адрес открывается по защищённому протоколу — без этого браузеры будут показывать посетителям предупреждение о небезопасном соединении, а часть форм и платёжных систем просто откажется работать.

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

Как убедиться, что сайт передан именно вам, а не остался у подрядчика?

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

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

Если хостинг и база данных изначально размещались у самого разработчика на его собственных серверах, стоит заранее договориться о переносе проекта на площадку, которую контролирует заказчик. Такие сервисы, как «Клауд АйСи», позволяют развернуть сайт на собственном сервере или в облаке, подключить домен и SSL-сертификат от своего имени и настроить регулярное резервное копирование — так весь проект остаётся под контролем заказчика с самого начала, а не переезжает «в чужие руки» на этапе разработки.

Что делать, если при проверке нашлись ошибки?

Все найденные недочёты стоит фиксировать письменно — списком с описанием проблемы и, если возможно, скриншотом. Не стоит подписывать акт сдачи-приёмки с формулировкой «замечаний нет», если замечания есть: как только акт подписан, доказать что-то постфактум становится сложнее.

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

Нужно ли отдельно проверять скорость загрузки и базовые SEO-настройки?

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

Из базовых SEO-моментов стоит проверить наличие уникальных заголовков и описаний на страницах, файл robots.txt, карту сайта sitemap.xml и корректную настройку редиректов, если сайт заменяет старую версию. Эти мелочи закладываются на этапе разработки, а исправлять их постфактум обычно дороже и дольше.

Как понять, что пора подписывать финальный акт и оплачивать оставшуюся сумму?

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

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