Как настроить noindex для страниц с параметрами в WordPress

Автор: Вера Волкова | Опубликовано: 27.08.2026

Страницы с параметрами в URL — типичная причина дублей в WordPress. Фильтры, сортировки, UTM-метки, внутренний поиск, пагинация с параметрами и служебные хвосты вроде ?replytocom= часто создают десятки URL с одинаковым или почти одинаковым контентом. Для пользователя это не проблема, а для индексации — лишний шум.

Задача здесь не в том, чтобы «запретить всё подряд», а в том, чтобы аккуратно закрыть от индексации именно те варианты, которые не должны ранжироваться. Ниже — рабочая схема: как найти проблемные URL, как выбрать способ закрытия, как внедрить решение и как проверить, что оно действительно сработало.

Когда noindex для параметров действительно нужен

Не каждый URL с параметром нужно закрывать. Если параметр меняет только сортировку или вид выдачи, а сам контент не несёт самостоятельной ценности, noindex обычно уместен. Если же параметр формирует полноценную посадочную страницу, которую вы хотите продвигать, закрывать её нельзя.

Типичные сценарии, где появляются дубли

?utm_source=, ?utm_medium= и другие маркетинговые метки;
?replytocom= на страницах с комментариями;
?s= во внутреннем поиске WordPress;
фильтры и сортировки в каталогах, если они реализованы через GET-параметры;
технические параметры плагинов, которые меняют только отображение, а не смысл страницы.

Если такие URL уже попали в индекс, поисковик может тратить краулинговый бюджет на мусорные варианты, а в отчётах вы увидите дубли, странные каноникалы или страницы без трафика, которые всё равно обходятся роботом.

Диагностика: какие URL нужно закрывать

Сначала не трогайте код. Посмотрите, какие параметры реально создают индексируемые страницы. Это можно сделать через поиск по сайту, отчёты в Google Search Console и обычный ручной обход.

Что проверить в первую очередь

есть ли в индексе URL с ?s=;
попадают ли в поиск страницы с ?replytocom=;
индексируются ли URL с UTM-метками;
создают ли фильтры отдельные страницы с одинаковым title и description;
не ломается ли навигация, если закрыть параметр через noindex.

Полезно посмотреть исходный код проблемной страницы и убедиться, какой meta robots уже стоит. Если там есть index,follow, а страница по смыслу должна быть закрыта, это и есть точка вмешательства.

Что выбрать: robots.txt, meta robots или каноникал

Для параметров есть несколько инструментов, и они решают разные задачи. Ошибка многих сайтов в том, что они пытаются закрыть всё через robots.txt. Это не всегда помогает: если URL уже известен поисковику, он может остаться в индексе без контента, но с адресом в выдаче.

Способ	Когда подходит	Ограничение
`noindex` в meta robots	Страница должна открываться пользователю, но не индексироваться	Нужно, чтобы робот мог зайти на страницу и увидеть тег
`robots.txt`	Нужно сократить обход технических URL	Не гарантирует удаление из индекса
canonical	Есть основной URL, а параметры — его вариации	Не подходит для страниц, которые не должны индексироваться вообще

На практике для параметров чаще всего нужен noindex,follow на уровне страницы, а для совсем технических URL — дополнительная настройка в robots.txt или на уровне сервера.

Пошаговое решение: закрываем параметры от индексации

Если у вас есть доступ к теме или небольшому плагину, самый надёжный вариант — добавить условную мета-строку robots в <head>. Ниже пример для дочерней темы или собственного мини-плагина.

<?php
add_action( 'wp_head', function () {
	if ( is_admin() ) {
		return;
	}

	$should_noindex = false;

	// Внутренний поиск WordPress.
	if ( is_search() ) {
		$should_noindex = true;
	}

	// Комментарии-ответы и другие служебные параметры.
	if ( isset( $_GET['replytocom'] ) ) {
		$should_noindex = true;
	}

	// UTM-метки и похожие маркетинговые параметры.
	$tracking_params = array( 'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content' );
	foreach ( $tracking_params as $param ) {
		if ( isset( $_GET[ $param ] ) ) {
			$should_noindex = true;
			break;
		}
	}

	if ( $should_noindex ) {
		echo '<meta name="robots" content="noindex,follow">' . "\n";
	}
}, 1 );

Этот вариант подходит, если вам нужно закрыть только конкретные группы параметров. Он не требует стороннего плагина и не меняет поведение сайта для обычных страниц.

Если нужно закрывать только часть URL

Иногда не стоит закрывать все UTM-метки одинаково. Например, вы можете оставить индексируемыми посадочные страницы с фильтрами, но закрыть только внутренний поиск и комментарии. Тогда список условий лучше держать явным, а не пытаться ловить все параметры подряд.

<?php
add_filter( 'wp_robots', function( array $robots ) {
	if ( is_search() || isset( $_GET['replytocom'] ) ) {
		$robots['noindex'] = true;
		$robots['follow']  = true;
	}

	return $robots;
} );

Фильтр wp_robots удобнее, чем прямой вывод в wp_head, если вы хотите работать в рамках стандартного механизма WordPress. Но он не решает задачу, если тема или плагин уже выводят свои robots-мета-теги с конфликтующими значениями. В таком случае нужно проверить, кто именно добавляет тег, и убрать дублирование.

Как закрыть параметры через SEO-плагин

Если на сайте уже стоит SEO-плагин, иногда проще использовать его настройки, чем писать код. Это особенно полезно, если в команде нет разработчика, который будет сопровождать кастомное решение.

Но здесь важен один момент: не все плагины одинаково умеют работать именно с параметрами URL. Одни позволяют задавать правила для архивов и таксономий, другие — только для отдельных типов страниц. Поэтому перед включением проверьте, что плагин действительно умеет ставить noindex на нужные шаблоны и не ломает canonical.

Если нужен более широкий контроль над дублями и технической чисткой сайта, в экосистеме WPShop есть Clearfy Pro, который как раз закрывает часть таких задач на уровне настроек. Но даже с плагином всё равно стоит понимать, какие URL вы закрываете и почему.

Проверка результата после внедрения

После изменений не ограничивайтесь просмотром страницы в браузере. Нужно проверить именно то, что видит робот.

Минимальный чек-лист проверки

откройте проблемный URL с параметром и посмотрите исходный код;
убедитесь, что в <head> появился noindex,follow;
проверьте, что обычные URL без параметров не получили тот же тег;
посмотрите, не дублируется ли meta robots из-за темы и плагина одновременно;
в Google Search Console отправьте URL на проверку и посмотрите, какой robots-тег распознан.

Если вы используете командную строку, удобно проверить заголовки и HTML напрямую:

curl -L https://example.com/page/?utm_source=test | grep -i robots

Для локальной проверки можно временно открыть страницу в браузере и посмотреть исходник. Но лучше не полагаться только на визуальный просмотр: иногда тег добавляется, но потом перезаписывается другим плагином.

Частые ошибки и как их исправить

Закрыли параметр в robots.txt и ждёте удаления из индекса

Это самая частая ошибка. Disallow может уменьшить обход, но не всегда убирает URL из поиска. Если страница уже проиндексирована, нужен либо noindex, либо корректный canonical, либо удаление через инструменты поисковой системы.

Поставили noindex на все страницы с параметрами без разбора

Так можно случайно закрыть полезные посадочные страницы. Например, если фильтр создаёт действительно отдельную коммерческую страницу, её лучше не убирать из индекса без анализа спроса и структуры сайта.

Получили два meta robots на одной странице

Это бывает, когда тема выводит один тег, а плагин — другой. В результате робот может увидеть конфликтующее поведение, а вы — нестабильную индексацию. Решение простое: оставьте один источник генерации robots-тега.

Использовали canonical вместо noindex

Canonical — это подсказка, а не запрет. Если параметр не должен индексироваться вообще, canonical не заменяет noindex. Он полезен, когда параметр — просто вариация основной страницы.

Безопасность и производительность

Код для meta robots лучше держать в дочерней теме или в небольшом mu-plugin, а не править напрямую файлы основной темы. Иначе при обновлении всё потеряется. Если сайт большой, не стоит делать тяжёлые проверки на каждом запросе: достаточно простых условий по is_search() и наличию нужных параметров в $_GET.

Если вы добавляете собственную логику, не выводите пользовательские значения в HTML без экранирования. Для robots-тега это обычно не нужно, потому что вы не вставляете данные пользователя в строку, но сама проверка параметров должна быть предсказуемой и ограниченной списком допустимых ключей.

Для сайтов с большим количеством технических дублей имеет смысл дополнительно пересмотреть внутреннюю перелинковку: если вы сами постоянно ссылаетесь на URL с параметрами, поисковик будет продолжать их находить, даже если они закрыты от индексации.

Когда лучше не писать код

Если у вас уже стоит SEO-плагин, который умеет управлять robots и canonical на уровне шаблонов, а проблема касается только нескольких типов страниц, иногда быстрее и безопаснее решить это настройкой. Код оправдан, когда:

нужно закрыть нестандартные параметры;
правило должно работать без зависимости от плагина;
важно точечно управлять логикой для конкретных URL;
вы не хотите тащить лишний функционал в сайт.

Если же задача шире и включает чистку дублей, служебных страниц и технических мета-данных, удобнее собрать это в одном инструменте, а не размазывать по нескольким сниппетам.