Как убрать дубли страниц из индекса в WordPress через noindex и robots.txt

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

Рабочая задача здесь не в том, чтобы «запретить всё подряд», а в том, чтобы разделить два уровня: что можно не обходить через robots.txt, а что лучше оставить доступным для обхода, но убрать из индекса через noindex. Это разные инструменты, и путать их опасно.

Какие дубли обычно появляются в WordPress

Перед правками полезно понять, что именно у вас индексируется. На практике чаще всего всплывают такие URL:

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

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

Диагностика: что именно нужно закрыть

Сначала проверьте, какие URL реально видит поисковик. Для этого достаточно трех источников: отчетов в Google Search Console, логов сервера и обычного поиска по сайту в поиске site:вашдомен. Если у вас есть доступ к аналитике обхода, смотрите, какие адреса бот посещает чаще всего без пользы.

Что искать в Search Console

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

Быстрая проверка на сайте

Если нужно быстро понять, есть ли проблема, проверьте несколько типовых URL вручную:

https://example.com/?s=test
https://example.com/page/2/
https://example.com/attachment/sample-image/
https://example.com/post-name/?replytocom=123

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

Что лучше: robots.txt, noindex или редирект

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

Практически это выглядит так: поиск и параметры часто закрывают в robots.txt, а страницы вложений, архивы тегов или пагинацию — через noindex, follow или каноникал, если это оправдано структурой сайта.

Пошаговое решение через код

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

Добавляем noindex для внутренних поисков, вложений и replytocom

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

    if (isset($_GET['replytocom'])) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1);

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

Убираем лишние архивы из индекса через фильтр robots

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

<?php
add_filter('robots_txt', function ($output, $public) {
    $output .= "\nUser-agent: *\n";
    $output .= "Disallow: /?s=\n";
    $output .= "Disallow: /search/\n";
    $output .= "Disallow: /*?replytocom=\n";
    $output .= "Disallow: /attachment/\n";

    return $output;
}, 10, 2);

Здесь есть важная оговорка: шаблоны в robots.txt поддерживаются не одинаково у всех роботов. Для Google такие правила обычно понятны, но это не универсальная гарантия. Поэтому для уже проиндексированных страниц лучше не рассчитывать только на Disallow.

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

В ряде проектов проще и безопаснее управлять индексированием через SEO-плагин, если он уже стоит и используется для каноникалов, sitemap и мета-тегов. Тогда не нужно дублировать логику в теме.

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

Если у вас уже есть Clearfy Pro, его удобно использовать для чистки дублей и служебных страниц, но все равно проверяйте итоговый HTML и robots.txt после сохранения настроек. Автоматические переключатели не отменяют ручную верификацию.

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

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

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

Для быстрой проверки можно использовать curl:

curl -I https://example.com/attachment/sample-image/

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

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

Закрыли в robots.txt, но URL остался в индексе

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

Поставили noindex на страницу, которую бот не может обойти

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

Закрыли слишком много разделов

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

Забыли про каноникал

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

Чек-лист перед публикацией правок

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

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

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

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

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