Привет, я Максим, веб-разработчик. Подрядчик говорит «сайт готов» — а вы не знаете, как проверить, действительно ли он готов. Принять сырой сайт — потерять деньги на бесконечных доработках. Отправить на переделку без чётких аргументов — испортить отношения и затянуть сроки. Я подготовил подробный чек-лист из сорока пунктов, который использую на каждом проекте. Он систематизирует приёмку и помогает избежать типичных конфликтов между заказчиком и разработчиком.
Зачем нужен формальный процесс приёмки
Многие заказчики принимают сайт «на глаз»: открыли, покликали, вроде работает — подписали акт. А через месяц начинают сыпаться проблемы: формы не отправляют письма, на iPhone экран уезжает, в Яндекс Вебмастере ошибки, скорость загрузки — десять секунд. Переделывать после подписания акта — уже за отдельные деньги.
Формальная приёмка по чек-листу защищает обе стороны. Заказчик получает подтверждение, что сайт соответствует ТЗ и стандартам качества. Подрядчик получает чёткий список замечаний вместо размытых «что-то не так» и «переделайте всё». Я рекомендую включать процедуру приёмки в договор на разработку — это снимает большинство споров.
Блок 1: Функциональность
Это самый важный блок — сайт должен работать как задумано.
Все страницы из технического задания созданы и наполнены контентом. Проверяю каждую страницу по списку из ТЗ — бывает, что забывают создать страницу «Доставка» или «Гарантия». Все формы работают корректно: заполняю каждую форму тестовыми данными, проверяю, что письмо приходит на указанный email, данные попадают в CRM или админку сайта. Обязательно проверяю формы на мобильном — часто именно там они ломаются.
Для интернет-магазинов — прохожу весь путь покупки от начала до конца: добавляю товары в корзину, оформляю заказ, проверяю расчёт стоимости доставки, тестирую оплату (хотя бы тестовым платежом). Каждый шаг, который не работает, — это потерянные продажи после запуска. Поиск по сайту должен возвращать релевантные результаты — вбиваю типичные запросы и смотрю, что выдаёт.
Если есть личный кабинет — тестирую регистрацию, авторизацию и восстановление пароля. Проверяю, что все ссылки ведут куда нужно — для этого прогоняю сайт через сервис проверки битых ссылок (Screaming Frog или онлайн-аналоги). Кнопка «Назад» в браузере не должна ломать навигацию — это частая проблема на SPA-сайтах.
Блок 2: Дизайн и вёрстка
Открываю утверждённый макет в Figma и сравниваю с реализацией. Сайт должен соответствовать макету — не пиксель в пиксель, но достаточно точно, чтобы дизайнер не схватился за голову. Отступы, размеры шрифтов, цвета — всё должно быть близко к макету.
Адаптивная вёрстка — отдельная проверка. Открываю сайт на реальных устройствах: iPhone SE (самый маленький актуальный экран), стандартный Android-смартфон, планшет, десктоп. Проверяю: на мобильных ничего не вылезает за экран, нет горизонтальной прокрутки, текст читаем без масштабирования, кнопки достаточно большие для нажатия пальцем (минимум 44 на 44 пикселя).
Шрифты должны загружаться корректно — без мигания текста (FOUT) или невидимого текста (FOIT). Изображения — не растянуты, не обрезаны, в нужном качестве. Favicon установлен и отображается на вкладке браузера. Мелочь, но отсутствие фавикона выглядит непрофессионально.
Блок 3: SEO-база
Здесь проверяю минимум, без которого сайт не сможет нормально индексироваться. Title и meta description заполнены для всех ключевых страниц — не шаблонные, а уникальные для каждой. Заголовки H1 — ровно по одному на каждой странице, и они соответствуют содержанию. Alt-теги у всех изображений заполнены — это требование и для SEO, и для доступности.
Файл robots.txt настроен правильно: не блокирует нужные страницы, блокирует служебные (админку, страницы фильтрации с параметрами, корзину). Sitemap.xml сгенерирован, содержит все публичные страницы и доступен для поисковиков. Canonical-теги установлены — особенно важно для интернет-магазинов с фильтрацией, где один товар может быть доступен по нескольким URL.
URL-адреса — человекочитаемые (ЧПУ): /catalog/krossovki/ вместо /catalog?id=347. Это влияет и на SEO, и на удобство пользователя.
Блок 4: Скорость и производительность
Запускаю Google Lighthouse в режиме инкогнито на мобильном пресете. Performance — минимум 70, для сложного сайта с динамическим контентом это реалистичный порог. Если ниже — смотрю, что тянет вниз.
Изображения должны быть оптимизированы: формат WebP, сжатие, правильные размеры (не загружать картинку 3000 пикселей для блока шириной 600). Lazy loading для изображений ниже первого экрана — обязательно. CSS и JavaScript — минифицированы. В консоли браузера не должно быть ошибок — каждая ошибка может указывать на сломанный функционал.
Блок 5: Безопасность
SSL-сертификат установлен, сайт открывается по HTTPS. Проверяю, что при обращении по HTTP автоматически происходит редирект на HTTPS — иначе поисковик увидит две версии сайта. Админка защищена надёжным паролем, а ещё лучше — двухфакторной аутентификацией.
Формы обратной связи защищены от спама — через reCAPTCHA, hCaptcha или хотя бы honeypot-поле. Без защиты в первую же неделю после запуска вы получите сотни спам-заявок. Бэкап настроен и проверен — причём проверен именно восстановлением, а не просто наличием файла. Один мой клиент обнаружил, что бэкап был пустым, только когда сервер упал.
Блок 6: Аналитика
Яндекс Метрика установлена и корректно считает визиты — проверяю, зайдя на сайт и посмотрев, появился ли визит в отчёте в реальном времени. Цели настроены: заявка, звонок, покупка, клик по email или телефону. Без целей вы не сможете оценить эффективность ни рекламы, ни самого сайта.
Яндекс Вебмастер подключён — через него будете отслеживать индексацию, ошибки, позиции. Для интернет-магазина — настроена электронная коммерция в Метрике. Если планируете рекламу — проверьте, что на сайте установлены пиксели ВКонтакте, Яндекс Аудиторий и других используемых площадок.
Блок 7: Контент
Тексты без орфографических и грамматических ошибок — прогоняю через Яндекс Спеллер или Орфограммку. Контактная информация актуальна и совпадает с реальной: телефон, адрес, email, время работы. Политика конфиденциальности и публичная оферта (или договор оказания услуг) размещены и содержат актуальные данные — это требование 152-ФЗ. Страница 404 оформлена — кастомная, а не стандартная ошибка сервера, с навигацией и ссылкой на главную.
Блок 8: Передача доступов и юридическое оформление
Критически важный блок, который многие игнорируют. Все доступы должны быть переданы заказчику: панель управления хостингом, регистратор домена, админка сайта, FTP или SSH, репозиторий кода, Яндекс Метрика, Яндекс Вебмастер, почтовые аккаунты. Если что-то из этого остаётся на аккаунтах подрядчика — вы в зависимости.
Исходный код передан — в виде Git-репозитория или хотя бы архива. Акт приёмки подписан обеими сторонами с указанием, что работы выполнены по ТЗ. Если есть замечания — они фиксируются отдельным приложением к акту с указанием сроков исправления.
Как пользоваться этим чек-листом на практике
Я рекомендую пройти по каждому пункту и отметить статус: «ОК», «Замечание» или «Критично». Критичные замечания — те, которые блокируют запуск: не работает оплата, сайт не открывается на мобильных, нет SSL. Некритичные — допускают запуск с условием исправления в оговорённый срок: мелкие визуальные расхождения с макетом, незаполненные alt-теги на второстепенных страницах.
Отправляйте подрядчику структурированный список замечаний, а не разрозненные сообщения в мессенджере. Таблица с колонками «Пункт — Описание — Скриншот — Приоритет» экономит время обоим сторонам. Этот подход я использую на каждом проекте — он экономит нервы, деньги и гарантирует, что сайт запускается в рабочем состоянии, а не дорабатывается ещё полгода после старта.