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

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

Когда это действительно нужно

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

Типичные кандидаты на закрытие

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

Диагностика: что именно мешает индексации

Перед правками проверьте, что проблема не в другом: страница может быть в индексе из-за внешних ссылок, старого sitemap, неправильного canonical или потому, что robots.txt закрывает обход, но не удаляет URL из поиска. Сначала откройте исходный код страницы и посмотрите:

• есть ли мета-тег noindex;
• какой canonical указан;
• не закрыт ли URL в robots.txt;
• не попадает ли он в XML-карту сайта;
• не генерирует ли тема или плагин отдельную страницу для вложения изображения.

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

Что выбрать: noindex, canonical или robots.txt

Пошаговое решение без лишних плагинов

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

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

Ниже пример, который закрывает от индексации страницу поиска, страницу 404, архивы вложений и отдельные страницы автора. Логику можно расширить под свой проект.

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

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

2. Ставим canonical на дубльные архивы

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_singular() || empty($canonical)) {
        return $canonical;
    }

    if (is_paged()) {
        return get_pagenum_link(1, false);
    }

    return $canonical;
}, 10, 2);

Если используете SEO-плагин, не пытайтесь одновременно задавать canonical и в коде, и в настройках плагина без проверки. Иначе можно получить конфликтующие URL в исходнике.

3. Ограничиваем обход технических путей в robots.txt

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

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

Sitemap: https://example.com/sitemap_index.xml

Если у вас ЧПУ-поиск через /search/, правило должно соответствовать реальному формату URL. Универсального шаблона нет: сначала посмотрите, как именно WordPress или тема формирует адрес поиска.

Если используете SEO-плагин

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

Если нужен более широкий контроль над дублями и технической чисткой, уместно посмотреть в сторону Clearfy Pro: у него есть инструменты для управления дублями, служебными страницами и лишними элементами в head. Но даже в этом случае проверка результата обязательна — плагин не отменяет необходимость смотреть исходный код и статус URL в Search Console.

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

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

• исходный код страницы — есть ли noindex,follow или нужный canonical;
• robots.txt — не блокирует ли он важные ресурсы и не дублируются ли правила;
• XML-карта сайта — не остался ли там URL, который вы хотите убрать;
• Search Console — как поисковик видит страницу после переобхода;
• кэш — не отдает ли сервер старую версию head.

Быстрый чек-лист:

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

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

Закрывают страницу в robots.txt и ждут удаления из индекса

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

Ставят noindex на полезные страницы

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

Оставляют дубль в sitemap

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

Дублируют canonical в теме и плагине

Когда canonical выводится одновременно из шаблона и SEO-плагина, в HTML может оказаться несколько тегов. Поисковик обычно выберет один, но это лишний риск. Оставьте один источник правды.

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

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

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

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

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

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

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