Как запретить индексацию технических страниц WordPress

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

Ниже — рабочая схема: что именно закрывать, чем это делать и как проверить, что вы не переусердствовали.

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

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

Типичные кандидаты на noindex

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

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

Диагностика: что именно индексируется сейчас

Перед правками проверьте, какие URL уже попали в поиск. Самый простой способ — поиск по оператору site: и просмотр отчётов в Google Search Console. Ищите не только очевидные страницы поиска, но и странные адреса с параметрами, вложения, архивы автора и теги.

Полезно сверить три источника:

• результаты site:ваш-домен;
• отчёт «Страницы» в Search Console;
• список URL в sitemap.xml.

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

Как запретить индексацию: три рабочих подхода

У каждого способа своя задача. Нельзя одним robots.txt закрыть всё подряд и считать вопрос решённым. Для части страниц нужен noindex, для части — ещё и nofollow или исключение из карты сайта.

Подход	Когда использовать	Плюс	Минус
noindex в meta robots	Для страниц, которые можно сканировать, но не нужно хранить в индексе	Гибко и безопасно	Страница должна быть доступна роботу
robots.txt	Для экономии краулингового бюджета на явно служебных разделах	Просто и быстро	Не гарантирует удаление из индекса, если URL уже известен
Удаление из sitemap	Для любых URL, которые не должны продвигаться	Убирает лишние сигналы	Нужно следить за генератором карты сайта

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

Если вы работаете с темой или небольшим кастомным плагином, самый надёжный путь — добавить мета-тег на нужные типы страниц. Для WordPress это делается через wp_robots.

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

    return $robots;
});

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

2. Исключить служебные URL из sitemap

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

Например, для таксономии, которая не должна индексироваться и не должна попадать в sitemap:

register_taxonomy('topic', ['post'], [
    'public'       => true,
    'show_ui'      => true,
    'show_in_rest' => true,
    'rewrite'      => ['slug' => 'topic'],
    'hierarchical' => false,
    'show_in_nav_menus' => false,
    'show_tagcloud' => false,
    'meta_box_cb'  => false,
    'publicly_queryable' => true,
    'exclude_from_search' => true,
]);

Важно: exclude_from_search не равен noindex. Это только убирает записи из поиска по сайту, но не запрещает индексацию поисковиками.

3. Использовать robots.txt для явных служебных разделов

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

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

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

Пошаговая настройка без лишних рисков

1. Составьте список URL, которые не должны индексироваться: поиск, вложения, авторы, теги, параметры.
2. Проверьте, есть ли они в sitemap.xml.
3. Добавьте noindex через wp_robots для шаблонов, которые должны оставаться доступными, но не индексироваться.
4. Исключите эти URL из sitemap.
5. При необходимости добавьте точечные правила в robots.txt для экономии обхода.
6. После правок отправьте на переобход только важные страницы, а не весь сайт целиком.

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

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

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

• Откройте страницу и проверьте наличие <meta name="robots" content="noindex,nofollow"> или эквивалентного значения.
• Посмотрите исходный код страницы поиска, автора или вложения.
• Проверьте, исчез ли URL из sitemap.xml.
• В Search Console используйте проверку URL и запрос на переобход.

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

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

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

Это ожидаемо. Если поисковик уже знает URL, одного Disallow мало. Нужен noindex или удаление страницы с последующим возвратом 404/410, если она больше не нужна.

Поставили noindex и одновременно закрыли URL в robots.txt

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

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

Частая ошибка при массовой настройке SEO-плагина. Теги и рубрики не одинаковы: рубрики часто нужны для структуры и внутренней перелинковки, а теги — нет. Решение — настраивать таксономии отдельно, а не одним переключателем на всё.

Оставили страницы в sitemap после noindex

Это создаёт противоречие. Поисковику вы одновременно говорите «не индексируй» и «вот важный URL». Уберите такие адреса из карты сайта.

Что делать с вложениями и архивами автора

На небольших сайтах архив автора часто не несёт пользы, особенно если у сайта один автор. В этом случае логично поставить noindex и убрать архив из меню и sitemap. Со страницами вложений ситуация похожая: если отдельная страница медиафайла не даёт ценности, лучше не продвигать её как самостоятельный URL.

Если вам нужен быстрый и аккуратный способ чистить SEO-настройки, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином принцип остаётся тем же: сначала определить, что именно закрываем, потом проверить sitemap и robots.

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

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

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

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

В итоге рабочая схема простая: noindex для страниц, которые должны быть доступны, но не индексироваться; robots.txt для явного мусора и экономии обхода; sitemap — только для полезных URL. Если эти три слоя согласованы, технические страницы перестают мешать основному контенту.