Приёмка сайта у подрядчика: что проверить, прежде чем платить и подписывать акт

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

Что считать готовым к оплате

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

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

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

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

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

Закрытая задача в трекере не равна принятому сайту: проверьте сценарий и его результат.

Мнение. Для сайта услуг с формой заявки начните с проверки доставки заявок и передачи домена с доступами. Если у вас нет корзины и оплаты, проверять магазинный контур не нужно.

Акт и существенный недостаток

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

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

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

Частичная приёмка подходит, когда одна часть проекта работает, а другой сценарий остаётся сломанным. Опишите, что именно не работает, и согласуйте с подрядчиком дальнейшие действия и расчёты по договору.

Не подписывайте акт «для бухгалтерии» с устной оговоркой «потом поправим». Устная договорённость не попадёт в документ.

Макеты и служебные страницы

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

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

Отдельно откройте страницу 404 и пустое состояние списка. Белый экран или сообщение об ошибке вместо понятного объяснения мешают посетителю продолжить работу.

При сверке с макетом проверьте:

• сетку, отступы и шрифты ключевых страниц;
• состояния кнопки «отправить»;
• опечатки и содержимое подвала;
• изображения;
• фавикон и превью ссылки;
• страницу 404 и пустой список.

Базовая поисковая готовность

Проверьте, что поисковые роботы могут открыть сайт, а метаданные относятся к рабочему домену. Откройте robots.txt и sitemap.xml, затем проверьте исходный код страниц из сценариев. Такая проверка помогает найти технические препятствия для индексации, но не предсказывает позиции в поиске.

У ключевых страниц должны быть заполнены title и description. Сравните их между собой: одинаковые метаданные на разных страницах могут затруднить понимание их содержания.

В исходном коде проверьте, не остались ли на рабочем сайте директивы noindex и nofollow, добавленные для тестового стенда. Убедитесь, что canonical указывает на рабочий адрес. Проверьте переход с HTTP на HTTPS и выбранную версию домена с www или без него. Если переносите старые адреса, заранее согласуйте карту редиректов. Микроразметку проверяйте, если она входила в ТЗ.

Скорость и Core Web Vitals

На приёмке записывайте, чем и как измеряли скорость. Отчёт Lighthouse или PageSpeed Insights показывает лабораторный замер, а полевые данные Core Web Vitals основаны на визитах пользователей. На новом сайте таких данных может ещё не быть, поэтому лабораторный отчёт не заменяет полевую оценку.

Для проверки согласуйте инструмент, тип устройства, страницы и критерии в договоре или приложении к нему. В документации Core Web Vitals описаны метрики LCP, INP и CLS. Один удачный скриншот сам по себе не показывает, стабильно ли сайт работает.

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

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

Лабораторный отчёт показывает работу сайта в условиях теста. Он не заменяет полевые данные по визитам пользователей.

Адаптив и доступность

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

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

Пройдите форму с клавиатуры: переключайтесь между полями клавишей Tab и проверяйте, виден ли фокус. Контраст текста и фона сверяйте с WCAG, если этот критерий включён в ТЗ. Проверка на глаз не подтверждает соответствие стандарту.

Для ручной проверки адаптива:

• телефон: проверьте прокрутку и доступность кнопок;
• планшет: посмотрите, не перекрывают ли карточки друг друга;
• компьютер: сравните шапку и подвал с макетом;
• форма: проверьте видимый фокус при переходе клавишей Tab;
• подписи: убедитесь, что текст читается на фоне.

Формы, CMS и краевые состояния

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

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

Проверьте каталог в разных состояниях: без товаров, с одной позицией, с длинным названием и с карточкой без фотографии. Вместо пустого экрана или слова «undefined» посетитель должен видеть понятный результат.

Порядок проверки формы:

Приёмка интернет-магазина

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

В корзине проверьте добавление товара, изменение количества и удаление позиции. Промокод проверяйте, если он был в ТЗ. После обновления страницы убедитесь, что корзина ведёт себя так, как согласовано в проекте.

В оформлении заказа проверьте успешный тестовый платёж и отказ в оплате. Отказ не должен отображаться как успешная покупка. Убедитесь, что письмо клиенту и запись в CMS появляются, если эти действия входят в ТЗ. Остатки, фильтры и карточки без фото проверяйте на данных проекта.

Если проект включает интеграцию с CRM или 1С, проверьте создание заказа и передачу статуса. Отложенная выгрузка подходит только тогда, когда такое поведение согласовали заранее.

Проверьте магазин на этих сценариях:

• товар остаётся в корзине после обновления, если это предусмотрено ТЗ;
• после оплаты заказ появляется в CMS;
• письмо клиенту отправляется, если это входит в проект;
• пустая выдача фильтра показывает понятное сообщение.

Домен, SSL и доступы

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

Откройте сайт по HTTPS и проверьте, не загружаются ли отдельные изображения или ресурсы по HTTP. Сверьте статус сертификата в браузере или панели хостинга. Для домена проверьте доступ к панели регистратора и возможность управлять настройками продления.

Перед передачей соберите хостинг, CMS, репозиторий, исходники макетов, сведения о лицензиях и резервные копии, если они входят в проект. Проверьте вход в почту домена и настройки SPF и DKIM, если почту настраивали в рамках работ. Один вход на личную почту разработчика — повод запросить отдельный способ восстановления доступа.

152-ФЗ, счётчики и замечания

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

Счётчик Яндекс Метрики и цель отправки формы проверяйте, если аналитика входит в ТЗ. Проверьте, что счётчик работает на нужных страницах и фиксирует отправку формы. Вебмастер и Search Console передавайте на аккаунт заказчика, если их настраивали для проекта. Сквозной сценарий поможет найти разрыв: заявка -> цель в Метрике -> запись в CRM.

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

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

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

Источники

• Гражданский кодекс Российской Федерации (часть вторая) — КонсультантПлюс
• Федеральный закон «О персональных данных» № 152-ФЗ — КонсультантПлюс
• Core Web Vitals — web.dev / Google