Перейти к содержимому
Сайты и сервисы25 сентября 2026 г.
Александр Донских·Основатель и директор Tipa агентства

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

Пошаговая приёмка сайта: страницы, мобильный вид, формы, CRM, SEO, доступы и резервные копии. Как разделить дефекты и новые пожелания.

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

Главное за 30 секунд

Приёмка сайта — не просмотр главной страницы и не вопрос «нравится ли дизайн». Владелец проверяет согласованный результат: посетитель находит нужное, может оставить обращение, менеджер его получает, а компания владеет доступами и способна поддерживать ресурс. Проверку удобно разделить на содержание, пользовательские сценарии, техническое состояние и передачу. Ниже — список действий, которые заказчик может выполнить вместе с подрядчиком без глубоких знаний программирования.

Подготовьте основание для проверки

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

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

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

Проверьте содержание и навигацию

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

Возьмите реальные вопросы покупателей и посмотрите, где сайт на них отвечает. Можно ли понять, кому подходит услуга, что входит, как запросить оценку, когда ждать ответа? Если стоимость зависит от задачи, страница должна объяснить параметры расчёта. Избегайте подмены содержания красивой формой: сильная визуальная подача не компенсирует отсутствующие условия или устаревший телефон.

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

Пройдите путь обращения как обычный клиент

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

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

Если есть CRM, проверьте создание записи и назначение ответственного. Если заявка дублируется в почту или мессенджер, убедитесь, что каналы согласованы и тест не потерялся. Материал об интеграции сайта с CRM поможет сформировать сценарии. Не закрывайте приёмку одной фразой «форма работает», пока менеджер не может открыть контакт и продолжить разговор.

Проверьте мобильный опыт и доступность

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

Пройдите ключевой сценарий клавиатурой: виден ли фокус, можно ли открыть меню и заполнить форму. Проверьте подписи полей, альтернативный текст смысловых изображений и заметность ошибок. Ресурсы W3C WAI предлагают предварительные ручные проверки; автоматический тест выявляет лишь часть проблем. Если сайт рассчитан на широкую аудиторию, доступность влияет на возможность получить услугу, а не только на техническую оценку.

Скорость оценивайте на важной странице и типичном устройстве. Google рассматривает LCP, INP и CLS как показатели загрузки, отзывчивости и стабильности, но единичная лабораторная оценка не равна реальному поведению всех посетителей. Если тяжёлое видео тормозит первый экран или кнопка прыгает при загрузке, запишите конкретное проявление и проверьте исправление после оптимизации.

Проверьте поисковую и техническую основу

Убедитесь, что сайт открывается по HTTPS, а основные страницы возвращают нормальный ответ сервера. У каждой важной страницы должны быть собственные понятные заголовок и описание, один основной адрес и доступный контент. Проверьте robots.txt, sitemap и отсутствие тестового noindex на опубликованных страницах. Наличие этих элементов не гарантирует место в поиске, но их ошибки могут мешать обнаружению.

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

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

Получите доступы и материалы

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

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

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

Сделайте контрольный выпуск и подпишите результат

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

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

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

Отдельно проверьте устойчивость после передачи

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

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

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

Следующий шаг

Если хотите применить схему к своему проекту, согласовать критерии приёмки сайта. Сначала зафиксируем исходные данные и критерии готовности, затем оценим объём работ.

От теории к делу

Посчитайте стоимость под вашу задачу

Стоимость сайта · калькулятор
Ориентир
от 8 млн UZS

Ориентир. Финальная смета — после брифа по задачам.

Обсудим вашу задачу?

Бесплатная диагностика за 24–48 часов: посмотрим ситуацию, скажем что даст результат, дадим смету.

Ташкентский арматурный завод
Кейс по теме
ТАЗ: B2B-сайт каталога трубопроводной арматуры
Смотреть →

Применим на проекте?