Как выбрать CMS для сайта бизнеса: критерии до разработки

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

CMS — система управления контентом сайта. Через неё редактор публикует страницы, меняет тексты и изображения, обновляет товары или статьи. В разговоре её также называют «движком». Но название платформы само по себе ничего не говорит о том, подходит ли она конкретной компании.

Выбор стоит начинать не со списка WordPress, 1С-Битрикс, Tilda или других продуктов. Сначала опишите, что люди и сотрудники должны делать на сайте. Только после этого сравнивайте классы решений и конкретные платформы.

1. Опишите задачи сайта на два-три года

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

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

1. Кто им пользуется?
2. Как часто?
3. Что произойдёт, если функции не будет?

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

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

2. Проверьте работу редактора на реальном сценарии

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

• создать страницу услуги по готовому образцу;
• заменить изображение и подпись;
• опубликовать статью, настроить адрес, Title и Description.

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

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

3. Составьте список обязательных интеграций

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

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

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

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

4. Проверьте SEO-возможности до договора

Для продвижения недостаточно поля «SEO-настройки». На тестовом сайте проверьте, можно ли без программиста:

• задать уникальные Title, Description и H1;
• изменить постоянный адрес страницы и настроить редирект;
• управлять canonical и правилами индексации там, где это нужно;
• создать sitemap.xml и корректный robots.txt;
• добавить внутренние ссылки и описания изображений;
• вывести основной текст в доступном для робота HTML;
• настроить шаблоны для каталога без одинаковых метатегов на сотнях страниц.

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

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

5. Разделите безопасность платформы и качество поддержки

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

До выбора выясните:

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

Для бизнеса важна не абстрактная «надёжность CMS», а понятная ответственность. Имя исполнителя, регламент обновлений и способ восстановления полезнее общего обещания безопасности.

6. Зафиксируйте владение данными и путь выхода

До договора получите ответы на неудобные вопросы:

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

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

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

7. Считайте стоимость владения, а не цену лицензии

Сравните расходы минимум на два года:

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

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

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

Какой тип платформы подходит в разных ситуациях

Облачный конструктор или SaaS-платформа

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

CMS с открытым исходным кодом

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

Коммерческая коробочная CMS

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

Заказная система или фреймворк

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

Headless CMS

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

Практическая матрица выбора

Возьмите два-три варианта и оцените каждый по шкале от 0 до 2:

• 2 — требование выполняется штатно и показано на тестовом сайте;
• 1 — нужна понятная доработка с оценкой и ответственным;
• 0 — функция отсутствует или ответ нельзя проверить.

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

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

Пример: почему нужен запас архитектуры

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

Сайт вырос в многостраничный ресурс и стал поддерживать не только рекламу, но и органический поиск. Этот пример не доказывает превосходство конкретной CMS — платформа в публичном кейсе не названа. Он показывает правильный принцип: вероятный следующий этап нужно учитывать до разработки, иначе рост потребует полной пересборки. Подробности есть в кейсе сайта «Надёжного дома».

Ошибки, которые обходятся дороже лицензии

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

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

Третья — сравнивать только стартовую смету. Поддержка, редактура, обновления и доработки продолжаются после запуска.

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

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

Что зафиксировать в ТЗ

В раздел о CMS добавьте:

1. выбранный класс платформы и причину выбора;
2. обязательные редакторские сценарии;
3. интеграции и состав передаваемых данных;
4. SEO-настройки и правила индексации;
5. роли пользователей и владельцев доступов;
6. обновления, резервное копирование и восстановление;
7. условия лицензий и подписок;
8. состав передачи проекта;
9. правила экспорта и миграции;
10. тесты, по которым принимается результат.

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

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

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