Как проходит разработка сайта
Разработка сайта начинается с бизнес-задачи, а не с дизайна или выбора технологии. Команда определяет, для кого создаётся продукт, какое действие должен совершить пользователь и какие процессы необходимо связать. Затем последовательно проверяет структуру, интерфейс, техническую реализацию и готовность к реальному трафику.
Этапы образуют общую последовательность, но не строгий конвейер. Контент можно готовить параллельно с прототипом, frontend — с частью backend, а интеграции лучше проверять до завершения интерфейса. Если на тестировании обнаруживается проблема в исходной логике, проект возвращается к требованиям или дизайну.
| Этап | Результат | Что проверяем |
|---|---|---|
| Аналитика | Цели и требования | Решает ли сайт нужную бизнес-задачу |
| Прототип | Структура и сценарии | Может ли посетитель найти нужное и выполнить действие |
| UI/UX | Макеты и компоненты | Понятность, адаптивность и состояния интерфейса |
| Frontend | Работающий интерфейс | Устройства, браузеры, контент и скорость |
| Backend | Серверная логика и управление данными | Роли, формы, каталог, поиск и бизнес-правила |
| Интеграции | Обмен с внешними системами | Полнота данных, ошибки, дубли и повторные запросы |
| Тестирование | Подтверждённые сценарии | Функциональность, доступность и безопасность |
| Запуск | Сайт на основном домене | Формы, аналитика, индексация и мониторинг |
Что происходит до разработки
До первой строки кода нужно определить задачу сайта и приоритетное целевое действие. Для корпоративного ресурса это может быть квалифицированная заявка, для магазина — оплаченный заказ, для SaaS-платформы — регистрация и выполнение ключевого сценария.
Команда изучает продукт, аудиторию, текущие процессы продаж, старый сайт и ограничения проекта. Одновременно определяется формат решения: лендинг, многостраничный корпоративный сайт, каталог, интернет-магазин или веб-сервис. Выбирать CMS или фреймворк до понимания функций обычно преждевременно. Подробнее о возможных форматах можно прочитать в материалах WebSolux о веб-разработке.
Со стороны заказчика нужен человек, который собирает обратную связь внутри компании и принимает итоговые решения. Также полезно заранее определить ответственных за тексты, фотографии, юридические материалы, доступы и интеграции.
Что выявляется на старте: попытка обратиться сразу к нескольким несвязанным аудиториям, отсутствие приоритетного действия, неверный формат сайта или задача, которую правильнее решать интеграцией и автоматизацией процесса.
Аналитика и требования
На этапе аналитики идея превращается в согласованный состав проекта. Команда проводит интервью, изучает конкурентов, обращения клиентов и данные существующего сайта. Для сложных продуктов описывает роли пользователей, бизнес-правила, источники данных, интеграции и нестандартные ситуации.
Требования необязательно оформлять как многостраничное техническое задание. Для небольшого сайта достаточно структуры, прототипа, списка функций и критериев приёмки. Для сервиса с личными кабинетами потребуются сценарии, роли, статусы, правила доступа и более подробная спецификация.
Результатом становятся карта страниц, перечень функций, пользовательские сценарии, список интеграций, границы первой версии и предварительный график. Отдельно фиксируется, что не входит в проект. Это помогает отличать ошибку реализации от нового требования: ошибка означает несоответствие согласованному поведению, а новое требование меняет саму утверждённую логику.
На этом этапе часто обнаруживаются конфликтующие пожелания отделов, забытые роли, недоступные API, необязательные для первой версии функции и отсутствие ответственного за контент. Для backend-проекта здесь же оценивается подход к управлению данными и выбирается подходящая архитектура, а не просто популярная технология.
Прототипирование
Карта сайта отвечает на вопрос, какие страницы существуют. Прототип показывает, что находится на этих страницах, в каком порядке посетитель получает информацию и как переходит к целевому действию. Дизайн отвечает уже за визуальное воплощение этой логики.
Прототип может быть статичным или кликабельным. Его детализация зависит от сложности продукта: для компактного лендинга иногда достаточно схемы блоков, а личный кабинет с несколькими ролями лучше проверять через интерактивные переходы.
Полезно использовать реальный или близкий к реальному контент. Идеальный короткий текст скрывает проблемы, которые появятся после загрузки настоящих названий товаров, характеристик и фотографий.
Что проверяем: видит ли пользователь ключевое предложение, понимает ли следующий шаг, хватает ли полей в форме или фильтре, не слишком ли длинный путь до заявки и отвечает ли страница на вопросы клиента, а не только рассказывает о компании.
UI/UX-дизайн
UI/UX-дизайн — это не только цвета и эффектный первый экран. Дизайнер создаёт визуальное направление, типографику, сетку, компоненты и правила их поведения. Проектируются desktop- и мобильные макеты, навигация, формы, таблицы, модальные окна и другие элементы.
Для интерактивных продуктов нужны состояния загрузки, ошибки, успеха, недоступного действия и пустого списка. Без них макет описывает только идеальный сценарий, а разработчикам приходится самостоятельно принимать продуктовые решения.
Мобильная версия проектируется на этом же этапе, а не получается механическим сжатием desktop-макета. Проверяются размер элементов управления, порядок блоков, навигация, длинные значения и ввод данных с экранной клавиатуры.
После утверждения разработчики получают макеты, компоненты, графические материалы и описание поведения интерфейса. Это снижает расхождение между дизайном и готовым продуктом. Подробнее о подходе WebSolux к UI/UX-дизайну и прототипированию можно узнать в разделе услуг.
Техническая веб-разработка
После согласования логики и дизайна проект превращается в работающий продукт. Frontend, backend и интеграции решают разные задачи и могут частично разрабатываться параллельно.
Frontend
Frontend — интерфейс, с которым взаимодействует пользователь. Разработчик реализует страницы и компоненты, адаптивность, формы, клиентскую валидацию, анимации, фильтры и состояния загрузки. Одновременно оптимизируются изображения, шрифты и сценарии, влияющие на скорость.
Здесь выясняется, выдерживает ли макет реальный контент, не перекрываются ли кнопки на мобильном устройстве, можно ли пользоваться функциями без наведения мыши и не вызывают ли изображения заметные сдвиги страницы.
Для оценки пользовательского опыта применяются Core Web Vitals. Актуальные ориентиры Google: LCP до 2,5 секунды, INP до 200 миллисекунд и CLS до 0,1 на 75-м перцентиле посещений. Лабораторная проверка до релиза помогает находить проблемы, но после запуска её дополняют полевыми данными реальных пользователей.
Backend
Backend отвечает за серверную логику, хранение и обработку данных. Он нужен, если сайт управляет каталогом, заказами, поиском, личными кабинетами, ролями, оплатой или нестандартными бизнес-процессами. Сюда же относится административная панель или CMS, через которую сотрудники обновляют контент.
Команда проверяет права доступа, пограничные значения, повторные запросы и соответствие логики реальной работе компании. Например, пользователь одной роли не должен видеть чужие данные, повторная отправка не должна создавать дубль заказа, а редактору не следует обращаться к разработчику ради замены обычного текста.
Интеграции
Интеграции связывают сайт с CRM, 1С, платёжными системами, доставкой, почтой, мессенджерами и внешними API. Для работы нужны документация, тестовые доступы и данные, максимально похожие на реальные.
Риск возникает не только при полном отказе внешнего сервиса. Поля сайта могут не совпадать с CRM, заявка — потерять источник, а один товар — иметь разные идентификаторы в нескольких системах. Поэтому заранее определяются сопоставление данных, обработка дублей, журналирование ошибок и поведение при временной недоступности API.
Например, в проектах WebSolux есть виджет с единой картой пунктов выдачи СДЭК, Почты России и Яндекс Доставки. Для такого продукта недостаточно вывести карту: требуется привести ответы разных сервисов к единому формату и предусмотреть состояния, когда один из источников недоступен.
Тестирование перед запуском
Тестирование начинается по мере готовности модулей, а не в последний день проекта. Проверяется не только соответствие макету, но и весь путь данных: от действия пользователя до письма, CRM, базы или платёжной системы.
- Пользовательские сценарии: поиск, заявка, регистрация, заказ и другие целевые действия.
- Формы и интеграции: доставка данных, письма, CRM, защита от повторной отправки.
- Устройства и браузеры: адаптивность, клавиатура, сенсорное управление и реальный контент.
- Контент: ссылки, изображения, контакты, сообщения об ошибках и юридические страницы.
- Техническое качество: скорость, коды ответа, базовая доступность и права доступа.
- Аналитика: корректная фиксация успешных действий, а не только нажатий на кнопки.
Найденные дефекты фиксируются с условиями воспроизведения, ожидаемым и фактическим результатом. Если форма показывает успешную отправку, но заявка не дошла, это ошибка. Если после согласования заказчик решает добавить новый маршрут заявки, это изменение требований.
Глубина проверки безопасности зависит от рисков. Информационный сайт и сервис с авторизацией, оплатой и персональными данными требуют разного объёма работ. Абсолютную безопасность обещать нельзя: корректно говорить о выполненных проверках и устранённых уязвимостях.
SEO-подготовка сайта
SEO рекомендуется подключать на этапе формирования структуры, до утверждения прототипа, если органический поиск важен для проекта. Поисковый спрос может влиять на структуру, набор страниц, навигацию и URL. Если заниматься оптимизацией только перед релизом, иногда приходится переделывать уже утверждённую архитектуру.
Во время разработки предусматриваются редактируемые title и description, иерархия заголовков, текстовые области, сканируемые ссылки и canonical. Для каталогов отдельно определяются правила индексирования фильтров, пагинации и дублей. Структурированные данные добавляются только там, где они соответствуют содержанию страницы; они не гарантируют расширенный результат в выдаче.
Перед запуском проверяются robots.txt, случайные директивы noindex, sitemap, коды ответа, мобильное отображение и доступность CSS и JavaScript для поисковых роботов. Сайт подключается к Google Search Console и Яндекс Вебмастеру.
Sitemap помогает поисковой системе обнаружить актуальные URL, но не гарантирует сканирование или индексацию. robots.txt управляет сканированием и не считается надёжным способом удалить страницу из индекса.
Одновременно настраиваются Метрика или другая система аналитики и бизнес-цели. После тестовой заявки нужно убедиться, что событие записалось именно при успешной отправке, а данные действительно пришли получателю.
Запуск сайта
Запуск — отдельный управляемый этап. До публикации сайт обычно размещается на закрытом staging-стенде, где команда и заказчик проверяют его без доступа обычных посетителей и поисковых роботов.
- Создать резервную копию и подготовить план отката.
- Настроить production-среду, домен и HTTPS.
- Перенести конфигурацию и рабочие ключи сервисов.
- Проверить формы и интеграции на основном домене.
- Настроить аналитику и протестировать цели.
- Снять ненужные запреты индексирования.
- Проверить canonical, sitemap и коды ответа.
- Просмотреть серверные логи и ошибки после публикации.
Типичные релизные проблемы: production использует тестовые ключи, заявки уходят разработчику, canonical указывает на staging, а открытый для посетителей сайт остаётся закрытым от индексации. Поэтому после публикации команда должна оставаться на связи и повторно пройти ключевые сценарии.
Если новый сайт заменяет старый, составляется карта прежних и новых URL. Настраиваются редиректы, обновляются внутренние ссылки, canonical и sitemap. Google рекомендует сохранять редиректы при переезде как можно дольше — обычно не менее года.
Заказчику передаются предусмотренные проектом доступы: к домену, серверу, CMS, репозиторию, аналитике и интеграциям. Владение критичными активами не должно зависеть от личного аккаунта отдельного исполнителя.
Поддержка и развитие после запуска
Публикация завершает создание первой версии, но не жизненный цикл сайта. После релиза команда отслеживает ошибки, реальные заявки, скорость, индексацию и работу внешних сервисов. Выполняются резервное копирование, обновление зависимостей и технические доработки.
Гарантийное исправление и развитие — разные виды работ. Если реализованное поведение не соответствует согласованному результату, устраняется дефект. Если бизнес хочет добавить функцию, изменить процесс или подключить новую систему, это развитие продукта с отдельной оценкой.
В процессе работы WebSolux после запуска предусмотрен один месяц бесплатной поддержки. Далее можно продолжить поддержку и развитие сайта: улучшать конверсию, расширять контент, подключать интеграции и развивать функциональность на основе данных.
Сколько времени занимают этапы
Срок зависит не столько от количества страниц, сколько от числа уникальных сценариев, готовности контента, сложности backend и внешних интеграций. Лендинг, магазин с синхронизацией остатков и многопользовательская платформа несопоставимы по объёму.
| Этап | Ориентир в WebSolux |
|---|---|
| Брифинг | 1–2 дня |
| ТЗ и смета | 2–3 дня |
| Дизайн | 3–5 дней |
| Разработка | 7–14 дней |
| Запуск | 1–2 дня |
Эти значения нельзя механически сложить и применить к любому сайту. Некоторые работы пересекаются, а согласования, передача материалов и изменение требований влияют на календарный срок. Для сложных платформ потребуется другой план. Подробнее о факторах бюджета можно прочитать в блоге WebSolux.
Организация процесса в WebSolux
Проект ведёт персональный менеджер. В процесс входят ежедневная связь в Telegram, еженедельные отчёты и доступ к репозиторию. Конкретный набор документов, макетов и проверок зависит от продукта, а изменение согласованного состава работ требует отдельной оценки.
Содержание этапов различается в зависимости от проекта. Для магазина GONKA Shop с каталогом более 15 000 позиций важны архитектура данных, поиск и обновление информации. В платформе beauty-чемпионатов — роли участников, судей и спонсоров. В калькуляторе технического обслуживания BMW — формализация расчётной логики и взаимодействие интерфейса с backend. Корпоративные сайты сильнее зависят от структуры, контента и доверительных элементов. Другие примеры представлены в портфолио WebSolux.
Частые вопросы
С чего начинается разработка сайта?
С формулирования бизнес-задачи: кто придёт на сайт, что должен понять и какое действие совершить. Затем команда фиксирует структуру, функции, интеграции и ограничения. Выбор цвета, CMS или фреймворка происходит после понимания задачи.
Кто нужен в команде?
Обычно участвуют менеджер или аналитик, UI/UX-дизайнер, frontend- и backend-разработчики, тестировщик. При необходимости подключаются SEO-специалист, редактор, DevOps-инженер и специалист по интеграциям. В небольшом проекте роли могут совмещаться.
Когда подключается SEO?
Рекомендуется на этапе формирования структуры, чтобы учесть поисковый спрос при проектировании URL и страниц. Технические требования реализуются во время разработки, перед релизом проводится проверка, а после него — контроль индексации и развитие контента.
Сколько занимает запуск?
Сам технический релиз в WebSolux занимает ориентировочно 1–2 дня. Общая продолжительность зависит от аналитики, дизайна, функций и интеграций. Запуск лендинга и многопользовательского сервиса требует разной подготовки.
Можно ли выполнять этапы параллельно?
Да. Контент может готовиться вместе с дизайном, frontend — параллельно с частью backend. Параллельная работа ускоряет проект, если требования и архитектура уже согласованы.
Что требуется от заказчика?
Описание продукта и аудитории, данные старого сайта, фирменные материалы, тексты, фотографии, контакты и юридическая информация. Для интеграций нужны доступы, документация API и тестовые данные. Также необходимо назначить ответственных за материалы и согласование.
От идеи к работающему продукту
Хороший процесс не усложняет веб-разработку, а последовательно снижает риски. Сначала проверяется бизнес-логика, затем структура, интерфейс, код и готовность к реальному трафику. Чем раньше обнаружена проблема, тем меньше уже выполненных работ она затронет.
Планируете новый сайт или переработку действующего? Расскажите WebSolux о задаче — команда поможет определить формат, состав этапов и реалистичный план запуска.
