Как закрыть от индексации технические страницы WordPress без лишних потерь в SEO

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

Диагностика: какие страницы реально мешают

Перед правками откройте отчёты в Google Search Console и посмотрите, какие типы URL уже есть в индексе или в статусе «Просканировано, но не проиндексировано». На WordPress это обычно:

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

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

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

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

Какие страницы WordPress обычно закрывают от индексации

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

Тип страницы Что делать Когда не закрывать
Внутренний поиск noindex, follow Практически никогда
Страницы вложений Редирект на файл или родительскую запись Если это отдельная галерея с полезным текстом
Архивы тегов Оставить только при сильной структуре контента Если теговые страницы реально собирают трафик
Архивы автора Закрыть на сайтах с одним автором Если это медиа или многoавторный проект
Параметры URL Каноникал на чистый URL или запрет индексации Если параметр меняет уникальный контент

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

Самый безопасный путь — не лезть сразу в robots.txt, а сначала убрать страницы из индекса на уровне HTML. Для WordPress это обычно делается через SEO-плагин или код темы/плагина. Robots.txt нужен для ограничения обхода, но не для гарантированного удаления уже проиндексированных URL.

1. Закройте внутренний поиск и архивы без ценности

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

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

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

2. Уберите индексацию страниц вложений

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

add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = wp_get_post_parent_id(get_the_ID());

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

        $url = wp_get_attachment_url(get_the_ID());
        if ($url) {
            wp_redirect($url, 301);
            exit;
        }
    }
});

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

3. Настройте canonical для параметров и дублей

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

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

4. Используйте robots.txt только для обхода, а не для удаления

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

Пример аккуратного правила для служебных разделов:

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

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

Если хотите сделать это через плагин

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

Как проверить, что решение сработало

После внедрения не ограничивайтесь визуальной проверкой. Нужны как минимум три шага:

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

Если вы закрывали страницы вложений редиректом, проверьте код ответа через DevTools, curl -I или любой HTTP-проверщик. Для редиректа должен быть 301, а не 302, если это постоянная схема.

curl -I https://example.com/sample-attachment/

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

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

Закрыли в robots.txt, но не добавили noindex

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

Закрыли слишком много архивов

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

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

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

Ожидали мгновенного удаления из выдачи

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

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

Когда вы правите индексацию, не забывайте о сопутствующих рисках. Избыточные правила в functions.php неудобны для поддержки: после смены темы они могут исчезнуть. Для постоянной логики лучше использовать мини-плагин или mu-plugin. Так вы не потеряете настройки при обновлении темы.

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

И ещё один практический момент: перед массовыми изменениями сделайте резервную копию и проверьте результат на staging-окружении. Это особенно важно, если вы меняете canonical, редиректы или правила robots.txt — такие правки легко ломают уже рабочую индексацию.

Когда лучше не трогать индексацию вручную

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

  • нужно закрыть нестандартные шаблоны;
  • плагин не умеет работать с конкретным типом URL;
  • важно контролировать логику на уровне темы или mu-plugin;
  • нужно убрать только часть архивов, а не все сразу.

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

Как отключить XML-RPC в WordPress и не сломать мобильные приложения и внешние сервисы
27.08.2026
Как настроить robots.txt и noindex для страниц автора в WordPress
27.08.2026
Как закрыть от индексации технические страницы WordPress без лишних потерь в SEO
22.08.2026
Как закрыть от индексации страницы поиска WordPress и убрать мусорные запросы из SEO
25.08.2026
Отложенная индексация через noindex для AI-сгенерированных страниц в WordPress
30.08.2026