Как выбрать CMS и платформу для интернет-магазина в 2026 году

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

Для проекта с типовым каталогом и простой розничной продажей может быть достаточно готовой облачной платформы. Магазину с несколькими складами, персональными ценами, B2B-кабинетом и сложным обменом с 1С потребуется другой набор возможностей. А в отдельных проектах готовая CMS вообще перестаёт быть центром всей системы.

До сравнения 1С-Битрикс, OpenCart, WooCommerce и других решений стоит описать сам интернет-магазин: откуда приходят товары и цены, как устроены склады, какие интеграции нужны, какая ожидается нагрузка и кто будет сопровождать систему. После этого часть CMS обычно отпадает ещё до подробного сравнения.

CMS, движок и платформа для интернет-магазина — в чём разница

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

Движок — разговорное название программной основы сайта. На практике этим словом часто называют ту же CMS.

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

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

Какие варианты платформ существуют

Большинство решений можно отнести к четырём подходам.

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

Что определить до выбора CMS

Сравнение конкретных продуктов имеет смысл только после того, как описаны основные процессы будущего интернет-магазина.

Какая система отвечает за товары, цены и остатки

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

Главным источником может быть:

• 1С;
• другая учётная система;
• отдельная товарная система;
• сам интернет-магазин.

Например, если цену можно независимо изменить и в 1С, и в CMS, рано или поздно возникает конфликт: какое значение считать правильным? Такая же проблема касается остатков, характеристик, названий товаров и статусов заказов. Для каждого вида данных лучше сразу зафиксировать источник: где создаётся значение, где оно может изменяться и в какую сторону идёт синхронизация.

В проекте Moymir команда Alto разрабатывала интернет-магазин с нуля и встраивала его в существующую инфраструктуру клиента. Источником данных витрины стала внутренняя учётная система: магазин получал из неё номенклатуру, цены и остатки, а обратно передавал оформленные заказы.

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

Для сложных проектов этот вопрос стоит решать ещё при проектировании архитектуры интернет-магазина.

Насколько сложен каталог

Каталог на 50 000 товаров не обязательно сложнее каталога на 5 000. Проблемы часто начинаются не из-за количества карточек, а из-за связей между ними, характеристик, фильтров и правил поиска.

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

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

При разработке интернет-магазина «Бендикс Авто» Alto работала с базой TecDoc примерно на 1 млрд записей. Такой массив данных требовался для подбора деталей практически для любого автомобиля. Поэтому отдельной технической задачей стала логика поиска и подбора комплектующих. При выборе платформы для большого каталога нужно оценивать не только количество товаров, но и то, как пользователь будет искать и сопоставлять их между собой.

Какие правила продаж нужно поддержать

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

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

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

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

Как рассчитывается цена

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

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

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

В проекте Termoland Alto развивает действующий сайт на 1С-Битрикс. Стандартные возможности CMS не позволяли корректно совмещать несколько акций и скидок и управлять их приоритетами. Вместо переноса на другую платформу команда продолжила развивать существующую систему и реализовала необходимую бизнес-логику отдельно. Также Alto создала собственную систему сертификатов и связала её с 1С и Битрикс24.

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

Как магазин работает с несколькими складами

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

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

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

Какие данные и системы нужно связать

Интернет-магазин может обмениваться данными с 1С, CRM, складской и товарной системами, OMS, сервисами оплаты и доставки, онлайн-кассой, маркетплейсами и внутренними сервисами компании.

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

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

1. какие данные передаются;
2. откуда они поступают;
3. куда передаются;
4. как часто идёт обмен;
5. что происходит при ошибке.

Если 1С занимает центральное место в системе продаж, интеграцию лучше рассматривать как отдельную задачу — интеграция сайта с 1С.

Как магазин должен развиваться

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

• новые регионы;
• дополнительные склады;
• B2B-кабинет;
• мобильное приложение;
• несколько витрин;
• новые юридические лица;
• дополнительные каналы продаж;
• программа лояльности.

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

Кто будет сопровождать систему

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

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

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

Как сравнивать платформы между собой

После сбора требований список можно сократить до двух-трёх кандидатов и проверить их по одной матрице.

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

Популярные CMS и платформы для интернет-магазина

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

1С-Битрикс

«1С-Битрикс: Управление сайтом» — коммерческая коробочная CMS. Для интернет-магазинов используются прежде всего редакции «Малый бизнес» и «Бизнес».

В сентябре 2026 года стоимость лицензий составляет:

1. «Малый бизнес» — 47 000 ₽;
2. «Бизнес» — 96 500 ₽.

Платформа содержит готовые механизмы для каталога, заказов, скидок и интеграций и допускает глубокую доработку проекта. Для российского рынка отдельное значение имеет работа с продуктами 1С. При этом наличие штатной функции не означает, что она полностью соответствует конкретному бизнес-процессу. Опыт Termoland показывает, что нестандартная торговая логика может потребовать собственной разработки даже при сохранении 1С-Битрикс в качестве основной CMS.

Платформу стоит оценивать по требованиям проекта, а не считать автоматическим выбором для компании определённого размера. Если 1С-Битрикс подходит по архитектуре и бизнес-процессам проекта, отдельно стоит оценить объём внедрения, интеграций и необходимых доработок. Подробнее об этом — разработка интернет-магазина на 1С-Битрикс.

OpenCart

OpenCart — система интернет-торговли с открытым исходным кодом. Саму CMS можно использовать бесплатно. В базовой системе есть возможности для работы с товарами, клиентами, заказами, налогами, купонами и поисковой оптимизацией.

Функциональность расширяется с помощью модулей и тем. Главное преимущество подхода — отсутствие стоимости лицензии и возможность изменять исходный код.

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

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

WordPress + WooCommerce

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

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

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

CS-Cart

CS-Cart — специализированная платформа для интернет-магазинов с открытым исходным кодом. Российская версия адаптирована для местных служб оплаты и доставки и распространяется по бессрочной лицензии.

В сентябре 2026 года доступны три редакции:

1. CS-Cart Стандарт — 37 900 ₽. В стоимость входят год обновлений и 30 дней стандартной технической поддержки.
2. CS-Cart Бизнес — 87 900 ₽. Дополнительно доступны несколько витрин, работа с несколькими складами, региональная доступность товаров и программный интерфейс административной части.
3. CS-Cart Максимум — 252 900 ₽. Включает возможности редакции «Бизнес», пять лет бесплатных обновлений и три месяца премиальной поддержки.

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

InSales

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

В сентябре 2026 года тариф «Интернет-магазин» стоит 2 295 ₽ в месяц. Первые семь дней платформой можно пользоваться бесплатно. Отдельные функции и интеграции оплачиваются дополнительно. Например, подключение обмена с 1С может потребовать отдельной опции. Для более крупных проектов предусмотрены расширенные тарифы.

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

Shop-Script

Shop-Script — платформа для интернет-магазинов, которую можно использовать в облаке или разместить на собственной инфраструктуре.

В сентябре 2026 года доступны в том числе:

1. бесплатный облачный тариф — 0 ₽ в месяц;
2. тариф «Киоск» — 719 ₽ в месяц.

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

Tempa

Tempa — платформа Alto для интернет-торговли, которая объединяет интернет-магазин, мобильное приложение и ИИ-продавца на одном ядре. Все три канала работают с общей административной панелью и данными каталога, цен, остатков, заказов и клиентов. Это позволяет развивать веб-магазин, мобильный канал и продажи с помощью ИИ в рамках одной платформы, без отдельной административной системы для каждого канала.

В состав Tempa входят:

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

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

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

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

При переходе с другой системы доступны инструменты миграции каталога, клиентов, заказов и медиа. В числе перечисленных источников — 1С-Битрикс, InSales, Tilda, Ecwid, Shopify, OpenCart и самописные решения. Конкретный состав переноса зависит от структуры исходного магазина и его интеграций.

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

Сколько стоит CMS и платформа для интернет-магазина

Цена лицензии или подписки — только часть расходов. Более дешёвая на старте CMS может потребовать дорогих интеграций и доработок. А более высокая стоимость готовой платформы иногда компенсируется меньшим объёмом собственной разработки.

Бесплатная CMS действительно бесплатна?

Бесплатной может быть лицензия, но не весь интернет-магазин.

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

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

Из чего складывается полная стоимость владения

Для сравнения платформ лучше учитывать основные статьи расходов отдельно.

1. Лицензия или подписка. Стоимость самой CMS или облачной платформы.
2. Внедрение. Настройка, верстка, программирование и запуск.
3. Инфраструктура. Серверы, облачные ресурсы и резервное копирование.
4. Интеграции. Обмен с 1С, системой работы с клиентами, складом, оплатой, доставкой и другими сервисами.
5. Модули и расширения. Готовые дополнения и их продление.
6. Сопровождение. Исправление ошибок и контроль работы системы.
7. Обновления. Установка новых версий и адаптация собственных доработок.
8. Развитие. Новые функции, интеграции и изменения бизнес-процессов.

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

Когда готовой CMS достаточно, а когда нужна другая архитектура

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

Когда существующую CMS разумнее развивать

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

В проекте Termoland Alto продолжила развивать существующий проект на 1С-Битрикс. Ограничения стандартной логики скидок решили собственными доработками, не останавливая продажи и не меняя всю платформу.

Другой пример — GURUGROW. Когда проект перешёл к Alto, он был разделён на две кодовые базы с общей базой данных, а документация по архитектуре отсутствовала. Клиентская база превышала 170 000 покупателей. Команда поставила задачу не переписать проект с нуля, а в пределах бюджета стабилизировать его и создать устойчивую основу для развития. После оптимизации скорость мобильных страниц выросла в среднем на 35–40%.

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

Когда оправдана индивидуальная разработка

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

В проекте Moymir Alto разработала решение с нуля и встроила его во внутреннюю инфраструктуру клиента. Интернет-магазину требовались актуальные цены и ассортимент во время прямых эфиров и устойчивая работа при высокой нагрузке.

Ещё один пример — TOLK. Команда Alto создавала платформу с нуля под новую модель электронной торговли. Нужно было реализовать кабинеты продавца и покупателя, витрину, оплату и интеграции с 1С и внутренней системой заказчика. Данные о товарах поступали из внешней системы и дополнительно обогащались перед публикацией. Первая рабочая версия была создана за три месяца.

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

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

Когда стоит рассматривать перенос на другую платформу

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

Но решение о переносе лучше принимать после сравнения двух сценариев:

1. продолжить развитие действующей системы;
2. перенести магазин на другую платформу.

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

Как проверить платформу до начала разработки

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

Например:

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

При проверке нужно ответить на два вопроса: Можно ли реализовать сценарий? Что потребуется для его реализации?

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

Как выбрать CMS: алгоритм из 7 шагов

1. Опишите требования. Зафиксируйте каталог, продажи, цены, склады, пользователей, оплату, доставку и планы развития.
2. Определите источники данных. Решите, где хранятся товары, цены, остатки, клиенты и заказы.
3. Выделите обязательные функции. Отделите критичные требования от возможностей, которые можно добавить позднее.
4. Определите ограничения проекта. Учтите бюджет, сроки и доступную команду.
5. Оставьте две-три подходящие платформы. После описания требований большую часть вариантов можно исключить без подробного тестирования.
6. Проверьте сложные сценарии и стоимость владения. Определите, что работает штатно, где требуется модуль, а где собственная разработка.
7. Сравните варианты и примите решение. Оценивайте не популярность CMS, а соответствие требованиям, стоимость и возможности дальнейшего развития.

Ошибки при выборе CMS

1. Выбирать только по рейтингу. Распространённость платформы полезна, но не доказывает её соответствие конкретному проекту.
2. Смотреть только на стоимость лицензии. Дешёвая CMS после интеграций и доработок может оказаться дороже коммерческой платформы.
3. Не проектировать обмен данными. Недостаточно решить, что сайт «будет связан с 1С». Нужно определить состав и правила обмена.
4. Не учитывать развитие бизнеса. Планируемые склады, регионы или B2B-направление лучше учитывать заранее.
5. Считать все интеграции одинаковыми. Загрузка каталога и полноценная синхронизация данных между несколькими системами требуют разного подхода и объёма разработки.
6. Игнорировать сопровождение. Система должна быть не только разработана, но и поддерживаться после запуска.
7. Покупать чрезмерно сложную платформу «на вырост». Возможность когда-нибудь использовать функцию не означает, что она нужна сейчас.
8. Пытаться решить технический долг только сменой CMS. Если причина проблем в архитектуре и процессах, она может сохраниться и после переноса.

Что в итоге выбрать

После нормального сбора требований выбор редко остаётся между десятками CMS. Обычно можно выделить две-три платформы, которые подходят по архитектуре и стоимости, а затем проверить их на самых сложных сценариях конкретного проекта: каталоге, обмене с 1С, ценах, складах, B2B-логике и других критичных процессах.

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

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