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

Страницы фильтров, сортировок и параметров в WordPress часто появляются сами: поиск по сайту, архивы с query string, страницы с сортировкой по цене или дате, результаты внутреннего поиска. Для пользователя это полезно, а для индексации — источник дублей, мусорных URL и лишней нагрузки на краулинг.

Типичный сценарий: в Google начинают всплывать адреса вида ?s=, ?orderby=, ?filter_ или страницы с параметрами, которые не несут самостоятельной ценности. При этом полностью ломать фильтр нельзя: он нужен посетителям, а иногда и для SEO-страниц категорий.

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

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

Признаки, что фильтры уже мешают индексации

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

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

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

Перед правками откройте список страниц в Search Console и посмотрите, какие шаблоны URL попадают в индекс. Дополнительно проверьте серверные логи или хотя бы результаты поиска по сайту через site:example.com с параметрами в адресе. Это помогает понять, где источник дублей: тема, плагин фильтрации, встроенный поиск или ручные ссылки.

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

Рабочая схема: что закрывать, а что оставлять

Самый безопасный подход — разделить URL на три группы:

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

Способ 1. Закрыть параметры через robots.txt

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

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

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

Способ 2. Добавить noindex для поисковых и фильтрующих страниц

Для WordPress это чаще всего самый практичный вариант. Нужно отдать поисковым страницам и техническим параметрам мета-тег noindex, follow, чтобы поисковик не включал их в индекс, но мог проходить по ссылкам дальше.

Если вы используете SEO-плагин, проверьте, умеет ли он задавать правила для архивов поиска и страниц с параметрами. Если нет, можно добавить логику в тему или мини-плагин. Ниже пример для внутреннего поиска и некоторых query string:

<?php
add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex, follow">' . "\n";
        return;
    }

    $blocked_params = array('orderby', 'filter_color', 'filter_size');
    foreach ($blocked_params as $param) {
        if (isset($_GET[$param])) {
            echo '<meta name="robots" content="noindex, follow">' . "\n";
            break;
        }
    }
}, 1);

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

Способ 3. Настроить canonical для страниц с параметрами

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

Пример для страниц поиска: canonical ведёт на базовый URL без параметров.

<?php
add_filter('get_canonical_url', function ($canonical) {
    if (is_search()) {
        return home_url('/');
    }

    if (!empty($_GET['orderby']) || !empty($_GET['filter_color']) || !empty($_GET['filter_size'])) {
        return home_url(add_query_arg(array(), $GLOBALS['wp']->request));
    }

    return $canonical;
});

Здесь важно не переусложнить логику. Если у вас уже есть SEO-плагин, сначала проверьте его настройки canonical. Дублировать правила в теме и плагине — частая причина конфликтов.

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

1. Составьте список параметров, которые реально создают дубли.
2. Проверьте, есть ли среди них полезные посадочные страницы.
3. Добавьте noindex, follow для внутреннего поиска и технических фильтров.
4. Оставьте canonical на основной URL для сортировок и неключевых параметров.
5. Исключите технические URL из sitemap, если они туда попали.
6. Проверьте, не создаёт ли плагин фильтра отдельные архивы или таксономии.

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

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

• откройте проблемный URL и убедитесь, что в <head> есть noindex, follow или корректный canonical;
• проверьте, что страницы с параметрами исчезли из XML-карты сайта;
• в Search Console отправьте URL на повторную проверку;
• посмотрите, уменьшилось ли число дублей в отчётах по индексированию;
• убедитесь, что фильтр по-прежнему работает для пользователей.

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

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

Закрыли фильтр в robots.txt, но URL остались в индексе

Это ожидаемо. Robots.txt не удаляет уже известные страницы. Добавьте noindex или верните 404/410 для действительно ненужных адресов, если они больше не должны существовать.

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

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

Canonical указывает на саму страницу с параметрами

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

Фильтр генерирует отдельные страницы, но их не видно в настройках SEO-плагина

Значит, проблема в теме или в плагине фильтрации. Проверьте шаблоны архива, таксономии и rewrite rules. Иногда проще отключить генерацию лишних URL на уровне плагина, чем лечить последствия в индексации.

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

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

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

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

Если нужна проверка после внедрения, сделайте короткий чек-лист:

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

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