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

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

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

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

Сначала стоит проверить, что речь именно о дублях, а не о нормальных страницах, которые должны индексироваться. Типичный сценарий: у категории есть страницы /category/news/, /category/news/page/2/, а ещё фильтр по тегу или параметру сортировки вроде ?orderby=popular или ?color=red. Если такие URL попали в индекс, поисковик может тратить обход на бесполезные варианты.

Что смотреть в первую очередь

отчёт по страницам в Google Search Console;
результаты поиска по шаблону site:example.com inurl:page/ и site:example.com inurl:?;
логи сервера или отчёты краулера, если есть доступ;
HTML-код страниц: есть ли там каноникал, robots и ссылки на пагинацию.

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

Как выбрать способ: noindex, canonical или запрет генерации

Не все методы одинаково полезны. Для пагинации и фильтров часто путают noindex и canonical. Это разные инструменты.

Подход	Когда применять	Плюс	Минус
`noindex,follow`	Для служебных страниц, которые не должны ранжироваться	Страница остаётся доступной для обхода ссылок	Не решает проблему дублей полностью, если URL активно генерируются
`rel=canonical`	Когда есть близкая основная версия страницы	Подсказывает поисковику основную страницу	Не всегда срабатывает для параметров и сложных фильтров
Убрать генерацию URL	Когда параметр не нужен пользователю и SEO	Самый чистый вариант	Нужно править код или настройки темы/плагина

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

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

1. Закрыть пагинацию архивов от индексации

Для страниц /page/2/ и дальше часто достаточно оставить их доступными для обхода, но не давать им индексироваться. Это особенно полезно для категорий, тегов и архивов автора.

add_action('wp_head', function () {
    if (is_paged()) {
        echo "<meta name=\"robots\" content=\"noindex,follow\" />\n";
    }
}, 1);

Этот вариант простой, но его лучше использовать только если тема или SEO-плагин не добавляют такой же тег уже сами. Дублировать robots-теги не нужно.

2. Убрать из индекса страницы с параметрами сортировки и фильтра

Если сайт генерирует URL с параметрами в строке запроса, можно точечно закрыть их от индексации. Например, для ?orderby= и ?filter_:

add_action('wp_head', function () {
    if (empty($_GET)) {
        return;
    }

    $blocked_params = ['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 без лишних параметров, если содержимое не уникально. В WordPress это можно сделать через фильтр wp_get_canonical_url или через SEO-плагин, если он уже управляет canonical.

add_filter('wp_get_canonical_url', function ($canonical, $post) {
    if (is_admin() || empty($canonical)) {
        return $canonical;
    }

    if (!empty($_GET['orderby']) || !empty($_GET['filter_color']) || !empty($_GET['filter_size'])) {
        return remove_query_arg(['orderby', 'filter_color', 'filter_size']);
    }

    return $canonical;
}, 10, 2);

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

4. Убрать лишние ссылки из шаблона и виджетов

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

Для меню и блоков фильтрации проверьте:

не создаются ли отдельные ссылки на каждый параметр;
не дублируются ли фильтры в сайдбаре и над списком записей;
не открываются ли параметры в новых URL без необходимости;
не попадают ли такие ссылки в XML sitemap.

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

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

Откройте страницу пагинации или URL с параметром.
Проверьте исходный код: должен быть один корректный meta robots и один canonical.
Убедитесь, что canonical не содержит лишних параметров.
Проверьте заголовок ответа через curl -I или DevTools, если закрываете URL на уровне сервера.
Отправьте страницу на повторную проверку в Search Console, если она уже была в индексе.

Пример быстрой проверки через консоль:

curl -s https://example.com/category/news/page/2/ | grep -iE 'robots|canonical'

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

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

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

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

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

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

Дублируют управление robots в теме и SEO-плагине

Если у вас уже стоит Yoast SEO, Rank Math или похожий плагин, не вешайте второй слой логики в wp_head без проверки. Два разных источника canonical и robots часто дают конфликт. Сначала посмотрите, что уже выводит плагин, и только потом добавляйте код.

Используют canonical на главную для всех дублей

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

Что делать для безопасности и производительности

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

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

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

Когда код лучше плагина, а когда наоборот

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

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