Выбор платформы для корпоративного сайта чаще всего сводится к спору о названиях: WordPress или 1С-Битрикс, готовая CMS или своё решение. Спор этот бесполезен, пока не сформулированы задачи. Одна и та же система оказывается удачным выбором для сайта на двадцать страниц и провальным для сайта с каталогом и обменом данными с учётной системой. Ниже разбираем варианты и порядок, в котором мы подходим к решению на проектах.
Начинаем с задач, а не с названий CMS
До того как обсуждать платформы, мы собираем ответы на несколько вопросов. Без них сравнение превращается в перечисление возможностей, которыми никто не воспользуется.
- Что сайт должен делать. Рассказывать о компании, продавать, принимать заявки, вести личные кабинеты клиентов, показывать каталог с остатками — это разные проекты.
- Кто и как часто наполняет сайт. Один маркетолог раз в месяц или отдел, публикующий новости каждый день.
- С чем нужно связать сайт. Учётная система, CRM, склад, платёжный сервис, система заявок.
- Какой объём содержимого. Тридцать страниц или каталог на несколько тысяч позиций с фильтрами.
- Кто будет поддерживать. Штатный разработчик, подрядчик или никто конкретно — от этого зависит, насколько распространённой должна быть платформа.
- Какие требования к данным. Персональные данные, размещение на серверах в России, разграничение доступа сотрудников.
Четыре типа решений
Все доступные варианты укладываются в четыре группы, и различаются они не столько возможностями, сколько тем, кто отвечает за развитие сайта.
Конструкторы
Сайт собирается в браузере из готовых блоков, хостинг и обновления берёт на себя сервис. Порог входа низкий, запуск быстрый. Ограничения проявляются позже: нетиповая логика не реализуется, доступ к коду ограничен, а перенос содержимого на другую платформу требует ручной работы. Для сайта-визитки или временной промостраницы это разумный выбор, для развивающегося корпоративного сайта — обычно тупик.
Готовые CMS общего назначения
WordPress, Drupal, MODX и подобные системы устанавливаются на свой сервер, код доступен, расширения ставятся модулями. Сильная сторона — распространённость: специалистов найти легко, готовых решений много. Слабая — качество этих готовых решений. Сайт, собранный из десятка сторонних плагинов, тяжёл и уязвим, а после обновления ядра часть модулей перестаёт работать.
Коммерческие CMS, ориентированные на бизнес-процессы
1С-Битрикс и близкие продукты изначально рассчитаны на каталоги, обмен с учётными системами и разграничение прав. Лицензия платная, требования к серверу выше, но многое из того, что в других системах пришлось бы дописывать, здесь есть из коробки — в первую очередь обмен с 1С. Для торговой или производственной компании это часто самый короткий путь.
Headless CMS и самописные решения
В headless-подходе система управления хранит содержимое и отдаёт его через API, а внешний вид собирает отдельное приложение. Это даёт свободу в интерфейсе и возможность использовать одни данные в сайте и мобильном приложении. Цена — две части системы вместо одной и более дорогая поддержка. Полностью самописное решение оправдано там, где сайт по сути является сервисом со своей логикой, и типовая CMS начинает мешать.
Сравнение типов платформ
| Тип решения | Когда подходит | Сильные стороны | Ограничения |
|---|---|---|---|
| Конструктор | Визитка, промостраница, проверка гипотезы | Быстрый запуск, хостинг и обновления на стороне сервиса | Нетиповая логика недоступна, сложный переезд, зависимость от тарифов |
| CMS общего назначения | Корпоративный сайт с новостями, услугами, небольшим каталогом | Много специалистов и готовых модулей, код открыт | Качество плагинов разное, обновления требуют внимания |
| Коммерческая CMS для бизнес-процессов | Каталог, обмен с учётной системой, права доступа | Обмен с 1С и торговый функционал из коробки | Стоимость лицензии и продлений, более высокие требования к серверу |
| Headless CMS плюс отдельный фронтенд | Сайт и приложение на одних данных, нестандартный интерфейс | Свобода в интерфейсе, переиспользование содержимого | Две системы вместо одной, дороже в разработке и поддержке |
| Самописное решение | Сайт-сервис со своей логикой, которой нет в готовых системах | Ровно нужный функционал, без лишнего | Всё, включая админку, делается и поддерживается вами |
Редакторская работа
Платформу выбирают разработчики, а живут с ней редакторы. Мы всегда показываем заказчику админку до начала работ и просим сотрудника, который будет вести сайт, выполнить в ней пару типовых действий: добавить новость с изображением, поправить текст на странице услуги, поменять порядок блоков.
На что смотрим при этом:
- Сколько шагов занимает публикация обычной страницы.
- Видит ли редактор результат до публикации.
- Можно ли собрать страницу из блоков, не обращаясь к разработчику.
- Что произойдёт, если вставить текст из редактора документов вместе с оформлением.
- Есть ли разграничение прав, если сайт ведут несколько человек.
- Сохраняется ли история изменений и можно ли вернуть прежнюю версию страницы.
Если наполнение неудобно, сайт перестают обновлять через несколько месяцев, и вложения в него обесцениваются при любой платформе.
Интеграции с 1С и CRM
Интеграции — та часть проекта, где различия между платформами видны сильнее всего. Мы разбираем их до выбора системы: переделывать обмен данными на живом сайте дорого.
- Учётная система. Что передаётся в сайт: номенклатура, цены, остатки, изображения. Что уходит обратно: заказы, заявки, данные клиентов.
- Направление и частота обмена. Раз в сутки по расписанию или в момент изменения. От этого зависит нагрузка и требования к серверу.
- CRM. Куда попадают заявки с форм, какие поля обязательны, что делать с повторными обращениями.
- Платежи и доставка. Есть ли готовые модули под используемые сервисы или их придётся писать.
- Аналитика. Передача событий и электронной торговли.
Отдельно проверяем, что происходит при сбое обмена: сайт должен показывать последние корректные данные, а не пустой каталог.
Безопасность, обновления и поддержка
Корпоративный сайт — это работающая система, которая требует внимания после запуска. Распространённые платформы регулярно выпускают обновления безопасности, и их нужно ставить: массовые взломы почти всегда происходят на сайтах со старыми версиями ядра и модулей.
Минимальный набор, который мы закладываем в любой проект независимо от платформы:
- Регулярное обновление ядра и модулей с предварительной проверкой на тестовой копии.
- Резервное копирование файлов и базы данных с проверенным восстановлением.
- Разграничение доступов: у редактора не должно быть прав администратора.
- Отдельная тестовая площадка, на которой проверяются изменения.
- Мониторинг доступности сайта и срока действия сертификата.
Чем больше сторонних модулей в проекте, тем дороже обслуживание. Это довод против того, чтобы ставить расширение ради одной небольшой возможности.
Стоимость владения и зависимость от платформы
Сравнивать платформы по стоимости запуска некорректно: заметная часть расходов приходится на последующие годы. В расчёт мы включаем лицензии и их продление, хостинг с учётом требований выбранной системы, регулярное обслуживание и обновления, доработки по мере роста сайта, а также обучение сотрудников.
Отдельно оцениваем зависимость от платформы — насколько тяжело будет уйти. Признаки высокой зависимости: содержимое хранится в закрытом формате, выгрузка неполная, оформление намертво связано с данными, а логика работы вынесена в интерфейс сервиса, а не в код. Чем сильнее эта связь, тем дороже обойдётся смена решения через несколько лет, а корпоративные сайты живут долго.
Отдельный вопрос — что будет за сайтом. Если корпоративный сайт должен показывать данные из учёта (заказы, статусы, документы), выбор платформы вторичен: сначала проектируют информационные системы для бизнеса, а потом решают, какая CMS станет их витриной.
Если готовая платформа под задачу не подходит, остаётся вариант собственной разработки — сайты и информационные системы под задачи бизнеса.
Порядок, в котором мы принимаем решение
- Собираем сценарии: что делает посетитель, что делает редактор, что делает система.
- Фиксируем интеграции и объём содержимого.
- Отсекаем варианты, которые не закрывают обязательные требования.
- Сравниваем оставшиеся по стоимости владения на горизонте нескольких лет, а не по цене запуска.
- Проверяем доступность специалистов: кто будет поддерживать сайт, если подрядчик сменится.
- Показываем админку будущим редакторам и слушаем их замечания.
- Договариваемся, как содержимое будет выгружаться, если платформу придётся менять.
Такой порядок редко приводит к экзотическим решениям, и это нормально. Корпоративному сайту важнее предсказуемость: понятная система, доступные специалисты, прозрачные расходы на поддержку.
Если вы выбираете платформу для нового сайта или сомневаетесь в текущей, мы разберём задачи и предложим вариант с обоснованием, а не по привычке. Разработку корпоративного сайта ведём от структуры и сценариев до запуска и передачи редакторам. Напишите нам — обсудим ваш проект.
