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

На WordPress чаще всего нужно не «закрыть сайт от поисковиков», а убрать из индекса конкретные страницы: результаты поиска по сайту, архивы с дублями, тестовые страницы, служебные URL, пагинацию, параметры фильтров или внутренние страницы плагинов. Ошибка здесь одна и та же: ставят Disallow в robots.txt и думают, что этого достаточно. На практике страница может остаться в индексе без контента, а поисковик всё равно будет видеть её как URL.

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

Когда проблема реально есть

Сначала стоит понять, что именно мешает. Не все «лишние» страницы одинаковы. Одни нужно скрыть от индекса, но оставить доступными для обхода. Другие лучше вообще не отдавать поисковику. Третьи надо не закрывать, а склеивать с основной страницей через canonical.

Типичные сценарии

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

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

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

<meta name="robots" content="noindex,follow">
<link rel="canonical" href="https://example.com/osnovnaya-stranica/">

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

Эти механизмы решают разные задачи. Если смешать их без понимания, можно получить страницы, которые не индексируются, но продолжают висеть в отчётах как «обнаружено, не проиндексировано» или «просканировано, но не проиндексировано».

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

Пошаговое решение в WordPress

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

1. Добавьте noindex для конкретных типов страниц

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

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

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

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

2. Закройте мусорные параметры через canonical

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_singular() && $post instanceof WP_Post) {
        return get_permalink($post);
    }

    return $canonical;
}, 10, 2);

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

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

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

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

Правило с Allow: /wp-admin/admin-ajax.php полезно для тем и плагинов, которые используют AJAX на фронтенде. Полностью закрывать wp-admin и при этом не разрешать admin-ajax.php — частая причина поломки интерактивных элементов.

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

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

• Откройте страницу и убедитесь, что в <head> есть meta robots с noindex.
• Проверьте, что canonical указывает на нужный адрес без параметров.
• Посмотрите robots.txt и убедитесь, что вы не заблокировали страницу раньше, чем поисковик увидит noindex.
• Если сайт подключён к Google Search Console или Яндекс.Вебмастеру, отправьте URL на повторную проверку.

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

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

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

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

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

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

Ставят noindex на страницу, но одновременно блокируют её в robots.txt

Так делать можно не всегда. Если бот не может зайти на страницу, он не увидит meta robots. В результате URL может остаться в индексе дольше, чем ожидается. Сначала дайте поисковику увидеть noindex, потом при необходимости ограничивайте обход.

Используют canonical на нерелевантную страницу

Canonical должен указывать на максимально близкую по смыслу основную версию. Если поставить его на главную страницу ради «удаления» дубля, поисковик может проигнорировать сигнал.

Дублируют сигналы SEO-плагином и кодом темы

Если плагин уже управляет мета-тегами, а вы вручную добавляете ещё один noindex, диагностика становится сложнее. Сначала проверьте, кто именно выводит тег: тема, плагин SEO или кастомный код.

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

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

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

И ещё один практический момент: не закрывайте от индексации то, что должно участвовать в внутренней перелинковке и передавать вес. Архивы категорий, полезные страницы тегов и некоторые посадочные могут быть ценными. Решение должно быть точечным, а не «закрыть всё, что не нравится».

Короткий чек-лист перед публикацией

• Поняли, какой именно тип страницы нужно скрыть.
• Выбрали правильный механизм: noindex, canonical или robots.txt.
• Проверили, не конфликтует ли решение с SEO-плагином.
• Убедились, что страница доступна для обхода, если нужен сигнал noindex.
• Проверили исходный код страницы и canonical после изменений.
• Отправили URL на повторную проверку в панели вебмастера.

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