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

Дубли в WordPress редко выглядят как одна очевидная проблема. Чаще это набор мелких источников: архивы тегов, страницы автора, пагинация, результаты поиска, параметры сортировки, версии с ?replytocom, а иногда и одинаковые записи, доступные по нескольким URL. В итоге поисковик тратит обход на мусорные адреса, а в индексе остаются не те страницы, которые вы хотели бы продвигать.

Ниже — рабочая схема, которая помогает не «запретить всё подряд», а аккуратно оставить в индексе нужные URL и убрать технический шум.

Какие дубли в WordPress встречаются чаще всего

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

Архивы, теги и страницы автора

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

Пагинация и параметры URL

Страницы вида /category/page/2/ сами по себе не ошибка. Ошибка начинается, когда в индексе оказываются десятки почти одинаковых листингов, а canonical указывает не туда, куда нужно. Параметры сортировки, фильтров и поиска тоже легко создают бесконечное число адресов с одинаковым содержимым.

Технические дубли

К ним относятся версии с www и без, http и https, адреса с index.php, страницы с ?replytocom, а также дубли из-за неправильной работы плагинов кеша или SEO-плагина. Здесь важно сначала проверить, не создаёт ли сам сервер лишние варианты URL.

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

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

• Проверьте отчёт по страницам в Google Search Console: ищите кластеры с одинаковым заголовком или похожим сниппетом.
• Откройте несколько подозрительных URL и сравните <title>, canonical и код ответа сервера.
• Посмотрите, не появляются ли дубли через параметры: ?utm_, ?replytocom, ?filter=, ?sort=.
• Проверьте, не индексируются ли архивы автора и теги, если они не нужны как посадочные.

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

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

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

1. Настройте canonical на основную версию страницы

Для большинства дублей canonical — первый и самый безопасный шаг. Он подсказывает поисковику, какая версия является основной. В WordPress это обычно делает SEO-плагин, но если вы правите шаблон или у вас кастомный тип записей, canonical лучше проверить вручную.

<?php
// Пример: вывод canonical в шаблоне, если тема не делает это автоматически.
if ( function_exists( 'rel_canonical' ) ) {
    rel_canonical();
}
?>

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

2. Закройте от индексации архивы, которые не несут ценности

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

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

    return $robots;
} );

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

3. Уберите параметры, которые создают мусорные URL

Параметры вроде ?replytocom и UTM-меток часто не нужны в индексе. Для UTM обычно достаточно canonical на чистый URL. Для других параметров иногда нужен отдельный код, чтобы поисковик не воспринимал их как самостоятельные страницы.

<?php
add_filter( 'wp_robots', function( array $robots ) {
    if ( ! empty( $_GET['replytocom'] ) ) {
        $robots['noindex'] = true;
        $robots['nofollow'] = true;
    }

    return $robots;
} );

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

4. Используйте robots.txt только для обхода, а не как замену noindex

robots.txt полезен, когда нужно снизить нагрузку на обход и убрать заведомо технические разделы: например, /wp-admin/, внутренние поисковые URL, временные каталоги плагинов. Но если страница уже в индексе, запрет в robots не удалит её сам по себе. Более того, поисковик может продолжать показывать URL без контента, если не видит возможность его переобхода.

Пример аккуратного файла для типового сайта:

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

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

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

Когда лучше плагин, а когда код

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

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

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

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

1. Откройте страницу в режиме просмотра исходного кода и проверьте, что canonical указывает на нужный URL.
2. Убедитесь, что на закрытых страницах есть noindex, если вы использовали именно этот метод.
3. Проверьте ответ сервера для URL с параметрами и без них.
4. В Search Console отправьте на повторную проверку страницы, которые были изменены.
5. Сравните индексацию через несколько дней или недель, в зависимости от частоты обхода сайта.

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

curl -I https://example.com/category/sample/
curl -I https://example.com/category/sample/?replytocom=123

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

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

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

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

Поставили noindex на важную посадочную

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

Сделали canonical на главную вместо релевантной страницы

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

Закрыли всё через плагин и не проверили шаблон

Плагины не всегда учитывают кастомные шаблоны, отдельные типы записей и правки в теме. После обновления темы или плагина настройки могут частично измениться. Поэтому всегда проверяйте итоговый HTML, а не только экран настроек.

Что ещё стоит проверить ради безопасности и производительности

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

• Нормализуйте основной домен: один вариант https, один вариант с www или без него.
• Не плодите служебные страницы в меню и внутренних ссылках.
• Проверьте, не создаёт ли тема отдельные шаблоны для одинакового контента.
• После правок очистите кеш страницы и, если есть, кеш объекта.

Если проблема повторяется после каждого обновления темы или плагина, имеет смысл вынести логику в небольшой mu-plugin или в отдельный мини-плагин, а не держать её в functions.php. Так вы не потеряете настройки при смене темы.

В сложных случаях полезно сначала закрыть только самые шумные источники дублей, а потом смотреть на динамику в Search Console. Это безопаснее, чем одномоментно менять всё: так проще понять, какое именно правило сработало, а какое только добавило побочный эффект.