Страницы фильтров и сортировок в WordPress часто появляются сами по себе: архивы с параметрами, результаты поиска по сайту, страницы с ?orderby=, ?filter_, ?s= и похожими хвостами. Если их не контролировать, поисковик начинает обходить десятки почти одинаковых URL, а в индексе остаются мусорные варианты вместо нужных страниц.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы оставить полезные страницы доступными для пользователей и убрать из индекса технические дубли. Ниже — рабочая схема: как диагностировать проблему, что закрывать, чем это делать и как проверить результат.
Когда фильтры становятся проблемой для индексации
Сценарий обычно выглядит одинаково: на сайте есть каталог, архив записей, поиск по сайту или страница с фильтрами по таксономиям. Для пользователя это удобно, а для поисковика — источник почти одинаковых страниц. Особенно часто это случается, если:
- фильтры меняют URL через GET-параметры;
- сортировка создаёт отдельные адреса;
- поиск по сайту индексируется как обычная страница;
- один и тот же контент доступен по нескольким путям;
- в sitemap попадают технические URL.
Если проблема уже есть, в Search Console обычно видно рост страниц с параметрами, а в отчёте по индексированию — URL, которые не должны были попадать в поиск вообще.
Диагностика: какие URL нужно закрывать, а какие оставить
Перед правками нужно разделить URL на три группы. Это важнее, чем сразу ставить noindex на всё подряд.
1. Полезные страницы
Это обычные записи, страницы, рубрики, теги, посадочные страницы и любые URL, которые должны ранжироваться. Их не трогаем без отдельной причины.
2. Технические и дублирующие URL
Сюда обычно попадают:
- поиск по сайту:
?s=; - сортировки:
?orderby=; - пагинация фильтра, если она создаёт мусорные варианты;
- страницы с несколькими параметрами, которые не несут уникального смысла;
- варианты с UTM и другими трекинговыми хвостами, если они индексируются как отдельные URL.
3. Пограничные страницы
Это фильтры, которые могут быть полезны пользователю, но не обязаны индексироваться. Например, архив по конкретной таксономии или подборка с осмысленным набором товаров/записей. Такие URL лучше оценивать отдельно: иногда им нужен noindex, иногда — каноникал на основную страницу, иногда — вообще отдельная посадочная страница с уникальным текстом.
Что выбрать: noindex, robots.txt или canonical
У каждого инструмента своя задача. Ошибка многих сайтов в том, что они пытаются решить всё одним способом.
| Подход | Когда использовать | Ограничение |
|---|---|---|
noindex | Страница должна открываться пользователю, но не попадать в индекс | Не убирает URL из обхода мгновенно, нужен повторный обход |
robots.txt | Нужно ограничить обход технических разделов | Не гарантирует удаление уже проиндексированных URL |
rel="canonical" | Есть несколько версий одной и той же страницы | Не подходит для реально разных страниц с разным смыслом |
Для страниц фильтров чаще всего рабочая связка такая: noindex, follow для самих страниц и canonical на основную версию там, где это действительно дубликат. robots.txt используют аккуратно, если нужно снизить лишний обход, но не вместо индексационных сигналов.
Пошаговое решение через код темы или мини-плагин
Если у вас нет SEO-плагина, который уже умеет управлять мета-тегами, можно добавить логику в мини-плагин. Это безопаснее, чем править functions.php активной темы: при обновлении тема не затрёт код.
Ниже пример, который ставит noindex, follow на поиск и на URL с типичными фильтрами в query string. Список параметров нужно адаптировать под ваш сайт.
<?php
/**
* Plugin Name: WPOne Filter Noindex
*/
add_filter('wp_robots', function (array $robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
return $robots;
}
if (!empty($_GET['orderby']) || !empty($_GET['filter_color']) || !empty($_GET['filter_size'])) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});
add_filter('wpseo_canonical', function ($canonical) {
if (is_search()) {
return home_url('/');
}
return $canonical;
});Если вы не используете Yoast SEO, фильтр wpseo_canonical не сработает, и это нормально. В таком случае canonical лучше задавать через SEO-плагин или отдельную логику на уровне шаблона.
Для более точного контроля можно добавить canonical прямо в <head> через wp_head, но только если вы понимаете, что делаете и не конфликтуете с SEO-плагином.
<?php
add_action('wp_head', function () {
if (!is_search() && empty($_GET['orderby']) && empty($_GET['filter_color'])) {
return;
}
echo '<link rel="canonical" href="' . esc_url(home_url('/')) . '" />' . "\n";
}, 1);Здесь важен порядок: если SEO-плагин уже выводит canonical, не дублируйте тег вручную. Два canonical на странице — частая причина путаницы.
Если фильтры генерируются плагином
У многих плагинов фильтрации есть собственные настройки индексации. Это предпочтительнее, чем пытаться ловить параметры через $_GET в коде. Проверьте, умеет ли плагин:
- отключать индексирование страниц фильтров;
- ставить canonical на базовую страницу архива;
- не добавлять фильтры в sitemap;
- не создавать отдельные страницы для пустых комбинаций фильтров.
Если плагин этого не умеет, тогда уже имеет смысл добавлять точечные правила в код. Но сначала проверьте настройки самого плагина: часто проблема решается без кастомной разработки.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой в браузере. Нужно проверить именно сигналы для поисковика.
- Откройте проблемный URL с параметром и посмотрите исходный код страницы.
- Убедитесь, что в
<head>естьmeta name="robots" content="noindex,follow"или эквивалентный сигнал от SEO-плагина. - Проверьте canonical: он должен вести на основную версию страницы, а не на сам параметризованный URL.
- Посмотрите, не попал ли URL в sitemap.xml.
- В Search Console отправьте проверку URL и убедитесь, что робот видит нужные директивы.
Если страница уже была в индексе, удаление не произойдёт мгновенно. Нужно дождаться повторного обхода. Для ускорения можно запросить переобход в Search Console, но это не заменяет корректную настройку.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL остались в индексе
Это типичная ошибка. Если поисковик уже знает URL, запрет на обход не всегда убирает его из индекса. Для удаления нужен индексный сигнал: noindex или корректный canonical, а не только Disallow.
Поставили noindex на все страницы фильтра
Так можно случайно убрать полезные посадочные страницы, которые приносят трафик. Сначала отделите технические параметры от страниц с реальным смыслом. Не все фильтры одинаково бесполезны.
Canonical указывает на саму страницу с параметром
Это не решает проблему дублирования. Если URL с ?orderby=price — это просто сортировка, canonical должен вести на чистую версию архива. Если же фильтр меняет смысл страницы, canonical может быть вообще неуместен.
В sitemap попадают технические URL
Тогда поисковик получает от вас прямой сигнал, что эти страницы важны. Проверьте генератор sitemap и исключите параметры, поиск и служебные архивы.
Дубли создаёт сама тема
Иногда тема выводит один и тот же контент в нескольких шаблонах: архив, блок похожих записей, отдельная страница автора, пагинация. В этом случае проблема не в фильтре как таковом, а в архитектуре шаблонов. Тогда уже нужно смотреть на шаблоны, каноникал и структуру архивов.
Чек-лист перед публикацией изменений
- Проверены все типы URL с параметрами, которые реально генерирует сайт.
- Отдельно отмечены страницы, которые должны остаться в индексе.
- Для технических URL задан
noindex, followили другой осмысленный сигнал. - Canonical не конфликтует с SEO-плагином.
- Технические URL не попадают в sitemap.
- После правок проверен исходный код страницы и отчёт в Search Console.
Практика по безопасности и производительности
Не добавляйте логику на основе $_GET без проверки условий и без понимания, какие параметры реально используются. Чем больше «универсальных» правил, тем выше шанс случайно закрыть нужные страницы. Лучше вести короткий список конкретных параметров, чем пытаться угадать все варианты сразу.
Если фильтров много, не делайте тяжёлые проверки на каждом запросе. Для простых условий достаточно стандартных функций WordPress и одного фильтра wp_robots. Это дешевле, чем отдельные SQL-запросы или сложная логика в шаблоне.
Если нужен более широкий набор SEO-инструментов для контроля дублей и технической чистки сайта, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином важно понимать, какие URL вы закрываете и почему — автоматические настройки не заменяют диагностику.
Когда схема настроена правильно, в индексе остаются только те страницы, которые действительно нужны. Остальное перестаёт отвлекать краулинговый бюджет и не размазывает релевантность по мусорным URL.