SEO-структура каталога запчастей: категории, модели и артикулы

SEO-структура каталога запчастей должна отвечать на три разных запроса. Один покупатель ищет тип детали, второй знает модель техники, третий вводит точный артикул. Если свести их на одну страницу, она получится слишком общей. Если создать отдельный URL под каждую комбинацию категории, бренда, модели и характеристики, сайт получит тысячи дублей и пустых листингов.

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

Какие страницы нужны каталогу запчастей

У каталога есть четыре основных поисковых сценария:

1. По типу детали: «гидронасос для экскаватора», «фильтр трансмиссии».
2. По модели техники: «запчасти Komatsu PC200», «детали для двигателя ЯМЗ-238».
3. По артикулу: точный номер производителя, заменённый номер или аналог.
4. По сочетанию параметров: категория плюс бренд, размер, применяемость или другой признак, который влияет на выбор.

Каждому сценарию нужна своя посадочная страница только при наличии отдельного спроса и достаточного ассортимента. Сам факт, что CMS умеет собрать комбинацию, не делает её полезной для поиска.

Эта карта не требует четырёх независимых баз товаров. Одна карточка может быть доступна из категории, страницы модели и результатов фильтра. В индексе при этом остаётся один канонический URL карточки.

Как собрать дерево каталога до проектирования URL

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

После этого соберите дерево из трёх независимых сущностей:

• товарная классификация: узел → тип детали → подтип;
• применяемость: производитель техники → серия → модель → модификация;
• идентификаторы: бренд детали → основной артикул → старые номера и аналоги.

Не вкладывайте все сущности друг в друга. Адрес вида /zapchasti/ekskavatory/komatsu/pc200/gidravlika/nasosy/brand/12345/ привязывает карточку к одному пути. Товар подходит нескольким моделям или переезжает в другую категорию, и адрес приходится менять.

Для большинства каталогов устойчивее короткая схема:

• /zapchasti/ — вход в каталог;
• /zapchasti/gidronasosy/ — категория;
• /zapchasti/komatsu/pc200/ — совместимость с моделью;
• /zapchasti/brand-12345/ — карточка по стабильному идентификатору.

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

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

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

Проверьте каждую категорию по пяти вопросам:

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

Если ответы отрицательные, оставьте группу в интерфейсе или объедините её с родительской категорией. Поисковому индексу не нужен отдельный URL ради одного пункта меню.

Подробную структуру самой карточки я разобрал в статье о карточке промышленного оборудования.

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

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

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

Отдельная страница модели оправдана, если выполняются три условия:

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

Если список совместимости получен из ненадёжной таблицы, лучше не обещать точный подбор. Покажите форму проверки и передавайте менеджеру модель, артикул и URL товара.

Артикул определяет товар, но не всегда определяет URL

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

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

Карточка по артикулу должна показывать:

• бренд и точный номер;
• название детали без поискового перечисления через запятую;
• совместимые модели и ограничения;
• заменённые номера и аналоги с пояснением статуса;
• характеристики, фото и документы;
• наличие, срок поставки или честный способ его уточнить.

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

Какие фильтры открывать для поиска

Фильтр решает задачу пользователя в интерфейсе. SEO-страница решает отдельный поисковый запрос. Иногда это один и тот же URL, но чаще фильтр создаёт служебные комбинации: сортировку, диапазон цены, наличие, вид таблицы, номер страницы, сессионные метки.

Google отдельно предупреждает, что фасетная навигация способна создать почти бесконечное число адресов и замедлить обнаружение полезных страниц [1]. Поэтому список индексируемых комбинаций лучше задавать правилами, а не открывать весь механизм фильтрации.

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

rel="canonical" не стоит использовать как единственный заслон. Google объясняет, что обработка canonical занимает время и не гарантирует немедленное сокращение обхода фасетных URL [1]. Сначала ограничьте генерацию ссылок и число доступных комбинаций, затем настройте каноникализацию дублей.

Как связать URL, canonical, Sitemap и внутренние ссылки

Выберите один формат для регистра, дефисов и завершающего слеша. Один товар и одна категория должны иметь по одному основному адресу. Google рекомендует последовательную структуру URL, самоканоникал для самостоятельных страниц и включение канонических адресов в Sitemap [2].

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

Поисковый робот должен дойти до важных страниц по обычным ссылкам. Яндекс указывает, что документы без входящих ссылок могут остаться неизвестными роботу [3]. Поэтому карта связей выглядит так:

• главная и меню ведут на крупные разделы;
• раздел ведёт на категории и востребованные модели;
• категории и модели ведут на карточки;
• карточка возвращает пользователя к категории, модели, аналогу и документу;
• статьи объясняют выбор и ссылаются на релевантные разделы каталога.

Хлебные крошки должны отражать понятную товарную иерархию. Они не обязаны перечислять все пути, по которым можно найти товар.

Порядок внедрения без массовой генерации ошибок

Не открывайте новый каталог целиком за один релиз. Возьмите одну товарную группу и пройдите восемь шагов:

1. Соберите запросы и обращения для категории, моделей и артикулов.
2. Нормализуйте товарные данные и таблицу совместимости.
3. Назначьте основной тип страницы каждому кластеру запросов.
4. Зафиксируйте URL и правила для дублей.
5. Создайте категории, страницы моделей и карточки на ограниченной выборке.
6. Проверьте коды ответа, canonical, Sitemap и внутренние ссылки.
7. Посмотрите в Вебмастере и Search Console, какие URL робот обходит и индексирует.
8. Сверьте органические обращения с CRM: категория, модель, артикул и результат обработки.

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

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

Быстрая проверка готовой схемы

Перед передачей каталога в разработку ответьте на десять вопросов:

• У каждой категории есть отдельный спрос и достаточный ассортимент?
• Страницы моделей основаны на проверенной совместимости?
• У товара один основной URL независимо от числа путей входа?
• Старые и альтернативные артикулы не создают копии карточки?
• Индексируемые фильтры перечислены явно?
• Сортировки, поиск и служебные параметры исключены из Sitemap?
• Пустые комбинации не превращаются в тысячи страниц с ответом 200?
• Canonical совпадает с выбранным основным URL?
• До каждой важной страницы можно дойти по обычной HTML-ссылке?
• Аналитика передаёт в заявку категорию, модель, артикул и посадочную страницу?

Если на несколько вопросов нет ответа, проблема обычно находится не в метатегах, а в модели данных или правилах генерации страниц. Быстрая проверка поможет увидеть часть технических ограничений: запустите предварительный аудит готовности сайта к AI-поиску. Он проверяет доступность главной страницы, robots.txt, Sitemap, заголовки и базовые признаки доверия. Для оценки всего каталога всё равно понадобятся выгрузка URL, данные Вебмастера и Search Console, логи и выборка заявок.

Источники

1. Google: управление обходом URL фасетной навигации.
2. Google: рекомендации по структуре URL для интернет-магазинов.
3. Яндекс Вебмастер: рекомендации по структуре сайта.
4. Google: как помочь поиску понять структуру интернет-магазина.
5. Яндекс Вебмастер: атрибут rel=canonical.