На WordPress часто всплывает одна и та же проблема: сайт уже нормально индексируется, но в поиске начинают появляться URL с параметрами — ?replytocom=, ?utm_, фильтры, сортировки, служебные хвосты от темы или плагина. Такие адреса редко нужны в выдаче, зато легко плодят дубли и размывают сигналы для поисковиков.
Ниже — рабочий сценарий без плагинов: как закрыть от индексации именно параметризованные страницы, не ломая нормальные URL и не трогая нужные интеграции.
Когда это действительно проблема
Не каждый URL с параметром нужно запрещать. Если параметр используется для реальной функции сайта, например для фильтра каталога или пагинации, сначала проверьте, не нужен ли он в индексе. Но если речь о технических хвостах, которые создают дубли одной и той же страницы, их лучше убрать из индексации.
Типичные признаки
- в Search Console появляются страницы с параметрами, хотя в контенте они не нужны;
- в индексе есть дубли одной и той же статьи с
?utm_source=или?replytocom=; - в логах и отчетах видны переходы на служебные URL, которые не должны ранжироваться;
- канонический URL на странице один, а в поиске всплывают несколько вариантов адреса.
Диагностика: что именно индексируется
Сначала не меняйте код, а посмотрите, какие URL уже попали в поиск. Это важно: если вы закроете все подряд, можно случайно задеть полезные страницы фильтра или сортировки.
- Откройте отчет по страницам в Google Search Console.
- Проверьте, есть ли там адреса с параметрами.
- Сравните эти URL с реальными сценариями использования на сайте.
- Посмотрите исходный код страницы: есть ли
rel="canonical"и на какой адрес он указывает.
Если canonical уже ведет на чистый URL, а в индекс все равно лезут параметры, обычно нужен дополнительный запрет на уровне robots.txt или заголовков ответа.
Пошаговое решение без плагинов
Для WordPress есть два практичных уровня защиты: запрет сканирования через robots.txt и установка noindex для страниц с параметрами. На практике лучше использовать их вместе, но аккуратно.
1. Добавьте правила в robots.txt
Если у вас есть доступ к файлу robots.txt в корне сайта, можно закрыть от обхода типовые технические параметры. Это не гарантирует удаление из индекса, но уменьшает количество обходов мусорных URL.
User-agent: *
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?fbclid=
Disallow: /*?gclid=
Такой вариант подходит только для очевидно технических параметров. Если у вас есть важные страницы с параметрами, не добавляйте слишком широкие правила вроде Disallow: /*? — это может задеть полезные URL.
2. Отдавайте noindex для страниц с параметрами
Если нужно закрыть именно индексацию, а не только обход, используйте мета-тег robots. Для WordPress это удобно сделать через wp_head.
<?php
add_action( 'wp_head', function () {
if ( is_admin() ) {
return;
}
$query = $_SERVER['QUERY_STRING'] ?? '';
if ( $query && preg_match( '/(^|&)(replytocom|utm_[^=]+|fbclid|gclid)=/i', $query ) ) {
echo "<meta name=\"robots\" content=\"noindex,follow\" />\n";
}
} );
Логика простая: если в строке запроса есть технический параметр, страница получает noindex,follow. Это не мешает переходу по ссылкам на странице, но сигнализирует поисковику не держать такой URL в индексе.
3. При необходимости задайте canonical на чистый адрес
Если тема или плагин не ставят canonical корректно, можно принудительно указать чистый URL для страниц с параметрами.
<?php
add_filter( 'wpseo_canonical', function ( $canonical ) {
if ( empty( $_SERVER['QUERY_STRING'] ) ) {
return $canonical;
}
if ( preg_match( '/(^|&)(replytocom|utm_[^=]+|fbclid|gclid)=/i', $_SERVER['QUERY_STRING'] ) ) {
return home_url( add_query_arg( array(), $GLOBALS['wp']->request ) );
}
return $canonical;
} );
Этот пример рассчитан на сайты, где используется Yoast SEO, потому что фильтр wpseo_canonical относится именно к нему. Если у вас другой SEO-плагин, не переносите код вслепую — сначала проверьте его документацию. Если SEO-плагина нет, лучше ограничиться wp_head и корректной логикой canonical в теме.
Что выбрать: robots, noindex или canonical
| Подход | Когда подходит | Ограничение |
|---|---|---|
| robots.txt | Нужно сократить обход технических URL | Не убирает уже проиндексированные страницы мгновенно |
| noindex | Нужно убрать URL из индекса | Страница должна быть доступна для обхода, иначе сигнал может не сработать |
| canonical | Есть дубль, который должен указывать на основной адрес | Не всегда достаточно, если URL уже активно индексируется |
Если задача — именно убрать мусорные параметры из поиска, canonical сам по себе часто слабоват. Для технических URL надежнее связка noindex + корректный canonical.
Проверка результата после внедрения
После правок не ориентируйтесь только на визуальный просмотр страницы. Нужно проверить, что поисковый робот видит именно те сигналы, которые вы добавили.
- Откройте проблемный URL с параметром в браузере и посмотрите исходный код страницы.
- Убедитесь, что появился
<meta name="robots" content="noindex,follow" />. - Проверьте canonical: он должен вести на чистый адрес без параметров.
- Посмотрите ответ сервера через
curl -Iили DevTools, если используете заголовкиX-Robots-Tag. - В Search Console отправьте URL на проверку и дождитесь переобхода.
Пример быстрой проверки через консоль:
curl -I "https://example.com/post/?replytocom=12"
Если вы используете заголовок X-Robots-Tag вместо мета-тега, в ответе должен быть виден нужный директивный заголовок. Это удобно для PDF, архивов и других URL, где в <head> ничего не вставить.
Частые ошибки и как их исправить
Слишком широкое правило в robots.txt
Ошибка выглядит так: закрыли все URL с вопросительным знаком, а потом сломали фильтры, сортировку или служебные страницы. Исправление простое — ограничивайте правила только конкретными параметрами, которые точно не нужны в индексе.
noindex на странице, которая закрыта от обхода
Если поисковик не может зайти на страницу, он может не увидеть мета-тег noindex. Поэтому не стоит одновременно жестко блокировать URL в robots.txt и рассчитывать, что он быстро выпадет из индекса. Для уже проиндексированных страниц сначала полезнее дать доступ на обход и показать noindex.
Canonical ведет не туда
Иногда тема автоматически ставит canonical на текущий URL с параметрами. Тогда поисковик получает противоречивый сигнал. Проверьте исходный код и убедитесь, что canonical указывает на чистый адрес.
Параметры используются для реальной логики
Например, ?sort=price или ?filter_color=blue могут быть нужны пользователям. В таком случае не закрывайте их автоматически. Лучше отдельно решить, какие комбинации должны индексироваться, а какие — нет.
Практические советы по безопасности и производительности
Закрытие мусорных параметров полезно не только для SEO. Чем меньше бесполезных URL обходит робот, тем меньше лишней нагрузки на сайт и логирование. Но не пытайтесь решить все одной директивой.
- не закрывайте в
robots.txtURL, которые нужны для авторизации, оплаты или AJAX-логики; - не используйте одинаковые правила для всех параметров без разбора;
- проверяйте, не генерирует ли тема лишние параметры в ссылках на внутренние страницы;
- если параметров много, сначала разберитесь с источником, а потом уже ставьте запрет.
Если на сайте уже накопилось много дублей, иногда удобнее сначала навести порядок в шаблонах и ссылках, а потом подключать точечную индексационную политику. Для этого полезно проверить, не добавляет ли тема или плагин лишние query string в навигацию, поиск и архивы.
Когда нужен более широкий технический аудит сайта, имеет смысл смотреть не только на индексацию, но и на дубли, ревизии, мусорные архивы и служебные страницы. На практике такие задачи часто решают вместе, а не по одной.