Готовый дизайн и открывающаяся главная страница ещё не повод принимать работу у подрядчика. Перед запуском заказчику стоит проверить сайт как рабочий инструмент: пройти путь клиента с телефона и компьютера, отправить заявки, намеренно ошибиться при заполнении формы, дождаться обращения в системе менеджера и убедиться, что владелец контролирует домен, хостинг и аналитику.
Приёмку лучше проводить до перевода проекта в статус «готово». Исправить найденный дефект на этом этапе обычно проще, чем разбираться с ним после старта рекламы, публикации адреса сайта в социальных сетях или рассылки ссылки клиентам. Сам факт запуска не гарантирует рост продаж, поискового трафика или позиций: сайт сначала должен корректно выполнять задачи, ради которых его заказывали.
Сверьте готовый сайт с задачами и согласованным объёмом работ
Откройте техническое задание, прототипы, дизайн-макеты и список согласованных функций. Проверяйте не только наличие страниц, но и пользовательские сценарии: может ли посетитель понять предложение компании, выбрать услугу, найти контакты и отправить обращение.
Не оценивайте работу только по принципу «нравится или не нравится». У сайта для бизнеса есть функции, которые легко проверить, а спор о цвете кнопки не заменяет тест формы заявки или мобильного меню. Заказчику, который ещё выбирает подрядчика либо сверяет состав работ перед договором, может пригодиться страница Оркестратор — разработка сайтов; при самой приёмке ориентиром остаются требования, согласованные именно для Вашего проекта.
Проверьте мобильную версию на обычном телефоне
Просмотр страницы в узком окне браузера помогает быстро найти часть дефектов, но не заменяет проверку на телефоне. Откройте сайт хотя бы на нескольких доступных устройствах и повторите действия, которые должен выполнять клиент. Проверьте главную страницу, услуги, контакты, формы, меню, всплывающие окна и страницы, на которые ведёт реклама.
На небольшом экране текст не должен выходить за границы блока, кнопки не должны перекрывать друг друга, а горизонтальная прокрутка без предусмотренной причины говорит о проблеме в адаптивной вёрстке. Отдельно посмотрите, удобно ли нажимать пункты меню пальцем, виден ли номер телефона, можно ли закрыть всплывающее окно и не скрывает ли экранная клавиатура активное поле формы.
Поверните телефон, увеличьте системный размер текста и проверьте страницу при другом масштабе браузера. Такие действия хорошо выявляют слабые места адаптивной вёрстки. Для проектов на конструкторе полезен и материал о том, как устроены мобильная версия и публикация сайта на Tilda.
Убедитесь, что посетителю понятно, чем занимается компания
Попросите человека, который не участвовал в проекте, открыть главную страницу и коротко пересказать предложение компании. По экрану должно быть понятно, какие услуги доступны, кому они подходят и какое действие можно сделать дальше. Если смысл приходится объяснять голосом, проблема уже есть в структуре или тексте.
Особенно внимательно проверьте страницы услуг. Название услуги, описание, состав работ, ограничения, порядок обращения и контакты должны согласовываться между собой. Не оставляйте на опубликованном сайте черновые подписи, шаблонные тексты, тестовые фотографии, пустые блоки и кнопки, ведущие не туда.
Посмотрите на страницу глазами человека, который ничего не знает о Вашей компании. Он не видел техническое задание и не присутствовал на обсуждении проекта, поэтому все важные пояснения должны находиться на самом сайте. Хорошая страница услуги отвечает хотя бы на базовые вопросы: что предлагает компания, кому подходит услуга, как связаться с менеджером и какой следующий шаг нужно сделать.
Протестируйте форму заявки при правильном и ошибочном вводе
Форма считается рабочей не тогда, когда кнопка нажимается, а когда обращение проходит весь путь до места, где его увидит менеджер. Заполните поля корректно, отправьте заявку и проверьте подтверждение на странице. Посетитель должен ясно понять, что сообщение принято; бесконечная анимация загрузки или молчание после нажатия оставляют его в неопределённости.
Затем намеренно вводите ошибки. Оставьте требуемое поле пустым, укажите некорректный адрес электронной почты, введите неподходящие символы в телефон, превысьте допустимую длину поля. Сайт должен показать понятную подсказку рядом с проблемным местом и дать человеку исправить ввод.
Отдельно дважды нажмите кнопку отправки и проверьте, что повторное нажатие не создаёт дублирующие обращения. Такая проблема встречается, когда сервер отвечает не сразу, а пользователь решает, что нажатие не сработало. Особенно полезно повторить этот тест при искусственно замедленном соединении.
Проверьте и поведение формы после ошибки. Поля, заполненные верно, не должны очищаться без причины. После исправления ошибочного значения отправка должна проходить штатно, а подтверждение — появляться один раз. Если в форме предусмотрены чекбокс согласия и ссылка на документ о конфиденциальности, проверьте их отображение и работу.
Проследите заявку от сайта до менеджера
После успешной отправки откройте почту, CRM или другую систему, куда по проекту должны поступать обращения. Сверьте имя, телефон, электронную почту, комментарий, страницу отправки и другие поля, которые нужны отделу продаж. Внешне исправная форма мало полезна, если часть информации теряется по дороге или письмо попадает в ящик, который никто не просматривает.
Проверьте несколько форм, если они размещены на разных страницах. Заявка с формы обратного звонка, страницы конкретной услуги и контактов может передаваться по разным сценариям. Ошибка в одной форме не всегда проявится в другой.
Для сайта, связанного с рекламой и CRM, стоит отдельно проверить передачу служебных меток и идентификаторов, предусмотренных настройкой. На Kvodo есть руководство про интеграцию Яндекс Директ и CRM, где разобран путь обращения от сайта до системы учёта. При приёмке Вашего проекта сверяйте именно те поля и каналы, которые закреплены в техническом задании.
Проверьте подтверждение отправки заявки
После нажатия кнопки клиент не должен гадать, ушло сообщение или нет. На странице нужен понятный результат действия: сообщение об успешной отправке либо уведомление об ошибке. Если открывается отдельная страница благодарности, проверьте адрес, текст и переход на неё.
Не ограничивайтесь визуальным сообщением на сайте. После появления надписи об успешной отправке убедитесь, что обращение действительно дошло до менеджера. Ситуация, когда посетителю показывается подтверждение, а информация не поступает в почту или CRM, намного опаснее очевидной ошибки формы.
Посмотрите, как сайт работает при медленном интернете
На быстром офисном Wi-Fi часть проблем трудно увидеть. Откройте инструменты разработчика в браузере, включите ограничение скорости сети и повторите ключевые действия. Страница должна оставаться понятной во время загрузки: элементы не должны хаотично перемещаться по экрану, а повторное нажатие кнопки отправки не должно плодить одинаковые обращения.
Особенно внимательно смотрите на крупные изображения, фоновые видео, веб-шрифты, меню и формы. Если отдельный ресурс не загрузился, основной текст и нужные действия не должны исчезать вместе с ним. При обрыве отправки форма должна сообщить о проблеме, а не показывать ложное подтверждение.
Повторите проверку на мобильном интернете. Такой тест ближе к условиям, в которых сайт увидит часть посетителей. Если страница долго показывает пустой экран из-за одного тяжёлого элемента, это стоит передать разработчику до запуска.
Проверьте ссылки, кнопки и основные сценарии переходов
Пройдите по меню, кнопкам на первом экране, карточкам услуг, контактам и ссылкам в подвале. Телефон должен открывать набор номера там, где это предусмотрено, адрес электронной почты — почтовое приложение, а кнопки — именно те страницы или формы, которые соответствуют их подписи.
Особое внимание уделите кнопкам с одинаковым текстом на разных страницах. При копировании блоков ссылка внутри кнопки иногда остаётся от старой страницы. Внешне элемент выглядит нормально, а посетителя отправляет не туда.
Проверьте страницы ошибок и несуществующие адреса. Если пользователь попал по старой или ошибочной ссылке, он не должен видеть технический экран сервера. Нормальная страница 404 помогает понять, что адрес не найден, и даёт путь обратно к полезным разделам сайта.
Перед приёмкой получите доступы владельца
Домен бизнеса должен находиться под контролем владельца или компании. Проверьте учётную запись регистратора, контактную почту, продление и права на управление DNS. Подрядчику можно дать отдельный доступ, но основной контроль не стоит оставлять на личной учётной записи разработчика.
То же касается хостинга, панели сайта, резервных копий и аналитики. У владельца должны быть рабочие учётные записи с нужными правами и понятный способ восстановить доступ. Пароли безопаснее передавать через предназначенный для этого менеджер паролей, а не хранить в одной переписке вместе с остальными материалами проекта.
Если код сайта хранится в репозитории, выясните, кому принадлежит учётная запись или организация, где расположен проект, и какие права есть у заказчика. Для сайта на CMS проверьте административную учётную запись владельца. Для конструктора — владельца проекта и аккаунта, на котором оплачивается сервис.
Проверьте аналитику до запуска рекламы
Войдите в систему аналитики именно под учётной записью компании. Посетите сайт с другого устройства и посмотрите, появляется ли визит. Затем выполните ключевые действия: отправьте форму, нажмите нужную кнопку, перейдите на страницу благодарности, если она предусмотрена проектом.
Цели должны соответствовать действиям, которые компания собирается анализировать. Само наличие счётчика ещё не подтверждает корректный сбор информации. Ошибка в настройке цели может месяцами оставаться незаметной, если никто не проверил её тестовым действием.
Для WordPress полезно заранее сверить техническую часть с руководством по SEO и настройке сайта на WordPress. Здесь важно разделять две задачи: наличие базовых технических настроек и дальнейшее поисковое продвижение. Запуск исправного сайта сам по себе не гарантирует высоких позиций в Google или Яндексе.
Зафиксируйте порядок обновления материалов после запуска
До приёмки должно быть понятно, кто меняет тексты, фотографии, список услуг, контакты и другие материалы. Попросите показать панель управления на тех страницах, которые сотрудники компании будут редактировать сами. Хорошая передача проекта — это не экскурсия по всей CMS, а понятный сценарий для типовых задач бизнеса.
Попробуйте самостоятельно поменять небольшой фрагмент текста, сохранить правку и проверить результат на сайте. Затем верните исходный вариант. Такой тест сразу показывает, хватает ли выданных прав и понятен ли интерфейс сотруднику, который будет работать с сайтом дальше.
Уточните, кто отвечает за технические обновления, резервные копии и восстановление сайта при сбое. Если правки сначала проверяются на тестовой копии, зафиксируйте этот порядок. Если контент публикует подрядчик, согласуйте канал постановки задачи и способ подтвердить появление новой версии на сайте.
Чек-лист приёмки сайта перед запуском
| Что проверить | Как проверить | Нормальный результат |
|---|---|---|
| Мобильная версия | Открыть ключевые страницы на телефоне и пройти основные сценарии | Текст, меню, кнопки и формы читаются и работают без наложений |
| Описание услуг | Попросить человека со стороны пересказать предложение компании | Понятны услуга, адресат и следующий шаг |
| Проверка формы | Отправить корректные и ошибочные значения | Ошибки объясняются рядом с полем, верная заявка отправляется |
| Защита от дублей | Нажать кнопку отправки два раза подряд | Повторное нажатие не создаёт одинаковые обращения |
| Подтверждение | Отправить тестовое обращение | Пользователь видит ясное сообщение о результате |
| Доставка заявки | Открыть CRM, почту или другую целевую систему | Менеджеру пришли нужные поля без потерь и дублей |
| Медленная сеть | Ограничить скорость в инструментах браузера | Интерфейс остаётся понятным, ошибки сети обрабатываются корректно |
| Ссылки и кнопки | Пройти основные маршруты по сайту | Каждая ссылка и кнопка ведёт в ожидаемое место |
| Домен и хостинг | Войти в учётные записи владельца | У компании есть полный контроль и восстановление доступа |
| Аналитика | Открыть счётчик и выполнить тестовые действия | Посещение и нужные события фиксируются |
| Обновление контента | Самостоятельно внести тестовую правку по инструкции | Ответственный сотрудник понимает порядок работы |
Частые вопросы о приёмке сайта
Перед публикацией заказчики нередко уделяют больше внимания внешнему виду, хотя серьёзные проблемы могут скрываться в формах, доступах и передаче обращений. Ниже разберём несколько вопросов, которые полезно закрыть до финальной приёмки.
Нужно ли проверять сайт, если подрядчик уже провёл тестирование?
Да. Подрядчик проверяет продукт со стороны команды, а заказчик принимает бизнес-сценарии и соответствие договорённостям. Вы знаете, куда должна приходить заявка, кто работает с ней дальше и какие материалы сотрудники будут менять после публикации.
Можно ли принять сайт, а мелкие ошибки исправить после запуска?
Замечания можно разделить по приоритету. Ошибки, которые мешают отправить заявку, открыть страницу, прочитать текст с телефона или получить доступ владельцу, лучше закрыть до публичного старта. Косметические правки можно вынести в отдельный список, если стороны согласовали такой порядок.
Как проверить форму без технических знаний?
Пройдите её как клиент: сначала заполните всё корректно, затем намеренно ошибитесь. После успешной отправки откройте систему менеджера и сравните пришедшую информацию с тем, что вводили на сайте. Для базовой приёмки этого подхода хватает, а сложные интеграции разумно принимать вместе с ответственным сотрудником и разработчиком.
Нужно ли проверять каждую форму отдельно?
Да, если на сайте несколько форм. Они могут выглядеть одинаково, но иметь разные настройки отправки, цели аналитики или интеграции. Рабочая форма на главной странице не подтверждает исправность формы на странице другой услуги.
Что должно остаться у владельца после передачи проекта?
Минимальный набор — контроль домена, хостинга, панели управления сайтом и аналитики, а также инструкция по типовым операциям. Если проект хранится в репозитории или связан со сторонними сервисами, права владельца на эти ресурсы тоже нужно проверить по договору и устройству проекта.
Приёмка сайта — это проверка всей цепочки от первого экрана до полученной менеджером заявки и доступа владельца к инфраструктуре. Такой подход помогает найти технические и организационные проблемы до публичного запуска и отделить их от субъективных правок дизайна.
Какая проверка чаще находила у Вас проблемы перед запуском сайта: мобильная версия, форма заявки или доступы?
