Внутренний поиск, фильтры по рубрикам, сортировка и параметры в URL часто создают страницы, которые не нужны в поиске. Проблема не в самом наличии таких страниц, а в том, что поисковик тратит на них обход, а в индексе появляются слабые или дублирующие URL. На небольшом сайте это заметно не сразу, но на контентном проекте или каталоге такие страницы быстро разрастаются.
Задача здесь не «закрыть всё подряд», а аккуратно разделить: что должно быть доступно пользователю, что можно сканировать, а что лучше убрать из индекса и не светить в карте сайта.
Когда это действительно проблема
Сначала стоит понять, что именно у вас индексируется. Типичный набор симптомов:
- в поиске видны URL вида
?s=...,?filter=...,?orderby=...; - в отчётах Search Console появляются страницы поиска по сайту с нулевой или слабой ценностью;
- одна и та же категория доступна через несколько комбинаций параметров;
- робот регулярно обходит URL, которые не дают уникального контента;
- в выдаче всплывают страницы с сортировкой, пагинацией фильтра или внутренним поиском.
Если фильтры используются только для навигации и не несут отдельной поисковой ценности, их обычно не имеет смысла индексировать. Но если у вас есть посадочные страницы под важные комбинации фильтров, подход должен быть точечным: одни URL закрываем, другие оставляем и делаем отдельными страницами.
Что проверить до изменений
- Какие параметры реально используются в URL:
s,orderby,filter,min_price,max_priceи т. п. - Есть ли у этих страниц уникальный контент или только список записей.
- Попадают ли они в XML-карту сайта.
- Есть ли на них внутренние ссылки из меню, виджетов, хлебных крошек.
Рабочая схема: что закрывать, а что оставлять
Для большинства сайтов логика такая:
| Тип страницы | Что делать | Почему |
|---|---|---|
Внутренний поиск ?s= | Закрыть от индексации | Это служебные страницы без стабильной ценности |
Сортировки ?orderby= | Обычно закрыть | Одна и та же выборка в разном порядке |
| Фильтры, создающие дубли | Закрыть или канонизировать на основную категорию | Снижают качество индекса |
| Посадочные страницы под важные комбинации | Оставить открытыми | Если у них есть уникальный текст и спрос |
Самый безопасный путь — не пытаться решать всё одним noindex везде. Для служебных URL лучше сочетать несколько мер: убрать из sitemap, не давать лишних внутренних ссылок, при необходимости добавить noindex и корректный canonical.
Пошаговое решение без лишнего риска
1. Уберите служебные страницы из карты сайта
Если у вас SEO-плагин генерирует sitemap, проверьте, не попадают ли туда страницы поиска, архивы с параметрами или технические URL. В нормальной конфигурации внутренний поиск туда не должен попадать вообще.
Если вы используете плагин уровня Clearfy Pro, у него есть инструменты для чистки SEO-мусора и дублей. Но даже без плагина базовая логика одна: в sitemap должны быть только страницы, которые вы хотите видеть в индексе.
2. Закройте внутренний поиск от индексации через robots.txt
Это не заменяет noindex, но помогает сократить обход мусорных URL. Для WordPress можно добавить правило через фильтр robots_txt:
add_filter('robots_txt', function ($output, $public) {
$output .= "\nDisallow: /?s=";
$output .= "\nDisallow: /search/";
return $output;
}, 10, 2);Этот вариант не идеален для всех конфигураций, потому что поисковые URL могут отличаться в зависимости от темы и плагинов. Поэтому сначала проверьте, какой именно формат генерируется у вас.
3. Добавьте noindex,follow для страниц поиска и параметров
Если страница всё же открывается, лучше явно сказать поисковику не индексировать её. Для этого удобно использовать фильтр wp_robots:
add_filter('wp_robots', function (array $robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if (!empty($_GET['orderby']) || !empty($_GET['filter']) || !empty($_GET['s'])) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Здесь есть важный нюанс: не стоит бездумно ставить noindex на все страницы с параметрами, если часть из них у вас реально используется как SEO-лендинги. Лучше ограничить правило только служебными сценариями.
4. Для фильтров с дублями задайте canonical на основную страницу
Если фильтр меняет только сортировку или не создаёт уникального контента, canonical должен вести на базовую категорию или архив без параметров. Это помогает поисковику понять, какая версия основная.
Пример для темы или мини-плагина:
add_filter('get_canonical_url', function ($canonical) {
if (is_search()) {
return home_url('/');
}
if (!empty($_GET['orderby']) || !empty($_GET['filter'])) {
$url = home_url(add_query_arg([], $GLOBALS['wp']->request ?? ''));
return $url;
}
return $canonical;
});Этот код нужно адаптировать под структуру сайта. Если у вас сложные фильтры, canonical лучше формировать аккуратно, без попытки «собрать» URL из случайных глобальных переменных.
Диагностика: как понять, что закрытие сработало
После внедрения не ограничивайтесь визуальной проверкой страницы. Нужно проверить три вещи: мета-роботы, canonical и статус индексации.
- Откройте страницу поиска и страницу с параметром в браузере.
- Посмотрите исходный код и найдите
meta name="robots". - Проверьте, что canonical указывает на нужную базовую страницу.
- В Search Console отправьте URL на проверку и посмотрите, как робот видит страницу.
- Убедитесь, что служебные URL больше не попадают в sitemap.
Если у вас включено кеширование, не забудьте очистить кеш страницы и, при необходимости, CDN. Иначе вы можете проверять уже старую версию HTML.
Что должно быть в исходном коде
Для внутреннего поиска обычно ожидается что-то вроде:
<meta name="robots" content="noindex,follow">
<link rel="canonical" href="https://example.com/">Для фильтра, который вы решили оставить открытым, наоборот, должно быть понятно, что это отдельная страница с уникальной ценностью, а не техническая комбинация параметров.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL всё равно в индексе
Это нормальная ситуация: Disallow запрещает обход, но не гарантирует удаление из индекса, если URL уже известен поисковику. Для удаления нужен noindex или снятие страницы с публикации/ссылок, а иногда и повторная переобходка.
Поставили noindex на все страницы с параметрами
Так легко сломать полезные посадочные страницы. Если у вас есть фильтрованные страницы с трафиком, не закрывайте их автоматически. Сначала разделите параметры на технические и контентные.
Canonical указывает не туда
Часто это происходит, когда тема или SEO-плагин уже генерируют canonical, а вы добавляете второй. В итоге поисковик видит конфликт. Проверьте, нет ли дублирующего вывода canonical в теме, в плагине SEO и в кастомном коде.
Страница закрыта, но продолжает грузить сервер
Если фильтры создают много комбинаций, одного noindex мало. Уберите лишние внутренние ссылки, ограничьте генерацию параметров и проверьте, не создаёт ли плагин фильтрации бесконечные комбинации URL.
Практические советы по безопасности и производительности
Чем меньше мусорных URL видит робот, тем меньше лишней нагрузки на сайт. Но есть и технические детали, которые часто упускают:
- не отдавайте индексируемые страницы поиска через кеш как обычные посадочные страницы;
- не добавляйте служебные URL в XML-sitemap;
- не плодите параметры в ссылках меню и виджетов;
- проверяйте, не создаёт ли тема отдельные архивы на каждый вариант сортировки;
- если используете фильтры, логируйте самые частые параметры и смотрите, какие из них реально нужны.
Если у вас сайт на тяжёлой теме или с большим количеством архивов, иногда проще сначала навести порядок в SEO-настройках и дублях через Clearfy Pro, а уже потом точечно дописывать правила для конкретных URL. Это не отменяет ручную проверку, но уменьшает количество технического мусора, который приходится закрывать отдельно.
Короткий чек-лист перед публикацией изменений
- Проверил, какие URL реально нужно закрыть.
- Убрал служебные страницы из sitemap.
- Добавил
noindex,followтолько для поиска и технических параметров. - Проверил canonical на страницах с фильтрами.
- Очистил кеш сайта и CDN.
- Протестировал исходный код и статус URL в Search Console.
Если после правок в индексе остаются старые служебные страницы, это не всегда ошибка настройки. Поисковику нужно время, чтобы переобойти URL и обновить данные. Но если через проверку видно, что noindex и canonical отдаются корректно, значит базовая часть решения уже работает.