Как принять готовый сайт у подрядчика: проверка до финальной оплаты

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

Проверку лучше разделить на результат для посетителя, техническое качество и владение проектом. Автоматические сервисы полезны, но не заменяют ручные действия.

Зафиксируйте версию для приёмки

Подрядчик должен назвать:

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

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

Проверьте главные сценарии

Составьте реальные маршруты:

• найти услугу и отправить форму;
• позвонить с телефона;
• добавить товар и оформить заказ;
• зарегистрироваться;
• восстановить пароль;
• скачать документ;
• открыть карту;
• воспользоваться фильтром;
• получить письмо;
• изменить статус в CRM.

Проходите их на компьютере и телефоне. Используйте корректные, пустые и ошибочные данные.

Для каждой формы проверьте:

• обязательные поля;
• понятные ошибки;
• маску телефона без ловушки;
• согласие на обработку;
• защиту от спама;
• сообщение об успехе;
• фактическое получение заявки;
• источник и UTM;
• повторную отправку при сбое.

Зелёная надпись «спасибо» не доказывает, что лид дошёл.

Контент и интерфейс

Проверьте:

• нет ли черновых текстов;
• корректны ли цены и контакты;
• все ли ссылки открываются;
• документы актуальны;
• изображения имеют смысл и alt;
• заголовок страницы один;
• текст читается на узком экране;
• кнопки доступны пальцем;
• фокус клавиатуры виден;
• интерактивные элементы работают без мыши;
• анимация не мешает чтению.

W3C подчёркивает, что автоматический инструмент не может полностью определить доступность. Нужна ручная оценка.

Устройства и браузеры

Минимальная матрица согласуется заранее. Обычно проверяют актуальные Chrome, Safari, Firefox или Edge, iOS и Android, несколько ширин экрана.

Ищите:

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

Реальное устройство обнаруживает проблемы, которых нет в эмуляторе.

Скорость

PageSpeed Insights и Lighthouse дают полезные сигналы, но оценка меняется от запуска к запуску. Смотрите на причины:

• слишком тяжёлое главное изображение;
• блокирующие стили;
• лишний JavaScript;
• отсутствие размеров картинок;
• долгий ответ сервера;
• шрифты;
• сторонние виджеты.

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

SEO перед запуском

Для всех индексируемых URL:

• 200 OK;
• правильный canonical;
• уникальные Title, Description и H1;
• нет noindex;
• robots.txt не закрывает сайт;
• sitemap содержит только канонические страницы;
• старые URL перенаправлены;
• внутренняя навигация ведёт на финальные адреса;
• микроразметка валидна;
• Open Graph соответствует странице;
• тестовый домен закрыт от индексации.

Если меняются URL старого сайта, нужна таблица соответствий и постоянные редиректы. Google рекомендует готовить карту старых и новых адресов и отдельно проверять снятие тестовых запретов.

Аналитика

Проверьте в реальном времени:

• установлен ли счётчик;
• исключён ли внутренний трафик при необходимости;
• фиксируются ли формы;
• работают ли клики по телефону и мессенджерам;
• передаются ли UTM;
• нет ли дублей событий;
• кто владеет аккаунтами;
• есть ли доступ у команды клиента.

Событие должно называться понятно и документироваться.

Безопасность

Для обычного сайта минимум включает:

• HTTPS без ошибок;
• уникальные учётные записи;
• отсутствие общих паролей;
• минимальные права;
• обновлённые компоненты;
• защищённую административную панель;
• резервное копирование;
• проверенное восстановление;
• безопасную обработку форм;
• отсутствие секретов в публичном коде;
• журналирование критичных действий.

Для приложения требования фиксируют глубже. OWASP ASVS можно использовать как основу проверки безопасности в закупке и приёмке.

Что должно быть передано

Владелец получает:

• домен;
• хостинг;
• CMS;
• репозиторий или архив исходников;
• базу данных;
• аналитику;
• Search Console и Вебмастер;
• аккаунты интеграций;
• лицензии;
• дизайн-исходники;
• документацию;
• список зависимостей;
• инструкцию резервного копирования;
• контакты поддержки.

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

Документация без формальности

Минимальная инструкция отвечает:

• как добавить страницу;
• как изменить контакты;
• как посмотреть заявки;
• как обновлять систему;
• как создать резервную копию;
• как восстановиться;
• как выкатить изменение;
• куда смотреть при ошибке;
• что нельзя менять без специалиста.

Проверьте инструкцию действием: пусть сотрудник клиента выполнит типовую операцию сам.

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

Хорошая запись содержит:

• URL;
• устройство и браузер;
• шаги;
• ожидаемый результат;
• фактический результат;
• скриншот или видео;
• приоритет.

«Всё поехало» трудно воспроизвести. «На iPhone при ширине 390 px кнопка формы перекрывается меню после шага 3» — рабочая задача.

Критичность:

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

Когда можно подписывать акт

Проект готов, если:

• основные сценарии пройдены;
• блокеры закрыты;
• остальные замечания зафиксированы;
• доступы переданы;
• резервная копия создана и проверена;
• аналитика получает события;
• запускной SEO-чек выполнен;
• определены гарантия и поддержка;
• клиент понимает, как управлять сайтом.

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

Вывод

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

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

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

Источники и документы

1. W3C WAI: оценка доступности сайта
2. OWASP ASVS: проверка безопасности приложений
3. Google: перенос сайта с изменением URL