Параметры URL: какие адреса должны попадать в поиск

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

Начните с реестра, а не общего запрета

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

Одинаковое имя может означать разное на разных маршрутах. Параметр id в карточке определяет товар, а в служебном переходе может обозначать рекламную кампанию. Поэтому правило задают сочетанием маршрута и параметра. Слепой список «удалять id, ref и page везде» способен разрушить содержание адресов.

Докажите, что параметр действительно не меняет страницу

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

Проверяйте и сочетания. Сам по себе sort может лишь менять порядок списка, но вместе с page он определяет другой набор товаров на конкретной странице. Это не повод автоматически индексировать каждую сортировку; это повод не объявлять любую пару адресов полными дублями без сравнения. Поисковую политику задают для всего сценария, а пользовательские ссылки должны воспроизводить ожидаемое состояние.

Учебный сценарий: партнёрская метка в справочнике

Справочник оборудования открывает документ по адресу /docs/view?manual_id=42. Партнёры добавляют partner_code, чтобы фиксировать источник. Затем редактор копирует такой адрес в меню, а генератор похожих материалов переносит метку дальше. Так возникает множество адресов одного документа. Все идентификаторы в примере условные.

Проверка показывает: manual_id выбирает документ, partner_code не меняет файл или страницу. Первое исправление — перестать наследовать партнёрскую метку при генерации собственных ссылок. Второе — согласовать канонический адрес документа, сохранив manual_id. Третье — проверить, что система аналитики по-прежнему фиксирует входной источник. Принудительный редирект с удалением метки до работы механизма атрибуции может потерять нужные сведения; его нельзя вводить без участия владельца аналитики.

Для Яндекса есть директива Clean-param: она позволяет указать параметры, которые не меняют содержимое. В данном подтверждённом сценарии пример узкого правила выглядит так:

User-agent: Yandex
Clean-param: partner_code /docs/view

Это пример для указанного маршрута, а не универсальная заготовка robots.txt. Префикс пути в Clean-param охватывает начинающиеся с него адреса, поэтому проверьте соседние маршруты. Отдельная группа Yandex также требует проверки всех остальных предназначенных этому роботу правил. Директива не удаляет параметр из адресной строки посетителя и не заменяет настройку других поисковых систем.

Согласуйте четыре места генерации адресов

После выбора предпочтительной формы сравните внутренние ссылки, canonical, sitemap и внешние ссылки, которые создаёт сама команда. Они не обязаны быть побайтно одинаковыми во всех пользовательских сценариях, но расхождения должны быть объяснены. Например, рекламный вход закономерно содержит метку, а навигация между статьями — обычно нет.

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

Не заменяйте анализ массовым запретом всех URL с вопросительным знаком. В такую группу могут попасть карточки, документы и пагинация. Правила обхода, исключение из индекса и указание предпочтительной версии решают разные задачи. Если нужен canonical, его следует применять к действительно похожим материалам; выбор канонического адреса остаётся отдельной проверкой, как описано в документации Google о дублях.

Набор тестов перед выпуском

1. Адрес без необязательного параметра возвращает правильный материал.
2. Значимый идентификатор сохраняется при нормализации и переходах.
3. Порядок параметров не создаёт непредусмотренное различие содержимого.
4. Пустое, неизвестное и повторяющееся значение обрабатывается по правилу приложения, а не создаёт бесконечные новые страницы.
5. Пользовательская ссылка на выбранную конфигурацию открывает именно её.
6. Рекламный источник фиксируется после изменения маршрута; внутренние ссылки не разносят его по сайту.
7. Смежный раздел с таким же именем параметра не попал под чужое правило.

Примите работу по конкретным семействам URL. Если исправлены партнёрские метки справочника, это не доказывает правильность сортировок каталога. Храните реестр рядом со спецификацией приложения и проверяйте новые параметры при добавлении интеграций. Тогда SEO-настройки будут следовать смыслу продукта, а не догонять случайно созданные адреса.