На чём делать сайт: сравнение CMS, конструкторов и собственной разработки для бизнеса

Один из самых популярных вопросов перед разработкой сайта звучит так:

Какая CMS лучше?

WordPress?

1С-Битрикс?

Tilda?

OpenCart?

Drupal?

А может вообще не использовать CMS и написать всё на Laravel?

Проблема в том, что вопрос сформулирован примерно как:

Что лучше — велосипед, легковой автомобиль или грузовик?

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

С платформами происходит ровно то же самое.

Небольшой сайт электрика, корпоративный сайт на 300 страниц, интернет-магазин на тысячу товаров, B2B-каталог с 1С и SaaS-сервис с личным кабинетом можно одинаково назвать «сайтом». Но технически это четыре совершенно разных системы.

Поэтому выбирать CMS по рейтингу популярности почти бессмысленно.

Ещё хуже выбирать её по принципу:

Наш разработчик всегда работает на этой системе.

Удобство разработчика важно. Но сайт создаётся всё-таки для бизнеса.

Правильный вопрос звучит иначе:

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

Именно поэтому в этой статье не будет победителя с медалью «лучшая CMS 2026 года».

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

Для начала перестанем называть всё CMS

В бытовом разговоре WordPress, Tilda, Shopify и Laravel часто складывают в одну коробку:

движки для сайта.

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

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

Классическая CMS

Примеры:

• WordPress;
• Drupal;
• MODX;
• 1С-Битрикс.

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

Обычно сама система размещается на выбранной вами инфраструктуре.

Это означает:

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

Но одновременно нужно заниматься:

• обновлениями;
• серверной средой;
• backup;
• безопасностью;
• совместимостью компонентов.

Конструктор / hosted SaaS

Самый очевидный пример — Tilda.

Вы не устанавливаете CMS на свой VPS.

Платформа предоставляет:

• редактор;
• hosting;
• CDN;
• часть аналитики;
• формы;
• магазин;
• техническую инфраструктуру.

Это снимает с бизнеса большой объём инженерной работы.

Но архитектура сайта живёт внутри правил платформы.

Commerce SaaS

Shopify похож по принципу на SaaS, но специализируется именно на электронной коммерции.

Вы получаете не просто визуальный редактор, а:

• product management;
• checkout;
• orders;
• payment infrastructure;
• apps;
• multichannel commerce.

Headless CMS

Например, Strapi.

CMS хранит контент и отдаёт его через API.

Frontend живёт отдельно.

Условно:

Strapi
   ↓ API
Next.js
   ↓
website

И тот же контент одновременно может использовать:

mobile app
digital screen
partner API

Strapi Community в 2026 году остаётся open-source продуктом под MIT License с REST и GraphQL API. Платные CMS-возможности Growth сейчас начинаются с $45 в месяц, а Strapi Cloud тарифицируется отдельно: Starter от $35 за проект в месяц.

Framework

Laravel — вообще не CMS.

Это framework для разработки web application.

Laravel 13 предоставляет разработчику архитектурную основу: dependency injection, database abstraction, queues, scheduled jobs, tests и другие инструменты. Но страницу «Услуги», удобный визуальный редактор или управление карточками товаров framework сам по себе вам не создаёт.

Если совсем упростить:

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

Свободы больше.

Но и построить нужно больше.

Сначала задача, потом WordPress

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

Официальный WordPress описывает платформу не только как blogging CMS: на ней работают простые сайты, сложные порталы, enterprise-проекты и приложения. WordPress позволяет изменять код, использовать собственные типы контента и работать через REST API.

Для бизнеса это даёт важные преимущества:

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

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

Не потому, что WordPress «лучше всех».

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

Когда WordPress особенно логичен

Возьмём компанию, которая оказывает 30 услуг.

Нужны:

• отдельные страницы услуг;
• статьи;
• сотрудники;
• кейсы;
• отзывы;
• формы;
• SEO-посадочные;
• несколько редакторов.

Здесь WordPress чувствует себя совершенно естественно.

Можно создать:

service
article
portfolio
review
employee

как отдельные content types и связать их между собой.

Редактор работает с контентом.

Разработчик — с шаблонами и данными.

SEO-специалист — со структурой.

И нет необходимости проектировать административную систему с нуля.

Где у WordPress начинаются проблемы

Не существует технической точки:

после 300 страниц WordPress ломается.

Проблема обычно начинается в другом месте.

Сайт становится сложным, а архитектура растёт не системно, а слоями:

WordPress
+ builder
+ WooCommerce
+ membership plugin
+ booking plugin
+ 42 других plugins
+ 200 строк functions.php
+ custom AJAX
+ неизвестный snippets plugin

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

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

И тогда вопрос уже звучит не:

умеет ли WordPress это сделать?

Вероятно, умеет.

Вопрос:

будет ли такое решение поддерживаемым через три года?

Именно поэтому я почти всегда сначала проектирую структуру данных и бизнес-логику, а потом выбираю plugins, а не собираю архитектуру методом поиска:

«WordPress plugin для…»

Мой практический процесс разработки таких проектов подробнее показан в статье о практическом workflow сборки WordPress-сайта с нейросетями.

WooCommerce: магазин на WordPress не заканчивается на тысяче товаров

Один из самых устойчивых мифов:

WooCommerce подходит для маленького магазина максимум на тысячу товаров.

Универсального технического порога нет.

Сама WooCommerce в документации по масштабированию приводит примеры магазинов с 100 000+ товаров и тысячами транзакций в минуту, подчёркивая, что масштабирование зависит от traffic pattern, hosting и инженерной оптимизации.

Это не значит:

WooCommerce спокойно выдержит всё на дешёвом hosting.

Как раз наоборот.

Большой магазин требует другой дисциплины:

• нормального сервера;
• cache;
• оптимизированной базы;
• контроля extensions;
• staging;
• version control;
• мониторинга;
• нагрузочного тестирования.

Поэтому число товаров само по себе плохо выбирает CMS.

Магазин с 100 000 редко меняющимися товарами может быть технически проще, чем магазин с 5 000 товарами, где одновременно есть:

• пять складов;
• персональные цены;
• сложные фильтры;
• bundles;
• программа лояльности;
• heavy checkout;
• realtime-синхронизация.

1С-Битрикс: дорогая CMS, которая иногда действительно оправдана

В российском интернете 1С-Битрикс часто обсуждают двумя крайностями.

Первая:

профессиональный бизнес должен быть только на Битриксе.

Вторая:

Битрикс — дорогой динозавр, который вообще никому не нужен.

Обе позиции слишком эмоциональны.

На 15 октября 2026 года официальные лицензии «1С-Битрикс: Управление сайтом» стоят:

Редакция	Цена
Старт	7 100 ₽
Стандарт	20 500 ₽
Малый бизнес	47 000 ₽
Бизнес	96 500 ₽
Энтерпрайз	от 1 950 000 ₽

Цены актуальны на момент проверки.

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

То есть сравнивать:

WordPress — бесплатно, Битрикс — 96 500 ₽

недостаточно.

Нужно смотреть весь TCO:

• разработку;
• hosting;
• поддержку;
• специалистов;
• integrations;
• лицензии;
• обновления.

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

Где у 1С-Битрикс есть реальное преимущество

Самый очевидный сценарий — российский e-commerce, тесно связанный с 1С.

У «1С-Битрикс» есть штатный механизм интеграции с 1С, использующий CommerceML. Официальная документация описывает обмен каталогом, номенклатурой и изменениями между системами.

Это серьёзный аргумент, если:

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

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

Но из этого не следует:

есть 1С — обязательно нужен Битрикс.

WooCommerce, OpenCart и custom system тоже можно интегрировать с 1С.

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

Когда Битрикс выглядит избыточно

Допустим, нам нужен сайт электрика:

• 15 страниц;
• цены;
• контакты;
• форма;
• блог.

Можно купить даже недорогую редакцию Битрикса.

Технически всё будет работать.

Но появляется вопрос:

что конкретно бизнес получил благодаря этой платформе такого, чего не получил бы более простой системой?

Если ответа нет, мощность платформы превращается в лишнюю эксплуатационную сложность.

Функция, которой бизнес не пользуется, тоже имеет стоимость.

Хотя бы в обучении и сопровождении.

Tilda: уже давно не только лендинг

Другой устаревший стереотип:

Tilda — только красивые одностраничники.

На октябрь 2026 года это уже технически неправильно.

Официальные российские тарифы Tilda при годовой оплате:

• Personal — 500 ₽/месяц;
• Business — 1000 ₽/месяц.

Personal поддерживает каталог до 5 000 товаров, Business — до 50 000 товаров. У Business также есть экспорт исходного кода.

Это уже вполне серьёзный набор возможностей.

Tilda умеет:

• многостраничные сайты;
• формы;
• Zero Block;
• каталоги;
• корзину;
• payment integrations;
• webhooks;
• SEO-настройки;
• собственный HTML-код;
• CRM;
• members.

Поэтому говорить:

больше ста товаров — нужна другая CMS

слишком примитивно.

Правильный вопрос:

насколько сложен процесс работы с этими товарами?

Где Tilda особенно хороша

Представим компанию, которой нужно:

• быстро запустить сайт;
• самостоятельно менять посадочные страницы;
• не заниматься hosting;
• не обновлять PHP;
• не обслуживать CMS;
• иногда запускать новые marketing pages.

Вот здесь hosted platform может быть очень рациональной.

Особенно если сайта касается маркетолог, а не штатный разработчик.

В TCO исчезает большая часть инфраструктурной работы:

• сервер;
• core updates;
• database administration;
• большая часть security maintenance.

Бизнес платит подписку и работает внутри системы.

Это существенное преимущество.

Где Tilda начинает ограничивать

Цена удобства — границы платформы.

Пока сайт развивается в рамках возможностей Tilda, это практически незаметно.

Но представим, что через два года бизнесу нужен:

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

Начинается борьба с платформой.

Можно подключать:

• JavaScript;
• external APIs;
• custom code.

Но в какой-то момент появляется вопрос:

мы всё ещё используем конструктор или уже строим приложение вокруг конструктора?

Это нормальная граница SaaS.

Экспорт из Tilda: можно, но не всего

Здесь особенно важно не использовать два противоположных мифа.

Первый:

из Tilda вообще нельзя переехать.

Не так.

На Business доступен экспорт кода.

Второй:

нажал Export — и получил полностью независимый сайт со всей логикой.

Тоже не так.

Официальная документация Tilda прямо указывает ограничения: Tilda CRM, Tilda Members и Product Catalog не экспортируются. Для форм и некоторых других сервисов после экспорта тоже сохраняются отдельные условия использования Tilda.

То есть статическая часть сайта переносима значительно лучше, чем SaaS-функции.

Именно поэтому переносимость платформы нужно оценивать не вопросом:

есть Export или нет?

А тремя отдельными вопросами:

1. Можно ли экспортировать контент?
2. Можно ли экспортировать код?
3. Можно ли воспроизвести бизнес-функции вне платформы?

Это три разные вещи.

Shopify: сильный e-commerce SaaS, но не универсальный вариант для России

Если смотреть на мировой e-commerce, игнорировать Shopify было бы странно.

Это одна из крупнейших hosted commerce platforms.

На октябрь 2026 года годовые тарифы Shopify составляют:

• Basic — $29/месяц;
• Grow — $79;
• Advanced — $299;
• Plus — от $2 300 в месяц.

За эти деньги бизнес получает:

• managed hosting;
• commerce backend;
• checkout;
• product management;
• themes;
• app ecosystem;
• international commerce tools.

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

Но для бизнеса, зарегистрированного в России, есть принципиальная оговорка.

В актуальном официальном списке стран Shopify Payments Россия отсутствует. Shopify указывает, что если страна не находится в списке поддерживаемых, нужно использовать стороннего payment provider.

Это не означает:

Shopify невозможно использовать.

Это означает:

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

В частности:

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

Для российского магазина эти вопросы могут оказаться важнее удобства самого интерфейса Shopify.

OpenCart: когда сайт почти целиком магазин

OpenCart занимает интересную нишу.

В отличие от WordPress, который изначально является универсальной контентной платформой, OpenCart строится вокруг e-commerce.

OpenCart официально остаётся open-source решением без обязательной ежемесячной платы за core и заявляет marketplace с более чем 13 000 modules and themes.

Это делает OpenCart рациональным кандидатом, если главная сущность сайта:

товар → корзина → заказ.

То есть бизнесу не нужно превращать обычную CMS в магазин.

Магазин уже является базовой моделью.

Где OpenCart хорош

Например:

• каталог;
• товары;
• категории;
• customer accounts;
• заказы;
• payment;
• delivery.

Интернет-магазин живёт естественно внутри структуры платформы.

Где WordPress может оказаться удобнее

Если кроме магазина важны:

• большой editorial-раздел;
• SEO-content;
• сложные landing pages;
• экспертный блог;
• нестандартные content types.

WooCommerce наследует очень мощную контентную сторону WordPress.

Поэтому выбор между OpenCart и WooCommerce зачастую не о том:

какой магазин лучше?

А о том:

магазин является всем сайтом или только частью большой контентной системы?

MODX: нишевый — не значит мёртвый

MODX часто вспоминают как платформу из прошлой эпохи.

Но актуальная документация MODX 3 обновлялась буквально 10–11 октября 2026 года, текущая линия — Revolution 3.x, а roadmap содержит дальнейшие версии 3.3 и 4.0.

Для актуальных MODX 3.2+ требуется PHP 8.1+.

То есть называть MODX заброшенной системой фактически неправильно.

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

Это может быть удобно для индивидуальных корпоративных проектов.

Но есть бизнесовый недостаток, который для владельца сайта важнее философии CMS:

рынок разработчиков меньше, чем у WordPress.

А значит, поиск нового специалиста может быть сложнее.

Это уже напрямую влияет на стоимость владения.

Технология может быть прекрасной.

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

Drupal: когда структура контента действительно сложная

Drupal тоже часто получает несправедливое описание:

тяжёлая CMS из прошлого.

В январе 2026 года вышел Drupal CMS 2.0 — отдельный продукт поверх Drupal Core с новым visual building experience.

В июле 2026 года Drupal 11.4 получил очередные серьёзные performance improvements: официальный release announcement говорит о значительном сокращении количества database/cache lookups и улучшениях работы с JS/CSS.

То есть платформа активно развивается.

Где Drupal особенно логичен

Представим не сайт электрика, а большую организацию.

У неё:

• много типов контента;
• разные роли редакторов;
• moderation workflow;
• multilingual;
• несколько подразделений;
• разные права публикации;
• API;
• большие структурированные данные.

Вот здесь сильная content model и permission system Drupal становятся реальным преимуществом.

Почему Drupal не нужен каждому бизнесу

Потому что дополнительная гибкость имеет цену.

Требуется:

• expertise;
• разработка;
• сопровождение;
• более серьёзное проектирование.

Для сайта:

Главная
Услуги
О компании
Контакты
15 статей

эта мощность может просто не окупиться.

Снова возвращаемся к главному принципу:

инструмент должен быть сопоставим с задачей.

Laravel: когда сайт стал приложением

Теперь рассмотрим другой проект.

Компания приходит и говорит:

Нам нужен корпоративный сайт с личным кабинетом.

Начинаем уточнять.

В кабинете:

• пять типов пользователей;
• договоры;
• загрузка документов;
• расчёты;
• история операций;
• approval workflow;
• billing;
• уведомления;
• API с внутренней системой;
• персональные тарифы;
• роли сотрудников.

Это уже не просто сайт с личным кабинетом.

Это web application.

На таком этапе выбирать технологию вопросом:

какой WordPress plugin делает личные кабинеты?

может быть не лучшей отправной точкой.

Laravel как full-stack или API framework предназначен именно для построения приложений и предоставляет developer-level инструменты для database, queues, jobs, tests и backend architecture.

Главное преимущество:

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

Главный недостаток:

почти всё приходится проектировать.

В WordPress пользователь, редактор, media library и publishing workflow уже существуют.

В custom application даже хороший административный интерфейс — отдельная задача разработки.

Поэтому свобода Laravel стоит дорого не из-за лицензии framework.

Laravel open source.

Дорого стоит объём инженерной работы.

Headless CMS: когда один контент нужен нескольким интерфейсам

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

Этот контент нужно показывать:

• на сайте;
• в мобильном приложении;
• в терминалах;
• в партнёрском API.

Вот здесь headless architecture выглядит естественно.

Например:

                  → website
Strapi → API      → mobile app
                  → client portal
                  → partner integration

Редакторы работают в одной CMS.

Frontend-команды развивают разные приложения независимо.

Это реальная архитектурная причина использовать headless.

Когда headless становится техническим туризмом

Компания услуг.

30 страниц.

Блог.

Форма.

SEO.

Можно построить:

Strapi
↓
GraphQL
↓
Next.js
↓
Node deployment
↓
CDN

Всё будет современно.

Вопрос только:

зачем?

Если ответ:

сейчас все так делают,

это довольно дорогая техническая стратегия.

Дополнительная система означает:

• отдельный frontend;
• API;
• deployment;
• несколько update cycles;
• разработчиков с другим профилем.

Headless хорош не потому, что новее.

Он хорош, когда разделение backend и frontend решает конкретную проблему бизнеса.

SEO: какая CMS лучше продвигается

Это один из моих любимых вопросов.

Иногда его формулируют так:

Google больше любит WordPress или Битрикс?

Ни то, ни другое.

Поисковая система в итоге получает документы, ссылки, HTTP-ответы, structured data и ресурсы.

Она не начисляет дополнительные баллы за логотип CMS в админке.

Поэтому вместо таблицы:

CMS	SEO
WordPress	10
Битрикс	8
Tilda	7

полезнее проверить реальные технические возможности.

Можно ли:

• редактировать Title;
• редактировать Description;
• делать понятные URL;
• управлять canonical;
• управлять robots;
• создавать Sitemap;
• делать redirects;
• добавлять Schema.org;
• управлять pagination;
• контролировать filters;
• строить internal linking;
• получать правильные HTTP statuses;
• оптимизировать изображения;
• контролировать performance.

Если платформа позволяет это реализовать без постоянной борьбы, её можно нормально продвигать.

Здесь важнее цена реализации SEO-архитектуры, а не название CMS.

Tilda и SEO

Tilda предоставляет стандартные SEO-настройки, мета-теги, H1–H6, ALT и другие базовые инструменты; они включены в сравнение официальных тарифов.

Для обычного сайта услуг этого часто достаточно.

Но сложная архитектура:

• огромные taxonomy;
• нестандартная pagination;
• dynamic SEO landing generation;
• сложные filters;

может потребовать возможностей, которых удобнее добиться на self-hosted CMS или custom architecture.

WordPress и SEO

WordPress особенно удобен не потому, что Google его предпочитает.

А потому что разработчик получает доступ:

• к routing;
• templates;
• HTTP;
• database;
• hooks;
• custom content;
• plugins.

То есть поисковую архитектуру можно достаточно глубоко менять.

Это свобода реализации.

Не ranking factor.

Производительность тоже нельзя оценить названием CMS

Ещё один бесполезный рейтинг:

Tilda — быстрая
WordPress — медленный
Laravel — быстрый

Реальная модель скорее такая:

performance = platform + implementation + infrastructure + content + third-party code + traffic

WordPress на аккуратной кастомной теме с нормальным cache может работать прекрасно.

WordPress с тяжёлым builder, десятками plugins и плохим hosting может работать ужасно.

Custom Laravel с плохими database queries тоже способен тормозить.

SaaS снимает часть infrastructure responsibility, но не отменяет:

• тяжёлые изображения;
• сторонние scripts;
• marketing pixels;
• сложную страницу.

Поэтому CMS задаёт технические условия.

Но не определяет конечный Core Web Vitals одной цифрой.

Безопасность: WordPress не «дырявый» по определению, а коммерческая CMS не бессмертна

Безопасность тоже редко живёт в одной CMS.

Она складывается из:

• updates;
• extensions;
• passwords;
• hosting;
• server configuration;
• custom code;
• file permissions;
• backup;
• access control.

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

Коммерческая CMS, которую пять лет не обновляли, — нет.

SaaS в этом отношении переносит значительную часть infrastructure security на платформу.

Это реальное преимущество.

Но аккаунт пользователя и бизнес-процессы всё равно остаются ответственностью бизнеса.

Большая сравнительная таблица

Ниже не рейтинг.

Оценки означают типичный сценарий, а не физический предел платформы.

Критерий	Tilda	WordPress / Woo	1С-Битрикс	OpenCart	MODX	Drupal	Shopify	Laravel/custom
Быстрый запуск простого сайта	сильная сторона	сильный	нормальный	слабый вне магазина	нормальный	избыточен	нормальный для магазина	слабый
Контент / блог	хороший	очень сильный	хороший	средний	сильный	очень сильный	средний	нужно строить
Интернет-магазин	малый/средний сценарий	сильный	очень сильный	очень сильный	требует решения	требует commerce stack	основное назначение	полностью custom
Интеграция с 1С	есть сценарии интеграции	через решения/API	сильная native ecosystem	через модули/custom	custom	custom	зависит от middleware	полностью custom
SEO-контроль	хороший для стандартных задач	очень высокий	высокий	высокий	высокий	высокий	высокий в рамках SaaS	максимальный
Собственная бизнес-логика	ограниченно	высокая, пока архитектура разумна	высокая	commerce-oriented	высокая	высокая	зависит от platform/apps	максимальная
Hosting freedom	нет	да	да	да	да	да	нет	да
Контроль исходного runtime	ограничен SaaS	высокий	высокий в рамках лицензии	высокий	высокий	высокий	ограничен SaaS	максимальный
Простота эксплуатации	высокая	зависит от проекта	требует сопровождения	требует сопровождения	требует специалиста	требует expertise	высокая	низкая без команды
Рынок разработчиков	большой в своём сегменте	очень большой	большой в РФ	средний	уже	уже	большой глобально	очень большой
Vendor lock-in	SaaS	низкий/средний	средний	низкий/средний	низкий	низкий	SaaS	зависит от custom architecture
Начальная инженерная свобода	средняя	высокая	высокая	средняя	высокая	высокая	средняя	максимальная

Слово «максимальная» в последнем столбце не означает «лучше».

Максимальная свобода означает максимальную ответственность.

Пять бизнесов — пять разных shortlist

Теперь возьмём реальные сценарии.

Сценарий №1. Электрик или небольшой сайт услуг

Нужно:

• 15–50 страниц;
• услуги;
• цены;
• контакты;
• формы;
• блог.

Что я бы рассматривал первым

Tilda или WordPress.

Tilda

Подходит, если:

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

WordPress

Подходит, если:

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

Нужен ли здесь Laravel

Можно.

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

Вопрос не в возможности.

Вопрос в рациональности.

Сценарий №2. Корпоративный сайт компании

Представим:

• 200 страниц;
• услуги;
• отрасли;
• сотрудники;
• проекты;
• вакансии;
• статьи;
• несколько редакторов.

WordPress

Часто мой первый кандидат.

Потому что сильный контентный сценарий хорошо совпадает с моделью WordPress.

1С-Битрикс

Может быть логичнее, если организация уже глубоко использует ecosystem:

• 1С;
• Bitrix;
• корпоративные процессы.

Drupal

Очень интересен, когда появляются:

• сложные роли;
• workflows;
• multilingual;
• большое количество structured content.

Tilda

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

Само слово «корпоративный» технологию не выбирает.

Сценарий №3. Интернет-магазин на 100–1000 товаров

Здесь уже невозможно честно выбрать одного победителя.

WooCommerce

Силен там, где магазин тесно связан с:

• контентом;
• SEO;
• landing pages;
• editorial.

OpenCart

Рационален, когда проект прежде всего является магазином.

1С-Битрикс

Особенно интересен при сильной зависимости от:

• 1С;
• склада;
• товарного обмена;
• сложной российской retail infrastructure.

Tilda

Да, для 100–1000 товаров она технически вполне может подходить.

Но сначала нужно проверить:

• filters;
• variants;
• warehouse logic;
• pricing;
• order processing;
• integrations.

Не размер каталога выбирает систему.

Сценарий №4. Большой каталог / e-commerce

Допустим:

• 300 000 SKU;
• несколько складов;
• B2B;
• персональные цены;
• ERP;
• сложные feeds;
• high load.

Здесь разумный shortlist уже может включать:

• 1С-Битрикс;
• хорошо спроектированный WooCommerce;
• специализированную e-commerce архитектуру;
• headless commerce;
• custom application.

Но даже здесь нельзя поставить правило:

300 000 товаров → Битрикс.

Потому что важно, что происходит с этими товарами.

300 000 простых read-only позиций и 30 000 товаров с realtime-stock, customer-specific pricing и configurator — разные нагрузки.

Сценарий №5. Сервис с личным кабинетом

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

• расчёты;
• workflow;
• кабинеты;
• документы;
• billing;
• permissions;
• transactions;

я бы вообще перестал начинать обсуждение с CMS.

Здесь ядро системы может быть на Laravel или другом application framework.

WordPress при этом вполне способен остаться рядом:

vagizov-example.ru
→ marketing site / WordPress

app.vagizov-example.ru
→ application / Laravel

Это не поражение WordPress.

Это нормальное разделение ответственности.

Количество товаров — плохой способ выбирать CMS

Это стоит повторить отдельно.

Две компании говорят:

у нас 10 000 товаров.

У первой:

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

У второй:

• 20 складов;
• персональные prices;
• B2B;
• bundles;
• остатки realtime;
• разные валюты;
• несколько типов доставки.

Количество SKU одинаковое.

Сложность отличается кратно.

Поэтому техническое задание должно описывать не:

товаров — 10 000.

А:

как эти товары живут.

Если такой информации пока нет, сначала полезно нормально описать требования. Например, я разбирал этот процесс в статье Как написать ТЗ на сайт через ChatGPT.

Сколько стоят платформы

Теперь можно вернуться к деньгам.

Но сравнивать только лицензию бессмысленно.

WordPress

Core — open source.

Лицензия:

0 ₽

Но появляются:

• hosting;
• development;
• paid plugins;
• support.

Tilda

На октябрь 2026 года:

• Personal — 500 ₽/мес при оплате за год;
• Business — 1000 ₽/мес.

Business включает до пяти сайтов и экспорт кода.

1С-Битрикс

Основные редакции:

7 100–96 500 ₽, Enterprise — от 1,95 млн ₽.

Обновления после первого года — отдельное продление.

OpenCart

Core — open source, обязательной ежемесячной платы нет.

MODX

Open-source CMS; основные расходы лежат в разработке, hosting и сопровождении.

Drupal

Open source.

Цена — разработка и expertise.

Shopify

От $29/месяц при годовой оплате.

Strapi

Community — free/open-source.

Growth — $45/месяц за платные CMS-возможности; managed Strapi Cloud оплачивается отдельно.

Laravel

Лицензия framework сама по себе не создаёт заметной стоимости.

Основная цена — разработка.

Именно поэтому предыдущий материал про полную стоимость владения важнее списка лицензий: платформа за 0 ₽ вполне способна иметь TCO выше системы с платной лицензией.

Права на код и возможность переезда

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

Зато очень любит обсуждать через пять лет.

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

Self-hosted open source

• WordPress;
• OpenCart;
• Drupal;
• MODX.

Вы можете менять hosting и работать с файлами/базой самостоятельно.

Self-hosted commercial

1С-Битрикс.

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

Hosted SaaS

• Tilda;
• Shopify.

Платформа управляет runtime.

Вы покупаете сервис.

Custom framework

Исходники и права зависят от договора с разработчиком.

И это особенно важное место: self-hosted ещё не означает автоматически «всё наше», если права на custom code и доступы оформлены плохо.

Миграция: самый дорогой вопрос, который редко задают заранее

Перед выбором платформы попробуйте задать неприятный вопрос:

Как мы уйдём отсюда через пять лет?

Не потому, что обязательно нужно уйти.

А потому, что ответ показывает степень зависимости.

Content portability

Можно ли получить:

• pages;
• posts;
• products;
• images;
• users;
• orders.

Code portability

Можно ли получить implementation.

Business logic portability

Что произойдёт с:

• memberships;
• checkout;
• workflows;
• cabinet;
• CRM;
• automation.

Именно здесь становится видно, почему «экспорт есть» ещё не означает полной переносимости.

Когда нужно думать о рынке разработчиков

Допустим, две CMS технически подходят одинаково.

На первой в вашем регионе работают 500 специалистов.

На второй — 15.

Это уже бизнесовый параметр.

Потому что через три года вам может понадобиться другой подрядчик.

Цена технологии включает не только:

сколько часов требуется написать функцию.

Но и:

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

Именно поэтому vendor lock-in бывает не только технологическим.

Он бывает кадровым.

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

Нормальный владелец бизнеса не обязан знать разницу между Laravel queues и WordPress hooks.

Но он способен описать бизнес.

Этого достаточно для первого этапа.

Как выбрать CMS или платформу для сайта

Шаг 1. Опишите не страницы, а задачи

Плохо:

нужен сайт на 100 страниц.

Хорошо:

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

Шаг 2. Выпишите основные типы данных

Например:

• услуги;
• товары;
• сотрудники;
• филиалы;
• документы;
• заказы;
• клиенты.

Если данных мало и они простые, тяжелая CMS может быть не нужна.

Шаг 3. Опишите интеграции

Есть ли:

• 1С;
• CRM;
• payment;
• delivery;
• ERP;
• external API;
• marketplace feeds.

Шаг 4. Представьте проект через три года

Что вероятно появится:

• второй язык;
• магазин;
• новые города;
• личный кабинет;
• десятки редакторов;
• дополнительные integrations.

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

Шаг 5. Определите роль SEO

Если сайт должен получать большой органический трафик, заранее проверьте:

• структуру URL;
• metadata;
• canonical;
• structured data;
• redirects;
• filters;
• internal linking.

Шаг 6. Посчитайте TCO

Не только лицензию.

Учитывайте:

• hosting;
• plugins;
• support;
• developers;
• updates;
• migration.

Шаг 7. Проверьте переносимость

Спросите:

что мы получим, если перестанем работать с платформой или подрядчиком?

Шаг 8. И только теперь сравнивайте CMS

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

Миф: WordPress подходит только для блогов

Нет.

Сам WordPress официально позиционируется от простых сайтов до сложных portals, enterprise и application use cases.

Другое дело, что не всякое приложение рационально строить на WordPress.

Это уже архитектурный вопрос.

Миф: Tilda подходит только для лендингов

Тоже нет.

Каталог до 5 000 товаров на Personal и 50 000 на Business — уже достаточное доказательство того, что платформа давно вышла за пределы одностраничников.

Но наличие такой технической возможности не означает, что любой магазин на 50 000 товаров рационально строить именно там.

Миф: крупный магазин нельзя делать на WooCommerce

Универсального ограничения по количеству товаров нет.

Официальная WooCommerce прямо пишет о магазинах со 100 000+ products.

Это говорит о возможности масштабирования.

Не о том, что масштабирование будет бесплатным и автоматическим.

Миф: если есть 1С, нужен только Битрикс

У Битрикса действительно сильная native ecosystem обмена с 1С через CommerceML.

Но это не делает альтернативы невозможными.

Просто стоимость integration нужно считать честно.

Миф: open source значит бесплатно

Open-source license может стоить 0 ₽.

Разработка, hosting, update и support — нет.

WordPress, OpenCart и Drupal прекрасно это демонстрируют.

Миф: headless лучше, потому что современнее

Нет.

Headless решает конкретный архитектурный вопрос:

отделить управление контентом от frontend и использовать данные в нескольких каналах.

Если такой задачи нет, разделение может просто увеличить TCO.

Миф: Laravel быстрее любой CMS

Framework не гарантирует производительность.

Можно написать прекрасное приложение.

Можно написать ужасные SQL-запросы.

Название технологии не отменяет качество реализации.

Миф: CMS определяет позиции сайта

Нет.

CMS определяет, насколько удобно реализовывать:

• архитектуру;
• технические SEO-требования;
• performance;
• content management.

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

Миф: с SaaS невозможно уехать

Слишком категорично.

Например, Tilda Business позволяет экспортировать code.

Но Product Catalog, Members и CRM не экспортируются.

Поэтому правильнее говорить:

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

Как выглядит плохой выбор CMS

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

Она появляется позже.

Например:

Tilda выбрана для проекта, который через год превратился в сложный B2B кабинет.

WordPress превратили в application из десятков плохо связанных plugins.

Laravel заказали для сайта на 20 страниц, и теперь любое изменение контента требует разработки.

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

Drupal внедрили ради трёх редакторов и одного языка.

Все решения технически могут работать.

Но бизнес переплачивает за несовпадение инструмента и задачи.

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

Как выглядит хороший выбор

Хорошо выбранная платформа обычно почти не обсуждается.

Редактор публикует.

Менеджер получает заявки.

Разработчик добавляет функции.

SEO-специалист управляет структурой.

Hosting справляется.

И никто каждые две недели не говорит:

наша CMS этого не умеет, поэтому придётся придумать обходной путь.

Это хороший признак.

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

Но не настолько сложной, чтобы сама стать главным проектом компании.

Какая платформа лучше для моего типового проекта

Если совсем сократить статью до практического shortlist, я бы ориентировался так.

Сайт услуг

Смотреть в сторону:

Tilda / WordPress.

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

Чаще:

WordPress.

При более сложной governance:

Drupal / 1С-Битрикс.

Интернет-магазин малого и среднего размера

Смотреть:

WooCommerce / OpenCart / 1С-Битрикс / Tilda.

Потом сравнивать реальные процессы.

Крупный российский e-commerce с 1С

1С-Битрикс становится особенно сильным кандидатом.

Но shortlist может включать:

• WooCommerce;
• custom;
• специализированную архитектуру.

Международный e-commerce

Shopify может быть очень сильным вариантом, если юридическая и payment-инфраструктура бизнеса подходит под его operating model.

Сервис с собственной логикой

Framework/application architecture.

Например:

Laravel.

CMS можно использовать рядом для content layer.

Несколько frontend поверх одних данных

Рассматривать:

headless CMS.

Например Strapi.

Но слово «рассматривать» принципиально.

Это не автоматическое назначение технологии.

Почему я чаще работаю с WordPress

На Vagizov.com большая часть разработки ориентирована на WordPress.

Это не означает:

WordPress лучший для любого проекта.

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

• сайты услуг;
• corporate;
• SEO-driven content;
• каталоги;
• WooCommerce;
• custom modules.

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

На текущей странице услуги Разработка сайтов проекты даже разделены по уровню сложности: WordPress Старт, WordPress Бизнес и WordPress Система. И это хорошо показывает сам принцип статьи — одна и та же CMS может использоваться совершенно по-разному в зависимости от архитектуры проекта.

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

Это и есть нормальный технологический выбор.

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

Самая частая ошибка происходит ещё до выбора CMS.

Заказчик говорит:

Нужен интернет-магазин.

Разработчик отвечает:

Делаем на Битриксе.

И обе стороны уже обсуждают технологию, хотя не выяснено:

• сколько товаров;
• какие склады;
• откуда цены;
• какие роли;
• какая доставка;
• что с 1С;
• нужен ли B2B;
• будет ли SEO;
• какой checkout;
• нужны ли персональные кабинеты.

То есть решение принято раньше задачи.

Поэтому перед сравнением CMS лучше сначала написать нормальное ТЗ.

Не обязательно 100 страниц.

Но должна существовать структура требований.

Для подготовки такого документа можно использовать мой подход из статьи Как написать ТЗ на сайт через ChatGPT.

И только после этого задавать исполнителю вопрос:

Почему вы предлагаете именно эту технологию?

Хороший ответ будет про ваши требования.

Плохой:

Мы просто на ней всё делаем.

Доступы и смена подрядчика тоже входят в выбор платформы

Выбирая self-hosted CMS, SaaS или custom development, бизнес выбирает ещё и модель управления.

На WordPress вам понадобятся:

• hosting;
• files;
• database;
• admin.

На SaaS часть этих доступов вообще отсутствует, потому что инфраструктурой управляет платформа.

На custom system список может стать значительно длиннее:

• Git;
• CI/CD;
• cloud;
• secrets;
• databases;
• queues.

Поэтому удобство поддержки и безопасность доступа тоже стоит оценивать до запуска.

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

Главное

Универсально лучшей CMS нет.

И это не дипломатический ответ, чтобы никого не обидеть.

Это техническая реальность.

Электрик может прекрасно работать на Tilda.

Тот же сайт услуг может быть рациональнее сделать на WordPress, если бизнес планирует несколько сотен SEO-страниц.

Интернет-магазин может отлично работать на WooCommerce.

Другому магазину с глубокой 1С-инфраструктурой рациональнее выбрать Битрикс.

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

Большой enterprise content project способен естественно лечь на Drupal.

А сервис с собственными расчётами и workflows вообще может не нуждаться в классической CMS как в ядре продукта.

Поэтому я бы не спрашивал разработчика:

Какая CMS лучшая?

Я бы сначала рассказал ему:

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

И после этого задал бы другой вопрос:

Почему именно эта платформа решит нашу задачу дешевле, надёжнее и проще в сопровождении, чем альтернативы?

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

Если аргумент сводится к:

эта CMS лучшая, потому что мы на ней всегда работаем,

то бизнес пока выбирает не платформу.

Он выбирает привычку подрядчика.

Главный принцип здесь очень простой:

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

Не выбирайте WordPress потому, что он самый популярный.

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

Не выбирайте Tilda только потому, что сайт можно запустить быстро.

Не выбирайте Laravel только потому, что custom development звучит профессионально.

Сначала определите, каким должен стать ваш сайт через три года.

После этого половина технологий обычно отпадает сама.