URL с параметрами — типичная причина мусорной индексации в WordPress. Фильтры, сортировки, UTM-метки, внутренний поиск, служебные параметры плагинов — всё это может создавать десятки почти одинаковых страниц. Поисковик тратит обход на лишние адреса, а в отчётах появляются дубли и странные посадочные.
Задача здесь не в том, чтобы «запретить всё подряд», а в том, чтобы отделить полезные параметры от технического шума. Одни URL должны оставаться доступными для пользователей, но не попадать в индекс. Другие лучше вообще не отдавать поисковым роботам. Ниже — рабочая схема без лишней магии.
Когда проблема уже есть: как её распознать
Сначала проверьте, действительно ли индексируются именно параметризованные URL. Самый быстрый способ — поиск по сайту и отчёты в Google Search Console. Ищите адреса с ?, например ?sort=price, ?filter_color=black, ?utm_source=..., ?s=.... Если таких страниц много, а контент на них почти не отличается от основной, это кандидат на закрытие от индексации.
Что обычно создаёт дубли
- фильтры каталога и сортировки;
- параметры внутреннего поиска;
- UTM-метки из рекламы и рассылок;
- служебные параметры плагинов кеша, аналитики, форм;
- страницы пагинации и сортировки, если они настроены неаккуратно.
Важно не путать дубли с полезными посадочными. Если параметр меняет смысл страницы и реально нужен для пользователей, иногда лучше оставить его доступным, но закрыть от индексации через noindex или заголовок X-Robots-Tag.
Что делать: сравнение подходов
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| robots.txt | Нужно ограничить обход, но не всегда индекс | Просто внедрить | Не гарантирует удаление из индекса, если URL уже известен поисковику |
| meta robots noindex | Страница должна открываться, но не индексироваться | Работает точечно | Нужно, чтобы робот мог зайти на страницу и увидеть тег |
| X-Robots-Tag | Нужно закрыть типы ответов или страницы на уровне сервера | Удобно для массовых правил | Чуть сложнее в настройке |
На практике для WordPress чаще всего используют комбинацию: не блокировать важные страницы в robots.txt, а для параметризованных URL ставить noindex,follow. Если нужно, дополнительно ограничивают обход для совсем бесполезных параметров.
Пошаговое решение через код
Если у вас есть доступ к теме или небольшому mu-plugin, можно добавить правило, которое будет ставить noindex для URL с известными параметрами. Это аккуратнее, чем закрывать всё через robots.txt.
<?php
add_action('wp_head', function () {
if (is_admin()) {
return;
}
$params_to_close = array(
'sort',
'orderby',
'filter_color',
'filter_size',
's',
);
foreach ($params_to_close as $param) {
if (isset($_GET[$param]) && $_GET[$param] !== '') {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
break;
}
}
}, 1);Этот вариант подходит, если параметры известны заранее и вы хотите закрывать только конкретные сценарии. Для UTM-меток обычно лучше не трогать саму страницу, потому что они не меняют контент, а лишь размечают источник трафика. Но если у вас рекламные ссылки создают индексируемые копии, можно закрыть их отдельно.
Вариант через X-Robots-Tag для служебных параметров
Если нужно закрывать не только HTML-страницы, но и ответы с определёнными параметрами, удобнее использовать заголовок. Это особенно полезно, когда один и тот же шаблон отдает много вариантов страницы.
<?php
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$close_params = array('sort', 'orderby', 'filter_color', 'filter_size');
foreach ($close_params as $param) {
if (!empty($_GET[$param])) {
header('X-Robots-Tag: noindex, follow', true);
break;
}
}
});Такой способ работает только до вывода контента, поэтому не вставляйте его слишком поздно. Если заголовки уже отправлены, правило не сработает.
Что писать в robots.txt, а что не писать
robots.txt полезен, когда нужно уменьшить лишний обход. Но это не инструмент для гарантированного удаления из индекса. Если страница уже известна поисковику, запрет в robots.txt может даже помешать увидеть noindex на самой странице.
Практичный вариант — закрывать только совсем технические адреса, которые не должны сканироваться вообще. Например:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /*?replytocom=
Disallow: /*?add-to-cart=
Последние две строки уместны не в каждом проекте. Перед добавлением проверьте, что именно создаёт параметры и не ломает ли это нужные сценарии. Для некоторых сайтов лучше решать вопрос на уровне noindex, а не через блокировку обхода.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что поисковый робот видит именно то, что вы ожидаете.
- откройте URL с параметром в браузере и проверьте исходный код на наличие
<meta name="robots" content="noindex,follow" />; - проверьте ответ сервера через
curl -Iили инструменты разработчика, если используетеX-Robots-Tag; - в Google Search Console отправьте URL на проверку и посмотрите, видит ли робот тег;
- убедитесь, что канонический адрес страницы остаётся без параметров, если это ваш целевой вариант;
- проверьте, не закрыли ли вы случайно важные страницы поиска, фильтров или пагинации.
Для быстрой локальной проверки заголовков можно использовать:
curl -I "https://example.com/catalog/?sort=price"В ответе должен быть виден X-Robots-Tag, если вы выбрали этот способ. Если заголовка нет, значит правило не сработало или сработало слишком поздно.
Частые ошибки и как их исправить
Закрыли всё через robots.txt и ждёте удаления из индекса
Это самая частая ошибка. robots.txt ограничивает обход, но не всегда убирает URL из индекса. Если страница уже известна поисковику, используйте noindex на самой странице или заголовок X-Robots-Tag.
Ставите noindex на страницу, которую сами же закрыли в robots.txt
Так делать не стоит, если рассчитываете на быстрое вычищение индекса. Робот может не зайти на страницу и не увидеть мета-тег. Сначала дайте ему возможность прочитать noindex, потом при необходимости ограничивайте обход.
Не учитываете параметры, которые создаёт плагин кеша или аналитики
Иногда мусорные URL появляются не из-за темы, а из-за стороннего плагина. Перед правками посмотрите реальные адреса в логах, Search Console и отчётах аналитики. Иначе вы закроете не тот параметр или пропустите основной источник дублей.
Ставите noindex на все страницы с вопросительным знаком
Это слишком грубо. На некоторых проектах полезные посадочные тоже используют параметры. Сначала составьте список конкретных параметров, а уже потом пишите правило.
Чек-лист перед публикацией правок
- собраны реальные параметризованные URL из Search Console и логов;
- определено, какие параметры закрываем, а какие оставляем;
- выбран один основной способ:
noindex,X-Robots-Tagили robots.txt; - проверен исходный код страницы и заголовки ответа;
- не сломаны фильтры, сортировка и внутренний поиск;
- важные канонические URL не получили лишних параметров;
- после правок отправлены на переобход ключевые страницы.
Практические замечания по безопасности и производительности
Если параметров много, не делайте тяжёлую логику на каждом запросе. Достаточно простого списка разрешённых или запрещённых параметров и раннего выхода из функции. Для больших проектов лучше вынести правило в mu-plugin, чтобы оно не зависело от темы.
Ещё один полезный момент: не используйте массовые редиректы для всех параметров подряд. Это создаёт лишнюю нагрузку и может ломать аналитику. Для SEO-задачи чаще достаточно корректного noindex и аккуратного каноникала.
Если у вас уже есть системная проблема с дублями, чисткой служебных страниц и мета-тегов, часть задач можно закрывать через Clearfy Pro, но только после проверки, какие именно правила он меняет в конкретной установке. В любом случае ручная диагностика URL остаётся обязательной.