Как ограничить индексацию технических страниц WordPress без поломки SEO

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

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

Что именно обычно нужно закрывать от индексации

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

Типовые кандидаты на noindex

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

Отдельно стоит проверить каноникал. Иногда страница уже закрыта от индексации, но при этом отдаёт неправильный canonical и поисковик продолжает воспринимать её как самостоятельный URL.

Диагностика: где искать проблему

Начинать лучше не с кода, а с проверки фактического поведения сайта. Это экономит время: часто видно, что проблема не в WordPress, а в теме или SEO-плагине.

Проверка в браузере и исходном коде

Откройте проблемную страницу и посмотрите исходный HTML. Ищите:

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

Если у вас есть доступ к Search Console, проверьте отчёт по страницам и исключённым URL. Там обычно видно, что именно попало в индекс или было исключено: дубли, просканировано, но не проиндексировано, страница с перенаправлением и т.д.

Что проверить в админке WordPress

• Настройки → Чтение: не включена ли случайно опция запрета индексации сайта;
• Записи → Рубрики/Метки: не создают ли таксономии тонкие архивы;
• Пользователи: нужен ли архив автора на сайте с одним автором;
• Медиафайлы: не открываются ли attachment pages;
• SEO-плагин: нет ли глобального шаблона, который закрывает слишком много страниц.

Пошаговое решение: закрываем только технические URL

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

Шаг 1. Закрыть поиск, вложения и архивы автора

Этот вариант полезен, когда вы хотите контролировать поведение без тяжёлых плагинов. Код добавляет noindex,follow только на технические типы страниц.

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

    if (is_author() && !is_admin()) {
        $robots['noindex'] = true;
        $robots['follow']   = true;
    }

    return $robots;
});

Этот фильтр работает с современным API robots в WordPress и не ломает стандартный вывод мета-тега. Но он не решает всё: если тема или SEO-плагин печатает собственный robots meta вручную, нужно убрать дублирующий вывод.

Шаг 2. Отключить архивы автора, если они не нужны

Если на сайте один автор или архивы не дают пользы, лучше не только закрыть их от индексации, но и убрать как публичную сущность. Тогда не будет лишних URL и редиректов.

<?php
add_action('template_redirect', function () {
    if (is_author()) {
        wp_redirect(home_url('/'), 301);
        exit;
    }
});

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

Шаг 3. Закрыть вложения и перенаправить их на родительскую запись

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

<?php
add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = wp_get_post_parent_id(get_queried_object_id());

        if ($parent) {
            wp_redirect(get_permalink($parent), 301);
            exit;
        }

        wp_redirect(home_url('/'), 301);
        exit;
    }
});

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

Шаг 4. Закрыть результаты поиска и параметры URL

Результаты внутреннего поиска и URL с фильтрами часто создают тысячи почти одинаковых страниц. Для них обычно достаточно noindex, а в некоторых случаях — ещё и canonical на основную страницу.

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

Сравнение подходов: плагин, код или настройки темы

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

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

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

Что смотреть в HTML

• на технических страницах должен быть noindex,follow;
• на обычных страницах не должно появиться случайного noindex;
• canonical должен указывать на правильный URL;
• не должно быть двух разных robots meta от темы и плагина одновременно.

Что смотреть в ответе сервера

Проверьте, что редиректы работают как задумано. Например, вложение должно отдавать 301 на родительскую запись, а не 200 с пустой страницей. Это можно проверить через DevTools, curl -I или любой HTTP-клиент.

curl -I https://example.com/?s=test
curl -I https://example.com/author/admin/
curl -I https://example.com/sample-attachment/

В ответе смотрите на статус, Location и наличие лишних цепочек редиректов.

Что проверить в Search Console

• исчезли ли из отчёта новые дубли;
• не выросло ли число исключённых страниц из-за неправильного noindex;
• не остались ли в индексе старые URL после редиректа;
• не появились ли ошибки сканирования после закрытия архивов.

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

Закрыли весь сайт вместо технических страниц

Это случается, когда в Настройки → Чтение включают запрет индексации и забывают выключить. В результате поисковик видит noindex почти на всех страницах. Исправление простое: отключить глобальный запрет и оставить точечные правила только для нужных URL.

Тема и SEO-плагин ставят разные robots meta

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

Редирект на вложения ломает галереи

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

Canonical указывает на неверный URL

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

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

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

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

Если вам нужен более широкий контроль над дублями, архивами и служебными страницами, имеет смысл посмотреть на инструменты, которые умеют управлять SEO-настройками и чисткой сайта централизованно, например Clearfy Pro: https://wpshop.ru/plugins/clearfy.

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

• проверили исходный HTML на технических страницах;
• убедились, что обычные записи не получили noindex;
• сверили canonical на страницах с параметрами;
• протестировали редиректы для вложений и архивов автора;
• очистили кеш WordPress, сервера и CDN;
• посмотрели отчёт в Search Console после переобхода;
• убрали дубли robots meta из темы и плагинов.

Если после внедрения технические URL всё ещё индексируются, почти всегда проблема в одном из трёх мест: кеш отдаёт старую версию, canonical указывает не туда или где-то остался второй источник robots meta. Проверка этих трёх точек обычно быстрее, чем бесконечная правка шаблонов.