На WordPress часто всплывает одна и та же проблема: сайт нормально работает для пользователя, но в индексе начинают плодиться страницы с параметрами фильтров, сортировок и поиска по каталогу. Для поисковика это обычно мусорные URL, а для владельца сайта — размывание релевантности, дубли и лишняя нагрузка на краулинг.
Сценарий типовой: у вас есть архив, рубрика, каталог записей или кастомный тип, а к нему прикручены параметры вроде ?color=red, ?sort=price, ?brand=asus. Такие страницы могут быть полезны пользователю, но далеко не каждая из них должна попадать в индекс. Ниже — рабочий способ разделить: что оставляем для обхода, что закрываем от индексации, и как не сломать сайт.
Когда это действительно проблема
Не все URL с параметрами нужно запрещать. Ошибка многих сайтов в том, что они закрывают вообще всё подряд, а потом теряют нормальные посадочные страницы. Сначала нужно понять, что именно индексируется и зачем.
Признаки, что фильтры уже создают мусор в индексе
- в поиске видны URL с параметрами, которые не несут самостоятельной ценности;
- в Google Search Console растёт количество страниц, а полезных переходов с них нет;
- одна и та же страница доступна в десятках комбинаций фильтров;
- внутренние ссылки ведут на URL с параметрами, хотя каноническая версия у страницы одна;
- краулер тратит время на сортировки и фильтры вместо важных разделов.
Что можно закрывать, а что лучше оставить
Если параметр меняет только порядок выдачи, почти всегда это кандидат на noindex. Если параметр формирует осмысленную посадочную страницу, например отдельную категорию по бренду или теме, её лучше оставить индексируемой и оформить как полноценный URL, а не как набор query string.
| Подход | Когда подходит | Минус |
|---|---|---|
| noindex для параметров | Сортировки, технические фильтры, служебные комбинации | Нужно контролировать каноникал и внутренние ссылки |
| robots.txt Disallow | Явно технические URL, которые не должны обходиться | Страница может остаться в индексе без контента, если на неё ссылаются |
Кодом через wp_robots | Нужен точечный контроль на уровне WordPress | Требует аккуратной логики по условиям |
Диагностика: где именно появляются дубли
Перед правками проверьте, какие URL реально индексируются и откуда они берутся. Не стоит закрывать всё наугад.
Что смотреть в первую очередь
- отчёт «Страницы» в Google Search Console;
- результаты поиска по
site:example.ruс параметрами в URL; - логи краулера, если используете Screaming Frog или аналог;
- HTML исходник проблемной страницы: есть ли
rel="canonical"и какой там URL; - какие ссылки генерирует тема, плагин фильтров или блоки в контенте.
Если у вас уже стоит SEO-плагин, проверьте, не конфликтует ли он с ручными мета-тегами. Частая ситуация: плагин ставит canonical на одну версию, а тема или кастомный код добавляют другой.
Пошаговое решение через WordPress-хуки
Самый надёжный вариант для точечной настройки — добавить логику в дочернюю тему или мини-плагин. Тогда вы контролируете, какие параметры считаются техническими, а какие — допустимыми.
Шаг 1. Определите список параметров
Например, сортировка и часть фильтров должны быть закрыты, а брендовый фильтр — нет. Логику лучше строить не по одному параметру, а по списку.
<?php
add_filter('wp_robots', function ($robots) {
$blocked_params = array('sort', 'orderby', 'view', 'price_min', 'price_max');
foreach ($blocked_params as $param) {
if (isset($_GET[$param])) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
break;
}
}
return $robots;
});Этот код добавляет noindex, nofollow на страницы, где присутствует один из указанных параметров. Для некоторых сайтов nofollow может быть слишком жёстким — тогда оставьте только noindex.
Шаг 2. Добавьте canonical на чистую версию URL
Если страница с параметрами должна существовать для пользователя, но не для индекса, canonical должен указывать на базовую версию без query string.
<?php
add_filter('get_canonical_url', function ($canonical, $post) {
if (is_admin() || ! is_singular()) {
return $canonical;
}
if (! empty($_GET)) {
return remove_query_arg(array_keys($_GET), $canonical);
}
return $canonical;
}, 10, 2);Этот пример не универсален для всех типов страниц, но для обычных записей и страниц помогает убрать параметрические дубли. Если у вас архивы или кастомные таксономии, логику лучше адаптировать отдельно.
Шаг 3. Закройте технические параметры в robots.txt только при необходимости
Robots.txt не заменяет noindex, но может снизить лишний обход. Используйте его только для явно технических URL, когда вы понимаете последствия.
User-agent: *
Disallow: /*?sort=
Disallow: /*?orderby=
Disallow: /*?view=
Важно: если страница уже известна поисковику и на неё есть ссылки, один robots.txt не гарантирует удаление из индекса. Поэтому для уже существующих дублей надёжнее сочетать noindex и canonical.
Если фильтры генерирует плагин
У многих фильтровых плагинов есть собственные настройки SEO. Перед тем как писать код, проверьте документацию и интерфейс плагина: иногда можно отключить индексацию параметров без кастомных правок. Но если опции нет или она работает грубо, код остаётся более предсказуемым вариантом.
Практика такая: сначала отключаете индексацию на уровне WordPress, потом проверяете, не создаёт ли плагин свои мета-теги поверх ваших. Если создаёт, нужно либо отключить SEO-часть в самом плагине, либо перенести логику в более ранний/поздний фильтр.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром исходника в браузере. Нужно убедиться, что поисковик видит именно то, что вы задумали.
Чек-лист проверки
- откройте URL с параметром и проверьте наличие
noindexв исходном коде; - убедитесь, что canonical ведёт на чистый URL без параметров;
- проверьте, не закрыт ли случайно полезный посадочный URL;
- прогоните страницу через краулер и посмотрите, не осталось ли конфликтующих мета-тегов;
- в Search Console отправьте страницу на повторную проверку после переобхода.
Если используете браузерный просмотр исходника, ищите именно <meta name="robots" и <link rel="canonical". Иногда плагины вставляют теги динамически, и визуально страница выглядит нормально, но в HTML уже есть конфликт.
Частые ошибки и как их исправить
Закрыли robots.txt, но не поставили noindex
Это одна из самых частых ошибок. Если URL уже известен поисковику, он может остаться в индексе как «URL без контента». Исправление: добавьте noindex и дождитесь переобхода.
Случайно закрыли полезные фильтры
Например, брендовые или тематические фильтры могут быть полноценными посадочными страницами. Если они приводят трафик и имеют уникальный смысл, не закрывайте их автоматически по наличию query string. Лучше перевести их на ЧПУ и оформить как отдельные страницы.
Canonical указывает на несуществующий или другой тип страницы
Так бывает, когда код без проверки удаляет все параметры подряд. В итоге canonical ведёт на URL, который не соответствует содержимому. Исправление: canonical должен указывать на ту же сущность, а не на случайную ближайшую страницу.
Плагин SEO перезаписывает ваши настройки
Если у вас уже стоит SEO-плагин, проверьте порядок фильтров. Иногда проще отключить автоматическую генерацию canonical для конкретного типа страниц, чем бороться с конфликтом в коде.
Безопасность и производительность
Любая логика на $_GET должна быть предсказуемой. Не используйте «магические» проверки на все параметры подряд без списка. Это приводит к тому, что любая служебная ссылка внезапно получает noindex.
С точки зрения производительности лучше не строить тяжёлые проверки на каждом запросе. Достаточно короткого списка параметров и раннего выхода из функции. Если фильтров много, вынесите список в отдельную функцию или конфиг, чтобы не раздувать шаблон.
Если нужно быстро навести порядок на сайте с дублями, иногда удобнее использовать специализированный SEO-плагин с функциями чистки технических страниц и мета-тегов. Например, в Clearfy Pro есть инструменты для удаления дублей и технической оптимизации, но даже в этом случае логику параметров стоит проверять вручную, а не полагаться на общую настройку.
Когда лучше не закрывать страницу, а переделать её
Если параметрическая страница уже получает трафик и решает пользовательскую задачу, не прячьте её от индекса только потому, что это «URL с вопросительным знаком». Иногда правильнее создать отдельную посадочную страницу, перенести на неё контент и сделать нормальную структуру ссылок. Это особенно актуально для брендовых подборок, тематических коллекций и страниц с устойчивым спросом.
Если же страница нужна только как технический промежуточный слой для сортировки и фильтрации, её место не в индексе. В этом случае noindex, canonical и аккуратная внутренняя перелинковка решают задачу без лишнего шума.