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

На WordPress часто всплывает одна и та же проблема: сайт начинает отдавать в поиск десятки URL с параметрами вроде ?s=, ?orderby=, ?filter=, ?replytocom= или кастомными параметрами от темы и плагинов. Для пользователя это просто временный адрес, а для поисковика — отдельная страница. В итоге в индексе появляются дубли, а краулинговый бюджет уходит на мусор.

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

Когда проблема действительно есть

Сначала не трогайте robots.txt наугад. Проверьте, какие URL реально попадают в индекс и откуда они берутся. Обычно сигналами служат:

• в site:example.com видны страницы с параметрами;
• в Search Console растёт число «Просканировано, но не проиндексировано» или «Дубликат, Google выбрал другой канонический URL»;
• в логах или аналитике заметны заходы на URL с ?s=, ?orderby=, ?filter_;
• на сайте есть поиск, фильтры, сортировка, AJAX-виджеты или страницы с UTM-параметрами, которые становятся отдельными адресами.

Какие параметры чаще всего создают дубли

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

• s — поиск по сайту;
• orderby, order — сортировка;
• filter_*, pa_* — фильтры и атрибуты;
• replytocom — ссылки на комментарии;
• служебные параметры плагинов, которые меняют только вид выдачи или списка.

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

Что выбрать: код, плагин или настройка шаблона

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

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

Пошаговое решение через код

Самый надёжный вариант — явно сказать WordPress, какие страницы с параметрами не должны индексироваться, и при необходимости добавить canonical на чистый URL. Для этого удобно использовать wp_robots и wp_head.

1. Закрываем страницы поиска и служебные параметры от индексации

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

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( is_search() ) {
        $robots['noindex']  = true;
        $robots['nofollow'] = true;
    }

    $blocked_params = array( 'replytocom', 'orderby', 'order' );

    foreach ( $blocked_params as $param ) {
        if ( isset( $_GET[ $param ] ) ) {
            $robots['noindex'] = true;
            break;
        }
    }

    return $robots;
} );

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

2. Для параметров фильтра добавляем canonical на чистый URL

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

<?php
add_action( 'wp_head', function() {
    $params = array( 'replytocom', 'orderby', 'order' );

    foreach ( $params as $param ) {
        if ( isset( $_GET[ $param ] ) ) {
            $canonical = home_url( add_query_arg( array(), $GLOBALS['wp']->request ) );
            echo '<link rel="canonical" href="' . esc_url( $canonical ) . '" />' . "\n";
            break;
        }
    }
}, 1 );

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

3. Если нужно снизить обход мусорных URL, ограничиваем их в robots.txt

Это не замена noindex, а дополнительный слой. Он помогает уменьшить количество обходов, но не удаляет уже найденные URL из индекса сам по себе.

User-agent: *
Disallow: /*?orderby=
Disallow: /*?replytocom=
Disallow: /*?filter_

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

Если удобнее через плагин

Когда технических страниц много, а код в теме трогать не хочется, проще использовать SEO-плагин или инструмент для чистки дублей. Важный критерий — возможность управлять canonical, noindex и мета-тегами без костылей. Для типовой чистки сайта это часто быстрее, чем писать всё вручную.

Но даже при использовании плагина проверьте:

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

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

Проверка нужна не только в исходном коде страницы. Смотрите на результат с точки зрения поисковика и браузера.

1. Откройте URL с параметром, например /search/?s=test или ?orderby=price.
2. Проверьте исходный код страницы: должен быть noindex или canonical на чистый URL, если это предусмотрено логикой.
3. Убедитесь, что страница открывается для пользователя и не отдаёт 404 без причины.
4. В Search Console отправьте URL на проверку и посмотрите, как Google видит мета-теги.
5. Через несколько дней проверьте, уменьшается ли число дублей в отчётах по индексированию.

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

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

Ставят noindex на всё подряд

Это самая неприятная ошибка. Иногда разработчик добавляет условие слишком широко, и под раздачу попадают не только страницы с параметрами, но и нормальные архивы, посты или категории. Исправление простое: сузить условие до конкретных query vars и протестировать несколько URL вручную.

Пытаются решить всё через robots.txt

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

Ломают фильтры для пользователей

Иногда после внедрения правил перестают работать сортировка, поиск или AJAX-фильтры. Обычно причина в том, что в коде перепутали индексацию и функциональность. Роботам можно запретить индексацию, но нельзя ломать сам URL, если он нужен посетителю.

Не учитывают кэш и CDN

После правки страницы с параметрами могут продолжать отдавать старые мета-теги из кэша. Очистите серверный кэш, плагин кэширования и CDN, если он есть. Иначе проверка будет показывать старый результат.

Чек-лист перед публикацией

• Определены конкретные параметры, которые создают дубли.
• Для страниц поиска и служебных URL добавлен noindex.
• Для параметров, не меняющих контент, настроен canonical на чистый адрес.
• Robots.txt не блокирует важные страницы случайно.
• После правок очищен весь кэш.
• Проверка выполнена на живом URL с параметром и в Search Console.

Когда лучше не закрывать параметр полностью

Если параметр формирует полезную посадочную страницу, например отдельную выдачу по категории, бренду или теме, не спешите ставить noindex. В таких случаях лучше сделать нормальную страницу архива, задать ей понятный title, description и canonical, а параметр использовать только как технический механизм. Иначе можно случайно убрать из индекса страницу, которая реально приносит трафик.

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