Цвета и размеры товара: как организовать URL вариантов и разметку ProductGroup

У товара могут быть четыре размера и несколько цветов, но это ещё не означает, что магазину нужны десятки самостоятельных страниц в поиске. Для SEO вариантов товара сначала определяют, что именно покупает посетитель, как он получает ссылку на выбранную модификацию и какие адреса магазин считает основными. Разметка ProductGroup закрепляет эту модель, а не заменяет её.

Практический результат настройки — предсказуемая карточка: ссылка открывает нужный вариант, изображение соответствует цвету, наличие относится к конкретному SKU, а корзина получает именно выбранную позицию. Поисковой системе передают ту же структуру семейства. Ни количество URL, ни наличие разметки сами по себе не гарантируют индексацию каждой модификации.

1. Отделите варианты одного товара от самостоятельных товаров

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

В определении Schema.org ProductGroup представляет товары, различающиеся определёнными характеристиками. Сама группа не является отдельной продаваемой позицией. Поэтому абстрактную «футболку всех размеров» не следует добавлять в корзину как пятый товар рядом с четырьмя реальными SKU.

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

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

2. Составьте реестр вариантов и устойчивых идентификаторов

Рабочий реестр связывает группу, SKU, характеристики, прямой URL и статус продажи. Название удобно покупателю, но плохо подходит на роль технического ключа: редактор может изменить его ради ясности. Идентификатор группы должен переживать такие правки, а идентификатор варианта — однозначно вести к конкретной складской позиции.

Ниже учебный пример магазина на example.com. Семейство basic-tee включает два цвета и два размера: 2 × 2 = 4 реально существующих варианта. Все стоят 29 EUR; серый L временно отсутствует, заказы на него магазин не принимает. Это условные данные для проверки схемы, а не сведения о действующем магазине.

SKU	Цвет	Размер	Параметры прямой ссылки	Состояние
basic-tee-blue-m	Синий	M	color=blue&size=M	Можно купить
basic-tee-blue-l	Синий	L	color=blue&size=L	Можно купить
basic-tee-gray-m	Серый	M	color=gray&size=M	Можно купить
basic-tee-gray-l	Серый	L	color=gray&size=L	Нет в наличии

Матрица не должна автоматически достраивать все математически возможные сочетания. Если производитель выпускает синий цвет только в M, синий L не появляется в каталоге из-за пересечения двух списков. У отсутствующего сочетания и временно закончившегося реального SKU разный смысл.

3. Выберите одну понятную модель URL

В одностраничной модели покупатель выбирает характеристики внутри одной карточки. Базовый адрес нашего примера — https://example.com/products/basic-tee/; параметры сохраняют конкретный выбор. Переключение может происходить без полной перезагрузки, но ссылка остаётся воспроизводимой.

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

Рекомендации Google по адресам интернет-магазинов помогают согласовать варианты URL, внутренние ссылки и canonical. Практически полезно заранее записать, какие параметры определяют товар, а какие лишь отслеживают рекламный переход. Метка кампании не должна создавать новый SKU или новое семейство.

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

В смешанной архитектуре полезно принимать решения по уровням. Допустим, цвет имеет самостоятельную страницу, а размер только меняет выбранный SKU внутри неё. Тогда отдельно обсуждают две страницы цветов и отдельно параметры размеров. Необязательно создавать четыре равноценных посадочных адреса только потому, что в учёте есть четыре позиции. Схему можно нарисовать в реестре: основной адрес страницы, доступные состояния, ожидаемый canonical каждого состояния.

4. Проверьте прямую ссылку без прежней сессии

Откройте https://example.com/products/basic-tee/?color=blue&size=M в новом сеансе браузера. Должны сразу определиться синий цвет и размер M. Если после копирования ссылки открывается ранее выбранный серый L, состояние хранится только в браузере и URL не выполняет свою задачу.

Проверка продолжается после загрузки JavaScript. Иногда сервер показывает правильный вариант, а клиентский код затем подставляет сохранённый выбор. Бывает обратная ситуация: переключатели выглядят правильно, но запрос добавления в корзину содержит SKU варианта по умолчанию. Поэтому визуальной отметки на кнопке размера недостаточно.

Для своего магазина сравните четыре результата: параметры URL, активные переключатели, карточку с изображением и наличием, позицию в корзине. Проверку добавления проводите без оформления реальной покупки. После обновления страницы и перехода назад выбор должен оставаться объяснимым и соответствовать адресу.

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

5. Настройте canonical с учётом выбранной архитектуры

Документация Google по вариантам различает две модели. Для одной страницы у группы должен быть один canonical, обычно базовый URL без выбранного варианта. Для нескольких самостоятельных страниц требование единственного canonical всей группы не применяется: варианты распределены между равнозначными страницами.

В нашем одностраничном примере базовая карточка и четыре адреса с параметрами содержат одинаковое указание:

<link rel="canonical" href="https://example.com/products/basic-tee/">

Этот элемент помещают в head страницы. Он не должен переключаться на текущий размер после каждого клика. При этом прямые ссылки на варианты продолжают работать: canonical не является редиректом и не отменяет выбранные параметры для покупателя.

Если магазин выбрал отдельные полноценные страницы цветов, не объединяйте их автоматически canonical на первый цвет. Для предназначенных к индексации самостоятельных страниц обычно задают собственные canonical, отдельно разбираясь с дублями внутри каждой. В правилах канонизации Google это сигнал предпочтения, а не гарантия окончательного выбора поисковой системы.

Согласуйте с этим sitemap: в нашей модели туда входит базовая карточка, а не четыре альтернативы с параметрами. Закрывать все параметры в robots.txt как дополнительную «защиту от дублей» без анализа нельзя: поисковому роботу может потребоваться открыть вариант.

6. Разделите свойства семейства и конкретного SKU

ProductGroup описывает семейство, hasVariant содержит варианты Product, а variesBy перечисляет характеристики различий. В примере это полные адреса свойств https://schema.org/color и https://schema.org/size. Значение productGroupID объединяет четыре SKU в одну группу.

Общие свойства указывают у группы только тогда, когда они действительно общие. Цвет и размер размещают у соответствующих вариантов; изображение синей футболки не описывает серую. Название варианта должно быть конкретнее названия семейства. Собственные SKU нельзя заменить одним общим артикулом basic-tee.

Каждый продаваемый вариант сохраняет данные Product и Offer согласно требованиям к merchant listing. Объединение в группу не освобождает от описания самого предложения. В этой статье цена нужна лишь для согласованного примера; её получение из учётной системы остаётся отдельной задачей.

Для многостраничной модели каждая страница должна содержать самодостаточное описание размещённых на ней сущностей. Google также ограничивает использование ProductGroup.url одностраничной моделью. Поэтому приведённый ниже объект нельзя механически размножить по самостоятельным страницам, сохранив базовый URL группы и прежнюю схему canonical.

7. Соберите согласованный пример ProductGroup

Ниже полный учебный JSON-LD для выбранной одностраничной схемы. Четыре варианта доступны через переключатели карточки; разметка перечисляет их одновременно. Параметры у Offer.url открывают конкретную комбинацию. Для отсутствующего серого L показано соответствующее наличие, а интерфейс не принимает заказ.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "@id": "https://example.com/products/basic-tee/#group",
  "name": "Футболка Basic",
  "url": "https://example.com/products/basic-tee/",
  "productGroupID": "basic-tee",
  "variesBy": ["https://schema.org/color", "https://schema.org/size"],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Футболка Basic, синяя, M",
      "sku": "basic-tee-blue-m",
      "color": "синий",
      "size": "M",
      "image": "https://example.com/images/basic-tee-blue.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/basic-tee/?color=blue&size=M",
        "price": 29.00,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Футболка Basic, синяя, L",
      "sku": "basic-tee-blue-l",
      "color": "синий",
      "size": "L",
      "image": "https://example.com/images/basic-tee-blue.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/basic-tee/?color=blue&size=L",
        "price": 29.00,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Футболка Basic, серая, M",
      "sku": "basic-tee-gray-m",
      "color": "серый",
      "size": "M",
      "image": "https://example.com/images/basic-tee-gray.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/basic-tee/?color=gray&size=M",
        "price": 29.00,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Футболка Basic, серая, L",
      "sku": "basic-tee-gray-l",
      "color": "серый",
      "size": "L",
      "image": "https://example.com/images/basic-tee-gray.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/basic-tee/?color=gray&size=L",
        "price": 29.00,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/OutOfStock"
      }
    }
  ]
}
</script>

Код показан как текст, а не как действующая разметка этой статьи. Условные URL необходимо заменить реальными адресами и изображениями магазина. У каждого варианта есть собственный SKU; группа не содержит предложения купить абстрактный товар. Отзывы, оценки и сведения о бренде намеренно не добавлены без исходных данных.

8. Проверьте идентификаторы и источник генерации

SKU — внутренний идентификатор магазина. GTIN — другой идентификатор, его нельзя получить, дописав цифры к артикулу. Если производитель присвоил вариантам GTIN, сопоставьте каждый код с точной модификацией по надёжным товарным данным. Правила Merchant Center для GTIN прямо запрещают угадывать значения. Поэтому в учебном примере GTIN отсутствует.

Назначьте один источник генерации семейства: например, модуль каталога, который знает связи вариантов. После подключения нового SEO-плагина проверьте, не появились ли одновременно старая одиночная Product и новая ProductGroup с противоречащими SKU. Два блока JSON-LD сами по себе не ошибка; проблема — две несовместимые версии одного товара.

Сравните исходный HTML и DOM после выполнения JavaScript. В выбранной реализации полный набор вариантов формируется сервером и остаётся тем же при переключении цвета; данные обновляются при изменении каталога. Если клиентский код удаляет группу и оставляет один случайный SKU, нужно согласовать генераторы, а не вручную чинить результат на одной странице.

Стабильность проверяют и после редактирования: новое название не меняет SKU, перенос категории не создаёт другую группу, а добавление размера не переписывает идентификаторы существующих вариантов.

9. Согласуйте каталог, ссылки и товарный фид

В карточке посетитель должен видеть доступные варианты и понимать, какие комбинации существуют. Для переходов между самостоятельными страницами используйте реальные ссылки; в одностраничной модели проверьте, что выбранное состояние можно скопировать и открыть отдельно. Ссылка из рекламного объявления на синий M должна вести к синему M, даже если в каталоге первым показывается серый цвет.

Если магазин передаёт данные в Merchant Center, сверяйте связь между группой на сайте и группой в выгрузке. Атрибут item_group_id объединяет варианты при отдельных идентификаторах позиций. В нашем внутреннем соглашении это basic-tee, а четыре SKU соответствуют четырём записям. Такая таблица сопоставления не заменяет полную спецификацию фида.

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

10. Различайте отсутствие остатка и исчезновение варианта

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

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

Проведите учебное изменение на тестовом каталоге: серый L снова появился. Проверьте карточку по прямой ссылке, состояние переключателя, разрешение добавления в корзину и новый объект Offer в разметке. Затем повторите обратное изменение. Так обнаруживается частый дефект, когда обновляется текст наличия, но кешированный блок семейства остаётся прежним.

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

Rich Results Test используют для проверки распознаваемой разметки и диагностических сообщений. Он не подтверждает, что складской SKU корректно добавляется в корзину. Для своего опубликованного URL дополнительно посмотрите, что получает Google, через инструмент проверки URL в Search Console.

Для четырёх учебных вариантов составьте матрицу: каждый открывают в новом сеансе, после обновления страницы и после перехода назад с другого варианта. Получается 4 × 3 = 12 случаев. Это небольшой согласованный набор проверок, а не доказательство исправности всех браузеров и всего ассортимента.

Что проверяем	Условие приёмки
Прямая ссылка	Цвет, размер и SKU соответствуют реестру
Изображение и наличие	Относятся к выбранной комбинации после загрузки страницы
Корзина	Получает точный SKU; отсутствующий серый L купить нельзя
Canonical	Во всех четырёх состояниях указывает на базовую карточку
JSON-LD	Четыре уникальных SKU, одна группа, согласованные адреса и характеристики

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

При несовпадении локализуйте первый неверный слой. Если прямой URL уже открывает другой размер, сначала исправляют разбор параметров. Если интерфейс верен, но корзина получает другой артикул, проверяют связь переключателя с отправляемой позицией. Если оба действия правильны, а JSON-LD описывает другой SKU, проверяют генератор и кеш разметки. Такой порядок сохраняет причинную связь: переустановка SEO-модуля не исправит ошибочное сопоставление размеров в товарной базе.

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

12. Принимайте результат по согласованной модели

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

Индексация модификаций товара оценивается относительно выбранной архитектуры. В одностраничном примере ожидание четырёх самостоятельных результатов поиска противоречит общему canonical. В многостраничной модели доступность и самостоятельность страниц тоже не означают обязательную индексацию каждой. Правила структурированных данных Google отдельно предупреждают: даже корректная разметка не гарантирует расширенное представление.

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

Для внешнего контроля HTTP-доступности страниц рассмотрите SiteGuard. Проверку вариантов и товарной разметки выполняйте отдельно по согласованной матрице.