Про WooCommerce обычно пишут в двух жанрах. Первый: «бесплатно, гибко, ставится за вечер». Второй: «не годится для серьёзного магазина, берите нормальную платформу». Оба одинаково бесполезны, потому что не отвечают на вопрос владельца: у меня столько-то товаров и такой-то поток - будет работать или нет?
Ответ зависит от объёма и от того, кто за магазином следит. Разберём по рубежам, а потом покажем пять реальных поломок с цифрами - из живого магазина украшений на несколько тысяч позиций, который мы приводили в чувство этим летом.
Рубеж первый: до 300 товаров#
Здесь Woo прекрасен и спорить не о чем. Каталог грузится, поиск работает, обычного хостинга хватает с запасом. Проблемы бывают только рукотворные: тяжёлые фотографии, десяток лишних плагинов и тема, купленная за 60 долларов, в которую напихано всё сразу.
Что делать на этом рубеже: не ставить ничего лишнего и следить за весом картинок. Всё.
Рубеж второй: 300-2000 товаров#
Начинает проявляться то, чего не видно на маленьком каталоге.
Админка тяжелеет: список товаров с фильтрами и сортировкой уже думает по несколько секунд. Появляется потребность в фильтрах по атрибутам на витрине, и вот здесь Woo впервые показывает характер. Фильтрация по атрибутам - это запросы к таблице метаданных, которая растёт быстрее самого каталога. Плагин-фильтр решает задачу, но становится самой хрупкой деталью магазина.
Второе, что вылезает - вариации. Товар с тремя размерами и четырьмя цветами превращается в двенадцать записей в базе. Каталог на 800 товаров с вариациями по нагрузке ведёт себя как каталог на 5000.
Рубеж третий: 2000-5000 товаров и выше#
Тут магазин требует инженерного отношения. Виртуальный хостинг перестаёт справляться, нужен отдельный сервер, объектный кэш, аккуратная настройка кэширования страниц. Любое массовое действие - импорт прайса, пересчёт цен, синхронизация остатков - становится операцией, которую нужно планировать, а не запускать в час пик.
Технического потолка у Woo нет, магазины живут и на десятках тысяч позиций. Есть потолок обслуживания: с какого-то момента вы платите не за платформу, а за человека, который держит её в форме.
Пять поломок из практики, с цифрами#
Дальше самое интересное. Это не список из чужой статьи, а то, что мы чинили руками в живом магазине с оборотом. Все цифры настоящие, название клиента опускаем.
21 МБвесила одна карточка товара до правки 3,8 МБстала после перевода галереи в webp 841вариация с рассинхронизированной ценой в базеПервое: вес карточки. Фотографии загружались как есть, галерея тянула все размеры сразу. Карточка весила 21 мегабайт - на мобильном интернете это просто не открывается, человек уходит до того, как увидит цену. Перевод галереи в webp и правка вывода размеров дали 3,8 мегабайта, то есть впятеро легче. Никакой магии, обычная гигиена, о которой мы отдельно писали в разборе скорости загрузки сайта.
Второе: склейка скриптов убила фильтр. В кэширующем плагине была включена опция объединения JavaScript. Выглядит безобидно и даже рекомендуется всеми гайдами по ускорению. В результате бандл собрался мёртвым, и фильтр каталога перестал работать: посетитель выбирал параметр и получал пустую страницу. Заметили не сразу, потому что на глаз сайт был жив, а продажи просто просели. Опцию пришлось снять и больше не включать.
Третье: цены разъехались. Клиенты писали: в каталоге видно 1650, а в корзине 1843. Причина - дубли вариаций товара, оставшиеся от старых импортов: часть записей хранила устаревшую цену, и витрина иногда цепляла именно её. Нашлись 841 вариация с грязными данными и пачка сирот, которые удалили.
Четвёртое: товары «видно, но не купить». У новых позиций по умолчанию включались предзаказы, и товар попадал в статус «под заказ». В каталоге он есть, кнопка не работает как надо, менеджеры узнают об этом от клиента. Лечится настройкой по умолчанию, но найти это можно только целенаправленно.
Пятое: логи и бэкапы в открытом доступе. Служебные логи разрослись до 3,8 гигабайта и забили диск на 82%, а лежали они вместе с бэкапами прямо в корне сайта - то есть отдавались по прямой ссылке любому, кто её угадает. Это уже не про скорость, это про безопасность: дыры в плагинах и открытые служебные файлы - главный канал взлома магазинов на WordPress.
Общее у всех пяти историй: ни одна не проявляется как «сайт лежит». Магазин работает, страницы открываются, админка отвечает. Просто продаж меньше, чем должно быть. Именно поэтому магазин на Woo нужно проверять по чек-листу, а не по ощущению «вроде всё нормально». Это первое, что мы делаем в аудите: проходим путь покупателя с телефона до оплаты и смотрим, где он ломается.
Плагины: главный источник и силы, и боли#
Философия Woo простая: ядро делает базовую торговлю, всё остальное приносят плагины. Фильтры, доставка, оплата, выгрузки, поп-апы, оптимизация.
Отсюда два практических правила, выстраданных на живых проектах.
Первое: каждый плагин - это будущий конфликт. В том же магазине один плагин оптимизации отключал SEO-модуль на главной и на витрине каталога: мета-теги просто пропадали, а в остальных разделах были на месте. Другой плагин транслитерации ломал названия атрибутов в админке. По отдельности оба работают правильно, вместе - нет.
Второе: обновления безопасности ставим сразу, крупные - по расписанию и на копии. Магазин с оборотом нельзя обновлять «на живую» в пятницу вечером. Что вообще должно входить в нормальное сопровождение, разбирали в статье про поддержку сайта.
Когда WooCommerce - правильный выбор#
Соберём честно, без агитации в обе стороны.
Берите Woo, если: каталог до нескольких тысяч позиций, вам нужен контроль над кодом и данными, важна цена входа, а контент-часть (блог, статьи, SEO) для вас не менее значима, чем сама торговля. WordPress остаётся сильнейшим инструментом для контента, и магазин на нём получает это в довесок.
Не берите Woo, если: у вас десятки тысяч активных позиций с вариациями, сложная логика цен и складов, и при этом нет человека, который будет вести магазин технически. В такой конфигурации конструктор превращается в постоянную статью расходов на починку.
Промежуточный вариант, который часто оказывается верным: витрина и контент на WordPress, а тяжёлая логика (склад, цены, документы) остаётся в учётной системе, откуда данные приходят по расписанию. В том же магазине синхронизация с учёткой идёт по расписанию каждые 15 минут, полный цикл занимает около 33 секунд - и этого достаточно, чтобы остатки на витрине не врали.
Если сомневаетесь между Woo и другой платформой, начните не с выбора движка, а с ответа на вопрос «сколько у меня товаров и кто будет это обслуживать». Мы этот разговор ведём на этапе оценки: что взять готовое, что писать руками, во сколько обойдётся содержание в год. Как считаем и что входит в работу - на странице сайтов и магазинов, а обзорный разбор форматов - в статье интернет-магазин под ключ.
Источники и оговорки#
Все числа в разделе про поломки взяты из работы над одним действующим магазином на WordPress и WooCommerce в июле и августе 2026 года: вес карточки до и после оптимизации, количество вариаций с расхождением цен, объём логов и параметры синхронизации замерялись на его продакшене. Название клиента не раскрываем. Рубежи по количеству товаров - обобщение нашей практики, а не результат синтетического тестирования: на другом железе и другой теме границы сместятся.
