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

Если в поиске всплывают страницы вида ?s=, ?filter=, ?orderby= или другие технические URL, это почти всегда не «проблема индексации вообще», а конкретная ошибка в управлении дублями. На живом сайте такие страницы быстро размывают краулинговый бюджет, плодят мусор в отчётах и иногда перетягивают на себя релевантность у нормальных посадочных страниц.

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

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

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

Типичные симптомы

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

Диагностика: что именно индексируется

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

Проверьте три места:

1. отчёт Страницы в Google Search Console;
2. поиск по оператору site:example.ru с фрагментами параметров;
3. исходный код проблемной страницы на наличие rel="canonical" и meta robots.

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

Пошаговое решение

1. Закройте технические страницы от индексации через meta robots

Для внутренних поисковых страниц и большинства параметров сортировки лучше отдать noindex,follow. Это позволяет не индексировать сам URL, но не ломает переходы по ссылкам на странице.

Вставить это можно через wp_head, если у вас есть чёткое условие для нужных шаблонов. Пример для внутреннего поиска и страниц с параметром orderby:

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

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

2. Настройте canonical на основную версию страницы

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

Пример для условного фильтра по параметру filter_color:

<?php
add_filter('get_canonical_url', function ($canonical) {
    if (isset($_GET['filter_color'])) {
        return remove_query_arg(['filter_color', 'page']);
    }
    return $canonical;
});

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

3. Ограничьте генерацию мусорных параметров на уровне шаблона или плагина

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

Практически это выглядит так:

• не выводить в HTML ссылки с параметрами, если они не нужны для SEO;
• оставить фильтр для пользователя, но не делать его отдельной страницей;
• для сортировки и технических параметров использовать noindex и canonical;
• для реально полезных посадочных страниц создавать отдельные статические URL.

4. Добавьте запрет в robots.txt только как вспомогательную меру

Если бот тратит ресурсы на обход бесполезных параметров, можно дополнительно закрыть их в robots.txt. Но это не замена noindex. Запрет полезен, когда нужно уменьшить обход, а не удалить уже известные URL из индекса.

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

Такой вариант нужно проверять на вашем сайте: шаблоны параметров зависят от структуры URL и от того, как именно работает тема или плагин фильтрации. Не копируйте правила вслепую, если у вас ЧПУ построены иначе.

Сравнение подходов

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

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

Дальше проверьте:

• в Search Console — статус URL через проверку конкретной страницы;
• в индексе — исчезают ли страницы с параметрами по мере переобхода;
• в логах сервера — сократился ли обход бесполезных комбинаций;
• в выдаче — не остаются ли старые дубль-URL по брендовым и тематическим запросам.

Если URL всё ещё виден в индексе, но уже помечен как noindex, это нормальная переходная ситуация. Поисковику нужно время, чтобы переобойти страницу и обновить статус.

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

Закрыли URL в robots.txt и ждёте удаления

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

Ставят noindex на все страницы подряд

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

Canonical ведёт на нерелевантную страницу

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

Не учитывают пагинацию

Страницы /page/2/ и дальше не всегда нужно закрывать. Если это нормальная пагинация архива, она может быть полезна для обхода и навигации. Закрывать её без причины — плохая идея. Проблема обычно не в пагинации как таковой, а в сочетании пагинации с параметрами фильтра.

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

Если фильтры и поиск создают много параметров, это влияет не только на SEO, но и на нагрузку. Особенно если запросы к базе строятся без кэширования. Для таких сценариев полезно:

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

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

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

• Проблемный URL открыт в браузере и проверен в исходнике.
• На странице стоит корректный noindex,follow или осознанный canonical.
• В robots.txt нет случайного запрета на полезные разделы.
• Search Console показывает нужный статус после переобхода.
• Основные страницы не потеряли индексацию из-за слишком широкого правила.

Если после внедрения решение работает только частично, почти всегда причина в том, что закрыли симптом, но не источник URL. Тогда нужно смотреть не в SEO-плагин, а в логику темы, фильтра или внутреннего поиска: кто генерирует ссылку, зачем она доступна в HTML и можно ли убрать её из публичного обхода.