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

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

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

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

Симптомы обычно видны в Search Console и в логах обхода. Страницы могут индексироваться с разными параметрами, а в выдаче всплывают не те URL, которые вы считали основными. Часто это заметно по таким признакам:

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

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

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

<link rel="canonical" href="https://example.com/post-slug/" />

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

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

robots.txt полезен для отсечения очевидного мусора, но он не решает проблему дублей сам по себе. Если URL уже в индексе, запрет на обход не удалит его мгновенно. Поэтому robots.txt — это инструмент для экономии обхода, а не для «удаления из поиска».

Обычно имеет смысл закрывать служебные и бесполезные для индексации разделы:

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

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=
Disallow: /*?utm_
Sitemap: https://example.com/sitemap_index.xml

Здесь есть важная оговорка: правило Disallow: /*?utm_ не удаляет уже проиндексированные URL с UTM, а только ограничивает обход. Если у вас много таких ссылок в индексе, лучше сначала убрать генерацию этих параметров во внутренних ссылках и дождаться переобхода.

Когда нужен canonical, а когда лучше редирект

Если у страницы есть несколько доступных адресов, canonical помогает поисковику выбрать основной вариант без жесткого перенаправления. Это удобно для пагинации, фильтров, параметров сортировки и UTM. Но canonical не заменяет редирект там, где у вас реально дублируется одна и та же сущность.

Пример редиректа в .htaccess

Если у записи есть старый и новый адрес, лучше не надеяться на canonical, а перевести старый URL на новый через 301. Для Apache это можно сделать через .htaccess:

RewriteEngine On
RewriteCond %{THE_REQUEST} \s/+old-post/?[\s?] [NC]
RewriteRule ^old-post/?$ /new-post/ [R=301,L]

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

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

1. Соберите список URL, которые дублируют друг друга: Search Console, серверные логи, ручная проверка страниц с параметрами.
2. Определите тип дубля: параметр, архив, пагинация, служебный маршрут, старая версия URL.
3. Для параметров и фильтров оставьте страницу открытой, но задайте canonical на чистый адрес.
4. Для старых адресов сделайте 301-редирект на основной URL.
5. Для бесполезных архивов и служебных страниц решите, что безопаснее: noindex, удаление или ограничение обхода.
6. Проверьте sitemap: в нем должны быть только канонические URL.

Если нужен noindex, делайте это осознанно

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

Для WordPress это часто делают через SEO-плагин или через фильтры темы/плагина. Если вы пишете кодом, не забывайте, что noindex должен быть осмысленным и точечным.

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

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

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

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

• Откройте страницу и проверьте canonical в исходном коде.
• Проверьте, что старый URL отдает 301, а не 200.
• Убедитесь, что в sitemap нет мусорных адресов.
• Посмотрите, исчезли ли дубли в отчете по страницам с альтернативным canonical.
• Проверьте, не закрыли ли вы случайно полезные архивы или рубрики.

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

curl -I https://example.com/old-post/

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

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

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

Это нормальная ситуация. Robots.txt запрещает обход, но не гарантирует удаление из поиска. Если нужно убрать страницу из индекса, используйте noindex или 301-редирект, а затем дождитесь переобхода.

Canonical указывает на несуществующую страницу

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

Слишком широкие правила в .htaccess

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

Плагин SEO и тема ставят разные canonical

Это частый конфликт. В итоге в коде страницы может быть два canonical, а поисковик выберет не тот, который вы ожидали. Проверьте, не дублируют ли друг друга SEO-плагин, тема и кастомный код в wp_head.

Что помогает держать сайт чище в долгую

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

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

Самый надежный критерий простой: если после изменения у страницы остался один основной URL, он отдает 200, в sitemap лежит только он, а в Search Console не растет число альтернативных версий — значит, схема работает.