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

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

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

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

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

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

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

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

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

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

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

• отчёт Страницы в Google Search Console;
• поиск по сайту через site:example.com с типовыми шаблонами URL;
• наличие тегов noindex и canonical в исходном коде страниц;
• robots.txt, если там уже есть жёсткие запреты;
• логи обхода, если доступен серверный лог или аналитика краулера.

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

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

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

Подход	Когда использовать	Плюс	Минус
noindex	Для страниц, которые не должны ранжироваться	Понятный сигнал поисковику	Нужно, чтобы робот мог зайти на страницу и увидеть мета-тег
robots.txt	Для сокращения обхода технических URL	Экономит crawl budget	Не гарантирует удаление уже проиндексированных страниц
canonical	Для дублей и параметров сортировки	Сохраняет сигналы на основной URL	Не всегда срабатывает мгновенно

Вариант 1: закрыть страницы через код темы или мини-плагин

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

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

    if (is_author() && !is_multi_author()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

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

Вариант 2: задать canonical для страниц с параметрами

Если у вас есть фильтры или сортировка, которые создают много URL с одинаковым контентом, лучше не закрывать всё подряд, а указывать каноническую версию. Для этого можно использовать фильтр wpseo_canonical в Yoast SEO или аналогичный механизм в другом SEO-плагине. Если плагина нет, canonical можно вывести вручную в wp_head, но только если вы точно контролируете шаблон.

<?php
add_action('wp_head', function () {
    if (is_page('catalog') && !empty($_GET['sort'])) {
        $canonical = get_permalink(get_queried_object_id());
        echo '<link rel="canonical" href="' . esc_url($canonical) . '">' . "\n";
    }
});

Важный момент: canonical должен вести на реально существующую чистую версию страницы, а не на случайный URL без параметров, который сам закрыт от индексации.

Вариант 3: ограничить обход через robots.txt

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

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

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

Когда лучше использовать плагин

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

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

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

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

1. Откройте страницу и проверьте исходный код: должен быть meta name="robots" или link rel="canonical".
2. Проверьте ответ сервера через curl -I, если вы меняли заголовки на уровне сервера.
3. В Google Search Console отправьте URL на повторную проверку.
4. Через несколько обходов проверьте, исчез ли URL из отчёта по индексированию или сменился ли статус.

Пример быстрой проверки canonical и robots на сервере:

curl -s https://example.com/?s=test | grep -iE 'robots|canonical'

Если тег не выводится, ищите конфликт в шаблоне темы, SEO-плагине или в кэше. Иногда страница в браузере уже обновлена, а в кэше CDN или плагина остаётся старая версия HTML.

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

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

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

Поставили noindex на нужную страницу по ошибке

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

Canonical ведёт на URL, который тоже закрыт

В этом случае поисковик получает противоречивый сигнал. Canonical должен указывать на индексируемую основную версию, иначе смысл настройки теряется.

Два SEO-решения одновременно

Если плагин и тема оба выводят robots meta tag, можно получить конфликт: один говорит index, другой — noindex. Проверьте, кто именно отвечает за мета-теги, и оставьте один источник правды.

Чек-лист перед публикацией изменений

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

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

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

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

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