Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелочей: архивы тегов, страницы автора, пагинация, параметры в URL, версии с ?replytocom, сортировки, UTM-метки, тестовые таксономии. Если их не контролировать, поисковик тратит краулинговый бюджет на мусорные URL, а в индексе начинают жить не те страницы, которые вы хотели продвигать.
Ниже — рабочая схема без магии: как диагностировать источник дублей, чем отличается robots.txt от noindex и canonical, что можно закрывать кодом, а что лучше оставить плагину или SEO-настройкам темы.
Как понять, что у вас именно проблема дублей
Не каждый странный URL — это проблема. Сначала нужно увидеть, какие версии страниц реально индексируются и какие из них конкурируют между собой. В WordPress это чаще всего видно по трем признакам: в поиске всплывают нецелевые архивы, в GSC растет число страниц с одинаковым заголовком, а в выдаче вместо статьи открывается тег, автор или пагинация.
Что проверить в первую очередь
- поиск по сайту через
site:example.ruи сравнение заголовков; - страницы с параметрами в URL:
?utm_,?replytocom, фильтры, сортировки; - архивы тегов, категорий, авторов и дат;
- страницы пагинации:
/page/2/,/page/3/; - дубли главной:
/page/2/на главной, версии с www и без www, http и https.
Если у вас есть доступ к Google Search Console, откройте отчеты по индексированию и посмотрите, какие URL помечены как дубли, альтернативные страницы с правильным canonical или просканированные, но не проиндексированные. Это самый честный источник, потому что он показывает не теорию, а то, что уже увидел робот.
Что закрывать robots.txt, а что — noindex
Здесь часто путают две разные задачи. robots.txt ограничивает обход, но не гарантирует удаление URL из индекса. noindex сообщает поисковику, что страницу не нужно индексировать, и это обычно правильный способ для тонких архивов и служебных страниц. canonical помогает выбрать основную версию, когда контент очень похож, но полностью закрывать дубль не нужно.
| Способ | Когда применять | Ограничение |
|---|---|---|
robots.txt | Для служебных разделов, которые не должны тратиться на обход | Не убирает уже проиндексированные URL |
noindex | Для архивов, пагинации, страниц с низкой ценностью | Страница должна быть доступна для обхода |
canonical | Для похожих страниц и параметров URL | Не подходит, если страницы реально разные по смыслу |
Практический вывод простой: если страница не должна индексироваться, но поисковик должен ее увидеть и понять, что делать, используйте noindex. Если нужно просто сократить обход мусорных URL, можно дополнить robots.txt. Если есть основная версия и несколько технических дублей — ставьте canonical на основную.
Пошаговое решение: от диагностики к настройке
Шаг 1. Уберите технические дубли на уровне адресов
Сначала приведите сайт к одной канонической схеме: один протокол, один хост, один вариант со слешем или без него. Это делается на уровне сервера и WordPress, а не через мета-теги. Если у вас гуляют www и без www, поисковик будет считать это разными адресами, пока вы не зададите жесткий редирект.
Для Apache базовая схема выглядит так:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.ru$ [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [L,R=301]На Nginx логика та же, только в конфиге сервера. Если вы не уверены, лучше не править это в WordPress-плагине, а сделать на уровне веб-сервера: так меньше шансов получить цепочки редиректов.
Шаг 2. Закройте архивы, которые не несут ценности
Для большинства контентных сайтов под WordPress архивы тегов и авторов часто создают больше шума, чем пользы. Это не значит, что их нужно удалять всегда. Но если теговые страницы пустые, слабо заполнены или дублируют категории, их лучше закрыть от индексации.
Если вы работаете через SEO-плагин, ищите настройки индексации архивов. Если нужно сделать это кодом, можно добавить noindex для отдельных типов архивов через wp_head:
add_action('wp_head', function () {
if (is_tag() || is_author() || is_date()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Это рабочий вариант, но использовать его стоит аккуратно: если у вас сильные авторские страницы или теговые подборки реально приводят трафик, закрывать их не нужно. Сначала проверьте их в аналитике и поиске.
Шаг 3. Настройте canonical для похожих страниц
Canonical нужен там, где есть несколько URL с почти одинаковым содержимым. Типичный пример — статья с параметрами в адресе, печатная версия, сортировка, UTM-метки, иногда пагинация. Canonical должен указывать на основную чистую версию.
В WordPress для записей canonical обычно уже выводится ядром или SEO-плагином. Проблемы начинаются, когда тема или кастомный код подменяют заголовки, убирают wp_head() или выводят дублирующий canonical вручную. Проверьте, что в шаблоне есть вызов wp_head() перед закрывающим </head>.
<head>
<meta charset="<?php bloginfo('charset'); ?>">
<?php wp_head(); ?>
</head>Если wp_head() отсутствует, вы теряете не только canonical, но и мета-теги, стили, скрипты и часть интеграций плагинов. Это одна из самых частых причин, почему SEO-настройки «не работают».
Шаг 4. Ограничьте мусорные параметры в URL
Параметры вроде ?replytocom и UTM-меток часто плодят технические дубли. Для UTM обычно достаточно canonical на чистую страницу. Для ?replytocom лучше отключить сам механизм, если он не нужен, или хотя бы не давать ему индексироваться.
Если вы хотите убрать ?replytocom из ссылок комментариев, можно отключить его фильтром:
add_filter('comment_reply_link', function ($link) {
return preg_replace('/([?&])replytocom=\d+/', '', $link);
});Но перед внедрением проверьте, как у вас работает ответ на комментарии в текущей теме. В некоторых шаблонах этот параметр завязан на JS и удаление может сломать UX. Иногда проще закрыть такие URL от индексации и оставить функциональность как есть.
Когда лучше использовать плагин, а когда — код
Если сайт небольшой и у вас стандартная структура, часть задач проще закрыть через SEO-плагин или через набор настроек темы. Если проект кастомный, с нестандартными таксономиями и шаблонами, код дает больше контроля. Но код нужно поддерживать, а плагин — проверять после обновлений.
| Подход | Плюсы | Минусы |
|---|---|---|
| SEO-плагин | Быстро, без правки шаблонов, удобно для редакторов | Может конфликтовать с темой или другим SEO-кодом |
| Код в теме/плагине | Точный контроль, меньше лишнего интерфейса | Нужна проверка после обновлений и бэкап |
| robots.txt | Просто ограничить обход | Не решает проблему индексации уже известных URL |
Если вам нужен более широкий набор технических правок — от чистки дублей до отключения лишних архивов и служебных элементов — имеет смысл смотреть в сторону инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином важно понимать, что именно вы закрываете и зачем.
Проверка результата после внедрения
После настройки нельзя ограничиваться тем, что «на странице появился meta robots». Нужно проверить, как это видит браузер, валидатор и поисковый робот.
Что смотреть вручную
- исходный код страницы: есть ли
canonicalи нужныйmeta robots; - открывается ли основная версия без цепочки редиректов;
- не дублируются ли canonical из темы и плагина;
- не закрыли ли вы случайно важные страницы, которые должны индексироваться;
- нет ли в sitemap URL, которые вы уже пометили как
noindex.
Для быстрой проверки можно использовать просмотр HTML-кода страницы и команду curl:
curl -I https://example.ru/post-name/
curl -s https://example.ru/post-name/ | grep -iE 'canonical|robots'Если в ответе виден 301 на нужный адрес, а в HTML — один canonical на чистый URL и корректный robots-метатег, базовая настройка сделана правильно. Дальше остается дождаться повторного обхода страниц и проверить отчеты в Search Console.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она все равно в индексе
Это ожидаемо. Если URL уже известен поисковику, запрет на обход не гарантирует удаление из индекса. Решение: временно открыть страницу для обхода, поставить noindex, дождаться переобхода и только потом при необходимости ограничивать crawl.
Поставили noindex на страницу, но оставили ее в sitemap
Так делать не стоит. Sitemap должен содержать только те URL, которые вы хотите индексировать. Иначе вы отправляете поисковику противоречивые сигналы: в карте сайта URL есть, а на странице написано не индексировать.
Canonical указывает не туда
Часто это происходит после правок темы или при конфликте SEO-плагинов. Проверьте, не выводится ли второй canonical в <head>. Если их два, поисковик может проигнорировать оба или выбрать не тот.
Закрыли слишком много архивов
Иногда под нож попадают полезные страницы: авторские профили, тематические подборки, страницы рубрик с трафиком. Перед массовым noindex посмотрите статистику по входам и запросам. Если архив приносит переходы и отвечает на отдельный интент, его лучше оставить.
Удалили параметры URL, но сломали функциональность
Это типично для ?replytocom, фильтров и сортировок. Сначала проверьте, где параметр используется в интерфейсе, и только потом убирайте его из ссылок или закрывайте от индексации.
Практические советы по безопасности и производительности
Любые правки, связанные с SEO-кодом, лучше вносить не в активную тему напрямую, а в дочернюю тему или в небольшой mu-plugin. Так вы не потеряете изменения при обновлении. Перед правками сделайте резервную копию файлов и базы, особенно если меняете шаблоны header.php, functions.php или логику редиректов.
Еще один практический момент: не плодите несколько инструментов, которые одновременно управляют canonical, noindex и архивами. Когда один плагин закрывает теги, другой переписывает мета-теги, а тема добавляет свой SEO-код, отладка превращается в угадайку. Лучше оставить один источник правды для SEO-логики и проверить его после обновлений.
Если на сайте уже накопилось много дублей, начните не с массового закрытия всего подряд, а с карты проблемных URL: какие из них должны индексироваться, какие — только обходиться, а какие — редиректиться на основную версию. Такой подход обычно быстрее приводит к чистой структуре, чем попытка «починить SEO» одной настройкой.