На больших сайтах дубли редко выглядят как две аккуратные одинаковые страницы, которые легко заметить глазами. Чаще всё гораздо скучнее: к нормальному адресу начинают прирастать параметры сортировки, фильтра, аналитики, источника перехода, номера страницы, сессии или какой-нибудь внутренней логики CMS. Контент почти тот же, а URL уже другой.
В результате поисковый робот получает не одну страницу, а целое семейство адресов. Часть из них Яндекс склеит как дубли, часть может продолжить обходить, а иногда в поиске оказывается не тот вариант URL, который хотелось бы видеть. На небольшом сайте это может долго оставаться незаметным. На каталоге с фильтрами и сортировками масштаб проблемы растёт очень быстро.
У Яндекс Вебмастера для этого есть отдельный инструмент — Настройка GET-параметров. Он позволяет прямо сообщить роботу, какие параметры действительно меняют содержимое страницы и должны учитываться, а какие можно игнорировать при индексировании. Инструмент появился в конце 2025 года, но до сих пор встречаются сайты, где с параметрами пытаются бороться только canonical, robots.txt и надеждой, что поисковик сам всё поймёт.
Откуда вообще берутся дубли с параметрами
Самый простой пример — рекламные метки. Есть страница /catalog/, а посетитель приходит на /catalog/?utm_source=…. Для пользователя это та же самая страница. Для сервера это другой URL, и робот технически тоже может его обнаружить и открыть.
С аналитическими метками всё более-менее очевидно: они обычно не меняют основной контент. Сложнее начинаются вещи вроде ?sort=price, ?brand=…, ?color=…, ?page=2. Тут параметр уже способен изменить набор товаров, порядок элементов или вообще сформировать полезную посадочную страницу.
Поэтому сама по себе конструкция со знаком вопроса в URL не является SEO-ошибкой. Ошибка начинается тогда, когда сайт бесконтрольно создаёт множество адресов, которые поиску не нужны, а робот вынужден тратить на них обход.
Что именно делает настройка в Вебмастере
В разделе Индексирование → Настройка GET-параметров Яндекс показывает параметры, которые робот уже обнаружил на сайте. Для каждого можно указать, нужно ли учитывать его при индексировании.
Логика довольно простая. Если параметр отмечен как значимый, робот может обходить такой URL и добавлять его в поиск. Если параметр признан незначимым, страницы с ним не должны участвовать в поиске как самостоятельные документы.
Яндекс прямо пишет, что это помогает уменьшить количество обращений робота, снизить нагрузку на сайт, ускорить индексирование и оставить в поиске нужную версию страницы. То есть речь не только о косметической чистоте индекса. Мы управляем тем, куда робот тратит время.
Для параметров, добавленных вручную, настройку можно ограничить всем сайтом, главной страницей или конкретным разделом. Это полезно, потому что один и тот же параметр в разных частях сайта теоретически может выполнять разную функцию.
Главная ошибка — запретить всё, что выглядит подозрительно
Когда в Вебмастере появляется длинный список параметров, возникает понятное желание пройтись по нему и везде поставить Нет. Вот этого я бы как раз не делал.
Нужно сначала ответить на один вопрос: меняет ли конкретный параметр содержимое страницы так, что получившийся URL имеет самостоятельную поисковую ценность?
UTM-метка почти наверняка не имеет. Параметр технического источника перехода — тоже. А фильтр по важной характеристике товара уже может формировать страницу, под которую существует отдельный спрос. Если такая страница доступна только через параметр, механический запрет параметра способен выкинуть из индекса полезную посадочную.
То же самое с пагинацией. Нельзя просто объявить все страницы после первой мусором, не посмотрев, как устроен каталог, доступны ли товары роботу другим способом и что происходит с внутренними ссылками. Иногда попытка сделать индекс красивым приводит к тому, что робот хуже добирается до глубоких карточек.
Как я бы разбирал список параметров
Не с кнопок в Вебмастере, а с таблицы. Выписать параметр, несколько реальных URL с ним и посмотреть, что фактически меняется на странице.
- Аналитические и рекламные параметры. Если они только передают источник визита и не меняют контент, поисковая версия с ними обычно не нужна.
- Сортировки. Цена по возрастанию, популярность, рейтинг и похожие варианты чаще всего переставляют те же объекты. Отдельная индексация таких комбинаций обычно смысла не имеет.
- Фильтры. Здесь автоматического ответа нет. Часть фильтров — технический мусор, часть может быть полноценной SEO-структурой.
- Пагинация. Нужно смотреть архитектуру сайта, внутреннюю перелинковку и доступность объектов для робота.
- Служебные параметры CMS. Сессии, режимы отображения, технические идентификаторы чаще всего поиску не нужны, но всё равно сначала стоит проверить содержимое.
После такой классификации становится понятно, где настройка GET-параметров действительно поможет, а где сначала нужно переделать структуру сайта.
Почему canonical не всегда закрывает вопрос
Частая логика такая: на всех вариантах с параметрами стоит canonical на чистый URL, значит можно больше ничего не делать. Но canonical решает немного другую задачу. Он подсказывает поисковику предпочтительный адрес документа, однако робот всё равно должен сначала обнаружить и обойти параметрические URL, чтобы увидеть эту подсказку.
Если таких URL немного, никакой трагедии. Если комбинации параметров генерируются почти бесконечно, мы всё равно заставляем робота ходить по мусорным адресам. Поэтому canonical полезен, но не заменяет нормального управления обходом.
Настройка GET-параметров работает раньше в этой цепочке: мы сообщаем Яндексу, какие варианты вообще не стоит воспринимать как самостоятельные страницы.
А что с Clean-param в robots.txt
Директива Clean-param никуда не исчезла. Яндекс продолжает её поддерживать. Через неё можно указать роботу, какие параметры URL не влияют на содержимое и должны игнорироваться.
Новый инструмент Вебмастера делает ту же область работы заметно доступнее: не нужно каждый раз лезть в robots.txt, вспоминать синтаксис и править файл на сервере. Особенно удобно сначала посмотреть параметры, которые робот уже реально нашёл.
Но есть важный нюанс. Яндекс указывает: если настройки Вебмастера и robots.txt противоречат друг другу, робот применит правило, которое запрещает индексирование URL с параметром. Поэтому после настройки в интерфейсе стоит проверить старый robots.txt. Там вполне может жить Clean-param, добавленный несколько лет назад и давно забытый.
Где инструмент особенно полезен
Первый очевидный кандидат — интернет-магазины. Фасетная навигация, сортировки, вид списка, диапазоны цен, бренды, характеристики, метки рекламных кампаний. Несколько независимых параметров легко превращаются в огромное количество комбинаций.
Второй — сайты объявлений и каталоги услуг. Там ситуация похожая: регион, категория, цена, дополнительные признаки, сортировка. Если CMS позволяет индексировать любую комбинацию, робот получает практически бездонную яму URL.
Третий случай менее очевиден — обычный корпоративный сайт после нескольких лет доработок. На нём могут остаться старые параметры рекламных систем, версии страниц, параметры форм, внутреннего поиска и плагинов. Страниц немного, но технических URL в обходе внезапно оказывается в несколько раз больше.
Как понять, что проблема уже есть
Я бы смотрел не на один показатель, а на несколько признаков вместе.
В Статистике обхода появляются многочисленные адреса с вопросительным знаком и повторяющимися параметрами. В разделе Страницы в поиске видны неожиданные варианты URL. В диагностике Яндекс может отдельно сообщать о страницах-дублях с GET-параметрами. Параллельно важные новые страницы индексируются заметно медленнее, чем хотелось бы.
Ещё полезно посмотреть серверные логи, если есть доступ. Вебмастер показывает картину со стороны Яндекса, а логи позволяют увидеть реальный масштаб обхода параметрических адресов. Иногда там быстро находится генератор мусора, о существовании которого никто уже не помнил.
После изменения не надо ждать мгновенной уборки индекса
Настройка GET-параметров не является кнопкой удалить всё сейчас. В справке Яндекс предупреждает, что внесённые изменения вступают в силу в течение недели. Дальше роботу нужно переобойти сайт и обновить данные.
Поэтому схема поставил настройку утром — вечером проверил индекс — решил, что не работает здесь не годится. Я бы зафиксировал дату изменения и посмотрел динамику обхода и индексирования через несколько дней, а затем ещё раз после нормального цикла обхода.
И ещё один неприятный сценарий
Иногда параметрические дубли появляются не потому, что робот сам придумал адреса, а потому что сайт активно на них ссылается. Например, меню сортировки, фильтры или внутренние блоки генерируют ссылки на URL с ненужными параметрами.
В таком случае одной настройки Вебмастера мало. Да, можно объяснить Яндексу, что параметр не нужен для поиска. Но сайт всё равно продолжит производить и раздавать эти адреса пользователям и роботам. Лучше убрать причину: исправить внутренние ссылки, нормализовать URL, проверить редиректы и canonical.
Вообще хорошее техническое SEO редко сводится к одному правилу в одном сервисе. Вебмастер здесь скорее даёт удобный рычаг, а не освобождает от необходимости понимать архитектуру сайта.
Что в итоге
Настройка GET-параметров — полезный инструмент именно потому, что решает очень приземлённую задачу. Не обещает рост позиций на 37 процентов, не требует шаманства с текстами и не выглядит эффектно на презентации. Он просто помогает роботу не тратить ресурсы на URL, которые поиску не нужны.
Но пользоваться им стоит аккуратно. Сначала определить назначение каждого параметра, проверить реальные страницы и поисковый спрос, потом уже запрещать индексацию. Особенно осторожно — с фильтрами и пагинацией.
Если параметр ничего не меняет для пользователя и существует только ради аналитики или технической логики, его обычно есть смысл убрать из поисковой картины. Если же он формирует отдельный полезный документ, простой запрет может сделать хуже. В этом месте автоматического рецепта нет — и это, пожалуй, самая важная часть всей настройки.