Обработка дублей в каталоге: canonical, фильтры и параметрические URL на практике
У крупного интернет-магазина легко наблюдать одну и ту же категорию в десятках вариаций URL - с параметром сортировки, с UTM-меткой, с примененным фильтром по цвету, с версией для печати. Формально это разные адреса, по факту - один и тот же список товаров, показанный под разным углом. Поисковик видит это разнообразие и должен как-то решить, какую версию считать основной, а остальные - дублями.
Проблема не в том, что дубли существуют - на любом каталоге с фильтрами и параметрами они возникают неизбежно как побочный эффект архитектуры. Проблема в том, что для разных типов дублей нужны разные инструменты, и применение не того метода к не той ситуации создаёт больше вреда, чем сами дубли. Разбираем на конкретных примерах, как выбрать между canonical, noindex и блокировкой в robots.txt для каждого типа параметрических URL.
Прежде чем переходить к конкретным случаям, стоит понимать общий принцип: любая техническая работа с дублями бессмысленна в отрыве от остального продвижения сайта - если каталог и так плохо индексируется или контент карточек откровенно слабый, устранение дублей не даст ощутимого прироста трафика, потому что проблема не в них, а в более фундаментальных вещах.
Canonical: рабочий сценарий на конкретном примере
Возьмём типичную ситуацию - категория «кроссовки» доступна по нескольким URL с параметрами сортировки: /krossovki/?sort=price_asc, /krossovki/?sort=popular, /krossovki/?sort=new. Контент на всех трёх версиях идентичен, отличается только порядок отображения товаров. Это классический случай для canonical - все три URL должны указывать на чистую версию /krossovki/ как на каноническую.
Важный нюанс, который часто упускают: canonical не блокирует индексацию страницы с параметром напрямую - он лишь передаёт поисковику рекомендацию, какую версию считать основной. Робот может продолжать заходить на URL с параметрами, но не должен показывать их в выдаче отдельно от канонической версии. Если после настройки canonical страницы с параметрами всё равно попадают в индекс через несколько недель, стоит проверить, не противоречит ли настройка другим сигналам - например, если на эти же URL ведут внутренние ссылки с анкорами, которые сигнализируют об их значимости.
Когда canonical не подходит: пример с фильтрами
Другая ситуация - фильтр по бренду внутри категории: /krossovki/?brand=***. В отличие от сортировки, здесь контент страницы содержательно отличается от родительской категории - показывается не весь ассортимент, а конкретная подвыборка, соответствующая реальному пользовательскому запросу «кроссовки ***». Указать canonical на /krossovki/ в этом случае означает добровольно отказаться от потенциального трафика по частотному запросу.
Правильное решение здесь - не canonical, а отдельная индексируемая страница с собственным заголовком, description и, желательно, ЧПУ вида /krossovki/nike/ вместо параметра в query string. Технически это требует доработки на стороне разработки - параметр фильтра нужно превратить в самостоятельный URL с уникальным контентом, а не просто разрешить его индексацию как есть с автоматически подставленным заголовком.
Комбинации фильтров: где заканчивается смысл
Продолжая пример с кроссовками - что делать с комбинацией /krossovki/?brand=***&color=black&size=42? Здесь принцип понятен: чем больше параметров применено одновременно, тем ниже вероятность, что у комбинации есть самостоятельный поисковый спрос. Никто не формулирует запрос «кроссовки найк черные 42 размер» с такой точностью в поисковике - за исключением крайне редких случаев в узких нишах, это стоит проверять по каждой конкретной категории отдельно.
Практический порог, который работает в большинстве каталогов: один-два значимых параметра (бренд, ключевой атрибут) - кандидаты на индексируемую страницу при подтверждённом спросе; три и более параметров одновременно - закрывать через noindex, оставляя страницу доступной для пользователя, но убирая её из индекса. Использовать здесь блокировку в robots.txt не стоит - если комбинация окажется полезной в будущем, снять noindex можно сразу, тогда как открытие ранее заблокированного в robots.txt раздела означает, что робот заново начинает узнавать о существовании этих страниц с нуля.
UTM-метки и служебные параметры: без вариантов
Для параметров, которые не влияют на контент страницы вовсе - меток аналитики, идентификаторов сессии, партнёрских кодов - вариативности в выборе метода нет. Такие параметры должны обрабатываться через canonical на чистый URL без параметра, и дополнительно стоит настроить обработку на уровне сервера так, чтобы подобные параметры не создавали новых записей в логах сканирования без необходимости. Здесь ошибка встречается редко, но иногда UTM-параметры случайно попадают во внутренние ссылки самого сайта - в письма рассылок, скопированные в меню,
в баннеры на главной странице - и тогда робот начинает регулярно натыкаться на эти URL при обычном обходе сайта, а не только при переходе по внешней рекламной ссылке. В этом случае canonical решает проблему индексации, но не устраняет саму причину - лучше найти источник и убрать метку из внутренних ссылок, оставив её только там, где она действительно нужна для аналитики переходов извне.
Версии для печати и мобильные поддомены: noindex, а не canonical
Отдельный случай - страницы, которые нужны как функциональность для пользователя, но не должны участвовать в поиске вообще. Версия для печати /krossovki/print/ дублирует карточку товара практически полностью, но выполняет служебную задачу - удобный формат для распечатки характеристик. Здесь подходит meta robots noindex, follow: страница остаётся доступной по прямой ссылке и через неё продолжает проходить робот при переходах, но сама она не попадает в выдачу как самостоятельный результат.
Похожая логика применима к мобильным версиям на отдельном поддомене, если сайт всё ещё использует такую архитектуру вместо адаптивной вёрстки. Здесь вместо простого noindex нужна связка rel=alternate на десктопной версии и rel=canonical на мобильной, указывающих друг на друга - это специальный случай, который Google обрабатывает не так, как обычные технические дубли, и настраивать его нужно по документированной схеме, а не по аналогии с версией для печати.
Постраничная навигация (пагинация)
Отдельная категория дублей возникает на многостраничных категориях - /krossovki/?page=2, /krossovki/?page=3 и так далее. Каждая страница пагинации технически уникальна по составу товаров, но с точки зрения смысла и релевантности запросу все страницы отвечают на один и тот же интент «кроссовки», просто показывают разные позиции списка.
Практика последних лет сместилась в сторону простого решения: canonical на страницах пагинации не нужен - каждая страница canonical сама на себя, потому что Google и Яндекс достаточно хорошо научились самостоятельно обрабатывать пагинацию как последовательность, а не как отдельные конкурирующие документы. Раньше рекомендовали rel=next/rel=prev, но Google официально отказался от использования этой разметки как сигнала - сегодня в ней нет смысла, хотя формально она не вредит при наличии. Единственное, что стоит проверить отдельно - чтобы страницы пагинации не блокировались через robots.txt и не закрывались noindex по ошибке, иначе робот не сможет дойти до товаров в глубине списка через обычный обход.
Как выбрать метод: сводная логика
Если свести разобранные случаи в единый принцип принятия решения, получается простая последовательность вопросов для любого нового типа параметра в каталоге:
- Меняется ли контент страницы содержательно относительно родительской - или это просто другой порядок отображения того же самого списка?
- Если контент меняется - есть ли у этой конкретной комбинации параметров подтверждённый поисковый спрос?
- Если спрос есть - нужна отдельная индексируемая страница с уникальным title, description и, желательно, человекочитаемым URL.
- Если спроса нет, но страница должна быть доступна пользователю - noindex, follow.
- Если параметр не несёт смысловой нагрузки вовсе (аналитика, сессии, сортировка) - canonical на чистый URL.
- Полная блокировка в robots.txt - только для случаев, где ни при каких обстоятельствах комбинация не станет полезной, потому что это единственный метод, который сложно и медленно отменить при пересмотре решения.
Частые ошибки при обработке параметрических дублей
- закрывать все параметры через robots.txt без разбора, теряя доступ к комбинациям, которые могли бы приносить трафик после доработки в отдельные страницы;
- ставить canonical на страницы с реальным самостоятельным спросом (как в примере с фильтром по бренду), добровольно отказываясь от части органического трафика;
- использовать noindex и canonical одновременно на одной странице - противоречивый сигнал, который алгоритм может интерпретировать непредсказуемо;
- пытаться применитьرel=next/rel=prev как решение проблемы пагинации, хотя Google давно не учитывает эту разметку как значимый сигнал;
- не отслеживать регулярно, какие новые параметры добавляются в каталог при обновлении фронтенда, из-за чего логика обработки дублей со временем отстаёт от реальной структуры сайта.
Итоги
Универсального решения «canonical для всех дублей» или «noindex для всего с параметрами» не существует - правильный метод определяется тем, меняется ли контент содержательно и есть ли у конкретной комбинации параметров реальный поисковый спрос. Разбор по конкретным случаям, а не по абстрактному правилу, экономит трафик там, где параметр на самом деле мог бы стать источником дополнительных посещений, и одновременно защищает от разрастания бесполезных страниц там, где спроса объективно нет.
Есть жалобы? Канал для добрых казанцев, которых вывели из себя. Делитеcь тем, что вас разозлило: Злой Казанец
