Интернет-магазин с тысячей товаров — это не тысяча уникальных URL, а часто десятки тысяч. Каждая комбинация фильтра «цвет=красный&размер=M&сортировка=по_цене» технически создаёт новый адрес с почти тем же самым контентом, что и на соседнем. Добавьте сюда UTM-метки от рекламных кампаний, идентификаторы сессий и параметры пагинации — и получится ситуация, в которой поисковик тратит время на обход тысяч страниц-клонов вместо того, чтобы чаще заходить на действительно важные.
Это отдельная, очень частая причина проблем с индексацией — и она не про контент, а конкретно про то, как параметры URL ведут себя с точки зрения краулера.
Откуда берутся параметрические дубли
Фильтры и сортировки каталога
/catalog/shoes?color=black, /catalog/shoes?sort=price_asc, /catalog/shoes?color=black&sort=price_asc — формально это три разных URL, выдающих практически идентичный набор товаров в разном порядке. Если все комбинации индексируются, на один реальный раздел каталога может приходиться десятки и сотни вариаций.
UTM-метки и метки аналитики
?utm_source=yandex&utm_medium=cpc&utm_campaign=... — параметры существуют исключительно для аналитики, но если страница с ними технически доступна для обхода и не имеет защиты от индексации, поисковик может зайти на неё и расценить как отдельный документ.
Сессионные и пользовательские параметры
?sessionid=abc123, ?ref=email, параметры персонализации — каждый уникальный визит потенциально создаёт уникальный URL. Если такие ссылки попадают во внутреннюю перелинковку (например, через email-рассылку, которую кто-то процитировал на сторонней странице), это прямой путь в индекс.
Пагинация
?page=2, ?page=3 — отдельная история: это не совсем дубли, но если на втором десятке страниц пагинации контента почти не остаётся ценности, краулинговый бюджет на них тоже расходуется не лучшим образом.
Чем это вредно
Дело не в «штрафе за дубли» — прямого наказания за дублированный контент как такового нет. Вред — комбинированный:
- Краулинговый бюджет уходит не туда. Робот тратит ограниченное число запросов на обход именно вашего сайта — если большая их доля приходится на параметрические клоны, до новых и обновлённых страниц очередь доходит реже.
- Размывание сигналов ранжирования. Если ссылочный вес и поведенческие сигналы распределяются между десятком версий одной страницы вместо одной канонической, ни одна версия не накапливает достаточно силы, чтобы хорошо ранжироваться.
- Непредсказуемый выбор канонической версии. Если вы явно не указали, какая версия основная, поисковик решает это сам — и не всегда выбирает ту страницу, которую выбрали бы вы.
Как навести порядок: три инструмента и когда какой использовать
Canonical — когда страница должна остаться доступной, но не дублироваться в индексе
Подходит для большинства параметров фильтрации и сортировки, где сама страница полезна пользователю (он должен иметь возможность отфильтровать товары), но не должна конкурировать в индексе с базовой версией раздела:
<link rel="canonical" href="https://example.com/catalog/shoes" />
На всех вариациях /catalog/shoes?color=*&sort=* ставится canonical на базовый /catalog/shoes без параметров. Страница остаётся рабочей для пользователей и доступной для обхода, но не плодит дубли в индексе. Проверить, правильно ли расставлены canonical-теги на параметрических страницах, можно через анализатор canonical.
Disallow в robots.txt — когда страница вообще не должна обходиться
Подходит для параметров, которые не несут никакой пользы для индексации и при этом массово генерируют URL — сессионные ID, метки аналитики, технические параметры сортировки в сложных комбинациях:
User-agent: *
Disallow: /*?sessionid=
Disallow: /*?utm_
Disallow: /*&utm_
Важный нюанс: Disallow в robots.txt запрещает обход, а не убирает страницу из индекса, если она уже туда попала другим путём (например, по внешней ссылке). Если страница уже проиндексирована, для удаления нужен noindex в мета-теге или HTTP-заголовке — но тогда её придётся оставить доступной для обхода, иначе робот не увидит сам noindex. Это частая путаница: Disallow и noindex решают разные задачи и в некоторых случаях противоречат друг другу при неправильном сочетании.
Безопасные параметры — когда трогать вообще не нужно
Не все параметры одинаково опасны. Параметры, которые не меняют контент страницы (например, чисто технические идентификаторы для A/B-тестов на бэкенде, не влияющие на HTML) или которые поисковик и так хорошо умеет распознавать как незначащие, можно не трогать вообще — лишняя возня с правилами без реальной проблемы только усложняет конфигурацию и повышает риск случайно закрыть что-то нужное.
Как понять, что параметры уже стали проблемой
Несколько практических признаков:
- В индексе поисковика на порядок больше страниц вашего сайта, чем реально существует уникальных разделов — проверьте через
site:вашдомен.ruи сравните с числом URL в sitemap; - В отчёте об индексации Google Search Console или Яндекс.Вебмастера много страниц со статусом «дубликат, канонический URL не выбран пользователем» или похожим;
- Бот регулярно обходит параметрические URL, судя по логам сервера, при этом не доходит до части реально важных страниц в разумные сроки.
Эта проблема — частный случай более широкой темы краулингового бюджета: если на сайте уже есть похожая ситуация с параметрами, имеет смысл одновременно проверить, как вообще распределяется внимание робота между разделами сайта.
Чек-лист
- Выписать все параметры, которые реально используются на сайте (фильтры, сортировки, UTM, сессии, пагинация)
- Для каждого решить: меняет контент страницы или нет
- На параметрах, не меняющих контент существенно — поставить canonical на базовый URL
- На технических параметрах (сессии, метки аналитики) — закрыть обход через Disallow в robots.txt
- Проверить, что canonical и Disallow не конфликтуют между собой на одних и тех же URL
- Сверить число URL в индексе с реальным числом уникальных разделов
- Перепроверить через несколько недель, что число дублей в индексе снижается
Заключение
Параметры URL — один из тех технических нюансов, которые незаметны в повседневной работе с сайтом, но накапливаются годами и в какой-то момент начинают ощутимо мешать индексации, особенно у крупных каталогов. Решение почти всегда комбинированное: canonical там, где страница полезна пользователю, и Disallow там, где параметр существует только для технических нужд. Начните с проверки текущих canonical-тегов через анализатор canonical и сверки robots.txt через анализатор robots.txt — это покажет, где уже есть прорехи.