Как закрыть от индексации страницы с параметрами в WordPress

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

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

Какие URL обычно создают дубли

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

Чаще всего это

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

Если у вас уже есть статья про canonical, это не дублирует её. Canonical помогает подсказать предпочтительный адрес, но не всегда достаточно, когда поисковик массово индексирует параметрические URL. Здесь нужен более точный набор мер: где-то noindex, где-то canonical, а где-то ограничение обхода через robots.txt.

Диагностика: как понять, что проблема именно в параметрах

Перед правками проверьте, какие URL уже попали в индекс и откуда они взялись. Не стоит закрывать всё подряд только потому, что в адресе есть знак вопроса.

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

  • отчёт «Страницы» в Google Search Console;
  • поиск по сайту через site:example.com с параметрами в URL;
  • логи сервера, если нужно понять, какие параметры реально запрашиваются;
  • результат обхода в Screaming Frog или аналогичном краулере;
  • наличие дублей в HTML: одинаковый контент, но разные адреса.

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

Что выбрать: noindex, canonical или robots.txt

У каждого инструмента своя роль. Ошибка — использовать только один способ на все случаи.

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

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

Пошаговое решение без лишнего риска

Шаг 1. Закройте индексирование страниц поиска

Если у вас есть внутренний поиск WordPress, его результаты почти всегда не нужны в поиске. Самый безопасный вариант — добавить мета-тег noindex,follow только на страницу поиска.

<?php
add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

Этот код можно добавить в дочернюю тему или в небольшой mu-plugin. Он не ломает сам поиск, но подсказывает поисковику не индексировать результаты.

Шаг 2. Отдавайте canonical на основную версию страницы

Если параметр меняет только вид URL, а не смысл страницы, canonical должен указывать на чистый адрес. Например, для страницы с фильтром или UTM-меткой каноническая версия обычно без параметров.

<?php
add_filter('wpseo_canonical', function ($canonical) {
    if (is_admin()) {
        return $canonical;
    }

    if (!empty($_GET) && isset($_SERVER['REQUEST_URI'])) {
        $path = strtok(home_url(add_query_arg([], $_SERVER['REQUEST_URI'])), '?');
        return $path;
    }

    return $canonical;
});

Этот пример уместен, если у вас уже используется Yoast SEO. Если плагина нет, не пытайтесь «подменять» canonical в лоб для всех страниц — сначала проверьте, не ломает ли это пагинацию и страницы с реальными параметрами.

Шаг 3. Ограничьте обход технических параметров в robots.txt

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

User-agent: *
Disallow: /*?replytocom=
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Не стоит массово запрещать все URL с вопросительным знаком. Это часто мешает поисковику увидеть canonical и мета-теги на страницах, которые вы как раз хотите обработать корректно.

Шаг 4. Для отдельных параметров используйте фильтрацию на уровне шаблона

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

<?php
add_action('template_redirect', function () {
    $blocked_params = ['utm_source', 'utm_medium', 'utm_campaign', 'fbclid'];

    foreach ($blocked_params as $param) {
        if (isset($_GET[$param])) {
            add_action('wp_head', function () {
                echo '<meta name="robots" content="noindex,follow">' . "\n";
            });
            break;
        }
    }
});

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

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

После правок важно не просто посмотреть исходный код страницы, а проверить, как URL ведёт себя для поисковика и краулера.

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

Если URL уже в индексе, одного изменения на сайте мало. Поисковику нужно время на переобход. Для ускорения иногда помогает ручная проверка в Search Console и повторная отправка важных страниц на переобход.

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

Закрыли всё через robots.txt

Это самая частая ошибка. Если страница уже в индексе, запрет в robots.txt не удалит её сам по себе. Поисковик просто перестанет видеть содержимое, но URL может ещё долго висеть в выдаче. Для удаления нужен noindex или корректная переобходная стратегия.

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

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

Сломали пагинацию

Если canonical на страницах пагинации указывает только на первую страницу, поисковик может хуже понимать структуру архива. Для архивов и списков записей нужно отдельно проверить, как ведут себя страницы /page/2/, /page/3/ и т. д.

Оставили конфликтующие сигналы

Например, страница одновременно получает noindex, canonical на другой URL и запрет в robots.txt. Такие комбинации не всегда критичны, но часто мешают диагностике. Лучше выбрать один основной сигнал и не перегружать страницу лишними правилами.

Практические советы по безопасности и производительности

Если параметров много, не пытайтесь обрабатывать их через тяжёлые запросы к базе на каждом хите. Проверка $_GET и вывод мета-тега в wp_head почти ничего не стоит по производительности, а вот сложные фильтры на уровне template_redirect и лишние запросы в базу могут замедлить сайт.

Для больших проектов удобнее вынести логику в маленький mu-plugin, а не держать её в теме. Тогда правило не исчезнет при смене шаблона и не потеряется после обновления.

Если на сайте уже есть SEO-плагин, сначала проверьте его настройки. Иногда нужное поведение можно собрать без кода: через шаблоны мета-тегов, правила для архивов и исключения для параметров. Если же плагин не даёт точечной настройки, кодовый вариант обычно надёжнее, но его нужно тестировать на staging-копии.

В проектах, где много дублей и технических страниц, полезно отдельно проверить чистку мусорных URL и настройку canonical. Если нужен более широкий набор инструментов для SEO- и технической гигиены сайта, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wp0.ru&utm_medium=article&utm_campaign=zakryt-ot-indeksacii-stranicy-po-parametram-v-wordpress

Главное правило простое: сначала определите, какие параметры реально создают дубль, потом выберите один основной сигнал для поисковика и только после этого проверяйте индексацию в Search Console. Так меньше шансов закрыть полезные страницы и проще понять, что именно сработало.

Как использовать WP Rollback для отката версии плагинов в WordPress
24.04.2026
Как настроить X-Robots-Tag в WordPress для закрытия страниц от индексации
29.08.2026
Как отключить и удалить Gutenberg в WordPress
26.03.2026
Как создать многоуровневую навигацию в WordPress: пошаговое руководство
18.03.2026
Как использовать REST API в WordPress для создания собственных эндпоинтов
11.11.2025

Мы занимаемся разработкой приложений и плагинов для WordPress. Ниже предлагаем ознакомиться с ними.