SEO для интернет-магазина: особенности, которых нет у обычных сайтов

Что вы получите из статьи:

• Какие 4 сущности отличают SEO магазина от SEO обычного сайта - и почему у каждой свои формальные требования
• Что обязано быть в разметке карточки, чтобы Яндекс показал цену в выдаче
• Откуда в индексе берутся тысячи страниц фильтров и чем их закрывать - Clean-param, canonical или robots.txt
• Что Яндекс требует от товарного фида и когда магазин отключают от Поиска
• Что делать с карточкой товара, которого нет в наличии, чтобы не потерять позиции

Из практики: применить можно за один вечер, экономит предотвращает отключение от товарного Поиска Яндекса из-за ошибок в фиде и разметке.

У карточки товара в схеме Product три обязательных поля - name, brand, image - плюс блок offers, а у самого offers (Offer) - ещё три обязательных поля: наличие, цена и валюта. Если больше 25% товаров в источнике данных - неважно, фид это или карточки на сайте - содержат ошибки, Яндекс может полностью отключить источник от товарного Поиска. Рекомендованная длина названия товара в фиде - 50-60 символов, жёсткий максимум - 150. Само продвижение интернет-магазина у нас стоит 45 000 ₽ в месяц на тарифе «Базовый» (каталог до 1 000 товаров) и 85 000 ₽ на «Стандарте» (от 1 000 товаров и несколько регионов).

Общий состав работ, бюджет и сроки первых заявок с органики разобраны в базовой статье про SEO-продвижение интернет-магазина. Здесь - особенности SEO именно для интернет-магазина в 2026 году: то, чем e-commerce отличается от обычного сайта. Карточка с ценой, страницы фильтров, товарный фид и остатки - у каждой из этих четырёх сущностей свои формальные требования Яндекса и Google, с конкретными числами.

Чем SEO интернет-магазина отличается от SEO обычного сайта?

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

У визитки SEO - это структура, тексты, скорость и ссылки. У магазина к этому добавляется целый пласт работы, которого нет у обычного сайта: карточка должна нести машиночитаемую разметку цены и наличия, потому что именно по ней Яндекс решает, показывать ли сниппет с ценой в выдаче. Фильтры («диван синий угловой размер L») на типовом каталоге в 5 000 SKU способны сгенерировать десятки тысяч комбинаций URL - и большая часть из них попадает в индекс как дубли, если это не остановить. Отдельно от сайта существует товарный фид - файл в формате YML, который Яндекс проверяет по собственным правилам и может отключить от Поиска целиком. И наконец, у магазина есть остатки: товар, который сегодня есть, а завтра закончился, - и то, что вы сделаете с его карточкой, либо сохранит позиции, либо уронит их.

Что должно быть в карточке, чтобы Яндекс показал цену прямо в выдаче?

Коротко: у схемы Product обязательны поля name, brand, image и блок offers. description в таблице Яндекса помечено необязательным, но заполнять его стоит всегда - это единственное поле схемы, куда попадает человеческое описание товара, а не служебные данные. У Offer внутри блока обязательны availability, price (или lowPrice) и priceCurrency. Без этого набора Яндекс не формирует расширенный сниппет с ценой и фото прямо в результатах поиска, и покупатель видит вашу карточку голой ссылкой рядом с конкурентами, у которых цена и фото уже показаны.

Обязательность полей описана в справке Яндекс Товаров по микроданным для сниппетов: у Product обязательны name, brand, image, у Offer (или AggregateOffer) - наличие, цена и код валюты. А в разделе поддержки Яндекс.Вебмастера про разметку цен товаров прямо сказано, что для оформления сниппета используются минимум две схемы одновременно - Product и Offer (или AggregateOffer) - а не одна общая. Формируется такая разметка не мгновенно: по данным того же раздела поддержки, «разметка формируется в течение двух недель» после того, как страницу обошёл робот и она прошла проверку.

Отдельно стоит развести код валюты. В микроразметке используется стандартный ISO-код RUB, а в товарном фиде, о котором ниже, - собственное обозначение Яндекса RUR. По нашей практике на проектах именно эта путаница - частая причина, по которой карточка технически валидна, но что-то в сниппете отображается не так, как ожидалось.

Почему микроразметка не поднимает позиции - и зачем тогда она нужна?

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

Формулировка справки Яндекс.Вебмастера по вопросам о семантической разметке звучит однозначно: «напрямую семантическая разметка не влияет на ранжирование». Это не новый тезис - ещё в 2017 году агентство «Ашманов и партнеры» приходило к тому же выводу в собственном разборе микроразметки для интернет-магазинов: «Микроразметка не влияет напрямую на ранжирование и место в выдаче». То есть представление о разметке как об инструменте роста позиций живёт в SEO-мифологии годами, хотя источник давно и прямо его опровергает.

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

Что чаще всего ломает разметку товара?

Коротко: типичные причины провала валидатора - отсутствующий атрибут itemscope, ссылка внутри content тега meta там, где должен быть текст, и конфликт между микроразметкой, которая уже стоит в коробочном шаблоне CMS, и добавленным поверх неё вторым блоком JSON-LD. Все три ошибки чинятся за час, если знать, где смотреть, но без проверки валидатором остаются незаметными месяцами.

Официальная документация валидатора микроразметки Яндекса перечисляет конкретные типы ошибок: пропущенный itemscope у корневого элемента, использование itemprop вне области действия своего itemscope. Отдельно - ситуацию, когда «в свойстве content тега meta не может содержаться ссылка» (частая ошибка, когда разработчик передаёт URL изображения через meta[content], вместо того чтобы использовать <img> с itemprop="image"). В разборе на Хабре разработчик Пётр Гришечкин отдельно разбирает этот случай: «если CMS генерирует Microdata в HTML, а вы добавили JSON-LD, поисковик видит два конфликтующих описания» - и рекомендует решение через отключение одной из двух разметок в шаблоне или плагине, а не через попытку их совместить.

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

Как уникализировать описания, если товаров пять тысяч?

Коротко: важнее внутренняя уникальность в рамках вашего каталога, чем внешняя уникальность против всего рунета - блок доставки, гарантий и характеристик может повторяться на всех карточках, а сам текст о товаре не должен быть идентичен другой карточке этого же магазина. По требованиям Яндекс Товаров к описанию: минимум 70 символов, оптимум - 400-800, максимум - 3 000, без ключевых слов, без цены и без ссылок внутри текста.

В разборе на Хабре SEO-специалист Евгений Захаренко прямо называет это проблемой, а не мелочью: «обширное меню, содержащее множество ссылок, а также описания условий доставки, оплаты, обмена и возврата, часто дублируются на всех страницах карточек товаров». Решение, которое он предлагает, - уникализировать саму сервисную информацию, вплетая название конкретного товара в разные части описания, а не оставлять эти блоки без изменений: тогда карточки различаются не только фотографией. То есть уникальным должен быть не только текст о товаре, но и то, как сервисные блоки на него ссылаются: карточка синего дивана и карточка того же дивана в зелёном цвете не должны совпадать текстуально ни в описании, ни в подводке к доставке и гарантии.

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

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

Откуда в индексе берутся тысячи страниц фильтров?

Коротко: каждая комбинация фильтров - это отдельный URL, и робот обходит их все, если не сказать ему обратное. По формулировке Google, «поисковые роботы не могут без сканирования определить, окажется ли URL полезным. В результате им приходится обрабатывать большое количество URL фасетной навигации, прежде чем становится понятно, что это ненужные URL» (facet-навигация - те самые фильтры по цвету, размеру, бренду).

Проблему усугубляет порядок параметров: /catalog/zoloto/fianity/ и /catalog/fianity/zoloto/ для робота - два разных адреса с идентичным содержимым, даже если для человека это один и тот же результат фильтрации. Яндекс формально определяет проблему так: «если GET-параметр не меняет контент страницы, то этот параметр называют незначащим» - и типовой пример незначащего параметра - UTM-метка, а не только параметр фильтра. По данным того же блога Яндекс.Вебмастера, диагностика подобных дублей приходит в раздел «Диагностика» с задержкой в 2-3 дня - то есть даже после исправления шаблона старые сигналы о дублях будут висеть в интерфейсе ещё несколько дней, и это не повод для паники.

В интерфейсе Яндекс.Вебмастера такие страницы получают статусы «Страница признана малоценной или маловостребованной» и «Страница дублирует содержание другой страницы» - оба видны в разделе «Страницы в поиске → Исключённые». По официальному руководству Google, краулинговый бюджет стоит держать в голове на двух масштабах: от 10 000 страниц - если контент на сайте меняется очень часто (ежедневно), и от 1 000 000 страниц - если контент меняется умеренно часто (примерно раз в неделю). У активного каталога с ежедневным обновлением остатков и цен порог применим уже на 10-тысячной отметке, а не только на миллионной.

Какие фильтры открывать в индекс, а какие закрывать?

Коротко: критерий Яндекса простой - если GET-параметр меняет содержание страницы, перед вами не дубль, и такую страницу можно открывать; если не меняет (сортировка, сессия, id пользователя) - закрывать. Дальше решение зависит от того, есть ли по конкретной комбинации фильтров реальный спрос в поиске, а идеологические споры тут вторичны.

Часть специалистов настаивает на закрытии всех страниц фильтров без исключения - в обсуждении на SearchEngines Антоний Казанский формулирует эту позицию жёстко: «эти страницы всегда нужно запрещать и для индексации, и для обхода... никакие уникальные мета там ловить не нужно, и уж тем более тексты». Там же участник форума под ником Lazy Badger возражает: «закрывать страницы фильтров от индексации - идеологически неправильно, если на них есть запросы с ненулевым спросом», и предлагает открывать конкретную комбинацию именно тогда, когда по ней есть спрос, а не закрывать категорию целиком по умолчанию. Спор решает частотность, а не идеология: есть спрос по конкретной комбинации («кроссовки adidas 42 размер») - делаем полноценную посадочную страницу со своим URL, H1 и описанием; спроса нет - вообще не создаём на неё ссылку.

У Google в текущей документации по управлению краулингом фасетной навигации для этого есть техническая опора: если краулинг фильтров всё же нужен, для комбинации без единого результата рекомендуется возвращать код 404, а не общую страницу с ошибкой - так робот отличает пустую комбинацию от содержательной. Там же Google советует ограничивать краулинг директивами disallow в robots.txt по конкретным параметрам (products=, color=, size=) вместо блокировки всего каталога целиком, и удерживать постоянный порядок параметров в самом URL, если фильтры кодируются в пути, а не в query-строке.

Clean-param, canonical или robots.txt - чем закрывать дубли?

Коротко: у Яндекса есть официальный приоритет из трёх инструментов - сначала директива Clean-param, затем canonical, и только в последнюю очередь запрет в robots.txt, потому что у него самые серьёзные побочные эффекты. У каждого инструмента - своё техническое ограничение, и на Битриксе они проявляются иначе, чем в общей документации.

Порядок и его причины прямо описаны в блоге Яндекс.Вебмастера. Директива Clean-param - предпочтительный вариант, потому что она сообщает роботу не индексировать страницы с указанным параметром вообще, экономя краулинговый бюджет. Canonical стоит на втором месте, потому что «роботу Яндекса всё равно придётся обойти страницу» - экономии обхода не происходит, экономится только сама индексация. И наконец, запрет в robots.txt через Disallow - крайний инструмент, потому что «поиск Яндекса не будет получать никаких сигналов с запрещённых страниц» вообще, включая исходящие с них внутренние ссылки на другие важные страницы.

У Clean-param есть техническое ограничение: директива не может быть длиннее 500 символов - это лимит из официальной справки Яндекс.Вебмастера по работе робота. Отдельная головная боль для магазинов на 1С-Битрикс: умный фильтр платформы на части каталогов отдаёт GET-параметры в квадратных скобках вида f[pf]=3100&f[820][]=19889, а по ответу поддержки Яндекса, который участник форума SearchEngines привёл ещё в 2014 году, использовать квадратные скобки в директиве Clean-param невозможно - синтаксис директивы их не поддерживает. Тогда же поддержка предложила обходной путь через Disallow с маской по конкретному параметру (например, Disallow: *f[e]*). В официальной справке по Clean-param про скобки прямо не сказано, так что при сомнении стоит проверять формат своих URL с фильтрами вручную, а не полагаться на синтаксис вслепую. Это значит, что стандартная выгрузка URL из Битрикса для Clean-param требует ручной или скриптовой подготовки, а не копирования параметра «как есть» из адресной строки.

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

Что делать с пагинацией и сортировкой?

Коротко: страницы пагинации не назначаются каноничными на первую страницу списка, а параметр сортировки, который не меняет состав товаров (только порядок), закрывается через Clean-param, а не через отдельные посадочные страницы. У каждой страницы каталога с реально разными товарами должен быть собственный уникальный адрес, доступный для индексации.

Официальная рекомендация Google по пагинации прямая: «не используйте первую страницу с результатами поиска в качестве канонической. Вместо этого назначайте каждой странице её собственный канонический URL» - у каждой страницы каталога должен быть собственный уникальный адрес и её саму можно и нужно индексировать, если на ней объективно разные товары. При этом технология rel=next/prev, которую иногда всё ещё рекомендуют старые статьи, Google давно не использует как сигнал для индексации - полагаться на неё как на инструмент управления дублями не стоит.

Частая проблема коробочных решений - SEO-текст описания категории, который дублируется на второй, третьей и последующей страницах пагинации слово в слово (типовой адрес такого дубля в логах выглядит как /catalog/divany/?PAGEN_1=2). Сортировка (по цене, по популярности, по новизне) - хороший кандидат на Clean-param именно потому, что состав товаров на странице не меняется, меняется только порядок их показа.

Зачем магазину товарный фид и что Яндекс от него требует?

Коротко: YML - формат Яндекса для передачи каталога товаров вне сайта, это второй, отдельный от микроразметки канал данных со своими жёсткими лимитами. Название товара укладывается в 50-60 символов (максимум 150), у картинки вес до 10 МБ и размер не меньше 300×400 px в формате JPEG, PNG или WEBP, а данные из фида доезжают до товарного Поиска раз в 4 часа.

По формальному определению из справки Яндекс Товаров, YML - «собственный стандарт Яндекса, основанный на XML» для описания каталога в файле, который система забирает отдельно от обхода страниц сайта. Это значит, что у вас параллельно существуют два канала передачи данных о товаре: сама страница с микроразметкой (описана выше) и файл фида - и рассинхронизация между ними - частая причина, когда на сайте цена одна, а в выдаче показана другая.

Требования к элементам фида детальные. name - от 50-60 (рекомендованная длина) до 150 символов максимум; url - не длиннее 512 символов; picture - JPEG, PNG или WEBP, минимум 300×400 px, до 10 МБ, рекомендованное соотношение сторон 3:4. Данные price попадают в поиск не мгновенно, а с той же задержкой около 4 часов, о которой шла речь выше - для срочного обновления цены Яндекс предлагает отдельный API поиска по товарам; oldprice должна быть выше price и показывать скидку в диапазоне 5-75%. currencyId для российского рубля - именно RUR, а не ISO-код RUB, который используется в микроразметке; id товара обязан быть уникальным в пределах фида.

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

Почему фид для Маркета не годится для Яндекс Товаров?

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

Справка Яндекс Товаров перечисляет 14 элементов, специфичных для Маркета (среди них age, count, vat, purchase_price, manufacturer_warranty, supplier), и прямо рекомендует не использовать их в фиде для Товаров - формально это не запрет, но фид с такими элементами рискует не пройти проверку, даже если остальные данные корректны. Прямая рекомендация из той же справки: «если вам необходимы фиды и для Маркета, и для Товаров, сформируйте для них отдельные фиды» - не пытайтесь обслужить оба канала одним файлом.

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

Что делать с товаром, которого нет в наличии?

Коротко: у отсутствия товара есть три разных сценария, и путать их - типичная ошибка. Товар вернётся: страница остаётся живой с кодом 200 и статусом OutOfStock в разметке, но цена в сниппете при этом не отображается («цена не отображается, если в свойстве availability схемы Offer указано, что товара нет в наличии» - формулировка из справки про разметку цен). Товар снят с продажи навсегда: страница должна отдавать 404 («Документ не существует») или 410 («окончательно удалён»). У товара есть прямая замена: настраивается 301-редирект, и «сохраняйте перенаправление минимум 6 месяцев» - это требование из официального словаря HTTP-кодов Яндекс.Вебмастера.

Важно развести два разных канала для одного и того же товара. Из товарного фида отсутствующий товар нужно убрать полностью: справка Яндекс Товаров прямо требует «для участия в Поиске используйте только со значением true» для параметра available, а при ошибке валидации рекомендует: «удалите из источника данных все товары, которых сейчас нет в наличии и которые нельзя заказать». Но это требование к фиду - не к самой странице сайта: страницу с временно отсутствующим товаром удалять не нужно, она продолжает жить, просто без цены в сниппете и без участия в товарном фиде до момента, когда товар снова появится.

У Google в этом вопросе схожая позиция - официальное руководство по краулинговому бюджету прямо рекомендует «возвращать код 404 или 410 для окончательно удалённых страниц» (return a 404 or 410 status code for permanently removed pages), то есть удаление страницы для товара, который больше никогда не появится в продаже, - штатный, ожидаемый сценарий, а не что-то, чего нужно избегать. При этом по нашей практике массовое одномоментное удаление тысяч карточек создаёт больше проблем (обвал трафика, битые внутренние ссылки, потерю накопленных сигналов), чем решает - поэтому чистку каталога стоит разносить во времени, а не выполнять одним днём. Практический совет, который в своём разборе на Хабре даёт Евгений Захаренко: товары, которых сейчас нет в наличии, стоит выводить в конец листинга категории, а не убирать из неё - так покупатель видит весь ассортимент, а самые доступные варианты остаются на виду.

Отдельно стоит следить, чтобы отсутствующий товар не превращался в soft 404 - ситуацию, когда сервер формально отвечает кодом 200, но по факту отдаёт пустую страницу или редирект на главную без явного 404/410/301. Такие страницы Яндекс распознаёт как псевдо-рабочие и они продолжают тратить краулинговый бюджет, не принося пользы ни покупателю, ни выдаче.

Что из этого Битрикс и Аспро уже умеют, а что придётся включать руками?

Коротко: выгрузка товарного фида для 1С-Битрикс поддерживается напрямую самим Яндексом, а не сторонним модулем - редкий случай, когда коробка не требует доработки. Микроразметка карточки в решениях на Аспро обычно уже есть в шаблоне из коробки, но её конкретный формат и полноту нужно проверять на своём сайте руками, а не считать это универсальным фактом.

По официальной информации Яндекс Товаров о способах загрузки фида, «все модули, кроме модуля для 1С-Битрикс, разработаны сторонними компаниями или специалистами. Яндекс не несёт ответственности за качество их работы» - то есть выгрузка фида для 1С-Битрикс поддерживается напрямую самим Яндексом, тогда как для большинства других CMS используются модули независимых разработчиков с разным качеством поддержки.

Готовые решения на Аспро в большинстве случаев уже отдают какую-то микроразметку товара из коробки, но какую именно (Microdata или JSON-LD, все ли обязательные поля Product/Offer закрыты) - вопрос конкретной версии шаблона, а не линейки решений в целом. Проверяется это за две минуты: открыть исходный код страницы товара (Ctrl+U в браузере) и найти либо атрибуты itemscope/itemprop, либо блок <script type="application/ld+json"> с "@type": "Product". Если добавлять свой блок разметки поверх уже существующего - получится ровно тот конфликт, что описан выше в разделе про ошибки валидатора. Прежде чем добавлять новый блок разметки, проверьте, что уже генерирует шаблон, - подробнее о том, что уже настроено в готовых решениях, в статье «Готовый интернет-магазин на Битрикс» и в разборе линейки решений Аспро на Битрикс.

На практике у типовых коробочных каталогов встречаются повторяющиеся технические грабли, не всегда очевидные из документации. На форуме поддержки 1С-Битрикс разбирался характерный случай: в каталоге на 77 326 товаров при генерации sitemap.xml ошибок не возникало, но по факту Google подхватывал из него около 27 тысяч страниц, а Яндекс - около 42 тысяч, то есть карта сайта расходилась с реальной индексацией на десятки тысяч адресов. В другой теме того же форума разбирался баг «умного фильтра»: при создании нового раздела каталога со сбросом фасетного индекса «умный фильтр виснет и тем самым ложет весь каталог» - администратор Битрикса Евгений Жуков подтвердил проблему прямым ответом: «Исправлено и выйдет в iblock 20.5.0». Это не повод отказываться от коробочных решений - но повод проверять актуальность версии модулей и реальное число страниц в индексе по каждой поисковой системе отдельно, а не полагаться на то, что «раз коробка, значит уже всё оптимизировано».

С чего начать: шесть проверок на этот вечер

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

1. Откройте Яндекс.Вебмастер → «Страницы в поиске» → раздел «Исключённые» и посчитайте, сколько страниц там помечены «Страница признана малоценной или маловостребованной» и «Страница дублирует содержание другой страницы». Если счёт идёт на тысячи при каталоге в сотни товаров - у вас проблема с дублями фильтров.
2. Загляните в «Диагностику» сайта - алерт про незначащие GET-параметры появляется там с задержкой в 2-3 дня после того, как Яндекс их накопил, так что имеет смысл заглянуть туда не один раз.
3. Прогоните через валидатор микроразметки Яндекса три случайные карточки товара из разных категорий - это покажет, стоит ли на них itemscope, не конфликтует ли коробочная разметка с добавленной вручную.
4. Наберите в Яндексе название конкретного товара и посмотрите, показывает ли выдача цену и фото прямо в сниппете - если нет при формально корректной разметке, вероятно, дело в несовпадении кода валюты или в статусе наличия.
5. Откройте адрес своего товарного фида прямо в браузере: отдаётся ли он с корректным content-type и есть ли внутри товары со значением available, отличным от true - это прямой признак того, что отсутствующие товары не вычищены из фида.
6. Замерьте мобильную скорость страницы категории со 100+ товарами: ориентиры для 75-го перцентиля реальных пользователей - LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1 (это официальные пороги Core Web Vitals). Каталожная страница с десятками изображений товаров - самый частый кандидат на просадку именно этих метрик.

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

Если карточки в порядке, а разметка и фид уже настроены, но каталог продолжает буксовать в выдаче - иногда пересборка магазина на актуальном решении обходится дешевле, чем чинить старый шаблон по частям: посмотрите, как мы строим интернет-магазины - за 150+ проектами стоит именно та типовая техничка, которая в этой статье разобрана по пунктам.

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

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

Нужен ли товарный фид, если магазин небольшой - 200-300 SKU? В требованиях Яндекс Товаров минимальный размер каталога для подключения фида не оговорён: правила про 25% ошибок и лимиты на поля применяются одинаково и к 300, и к 30 000 товарам. Экономический вопрос в другом - при малом каталоге эффект от товарной выдачи может быть не так заметен на общем трафике, но сложность и стоимость подключения фида от размера каталога не зависят.

Считается ли описание товара от поставщика дублем контента? Само по себе - не обязательно, если такое же описание не стоит один в один ещё на десятках других сайтов, которые уже проиндексированы. Риск в том, что описание от одного и того же поставщика чаще всего используют сразу несколько конкурентов без изменений - тогда для поисковика это уже массовый дубль по всему рынку, а не уникальный текст именно вашего магазина.

Сколько стоит разобрать фильтры и дубли на существующем каталоге? Отдельной услугой «разбор фильтров» мы не продаём: эта работа идёт внутри продвижения магазина - 45 000 ₽ в месяц, если в каталоге до 1 000 товаров, и 85 000 ₽ в месяц, если товаров больше или регионов несколько. Границу задаёт размер каталога и региональность, а не количество найденных дублей.

Источники

• Разметка цен товаров - Яндекс.Вебмастер
• Микроданные для сниппетов - Яндекс Товары
• Проверка фида - Яндекс Товары
• Требования к элементам фида (offers) - Яндекс Товары
• Требования к описанию товара - Яндекс Товары
• Способы формирования фида, модуль для 1С-Битрикс - Яндекс Товары
• Особенности фида Яндекс Товаров (элементы Маркета) - Яндекс Товары
• Семантическая разметка и ранжирование - Яндекс.Вебмастер
• Валидатор микроразметки - Яндекс.Вебмастер
• Работа с ошибками источника данных - Яндекс Товары
• Причины исключения страниц из поиска - Яндекс.Вебмастер
• Строгая микроразметка каталогов (OfferCatalog) - Яндекс.Вебмастер
• Рекомендации по формированию фида (регионы продаж) - Яндекс Товары
• Как найти дубли страниц с незначащими GET-параметрами - блог Яндекс.Вебмастера
• Директива Clean-param - Яндекс.Вебмастер
• rel=canonical - Яндекс.Вебмастер
• Словарь HTTP-кодов ответа - Яндекс.Вебмастер
• Пагинация и постепенная подгрузка страниц - Google Search Central
• Управление краулингом URL фасетной навигации - Google Search Central
• Управление краулинговым бюджетом крупного сайта - Google Search Central
• Core Web Vitals - web.dev
• Проблема с индексацией каталога на 77 326 товаров - форум 1С-Битрикс
• Баг «умного фильтра» при сбросе фасетного индекса - форум 1С-Битрикс
• Внутренняя текстовая уникальность карточек товаров - Евгений Захаренко, Хабр
• Ошибки микроразметки товара - Пётр Гришечкин, Хабр
• Открывать ли страницы фильтров в индекс - обсуждение на SearchEngines
• Квадратные скобки в Clean-param - обсуждение на SearchEngines, 2014
• Микроразметка не влияет напрямую на ранжирование - Ашманов и партнеры, 2017
• «Не уник от производителя лучше бредового уника» - обсуждение на SearchEngines, 2013

Магазин не продаёт - загляните, как устроены наши проекты интернет-магазинов: разбираем такие случаи предметно, на конкретном сайте, а не по шаблону из статьи.