Как устроить категории, карточки и фильтры интернет-магазина для поиска

Короткий ответ: из каких страниц складывается SEO-каталог

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

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

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

Начните с ролей страниц, а не с дерева разделов

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

До разработки я собираю рабочую карту из шести полей. Она связывает запрос бизнеса с задачей SEO-специалиста, контентной команды и разработки:

1. Текущая точка. на каких реальных URL проявляется ограничение и как оно влияет на выбор товара.
2. Задача человека. что он пытается выбрать или уточнить.
3. Группа спроса. какие формулировки относятся к одной задаче.
4. Ассортимент. есть ли достаточно подходящих товаров сейчас и будет ли выбор сохраняться.
5. Тип страницы. категория, подкатегория, индексируемая подборка или карточка.
6. Владелец и приемка. кто отвечает за данные и реализацию, по каким URL и в какую дату проверяется результат.

Решение принимают по совокупности спроса, ассортимента и пользы, а не по тому, может ли CMS создать URL.

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

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

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

Google объясняет структуру интернет-магазина через связи между страницами: меню ведет к категориям, категории к подкатегориям, а те к карточкам. Если товары доступны только через внутренний поиск и не имеют обычных ссылок из каталога, Googlebot может их не обнаружить. Для переходов рекомендуются crawlable-ссылки <a href>, а Sitemap или товарный фид дополняют, но не заменяют навигацию (рекомендации Google по структуре магазина).

Что проверить на странице категории

• Название и H1 однозначно описывают класс товаров.
• Товарная сетка доступна без ввода запроса во внутренний поиск.
• Карточки в списке ведут на постоянные URL товаров через обычные ссылки.
• Фильтры используют характеристики, которые заполнены в товарных данных, а не собираются вручную в каждом шаблоне.
• Покупатель видит важные отличия: тип, назначение, диапазон цены, наличие, совместимость или другие реальные критерии.
• Пустая категория не маскируется под полезную страницу.
• Текст, если он нужен, объясняет выбор и ограничения, а не повторяет название категории разными словами.

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

Карточка отвечает за конкретный товар

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

Базовый набор обычно включает:

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

Структурированные данные Product могут помочь Google понять товар и сделать страницу кандидатом на расширенное представление, но разметка не гарантирует такой результат и должна совпадать с видимым содержанием (документация Google по Product, общие правила structured data). Сначала исправляют страницу и данные, затем размечают их. JSON-LD не заменяет отсутствующую цену, характеристику или статус наличия для пользователя.

Одинаковые описания поставщика не решаются случайной генерацией текста

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

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

Какие фильтры превращать в посадочные страницы

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

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

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

Матрица решения по фильтру

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

Для комбинации без результатов, повторяющихся фильтров или невозможного сочетания Google рекомендует возвращать 404 на том же URL и не перенаправлять посетителя на общую страницу ошибки. Это правило относится к фасетным URL, которые робот может обходить; для конкретной реализации его проверяют на исходном адресе (справка Google по фасетной навигации).

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

Не применяйте одно правило ко всем фильтрам

Универсальная схема все параметры закрыть в robots.txt, все поставить noindex или все canonical на категорию может сломать полезные страницы или оставить обход неуправляемым. Google разделяет правила обхода в robots.txt и директивы индексирования в robots meta: чтобы робот увидел noindex, страница должна оставаться доступной для обхода. В Яндексе правила robots.txt также управляют доступом робота к URL, а не заменяют решение об основной странице (справка Яндекса по robots.txt).

• robots.txt управляет обходом, но не подтверждает, что поисковик увидит noindex внутри закрытого URL.
• noindex относится к индексированию доступной страницы, а не к выбору главного URL среди дублей.
• canonical помогает указать предпочтительный адрес среди одинаковых или близких вариантов, но не должен склеивать самостоятельные полезные подборки.
• Clean-param — директива Яндекса для параметров, которые не меняют содержание страницы, например меток отслеживания или идентификаторов сессии. Ее нельзя применять к фасетным параметрам, которые меняют набор товаров (справка Яндекса по Clean-param).

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

Дубли каталога начинаются с инвентаризации URL

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

Google рекомендует согласовывать canonical-сигналы и использовать один основной URL для консолидации дублей; robots.txt не служит способом канонизации (документация Google по canonical). Яндекс отдельно показывает дубли в Вебмастере и описывает ситуации с параметрами, зеркальными адресами и выбранным основным URL (справка Яндекса о дублях).

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

Пагинация и бесконечная прокрутка должны оставлять путь роботу

Кнопка «Показать еще» удобна человеку, но поисковый робот не обязан нажимать ее. Google обычно обнаруживает новые страницы через URL в href и рекомендует отдельные адреса для частей пагинации с последовательными ссылками между ними. Каждая страница пагинации должна иметь собственный canonical, а не указывать на первую только потому, что относится к одной категории (рекомендации Google по пагинации).

Бесконечная прокрутка может остаться интерфейсным слоем, если за ней существует доступная последовательность URL:

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

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

Как работать с вариантами одного товара

Цвет, размер, объем и комплектация могут быть переключателями внутри одной карточки или самостоятельными URL. Универсального правила «каждому варианту отдельная страница» нет.

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

Google поддерживает описание группы вариантов через ProductGroup, hasVariant, variesBy и productGroupID как для одно-, так и для многостраничных моделей (справка Google о вариантах товара). Если сайт использует эту разметку, каждый вариант должен открываться по прямому URL с предварительно выбранным состоянием. В одностраничной модели у группы один канонический URL, а варианты могут выбираться параметрами. В многостраничной модели равнозначные страницы вариантов имеют собственные canonical и полную разметку объектов на каждой странице. Разметка должна отражать реальную модель сайта и не исправит противоречие между URL, видимым названием, ценой и наличием.

Для приемки вариантов проверьте:

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

Что делать с отсутствующими и снятыми товарами

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

Товар временно отсутствует

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

Товар снят, но есть точная замена

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

Товар снят без эквивалента

Если товар удален навсегда и близкой замены нет, URL возвращает 404 или 410, а внутренние ссылки и Sitemap обновляют. Если есть ясная равноценная замена, используют прямой 301 на нее. Редирект на нерелевантную категорию может быть классифицирован Google как soft 404 (справка Google по ошибкам сканирования).

Яндекс относит к возможным причинам исключения страницы дубли, отсутствие видимого полезного содержания и несоответствие задаче пользователя; при этом фиксированного лимита «полезных страниц» нет (справка о малоценных и маловостребованных страницах). Поэтому задача не в сохранении любого URL, а в ясном статусе и самостоятельной пользе страницы.

Структурированные данные и фиды дополняют каталог

У интернет-магазина есть несколько машинных представлений: HTML-страницы, structured data, Sitemap и товарные фиды. Они должны описывать одну реальность, но выполняют разные функции.

• HTML дает покупателю и роботу видимый ответ и навигацию.
• Product и ProductGroup помогают описать товар и варианты.
• Sitemap сообщает о канонических URL, которые сайт считает важными.
• Товарный фид передает площадке структурированные данные по ее формату.

Фид не заменяет crawlable-ссылки внутри сайта, а structured data не создает отсутствующую карточку. При расхождении цены, наличия или URL поисковой системе и покупателю приходится выбирать между противоречивыми версиями.

Как оформить техническое задание на каталог

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

Приемка не заканчивается после публикации шаблона. Команда должна проверить реальные категории, пустые выдачи, снятые товары, варианты и данные в Вебмастере.

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

Как измерять результат после запуска

Сначала проверяют, выполняется ли архитектура, и только затем оценивают трафик.

Технические наблюдения

• важные страницы доступны по внутренним ссылкам;
• робот получает ожидаемые HTTP-статусы и содержимое;
• в Sitemap нет технических и неканонических URL;
• поисковые системы выбирают утвержденные canonical;
• не растет число обходов бесполезных параметров;
• новые карточки обнаруживаются без ручной отправки каждой страницы.

Поисковые наблюдения

• какие категории, подборки и карточки получают показы;
• соответствует ли запрос роли страницы;
• не конкурируют ли несколько URL по одной задаче;
• какие исключения показывают Яндекс Вебмастер и Google Search Console;
• появляются ли полезные страницы среди «малоценной», дублирующей или неканонической группы.

Бизнес-наблюдения

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

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

Частые ошибки

• Строить категории только по структуре учетной системы.
• Создавать посадочную под каждый доступный фильтр.
• Считать длинный текст обязательным признаком полезной категории.
• Оставлять товары доступными только через внутренний поиск или кнопку без href.
• Указывать canonical всех страниц пагинации на первую.
• Закрывать URL в robots.txt и одновременно ожидать, что робот прочитает noindex.
• Перенаправлять любой снятый товар на родительскую категорию.
• Размечать Product, когда видимые цена, наличие и вариант противоречат данным.
• Открывать параметры для обхода без единого порядка и нормализации URL.
• Принимать шаблон на одной идеальной странице, не проверяя пограничные состояния.

Чек-лист перед публикацией каталога

1. Для каждой категории и индексируемой подборки записана самостоятельная задача.
2. Коммерческий и информационный спрос не смешан в одной случайной странице.
3. Товары доступны через crawlable-ссылки из каталога.
4. Для фильтров есть явный список индексируемых и технических сочетаний.
5. Параметры и порядок их применения нормализованы.
6. Пустые, повторяющиеся и невозможные сочетания возвращают 404 на исходном URL без редиректа на общую ошибку.
7. Пагинация имеет отдельные URL и последовательные ссылки.
8. Карточки показывают реальную цену, наличие, характеристики и варианты.
9. Canonical, внутренние ссылки и Sitemap не противоречат друг другу.
10. Сценарии временного отсутствия, снятия и замены товара разделены.
11. Structured data совпадает с видимым содержанием.
12. Приемка проведена на реальных и пограничных URL.
13. После запуска проверены Вебмастер и Search Console.

Что делать дальше

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

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

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