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

Проблема с тонкими страницами фильтров в WordPress обычно выглядит одинаково: в индексе появляются десятки URL с параметрами, а полезного трафика они не дают. Чаще всего это страницы вида ?sort=, ?filter=, ?page=, ?utm_, а также комбинации, которые создают почти одинаковый контент. Поисковик тратит обход на мусорные адреса, а важные страницы получают меньше внимания.

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

Как понять, что проблема именно в тонких URL

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

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

• отчёт Страницы в Google Search Console: есть ли рост URL с параметрами;
• логи сервера или отчёт по обходу: ходит ли бот по одинаковым страницам с разными query string;
• исходный код страницы: есть ли noindex, canonical и не конфликтуют ли они между собой;
• карта сайта: не попали ли туда URL с параметрами;
• внутренние ссылки: не генерирует ли тема или плагин ссылки на фильтры как на обычные страницы.

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

Какие URL закрывать, а какие нет

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

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

Пошаговое решение: от простого к надёжному

Лучше идти по слоям: сначала исключить мусор из индекса, потом убрать его из внутренней перелинковки, затем проверить canonical и sitemap. Так меньше шансов сломать полезные страницы.

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

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

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

    $query_args = array('sort', 'orderby', 'filter', 'paged', 'page');
    foreach ($query_args as $arg) {
        if (isset($_GET[$arg]) && $_GET[$arg] !== '') {
            echo '<meta name="robots" content="noindex,follow">' . "\n";
            break;
        }
    }
}, 1);

Этот вариант рабочий, но его нужно использовать аккуратно. Если на сайте уже есть SEO-плагин, проверьте, не выводит ли он свой robots meta. Два разных meta name="robots" в одном документе — частая причина путаницы.

Шаг 2. Добавьте canonical на основную версию страницы

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

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

    $remove_args = array('sort', 'orderby', 'filter', 'utm_source', 'utm_medium', 'utm_campaign');
    $current_url = home_url(add_query_arg(array(), $_SERVER['REQUEST_URI']));

    $clean_url = remove_query_arg($remove_args, $current_url);

    return $clean_url ?: $canonical;
}, 10, 2);

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

Шаг 3. Уберите мусорные URL из sitemap

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

Проверьте, не включены ли в sitemap:

• страницы с query string;
• архивы с сортировкой;
• служебные страницы поиска;
• дубли пагинации, если плагин генерирует их отдельно.

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

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

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

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

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

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

Что проверить вручную

1. Откройте URL с параметром и посмотрите исходный код страницы.
2. Убедитесь, что есть только один корректный meta name="robots", если он нужен.
3. Проверьте canonical: он должен вести на ожидаемую чистую страницу.
4. Сравните заголовок, H1 и основной контент с канонической версией.
5. Посмотрите, не осталась ли страница в sitemap.

Если используете Google Search Console, отправьте проблемный URL на проверку через инструмент проверки страницы. После переобхода смотрите, изменился ли статус индексации и исчез ли параметрический адрес из отчётов.

Что проверить через сервер

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

curl -I "https://example.com/catalog/?sort=price"

В ответе ищите X-Robots-Tag, если вы используете его вместо meta-тега, и проверяйте, нет ли неожиданных редиректов на другой URL. Иногда проблема не в индексации, а в том, что фильтр создаёт цепочку редиректов и тормозит обход.

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

Ставят noindex, но оставляют URL в sitemap

Это частая несостыковка. Поисковик получает два сигнала: «не индексируй» и «вот список страниц, которые нужно обходить». В итоге страница может ещё долго висеть в отчётах. Решение простое: убрать такие URL из sitemap и проверить, не генерирует ли их плагин автоматически.

Закрывают всё через robots.txt

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

Ломают пагинацию

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

Подменяют canonical на главную страницу сайта

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

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

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

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

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

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