Акт приёма-передачи сайта: чек-лист приёмки перед подписанием

Акт приёма-передачи сайта — последний документ проекта и последний момент, когда исправления входят в уже оплаченную смету. После подписи позиция сторон меняется: на явные недостатки, которые можно было увидеть при обычной проверке и которые не оговорены в акте, по ст. 720 ГК ссылаться уже нельзя, а любая правка превращается в новую задачу с новым счётом. Поэтому приёмка — это не просмотр главной страницы с ноутбука, а отдельная работа на несколько дней по списку.

Ниже — практический чек-лист приёмки нового сайта: что проверить, чем и кто из вашей команды это делает, что писать в акте, как оформить замечания и что делать с гарантийным периодом. Материал для владельцев и руководителей, которые принимают корпоративный сайт, интернет-магазин или сервис у студии или фрилансера. Это не юридическая консультация: формулировки акта и договора стоит согласовать с юристом.

Что должно быть готово до приёмки: ТЗ, договор и тестовый стенд

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

• Техническое задание или согласованный прототип — список страниц, функций, интеграций и сценариев. Всё, что проверяется ниже по функционалу, сверяется именно с ним.
• Договор — порядок приёмки, срок на проверку, срок на исправление замечаний, гарантийный срок и состав передаваемых материалов. Как эти пункты прописать заранее, разобрано в статье о договоре на разработку сайта.
• Список согласованных изменений — переписка или протоколы, где меняли объём работ. Без них спор «это было в ТЗ / это доработка» решается в пользу того, у кого лучше память.

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

Функционал по ТЗ: формы, оплата, личный кабинет, поиск и фильтры

Функции проверяются сценариями, а не кликами по кнопкам. Возьмите ТЗ и пройдите путь реального клиента от входа до результата, фиксируя каждое отклонение.

Формы заявок

Отправьте каждую форму — обратный звонок, заявку, расчёт, подписку. Заявка должна дойти во «Входящие» (не в спам) нужного адресата и в CRM, если интеграция предусмотрена, со всеми полями, включая UTM-метки и страницу отправки. Проверьте валидацию телефона и почты, сообщение об успехе, защиту от спама и поведение при двойном нажатии.

Оплата и заказ

Проведите реальный платёж на минимальную сумму картой и через СБП, затем возврат. Проверьте, что статус заказа меняется в админке, клиенту приходит письмо, а онлайн-касса формирует чек по 54-ФЗ. Отдельно — неуспешная оплата: что видит покупатель и не «зависает» ли заказ. Для магазина с обменом с 1С сделайте заказ и убедитесь, что он появился в учётной системе, а остатки и цены пришли обратно.

Личный кабинет

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

Поиск, каталог и фильтры

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

Админка

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

Мобильная версия, браузеры и скорость загрузки

Кроссбраузерность: только реальные устройства

Режим адаптивности в браузере на ноутбуке не заменяет телефон: он не показывает поведение клавиатуры, реальную скорость на мобильной сети, особенности Safari на iPhone и системный масштаб шрифта. Минимальный набор для приёмки:

• iPhone с Safari и Android-смартфон с Chrome или Яндекс Браузером — разных размеров экрана;
• Chrome, Яндекс Браузер, Safari и Firefox на компьютере, ширины 1280, 1440 и 1920 пикселей;
• планшет в двух ориентациях, если его доля в аналитике заметна.

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

Скорость: PageSpeed Insights и Core Web Vitals

Проверьте 5–7 типовых страниц — главную, каталог, карточку товара или услуги, статью, контакты — в PageSpeed Insights в мобильном режиме. У нового сайта ещё нет полевых данных реальных пользователей, поэтому ориентируйтесь на лабораторные показатели и прогоните каждую страницу 2–3 раза: результат плавает. INP в лабораторном тесте не измеряется — его косвенно заменяет TBT (Total Blocking Time).

Если сервер отвечает быстро, а страница грузится долго, проблема во фронтенде — тяжёлые картинки, скрипты, шрифты — и её решает разработчик. Если сервер отвечает 2 секунды даже на простой странице, вопрос к хостингу, кэшированию или запросам в базу. Нормы скорости лучше заранее вписать в ТЗ: «до 90 баллов на мобильных» без указания страниц и условий замера — не критерий приёмки.

SEO-база и аналитика перед запуском

Индексация, редиректы, разметка

Самая частая находка при приёмке — сайт, закрытый от поисковиков с этапа разработки. Проверяйте запрет индексации в четырёх местах: robots.txt, мета-тег robots, заголовок ответа сервера X-Robots-Tag и настройка «закрыть от индексации» в самой CMS.

• title и description — уникальны на каждой странице, шаблоны для каталога и карточек работают, нет «Главная» и «Новая страница».
• robots.txt — открыт для боевого домена, закрыты служебные разделы, корзина, поиск, параметры сортировки; указан путь к карте сайта.
• sitemap.xml — генерируется автоматически, содержит только рабочие страницы с кодом 200, без тестовых адресов.
• Главное зеркало и 301 — из четырёх вариантов адреса (http/https, с www и без) открывается один, остальные ведут на него постоянным 301-редиректом без цепочек. При редизайне — карта редиректов со старых адресов на новые.
• canonical — есть на страницах с параметрами и пагинацией, указывает на правильный адрес.
• Микроразметка — Organization, BreadcrumbList, Product с ценой и наличием для магазина; проверка валидатором Яндекса без ошибок.
• Страница 404 — несуществующий адрес отдаёт код 404 (не 200 и не редирект на главную) и понятную страницу с навигацией.

Отдельно ищите демо-контент: «Lorem ipsum», тестовые товары, страницы «Пример» из шаблона. Поисковик их проиндексирует вместе с остальным.

Яндекс Метрика, цели и Вебмастер

Счётчик Метрики должен стоять на всех страницах, быть создан на аккаунте компании (подрядчику — гостевой доступ) и включать Вебвизор. Главное — цели: отправка каждой формы, клик по телефону и мессенджерам, оформление заказа, успешная оплата. Отправьте тестовую заявку и убедитесь, что цель засчиталась. Для магазина — электронная коммерция с передачей товаров и суммы. Сайт добавлен в Яндекс Вебмастер с подтверждёнными правами владельца на вашем аккаунте, указано главное зеркало, отправлена карта сайта.

Безопасность и юридическая часть

HTTPS, админка, обновления и пароли

• HTTPS — действующий сертификат с автопродлением, нет смешанного содержимого (картинки и скрипты по http), http перенаправляет на https.
• Админка — у вас собственная учётная запись с правами администратора; общие учётки вроде admin/admin удалены; у подрядчика — отдельный пользователь, которого можно отключить.
• Версии — CMS, модули, язык (PHP, Node.js) и библиотеки актуальны и находятся на поддержке. Сайт, сданный на снятой с поддержки версии, сразу начинает копить технический долг.
• Секреты — ключи платёжных систем и API не лежат в открытом виде в репозитории, отладочный режим выключен, нет публичных дампов базы и архивов в корне сайта.
• Резервное копирование — настроено, копии хранятся отдельно от сервера, и вам показали, как восстановить сайт из копии.

Персональные данные, согласия, cookie

Любая форма с именем и телефоном — это обработка персональных данных по 152-ФЗ. На приёмке проверьте, что на сайте опубликована политика обработки ПДн вашей компании (не шаблон с чужими реквизитами), у форм есть согласие на обработку, оформленное отдельно от других документов (требование 156-ФЗ с 1 сентября 2025 года), без заранее проставленных галочек, а согласие на рекламные рассылки отделено от согласия на обработку заявки. Если работают Метрика и другие сервисы, использующие cookie, — уведомление о cookie с их перечнем. База данных с ПДн граждан РФ должна храниться на серверах в России. Для магазина — оферта, реквизиты продавца, условия доставки и возврата.

С 30 мая 2025 года действуют повышенные штрафы за утечки по ст. 13.11 КоАП (420-ФЗ), а при повторной утечке — оборотные, поэтому, если сайт собирает много данных, есть личный кабинет или онлайн-оплата, имеет смысл заказать аудит сайта на соответствие 152-ФЗ до запуска рекламы.

Передача: доступы, исходники, документация и лицензии

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

Что должно оказаться у вас на руках:

• доступы к регистратору домена, хостингу или серверу, админке, почте на домене, DNS, Метрике и Вебмастеру, платёжному кабинету, CRM и внешним сервисам;
• исходный код в репозитории вашей компании (не архивом «на флешке») и дамп базы данных, скачанный себе;
• исходники дизайна — файлы Figma в вашем рабочем пространстве, шрифты, иконки;
• документация: инструкция для контент-менеджера, описание развёртывания, список интеграций и сторонних сервисов с условиями их оплаты, перечень доработок ядра CMS, если они есть;
• лицензии: на платную CMS (например, 1С-Битрикс — на ваше юрлицо), платные модули, шрифты и фотографии со стоков.

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

Что писать в акте приёма-передачи сайта

Типовой акт «работы выполнены в полном объёме, претензий нет» заказчику почти ничего не даёт. Полезный акт фиксирует, что именно передано и в каком состоянии. Примерная структура:

1. Реквизиты — номер и дата договора, этап или весь объём, стороны.
2. Предмет — адрес сайта, версия (номер релиза или коммита в репозитории), ссылка на ТЗ, которому он соответствует.
3. Перечень переданного — исходный код с указанием репозитория, дамп базы, дизайн-макеты, документация, лицензии; доступы — списком сервисов, без паролей в тексте акта.
4. Права — отметка о передаче исключительных прав или лицензии в объёме, предусмотренном договором.
5. Результат проверки — «принято без замечаний» либо «принято с замечаниями согласно приложению» либо мотивированный отказ.
6. Замечания и сроки — приложение с перечнем и датами устранения.
7. Гарантия — дата начала гарантийного срока, если договор привязывает её к акту.
8. Сумма — стоимость принятых работ, подписи и печати.

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

Как оформить замечания и сроки на исправление

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

• Блокирующие — не работает оплата, формы, вход, сайт закрыт от индексации. Без их исправления акт не подписывается.
• Существенные — сломан сценарий на одном из устройств, нет целей в аналитике, не переданы доступы. Можно подписать акт с замечаниями и сроком устранения, обычно 5–10 рабочих дней, либо удержать часть оплаты до исправления, если это предусмотрено договором.
• Косметические — опечатки, отступы, мелкие расхождения с макетом. Исправляются в рамках гарантии или пакетом.

Отличайте дефект от пожелания. «Кнопка не отправляет форму» — дефект. «Хочу кнопку другого цвета», если цвет согласован в макете, — новая задача. Смешивание этих списков — главная причина затяжной приёмки и конфликтов. После исправления проводится повторная проверка только по списку замечаний.

Гарантийный период после подписания акта

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

Гарантийный срок обычно отсчитывается с даты финального акта. Если гарантийный срок не установлен, по ст. 724 ГК недостатки можно предъявить, если они обнаружены в разумный срок, но в пределах двух лет со дня передачи результата, — и доказывать их придётся заказчику. Важно, как устроена работа по гарантии: куда писать, в какой срок подрядчик реагирует и исправляет, что считается гарантийным случаем. Без этих деталей гарантия остаётся строчкой в договоре. После окончания гарантии сайт переходит на поддержку — по отдельному договору и с понятным регламентом.

Когда нужен независимый аудит перед подписанием акта

Чек-лист выше закрывает то, что видно снаружи. Качество кода, архитектуру, запросы к базе, правки ядра CMS и безопасность серверной части заказчик без технической команды не проверит, а подрядчик не будет объективно проверять сам себя. Независимая экспертиза оправдана, если:

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

Технический аудит сайта и кода перед подписанием даёт отчёт с перечнем рисков, их критичностью и оценкой исправления — его удобно приложить к замечаниям по акту. Экспресс-аудит небольшого сайта — от 30 000 ₽ за 3–5 рабочих дней, полный аудит магазина или сайта с интеграциями — от 60 000 ₽ за 7–10 рабочих дней; точная цена зависит от объёма кода и стека. Заложите это время в срок на приёмку заранее, иначе оно не поместится в пять дней «молчаливой приёмки».

Сводная таблица, типовые ошибки и итоговый чек-лист приёмки

Сводная таблица приёмки: что проверить, как и кто

Распределите проверку между людьми: владелец не обязан сам смотреть заголовки ответа сервера, но должен убедиться, что это кто-то сделал.

Ошибки, из-за которых платят дважды

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

Чек-лист перед подписанием акта

• ТЗ, договор и список согласованных изменений собраны, срок на проверку достаточный
• Все формы, оплата, личный кабинет, поиск и фильтры пройдены сценариями из ТЗ
• Сайт проверен на iPhone, Android и в четырёх браузерах на ПК
• Скорость ключевых страниц в PageSpeed Insights в норме, сервер отвечает быстро
• Сайт открыт для индексации, главное зеркало и 301 настроены, sitemap, canonical, 404 и микроразметка работают
• Метрика на аккаунте компании, цели срабатывают, сайт добавлен в Вебмастер
• HTTPS, собственная учётка администратора, актуальные версии, бэкапы с проверенным восстановлением
• Политика ПДн, отдельные согласия и cookie-баннер на месте
• Домен и хостинг на вас, код в вашем репозитории, дизайн, документация и лицензии переданы
• Замечания оформлены таблицей со сроками, в акте — перечень переданного и дата начала гарантии

Приёмка по такому списку занимает 1–3 рабочих дня для корпоративного сайта и 5–10 — для магазина или сервиса. Это дешевле любого исправления, которое придётся оплачивать после подписи акта.