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

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

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

Как понять, что у вас именно проблема дублей

Сначала стоит отделить настоящие дубли от просто похожих страниц. В WordPress это часто путают. Например, архив категории и страница записи не дубль, а вот одна и та же запись, доступная по адресу с ?utm_, через пагинацию комментариев или через несколько архивов, уже создаёт лишние варианты.

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

• Есть ли у страниц одинаковый заголовок и почти одинаковый <title>.
• Открываются ли записи с параметрами в URL: ?replytocom=, ?utm_, ?amp, сортировка, фильтры.
• Есть ли архивы тегов, авторов, дат, которые дублируют контент рубрик.
• Не индексируются ли страницы пагинации, если они не несут самостоятельной ценности.
• Совпадает ли в исходном коде canonical с тем адресом, который вы считаете основным.

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

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

Это ключевой момент. robots.txt не удаляет URL из индекса и не решает проблему дубля сам по себе. Он только ограничивает обход. canonical показывает предпочтительную версию страницы. Поэтому эти инструменты работают по-разному и не взаимозаменяемы.

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

Пошаговая схема: как убрать дубли без лишнего риска

Шаг 1. Составьте список типов дублей

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

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

Шаг 2. Настройте canonical для основных типов страниц

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

Пример для записи: если вы выводите кастомный шаблон и хотите явно задать canonical, можно использовать фильтр wpseo_canonical в Yoast SEO или аналогичный механизм в вашем SEO-плагине. Ниже пример для случая, когда нужно убрать параметр ?replytocom и всегда указывать чистый URL записи:

<?php
add_filter( 'wpseo_canonical', function( $canonical ) {
    if ( is_singular( 'post' ) ) {
        $canonical = get_permalink();
    }

    return $canonical;
} );

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

Шаг 3. Закройте лишние архивы от индексации

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

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

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

    return $robots;
} );

Это не заменяет canonical, но помогает поисковику не держать в индексе страницы, которые не несут самостоятельной ценности.

Шаг 4. Ограничьте обход технических параметров

Параметры вида ?replytocom= и некоторые сортировки могут плодить копии URL. Их обычно не нужно индексировать и часто не нужно обходить. В robots.txt можно закрыть наиболее очевидные технические варианты, но без фанатизма: если запретить слишком много, поисковик перестанет видеть важные страницы.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?sort=
Disallow: /*?filter=

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

Этот пример нужно адаптировать под реальные параметры на сайте. Не копируйте его вслепую: если у вас нет фильтров или сортировки, такие правила не нужны. И не закрывайте в robots всё подряд с символом *, не проверив, как это влияет на обход.

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

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

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

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

curl -I https://example.com/sample-post/
curl -s https://example.com/sample-post/ | grep -i canonical

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

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

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

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

Поставили noindex на страницу, которая должна ранжироваться

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

Сломали canonical в шаблоне темы

Иногда разработчики вручную выводят <link rel="canonical"> в header.php, а SEO-плагин делает то же самое. В результате на странице два canonical, и это уже техническая ошибка. Оставьте один источник правды.

Закрыли слишком много в robots.txt

Если в Disallow попали CSS, JS или важные разделы, поисковик может хуже рендерить страницу. Это особенно заметно на сайтах, где часть контента подгружается скриптами. Проверяйте файл после каждого изменения.

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

Если у вас типовой сайт на WordPress без кастомной логики, часть задач проще и безопаснее закрыть через SEO-плагин. Это особенно удобно для noindex на архивах, управления canonical и генерации карты сайта. Например, в Clearfy Pro есть инструменты для чистки сайта, удаления дублей и управления техническими настройками, что полезно на проектах, где не хочется держать отдельный набор правок в теме. Но даже в этом случае нужно понимать, что именно отключается и почему.

Код имеет смысл, когда:

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

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

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

• Проверен список дублей по типам URL.
• Canonical указывает на основную версию страницы.
• Лишние архивы закрыты через noindex, а не случайно через robots.
• В robots.txt нет запрета на важные ресурсы.
• Проверены URL с параметрами и пагинация.
• В Search Console нет резкого роста исключённых страниц из-за ошибки в шаблоне.

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