GET-параметры в URL

Возражения и FAQ по GET-параметрам и дублям страниц

Полный справочник GET-параметров с рекомендациями по обработке

User-agent: *
# Блокируем Яндекс аналитику и внутренние параметры
Disallow: /*?*yklid=*
Disallow: /*?*icliyd=*
Disallow: /*?*iclyd=*
Disallow: /*?*icllcd=*
Disallow: /*?*ycllcd=*
Disallow: /*?*ylecd=*
Disallow: /*?*yhyd=*
Disallow: /*?*yiclyd=*
Disallow: /*?*yklld=*
Disallow: /*?*ykild=*
Disallow: /*?*ykilt=*
Disallow: /*?*ykilp=*
Disallow: /*?*yqilp=*
Disallow: /*?*yqipl=*
Disallow: /*?*yqpil=*
Disallow: /*?*yaqpil=*
Disallow: /*?*yclud=*
Disallow: /*?*ybqpil=*
Disallow: /*?*ypppil=*
Disallow: /*?*yqppel=*
Disallow: /*?*yprqee=*
Disallow: /*?*ypppel=*
Disallow: /*?*yycleed=*

# Блокируем внутренние системные параметры
Disallow: /*?*parent-baobab-id=*
Disallow: /*?*parent-reqid=*
Disallow: /*?*cm_id=*
Disallow: /*?*erid=*

# Блокируем технические параметры
Disallow: /*?*ctime=*
Disallow: /*?*gtm_latency=*
Disallow: /*?*loadme=*

# Блокируем стандартную аналитику
Disallow: /*?*utm_*
Disallow: /*?*gclid=*
Disallow: /*?*fbclid=*
Disallow: /*?*yclid=*
Disallow: /*?*yclod=*
Disallow: /*?*yclad=*
Disallow: /*?*sbclid=*

# Разрешаем всё остальное
Allow: /*?*
Allow: /*

<!-- example.com/articles?type=news -->
<link rel="canonical" href="https://example.com/articles/" />

<!-- example.com/blog?tag=seo -->
<link rel="canonical" href="https://example.com/blog/" />

<!-- example.com/services?region=moscow -->
<link rel="canonical" href="https://example.com/services/?region=moscow" />
<meta name="description" content="Услуги в Москве" />

Подробнее о том, какие GET-параметры категорически запрещено добавлять в clean-param или disallow?

Опасность необдуманного управления параметрами

Я сталкивался с множеством случаев, когда неправильная настройка обработки GET-параметров приводила к катастрофическим последствиям для видимости сайта. Директивы clean-param в robots.txt и настройки disallow для параметризованных URL — это мощный инструмент, но обращаться с ним нужно как с хирургическим скальпелем: точно и осознанно.

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

Что такое clean-param и disallow для параметров?

Директива clean-param в файле robots.txt указывает поисковым системам (в основном Яндекс), что определенные GET-параметры не влияют на содержание страницы. Например:

Clean-param: ref /some_dir/*.html

Это говорит роботу: "Параметр ref в URL вида /some_dir/*.html не меняет контент, не индексируй разные варианты с этим параметром".

Директива Disallow с параметрами в URL блокирует индексацию конкретных параметризованных страниц:

Disallow: /*?session_id=

В Google аналогичного поведения можно добиться через параметры в Google Search Console или с помощью канонических ссылок.

КАТЕГОРИЧЕСКИ ЗАПРЕЩЕННЫЕ К ДОБАВЛЕНИЮ ПАРАМЕТРЫ

Примеры:

• ?category=
• ?cat_id=
• ?brand=
• ?price_from= / ?price_to=
• ?size=
• ?color=
• ?sort= (если сортировка влияет на выдачу товаров)

Почему нельзя блокировать:

Эти параметры создают уникальный контент. Страница site.ru/catalog?category=shoes и site.ru/catalog?category=hats — это разные страницы с разным содержанием. Блокировка приведет к тому, что:

• Не будут проиндексированы категории товаров
• Потеряется целевой трафик по коммерческим запросам
• Упадут конверсии

Примеры:

• ?page=
• ?p=
• ?pagenum=
• ?from=

Почему нельзя блокировать:

Пагинация — это механизм навигации по последовательному контенту. Страница news?page=1 и news?page=2 содержат разные статьи. Блокируя параметр пагинации, вы:

• Останавливаете индексацию контента beyond первой страницы
• Нарушаете внутреннюю перелинковку
• Создаете проблемы с краулинговым бюджетом

Правильный подход: Используйте rel="next"/"prev" или канонические ссылки на первую страницу для бесконечной прокрутки.

Примеры:

• ?id=
• ?product_id=
• ?article_id=
• ?news_id=

Почему нельзя блокировать:

Это самые опасные параметры для блокировки. Они часто являются основным способом доступа к уникальному контенту. Например:

• site.ru/product.php?id=123 — конкретный товар
• site.ru/article.php?id=456 — конкретная статья

Блокировка ?id= через disallow может привести к полной деиндексации всего каталога товаров или статей.

Примеры:

• ?q=
• ?query=
• ?search=
• ?keyword=

Почему нельзя блокировать:

Внутренний поиск сайта может создавать страницы с уникальным контентом, особенно если:

• Это поиск по товарам с фильтрацией
• Поиск по статьям с релевантными результатами
• Страницы результатов поиска хорошо оптимизированы

Однако здесь нужен анализ: если поиск создает тонны низкокачественных дублей — возможно, потребуется осторожная настройка.

Примеры:

• ?lang=
• ?language=
• ?region=
• ?country=
• ?currency=

Почему нельзя блокировать:

Эти параметры создают географически или лингвистически таргетированный контент. Блокировка приведет к:

• Невозможности индексации мультиязычной версии сайта
• Потере международного трафика
• Проблемам с hreflang-разметкой

Примеры:

• ?sid=
• ?sessionid=
• ?phpsessid=

Здесь сложная ситуация:

С одной стороны, сессионные параметры создают дубли страниц и расходуют краулинговый бюджет. С другой — их полная блокировка через disallow может помешать индексации, если поисковый робот получит URL с сессией.

Правильный подход:

• По возможности избавиться от сессионных параметров в URL (перейти на cookies)
• Использовать clean-param для Яндекс
• Для Google — настройка в Search Console + канонические ссылки
• Никогда не использовать Disallow: /*?sid= — это может заблокировать ВСЕ страницы, если робот перейдет по ссылке с сессией

Примеры:

• ?utm_source=
• ?utm_medium=
• ?utm_campaign=
• ?ref=

Почему обычно нельзя полностью блокировать:

Хотя UTM-параметры не должны влиять на контент, их блокировка через disallow опасна:

• Робот может начать с URL с UTM и заблокировать основную страницу
• Лучше использовать clean-param для Яндекса
• Для Google — настройка "Игнорируемые параметры" в Search Console

ПАРАМЕТРЫ, КОТОРЫЕ ЧАСТО МОЖНО ДОБАВЛЯТЬ (с осторожностью)

Для полноты картины упомяну параметры, которые часто безопасно добавлять в clean-param:

• Параметры отслеживания: ?fbclid=, ?gclid= (но только если у вас настроены другие методы отслеживания)
• Параметры кеширования: ?timestamp= (если они не меняют контент)
• Параметры социальных сетей: ?fb_action_ids=
• Параметры порядка сортировки: ?order= (если это чисто визуальная сортировка без изменения набора элементов)

МЕТОДИКА АНАЛИЗА ПЕРЕД ДОБАВЛЕНИЕМ ПАРАМЕТРА В CLEAN-PARAM ИЛИ DISALLOW

• Соберите все URL с параметрами через лог-файлы или инструменты аналитики
• Сгруппируйте параметры по типап
• Проанализируйте, сколько уникальных значений у каждого параметра

Проверка влияния на контент: Откройте одну и ту же страницу с параметром и без него. Меняется ли:

• HTML-код (кроме служебных скриптов)?
• Заголовок H1?
• Мета-теги?
• Основной текстовый контент?

Проверка ответа сервера: Сравните HTTP-заголовки, особенно:

• Код ответа (должен быть 200 для обоих вариантов)
• Заголовок Canonical (самостоятельно или генерируется)

• Проверьте в индексе Google: site:yourdomain.com inurl:"параметр="
• Проверьте позиции страниц с параметрами и без
• Проанализируйте трафик на параметризованные страницы

Создайте таблицу принятия решений:

РЕАЛЬНЫЕ КЕЙСЫ ИЗ ПРАКТИКИ

ИНСТРУМЕНТЫ ДЛЯ МОНИТОРИНГА И КОНТРОЛЯ

• Google Search Console → Отчет "Покрытие" → Исключенные → Просканированные, но не проиндексированные
• Яндекс.Вебмастер → Индексирование → Структура сайта → Анализ robots.txt
• Screaming Frog → Анализ параметров через Configuration → Spider
• Лог-файлы сервера — самый точный источник информации о том, как роботы видят ваш сайт
• Google Analytics → Поведение → Содержание сайта → Все страницы (смотреть на параметры)

ЗАКЛЮЧЕНИЕ: ГЛАВНЫЕ ПРИНЦИПЫ БЕЗОПАСНОЙ РАБОТЫ С ПАРАМЕТРАМИ

Глубокий разбор для интернет-магазинов: битва с параметрами за краулинговый бюджет и трафик

Для интернет-магазина GET-параметры — это не просто техническая помеха, а основной канал взаимодействия с пользователем. Их полная блокировка убьет функциональность, а игнорирование — уничтожит SEO. Задача — найти баланс и превратить параметры из врага в инструмент привлечения длинного хвоста запросов.

Категории параметров в e-commerce и стратегия для каждой

Продвинутая тактика: какие страницы с параметрами СТОИТ оставить в индексе?

Главный вопрос: "Имеет ли страница с параметром уникальную коммерческую ценность и отвечает ли на отдельный кластер поисковых запросов?"

Техническая реализация для индексируемых страниц с фильтрами:

1. Уникальный Title и Description: "Купить кроссовки Nike. Цены от 3 990 руб." вместо "Кроссовки".
2. Уникальный текстовый блок: введение, описывающее преимущества выбранного фильтра (например, "Кроссовки Nike для бега сочетают инновационные технологии и стильный дизайн...").
3. "Хлебные крошки": они должны отражать путь (Главная > Обувь > Кроссовки > Nike).
4. Внутренние ссылки: ссылайтесь на такие страницы с главной, из статей, карты сайта.

Критически важная связка: пагинация + «Показать ещё» + бесконечная прокрутка

Чек-лист по настройке для интернет-магазина

Мониторинг и постобработка: как отслеживать результаты и что делать после внедрения

После того как вы настроили обработку GET-параметров — установили canonical-ссылки, обновили robots.txt и применили другие технические решения, — работа не заканчивается. Самая большая ошибка — это внедрить изменения и забыть о них. Неправильная настройка может привести к неожиданным последствиям, а корректная — потребует времени для полноценного эффекта.

В этом разделе я расскажу, как правильно мониторить результаты, на что обращать внимание и какие шаги предпринимать в постобработке.

Что и как отслеживать: ключевые метрики

1. Отслеживание индексации (первые 2-8 недель)

2. Мониторинг трафика и позиций

// Пример настройки сегмента в Google Analytics
// для отслеживания трафика на канонические vs параметризованные URL:

Сегмент "Канонические страницы":
Условие: "Хост + путь страницы" не содержит "?"
(или Регулярное выражение: ^[^?]*$)

Сегмент "Страницы с параметрами":
Условие: "Хост + путь страницы" содержит "?"

Что смотреть в Google Analytics и Яндекс.Метрике:

• Изменение глубины просмотра — после устранения дублей пользователи должны лучше ориентироваться на сайте.
• Снижение показателя отказов на ключевых страницах — канонические URL получают больше внимания.
• Распределение трафика — доля параметризованных URL должна снижаться, канонических — расти.

В инструментах отслеживания позиций (Ahrefs, Serpstat, KeyCollector):

• Отслеживайте позиции именно по каноническим URL.
• Если раньше позиции "плавали" между разными версиями страницы, после настройки они должны стабилизироваться.

3. Краулинговый бюджет и здоровье сайта

Критические точки контроля: когда бить тревогу

Ситуация 1: Пропали из индекса важные страницы

Симптомы:

• В GSC в отчете "Покрытие" резко выросло количество "Исключено" → "Просканировано, но не проиндексировано"
• Ключевые страницы (товары, статьи) перестали находиться по запросу site:домен.com/ключевая-страница

Возможные причины:

• Слишком агрессивные правила в robots.txt: Disallow: /*?* заблокировал ВСЕ страницы с параметрами, включая product.php?id=123.
• Ошибка в канонических ссылках: На всех страницах с параметрами стоит canonical на главную страницу, а не на их основную версию.
• Конфликт директив: На одной странице одновременно canonical и noindex, или noindex вместе с разрешением в robots.txt.

Срочные действия:

# 1. Проверьте текущий robots.txt, откатите опасные правила:
# ВМЕСТО ЭТОГО (опасно!):
Disallow: /*?*
# ИСПОЛЬЗУЙТЕ (точечно):
Disallow: /*?utm_
Disallow: /*?gclid=
Disallow: /*?sessionid=

# 2. Проверьте канонические ссылки на ключевых страницах:
# Правильно для товара с ID:
<link rel="canonical" href="https://site.com/product/123" />
# НЕПРАВИЛЬНО:
<link rel="canonical" href="https://site.com/" />

Ситуация 2: Дубли не исчезают через 2 месяца

Симптомы: В GSC по-прежнему много "Дублей", параметризованные URL все еще в индексе.

Ситуация 3: Упал трафик на разделы с фильтрами

Симптомы: После настройки clean-param для параметров фильтрации (?color=, ?size=) упал трафик из поиска на эти страницы.

Решение:

• Пересмотрите классификацию параметров. Фильтры, которые создают уникальные подборки товаров (например, ?category=premium-shoes), должны быть индексируемыми.
• Для индексируемых фильтров:
  • Установите canonical на самих себя
  • Добавьте уникальные title и description
  • Создайте уникальный текстовый контент на странице фильтра

Пошаговый план постобработки (первые 90 дней)

Первые 7 дней: активный мониторинг

• Ежедневно: проверяйте отчеты GSC на предмет резких изменений в "Покрытии".
• Через 3 дня: проведите точечный краулинг Screaming Frog для проверки корректности canonical.
• Через 7 дней: сделайте первый запрос в Google site:домен.com inurl:"?параметр=" для ключевых параметров.

30 дней: первый анализ результатов

60-90 дней: финальная оценка и оптимизация

• Полный аудит: запустите полный краулинг сайта с анализом всех оставшихся параметров.
• Анализ логов: изучите логи сервера — какие параметры все еще активно сканируются роботами.
• Оптимизация правил: уточните robots.txt на основе данных логов.
• Документирование: зафиксируйте все примененные правила и их эффект.

Кейс: реальные сроки и результаты

Инструменты для постоянного мониторинга

Бесплатные:

• Google Search Console — основной инструмент
• Яндекс.Вебмастер — для отслеживания clean-param
• Google Analytics — сегменты по URL
• Log File Analyzers (Screaming Frog, ELT) — анализ логов сервера

Платные (но эффективные):

• Screaming Frog — регулярные аудиты с сохранением конфигураций
• Botify, OnCrawl, DeepCrawl — для крупных сайтов
• Ahrefs, Semrush — мониторинг позиций и обратных ссылок на разные версии URL

Чек-лист постобработки (распечатайте и отмечайте)

Золотые правила постобработки

Заключение по мониторингу

Управление GET-параметрами — это не разовая акция, а циклический процесс: Аудит → Внедрение → Мониторинг → Корректировка.

Самая частая ошибка SEO-специалистов — прекращать мониторинг через 2 недели после внедрения. Полный цикл переиндексации занимает 60-90 дней. Именно через этот период можно объективно оценить результаты.