Как закрыть от индексации отдельные разделы WordPress через robots.txt, noindex и X-Robots-Tag

Когда в индексе начинают всплывать служебные страницы WordPress, проблема обычно не в одном теге, а в смеси настроек: архивы автора, страницы поиска, вложения медиафайлов, служебные таксономии, параметры URL и технические дубли. Если закрывать всё подряд через robots.txt, можно только усугубить ситуацию: поисковик перестанет заходить на страницу, но уже найденный URL может остаться в выдаче без сниппета. Поэтому здесь важен порядок действий: сначала определить, что именно нужно убрать из индекса, потом выбрать способ — noindex, X-Robots-Tag или запрет обхода в robots.txt.

Какие страницы WordPress чаще всего нужно закрывать

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

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

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

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

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

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

• отчёт «Страницы» в Google Search Console;
• поиск по сайту в выдаче через site:domain.ru;
• наличие дублей с параметрами в логике темы или плагинов;
• мета-теги robots на проблемных URL;
• заголовки ответа сервера, если страница генерируется не как обычная HTML-страница.

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

Что выбрать: robots.txt, noindex или X-Robots-Tag

У каждого способа своя задача. Универсального варианта нет, и именно из-за этого на проектах часто появляются конфликты: страница закрыта от обхода, но при этом её нужно удалить из индекса; или наоборот — стоит noindex, но robots.txt не даёт боту дойти до страницы.

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

Ниже — рабочая схема для типового WordPress-сайта. Она не требует выдуманных хуков и подходит для темы или небольшого mu-plugin.

Шаг 1. Добавляем noindex для поисковых и служебных страниц

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

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

    if ( is_paged() && ! is_singular() ) {
        $robots['noindex'] = true;
    }

    return $robots;
} );

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

Шаг 2. Для файлов и нестандартных ответов используем X-Robots-Tag

Если нужно закрыть от индексации не HTML-страницу, а, например, PDF или вложение, удобнее отдать заголовок ответа. В WordPress это можно сделать через send_headers.

<?php
add_action( 'send_headers', function() {
    if ( is_attachment() ) {
        header( 'X-Robots-Tag: noindex, nofollow', true );
    }
} );

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

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

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

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

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

Если нужен быстрый вариант без кода

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

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

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

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

1. Откройте проблемный URL и посмотрите исходный код страницы.
2. Убедитесь, что в <head> появился noindex там, где он нужен.
3. Для вложений и нестандартных файлов проверьте заголовки ответа через DevTools или curl -I.
4. Проверьте, не закрыт ли URL одновременно в robots.txt и через noindex, если вам нужно ускорить удаление из индекса.
5. Отправьте страницу на повторную проверку в Google Search Console, если она уже была в индексе.

curl -I https://example.com/wp-content/uploads/file.pdf

В ответе ищите строку X-Robots-Tag: noindex, nofollow, если вы настраивали именно этот способ. Для HTML-страниц проверяйте исходник и наличие мета-робота, а не только визуальный вид страницы.

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

Закрыли страницу в robots.txt, но не поставили noindex

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

Поставили noindex на все архивы подряд

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

Использовали одинаковую логику в теме и SEO-плагине

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

Закрыли вложения, но не перенаправили их на исходную запись

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

Безопасность и производительность: что не стоит упускать

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

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

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

Когда стоит идти не кодом, а настройкой плагина

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

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