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

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

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

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

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

Типовые кандидаты на исключение

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

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

Диагностика: как понять, что именно индексируется лишнего

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

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

1. Поиск по сайту в Google с оператором site:example.com.
2. Отчёт «Страницы» в Google Search Console.
3. Исходный код проблемной страницы: есть ли <meta name="robots" и какой у неё canonical.
4. Ответ сервера: не отдаёт ли страница 200 OK там, где уже должен быть 404 или 410.
5. Список URL в логах или аналитике: не генерируются ли технические адреса внутренними ссылками.

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

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

В WordPress есть три основных инструмента: noindex, canonical и robots.txt. Они решают разные задачи и не заменяют друг друга.

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

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

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

    return $robots;
});

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

Вариант 2: задать canonical для дублей

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_singular('post') && $post instanceof WP_Post) {
        return get_permalink($post);
    }

    return $canonical;
}, 10, 2);

На практике такой код нужен редко, потому что большинство SEO-плагинов уже умеют формировать canonical. Но если проблема возникает из-за кастомной логики темы, полезно проверить именно этот слой.

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

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

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

Но здесь важно не переборщить. Полностью закрывать /wp-json/ имеет смысл не всегда: если сайт использует REST API для фронтенда или интеграций, такой запрет может мешать работе темы или плагинов. Сначала проверьте, какие запросы реально идут с сайта.

Как убрать страницы вложений и медиа-архивы

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

Если у вас SEO-плагин умеет перенаправлять attachment page на сам файл или родительскую запись, это обычно самый простой путь. Если нет — можно сделать это кодом.

<?php
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;
        }

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

Такой редирект лучше, чем просто noindex, если attachment-страницы уже накопились в индексе и не несут ценности. Но если на них есть трафик из поиска по картинкам, сначала посмотрите статистику, чтобы не сломать полезный входящий поток.

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

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

• Откройте страницу в браузере и посмотрите исходный код: есть ли noindex или корректный canonical.
• Проверьте заголовки ответа через DevTools или curl -I, если используете редиректы.
• В Google Search Console отправьте URL на повторную проверку через проверку URL.
• Сравните статус страницы в отчёте индексации до и после изменений.

Пример быстрой проверки через консоль:

curl -I https://example.com/?s=test

Если страница должна редиректиться, вы увидите 301 и новый адрес в заголовке Location. Если вы ожидаете noindex, смотрите уже HTML-ответ, а не только заголовки.

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

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

Это самая распространённая проблема. Страница остаётся в индексе, потому что поисковик не может заново её просканировать и увидеть запрет на индексацию. Решение: сначала вернуть доступ для обхода, затем добавить noindex, и только после этого при необходимости ограничить crawl.

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

Иногда фильтр в теме срабатывает слишком широко: например, на все архивы или все записи определённого типа. Проверяйте условия is_search(), is_author(), is_attachment() и не применяйте директиву без точного контекста.

Сделали редирект на главную для всех дублей

Редирект на главную часто выглядит как быстрый способ «почистить» индекс, но для поисковика это слабый сигнал. Если дубль имеет очевидный основной аналог, лучше редиректить на соответствующую страницу, а не на homepage.

Закрыли REST API без проверки зависимостей

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

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

• Проверил, какие URL реально попадают в индекс.
• Выбрал правильный метод: noindex, canonical или robots.txt.
• Не закрыл случайно полезные страницы.
• Проверил исходный код и ответ сервера.
• Отправил URL на повторную проверку в Search Console.
• Убедился, что внутренние ссылки не ведут на мусорные адреса.

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

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

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

Главный принцип здесь простой: не пытайтесь лечить индексацию только robots.txt. Сначала определите тип страницы, затем выберите точный механизм, и только после этого проверяйте, как поисковик отреагировал на изменения.