Как закрыть от индексации параметры URL в WordPress без потери нужных страниц

Параметры в URL — частая причина мусора в индексе: сортировки, фильтры, UTM-метки, внутренний поиск, служебные параметры плагинов. На сайте это выглядит безобидно, но поисковик может начать обходить десятки почти одинаковых адресов, а в отчётах появятся дубли и «тонкие» страницы.

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

Когда параметры URL становятся проблемой

Сценарий обычно один и тот же: в поиске появляются адреса вида ?sort=price, ?replytocom=1, ?utm_source=..., ?filter_color=red или служебные параметры плагинов. Если страница с параметром не несёт отдельной ценности, её индексирование почти всегда лишнее.

Типичные признаки

• в Google Search Console растёт число страниц с параметрами;
• в отчётах по обходу видны URL, которые не должны ранжироваться;
• одна и та же страница доступна по нескольким адресам;
• в логах или аналитике много заходов на URL с UTM, но эти адреса попадают в индекс;
• поисковик выбирает неканоническую версию страницы.

Диагностика: какие параметры реально мешают

Сначала не закрывайте всё подряд. Нужна короткая инвентаризация: какие параметры меняют контент, а какие только создают альтернативный адрес. Для этого достаточно посмотреть URL в поисковой выдаче, в логах сервера, в Search Console и в отчёте по страницам сайта.

Что проверить вручную

• открывается ли страница без параметра и с параметром одинаково;
• меняется ли контент при добавлении параметра;
• есть ли у страницы корректный rel="canonical";
• не используется ли параметр для реальной навигации, например фильтра каталога или пагинации;
• не нужен ли этот URL для внешней интеграции или аналитики.

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

Как закрыть параметры URL: рабочие варианты

Есть три практических подхода: через robots.txt, через noindex на уровне ответа или шаблона, и через каноникализацию. У каждого способа свои ограничения.

Вариант 1: запретить обход через robots.txt

Это уместно для служебных параметров, которые не должны обходиться вообще. Например, если у вас есть технические URL, не предназначенные для пользователей. Но не стоит использовать robots.txt как универсальный способ скрыть всё подряд: если URL уже в индексе, одного запрета на обход может быть недостаточно.

User-agent: *
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?sort=

Такой вариант работает только как часть общей схемы. Для UTM-меток он полезен не всегда: поисковики могут всё равно увидеть ссылки из внешних источников. Поэтому для маркетинговых параметров чаще важнее каноникал и отсутствие внутренних ссылок с UTM.

Вариант 2: отдать noindex для страниц с параметрами

Если страница должна открываться пользователю, но не попадать в индекс, лучше использовать noindex, follow. В WordPress это можно сделать на уровне шаблона или через хук wp_robots, который позволяет добавить директивы в robots-мета.

<?php
add_filter( 'wp_robots', function( $robots ) {
    if ( isset( $_GET['sort'] ) || isset( $_GET['replytocom'] ) ) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }

    return $robots;
} );

Этот код — пример для темы или небольшого mu-plugin. Он не должен быть слепо универсальным: сначала проверьте, что условие действительно ловит только мусорные параметры. Если добавить слишком широкую проверку, можно случайно закрыть важные страницы.

Вариант 3: задать канонический URL

Если параметр меняет только представление страницы, а не её смысл, canonical часто лучше, чем запрет индексации. Поисковик видит альтернативный адрес, но понимает, что основная версия — без параметра.

<?php
add_filter( 'get_canonical_url', function( $canonical, $post ) {
    if ( is_singular() && ! empty( $_GET ) ) {
        $canonical = get_permalink( $post );
    }

    return $canonical;
}, 10, 2 );

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

Пошаговое решение для WordPress

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

1. Составьте список параметров, которые не должны индексироваться.
2. Проверьте, не используются ли они в навигации, фильтрах или внешних ссылках.
3. Для служебных параметров добавьте запрет обхода в robots.txt.
4. Для открывающихся, но не нужных в индексе страниц добавьте noindex.
5. Для альтернативных версий одной и той же страницы задайте canonical на основной URL.
6. Уберите внутренние ссылки с параметрами, если они не нужны пользователю.
7. Переобходите важные страницы через Search Console и отслеживайте результат.

Если нужен точечный контроль по шаблонам

Иногда удобнее закрывать не по имени параметра, а по типу страницы. Например, все результаты внутреннего поиска или страницы сортировки. Для этого можно использовать условные теги WordPress и проверять конкретный запрос.

<?php
add_action( 'wp_head', function() {
    if ( is_search() || isset( $_GET['sort'] ) ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
} );

Но если у вас уже используется SEO-плагин, сначала проверьте его настройки. Часто он умеет управлять robots-мета и canonical без кастомного кода. Код нужен тогда, когда стандартных настроек не хватает.

Как проверить, что решение сработало

Проверка должна быть не формальной, а по факту. Откройте страницу с параметром и посмотрите исходный код: должен быть либо noindex, либо canonical на чистый URL, либо отсутствие индексации по правилам robots.txt — в зависимости от выбранного метода.

Чек-лист проверки

• страница с параметром открывается без ошибки 404, если она нужна пользователю;
• в исходном коде есть нужный meta robots или canonical;
• внутренние ссылки ведут на чистый URL без лишних параметров;
• в Search Console URL с параметром не растёт как отдельная индексируемая страница;
• основная страница сохраняет позиции и не теряет канонический статус;
• в логах нет массового обхода мусорных адресов после изменений.

Если вы используете Search Console, проверьте конкретный URL через инструмент проверки. Для страниц с noindex важно убедиться, что поисковик действительно видит мета-тег, а не блокировку в robots.txt, которая мешает обходу.

Частые ошибки и как их исправить

Закрыли параметр в robots.txt, но URL остался в индексе

Это нормальная ситуация. Запрет на обход не равен удалению из индекса. Если URL уже известен поисковику, добавьте noindex или canonical, а затем дождитесь переобхода.

Поставили noindex на все URL с параметрами

Так можно случайно закрыть полезные страницы фильтра или сортировки. Разделяйте параметры по смыслу: трекинг и служебные — отдельно, пользовательские фильтры — отдельно.

Canonical указывает на главную, а не на исходную страницу

Это частая ошибка при шаблонной настройке SEO-плагина или темы. Canonical должен вести на наиболее близкую основную версию страницы, а не на случайный «главный» адрес.

Внутренние ссылки продолжают генерировать параметры

Даже правильный noindex не спасёт, если меню, блоки или кнопки массово создают URL с параметрами. Проверьте шаблоны, виджеты и плагины, которые добавляют UTM или служебные хвосты в ссылки.

Безопасность и производительность: что учесть

Чем меньше мусорных URL обходится поисковиком и пользователями, тем меньше лишней нагрузки на сайт. Это не магическая оптимизация, но на больших проектах с фильтрами и параметрами она заметна в логах и отчётах.

• не открывайте индексирование для страниц, которые создаются только для технических нужд;
• не используйте слишком общий паттерн в robots.txt, если он может задеть важные URL;
• проверяйте, не создаёт ли плагин фильтров бесконечные комбинации параметров;
• для кастомного кода выносите логику в mu-plugin, а не в файл темы, если тема часто меняется;
• после изменений отслеживайте не только индекс, но и серверные логи: иногда проблема остаётся на уровне обхода, даже если в выдаче всё выглядит нормально.

Если нужен более широкий технический аудит дублей и служебных страниц, имеет смысл смотреть в сторону инструментов, которые помогают чистить SEO-следы и управлять индексацией на уровне сайта. Например, в Clearfy Pro есть набор функций для технической чистки WordPress, но применять его стоит только после проверки, какие именно URL у вас создают шум.

Главная идея простая: закрывать нужно не «всё с вопросительным знаком», а конкретные сценарии. Тогда вы убираете мусор из индекса, не ломая фильтры, поиск и реальные посадочные страницы.