Кратко: приёмка сайта — это не «посмотреть и похвалить», а формальная проверка результата по договору и техническому заданию до финальной оплаты. Пройдите по чек-листу: контент и структура страниц, работа форм и интерактивных элементов, скорость загрузки, мобильная версия и браузеры, SEO-база (метатеги, ЧПУ, карта сайта), SSL и передача доступов, гарантийные обязательства и акт приёмки. Ниже — таблица из 15 пунктов проверки, список бесплатных инструментов и порядок действий, который защитит ваши деньги, сроки и нервы.
Самый рискованный момент проекта — не разработка, а её финиш. Сайт показан, «вроде всё работает», заказчик переводит остаток суммы — и через неделю выясняется, что форма заявки отправляла письма в никуда, а в мобильном браузере не раскрывается меню. Приёмка существует именно для того, чтобы такие сюрпризы всплывали до оплаты, а не после: она превращает размытое «готово» в список конкретных проверок с понятным критерием «работает / не работает».
Этот материал — часть серии для заказчиков. Если вы ещё выбираете исполнителя, начните со статьи о том, как проверить подрядчика перед заказом сайта, а на старте проекта подготовьте требования по нашему чек-листу технического задания. Здесь разберём финишную прямую: как принимать готовый сайт, что проверять и на что подписывать документы.
Зачем нужна формальная приёмка, а не «взгляд со стороны»
Пока оплата не внесена, у заказчика есть главный рычаг влияния — деньги. Формальная приёмка связывает этот рычаг с конкретными критериями: вы платите не за «красиво», а за выполнение пунктов ТЗ и работоспособность каждой функции. Подрядчику приёмка тоже выгодна: она ограничивает поток «а можно ещё», потому что всё вне ТЗ оформляется отдельными доработками за отдельную плату.
Вторая причина — юридическая. Подписанный акт приёмки фиксирует, что результат соответствует договору, запускается гарантийный срок и переходят права на сайт. Если принять работы «на словах» и обнаружить брак через месяц, доказать, что недостатки были уже при сдаче, будет сложно: исполнитель сошлётся на то, что сайт «испортили» уже после передачи. Поэтому акт подписывается только после проверки, а не до неё.
Третья причина — дисциплина сроков. Когда в договоре прописано, что заказчик проверяет сайт по чек-листу в течение 5–7 рабочих дней, а подрядчик обязан исправить замечания бесплатно, у проекта появляется финал. Без этого механизма проекты живут в режиме вечного «почти готово»: исполнителю проще забросить недоделку, чем доделывать без понятных критериев.
Поэтапная приёмка или одна финальная: как строить процесс
Проверять всё разом в конце проекта — плохая стратегия: ошибка в дизайне, обнаруженная на готовом сайте, тянет за собой переделку вёрстки и наполнения. Правильный процесс — поэтапная приёмка, когда каждый этап закрывается актом или письменным согласованием. Ориентир по количеству этапов и их длительности даёт статья про этапы разработки сайта от брифа до запуска.
| Этап проекта | Что проверяет заказчик | Критерий «принято» |
|---|---|---|
| Дизайн-макеты | Структура страниц, стиль, соответствие бренду и референсам | Макет соответствует ТЗ, правки внесены и согласованы письменно |
| Вёрстка | Соответствие макетам в браузере, адаптивность | Страницы выглядят как макеты на компьютере и телефоне |
| Наполнение | Тексты, изображения, структура меню | Все страницы из карты сайта заполнены, «рыбы» нет |
| Функционал | Формы, корзина, поиск, калькуляторы | Каждый сценарий проходит от начала до конца |
| Финальная приёмка | Полный чек-лист: скорость, SEO-база, доступы, документы | Акт подписан, права переданы, гарантия стартовала |
На промежуточных этапах достаточно письменного согласования («макет главной утверждаю, работаем дальше») — акты нужны на ключевых точках: после вёрстки и по итогам проекта. Если подрядчик сопротивляется поэтапной приёмке и тянет к «покажем всё в конце», это повод перечитать материал про проверку подрядчика по чек-листу: зрелые команды работают этапами, потому что так дешевле исправлять ошибки — и им, и вам.
Что подготовить до приёмки: документы и окружение
Приёмка начинается не с открытия сайта, а с подготовки трёх вещей. Первая — техническое задание: сверка идёт именно по нему, а не по памяти. Если ТЗ нет вообще, приёмка превращается в спор о вкусах — в этом случае хотя бы составьте короткий список требований до начала проверки. Вторая — договор: в нём должны быть порядок сдачи-приёмки, гарантийный срок и ответственность сторон; подробный разбор формулировок есть в статье про договор на разработку сайта.
Третья — тестовое окружение. Готовый сайт принимается на рабочей версии, размещённой на хостинге, а не на локальном компьютере разработчика. Если проект делался на тестовом поддомене, заранее договоритесь о порядке переноса на основной домен — и включите повторную проверку после переноса в план приёмки: перенос — штатная, но не безгрешная операция.
Соберите и список своих данных: реквизиты для тестовой оплаты (если принимаете магазин), почтовые ящики, куда должны приходить заявки, логотип и материалы в исходном качестве. Тестовые заказы лучше оформлять на реальные, но проверяемые данные — так вы увидите весь путь заявки от формы до письма или CRM, а не «оно вроде ушло».
Контент и структура: что смотреть в первую очередь
Начните с карты сайта — перечня страниц, зафиксированного в ТЗ. Откройте каждую страницу и проверьте три вещи: она существует, она доступна из меню (или по нужному адресу), она заполнена. Особое внимание — страницам-сателлитам для рекламы и услугам: именно на них чаще всего остаются страницы-заглушки, потому что основную часть проекта подрядчик делал внимательно, а хвосты — по остаточному принципу.
Дальше — вычитка. Опечатки в текстах, картинки-заглушки, дублирующиеся заголовки, кнопки «Подробнее», ведущие в никуда, — всё это выглядит мелочью, но для посетителя сайта это маркер небрежности всей компании. Тексты проверяются не только на ошибки, но и на смысл: написано ли то, что согласовывалось, подставлены ли реальные цены и контакты, нет ли остатков тестового контента вроде «Ваш текст заголовка».
Проверьте навигацию как живой человек, а не как владелец проекта: зайдите на сайт «холодным» взглядом и попробуйте найти конкретную услугу, цену и контакт. Структура меню, хлебные крошки, страница 404 (которая должна предлагать перейти на главную или в каталог, а не показывать голую надпись) — всё это часть контентной приёмки. Отдельный пункт — страницы ошибок и поиск: введите несуществующий запрос и посмотрите, что вам покажут.
Функциональность: формы, корзина и интерактив
Главный принцип функциональной приёмки — каждая функция проверяется живым действием, а не объяснением «оно работает». Каждая форма на сайте — тестовая отправка: заявка с главной, форма в контактах, заказ звонка, подписка. После отправки проверьте полный цикл: сообщение об успешной отправке показалось, письмо пришло на согласованную почту (или заявка появилась в CRM и Telegram), поля, обязательные для заполнения, действительно обязательны, а защита от спама не мешает живым людям.
Для интернет-магазина сценарий шире: добавление товара в корзину, изменение количества, применение промокода, оформление заказа, тестовая оплата через платёжный шлюз в тестовом режиме шлюза, письмо покупателю и уведомление продавцу. Каждый шаг — отдельная строка в вашем чек-листе: письмо с заказом, которое не доходит до продавца, — самая дорогая ошибка магазина, и приёмка для того и существует, чтобы поймать её до оплаты.
Интерактивные элементы проверяются по одному: фильтры каталога (включая комбинации фильтров), сортировка, поиск, калькуляторы (сверьте результат с ручным расчётом), слайдеры, вкладки, аккордеоны, всплывающие окна. Модальные окна должны корректно закрываться, а кнопки — иметь рабочие состояния наведения. Не стесняйтесь «ломать» сайт намеренно: введите в поле телефона буквы, отправьте пустую форму, загрузите в галерею тяжёлую фотографию — поведение сайта в нештатных ситуациях тоже часть качества.
Техническая проверка: скорость, мобильная версия, браузеры
Технический блок приёмки не требует знаний программирования — нужны бесплатные инструменты и системность. Скорость измеряется сервисом PageSpeed Insights от Google: он же проверяет и мобильную версию, показывая отдельные оценки для телефонов и компьютеров. Ориентир для готового сайта — зелёная зона или хотя бы 70+ баллов на мобильных; хуже — повод для замечания, потому что скорость напрямую влияет и на поведение посетителей, и на продвижение.
Мобильную версию проверяйте на реальном смартфоне, а не только в эмуляторе: раскрытие меню, размер кнопок, отсутствие горизонтальной прокрутки, читаемость текста, работа форм. Что именно должно быть в мобильной версии и как её проверять — подробный разбор в статье про мобильную версию сайта. Браузеры проверяются по минимуму из четырёх: Chrome, Safari (обязательно, если аудитория заходит с iPhone), Firefox и Edge — достаточно беглого прохода по ключевым страницам.
| Инструмент | Что проверяет | Ориентир готовности |
|---|---|---|
| PageSpeed Insights | Скорость загрузки, мобильная адаптация | 70+ баллов на мобильных, нет критичных ошибок |
| Реальные смартфоны | Меню, кнопки, формы на телефоне | Всё нажимается, вёрстка не разваливается |
| Chrome / Safari / Firefox / Edge | Кроссбраузерность ключевых страниц | Нет развалов вёрстки и неработающих элементов |
| Консоль браузера (F12) | Ошибки JavaScript и 404-запросы | Консоль без красных ошибок на ключевых страницах |
| Онлайн-сканеры ссылок | Битые внутренние и внешние ссылки | Ноль битых ссылок |
Скорость и стабильность зависят и от площадки: если хостинг выбирает подрядчик, уточните тариф и посмотрите, соответствует ли он задаче — критерии выбора разобраны в статье про выбор хостинга для сайта. Сайту с каталогом на тысячу товаров и корпоративной визитке нужен разный уровень ресурсов, и «самый дешёвый тариф» на старте — частая причина медленной работы.
SEO-база: что проверить для продвижения
Даже если продвижение в планах не сегодня-завтра, базовая SEO-гигиена проверяется на приёмке — потом переделывать дороже. Первый пункт — метатеги: у каждой страницы должен быть свой уникальный title (до 60–70 символов, с ключевым запросом) и description (до 160–170 символов). Откройте 5–7 ключевых страниц и посмотрите заголовок вкладки браузера: если везде одинаковый текст «Главная — Название компании», это замечание.
Второй блок — технические файлы и структура адресов. Адреса страниц должны быть человекочитаемыми (ЧПУ): /uslugi/sozdanie-sajtov/, а не /?page_id=123. Файл robots.txt должен открываться и не запрещать важные разделы, sitemap.xml — содержать все страницы сайта, favicon — отображаться во вкладке. Заголовки на страницах: один H1 с ключевым запросом, логичная иерархия H2–H3 — как в этой статье.
Если это редизайн существующего сайта, добавляется самый важный пункт — редиректы: каждый старый адрес должен вести 301-редиректом на соответствующую новую страницу, иначе сайт потеряет позиции, накопленные за годы. Как проходит редизайн без потери трафика и что требует отдельного внимания — описано в материале про редизайн сайта без потери SEO. Проверяется просто: возьмите список из 10–15 старых адресов и откройте их — вы должны попадать на нужные новые страницы, а не на 404.
Безопасность и доступы: что получить вместе с сайтом
Первое, что проверяется за десять секунд, — SSL-сертификат: адрес сайта начинается с https, а браузер показывает замок без предупреждений «незащищённое соединение». Это влияет и на доверие посетителей, и на SEO, и на работу форм. Что такое SSL и каким он должен быть — разбор в статье про SSL-сертификаты для сайта.
Второе — передача доступов. По завершении проекта заказчик должен получить полный комплект: административную панель сайта, аккаунт хостинга, доступ по FTP/SFTP, доступ к базе данных, панель регистратора домена, аккаунты аналитики (Яндекс Метрика, Google Analytics) и почтовые сервисы, от имени которых уходят письма с сайта. Принцип простой: домен и хостинг оформлены на вас, подрядчик работает под выданными доступами — тогда никакой конфликт не оставит сайт «заложником».
Третье — пароли и резервные копии. Все временные пароли, которые использовались в работе, меняются на новые, придуманные заказчиком. Подрядчик демонстрирует, что настроено автоматическое резервное копирование и бэкап реально скачивается или восстанавливается — страховка от любого сбоя. И последнее: уточните, какие платные темы, плагины и лицензии используются, на кого они оформлены и когда заканчивается подписка — иначе через год обновления просто перестанут приходить.
Чек-лист приёмки сайта: 15 пунктов перед финальной оплатой
Соберём всё в компактную таблицу. Перед подписанием акта пройдитесь по ней как по инструктажу перед вылетом: 20–30 минут проверки экономят недели переделок и споров.
| № | Что проверяем | Как проверяем | Критерий готовности |
|---|---|---|---|
| 1 | Соответствие ТЗ | Сверка по пунктам технического задания | Все пункты ТЗ закрыты или письменно согласованы изменения |
| 2 | Структура страниц | Обход по карте сайта из ТЗ | Нет потерянных и лишних страниц |
| 3 | Контент | Вычитка текстов и проверка изображений | Нет «рыбы», заглушек и опечаток на ключевых страницах |
| 4 | Навигация и 404 | Поиск информации «холодным» взглядом | Услуга, цена и контакты находятся за три клика |
| 5 | Формы | Тестовая отправка каждой формы | Письмо/CRM-уведомление приходит, ответ показывается |
| 6 | Магазин (если есть) | Тестовый заказ с оплатой в тестовом режиме шлюза | Заказ проходит, письма получает обе стороны |
| 7 | Мобильная версия | Реальный смартфон: меню, формы, картинки | Вёрстка не разваливается, всё нажимается |
| 8 | Скорость | PageSpeed Insights | 70+ баллов на мобильных, нет критичных ошибок |
| 9 | Браузеры | Chrome, Safari, Firefox, Edge | Ключевые страницы работают одинаково |
| 10 | Битые ссылки | Онлайн-сканер ссылок | Ноль битых внутренних ссылок |
| 11 | Метатеги и ЧПУ | Постраничная проверка заголовков и адресов | Уникальные title/description, человекочитаемые URL |
| 12 | robots.txt и sitemap.xml | Открыть файлы по адресу сайта | Файлы доступны, адреса актуальны |
| 13 | SSL и доступы | Замок в браузере + вход по всем переданным логинам | Https работает, все аккаунты принадлежат заказчику |
| 14 | Бэкапы и лицензии | Тестовое восстановление копии, список платных лицензий | Копия восстанавливается, лицензии оформлены на заказчика |
| 15 | Документы и обучение | Акт, передача прав, инструкция подрядчика | Акт подписан, вы умеете менять базовый контент |
Если замечания нашлись — это нормальная часть процесса, а не «срыв сдачи». Замечания фиксируются одним списком с приоритетами (критично / желательно), подрядчик называет срок исправления, повторная проверка проходит только по пунктам замечаний. Финальная оплата вносится после закрытия критичных пунктов; мелкие пожелания можно унести в гарантийный период или оформить отдельной доработкой.
Частые вопросы о приёмке сайта
Сколько времени занимает приёмка сайта?
Визитка или лендинг проверяется за 2–4 часа, корпоративный сайт — за 1–2 дня, интернет-магазин — 2–3 дня из-за большего числа сценариев. В договоре обычно закладывают 5–7 рабочих дней на проверку: это комфортный срок и для заказчика, и для исполнителя. Затягивать проверку на недели не стоит — гарантийный срок стартует с подписания акта, а не с фактического начала использования.
Что делать, если недостатки нашлись уже после оплаты?
Действуйте по договору: опишите недостатки письменно и сошлитесь на гарантийный срок — дефекты в рамках ТЗ исправляются бесплатно. Поэтому так важно зафиксировать гарантию в договоре до старта: длительность, срок реакции и что считается ошибкой. Если гарантии нет и подрядчик отказывается — оценивайте стоимость исправления через другого специалиста и взвешивайте, стоит ли спор сэкономленных денег.
Сайт отличается от ТЗ, но получилось лучше. Принимать?
Отличия от ТЗ в лучшую сторону — тоже отличия, и их нужно оформить письменно: допсоглашение или хотя бы почта с формулировкой «изменения согласованы, принимаю». Это защищает обе стороны: подрядчик получает подтверждение, что инициатива одобрена, вы — фиксацию того, что изменилось. Молчаливое «ну, получилось же хорошо» создаёт прецедент, что ТЗ можно не соблюдать.
Подрядчик торопит с приёмкой и просит оплатить «по факту демо». Как реагировать?
Спешка на финише — красный флаг. Нормальная практика: подрядчик уведомляет о готовности, даёт 5–7 рабочих дней на проверку и принимает замечания списком. Если просят оплату сразу после короткой демонстрации, предложите компромисс: оплату после проверки по чек-листу в течение 1–2 дней — вы не затягиваете проект, а проверяете то, за что платите. Ссылайтесь на пункт договора о порядке приёмки.
Я не разбираюсь в технологиях. Кто проверит сайт за меня?
Большая часть чек-листа не требует технических знаний: контент, формы, меню, мобильная версия проверяются обычным пользователем. Технические пункты закрываются инструментами из таблицы — PageSpeed Insights и сканеры ссылок работают в пару кликов. Если хочется страховки, закажите независимый аудит у стороннего специалиста (не у вашего подрядчика): стоить он будет несопоставимо меньше, чем исправление невыявленных проблем.
Обязательно ли подписывать акт приёмки, если работали по оферте?
Оферта заменяет сам договор, но не отменяет приёмку: письменно зафиксируйте, что работы по заказу №X выполнены и приняты, укажите дату и остаток оплаты. Для оферты такой фиксацией может служить подписанный скан акта или одностороннее письмо-подтверждение после проверки. Без этой бумаги сложнее доказать дату сдачи, а от неё отсчитывается гарантийный срок и переход прав на сайт.
Вывод: приёмка — это защита ваших денег, а не недоверие подрядчику
Хороший подрядчик воспринимает подробную приёмку как признак адекватного заказчика, а не как оскорбление: чек-лист экономит время обеих сторон и закрывает вопросы до оплаты, а не в спорах после. Порядок действий простой: принимайте проект поэтапно, проверяйте каждую функцию живым действием, сверяйте результат с ТЗ, фиксируйте замечания одним списком и подписывайте акт только после закрытия критичных пунктов.
Если хотите, чтобы этапность и прозрачная приёмка были частью процесса с самого начала, посмотрите услуги разработки сайтов и примеры сданных проектов в портфолио — а с вопросами по своему проекту пишите через форму контактов. Каждый наш проект сдаётся с поэтапным согласованием и финальной проверкой по чек-листу — именно так, как описано в этой статье.
Больше материалов для заказчиков — в блоге delai-sait.ru. Логичное продолжение темы: поддержка сайта после запуска — что происходит с сайтом после приёмки, и сроки разработки сайта — чтобы планировать проверку этапов без авралов.
