Как заказать корпоративный сайт: структура, CMS и приёмка

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

Базовый корпоративный сайт в публичном прайсе Za IT стоит 19 999 ₽. В пакет входят до десяти типовых страниц, CMS, формы, контакты, аналитика и базовая поисковая подготовка. Кабинеты, нестандартные калькуляторы, сложные каталоги и интеграции оцениваются отдельно после описания сценария.

Короткий план заказа

1. Определить цели и аудитории.
2. Составить карту страниц и действий.
3. Зафиксировать CMS, формы и интеграции.
4. Назначить ответственных за контент и приёмку.
5. Утвердить прототип до визуального дизайна.
6. Проверять проект по критериям, а не «нравится/не нравится».
7. Перед запуском получить доступы, резервный план и инструкцию.

Когда нужен именно корпоративный сайт

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

• Проверить спрос на одну услугу. Для такой задачи подойдёт лендинг.
• Представить компанию и несколько направлений. Для такой задачи подойдёт корпоративный сайт.
• Показать ассортимент без онлайн-заказа. Для такой задачи подойдёт сайт-каталог.
• Дать корзину и оформление покупки. Для такой задачи подойдёт интернет-магазин.
• Обслуживать авторизованных клиентов. Для такой задачи подойдёт web-приложение или кабинет.

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

Структура: от вопросов клиента, а не от отделов компании

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

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

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

Что записать в ТЗ

Рабочее ТЗ не обязано быть сотней страниц. Оно должно снять спорные трактовки.

Пользовательские сценарии

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

Список страниц и шаблонов

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

Состояния интерфейса

Форма имеет состояния загрузки, успеха, ошибки и валидации. Каталог — пустую выдачу и отсутствие изображения. Меню — desktop и mobile. Если состояния не названы, они всё равно появятся, но решение будет принято в последний момент.

Нефункциональные требования

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

CMS: что должен уметь редактор

CMS выбирают по редакционным операциям. Составьте список того, что команда будет менять сама:

• заголовки, описания и изображения страниц;
• статьи и FAQ;
• кейсы, теги и порядок карточек;
• SEO title, description и OG-поля;
• контакты и служебные данные, если они действительно должны быть динамическими.

Не всё стоит переносить в CMS. Цены и продуктовые правила, которые изменяются через тесты и релизный процесс, иногда безопаснее держать в коде. И наоборот, статьи не должны требовать деплоя. Граница определяется частотой изменения и риском ошибки.

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

Интеграции

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

1. источник истины;
2. событие запуска;
3. формат данных;
4. авторизацию и владельца аккаунта;
5. повтор при ошибке;
6. журнал и способ диагностики;
7. тестовый сценарий приёмки.

То же относится к почте, Telegram, телефонии, картам, платёжным сервисам и аналитике. Успешный ответ API ещё не означает, что менеджер получил заявку — нужно проверить весь путь.

Контент: кто и когда его готовит

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

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

Этапы проекта

Диагностика и структура

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

Прототип

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

Визуальный дизайн

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

Разработка и CMS

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

Наполнение и QA

Загружается реальный контент, проверяются ссылки, формы, canonical, sitemap, JSON-LD, аналитика, скорость, консоль и оба основных viewport.

Запуск

Настраиваются домен, SSL, production env, резервные копии и мониторинг. После запуска выполняется smoke test публичных URL и критического пути заявки.

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

Приёмка должна быть воспроизводимой. Подготовьте таблицу «критерий — способ проверки — результат».

• каждый согласованный URL отдаёт 200 и имеет self-canonical;
• title и description уникальны;
• формы валидируют данные, показывают результат и доставляют уведомление;
• события аналитики фиксируют начало и отправку заявки;
• меню и CTA работают на desktop и mobile;
• CMS позволяет выполнить согласованные редакционные операции;
• изображения имеют alt и корректный MIME;
• sitemap содержит новые страницы;
• нет ошибок консоли и битых внутренних ссылок;
• переданы репозиторий, домен, хостинг, аналитика и инструкции.

Скриншот красивой главной не закрывает эти пункты.

Кейсы и метрики без выдумок

Кейс должен связывать контекст, задачу, решение и проверяемый результат. Если нет подтверждённой выручки или конверсии, лучше описать технический эффект и бизнес-сценарий без случайных процентов. Например, в кейсе hotelarazny показана связка сайта отеля, TravelLine, аналитики и продвижения, а не абстрактный «рост в несколько раз».

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

Цена и границы базового пакета

Базовая конфигурация корпоративного сайта Za IT стоит 19 999 ₽ и рассчитана на проект до десяти типовых страниц. В смете отдельно фиксируют контент, лицензии, кабинеты, многоуровневые каталоги, нестандартные интеграции и миграцию данных. Так заказчик заранее видит границу между пакетом и дополнительными работами.

Если задача не помещается в пакет, команда сначала проводит оценку. Разовые инженерные работы имеют публичный ориентир 2 999 ₽/час, но крупную подсистему лучше считать по результату и критериям, а не по неопределённому количеству часов.

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

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

Для проекта со сложным продуктовым контуром посмотрите кейс RocketRush. Следующий материал — как выбрать сайт для бизнеса.