В WordPress внутренний поиск и страницы с параметрами фильтров часто создают мусорные URL: одинаковый контент, пустые выдачи, бесконечные комбинации параметров. Для поисковика это не «полезная навигация», а набор дублей и слабых страниц, которые размывают обход и усложняют индексацию нормальных материалов.
Задача здесь не в том, чтобы «запретить всё подряд», а в том, чтобы аккуратно убрать из индекса только технические и бесполезные страницы: результаты поиска, URL с фильтрами, сортировками и служебными параметрами. При этом обычные категории, записи и посадочные страницы должны остаться доступны.
Когда проблема уже видна в индексе
Обычно сигналов несколько. В поиске начинают всплывать URL вида ?s=, ?filter_, ?orderby= или страницы с длинными цепочками параметров. В отчётах Google Search Console появляются URL с низким качеством и странными заголовками. Иногда сайт ещё и сам генерирует такие ссылки в блоках фильтрации, а робот их активно обходит.
Что проверить до правок
- Есть ли у сайта внутренний поиск и индексируются ли его результаты.
- Создают ли фильтры отдельные URL с GET-параметрами.
- Не закрыты ли случайно нужные страницы вместе с мусорными.
- Есть ли у фильтров канонические URL или хотя бы понятная логика noindex.
Если у вас интернет-магазин, блог с тегами или каталог статей, особенно внимательно смотрите на страницы сортировки, поиска и фильтрации. Именно они чаще всего плодят дубли, а не основной контент.
Какой подход выбрать: robots.txt, noindex или каноникал
Для разных типов страниц нужен разный инструмент. Не стоит закрывать всё через robots.txt: если страница уже попала в индекс, запрет обхода не всегда удалит её оттуда быстро. И наоборот, noindex на страницах, которые должны передавать вес и быть доступны для обхода, тоже не лучший вариант.
| Подход | Когда использовать | Ограничение |
|---|---|---|
noindex,follow | Для страниц поиска, фильтров, сортировок | Страница может ещё какое-то время обходиться роботом |
robots.txt | Для явного ограничения обхода служебных URL | Не гарантирует удаление уже проиндексированных страниц |
rel=canonical | Когда фильтр создаёт почти дубль основной страницы | Не подходит для пустых или бесполезных результатов поиска |
На практике чаще всего нужен комбинированный вариант: noindex для страниц поиска и фильтров, а в robots.txt — только аккуратное ограничение некоторых параметров, если они создают слишком много мусорных URL.
Пошаговое решение через код темы или мини-плагин
Если вы не хотите зависеть от SEO-плагина, можно добавить логику в дочернюю тему или в небольшой mu-plugin. Для страниц поиска WordPress уже даёт понятный запрос через is_search(). Для фильтров с параметрами нужно смотреть на $_GET и тип URL.
1. Добавить noindex на страницу поиска
Это самый безопасный шаг: результаты внутреннего поиска редко должны попадать в индекс. Если на сайте есть отдельная поисковая выдача, она почти всегда создаёт тонкие страницы без ценности для пользователя из поиска.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Этот вариант работает, если тема выводит wp_head() в header.php. Если у вас кастомная тема без стандартного хука, сначала исправьте это, иначе мета-тег просто не попадёт в HTML.
2. Закрыть от индексации страницы с фильтрами по параметрам
Ниже пример для типичных параметров filter_, orderby, min_price, max_price. Логику нужно подстроить под ваш сайт, не копировать вслепую. Если параметр нужен для навигации, но не должен индексироваться, это хороший кандидат на noindex.
<?php
add_action('wp_head', function () {
$filter_keys = ['orderby', 'min_price', 'max_price'];
foreach ($_GET as $key => $value) {
if (strpos($key, 'filter_') === 0 || in_array($key, $filter_keys, true)) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
break;
}
}
});Если фильтры есть только в одном разделе сайта, лучше ограничить правило этим разделом через is_page(), is_tax() или is_post_type_archive(). Так вы не заденете служебные страницы админки или другие шаблоны, где параметры могут использоваться по делу.
3. Добавить canonical на основную страницу раздела
Когда фильтр меняет только сортировку или второстепенные параметры, канонический URL должен указывать на чистую страницу раздела. Это помогает поисковику понять, что основная версия — без параметров.
<?php
add_action('wp_head', function () {
if (!empty($_GET) && !is_search()) {
$canonical = home_url(add_query_arg([], $GLOBALS['wp']->request ?? ''));
$canonical = strtok($canonical, '?');
echo '<link rel="canonical" href="' . esc_url($canonical) . '">' . "\n";
}
}, 1);Этот фрагмент не универсален и требует проверки на вашем шаблоне. Если SEO-плагин уже генерирует canonical, не дублируйте тег вручную. Два canonical в одной странице — частая ошибка, которая ломает сигнал для поисковика.
Если используете SEO-плагин
В ряде случаев проще и надёжнее управлять индексацией через SEO-плагин, чем писать собственную логику. Но даже тогда важно понимать, что именно он делает: ставит noindex, меняет canonical или только управляет robots meta.
Если на сайте уже стоит плагин с настройками для архивов, таксономий и служебных страниц, проверьте, умеет ли он закрывать внутренний поиск и параметры URL без ручного кода. Это удобнее, чем поддерживать собственный костыль в теме. Для технической чистки сайта и удаления дублей иногда используют Clearfy Pro, но решение всё равно нужно проверять по исходному HTML и в Search Console, а не по галочке в интерфейсе.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что поисковик видит именно те сигналы, которые вы задумали.
- Откройте страницу поиска и проверьте исходный код: должен быть
meta name="robots" content="noindex,follow". - Проверьте URL с фильтрами: на них тоже должен появляться noindex, если это предусмотрено логикой.
- Убедитесь, что обычные страницы записей, рубрик и статические страницы не получили noindex случайно.
- В Google Search Console отправьте проверку URL и посмотрите, как страница определяется после повторного обхода.
- Если меняли canonical, проверьте, что в HTML только один тег canonical и он указывает на чистый URL.
Для быстрой локальной проверки удобно открыть страницу в браузере и посмотреть исходник, а затем пройтись по URL с параметрами через curl:
curl -I "https://example.com/?s=test"
curl -s "https://example.com/?s=test" | grep -i robotsЕсли сервер отдаёт кэшированную версию, очистите кэш плагина, серверный кэш и CDN. Иначе вы будете проверять старый HTML и решите, что код не работает.
Частые ошибки и как их исправить
Закрыли URL в robots.txt, но они остались в индексе
Это типичная ситуация. Если страница уже известна поисковику, одного запрета обхода часто недостаточно. Добавьте noindex на саму страницу и дайте поисковику заново её обойти.
Поставили noindex на все страницы с параметрами и сломали полезную навигацию
Так бывает, когда правило написано слишком широко. Например, под запрет попадают страницы пагинации или сортировки, которые нужны пользователю и не являются дублями. Сужайте условие до конкретных параметров и конкретных шаблонов.
Дублируется canonical
Обычно это происходит, когда canonical выводит SEO-плагин, а вы добавили свой код в wp_head. Оставьте один источник правды. Если используете плагин, ручной canonical лучше убрать.
Фильтры работают через JavaScript, но URL всё равно индексируются
Если JS меняет адрес страницы через history API или формирует GET-параметры, поисковик может видеть эти URL как отдельные страницы. Нужна серверная логика: noindex, canonical или изменение структуры фильтрации.
Что стоит учесть для безопасности и производительности
Не используйте сырые значения из $_GET для вывода в HTML без экранирования. Даже если речь о технических параметрах, это всё равно пользовательский ввод. В примерах выше вывод идёт только фиксированной строкой, а не содержимым параметра.
Если фильтров много, не вешайте тяжёлую логику на каждый запрос без необходимости. Достаточно проверить список известных параметров и коротко выйти из функции. Для больших сайтов лучше держать правила в одном месте — в mu-plugin или в дочерней теме, а не размазывать по шаблонам.
И ещё один практический момент: если у вас есть отдельные страницы поиска с полезной выдачей, например по базе знаний, не закрывайте их автоматически. В таком случае сначала смотрят на поведение пользователей и структуру контента, а потом уже решают, нужен ли noindex или каноникал.