Как принять сайт у разработчика в 2026 году: чек-лист приёмки и что проверить перед оплатой

Коротко: Принять сайт у разработчика — значит пройти структурированную проверку по 4 блокам: функциональность и визуал, техническое состояние (скорость, ошибки, кросс-браузерность), SEO-базис и безопасность, передача доступов и документации. Полная приёмка занимает 2–5 рабочих дней. Без неё 6 из 10 заказчиков сталкиваются с проблемами в первые 30 дней после запуска.

Почему приёмка сайта — это не формальность?

По данным опросов среди владельцев малого и среднего бизнеса в 2025–2026 годах, 58% заказчиков, которые приняли сайт «на глаз» (просто открыли в браузере и сказали «выглядит хорошо»), обнаружили критические баги или упущения в течение первого месяца работы. Типичные последствия: сломанная форма заявки (потеря лидов), отсутствие SSL-сертификата (браузеры блокируют сайт), неправильно настроенные редиректы (падение SEO), отсутствие резервного копирования.

Приёмка — это ваш единственный рычаг давления. После подписания акта и финальной оплаты большинство студий и фрилансеров переходят на платный режим поддержки. Исправление ошибок, которые не были зафиксированы при приёмке, обойдётся в 3 000–25 000 ₽ за каждый пункт в зависимости от сложности.

Сколько времени занимает правильная приёмка?

Время на приёмку зависит от типа проекта. Лендинг можно проверить за 4–8 часов, многостраничный корпоративный сайт требует 1–2 рабочих дней, интернет-магазин до 100 SKU — 2–3 дней, крупный e-commerce или веб-приложение — 4–7 рабочих дней. Закладывайте это время в проектный план заранее: многие заказчики не учитывают этап приёмки и потом торопятся, пропуская критические пункты.

Блок 1. Функциональность и визуал: что проверить глазами

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

Визуальное соответствие макету

• Сравните каждую страницу с утверждённым дизайн-макетом (Figma, Adobe XD). Отступы, цвета, шрифты, размеры — всё должно совпадать.
• Проверьте адаптивность: откройте сайт на реальных устройствах (iPhone, Android, планшет) и в браузерах Chrome, Safari, Firefox, Edge. Эмуляторы в DevTools не заменяют реальные устройства.
• Проверьте все состояния кнопок и ссылок: hover, active, disabled, visited.

Работа всех форм

• Заполните каждую форму на сайте и убедитесь, что заявка приходит на нужный email или в CRM.
• Проверьте валидацию: что происходит, если отправить форму с пустыми полями или некорректным email.
• Убедитесь, что после отправки появляется подтверждение (thank you page или всплывающее окно).
• Проверьте, что письмо-автоответ уходит пользователю (если предусмотрено ТЗ).

Контент и тексты

• Нет ли заглушек типа «Lorem ipsum», «Текст здесь», «НАЗВАНИЕ КОМПАНИИ».
• Все изображения загружены, не битые, имеют alt-теги.
• Все ссылки работают, нет ссылок на несуществующие страницы (404).
• Телефоны и email кликабельны на мобильных устройствах.

Блок 2. Техническое состояние: скорость, ошибки, безопасность

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

Скорость загрузки

Проверьте сайт через профильные сервисы проверки скорости. Минимально приемлемые показатели в 2026 году: LCP (Largest Contentful Paint) — не более 2,5 секунды, CLS (Cumulative Layout Shift) — не более 0,1, FID/INP — не более 200 мс. Мобильный балл скорости ниже 70 — повод требовать оптимизацию до подписания акта. Каждые 100 мс задержки снижают конверсию на 1–3% по данным Google.

SSL и безопасность

• Сайт открывается по HTTPS, замок в браузере зелёный.
• HTTP автоматически редиректит на HTTPS.
• Нет смешанного контента (mixed content): все ресурсы — изображения, скрипты, шрифты — загружаются по HTTPS.
• Для сайтов на WordPress: установлен плагин безопасности (Wordfence или аналог), стандартный путь /wp-admin изменён или защищён двухфакторной аутентификацией.

Консоль браузера

Откройте DevTools (F12) → вкладка Console. Красных ошибок быть не должно. Жёлтые предупреждения допустимы, но каждое нужно объяснить. Типичные красные ошибки, которые разработчики оставляют: 404 на JS/CSS файлы, CORS-ошибки при запросах к API, ошибки JavaScript в консоли.

Резервное копирование

Уточните у разработчика: настроено ли автоматическое резервное копирование, как часто, где хранятся бэкапы, как их восстановить. Отсутствие бэкапов — критический пункт. Восстановление сайта после сбоя без бэкапа стоит от 15 000 до 80 000 ₽.

Блок 3. SEO-базис: минимум, без которого сайт не найдут

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

Обязательный SEO-чек-лист при приёмке

• Title и description — уникальные для каждой страницы, не пустые, не дублируются.
• H1 — один на каждой странице, содержит ключевой запрос.
• robots.txt — файл существует, не закрывает важные страницы от индексации.
• sitemap.xml — сгенерирован, содержит все важные страницы, отправлен в Яндекс Вебмастер и Google Search Console.
• Канонические URL — настроены, нет дублей страниц (с www и без, с / и без).
• Open Graph теги — настроены для корректного отображения при шаринге в соцсетях.
• Микроразметка Schema.org — если предусмотрена ТЗ (для интернет-магазинов — обязательно).
• Скорость мобильной версии — Google индексирует mobile-first, мобильная версия важнее десктопной.

Блок 4. Передача доступов и документации

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

Что должно быть передано при приёмке

• Хостинг и домен — логин и пароль от панели управления хостингом, доступ к DNS-записям, домен зарегистрирован на вас (не на разработчика).
• CMS / админ-панель — логин и пароль администратора, инструкция по управлению контентом.
• Исходный код — доступ к репозиторию (GitHub/GitLab) или архив с исходниками. Это ваша собственность по договору.
• База данных — дамп базы данных или доступ к phpMyAdmin/аналогу.
• Сторонние сервисы — доступы к почтовым сервисам (SendGrid, UniSender), платёжным системам, CRM-интеграциям, аналитике (GA4, Яндекс Метрика).
• Документация — описание архитектуры, используемые технологии и версии, инструкции по деплою и обновлениям.
• Лицензии — на платные плагины, темы, шрифты, изображения (стоковые фото).

Важно: если разработчик отказывается передавать исходный код или доступы к хостингу — это нарушение договора (при условии, что в договоре прописан переход прав). Не подписывайте акт приёмки до получения всех доступов.

Как оформить результаты приёмки?

Все найденные проблемы фиксируйте письменно — в Google Docs, Notion, Jira или просто в email. Каждый баг описывайте по схеме: страница → описание проблемы → скриншот или запись экрана → ожидаемое поведение. Не принимайте устные обещания «исправим». Только письменное подтверждение с датой исправления.

После исправления всех критических замечаний подписывается акт приёмки-передачи работ. Это юридически значимый документ. До его подписания финальный платёж (обычно 30–50% от суммы договора) не перечисляется.

Что делать, если разработчик отказывается исправлять баги?

Если подрядчик отказывается устранять замечания, зафиксированные при приёмке, у вас есть несколько инструментов. Первый — претензионное письмо со ссылкой на конкретные пункты договора и ТЗ. Второй — привлечение независимого технического эксперта для составления экспертного заключения (стоимость — 5 000–20 000 ₽). Третий — обращение в суд или арбитраж: при наличии договора, ТЗ и переписки суды в 2025–2026 годах стабильно встают на сторону заказчика при доказанных нарушениях. Удержание финального платежа — законный инструмент давления до устранения замечаний.

Полный чек-лист приёмки: 42 пункта

Ниже — сжатый чек-лист для самостоятельной проверки. Распечатайте или скопируйте в Notion.

Визуал и функциональность (14 пунктов)

1. Соответствие макету на десктопе
2. Адаптивность на мобильных (реальные устройства)
3. Адаптивность на планшете
4. Кросс-браузерность (Chrome, Safari, Firefox, Edge)
5. Все формы работают и отправляют заявки
6. Валидация форм
7. Thank you page / подтверждение после отправки
8. Нет заглушек Lorem ipsum
9. Все изображения загружены
10. Все ссылки работают (нет 404)
11. Телефоны кликабельны на мобильных
12. Email кликабельны
13. Корректная работа поиска по сайту (если есть)
14. Корзина и оформление заказа (для e-commerce)

Техническое состояние (14 пунктов)

1. HTTPS работает
2. HTTP редиректит на HTTPS
3. Нет mixed content
4. Нет ошибок в консоли браузера
5. мобильный балл скорости ≥ 70
6. десктопный балл скорости ≥ 85
7. LCP ≤ 2,5 сек
8. CLS ≤ 0,1
9. Настроено резервное копирование
10. Настроен мониторинг доступности (Uptime)
11. Обновлены все плагины/зависимости
12. Закрыты технические страницы от индексации
13. Настроена защита от спама в формах (reCAPTCHA или аналог)
14. Нет уязвимостей по результатам базового сканирования

SEO-базис (8 пунктов)

1. Title уникальны для всех страниц
2. Description заполнены
3. H1 один на каждой странице
4. robots.txt корректный
5. sitemap.xml сгенерирован и отправлен
6. Настроены канонические URL
7. Open Graph теги заполнены
8. Alt-теги у изображений

Доступы и документация (6 пунктов)

1. Доступ к хостингу передан
2. Домен оформлен на заказчика
3. Доступ к CMS / админ-панели передан
4. Исходный код передан (репозиторий или архив)
5. Доступы к сторонним сервисам переданы
6. Документация и инструкции переданы

Часто задаваемые вопросы

Когда нужно проводить приёмку сайта?

Приёмку нужно проводить до подписания акта выполненных работ и до перечисления финального платежа. Обычно финальный платёж составляет 30–50% от суммы договора — это ваш главный рычаг давления. После оплаты большинство подрядчиков переходят на платный режим поддержки.

Сколько времени занимает приёмка сайта?

Лендинг — 4–8 часов. Корпоративный сайт (5–20 страниц) — 1–2 рабочих дня. Интернет-магазин до 100 SKU — 2–3 дня. Крупный e-commerce или веб-приложение — 4–7 рабочих дней. Закладывайте это время в проектный план заранее.

Должен ли разработчик передать исходный код сайта?

Да, если это прописано в договоре (а это стандартное условие). Исходный код — ваша интеллектуальная собственность. Разработчик обязан передать доступ к репозиторию (GitHub/GitLab) или архив с исходниками. Отказ передавать код — нарушение договора.

Какой балл скорости считается приемлемым при приёмке?

В 2026 году минимально приемлемые показатели: мобильный балл скорости — не ниже 70, десктоп — не ниже 85. LCP (Largest Contentful Paint) — не более 2,5 секунды, CLS — не более 0,1. Если показатели ниже — требуйте оптимизацию до подписания акта.

Что делать, если после приёмки обнаружились новые баги?

Если баги обнаружены в течение гарантийного срока (обычно 1–3 месяца по договору) — разработчик обязан исправить их бесплатно. Фиксируйте все проблемы письменно (email, мессенджер с историей). Устные договорённости юридически не работают.

Можно ли принять сайт без технических знаний?

Частично — да. Визуальную проверку, тестирование форм и проверку доступов может сделать любой заказчик. Для технической части (скорость, безопасность, SEO-базис) используйте бесплатные инструменты: сервис проверки скорости, SSL Labs, Screaming Frog (бесплатно до 500 URL). Для крупных проектов стоит нанять независимого QA-специалиста — это стоит 5 000–15 000 ₽ и окупается.

Что будет, если не провести приёмку и сразу оплатить?

По статистике, 58% заказчиков, которые приняли сайт без проверки, обнаруживают критические проблемы в первые 30 дней. После финальной оплаты исправление каждой ошибки переходит в платный режим: 3 000–25 000 ₽ за задачу в зависимости от сложности. Полноценная приёмка экономит в среднем 20 000–80 000 ₽ на постзапускных доработках.