Magento и WooCommerce для крупного магазина и что каждая платформа даёт поисковой оптимизации

Обе платформы написаны на PHP, обе держат каталоги в десятки тысяч позиций, обе умеют отдавать карту сайта, canonical и микроразметку. За похожими строчками в сравнительных таблицах стоят разные философии: Magento - тяжёлый каркас под большой e-commerce и командную разработку, WooCommerce - гибкая экосистема, где магазин собирают из плагинов за неделю. Выбор между ними редко сводится к вкусу: он зависит от оборота, размера каталога, состава команды и планов на зарубежные рынки. Сравнение ниже - про различия, которые проявляются на втором году жизни проекта, а не в первый день.

Техническая база Magento и настоящая цена масштаба

Magento Open Source бесплатен, но это единственное, что в системе не стоит денег. Актуальные версии ветки 2.4.x требуют PHP 8.1 и новее и MySQL 8.0, а для нормальной работы крупному каталогу нужны Redis под сессии и кеш, RabbitMQ под очереди и поисковый движок - Elasticsearch или OpenSearch, который с версии 2.4.6 стал стандартом для собственной инфраструктуры. Стек собирают на VPS или выделенном сервере, приличный управляемый хостинг обходится от 150-200 долларов в месяц. Adobe Commerce, коммерческая версия с облачной инфраструктурой и поддержкой вендора, продаётся по лицензии от десятков тысяч долларов в год и дороже на этапе внедрения.

Расплата за сложность - возможности. Один инстанс Magento держит несколько сайтов, магазинов и представлений (store views): в одной админке живут разные домены, языки, валюты и даже разные каталоги с разными ценами. Товары хранятся в EAV-архитектуре, которая позволяет вешать на позицию сотни атрибутов без переделки таблиц. Стандартная тема Luma тяжёлая и устаревшая, поэтому живые проекты ставят Hyva - фронтенд на Alpine.js и Tailwind CSS, который собирается с минимальным JavaScript и бережёт Core Web Vitals. GraphQL-интерфейс в ядре открывает дорогу к headless-витринам, если бизнесу нужен настоящий PWA, а не модное слово в презентации. Тяжёлые операции - переиндексацию каталога, массовое обновление цен и остатков через REST API, синхронизацию с ERP - Magento выносит в фоновые процессы по расписанию cron, и витрина не ждёт их при отдаче страницы.

WordPress с WooCommerce как экосистема быстрых решений

WordPress обслуживает около 40 процентов всех сайтов в сети, и почти каждый второй магазин на готовом движке работает именно на WooCommerce. Ядро бесплатное, хостинг для старта стоит 10-20 долларов в месяц, тему и плагины для оплаты, доставки и фильтров ставят из открытого репозитория за пару вечеров. Магазин с сотней товаров запускается за неделю силами одного человека, который не обязан быть программистом. Такой старт дешевле, чем кажется: лицензий нет, приличная тема стоит 30-60 долларов, базовый набор расширений бесплатен. Экономия настоящая, но временная - с ростом каталога и трафика её съедают платные подписки на плагины, хостинг посерьёзнее и часы на разбор конфликтов.

Архитектура другая: товары лежат в таблице записей wp_posts, свойства - в wp_postmeta. До 10-20 тысяч позиций при грамотном кеше это почти незаметно, дальше запросы начинают толстеть: сотни атрибутов разрастают таблицу метаданных, и выборки с фильтрами ощутимо нагружают базу. Обязательный минимум для большого магазина - Redis под object cache, нормальный SQL-хостинг и дисциплина по автозагрузке в wp_options. Слабое место экосистемы - плагины: уязвимости в расширениях, а не в ядре, остаются главной причиной взломов, а конфликт двух обновившихся плагинов способен уложить витрину в самый разгар сезона.

Поисковая механика Magento и уборка фильтров каталога

В Magento SEO-механика встроена глубже. Системный менеджер URL-переопределений ведёт историю редиректов: поменялся адрес товара - старый URL автоматически получит 301. У категорий настраиваются канонические теги, вплоть до выбора между адресами с путём категории и без него. Карта сайта генерируется ядром, у атрибутов есть собственные мета-поля, из которых собирают посадочные под фильтры. Слабое звено - многослойная навигация: страницы вида /category?color=4&size=5 плодят миллионы комбинаций, и их принято закрывать от робота:

User-agent: *
Disallow: /checkout/
Disallow: /customer/
Disallow: /*?dir=
Disallow: /*?order=
Disallow: /*?price=
Sitemap: https://example.com/sitemap.xml

Для международных представлений есть store views с отдельными адресами, валютами и контентом, но hreflang ядро не собирает: связи между языковыми версиями настраивают модулями или правкой шаблона. В Adobe Commerce из коробки работает модуль B2B с корпоративными аккаунтами, персональными прайсами и котировками, что для оптового бизнеса часто важнее любой микроразметки. Плата за глубину - порог входа: без разработчика в Magento не делается почти ничего, от смены шаблона title до вывода новой секции на главной. Зато контроль полный: доступны и серверные настройки, и кеширование на уровне Varnish, и логи, и планировщик задач, что для каталогов с большими выборками и есть граница выживания. Массовые операции решены по-взрослому: метатеги тысяч товаров правятся импортом и экспортом CSV, посадочные под значения атрибутов собираются из встроенных мета-полей, категорийные тексты выводятся CMS-блоками без изменения кода. Когда SEO-специалисту нужно перестроить структуру из пятисот категорий, разница между "настроил за день" и "неделю правил шаблоны" превращается в деньги.

Поисковая механика WooCommerce и пределы плагинного подхода

В WooCommerce оптимизацию собирают из плагинов, и это удобно: Yoast SEO или RankMath дают карту сайта, шаблоны title и description, канонические теги, хлебные крошки и микроразметку товаров за один вечер. Проблемы начинаются на нестандартных шаблонах, где автоматика путается: canonical на странице фильтрации иногда указывает сам на себя, а иногда на базовую категорию - поведение зависит от настроек плагина и темы, и за этим приходится следить руками. Фильтры создают адреса с параметрами вида /?filter_color=blue, их тоже закрывают от индексации:

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /*?filter_
Sitemap: https://example.com/sitemap_index.xml

Карту сайта SEO-плагин делит на вложенные файлы по типам контента, и для магазина на десятки тысяч позиций это спасает и от лимитов парсера, и от путаницы в отчётах. Многоязычность собирается на WPML или Polylang: плагины умеют hreflang, переведённые адреса и связность контента. Для отдельных стран применяют мультисайт - сеть самостоятельных сайтов на одном ядре WordPress с общей админкой сети и разными доменами. Подход рабочий, но каждый сайт сети живёт своей темой и своим набором плагинов, и на пяти-шести языках обслуживание превращается в полноценную отдельную работу администратора. Отдельная зона внимания - вариативные товары: у каждого варианта свои записи в базе, и при неряшливой настройке варианты порождают собственные адреса, которые потом ловят в отчётах как дубли. Микроразметку Product SEO-плагины собирают сами, отзывы со звёздами тоже, но за фильтры и страницы поиска отвечает ручная настройка, и по умолчанию она не консервативная. Плюс WooCommerce - скорость изменений: новый функционал ставится за вечер, минус - каждый новый плагин добавляет точку отказа.

Критерии выбора под оборот, каталог и состав команды

Если убрать эмоции, решение принимается по нескольким измеримым признакам:

1. размер каталога: до 20 тысяч позиций WooCommerce с Redis тянет спокойно, от 50 тысяч честнее сразу закладывать Magento;
2. оборот и бюджет: Adobe Commerce с внедрением по цене автомобиля сходится при выручке от нескольких миллионов долларов в год;
3. B2B-сценарии: корпоративные аккаунты, индивидуальные прайсы и котировки в Magento есть в ядре, в WooCommerce собираются плагинами;
4. международные планы: мультимагазинность из одной админки против мультисайта WordPress с раздельным обслуживанием;
5. команда: Magento требует PHP-разработчика в штате постоянно, WooCommerce позволяет жить внешним подрядчиком;
6. скорость запуска: магазин на WooCommerce собирают за недели, проект на Magento занимает месяцы;
7. headless-планы: GraphQL и PWA-инструментарий в ядре Magento против плагина WPGraphQL на WordPress;
8. существующая экспертиза: если в штате уже есть Magento-разработчики или проверенное агентство, спор о WooCommerce закрывается сам.

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

Производительность и зелёные Core Web Vitals на тяжёлых каталогах

Пороги метрик одинаковы для всех: LCP до 2.5 секунды, INP до 200 миллисекунд, CLS до 0.1. Дорога к ним у платформ разная. Magento умеет полностраничный кеш через Varnish: собранная страница отдаётся из памяти за миллисекунды, а персональные блоки вроде корзины пересчитываются отдельно. Настройка Varnish и Redis - работа инженера, а не галочка в админке, зато дальше крупный каталог отдаётся с ровной скоростью независимо от числа атрибутов.

WooCommerce быструю отдачу собирают из плагинов: WP Rocket или LiteSpeed Cache закрывают страничный кеш, Redis берёт на себя object cache, CDN развозит статику. На лёгком каталоге результат сопоставим с Magento. Разница вылезает на больших выборках: фильтрация по десяткам атрибутов через wp_postmeta без кеша порождает тяжёлые запросы с соединениями таблиц, и листинг с сортировкой начинает отдаваться за секунду и дольше. Спасают либо плагины ускорения каталога с выносом атрибутов в собственные таблицы, либо честное признание, что проект перерос стек.

Фронтенд в обоих лагерях решается темой: Hyva для Magento собирается с минимальным JavaScript, блочные темы WordPress дают предсказуемую вёрстку, а ленивую загрузку, srcset и форматы WebP и AVIF поддерживают обе стороны. Вывод скучный и честный: зелёные метрики достижимы и там и там, но в Magento они стоят инженерных часов на старте, а в WooCommerce требуют дисциплины и пересборки по мере роста.

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

Крупному оптовому бизнесу с сотнями тысяч SKU, персональными ценами и десятком стран в одной админке WooCommerce объективно не подходит: плагинная архитектура треснет по швам на этапе роста, и переезд обойдётся дороже, чем сразу заложить Magento. Небольшому бренду, который живёт на контент-маркетинге, ведёт блог и продаёт двести позиций, Magento наоборот избыточен: он съест бюджет, который лучше потратить на рекламу и контент. Границу обычно находят между десятью и пятьюдесятью тысячами позиций - в этом коридоре оба варианта рабочие, и выбор делают по команде.

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

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