Как запретить индексацию отдельных страниц WordPress: noindex, robots.txt и canonical

Автор: Олеся Новикова | Опубликовано: 14.08.2026

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

Ниже разберём, чем noindex отличается от robots.txt и canonical, когда что применять и как проверить, что закрытие от индексации действительно сработало.

Когда проблема уже есть: как понять, что страницы нужно закрывать

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

в Google Search Console или Яндекс.Вебмастере есть URL с параметрами, страницами поиска, служебными архивами;
в поиске находятся страницы с почти пустым или повторяющимся содержимым;
в выдаче появляется неканоническая версия: с ?replytocom=, с пагинацией, с UTM-параметрами, с дублем по HTTP/HTTPS или www/non-www.

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

Что именно искать в коде страницы

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

<meta name="robots" content="noindex,follow"> — страница не индексируется, ссылки на ней можно обходить;
<link rel="canonical" href="..."> — указывает основную версию URL;
правило в robots.txt — только если нужно ограничить обход, а не убрать страницу из индекса.

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

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

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

Если задача — убрать страницу из поиска, почти всегда нужен именно noindex. Если задача — склеить дубли, нужен canonical. Если задача — снизить нагрузку от обхода, можно добавить robots.txt, но только как дополнительную меру.

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

Самый надёжный путь — выставлять noindex на уровне шаблона или через SEO-плагин, если он уже управляет мета-тегами. Ниже — рабочий вариант без выдуманных хуков и без привязки к конкретному плагину.

Шаг 1. Определите тип страниц, которые нужно закрыть

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

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

Важно не закрывать всё подряд. Например, архивы рубрик часто полезны для SEO, если они заполнены и имеют нормальную структуру.

Шаг 2. Добавьте noindex для конкретных шаблонов

Если у вас кастомная тема или дочерняя тема, можно вывести мета-тег в <head> через wp_head. Пример ниже закрывает от индексации результаты поиска и архивы авторов без записей. Логику можно расширить под свои условия.

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

Этот вариант простой, но его нужно применять аккуратно. Если на сайте уже есть SEO-плагин, который тоже выводит robots meta, не дублируйте тег. Два разных robots-тега на одной странице — частая причина путаницы.

Шаг 3. Для дублей добавьте canonical

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

<?php
add_action('wp_head', function () {
    if (is_singular()) {
        $canonical = get_permalink();
        echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
    }
}, 5);

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

Шаг 4. Ограничьте обход в robots.txt только там, где это оправдано

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

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

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

Если нужен более управляемый вариант: через SEO-плагин или фильтры темы

На проектах с большим количеством шаблонов удобнее управлять индексацией централизованно. Если SEO-плагин уже стоит, лучше использовать его настройки для noindex на архивах, тегах, авторах и пагинации. Это снижает риск конфликтов с темой.

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

Пример: закрыть страницы поиска и пагинацию архивов

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

Такой код подходит не всем: на некоторых сайтах пагинация рубрик полезна для индексации. Поэтому сначала проверьте, действительно ли страницы /page/2/ и дальше создают дубли, а не помогают распределять внутренний вес.

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

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

Откройте проблемный URL в браузере и проверьте исходный код.
Убедитесь, что на странице есть один корректный meta robots, если он нужен.
Проверьте canonical: он должен вести на нужную основную версию.
Посмотрите заголовки ответа сервера, если используете серверные правила или кэш.
В Google Search Console отправьте URL на повторную проверку через инспекцию страницы.
Если страница была в индексе, дождитесь переобхода: мгновенного эффекта обычно нет.

Для быстрой локальной проверки удобно использовать curl:

curl -I https://example.com/stranica/
curl -s https://example.com/stranica/ | grep -iE 'robots|canonical'

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

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

Закрыли URL в robots.txt, но он всё равно в индексе

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

Поставили noindex, но страница всё равно ранжируется

Проверьте, не блокируется ли страница robots.txt. Если робот не может её обойти, он может не увидеть мета-тег noindex. В таком случае сначала снимите блокировку, дождитесь обхода и только потом оценивайте результат.

Canonical указывает на не ту страницу

Это бывает после правок темы, когда canonical собирается вручную и не учитывает параметры или тип записи. Проверьте, что canonical ведёт на чистый, доступный и индексируемый URL.

На странице два robots-тега

Обычно это конфликт темы и SEO-плагина. Оставьте только один источник генерации мета-тегов. Иначе поисковик может интерпретировать сигналы неоднозначно.

Скрыли важные страницы вместе со служебными

Такое случается, если правило слишком широкое: например, is_archive() без уточнений. Перед выкладкой проверьте список URL, которые попадают под условие.

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

Если вы закрываете от индексации страницы поиска, фильтров и параметров, это не только про SEO. На таких URL часто сидит лишняя нагрузка: кэш раздувается, поисковые роботы тратят обход, а сервер получает больше однотипных запросов.

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

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

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