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

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

Ниже — рабочая схема: сначала находим источник дублей, потом выбираем способ закрытия, а после — проверяем результат в Search Console и по HTML-коду страниц. Без магии и без «удалите всё лишнее».

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

Перед правками полезно понять, что именно у вас индексируется. В реальном проекте обычно всплывает не один тип дубля, а несколько сразу:

• архивы тегов и рубрик, которые повторяют контент записей;
• страницы автора на сайтах с одним автором;
• архивы по датам, если они не нужны для поиска;
• страницы вложений медиафайлов;
• пагинация архивов и комментариев;
• URL с параметрами, например ?replytocom=, ?utm_ и сортировками;
• версии страниц с www и без www, http и https, со слешем и без него.

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

Диагностика: где именно появляются дубли

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

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

• отчет «Страницы» в Google Search Console;
• поиск по сайту через site:example.ru и сравнение URL;
• исходный код проблемной страницы: есть ли rel="canonical" и не указывает ли он на неверный адрес;
• мета-тег robots на архивных страницах;
• ответ сервера для дублей: 200, 301 или 404.

Если у вас есть доступ к серверу, полезно быстро посмотреть заголовки ответов:

curl -I https://example.ru/tag/seo/

И отдельно проверить канонический URL в HTML:

curl -s https://example.ru/tag/seo/ | grep -i canonical

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

Что закрывать через robots.txt, а что через noindex

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

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

Пошаговое решение без лишнего риска

1. Закройте ненужные архивы в SEO-плагине

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

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

2. Уберите страницы вложений

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

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;
        }
    }
});

Этот вариант рабочий, но его нужно тестировать на медиабиблиотеке: если у вложения нет родителя, редиректить надо аккуратно, иначе можно получить цепочку или 404.

3. Приведите canonical к одному варианту URL

Если сайт доступен по нескольким версиям домена или протокола, сначала настройте один основной вариант на уровне сервера или хостинга. После этого проверьте, что WordPress и тема не генерируют альтернативные canonical.

Для страниц с параметрами canonical должен указывать на чистый URL без мусорных query string. Пример фильтра для нестандартного случая:

add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_singular() && !empty($canonical)) {
        $canonical = remove_query_arg(array('utm_source', 'utm_medium', 'utm_campaign'), $canonical);
    }
    return $canonical;
}, 10, 2);

Фильтр get_canonical_url существует в WordPress, но применять его стоит только если вы точно понимаете, что меняете. Обычно достаточно нормальной настройки темы и SEO-плагина.

4. Ограничьте индексацию параметров и служебных страниц

Параметры вроде ?replytocom= и UTM-меток часто создают сотни дублей. Для UTM обычно не нужно ничего делать на уровне WordPress: поисковик сам понимает, что это рекламные параметры, если canonical настроен правильно. А вот ?replytocom лучше убрать, если он плодит мусорные URL в индексе.

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

Пример настройки robots.txt для технических URL

robots.txt не решает все проблемы, но помогает не тратить обход на очевидный мусор. Пример минимальной и осторожной настройки:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?replytocom=
Disallow: /*?replytocom=
Disallow: /*?attachment_id=
Sitemap: https://example.ru/sitemap_index.xml

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

Как проверить, что решение сработало

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

1. Откройте проблемный URL и проверьте исходный код: есть ли meta name="robots" с нужным значением и корректный canonical.
2. Проверьте HTTP-ответы для дублей: нужные страницы должны отдавать 200, а старые или ненужные варианты — 301 или 404, если это задумано.
3. В Google Search Console отправьте проверку URL и посмотрите, как робот видит страницу после переобхода.

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

curl -s https://example.ru/tag/seo/ | grep -iE 'robots|canonical'

Если вы закрывали attachment-страницы редиректом, проверьте, что редирект одинарный и ведёт сразу на конечный URL, без цепочки 301 -> 301 -> 200. Цепочки замедляют обход и иногда ломают передачу сигналов.

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

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

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

Поставили noindex на страницу, но поисковик её не видит

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

Canonical указывает не туда

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

Слишком агрессивно закрыли архивы

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

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

• проверен список дублей в Search Console;
• настроен один основной вариант домена и протокола;
• у архивов, которые не нужны в поиске, стоит noindex;
• страницы вложений редиректят или закрыты;
• canonical на основных страницах указывает на чистый URL;
• robots.txt не блокирует страницы, которые должны быть переобойдены для снятия из индекса;
• проверены ответы сервера для старых и параметризованных URL.

Когда лучше не чинить кодом

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

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