Лендинг / визитка
Одна задача, компактный объём, рекламная посадочная или простое присутствие.
Услуга / веб-бюро Дениса Богданова
Полный цикл создания нового сайта: от задачи бизнеса, исследования спроса и архитектуры до дизайна, реализации, запуска и готовности к дальнейшему развитию.
Услуга для ситуации, когда нужен новый сайт, но правильный формат ещё не определён. Сначала выбираем роль проекта в бизнесе, затем архитектуру и только после этого — реализацию.
01 / роль услуги
«Создание сайта» — не один продукт. Для одной компании рационален лендинг, для другой — корпоративный или B2B-сайт, для третьей — интернет-магазин. Общая услуга нужна, когда исходная задача сформулирована как «нам нужен новый сайт», но формат ещё предстоит выбрать.
Задача бюро — не продать самый большой объём, а определить минимальную достаточную архитектуру, которая решает текущую задачу и не создаёт тупик для будущего роста.
02 / выбор формата
Клиенту важно понимать не только что мы делаем, но и почему ему нужен именно этот формат, а не более простой или более сложный.
Одна задача, компактный объём, рекламная посадочная или простое присутствие.
Несколько направлений, доверие, кейсы, команда, контент и долгосрочное развитие.
Сложный продукт, длинный цикл сделки, несколько ролей и глубокая доказательная структура.
Каталог товаров, поиск, фильтры, заказ, оплата, доставка и товарная логика.
03 / применимость
Не предлагаем услугу по умолчанию. Сначала проверяем, соответствует ли она реальной задаче и текущему состоянию проекта.
04 / состав работ
Состав не собирается из абстрактного прайса. Каждый блок включается потому, что решает конкретную часть задачи.
Сопоставляем задачи, аудитории, спрос, контент и функциональность и выбираем подходящий тип сайта.
Проектируем разделы, типы страниц, навигацию, сущности и путь пользователя.
Фиксируем содержание и логику ключевых страниц до дизайна.
Создаём визуальную основу, которая выдерживает не только стартовые страницы, но и развитие.
Реализуем функциональность, модели контента и управление сайтом.
Проверяем техническое качество, формы, аналитику, индексацию и ключевые сценарии.
05 / процесс
Этапы уменьшают риск дорогих переделок: сначала принимаем решения, затем оформляем и реализуем их.
Определяем роль сайта, приоритеты бизнеса, аудитории и ограничения.
Принимаем решение: компактная посадочная, корпоративный, B2B, магазин или иной сценарий.
Проектируем страницы, сущности, URL и развитие проекта.
Последовательно фиксируем смысл и визуальную систему.
Реализуем согласованный объём, CMS, формы и интеграции.
Тестируем ключевые сценарии и переводим проект в production.
Добавляем контент, SEO, новые страницы и улучшения по приоритету.
06 / результат
Результат описываем через конкретные артефакты и рабочие части системы, а не через обещания позиций или абстрактный «рост».
Понимание, почему бизнесу нужен именно такой тип сайта и где его границы.
Карта страниц, сущностей и пользовательских маршрутов.
Production-версия в согласованном объёме, а не только дизайн-макеты.
CMS и модели данных для тех сущностей, которые должны регулярно обновляться.
Адаптив, производительность, метаданные, индексируемость и другие базовые требования.
Понимание, что развивать после запуска и в какой последовательности.
07 / связанные контуры
Эти части не добавляются декоративно. Показываем их роль только там, где они действительно влияют на результат.
Если поиск важен, семантика, интенты и структура входят в проектирование до разработки.
Ключевые действия и источники должны быть измеримы после запуска.
Формы, CRM, уведомления и внешние сервисы подключаются по реальной бизнес-потребности.
Для замены действующего сайта отдельно планируется перенос URL, контента и поискового потенциала.
08 / оценка проекта
Не ставим искусственную универсальную цену там, где объём определяется архитектурой, контентом и интеграциями. Сначала фиксируем состав — затем считаем.
Одностраничный проект, корпоративная система и интернет-магазин имеют принципиально разный объём.
Уникальные типы страниц и интерфейсные сценарии важнее простого подсчёта URL.
Тексты, фото, кейсы, каталог и другие материалы могут быть отдельной существенной частью проекта.
Интеграции, расчёты, кабинеты, каталог и нестандартная логика влияют на оценку разработки и тестирования.
09 / границы и риски
Заранее проговариваем типовые ошибки и ограничения, чтобы клиент понимал не только преимущества, но и условия хорошего результата.
Фреймворк или CMS не определяют роль сайта. Сначала нужна модель задачи, затем технология.
Чужая структура отражает чужой продукт, бизнес-процесс и историю SEO и не является готовым ТЗ.
Если органический поиск важен, позднее подключение часто приводит к переделке структуры и URL.
Большая архитектура может запускаться поэтапно, если границы и зависимости определены заранее.
После основного этапа
10 / альтернативы
Страница должна помогать выбрать правильный путь, а не удерживать клиента внутри одного продукта.
Если сайт уже существует и сначала нужно понять, действительно ли новый проект необходим.
Смотреть аудит ↗Если текущий фундамент пригоден и рациональнее улучшать существующий проект.
Смотреть развитие ↗Если сайт уже соответствует продукту, а задача находится прежде всего в поисковой видимости.
Смотреть SEO ↗11 / связанные решения
Не обязательно собирать проект из отдельных услуг самостоятельно. Решения объединяют их вокруг бизнес-ситуации.
Когда бизнесу нужен не просто новый дизайн, а сайт, в котором заранее связаны спрос, структура, SEO, GEO, контент, аналитика и дальнейшее развитие.
06Для компаний, где ассортимент, технические характеристики, отрасли применения и поисковый спрос должны складываться в понятную архитектуру, а не в бесконечный список карточек.
12 / вопросы до старта
Если вашего вопроса здесь нет, его лучше вынести в разбор до оценки проекта, а не выяснять после старта.
Смотрим на количество самостоятельных продуктов, аудитории, способ покупки, роль поиска и необходимые функции. Формат является следствием этих параметров, а не предпочтения подрядчика.
Сначала задача и структура. Дизайн работает лучше, когда уже понятно, какую информацию он должен организовать и какие сценарии поддерживать.
Состав проекта может включать исследование, архитектуру, прототипы, дизайн, разработку, CMS, формы, аналитику и запуск. Точный объём фиксируется под задачу, чтобы не включать ненужные работы.
Да, если проект заменяет существующий сайт, домен обычно сохраняется. При этом отдельно планируется миграция URL и контента, чтобы снизить поисковые риски.
Нет. Достаточно описать бизнес-задачу, продукт и ограничения. Технические требования формируются после проектирования, когда понятна архитектура решения.
Технология выбирается по требованиям к функциональности, управлению контентом, интеграциям, производительности и поддержке. Она не должна определять архитектуру раньше бизнес-задачи.
Сначала определяется тип сайта, число уникальных шаблонов, контент и функциональность. После этого можно дать содержательную оценку бюджета и сроков вместо условной стартовой цифры.
Сайт развивается: добавляются страницы и материалы, улучшаются сценарии, наращивается SEO/GEO и корректируются приоритеты по данным аналитики.
Следующий шаг
Опишите бизнес-контекст, текущий сайт и то, что хотите изменить. На первичном разборе определим, подходит ли эта услуга, нужна ли другая или разумнее начать с более узкого шага.
Разобрать сайт / задачу