Как правильно принимать сайт?

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

Ниже — структурированное руководство, основанное на многолетнем опыте работы с клиентами с 2010 года.

1. Подписание договора

Хотя этап кажется формальным, он критически важен.

Юридическая значимость

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

Договор для хостингов

Бывают случаи, когда кто-то копирует ваш сайт полностью. Чтобы добиться удаления копии, вам может понадобиться подтверждение, что именно вы являетесь заказчиком разработки — как правило, достаточно отправить копию договора владельцу площадки или хостинг-провайдеру. Это может помочь убрать незаконную копию с хостинга, но удаление страниц из поисковой выдачи — отдельный процесс и не происходит автоматически только из-за такого обращения.

Дополнительное соглашение: детализация функционала

В допсоглашении необходимо максимально подробно описать функционал:

• каждую страницу, блок и модуль;
• назначение функционала;
• дополнительные элементы (например, реферальная программа в личном кабинете).

Чем точнее описание, тем меньше риск, что в финале вы получите не то, что ожидали.

2. Этап дизайна

На этом этапе вы должны получить визуальный макет вашего будущего сайта — в виде изображений.

Формат передачи макетов

Раньше макеты делали в PSD, сегодня стандарт — Figma. Если дизайн и разработка выполняются разными командами, Figma удобнее для всех сторон.

Важность дизайн-концепции

Заказ «сделайте красиво, как посчитаете нужным» обычно приводит к разочарованию. Нужно:

• предоставить примеры сайтов, которые нравятся и не нравятся;
• передать логотип и фирменные цвета;
• указать, есть ли готовый контент;
• пройти бриф, если студия его отправляет.

Порядок согласования

1. Дизайнер отрисовывает главную страницу.
2. Вы вносите правки и утверждаете.
3. Дизайнер создаёт остальные страницы.
4. После их согласования — мобильную версию.

Обязательно требуйте мобильные макеты — это отдельный блок работы.

3. Верстка (frontend)

На данном этапе картинка превращается в код.

Как предоставляют верстку

Варианты:

• тестовый поддомен студии;
• архив с версткой, которую можно открыть локально.

Запросите результат обязательно: некоторые студии сразу переходят к следующему этапу и не показывают чистую верстку.

Проверка верстки

Проверяйте верстку:

• на компьютере;
• на планшете;
• на телефонах разных типов.

Важно протестировать как можно больше устройств и экранов.

Проверка внутренних ошибок

Используйте валидатор W3C. Он позволяет увидеть:

• критические ошибки (fatal errors) — их исправляют в первую очередь;
• ошибки уровня error — желательно исправить;
• предупреждения (warnings) — допустимы и чаще всего не критичны.

Проверять нужно каждую страницу отдельно, а не только главную.

Коллективная проверка

Эффективный подход — создать общий чат, куда отправить ссылку на тестовую верстку. Разные сотрудники проверят сайт на своих устройствах, что позволяет быстрее обнаружить редкие баги.

В нашем блоге есть уже подробная видео-инструкция, как проверять верстку сайта.

4. Программирование и установка на CMS

Верстка интегрируется в CMS (админку), чтобы вы могли управлять сайтом.

Что обсудить с проект-менеджером

Важно заранее определить, какие блоки будут выведены в админку для редактирования.

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

Задавайте себе вопрос: «Буду ли я менять этот контент?»
Если нет — лучше оставить блок статичным.

Передача доступов

После завершения этапа вам должны передать:

• логин/пароль редактора (для работы с контентом);
• позже — администраторские доступы.

К моменту финальной передачи у заказчика должны быть доступы к тем системам, которые используются в проекте:

• домен / аккаунт регистратора;
• хостинг;
• CMS;
• Яндекс Метрика;
• почта или другие сервисы, связанные с формами;
• исходники / репозиторий — если это предусмотрено договором и процессом разработки.

Если используются FTP/SFTP/SSH — доступы также должны быть переданы заказчику или ответственному специалисту. Критически важные аккаунты не должны оставаться только у подрядчика.

5. Тестирование админки

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

Как тестировать

• Если система знакома — проверяйте самостоятельно.
• Если впервые видите — попросите проект-менеджера пройтись по админке в видеозвонке.

Проверьте:

• изменение текста;
• добавление изображений;
• сохранение данных;
• публикацию материалов.

Ранняя загрузка реального контента

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

6. Финальное тестирование на вашем хостинге

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

Что важно учитывать

Оборудование студии и вашего хостинга различается: PHP, ОС, настройки сервера. Из-за этого элементы верстки могут «поехать», даже если на тестовом домене всё было корректно.

Ваша задача — повторно пробежаться по основным страницам и убедиться, что:

• верстка отображается корректно;
• функционал работает как ранее;
• админка доступна;
• есть администраторские доступы.

Исправления, связанные с различиями серверов, студия обычно вносит быстро.

Формы и ключевые сценарии

Недостаточно увидеть, что форма визуально отправилась. Проверьте всю цепочку: форма → успешная отправка → корректные данные → письмо, CRM или другой предусмотренный канал (если CRM или другой внешний сервис используется в проекте) → понятное сообщение пользователю после отправки. Также проверьте кликабельность телефонных номеров, email, основные CTA, меню и кнопки.

Перед запуском проверьте базовые SEO-настройки

• страницы не закрыты случайно через noindex;
• robots.txt не запрещает обход нужных страниц;
• sitemap.xml доступен;
• Title и Description заполнены для основных страниц;
• на странице один основной H1;
• canonical не ведёт на неправильный URL;
• страница 404 действительно отдаёт HTTP 404;
• favicon установлен.

Подробнее — в материале как проверить, открыт ли сайт для индексации.

Проверьте аналитику

Убедитесь, что счётчик Яндекс Метрики установлен на production, визиты фиксируются, а основные цели и события, предусмотренные проектом, действительно срабатывают. Наличие кода счётчика без проверки фиксации действий — недостаточно.

Резервная копия

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

Итоги: шесть обязательных этапов приёмки сайта

1. Договор — внимательно составьте и детализируйте функционал в допсоглашении.
2. Дизайн — активно участвуйте в процессе, предоставьте максимум информации.
3. Верстка — проверяйте на множестве устройств и через валидатор.
4. Программирование — обсудите, какие блоки должны быть редактируемыми, а какие нет.
5. Тестирование админки — убедитесь, что все страницы корректно редактируются.
6. Финальное тестирование на хостинге — проверьте работу сайта уже на вашей платформе.

За качественной разработкой сайта вы всегда можете обратиться в нашу веб-студию. Мы все эти этапы всегда соблюдаем.

Тема в видеоформате