Разработка сайта: от бизнес-задачи до запуска и развития

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

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

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

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

По данным «Рейтинга Рунета», в России и странах СНГ работает не менее 6 299 студий, специализирующихся на веб-разработке. В год они запускают около 27 894 сайтов. Краткий гид «Рейтинга Рунета» по рынку веб-разработки

Российский рынок разработки при этом продолжает расти. По данным исследования Workspace, которые приводит Sostav, в 2025 году обороты студий разработки сайтов увеличились на 26% по сравнению с предыдущим годом. Исследование Workspace на Sostav

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

Сначала определите роль сайта в бизнесе

Фраза «нам нужен новый сайт» описывает намерение, но не задачу. За ней могут стоять разные ситуации: компания выводит новый продукт, хочет получать обращения из поиска и рекламы, объединяет несколько направлений под одним брендом, запускает интернет-продажи или автоматизирует обслуживание действующих клиентов.

У этих проектов разные пользователи, функции и критерии успеха.

Результат сайта нельзя оценивать в отрыве от предложения, цены, рекламы, работы отдела продаж, узнаваемости бренда и ситуации на рынке. Поэтому важно понимать не только показатели сайта, но и место ресурса в общей воронке.

Что определить до обсуждения дизайна

До цвета кнопок, анимации и выбора CMS полезнее ответить на несколько вопросов:

• кто приходит на сайт и в какой ситуации

• что человек уже знает о компании или продукте

• какой вопрос или сомнение мешает ему двигаться дальше

• какое действие должно стать следующим

• что произойдёт после заявки, регистрации или оплаты

• откуда сайт будет получать трафик

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

• кто будет обновлять сайт после запуска

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

Новый сайт, редизайн или доработка

Наличие старого сайта не означает, что его нужно сохранять любой ценой. Но возраст ресурса сам по себе тоже не причина начинать всё с нуля.

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

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

При переходе на новую платформу отдельно сопоставляют старые и новые адреса, сохраняют востребованный контент, настраивают перенаправления и следят за индексацией после запуска. Google рассматривает перенос с изменением URL как отдельный процесс и рекомендует заранее готовить карту соответствий страниц. Рекомендации Google по переносу сайта

Как выбрать формат сайта

Названия вроде «лендинг», «корпоративный сайт» или «интернет-магазин» помогают примерно определить масштаб проекта, но не заменяют проектирование.

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

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

Лендинг, визитка и спецпроект

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

Сайт-визитка решает более простую задачу: подтверждает присутствие компании или специалиста в интернете, показывает основные услуги и контакты.

Спецпроект строится вокруг истории, события, игры, визуального эксперимента или отдельного продукта. Анимация и интерактив здесь оправданы, если помогают раскрыть идею, а не мешают добраться до содержания.

Сайт услуг, каталог и корпоративный сайт

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

Каталог подходит, когда ассортимент нужно изучить и сравнить, но сама покупка требует консультации, расчёта или индивидуального предложения.

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

В проекте для ГК «Стэлл Город» нам нужно было объединить пять разных компаний в единый образ холдинга. Работу начали с глубинного интервью, изучения рынка, аудитории и действующих сайтов. Общая идея затем определила не только дизайн, но и структуру: от образа холдинга к отдельным компаниям и их услугам.

Кейс сайта для ГК «Стэлл Город»

Интернет-магазин

Интернет-магазину нужны каталог, поиск и фильтрация, карточки товаров, корзина, оформление заказа, оплата, доставка, уведомления и обмен данными с учётными системами.

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

По данным АКИТ, объём интернет-торговли в России в 2025 году достиг 11,5 трлн рублей, увеличившись на 28% за год. Доля интернет-торговли в общем объёме розничных продаж выросла до 18,8%. Итоги интернет-торговли АКИТ за 2025 год

Для такого проекта сбой в корзине, оплате, доставке или обмене остатками уже напрямую влияет на продажи.

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

Блог и бренд-медиа

Контентному проекту нужна удобная редакционная система: рубрики, теги, авторы, связанные материалы, поиск и правила публикации.

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

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

Личный кабинет, B2B-портал и онлайн-сервис

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

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

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

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

Что означает разработка сайта под ключ

«Под ключ» — удобное коммерческое определение, но единого состава работ у него нет.

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

Поэтому важнее заранее определить границы проекта:

• какие результаты команда передаёт после каждого этапа

• кто готовит и согласовывает контент

• сколько типов страниц и состояний проектируется

• какие функции и интеграции входят в работу

• кто отвечает за домен, хостинг, лицензии и сторонние сервисы

• что считается готовностью к запуску

• как принимаются работы и согласовываются изменения

• какие исходники, доступы и инструкции получает заказчик

• что входит в гарантию, поддержку и дальнейшее развитие

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

Аналитика и постановка задачи

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

Если сайт уже существует, дополнительно смотрят веб-аналитику, поисковую видимость, техническое состояние и обратную связь от сотрудников.

На этом этапе фиксируют роль сайта, основные сценарии, ограничения и критерии приёмки.

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

Информационная архитектура и прототип

Структура отвечает на два разных вопроса: какие страницы нужны всему сайту и как человек должен двигаться внутри каждой из них.

На этом этапе определяют:

• карту разделов

• навигацию, поиск и фильтры

• основные пользовательские сценарии

• состав типовых страниц

• состояния форм и интерактивных элементов

• модель контента в CMS

• страницы под подтверждённый поисковый спрос

• внутренние ссылки и правила формирования URL

Прототип может быть текстовым, схематичным или кликабельным. Степень детализации зависит от риска.

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

На сайте бизнес-центра К7 мы сделали отдельные страницы для офисов, ретейла и HoReCa, фитнеса и бьюти: разные арендаторы оценивают объект по разным критериям. Позже в готовую систему добавили калькулятор доходности для инвесторов.

Кейс сайта бизнес-центра К7

Контент и текстовый прототип

Тексты лучше готовить до финального дизайна.

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

Работа с контентом включает:

• сбор фактуры у экспертов и сотрудников

• проверку терминов, цифр и утверждений

• разработку логики раскрытия информации

• заголовки, подписи, формы и системные сообщения

• задания на фотографии, видео, иллюстрации и инфографику

• описание повторяемых сущностей

• правила обновления материалов после запуска

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

Сайт получил Special Kudos и награды за UI, UX и инновационность на CSS Design Awards.

Кейс сайта для франшизы SNAX

Визуальная концепция и интерфейс

Дизайн задаёт визуальную иерархию: что человек замечает первым, как понимает главное и где видит следующий шаг.

Для крупных проектов создают UI-kit или дизайн-систему с типографикой, сеткой, кнопками, полями, карточками и другими повторяющимися компонентами.

Адаптивность лучше закладывать сразу, а не превращать мобильную версию в уменьшенную копию десктопа.

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

Разработка и интеграции

Frontend отвечает за отображение и поведение интерфейса, backend — за данные, бизнес-логику, права доступа и взаимодействие с внешними системами.

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

Чем сложнее проект, тем раньше стоит определить:

• где хранится код и кто имеет к нему доступ

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

• с какими внешними системами работает сайт

• что происходит при сбое интеграции

• кто отвечает за инфраструктуру и резервные копии

• как сотрудники будут работать с CMS

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

SEO, аналитика и тестирование

SEO-подготовка начинается не перед публикацией, а ещё при проектировании структуры.

До запуска проверяют URL, метаданные, внутренние ссылки, карту сайта, robots.txt, canonical и перенаправления со старых страниц.

Google отдельно подчёркивает, что соответствие техническим рекомендациям не гарантирует индексацию или позиции — оно прежде всего помогает не создавать препятствий для поисковой системы. Google Search Essentials

План аналитики тоже лучше составить заранее. Нужно понимать, какие действия пользователя связаны с бизнес-задачей и как они будут передаваться в отчёты и CRM.

Яндекс Метрика позволяет отслеживать целевые действия — например, отправку заявки, переход по ссылке, регистрацию или оплату. Документация Яндекс Метрики по целям

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

После публикации основные сценарии проверяют ещё раз уже на рабочем домене.

Как выбрать платформу и способ разработки

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

Спор «конструктор или собственная разработка» без контекста мало полезен. Промостраница с известным сроком жизни, большое медиа и кабинет дилера требуют разных решений.

Какие платформы используются в российском сегменте

Единой платформы, которая доминировала бы во всех типах российских сайтов, нет. По данным W3Techs, на 27 августа 2026 года среди сайтов в доменной зоне .ru с определяемой CMS на WordPress приходится 33,5%, на Tilda — 27,1%, на Bitrix — 16%.

Другой срез даёт CMS Magazine — каталог проектов российских веб-разработчиков. На 25 августа 2026 года в нём указано 39 580 проектов на 1С-Битрикс, 11 834 на WordPress и 6 488 на Tilda Publishing.

Эти цифры нельзя напрямую сравнивать между собой: W3Techs анализирует работающие сайты, а CMS Magazine — проекты, добавленные разработчиками в собственный каталог. Но оба источника показывают, что российский рынок не сводится к одной платформе.

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

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

Поэтому платформу лучше выбирать не по месту в рейтинге, а по требованиям проекта: функциям, интеграциям, способу управления контентом, нагрузке и планам развития.

По каким критериям выбирать платформу

Перед выбором стоит определить:

1. Какой контент будет храниться и кто будет его обновлять

2. Насколько сложны функции и пользовательские роли

3. С какими CRM, ERP, платёжными и другими системами нужен обмен

4. Какие нагрузки и требования к стабильности ожидаются

5. Какая команда будет поддерживать и развивать проект

6. Кому принадлежат данные, код и доступы

7. Какие изменения вероятны в ближайшие годы

Не стоит заранее выбирать самый сложный стек «на вырост». Избыточная архитектура увеличивает сроки разработки, число зависимостей и стоимость каждого изменения.

Опыт Эдс: почему мы переехали с Tilda на Taptop

Собственный сайт Эдс раньше работал на Tilda. По мере развития на нём появлялось всё больше услуг, кейсов и статей, и команде понадобились более гибкая работа с повторяемым контентом и единые компоненты.

Мы перешли на Taptop не потому, что Tilda стала плохим инструментом. Для лендинга или промопроекта с жёстким сроком она по-прежнему может быть рациональным вариантом.

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

Этот опыт подробно разобрали в статье «Сначала на себе: как мы переехали с Tilda на Taptop». Опыт переезда Эдс с Tilda на Taptop

Интеграции, данные и контент

Даже простая форма на сайте обычно связана с почтой, CRM или мессенджером. Интернет-магазин обменивается товарами, остатками и заказами. Личный кабинет может получать данные из ERP и отправлять действия пользователя обратно.

Поэтому фразы «подключить CRM» недостаточно.

Для каждой интеграции нужно определить:

• какие данные передаются

• в каком направлении идёт обмен

• когда он происходит

• какие поля обязательны

• что делать с дублями

• как система ведёт себя при ошибке

• какая система считается основной при расхождениях

• кто отвечает за интеграцию с каждой стороны

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

Формулировка похожая, объём разработки — нет.

Контент, который будет регулярно обновляться

Если на сайте постоянно появляются кейсы, новости, товары, сотрудники или объекты, нужно заранее продумать не только дизайн карточки, но и её устройство в CMS.

Какие поля обязательны? Кто может редактировать и публиковать материал? Как формируются превью и ссылки? Что происходит после удаления записи?

До дизайна полезно провести инвентаризацию:

• что можно перенести со старого сайта

• какие материалы устарели

• какие цифры нужно перепроверить

• есть ли права на изображения, шрифты и видео

• кто предоставляет фотографии и документы

• что обязательно подготовить к запуску

Фраза «контент предоставляет заказчик» сама по себе проблему не решает. В плане должны быть понятны ответственный, формат и срок передачи материалов.

Что должно быть готово к запуску

До публикации сайт проверяют по нескольким направлениям.

Скорость и стабильность

Для оценки скорости используют лабораторные тесты и данные реальных пользователей.

Core Web Vitals дают три основных ориентира: LCP до 2,5 секунды, INP менее 200 миллисекунд и CLS менее 0,1. Google рассматривает их как показатели реального пользовательского опыта. Google — Core Web Vitals

По данным Web Almanac 2025, медианный вес главной страницы составлял 2,86 МБ на десктопе и 2,56 МБ на мобильных устройствах. Больше всего данных в среднем приходилось на изображения, затем на JavaScript и шрифты. HTTP Archive — Web Almanac 2025: Page Weight

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

Яндекс тоже рекомендует отдельно работать со скоростью загрузки, оптимизировать изображения, код, серверную часть и количество запросов. Рекомендации Яндекс Вебмастера по скорости сайта

Поиск перед публикацией

Базовая SEO-подготовка не гарантирует позиции, но помогает не создавать технические препятствия для индексации.

Перед запуском проверяют:

• доступность важных страниц

• постоянные и понятные URL

• title, description и H1

• canonical

• внутренние ссылки

• sitemap и robots.txt

• страницы ошибок и перенаправления

• сохранение поисковых сигналов при переносе сайта

Если старый ресурс уже получает органический трафик, миграцию лучше планировать вместе с SEO-специалистом.

Аналитика

Счётчик ради счётчика мало полезен.

До запуска стоит определить, какие действия действительно связаны с бизнес-результатом: заказ, заявка, регистрация, звонок, оплата или другой значимый этап.

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

Так аналитика отвечает не на вопрос «сколько событий произошло», а помогает понять, где сайт влияет на реальный путь клиента.

Доступность, безопасность и персональные данные

У сайта должны нормально работать контраст, подписи полей, клавиатурная навигация, масштабирование и сообщения об ошибках. Международным ориентиром для веб-доступности служит WCAG 2.2. Стандарт WCAG 2.2

Проблема остаётся распространённой. В исследовании WebAIM Million 2026 автоматическая проверка миллиона главных страниц обнаружила в среднем 56,1 ошибки доступности на страницу, а вероятные нарушения WCAG были найдены на 95,9% исследованных страниц. При этом сам WebAIM подчёркивает: автоматическая проверка видит не все проблемы и не заменяет ручной аудит. WebAIM Million 2026

Требования к безопасности зависят от проекта. Для презентационного сайта и сервиса с личными данными или оплатой нужен разный объём работ.

Для первичной систематизации рисков веб-приложений можно использовать актуальный OWASP Top 10:2025. Он включает проблемы контроля доступа, конфигурации, цепочки поставки ПО, аутентификации и другие распространённые категории рисков. OWASP Top 10:2025

Формы, кабинеты, cookie и системы аналитики могут затрагивать персональные данные. Конкретные юридические и технические требования зависят от того, какие данные собираются и как они обрабатываются, поэтому такую схему нужно отдельно сверять с профильным специалистом.

Что проверить сразу после публикации

После переключения домена стоит ещё раз:

1. Открыть основные страницы с компьютера и телефона

2. Отправить реальные тестовые формы, заказы или регистрации

3. Проверить передачу данных во внешние системы

4. Проверить цели и события аналитики

5. Убедиться, что сняты тестовые ограничения индексации

6. Проверить перенаправления со старых адресов

7. Зафиксировать рабочую резервную копию и доступы

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

От чего зависят сроки и стоимость

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

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

На объём работ влияют:

• степень определённости задачи

• количество типов страниц и состояний

• сложность визуальной концепции

• объём текстов, фото, видео и других материалов

• функции и пользовательские роли

• интеграции

• выбранная технология и инфраструктура

• необходимость сохранить поисковый трафик

• требования к безопасности и производительности

• количество участников согласования

• поддержка после запуска

На сроки влияет не только производительность команды. Если задерживаются тексты, фотографии, доступ к CRM или согласование прототипа, сдвигаются и следующие этапы.

Срочный запуск возможен, если сознательно сократить первую версию: отложить часть функций, использовать готовую платформу или упростить визуальные эффекты.

Сжимать исследование, согласование и тестирование без изменения объёма опаснее: риск не исчезает, а переносится на уже работающий сайт.

Как читать оценку подрядчика

Хорошая смета показывает не только итоговую сумму, но и состав работ, допущения и исключения.

Из неё должно быть понятно:

• сколько типов страниц проектируется

• кто готовит материалы

• какие функции и интеграции учитываются

• что входит в тестирование

• какие результаты получает заказчик

• что находится за границами текущего проекта

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

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

Как заказчику контролировать разработку

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

Что зафиксировать до начала работ

В договоре и документации стоит определить:

• состав работ

• критерии приёмки

• ответственность за материалы и доступы

• сроки и зависимости между этапами

• порядок работы с новыми требованиями

• права на дизайн, код и контент

• принадлежность домена и учётных записей

• правила работы с данными

• гарантийные обязательства

• формат поддержки после запуска

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

Роль представителя заказчика

Проекту нужен человек со стороны заказчика, который может принимать решения.

Если маркетинг, продажи, IT, юристы и руководители отправляют противоречащие друг другу комментарии, подрядчик не может сам определить, какой из них считать главным.

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

Инструмент здесь вторичен: это может быть трекер задач, таблица, документация или комментарии в Figma. Главное — понятный порядок принятия решений.

Что происходит после запуска

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

Дальнейшая работа обычно идёт по четырём направлениям.

Техническое обслуживание

Обновления CMS и модулей, резервные копии, контроль сертификатов и домена, ошибок, производительности и безопасности.

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

Контент и поисковое развитие

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

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

Улучшение пользовательского пути

Веб-аналитика, записи сессий, CRM, обращения клиентов и обратная связь помогают находить места, где пользователь останавливается или ошибается.

Изменения лучше формулировать как гипотезы: что именно нужно изменить и какой эффект ожидается.

Развитие продукта

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

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

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

Как Эдс подходит к разработке сайтов

В Эдс состав проекта определяем по задаче бизнеса, сценарию пользователя и тому, как сайт будет работать после запуска.

Одному проекту достаточно прототипа, дизайна и сборки на подходящей no-code-платформе. Другому нужны исследование, бренд-концепция, тексты, CMS, интеграции и отдельная техническая команда.

Технологию выбираем после того, как понятны структура, функции и порядок обновления сайта, а не наоборот.

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

Посмотреть возможности команды можно в направлении «Сайты».

Конкретные решения — в наших кейсах: от сайта для ГК «Стэлл Город» и бизнес-центра К7 до сайта франшизы SNAX и цифровой платформы для агентства недвижимости «Первоцветы».

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

По этим данным уже можно определить, какое исследование нужно провести, какой формат подходит проекту и что должно войти в разработку.

Что делает сайт рабочим инструментом

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

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

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

Поэтому первый вопрос перед разработкой звучит не «на чём делать сайт?», а:

Что должно измениться для пользователя и бизнеса, когда сайт начнёт работать?

После ответа уже можно выбирать формат, состав работ и технологию.

Источники и материалы

Российский рынок и e-commerce

Рейтинг Рунета — краткий гид по рынку заказной веб-разработки
Sostav / Workspace — исследование российского digital-рынка за 2025 год
АКИТ — итоги интернет-торговли в России за 2025 год

Платформы, технологии и производительность

W3Techs — статистика CMS среди сайтов в доменной зоне .ru
CMS Magazine — каталог CMS и реализованных проектов
HTTP Archive — Web Almanac 2025: Page Weight
Google — Core Web Vitals
Яндекс Вебмастер — рекомендации по скорости сайта

Поиск и аналитика

Google Search Essentials
Google — рекомендации по переносу сайта
Яндекс Метрика — цели и целевые действия

Доступность и безопасность

WebAIM Million 2026
WCAG 2.2
OWASP Top 10:2025