Чек-лист приёмки сайта от подрядчика: что проверять перед оплатой
Приёмка сайта — это не «открыли главную, убедились, что она загрузилась, и подписали акт». Это структурированная проверка перед тем, как перевести деньги и остаться с подрядчиком один на один с готовым результатом. Именно на этом этапе вскрывается большинство проблем — и то, как они фиксируются, определяет, сколько потом будет переделок и писем «а помните, мы же просили поправить». Ниже — рабочий чек-лист: что именно проверять и в каком порядке, прежде чем закрывать проект.
Что вы на самом деле принимаете
Приёмка — это не только фронтенд, который видно в браузере. Это ещё доступы, исходный код, контент и документы. Прежде чем смотреть на картинку, сверьте результат с техническим заданием построчно: каждый пункт ТЗ должен быть либо реализован, либо явно отмечен как перенесённый на следующий этап. Если сверки с ТЗ не было, формально проверять нечего — непонятно, что считается «готово». С этой же сверки удобно начать и внешний аудит: если своей команды для построчной проверки не хватает, этим занимается YuSMP Group — тестирование и IT-аудит перед сдачей проекта заказчику.
Когда начинать приёмку: до оплаты или после?
Правильный ответ — до, и не один раз, а поэтапно. Если ждать полного завершения проекта, чтобы провести единственную большую приёмку, исправление системной ошибки (например, неверной структуры данных в CMS) обойдётся в разы дороже, чем на промежуточном этапе. На каждом значимом этапе — вёрстка, интеграция, тестовый контур — стоит делать короткую сверку: что сделано, что отличается от ТЗ, что переносится дальше. Финальная приёмка в этом случае превращается в проверку мелочей, а не в поиск архитектурных проблем впервые за весь проект.
Доступы, без которых сайт вам не принадлежит
До подписания акта должны быть на руках: доступ к административной панели CMS, хостингу или серверу, домену (и он должен быть оформлен на компанию-заказчика, а не на подрядчика), аналитике и CRM, платёжным кабинетам, если есть приём оплат, а также исходники и макеты в рабочих форматах. Отдельно стоит зафиксировать документально, что передаётся вместе с актом приёма-передачи: без этого списка через полгода трудно доказать, что часть материалов вам вообще должны были отдать.
Проверка сайта глазами клиента
Отложите техническую сторону на минуту и пройдите по сайту так, как это сделает обычный посетитель. Опечатки и разбитая вёрстка на мобильном — то, что бросается в глаза в первую очередь. Проверьте все ссылки в меню и подвале — живые ли они. Заполните формы реальными, пусть и тестовыми, данными и убедитесь, что заявка действительно доходит — письмом или записью в CRM, а не теряется где-то между фронтендом и бэкендом. Проверьте, что контакты и ссылки на соцсети ведут туда, куда нужно, а не на демо-страницы разработчика.
Техническая часть, которую легко пропустить
Здесь чаще всего экономят на внимании, потому что «на вид всё работает». Убедитесь, что подключён действующий SSL-сертификат и сайт отдаёт один канонический адрес — без дублей вида www и без www одновременно. Проверьте скорость загрузки и вес изображений: тяжёлые нешжатые картинки — самая частая причина медленного сайта, который сдали «технически готовым». Наконец, убедитесь, что сайт индексируется корректно — есть файл sitemap.xml, robots.txt не блокирует нужные разделы, а на сайт не остался технический noindex с этапа разработки.
Где чаще всего ошибаются при приёмке
Первая типичная ошибка — принимать работу «на глаз», без построчной сверки с ТЗ: кажется, что сайт выглядит так, как договаривались, но часть функциональности тихо выпала. Вторая — не проверять формы с реальными данными, из-за чего заявки с сайта могут не доходить неделями, а узнают об этом случайно. Третья и самая системная — замечания фиксируются где попало: скриншот в одном чате, комментарий в другом, голосовое сообщение, которое никто не записал. В результате часть правок просто не доходит до подрядчика, а на финальном этапе проекта — там, где и так много напряжения — добавляется ещё и путаница с тем, что вообще было найдено.
Именно поэтому важно собирать все найденные на приёмке замечания в одном месте, привязанными к конкретному экрану или элементу, а не распределять их по пяти каналам связи. Так подрядчик видит список целиком, ничего не теряется между этапами, а финальная сдача проекта не превращается в разбор переписки за последнюю неделю.
Коротко — чек-лист, который можно пройти перед подписанием акта:
Сверка с ТЗ построчно. Все доступы переданы и оформлены на заказчика. Формы проверены с реальными тестовыми данными, заявки доходят до CRM. Подключён SSL, нет дублей адреса www/без www. Проверена скорость загрузки и вес изображений. Сайт корректно открывается и выглядит на мобильном. Акт приёма-передачи и список переданных материалов оформлены документально.
Если на сторонний ресурс нужен ещё один взгляд со стороны, полезно свериться с отраслевыми разборами цифровой приёмки — например, с отраслевым гайдом по приёмке цифровых продуктов, где эта же логика разбирается на примерах из смежных индустрий.
