WooCommerce или 1С-Битрикс: честное сравнение для российского магазина

# WooCommerce или 1С-Битрикс: честное сравнение для российского магазина

Финансовый директор одной компании, с которой я работал по другому проекту, как-то поймал меня в переговорной и задал вопрос в лоб: «Объясните мне как человеку, который считает деньги, а не пишет код — почему мы каждый год платим за продление лицензии Битрикса, если рядом есть бесплатный WordPress, на котором, как я слышал, тоже можно сделать магазин?» Вопрос звучал невинно, но за ним стояла реальная сумма — компания на тот момент отдавала за поддержку лицензии больше двухсот тысяч рублей в год, и никто в руководстве толком не мог объяснить, за что именно — платили по инерции, потому что так повелось с момента запуска сайта несколько лет назад, а разбираться в деталях лицензионной модели было попросту некому.

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

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

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

За что вообще платишь: лицензия против экосистемы

Начнём с самого болезненного вопроса — денег на входе. Модель Битрикса устроена так: вы покупаете лицензию «1С-Битрикс: Управление сайтом» одной из редакций, и цена растёт вместе с функциональностью. Младшая редакция «Старт» стоит в районе 15 тысяч рублей и по сути годится только для визитки, а не для полноценного магазина. Для реальной торговли нужна как минимум редакция «Стандарт» — это порядка 60-70 тысяч рублей, и там уже есть базовый функционал интернет-магазина. Для серьёзного каталога с расширенными возможностями — торговыми предложениями, скидочными механиками, интеграцией с 1С — потребуется редакция «Малый бизнес» в районе 100-130 тысяч рублей, а для крупного проекта — «Бизнес» под 200-250 тысяч рублей и выше. Это ориентировочные цифры по актуальному на момент написания статьи прайсу, они меняются, и перед реальной сделкой их нужно сверять напрямую у партнёра, но порядок величин такой.

Но сама покупка лицензии — это только вход в экосистему. Дальше начинается обязательное ежегодное продление подписки на обновления и техническую поддержку — обычно это 20-25 процентов от стоимости лицензии в год. То есть если вы один раз заплатили 130 тысяч за редакцию «Малый бизнес», рассчитывайте дополнительно на 25-35 тысяч рублей ежегодно просто за то, чтобы продукт продолжал обновляться и получать патчи безопасности. Не продлили — модуль продолжает формально работать, но перестаёт получать критичные обновления, и рано или поздно это аукается несовместимостью с новыми требованиями законодательства или уязвимостью, которую никто уже не закроет.

WooCommerce устроен принципиально иначе. Само ядро — WordPress и WooCommerce — бесплатно и всегда будет бесплатным, потому что это open-source проекты с открытой лицензией GPL. Здесь деньги уходят не на лицензию платформы, а на платные расширения и модули, которые добавляют конкретную функциональность — способы оплаты, доставку, B2B-логику, интеграцию с 1С, защиту от взлома. И вот тут возникает та самая проблема, о которой я подробно писал в статье про зоопарк из двадцати WooCommerce-расширений — если покупать каждую функцию отдельным плагином у отдельного разработчика, годовые траты на подписки могут набежать до сопоставимых с лицензией Битрикса цифр, просто раскиданных по десятку разных счетов вместо одного.

Честно говоря, именно в этом и кроется главный практический вывод, который мало кто произносит вслух: разница между Битриксом и WordPress — не в том, что один платный, а другой бесплатный. Разница в модели платежа. Битрикс продаёт вам платформу целиком, с понятной, хоть и не маленькой ценой, и дальше вы получаете предсказуемый, единый набор модулей внутри одной экосистемы, поддерживаемой одним вендором. WordPress продаёт вам бесплатное ядро, но дальше вы сами собираете стек из независимых компонентов, и итоговая стоимость владения зависит от того, насколько разумно вы этот стек собрали — можно уложиться в скромную сумму, а можно наплодить дублирующих друг друга платных плагинов и заплатить больше, чем стоила бы Битрикс-лицензия. Именно поэтому мы в COS WP Woo сделали ставку на единый пакет модулей внутри одного плагина с прозрачными тарифами — это, по сути, попытка взять модель предсказуемости у Битрикса и совместить её с гибкостью и стоимостью открытой экосистемы WordPress.

Есть ещё одна статья расходов внутри лицензионной модели Битрикса, о которой честно предупреждают редко, — это требования к хостингу. Платформа рекомендует так называемое оптимизированное окружение — BitrixVM или его аналоги — с конкретным набором модулей PHP, настроенным memcached, скомпилированным модулем ускорения самого движка. Формально Битрикс работает и на обычном хостинге, но без рекомендованного окружения часть встроенных механизмов производительности, включая композитное кеширование, работает не в полную силу. На практике это означает, что многие компании в итоге выбирают хостинг именно у партнёров, аккредитованных под Битрикс, а такие тарифы обычно на 20-40 процентов дороже условно универсального VPS того же объёма ресурсов — просто потому что в цену заложена лицензия на оптимизированное окружение и поддержку именно этой платформы. WordPress в этом смысле принципиально проще: подойдёт практически любой хостинг с PHP и MySQL, конкуренция среди хостеров огромная, и цена определяется рынком, а не привязкой к конкретной платформе.

Есть и обратная сторона медали, о которой я тоже скажу честно. Модуль поисковой оптимизации у Битрикса — встроенный, без необходимости ставить сторонний плагин: правила ЧПУ, метатеги, микроразметка настраиваются из коробки одним модулем, интегрированным с остальной системой. В мире WordPress эту же задачу закрывают либо сторонние SEO-плагины вроде Yoast или Rank Math, либо, как в нашем случае, собственный SEO-движок внутри плагина магазина. Разница не в том, что где-то это невозможно, а в том, что у Битрикса это единая система с одним поставщиком, а у WordPress — выбор из нескольких конкурирующих решений, каждое со своими нюансами совместимости.

Если свести это всё к грубым цифрам первого года — что называется, для ориентира, а не как истину в последней инстанции, — то для среднего магазина в несколько тысяч товаров с редакцией «Малый бизнес» Битрикс на старте обойдётся в 130-180 тысяч рублей на саму лицензию плюс 25-35 тысяч ежегодного продления, плюс отдельно оплата работы интегратора по внедрению и адаптации дизайна — обычно ещё 150-400 тысяч рублей в зависимости от сложности. WooCommerce с грамотно подобранным набором расширений на тот же функционал обходится в 0 рублей за само ядро плюс 40-100 тысяч рублей в год на подписки нужных модулей, плюс работа по адаптации темы и настройке — обычно 100-350 тысяч рублей в зависимости от сложности. На бумаге WordPress выглядит дешевле на входе, но разница не настолько драматична, как рисуют сторонники открытого кода в горячих спорах — просто потому что грамотное внедрение стоит денег вне зависимости от платформы, а лицензия — это далеко не единственная и даже не всегда самая большая статья расходов.

Ещё один нюанс, о котором забывают в разговорах о лицензиях — это стоимость дополнительных лицензий при масштабировании. Если у компании несколько сайтов или планируется региональная сеть отдельных доменов под разные города, в мире Битрикса это, как правило, отдельная лицензия на каждый сайт, либо переход на более дорогую редакцию с поддержкой мультисайтовости. У нас в модели тарифов это тоже учтено, но иначе — Professional-тариф уже покрывает пять сайтов лицензией за 9900 рублей в месяц, а Enterprise снимает ограничение по числу сайтов вовсе за 19900 рублей в месяц. Для сети из нескольких региональных доменов эта разница в подходе к мультисайтовости может ощутимо изменить итоговую экономику проекта.

1С из коробки — и что эта коробка стоит на самом деле

Вот аргумент, который я слышу чаще всего в пользу Битрикса, и он не на пустом месте — интеграция с 1С у Битрикса действительно продумана глубже, потому что обе системы разрабатываются, по сути, в одной технологической орбите, а сам протокол обмена CommerceML исторически создавался именно под связку «1С плюс Битрикс». Модуль обмена данными в редакциях «Малый бизнес» и выше идёт из коробки, настройка обмена товарами, ценами и остатками — это относительно стандартизированная процедура, которую грамотный интегратор Битрикса делает за несколько дней.

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

И вот здесь наступает момент, о котором я хочу сказать максимально честно, потому что сам эту эволюцию наблюдал вблизи. Протокол CommerceML, на котором исторически строилась связка Битрикс-1С, спроектирован в середине двухтысячных и с тех пор архитектурно почти не менялся — полная выгрузка XML-файлов вместо инкрементальных обновлений, отсутствие вебхуков, синхронные долгие обмены, которые на каталоге в десятки тысяч позиций начинают занимать часы, а не минуты. Я подробно разбирал техническую сторону этой проблемы в статье «Почему CommerceML устарел и чем его заменить» — и там же показывал, что современная альтернатива, протокол OData, который используют актуальные версии 1С, даёт принципиально другой уровень интеграции: инкрементальные обновления вместо полной выгрузки, вебхуки вместо периодического опроса, JSON вместо тяжёлого XML.

Ирония в том, что переход на OData доступен не только Битриксу — это протокол самой платформы 1С, и подключиться к нему может любая система, включая WooCommerce, если в неё встроен нормальный OData-коннектор. Мы в COS WP Woo сделали ставку именно на такую интеграцию — прямое подключение к OData 1С:Управление Торговлей, с двусторонним обменом заказов, автоматическим определением атрибутов и гибким маппингом полей в админке. Подробно про архитектуру этого решения я писал в статье «Синхронизация WooCommerce с 1С:Управление Торговлей в реальном времени». Так что аргумент «у Битрикса 1С из коробки, а у WordPress нужно городить костыли» был абсолютно справедлив лет десять назад, но сегодня, при выборе современного коннектора, разрыв в удобстве интеграции гораздо меньше, чем принято думать — вопрос скорее в том, какой конкретно коннектор вы ставите, а не в том, на какой платформе построен сайт.

Расскажу конкретный случай, который хорошо иллюстрирует, насколько сильно решает не платформа, а структура данных на стороне 1С. Один из клиентов вёл учёт по нестандартной схеме — товары с одинаковым артикулом продавались под разными торговыми марками в зависимости от канала поставки, и эта логика была реализована через дополнительные реквизиты справочника, которых в типовой конфигурации не существует. Партнёр по внедрению Битрикса на предварительном созвоне уверенно сказал: «Модуль обмена из коробки, настроим за три дня». Через три недели выяснилось, что стандартный модуль эту логику попросту не видит, потому что не заточен под нетиповые реквизиты, и потребовалась доработка на стороне 1С-модуля обмена, которая стоила отдельных 180 тысяч рублей сверх изначальной сметы. С тем же самым сценарием на OData-коннекторе для WooCommerce потребовалась ровно та же самая доработка маппинга полей — просто в нашем случае она изначально закладывалась в проект, потому что гибкий маппинг атрибутов через админку — это часть архитектуры коннектора, а не исключение из правил.

Есть ещё одна тема, где сравнение обычно однобокое, — безопасность. У Битрикса есть встроенный модуль «Проактивная защита», который сканирует код на уязвимости, ведёт журнал попыток входа, фильтрует подозрительные запросы — всё это часть платной лицензии, интегрированная с остальной системой одним поставщиком. У WordPress аналогичный функционал закрывается отдельными решениями — либо тяжеловесным Wordfence, который конфликтует с половиной систем кеширования, либо специализированными модулями внутри плагинов вроде нашего, где WAF, двухфакторная аутентификация, гео-блокировка и мониторинг целостности файлов идут одним пакетом — я подробно разбирал эту архитектуру в статье про защиту WooCommerce-магазина. По факту уровень защищённости в обоих случаях зависит не столько от платформы, сколько от того, насколько ответственно владелец магазина подошёл к выбору и настройке защитного модуля — плохо настроенный Битрикс так же уязвим, как WordPress без единого защитного плагина.

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

Рынок труда: где легче найти нормального разработчика

Вот аргумент, который на мой взгляд, недооценён в большинстве сравнений, хотя именно он определяет, насколько спокойно вы будете спать после запуска сайта. Разработчик 1С-Битрикс — это узкоспециализированная роль. Рынок таких специалистов в России не маленький, но и не огромный, и хороший сертифицированный Битрикс-разработчик с реальным опытом в e-commerce стоит соответствующе — ставки в районе 3000-6000 рублей в час для фриланса или 180-350 тысяч рублей в месяц на постоянной основе для мидла-сеньора в крупном городе. И что важно — таких разработчиков объективно меньше, чем WordPress-специалистов, потому что WordPress — самая распространённая CMS в мире, а не только в России, и порог входа в неё исторически ниже.

WordPress-разработчик — это гораздо более широкий и доступный рынок труда. PHP на связке с WordPress знают миллионы разработчиков по всему миру, начиная от фрилансеров за 1000-2000 рублей в час для несложных задач, заканчивая опытными сеньорами за 4000-5000 рублей в час для сложных архитектурных решений. Что практически означает эта разница? Если ваш штатный Битрикс-разработчик уволился внезапно в среду, найти замену такого же уровня может занять несколько недель, и всё это время критичные доработки просто стоят. Найти замену WordPress-разработчику — вопрос обычно нескольких дней, потому что предложение на рынке кратно шире.

Тем, кто не готов держать разработчика в штате, обе платформы предлагают путь через аутстаффинговые агентства и техническую поддержку по подписке — вместо найма конкретного человека вы платите компании за доступ к пулу специалистов. Здесь разница между платформами тоже ощутима: агентств, специализирующихся на поддержке Битрикс-проектов, на порядок меньше, чем агентств, поддерживающих WordPress, просто в силу упомянутого выше размера рынка. Это означает, что при выборе Битрикса вы чаще оказываетесь привязаны к конкретному партнёру с его расценками и загрузкой, а при выборе WordPress у вас реально есть из чего выбирать, если текущий подрядчик перестал устраивать по цене, скорости или качеству.

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

Я сам наблюдал историю смены Битрикс-разработчика на живом проекте у одного из клиентов, для которого делал консультацию по совершенно другому вопросу. Штатный специалист, который вёл сайт почти три года, уволился без долгого предупреждения — обычная ситуация на рынке труда. Поиск замены занял почти два месяца: откликов было немного, часть кандидатов имели сертификат, но реального опыта работы с крупным каталогом и нетиповыми доработками не хватало, а тот единственный кандидат с подходящим опытом заломил ставку почти вдвое выше рыночной, откровенно пользуясь дефицитом на локальном рынке труда. Всё это время сайт продолжал работать, но накопившиеся к тому моменту задачи по доработке каталога просто стояли на паузе, а сезон, ради которого эти доработки затевались, к моменту найма нового специалиста уже прошёл.

Ещё один практический момент — это стоимость передачи проекта между командами. Если Битрикс-проект спроектирован по стандартам платформы, с использованием типовых модулей, а не безумного количества кастомных компонентов, разобраться в нём новому сертифицированному партнёру относительно просто — структура предсказуема, документация по платформе обширная, и любой Битрикс-разработчик примерно понимает, куда смотреть. WordPress-проект в этом смысле более рискованный — если предыдущий разработчик злоупотреблял кастомным кодом в файле functions.php темы вместо создания отдельного плагина, если использовал нестандартные хуки без документации, разобраться в этом новой команде может оказаться сложнее, чем в Битриксе, просто потому что WordPress не навязывает архитектурных ограничений так жёстко, и итоговое качество кода целиком зависит от дисциплины конкретного разработчика, а не от платформы.

Стоит сказать пару слов и про экосистему готовых решений вокруг каждой платформы, потому что это напрямую влияет на то, сколько будет стоить закрыть конкретную бизнес-задачу. У Битрикса есть собственный маркетплейс решений — модули для конкретных отраслевых сценариев, готовые интеграции с распространёнными сервисами, темы дизайна. Экосистема курируется одним вендором, что снижает риск купить откровенно заброшенный или несовместимый модуль, но и сужает выбор — решений там на порядок меньше, чем в экосистеме WordPress. У WordPress счёт готовых решений идёт на десятки тысяч плагинов в официальном каталоге плюс огромный рынок платных расширений на сторонних площадках. Это одновременно и сила, и слабость: почти для любой мыслимой задачи найдётся готовый плагин, но качество, поддержка и совместимость этих плагинов между собой не гарантированы никем централизованно — отсюда и рождается та самая проблема зоопарка несовместимых расширений, знакомая любому владельцу магазина, который годами добавлял по одному плагину под каждую новую задачу, от кастомных полей до конструктора форм. По сути, выбирая Битрикс, вы платите за курируемую, но более узкую экосистему; выбирая WordPress, вы получаете кратно более широкий выбор ценой необходимости самостоятельно — или силами того, кому вы это доверите, — фильтровать, что из этого выбора действительно надёжно.

Пятьдесят тысяч товаров: где у каждой системы отваливается пол

Разговоры про производительность обычно ведутся абстрактно — «Битрикс тяжёлый», «WordPress не для больших каталогов» — и в обоих случаях это упрощение, за которым прячется гораздо более интересная техническая правда. Обе платформы способны выдержать каталог в пятьдесят тысяч товаров и серьёзную нагрузку, но обе требуют для этого совершенно конкретных инженерных решений, без которых обе одинаково успешно падают на колени.

Битрикс на больших каталогах имеет встроенный механизм композитного кеширования — композит-кеш умеет отдавать статичный слепок страницы почти мгновенно, подгружая динамические блоки (корзину, персональные предложения) отдельными зонами уже после отдачи основной страницы. Это действительно продуманный инженерный инструмент, который на типовых сценариях розничной торговли работает хорошо из коробки, без необходимости городить костыли. Но у медали есть обратная сторона — сама платформа Битрикс объективно тяжелее по потреблению ресурсов сервера, чем WordPress, при сопоставимой функциональности. Инфоблоки — базовый механизм хранения каталога в Битриксе — на больших объёмах данных без грамотной настройки индексов в базе тоже начинают тормозить, и Битрикс-специалисты знают ровно те же самые боли с оптимизацией SQL-запросов, что и специалисты по WordPress, просто в рамках другой архитектуры хранения данных.

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

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

Честно если сравнивать: на объёме в пятьдесят тысяч товаров без всякой дополнительной оптимизации оба движка начинают ощутимо тормозить примерно на одном и том же этапе — там, где встроенный поиск и встроенная фильтрация упираются в лобовые SQL-запросы без должной индексации. Разница появляется в том, что нужно делать дальше. Для Битрикса типовое решение — подключение внешнего поискового движка вроде Sphinx или Elasticsearch поверх штатного поиска, композитный кеш и грамотная настройка индексов MySQL. Для WooCommerce — практически тот же самый список: вынос поиска на специализированный движок, объектное кеширование через Redis или Memcached, включение современных механизмов хранения заказов и мета-данных. То есть на серьёзном объёме обе платформы одинаково требуют квалифицированной инженерной работы, и миф о том, что «Битрикс из коробки тянет большие каталоги, а WordPress нет» — это, положа руку на сердце, упрощение, за которым чаще всего стоит просто разница в бюджете на инженерную настройку конкретного проекта, а не фундаментальное архитектурное превосходство одной платформы над другой.

Приведу конкретную иллюстрацию, чтобы разговор о производительности не остался абстрактным. Магазин промышленных товаров, о котором я уже неоднократно писал в других статьях, — это каталог на 16-17 тысяч товаров на WooCommerce. До того как мы навели порядок с архитектурой, встроенный поиск на этом объёме отвечал за 800-2000 миллисекунд, а страницы категорий с фильтрацией по нескольким атрибутам подгружались по полторы-две секунды в моменты нагрузки. После переноса поиска на отдельный движок и настройки объектного кеширования те же самые операции стали занимать единицы и десятки миллисекунд. Формально каталог не изменился ни на один товар — изменилась только архитектура обработки запросов. Я привожу этот пример специально, чтобы показать: разговор «WordPress не тянет большие каталоги» на самом деле почти всегда означает «конкретная, не оптимизированная под объём конфигурация WordPress не тянет большие каталоги», и абсолютно то же самое можно сказать про любую неправильно настроенную инсталляцию Битрикса — платформа тут ни при чём, при чём инженерная работа, которая либо была сделана, либо нет.

Мы для наших клиентов эту проблему на стороне WordPress решаем встроенным модулем поиска на Typesense, который снимает нагрузку с MySQL полностью и обрабатывает запросы за единицы миллисекунд даже на каталоге в 16-17 тысяч позиций — я подробно разбирал эту архитектуру и реальные цифры производительности в статье «Умный поиск на Typesense: быстрее встроенного WooCommerce в 50 раз». Это ровно тот случай, когда правильно выбранный инструмент снимает саму проблему, из-за которой возникает миф о принципиальной ограниченности платформы.

Когда Битрикс — правильный выбор

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

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

Второе, и это прямое продолжение первого пункта, — если бизнес требует сложной, глубоко кастомной внутренней логики уровня крупного корпоративного ретейлера: сложные схемы резервирования на множестве складов, интеграция с внутренними ERP-системами помимо 1С, специфичные требования по документообороту и внутреннему аудиту, которые нужно закрывать типовыми, годами обкатанными корпоративными модулями, а не собирать из отдельных компонентов. Битрикс с его модулем «Бизнес-процессы» и глубокой интеграцией корпоративных сценариев в таких кейсах даёт готовую, проверенную временем инфраструктуру, которую пришлось бы либо собирать вручную на любой другой платформе, либо не собирать вовсе, ограничившись более простым сценарием.

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

Четвёртое, и об этом почему-то редко говорят вслух в маркетинговых материалах обеих сторон, — вопрос реестра отечественного программного обеспечения. Для государственных заказчиков, компаний с госучастием и ряда регулируемых отраслей закупка программного обеспечения из реестра отечественного ПО — не пожелание, а формальное требование конкурсной документации. «1С-Битрикс: Управление сайтом» в этом реестре присутствует, что снимает для таких заказчиков целый пласт юридических рисков при закупке. Ядро WordPress разрабатывается международным сообществом и фондом Automattic, и само по себе оно в этот реестр не входит — если для вашей организации соответствие реестру формально обязательно, это весомый и вполне объективный аргумент в пользу Битрикса, который не имеет отношения к техническим характеристикам платформы вообще. Но для подавляющего большинства коммерческих интернет-магазинов, для которых нет таких закупочных ограничений, этот фактор попросту не применим, и упоминают его обычно как последний аргумент те, кому больше нечем крыть в чисто техническом споре.

Но при этом я не советую переезжать с одной платформы на другую просто потому, что «вроде дороже» без честного разбора, во что реально обходится альтернатива. Я видел компании, которые потратили несколько миллионов рублей на миграцию с Битрикса на WordPress, рассчитывая сэкономить на лицензиях, и в итоге за первый год эксплуатации потратили на доработку недостающего функционала и обучение команды сумму, сопоставимую с несколькими годами лицензионных отчислений, от которых они якобы «избавились». Экономия на бумаге и экономия по факту — это разные вещи, и прежде чем принимать решение о смене платформы, честный ответ на вопрос «что мы реально получим и что реально потеряем» стоит гораздо дороже, чем кажется на первый взгляд, но окупается многократно, если его дать себе труд найти.

Возвращаясь к финансовому директору с его вопросом про продление лицензии — мы в итоге посчитали для его компании полную стоимость владения на горизонте трёх лет по обеим платформам, с учётом реального объёма их каталога, реальной сложности интеграции с их конкретной конфигурацией 1С и реальной доступности кадров в их регионе. Разложили всё по тем же пунктам, что я привёл выше: лицензии и продления, стоимость интеграции с учётом нестандартных реквизитов в их 1С, зарплатную вилку по обоим типам разработчиков в их городе, и отдельно — стоимость самого перехода, если решение будет принято в пользу смены платформы. Оказалось, что для их конкретной ситуации — сорок тысяч товаров, нестандартная структура ценообразования по группам дилеров, региональная команда без штатных Битрикс-специалистов, у которой к тому же давно назрели трения с текущим интегратором из-за медленных доработок — переход на WordPress с грамотно настроенным OData-коннектором к 1С действительно давал ощутимую экономию, не в разы, но заметную, порядка 30-40 процентов совокупных затрат за три года, даже с учётом расходов на саму миграцию. Но я видел и обратные ситуации, где для компании с готовой командой Битрикс-разработчиков, типовой структурой 1С и давно отлаженными бизнес-процессами оставаться на Битриксе было объективно разумнее, чем городить миграцию ради экономии, которая на практике съедалась бы стоимостью самого переезда и рисками простоя во время него. В обоих случаях решение принималось не на эмоциях и не по принципу «open source по умолчанию лучше», а строго по цифрам, разложенным на бумаге и обсуждённым с теми, кто эти деньги реально платит.

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

Мы в COS WP Woo делаем ставку именно на WordPress и WooCommerce — не потому что считаем Битрикс плохим продуктом, а потому что видим, что для большинства некрупных и средних российских интернет-магазинов, особенно тех, где нет штатной Битрикс-команды и где 1С не идеально стандартная, связка открытого ядра с продуманным модульным пакетом даёт лучшее соотношение стоимости, гибкости и скорости внедрения. Но если ваша ситуация иная — если у вас уже работающая Битрикс-команда, типовая конфигурация 1С и требования тендерной документации к реестру отечественного ПО — я скажу вам это прямо, а не буду убеждать переезжать туда, где вам станет хуже, лишь бы продать своё решение. Хорошее консультирование в этом вопросе — это не про то, чтобы доказать превосходство одной платформы, а про то, чтобы честно посчитать, что выгоднее именно вам, даже если ответ окажется не в пользу того, что я продаю. И если вы сейчас как раз стоите перед этим выбором — начните не с сравнения демо-версий или с чтения рекламных материалов обеих сторон, а с того же вопроса, с которого начал финансовый директор: за что конкретно я плачу сейчас, и во что реально обойдётся альтернатива через три года, а не через месяц после запуска.