Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелочей: архивы тегов, пагинация, параметры в URL, версии с www и без него, страницы вложений, сортировки, UTM-параметры. В итоге поисковик видит несколько адресов с одинаковым или почти одинаковым содержимым и выбирает не тот URL, который нужен вам.
Если задача не в «косметике», а в реальной технической чистке, сначала нужно понять, какие именно дубли у вас есть: индексируемые копии, дубли с параметрами или страницы, которые должны остаться доступными, но не должны конкурировать в выдаче. От этого зависит, что применять — canonical, noindex или 301-редирект.
Какие дубли WordPress встречаются чаще всего
На практике чаще всего всплывают такие сценарии:
- одна и та же запись открывается по нескольким адресам из-за параметров в URL;
- страницы вложений медиафайлов индексируются отдельно, хотя содержимого там почти нет;
- архивы тегов и рубрик дублируют друг друга по смыслу;
- страницы пагинации попадают в индекс без необходимости;
- сайт доступен одновременно по
http/httpsилиwww/non-www; - фильтры и сортировки создают десятки URL с одинаковым контентом.
Диагностика проблемы: что проверить до правок
Не начинайте с массового закрытия всего подряд. Сначала проверьте, какие URL реально индексируются и где поисковик видит дубли.
Проверка в Search Console и по сайту
Откройте отчёт по страницам и посмотрите, какие адреса попали в индекс. Затем вручную сравните несколько вариантов одного и того же материала:
- основной URL записи;
- URL с параметром
?utm_source=...; - URL вложения изображения;
- URL архива рубрики или тега;
- URL с
wwwи без него.
Если контент одинаковый, а адреса разные — это уже кандидат на канонизацию или редирект.
Быстрая проверка через консоль
Если есть доступ к серверу, можно посмотреть, как сервер отвечает на разные варианты адреса:
curl -I https://example.com/sample-post/
curl -I https://www.example.com/sample-post/
curl -I "https://example.com/sample-post/?utm_source=test"В идеале у сайта должен быть один основной вариант домена, а параметризованные URL не должны создавать отдельные индексируемые копии без необходимости.
Что делать: canonical, noindex или редирект
Здесь важно не путать инструменты. Они решают разные задачи.
| Подход | Когда использовать | Компромисс |
|---|---|---|
canonical | Когда страница должна открываться, но поисковику нужен основной URL | Не убирает дубль физически, только подсказывает приоритет |
noindex | Когда страница полезна пользователю, но не нужна в поиске | Страница остаётся доступной, но может дольше выпадать из индекса |
| 301-редирект | Когда дубль не нужен вообще и есть явный основной адрес | Нужно аккуратно проверить цепочки редиректов |
Когда достаточно canonical
canonical подходит для страниц с параметрами, сортировками, UTM-метками, а также для архивов, если вы хотите оставить их доступными. Для WordPress это часто лучший вариант для страниц, которые не должны конкурировать с основной записью.
Пример: если одна и та же статья открывается как /post/ и /post/?utm_source=newsletter, параметризованную версию можно оставить доступной, но указать canonical на чистый URL.
Когда нужен noindex
noindex уместен для страниц вложений, служебных архивов, результатов внутреннего поиска и некоторых тегов, если они не несут самостоятельной ценности. Но не стоит закрывать всё подряд: если вы поставите noindex на важные рубрики, можно потерять полезный трафик.
Когда нужен 301-редирект
Редирект нужен там, где дубль не должен существовать как отдельная страница: http на https, www на без www, старые URL после смены структуры, вложения медиафайлов на родительскую запись. Это самый жёсткий и понятный вариант, если есть один правильный адрес.
Пошаговое решение без лишних рисков
Шаг 1. Зафиксируйте основной URL
Сначала убедитесь, что в WordPress и на сервере выбран один канонический вариант домена. В Настройки → Общие адреса сайта и WordPress должны совпадать с фактическим основным доменом. Если сайт должен жить на https://example.com, не оставляйте вторую версию доступной без редиректа.
Шаг 2. Закройте очевидные технические дубли редиректом
Для Apache можно использовать стандартный .htaccess. Пример для принудительного HTTPS и без www:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
</IfModule>Если у вас Nginx, правило будет другим, и его лучше править в конфиге сервера, а не через WordPress.
Шаг 3. Уберите индексацию страниц вложений
Страницы медиафайлов часто создают тонкий контент и дубли. Если они не нужны как отдельные посадочные, перенаправляйте их на файл или на родительскую запись. Для этого удобно использовать фильтр attachment_redirect_url или готовую логику в теме/плагине, но только если вы понимаете, куда именно должен вести переход.
Пример безопасной логики для перенаправления вложения на родительскую запись:
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$parent_id = wp_get_post_parent_id(get_queried_object_id());
if ($parent_id) {
wp_safe_redirect(get_permalink($parent_id), 301);
exit;
}
});Шаг 4. Добавьте canonical для страниц с параметрами
Если у вас есть фильтры, сортировки или UTM-метки, canonical должен указывать на чистую версию URL. В большинстве случаев SEO-плагины делают это автоматически, но после кастомных правок стоит проверить исходный код страницы.
Если нужно задать canonical вручную для конкретного шаблона, можно использовать фильтр wpseo_canonical в Yoast SEO или аналогичный механизм вашего SEO-плагина. Но не стоит смешивать несколько SEO-плагинов одновременно: они часто конфликтуют между собой.
Шаг 5. Закройте служебные архивы от индексации
Если теги, авторские архивы или страницы поиска не несут пользы, их можно закрыть от индексации. В WordPress это лучше делать точечно, а не глобально. Например, для архивов тегов можно добавить noindex через SEO-плагин или через собственную логику в wp_head, если проект небольшой и вы контролируете шаблоны.
add_action('wp_head', function () {
if (is_tag() || is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот вариант рабочий, но в реальном проекте лучше использовать SEO-плагин, чтобы не размазывать SEO-логику по теме.
Проверка результата после внедрения
После правок не ограничивайтесь открытием страницы в браузере. Проверьте три вещи: код ответа, canonical и отсутствие лишних дублей в индексе.
- основной URL отдаёт
200; - старые или альтернативные адреса отдают
301на нужную страницу; - в исходном коде у страницы указан один canonical;
- страницы, закрытые от индексации, содержат
noindex; - в Search Console постепенно уменьшается число дублей и альтернативных URL.
Для быстрой проверки canonical можно посмотреть HTML страницы:
curl -s https://example.com/sample-post/ | grep -i canonicalЕсли canonical указывает на другой адрес, чем вы ожидали, ищите конфликт в теме, SEO-плагине или в кэше.
Частые ошибки и как их исправить
Ставят noindex вместо редиректа
Это типичная ошибка. Если у страницы есть явный правильный адрес, лучше сделать 301. noindex не решает проблему дубля как такового, а только скрывает страницу из поиска.
Оставляют цепочки редиректов
Например, http → www → https → без www. Это лишняя задержка и риск ошибок. Нужен один прямой переход.
Закрывают от индексации важные рубрики
Иногда после чистки дублей случайно закрывают рубрики, которые приносят трафик. Перед изменениями проверьте, есть ли у архива поисковый спрос и входящие переходы.
Путают canonical и redirect
Canonical не меняет URL в адресной строке и не убирает дубль из доступа. Если нужен один адрес для пользователя и поисковика, используйте редирект.
Ломают кэш после правок
После изменения canonical или редиректов старый HTML может оставаться в кэше. Очистите серверный кэш, кэш плагина и, если используется CDN, его тоже.
Что стоит учесть для безопасности и производительности
Чистка дублей часто идёт рядом с оптимизацией, и здесь полезно не перегрузить сайт лишними проверками. Не вешайте тяжёлые запросы к базе на каждый wp_head, если это можно сделать через настройки SEO-плагина или через серверный редирект. Не добавляйте несколько независимых обработчиков canonical — это приводит к конфликтам и мусору в HTML.
Если нужен более аккуратный контроль над дублями, служебными архивами и технической чисткой, в проектах часто используют набор инструментов вроде Clearfy Pro: он помогает убрать часть типовых дублей и лишних сущностей без ручного размазывания логики по теме. Но даже с плагином всё равно нужно проверять результат в исходном коде и в Search Console.
Главный критерий простой: у каждой страницы должен быть понятный статус — либо это основной индексируемый URL, либо осознанный дубль с canonical, либо служебная страница с noindex, либо старый адрес, который честно уводит на новый 301-редирект.