WooCommerce атрибут: настройка вариаций товара под каталог

Атрибут WooCommerce описывает характеристику товара: цвет, размер, материал, объём флакона. Сам по себе атрибут ничего не продаёт, а для интернет-магазина с вариативными товарами он превращается в отдельные позиции с собственной ценой и остатком только после нескольких настроек, которые на практике путают даже опытных админов каталога. Я настраивал атрибуты для магазина одежды на 300+ SKU, для косметики с разными фасовками и для B2B-каталога, где у одного товара было по 40 модификаций, и ниже разбираю рабочую схему, которая экономит часы на генерации вариаций и не роняет админку при росте каталога.

Чем атрибут WooCommerce отличается от вариации товара

Атрибут описывает свойство: «Цвет» со значениями «красный», «синий», «зелёный». Вариация: конкретная комбинация значений атрибутов внутри одного вариативного товара, у которой есть свой артикул, цена, остаток, вес и картинка. Пока атрибут просто прикреплён к товару, магазин показывает список опций, но без сгенерированных вариаций у каждой комбинации нет собственной цены, и WooCommerce либо показывает цену родителя, либо вообще не даёт добавить товар в корзину.

Чтобы атрибут стал вариацией, товар должен иметь тип «Вариативный товар», у атрибута нужно включить галку «Задействовано для вариаций», а затем нажать «Сгенерировать вариации» на вкладке «Вариации». Это три отдельных шага, и пропуск любого из них чаще всего оказывается причиной того, что в магазине «вариации не появляются» после добавления нового цвета или размера.

Глобальные и локальные атрибуты WooCommerce: что выбрать для каталога

WooCommerce даёт два типа атрибутов. Глобальные создаются в разделе «Товары → Атрибуты», хранятся как таксономия (в базе это записи вида pa_cvet, pa_razmer) и переиспользуются на любом количестве товаров. Локальные создаются прямо внутри карточки товара, живут только в его метаданных и нигде больше не всплывают.

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

Как создаю атрибут и привязываю его к вариациям

Порядок, который у меня отработан для магазинов на 100‑2000 товаров:

• Завожу глобальный атрибут в «Товары → Атрибуты», указываю тип обозначений (текст, цвет, изображение) и добавляю термины со значениями
• На карточке товара меняю тип на «Вариативный товар» и на вкладке «Атрибуты» подключаю нужные глобальные атрибуты
• Включаю галку «Задействовано для вариаций» у каждого атрибута, который должен формировать отдельные комбинации
• Перехожу на вкладку «Вариации» и жму «Сгенерировать вариации из всех атрибутов»
• Для каждой сгенерированной вариации заполняю цену, артикул, остаток, вес и, если нужно, отдельное изображение

Тут кроется ловушка комбинаторики: три атрибута по 4-5 значений каждый дают 60-125 вариаций на один товар. Для магазина одежды с цветом, размером и составом ткани это легко превращается в 150+ строк, где половина комбинаций реально не продаётся, например размер S не шьётся в цвете «бордовый». Я в таких случаях удаляю лишние комбинации вручную сразу после генерации, а не оставляю их на потом, потому что заброшенные вариации с нулевым остатком путают покупателей и портят фильтры по наличию.

Значение по умолчанию и порядок атрибутов

В блоке «Атрибуты» товара можно задать значение по умолчанию, оно определяет, какая вариация выбрана при открытии карточки и какая цена показана в списке товаров до выбора покупателем. Без дефолта магазин выводит текст «Выберите вариант» вместо цены, что на практике снижает конверсию с карточки, особенно на мобильных, где покупатель не всегда долистывает до селектора. Порядок атрибутов в списке тоже влияет на восприятие: если используешь свотчи через плагин вроде Variation Swatches, первым обычно ставлю визуальный атрибут (цвет), а не размер, чтобы покупатель сначала выбирал по картинке.

Цены, остатки и вес вариаций на практике

У каждой вариации свои поля «Управление запасами», «Цена», «Вес», «Габариты», фактически это отдельный товар в базе. На эквайринге через T‑Bank для WooCommerce именно эти цены передаются в платёжный виджет, поэтому после массового изменения цен я всегда прогоняю тестовую оплату по паре вариаций с разной стоимостью, чтобы убедиться, что в кассу уходит цена конкретной вариации, а не цена родительского товара.

Вес и габариты вариаций напрямую влияют на расчёт доставки через плагин СДЭК: если вес указан только у родительского товара, а у вариаций поле пустое, виджет расчёта стоимости на фронте либо берёт нулевой вес, либо выдаёт ошибку расчёта тарифа. При настройке крупного каталога с разными фасовками, например косметика 50 мл, 100 мл, 250 мл, я всегда прохожусь чек-листом именно по весу вариаций, это самая частая причина, по которой у клиента «СДЭК не считает доставку».

Для массовых правок есть выпадающее меню «Действие с вариациями» на самой вкладке, оно умеет поднять или опустить цены на процент или фиксированную сумму сразу для всех вариаций, задать одинаковый остаток, включить или выключить управление запасами. Для каталогов от 500 SKU, которые синхронизируются из 1С, Google Таблиц или CRM вроде RemOnline, ручное редактирование карточек уже не вариант, синхронизацию делаю через WooCommerce REST API, обычно связкой с автоматизацией обмена данными между каталогом и учётной системой, чтобы остатки и цены вариаций обновлялись по расписанию, а не руками.

curl -X PUT https://site.ru/wp-json/wc/v3/products/123/variations/456 \
  -u ck_xxx:cs_xxx \
  -H "Content-Type: application/json" \
  -d '{"regular_price": "1990", "stock_quantity": 12, "weight": "0.35"}'

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

Типичные ошибки при настройке атрибутов и вариаций

• Забыли включить «Задействовано для вариаций», атрибут виден в карточке, но вариации не генерируются
• Смешали глобальный и локальный атрибут с одинаковым названием на разных товарах, фильтр в каталоге видит только глобальный и теряет часть товаров
• Оставили управление запасами включённым и на родительском товаре, и на каждой вариации, из-за чего остаток на витрине не совпадает с реальным
• Не удалили лишние комбинации после генерации, каталог зарастает вариациями с нулевым остатком, которые всё равно попадают в поиск и фильтры
• Не задали значение по умолчанию, карточка товара показывает «Выберите вариант» вместо цены прямо в блоке добавления в корзину
• Создали сотни вариаций на один товар без реальной необходимости, каждая вариация хранится как отдельная запись product_variation в базе, и при 300+ вариациях на товар вкладка «Вариации» в редакторе начинает подвисать

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

Атрибуты в фильтрах каталога и SEO-адресах

Глобальные атрибуты формируют собственные архивные страницы вида /product-attribute/cvet/krasnyi/, и эти страницы участвуют в выдаче наравне с обычными категориями, если их не закрыть от индексации. Слаги терминов лучше сразу задавать транслитом в понятном виде («krasnyi», а не автосгенерированный «%d0%ba%d1%80»), это упрощает и адрес, и восприятие ссылки в поиске.

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

Если часть комбинаций атрибутов не имеет смысла индексировать, пустые архивы без товаров, служебные термины вроде «Артикул поставщика», закрываю их через noindex в Yoast или Rank Math точечно по шаблону архива термина, чтобы не плодить дубли и не размывать вес основных категорий.

Частые вопросы

Сколько вариаций можно создать в одном товаре WooCommerce без потери производительности?

На практике комфортный потолок для стандартной админки: 100-150 вариаций на товар. При 300+ вариациях вкладка «Вариации» в редакторе товара начинает заметно тормозить при загрузке и сохранении, потому что каждая вариация хранится как отдельная запись в базе со своим набором метаполей. Если бизнес-логика требует больше комбинаций, обычно проще разбить товар на несколько отдельных карточек по одному из атрибутов.

Можно ли поменять локальный атрибут на глобальный без потери данных?

Напрямую конвертации нет, но данные не теряются: создаёшь глобальный атрибут с теми же значениями, затем на каждом товаре заново привязываешь его вместо локального и пересохраняешь вариации. На каталоге в 10-20 товаров это делается руками за полчаса, на сотнях товаров разумнее выгрузить данные через CSV-экспорт вариаций, подставить новые ID атрибутов и импортировать обратно.

Почему на сайте не появляются вариации после добавления атрибута?

Чаще всего одна из трёх причин: не включена галка «Задействовано для вариаций» у атрибута, не нажата кнопка «Сгенерировать вариации» после добавления нового значения, или товар остался с типом «Простой товар» вместо «Вариативный товар». Проверяю все три пункта по порядку, обычно проблема в первом или последнем.

Как атрибуты WooCommerce влияют на скорость загрузки каталога?

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