Приёмка сайта у подрядчика: чек-лист, который защитит от типовых проблем
7 мин чтения15 минут + 10 пунктов чек-листа — готовая основа задачи разработчику.
Кому полезноРуководителю проекта и разработчику
Что станет понятноДомен и хостинг должны быть оформлены на владельца бизнеса, а не на подрядчика
С чем уйдёте15 минут + 10 пунктов чек-листа — готовая основа задачи разработчику.
Сайт сдан, акт подписан, а через месяц выясняется, что домен оформлен на подрядчика, формы не доходят, а половина страниц закрыта от поиска. Список проверок, которые делаются до подписания.
- Домен и хостинг должны быть оформлены на владельца бизнеса, а не на подрядчика
- Проверять нужно боевой сайт после выкладки, а не тестовую площадку
- Форму заявки обязательно проверять живой отправкой — с телефона и с компьютера
- Половина проблем находится в исходном коде страницы, а не на экране
- Приёмку проходит не тот, кто делал сайт, — иначе проверка формальна
- Почему приёмка «на глаз» не работает
- Блок 1. Доступы и права — проверяется первым
- Блок 2. Техническая часть — проверяется в браузере
- Блок 3. Что должно работать по-настоящему
- Что зафиксировать в договоре до начала работ
- Как оформить приёмку, чтобы она имела вес
- Путь клиента
- Стратегия по шагам
- Чек-лист
- Что в итоге
- Вопросы и ответы
Почему приёмка «на глаз» не работает
Обычная приёмка выглядит так: заказчик открывает сайт, листает страницы, смотрит на телефоне, находит опечатку и просит поправить. После этого акт подписывается.
Проблема в том, что таким способом проверяется только видимая часть — примерно треть того, от чего зависит работа сайта. Всё остальное живёт в исходном коде, в настройках сервера и в оформлении доступов, и обнаруживается через месяцы, когда исправлять уже некому.
Ниже — список, который проходится за два-три часа и закрывает основные риски. Он не требует технических знаний: почти всё проверяется в браузере, а для нескольких пунктов достаточно задать подрядчику вопрос и получить письменный ответ.


Блок 1. Доступы и права — проверяется первым
Это самый важный блок, и он же чаще всего пропускается. Без доступов вы не владелец сайта, а его арендатор.
1. Домен оформлен на вас. Проверяется в личном кабинете регистратора: администратор — ваша компания или вы лично. Домен, оформленный на подрядчика, — самый дорогой вид зависимости: вернуть его без согласия владельца долго и не всегда возможно.
2. Аккаунт хостинга — ваш. Оплата идёт с ваших реквизитов, доступ в панель у вас. Подрядчику даётся отдельный доступ, который можно отозвать.
3. Административный доступ к сайту. Учётная запись с полными правами, не «редактор».
4. Доступ к базе данных и файлам. Достаточно того, что он есть в панели хостинга.
5. Исходный код передан. Если разработка велась в репозитории — доступ к нему или архив.
6. Счётчики аналитики на вашем аккаунте. Подрядчику выдаётся гостевой доступ. Счётчик на аккаунте агентства означает, что при расставании вы теряете всю историю.
7. Почта на домене под вашим контролем. Через неё восстанавливаются все остальные доступы, поэтому это критичный пункт.
8. Список сторонних сервисов. Письменный перечень: что подключено, где оплачивается, когда продлевать. Обычно всплывают один-два сервиса, о которых заказчик не знал.

Блок 2. Техническая часть — проверяется в браузере
9. Сайт открывается по одному адресу. Проверьте четыре варианта написания адреса — с приставкой и без, с защищённым соединением и без. Все должны вести на один и тот же вариант, а не открываться параллельно: иначе поиск видит несколько копий сайта.
10. Защищённое соединение работает. Замок в адресной строке, без предупреждений. Заодно спросите, до какой даты действует сертификат и продлевается ли он автоматически.
11. Файл robots.txt не закрывает сайт. Откройте адрес сайта с добавлением /robots.txt. Строка, запрещающая обход всего сайта, — самая частая и самая дорогая ошибка при переносе с тестовой площадки.
12. Нет запрета индексации в коде. Откройте исходный код главной страницы и поищите слово noindex. Его быть не должно.
13. Карта сайта существует и заполнена. Адрес с /sitemap.xml должен открываться и содержать актуальные адреса, а не десяток страниц из шаблона.
14. У каждой страницы свой заголовок вкладки. Пройдите по десяти страницам и посмотрите на подписи вкладок в браузере. Одинаковые заголовки — признак незаполненных настроек.
15. Заголовок первого уровня — текст, а не картинка. Проверяется попыткой выделить заголовок мышью.
16. Несуществующая страница отдаёт ошибку 404. Наберите заведомо неверный адрес: должна открыться страница «не найдено», а не главная и не пустой экран.
17. Скорость на мобильном. Прогоните две-три страницы через бесплатный сервис проверки. Ориентир — не балл, а время загрузки основного содержимого.


Блок 3. Что должно работать по-настоящему
Эти пункты проверяются только действием — просмотр не даёт ничего.
18. Отправьте заявку через каждую форму. Через каждую, а не через одну. С телефона и с компьютера. Убедитесь, что письмо пришло, содержит все поля и не попало в спам.
19. Проверьте письмо, которое получает клиент. Если настроен автоответ — прочитайте его целиком. Часто там остаётся текст-заглушка от разработчика.
20. Нажмите на телефон с мобильного. Должен запускаться звонок. Номер, вставленный картинкой или неверно оформленный, — распространённая недоработка.
21. Проверьте кнопки мессенджеров. Каждая должна открывать нужный чат, а не главную страницу сервиса.
22. Пройдите весь путь покупки. Для магазина: положить в корзину, оформить заказ, дойти до оплаты. Хотя бы один тестовый заказ с реальной оплатой на минимальную сумму.
23. Проверьте счётчик аналитики. Откройте отчёт «в реальном времени» и зайдите на сайт с телефона. Ваш визит должен появиться. Заодно проверьте, что цели на формы срабатывают.


Что зафиксировать в договоре до начала работ
Большинство спорных ситуаций при приёмке возникает не потому, что подрядчик недобросовестный, а потому что стороны по-разному понимали объём. Пункты, которые снимают это заранее.
Кому принадлежат доступы. Прямая формулировка: домен, хостинг и аккаунты аналитики оформляются на заказчика с момента начала работ. Это исключает самый дорогой сценарий.
Порядок приёмки и срок на замечания. Например: заказчик проверяет в течение 10 рабочих дней, замечания направляет письменно, подрядчик устраняет в течение 10 рабочих дней. Без сроков процесс растягивается на месяцы.
Гарантийный период. Обычно 3–6 месяцев на устранение недостатков, возникших не по вине заказчика. Отдельно оговорите, что считается недостатком, а что — новой задачей.
Передача исходного кода. Прямо указать, что код и резервная копия передаются заказчику при сдаче. Если подрядчик работает на своей платформе и код не передаётся — это тоже нормально, но знать об этом нужно до начала, а не при расставании.

Как оформить приёмку, чтобы она имела вес
Проверяет не тот, кто делал. Разработчик смотрит на свою работу и видит то, что ожидает увидеть. Пройдите список сами или попросите постороннего человека.
Проверяется боевой сайт после выкладки. Тестовая площадка настроена иначе: там намеренно закрыта индексация, часто отключены письма и стоят тестовые ключи платёжной системы. Половина проблем возникает именно на переносе.
Результат фиксируется письменно. Список с отметками и датой, отправленный подрядчику письмом. Устные замечания забываются и не имеют веса при споре.
Часть оплаты — после приёмки. На практике это самый действенный механизм. Если весь платёж прошёл до проверки, устранение замечаний зависит только от доброй воли подрядчика.
Сохраните копию сайта. Резервная копия на момент приёмки, лежащая у вас, а не на хостинге подрядчика, — дешёвая страховка на случай любых будущих проблем.


window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'lead_submit',
form_id: 'audit',
page_path: location.pathname
});
Путь клиента: где эта тема срабатывает
Тема решает в момент, когда подрядчик присылает сообщение «сайт готов, можно принимать» и клиенту нужно за один-два дня решить, подписывать акт или нет.
Что у клиентаПодрядчик присылает ссылку и просит подписать акт закрытия работ, часто с дедлайном по оплате.
Что делаем
Сигнал, что работаетКлиент откладывает подписание до завершения проверки, а не подписывает «на веру».
Что у клиентаКлиент не понимает, на кого оформлен домен и кто может отключить сайт в будущем.
Что делаемПроверяем регистратора домена, хостинг-панель, админку CMS — везде должен быть владелец бизнеса как основной аккаунт.
Сигнал, что работаетКлиент лично заходит в панель регистратора и хостинга под своим логином.
Что у клиентаКлиент видит красивую верстку и решает, что этого достаточно для приёмки.
Что делаемОткрываем исходный код страниц, проверяем robots и индексацию, отправляем тестовую заявку с телефона и компьютера.
Сигнал, что работаетФорма реально пришла на почту или в CRM, страницы открыты для поиска там, где это нужно.
Что у клиентаКлиент готов закрыть проект и перейти к продвижению или запуску рекламы.
Что делаемФиксируем результаты проверки письменно, прикладываем к акту перечень проверенных пунктов и скриншоты.
Сигнал, что работаетАкт подписан с приложением, а не одной фразой «работы выполнены в полном объёме».
Стратегия: что делать по шагам
Цель: Пройти приёмку так, чтобы после подписания акта не осталось скрытых прав подрядчика на сайт и нерабочих функций.
Шкала собрана из сроков плана ниже. Это ориентир для последовательности работ.
- День 1 Собираем все доступы: домен, хостинг, админка CMS, почта, аналитика — и проверяем, кто указан владельцем. Список доступов с пометкой, что нужно переоформить на бизнес до подписания.
- День 2 Открываем боевой сайт (не тестовый) в браузере, смотрим исходный код страниц, robots.txt, наличие метатегов и заголовков. Перечень технических замечаний по факту, а не по демо-версии.
- День 3 Проверяем формы живой отправкой с телефона и компьютера, кнопки, переходы, корзину — всё, что должно работать по назначению. Подтверждение, что заявки реально доходят получателю.
- День 4 Привлекаем к проверке человека, который не участвовал в разработке — штатного сотрудника или другого специалиста. Независимый взгляд, который часто находит то, что разработчик пропустил как «само собой очевидное».
- День 5 Фиксируем итоги проверки письменно и прикладываем к акту закрытия работ вместе с перечнем прав, переданных бизнесу. Акт с приложением, на который можно ссылаться при возникновении споров.
Сроки — ориентир для планирования, а не обязательство: скорость зависит от ниши, конкуренции и состояния сайта.
Чек-лист: приёмка сайта у подрядчика
Пройдите по пунктам до подписания акта — после подписания требовать исправлений будет сложнее.
- Проверьте, на кого оформлен домен — владельцем должен быть бизнес, а не подрядчик
- Проверьте доступ к хостинг-панели под логином компании, а не только подрядчика
- Откройте боевую версию сайта, а не тестовую площадку разработчика
- Посмотрите исходный код ключевых страниц, а не только внешний вид
- Проверьте robots.txt и индексацию — часть страниц не должна быть закрыта от поиска без причины
- Отправьте тестовую заявку через форму с телефона и с компьютера и убедитесь, что она дошла
- Проверьте корзину, оплату, переходы по кнопкам — всё, что заявлено как рабочий функционал
- Поручите приёмку человеку, который не участвовал в разработке сайта
- Зафиксируйте результаты проверки письменно и приложите к акту
- Убедитесь, что права на исходный код и контент переходят к бизнесу по договору
Чаще всего проблемы находят не там, где смотрят — не на экране, а в исходном коде и в панели хостинга. Клиент листает страницы, видит, что всё красиво, и подписывает акт, а через месяц оказывается, что домен продлевается на аккаунт подрядчика. В наших проектах правило простое: приёмку проходит тот, кто не делал сайт, иначе проверка превращается в формальность.
Первоисточник: Документация 1С-Битрикс ↗ — справочник по проверке прав и настроек CMS
Что в итоге
Приёмка сайта — это не осмотр верстки на экране, а проверка того, что скрыто: кто владеет доменом, что видно в исходном коде, доходят ли заявки до получателя. Формальный акт без приложенного списка проверок защищает подрядчика, а не бизнес.
Самая частая ошибка — доверить приёмку тому же человеку, который делал сайт, или ограничиться визуальным осмотром за пять минут. Как правило, именно в этих случаях домен, права на код и рабочие формы всплывают проблемой уже после оплаты.
С чего начать: Перед следующей приёмкой соберите список доступов и попросите кого-то со стороны отправить тестовую заявку через форму — это займёт пятнадцать минут и покажет больше, чем внешний осмотр.
Вопросы и ответы
Что делать, если домен уже оформлен на подрядчика?
Запросить передачу прав администрирования — процедура стандартная и делается через регистратора. Если подрядчик отказывается, вопрос решается через регистратора и документы, подтверждающие, что домен использовался вашей компанией. Это долго, поэтому лучше не доводить.
Можно ли принимать сайт по частям?
Можно и часто разумно: сначала принять структуру и функции, затем содержимое. Но финальную проверку по техническим пунктам всё равно проводят на боевом сайте после полной выкладки.
Подрядчик говорит, что часть пунктов — это работа SEO-специалиста. Так ли это?
Заголовки, описания и стратегия — да. Но техническая доступность сайта, отсутствие запрета индексации, наличие карты сайта и корректная работа адресов — зона разработки. Разграничение стоит зафиксировать в договоре до начала работ.
Сколько времени занимает приёмка по такому списку?
Два-три часа для сайта услуг, до дня для интернет-магазина с проверкой оформления заказа. Это несопоставимо с временем, которое уходит на устранение тех же проблем через полгода.
Нужно ли привлекать стороннего специалиста для приёмки?
Для крупного проекта — да, независимая проверка окупается. Для сайта услуг список выше проходится самостоятельно: почти все пункты проверяются в браузере без специальных знаний.
Что делать, если замечания найдены после подписания акта?
Смотреть договор: обычно предусмотрен гарантийный срок на устранение недостатков. Если он есть — направить замечания письменно в его рамках. Если нет — договариваться, и это самый частый аргумент в пользу того, чтобы не подписывать акт до проверки.
Обязательно ли иметь доступ к исходному коду?
Желательно. Без него смена подрядчика превращается в переделку с нуля. Если код передавать отказываются, это стоит обсуждать до начала работ, а не по факту сдачи.
Кто отвечает, если на сайте использованы чужие фотографии?
Договориться с подрядчиком о возмещении можно, но только если в договоре зафиксирована его ответственность за передаваемые материалы.
Нужно ли проверять сайт на разных устройствах?
Обязательно: минимум телефон, планшет и компьютер, и хотя бы два разных браузера. Значительная часть проблем с формами и меню проявляется только на конкретных сочетаниях.
- Структура каталога, собранная из спроса, а не из выгрузки
- Ускорение загрузки первого экрана
- Интеграция форм с CRM без потери источника
- Редизайн без переноса структуры и адресов
- Тяжёлые изображения и скрипты «на всякий случай»
- Формы без передачи источника заявки
Что делать дальше
₽Посчитать экономикуСходится ли реклама при вашем чеке
?Задать вопросОтветим по вашей ситуации
Опишите задачу в двух словах — специалист ответит в Telegram, обычно в течение рабочего дня. Без презентаций и обязательств.
Написать в Telegram ↗✓Заявка на продвижениеОценить мой сайт
Бесплатно оценим текущее состояние и риски — до того, как вы начнёте что-то менять.
Поставьте оценку — она поможет редакции улучшать следующие разборы.
Обсуждение 17
Спросите, что осталось непонятным — автор материала отвечает в комментариях.


