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

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

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

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

С чего начать приёмку

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

Уточните, что уже работает, что пока не готово и как всё проверять. Для CRM, записи, каталога и оплаты заранее подготовьте с разработчиком тестовые данные и нужные аккаунты.

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

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

1. Пройдите основной путь клиента и проверьте получение заявки

Откройте главную или страницу услуги, найдите условия и отправьте тестовую заявку. Используйте свои контакты и пометку «Тест приёмки». Предупредите менеджера, чтобы он не принял её за настоящий заказ.

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

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

Сбой отправки проверяйте вместе с разработчиком в тестовом режиме. Отключать для этого рабочий сервис не нужно.

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

Нажмите на телефон, почту и мессенджеры: открывается ли нужное приложение, верно ли указан получатель? Если хотите проверить ещё и звонок, заранее предупредите того, кто его примет.

2. Для каталога, записи и оплаты проверьте особые сценарии

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

В магазине пройдите путь от выбора товара до появления заказа у менеджера. Сверьте вариант, количество, цену, доставку и общую сумму. Оплату сначала проверьте в тестовом режиме поставщика: пусть разработчик покажет, как это сделать и что произойдёт с заказом. Не начинайте с несогласованного платежа настоящей картой.

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

Отраслевые сценарии отличаются. В гайдах о заказе сайтов разобраны варианты для 22 сфер. Дополнительно можно посмотреть проверку гостиничного сайта перед рекламой: выбор дат и подтверждение бронирования нельзя заменить тестом обычной формы с телефоном.

3. Откройте сайт с телефона

Возьмите свой телефон и откройте сайт в браузерах, которые решили поддерживать. Узкое окно на компьютере не покажет, как мешает экранная клавиатура или что происходит при нажатии пальцем.

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

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

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

4. Проверьте тексты и сравните сайт с макетами

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

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

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

Тексты и условия должен проверить человек, который знает ваш бизнес. Разработчик исправит отображение цены, но сказать, правильная ли она, можете только вы.

5. Проверьте настройки перед запуском

Попросите разработчика показать следующие настройки и объяснить, что уже сделано:

Что проверить	Какое подтверждение получить
Основной адрес и HTTPS	Сайт открывается на согласованном домене без предупреждения браузера
Страницы и ошибки	Нужные адреса открываются; для неизвестного адреса предусмотрена страница ошибки
Перенос адресов	Согласованные старые ссылки ведут на соответствующие новые страницы
Метаданные	У опубликованных страниц есть уместные title, description и заголовки
Индексация	Настройки публичных и служебных страниц соответствуют плану запуска
Резервная копия	Понятны состав копии, место хранения, ответственный и способ восстановления

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

По документации Google, noindex запрещает индексацию страницы, когда робот может прочитать это правило. Закрытие обхода через robots.txt — другой механизм. Поэтому ответ «robots.txt есть» сам по себе не подтверждает правильную настройку. Даже корректная техническая подготовка не гарантирует включение в индекс или позиции.

Посмотрите, как сайт открывается на обычном телефоне: не приходится ли ждать картинки, не прыгают ли блоки, быстро ли отзываются кнопки? Попросите и результаты замеров по типичным страницам. Core Web Vitals помогают оценивать эти вещи. Но одного балла в тесте мало, а статистики реальных посетителей у нового сайта может ещё не быть.

Если вы заказывали проверку безопасности, нагрузки или восстановления из копии, попросите отчёт. Само наличие HTTPS не означает, что эти проверки проведены.

6. Проверьте счётчик и цели

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

В инструкции Яндекс Метрики описана проверка целей через _ym_debug=2 и панель отладки для нового кода счётчика. Попросите разработчика показать её на вашем сайте; для старого кода в инструкции есть другой способ.

Цель может сработать на клик, отправку формы или другое действие. Поэтому проверьте отдельно событие в Метрике и доставку заявки. Клик — ещё не обращение и тем более не продажа.

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

7. Войдите в аккаунты и выполните обычное обновление

Попросите перечень сервисов: домен, размещение, CMS или конструктор, аналитика, почта, CRM и другие подключения. Для каждого должны быть понятны владелец, права вашего аккаунта, способ восстановления доступа, период оплаты и ответственный за продление.

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

Попробуйте изменить цену, заменить фотографию и опубликовать изменения. Затем откройте страницу с телефона. Если вам обещали самостоятельное добавление услуг или товаров, создайте новый материал: это сложнее, чем поправить уже готовый текст.

Если сайт на конструкторе, убедитесь, что проект передали в ваш аккаунт. Тильда принимает такие передачи только на фактически оплаченный Personal или Business; пробного периода недостаточно. Для сайта на коде получите исходники, нужные доступы и инструкции по сборке и размещению.

Уточните границы поддержки: что считается ошибкой, куда обращаться, когда ждать реакции и как оцениваются новые задачи. Не предполагайте бессрочное обслуживание только потому, что сайт уже оплачен.

Как записать замечание, чтобы его можно было исправить

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

Условный пример замечания:

№ 07. Страница «Диагностика», мобильный браузер, дата — [дата]. Открываю форму, ввожу тестовые имя и телефон, нажимаю «Отправить». По F03 в ТЗ менеджеру должна прийти заявка с названием услуги. На сайте появляется «Спасибо», но заявки у получателя нет. Прилагаю время отправки и скриншот. Нужно проверить доставку; причина пока неизвестна.

Пока причина не найдена, не спешите обвинять форму или CRM. Передайте разработчику шаги и результат. После исправления повторите ту же проверку: одного сообщения «готово» в чате недостаточно.

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

Короткий чек-лист перед завершением приёмки

1. Состав страниц и функций сверен с актуальным заданием и изменениями.
2. Основной путь клиента пройден с компьютера и телефона.
3. С каждой формы пришла тестовая заявка.
4. Каталог, запись, расчёты и оплата проверены в предусмотренных для проекта сценариях.
5. Контакты, цены, фотографии, файлы и тексты подтверждены ответственным компании.
6. Меню, всплывающие окна и сообщения об ошибках доступны на мобильном экране.
7. Основной домен, HTTPS, нужные адреса и перенаправления проверены.
8. Проверено, какие страницы должны попасть в поиск, а какие — нет.
9. Аналитика и цели проверены отдельно от доставки обращения.
10. Вы получили нужные аккаунты, файлы и инструкции, знаете, как восстановить доступ.
11. Владелец самостоятельно выполнил типовую правку.
12. Замечания повторно проверены; ограничения, поддержка и разрешение на запуск зафиксированы.

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

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