Как закрыть от индексации страницы с параметрами в WordPress

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

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

Когда проблема уже есть

Сначала стоит понять, что именно индексируется. В Search Console и в логах сервера обычно видно один из сценариев: в выдаче появляются URL вида ?s=, ?orderby=, ?filter_, ?utm_ или адреса с параметрами, которые вообще не должны жить отдельно. Иногда проблема заметна только по росту числа страниц в индексе без роста трафика.

Что проверить до правок

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

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

Какие параметры можно закрывать, а какие нельзя

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

Пошаговое решение без лишнего риска

1. Закройте служебные параметры через noindex

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

<?php
add_action('wp_head', function () {
    if (is_admin()) {
        return;
    }

    $noindex_params = array('s', 'orderby', 'filter_color', 'filter_size');

    foreach ($noindex_params as $param) {
        if (isset($_GET[$param]) && $_GET[$param] !== '') {
            echo '<meta name="robots" content="noindex,follow" />' . "\n";
            break;
        }
    }
});

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

2. Добавьте канонический URL без параметров

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_admin() || !is_singular()) {
        return $canonical;
    }

    $remove_params = array('utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content');

    if (empty($_GET)) {
        return $canonical;
    }

    $url = home_url(add_query_arg(array(), $GLOBALS['wp']->request));

    foreach ($remove_params as $param) {
        if (isset($_GET[$param])) {
            $canonical = get_permalink($post);
            break;
        }
    }

    return $canonical;
}, 10, 2);

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

3. Снизьте обход мусорных URL в robots.txt

robots.txt не удаляет страницы из индекса, зато помогает не тратить crawl budget на очевидный мусор. Это полезно для параметров поиска и сортировки, если они генерируют много адресов.

User-agent: *
Disallow: /*?orderby=
Disallow: /*?s=
Disallow: /*?utm_
Disallow: /*?filter_

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

Если у вас фильтры, поиск или сортировка

Самый частый конфликт возникает на сайтах с каталогом, блогом и внутренним поиском. Пользовательский сценарий требует параметров, а SEO — не плодить дубли. В таких случаях лучше разделять логику: служебные параметры закрывать, а полезные фильтры либо оставлять с каноникалами, либо выносить в отдельные ЧПУ-страницы, если они действительно нужны для поиска.

• Поиск по сайту с ?s= обычно не нужен в индексе.
• Сортировка по цене, дате, популярности чаще всего тоже не нужна.
• Фильтры по цвету, размеру, тегам и таксономиям нужно оценивать по трафику и спросу.
• UTM-метки и рекламные хвосты почти всегда должны указывать на чистый канонический URL.

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

После внедрения не ограничивайтесь визуальной проверкой HTML. Нужно пройтись по нескольким уровням: исходный код страницы, ответ сервера и индексация в Search Console.

1. Откройте URL с параметром в браузере и проверьте исходный код на наличие <meta name="robots" content="noindex,follow" />.
2. Проверьте canonical: он должен вести на чистую страницу без служебных параметров.
3. В Search Console отправьте URL на проверку и посмотрите, как робот видит страницу.
4. Через несколько обходов проверьте, исчез ли параметрический URL из отчётов по индексированию.

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

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

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

Это типичная ошибка. Если страница уже в индексе, одного запрета на обход мало. Нужен доступ робота к странице, чтобы он увидел noindex или canonical.

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

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

Canonical ведёт на саму себя с параметром

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

Смешали логику темы и плагина

Когда часть правил живёт в теме, а часть — в SEO-плагине, потом сложно понять, что именно отдает страницу в индекс. Лучше выбрать один источник правды: либо настройки плагина, либо код в небольшом mu-plugin.

Практика по безопасности и производительности

Чем больше параметров вы обрабатываете на лету, тем внимательнее нужно относиться к валидации. Не используйте сырые значения из $_GET без проверки, если на их основе строите логику вывода. Для простого определения наличия параметра достаточно isset(), но для сравнения значений лучше использовать явную нормализацию.

Если сайт большой, не плодите тяжёлые условия в wp_head на каждой странице. Логика должна быть короткой и предсказуемой. Для сложных сценариев удобнее вынести её в отдельный мини-плагин или mu-plugin, чтобы не потерять правки при смене темы.

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

Короткий чек-лист перед публикацией

• Список параметров разделён на мусорные и рабочие.
• Для мусорных параметров добавлен noindex,follow.
• Canonical указывает на чистый URL.
• robots.txt не блокирует важные страницы раньше времени.
• В Search Console проверен рендер и статус индексации.
• Нет конфликта между SEO-плагином, темой и кастомным кодом.

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