Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелочей: страницы с и без слэша, http и https, www и без www, архивы тегов, пагинация, параметры в URL, отдельные версии для печати, а иногда и дубли из-за темы или SEO-плагина. В результате поисковик видит несколько адресов с одинаковым или почти одинаковым содержимым и выбирает не тот URL, который нужен вам.
Ниже — рабочий сценарий: как быстро диагностировать источник дублей, что исправлять в первую очередь и как проверить, что после изменений сайт не потерял важные страницы из индекса.
Как понять, что проблема именно в дублях
Сначала не трогайте код. Проверьте, какие URL реально индексируются и какие из них повторяют один и тот же контент. Для этого достаточно открыть несколько типовых страниц и сравнить:
- главную страницу с
https://site.ruиhttps://site.ru/; - страницу записи с разными вариантами слэша;
- архив рубрики, тега и автора;
- страницы пагинации:
/page/2/,/page/3/; - URL с параметрами, если они есть:
?utm_source=...,?replytocom=....
Если один и тот же текст открывается по нескольким адресам без редиректа, это уже кандидат на дубль. Если в выдаче Google или Яндекса видны разные версии одной страницы, проблема подтверждается.
Что смотреть в первую очередь
Откройте исходный код страницы и найдите тег rel="canonical". Он должен указывать на один основной адрес. Если canonical отсутствует, ведёт на не тот URL или меняется от страницы к странице без причины, поисковик может выбрать дубль сам.
Ещё один быстрый тест — заголовки ответа сервера. Для этого удобно использовать:
curl -I https://site.ru/stranica/В ответе проверьте код статуса. Для основного адреса должен быть 200, а старые или лишние варианты должны отдавать 301 на канонический URL. Если вместо редиректа вы видите 200 на нескольких адресах, это и есть технический дубль.
Какие дубли в WordPress встречаются чаще всего
На практике источник почти всегда один из этих:
| Источник дубля | Как выглядит | Что делать |
|---|---|---|
| Слэш в конце URL | /page и /page/ | Привести к одному формату и настроить 301 |
| www / без www | www.site.ru и site.ru | Выбрать один домен и редиректить второй |
| HTTP / HTTPS | http:// и https:// | Оставить только HTTPS |
| Архивы таксономий | рубрики, теги, авторы, даты | Закрыть лишнее от индексации или удалить архивы |
| Параметры URL | ?replytocom=, UTM, сортировки | Нормализовать canonical и редиректы там, где нужно |
Если сайт небольшой, чаще всего достаточно исправить канонизацию и редиректы. Если сайт контентный и архивов много, придётся ещё убирать лишние страницы из индекса и чистить внутренние ссылки.
Пошаговое решение: от диагностики к исправлению
1. Выберите один основной формат URL
В WordPress это начинается с настроек постоянных ссылок и домена сайта. Проверьте, что в Настройки → Общие указан один и тот же вариант домена, а в Настройки → Постоянные ссылки структура не меняется хаотично между публикациями.
Если сайт уже в индексе, не меняйте структуру без необходимости. Сначала настройте редиректы, потом обновляйте внутренние ссылки и sitemap.
2. Настройте 301-редиректы для лишних версий
Самый надёжный вариант — редирект на уровне сервера или через .htaccess для Apache. Пример для принудительного HTTPS и одного домена:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.site\.ru$ [NC]
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]Если у вас Nginx, правило обычно добавляют в конфигурацию сервера, а не в WordPress. Логика та же: один канонический хост, один протокол, один формат URL.
3. Проверьте canonical на страницах и архивах
Если используете SEO-плагин, убедитесь, что он не генерирует несколько canonical или не подставляет неправильный URL. На страницах записи canonical должен указывать на саму страницу, а не на рубрику, главную или версию с параметрами.
Для проверки откройте исходный код и найдите:
<link rel="canonical" href="https://site.ru/stranica/" />Если canonical отсутствует, это уже повод проверить тему и SEO-плагин. Иногда проблема появляется после кастомизации шаблона header.php или из-за ручного вывода метатегов.
4. Уберите лишние архивы из индекса
Теги, архивы автора и даты часто создают тонны почти пустых страниц. Если они не несут ценности, их лучше закрыть от индексации или отключить вывод на уровне темы/плагина. Но не делайте это вслепую: если архивы дают трафик, сначала посмотрите статистику.
Практический подход такой:
- оставить индексируемыми только те рубрики, которые реально помогают навигации;
- теги использовать аккуратно, без автоматического размножения;
- архивы дат и авторов отключать, если они не нужны пользователям;
- не плодить страницы поиска по сайту в индексе.
5. Нормализуйте параметры URL
Параметры вроде ?replytocom= или UTM не должны создавать отдельные индексируемые страницы. Для UTM обычно достаточно canonical на чистый URL. Для технических параметров иногда нужен редирект или настройка в SEO-плагине, но сначала проверьте, не ломает ли это аналитику и формы.
Если проблема в комментариях WordPress и параметре replytocom, часто помогает отключение этой механики на уровне темы или плагина, но делать это надо аккуратно: на старых сайтах могут быть ссылки из внешних источников.
Когда лучше исправлять через код
Если дубль создаёт тема или кастомный плагин, проще убрать причину в коде, чем пытаться лечить последствия SEO-настройками. Например, если шаблон выводит лишние ссылки на архивы или делает отдельные версии контента для мобильных страниц без необходимости, это надо править в шаблоне.
Ниже пример, как принудительно задать canonical для записей, если тема его не выводит или выводит неправильно. Код можно добавить в дочернюю тему или в небольшой mu-plugin.
<?php
add_action('wp_head', function () {
if (is_singular()) {
echo '<link rel="canonical" href="' . esc_url(get_permalink()) . '" />' . "\n";
}
}, 1);Это не заменяет полноценную SEO-настройку, но помогает, если проблема именно в шаблоне. Если canonical уже выводится SEO-плагином, не дублируйте его вручную.
Ещё один полезный вариант — редиректить вложения медиафайлов на сам файл или на родительскую запись. В WordPress страницы вложений часто создают мусорные URL без пользы для пользователя.
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$url = wp_get_attachment_url(get_queried_object_id());
if ($url) {
wp_redirect($url, 301);
exit;
}
}
});Если у вложений нет отдельной ценности, такой редирект обычно уменьшает количество бесполезных страниц в индексе.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Смотрите именно поведение URL и индексацию.
- Откройте старый и новый адреса в браузере: старый должен вести на канонический через
301. - Проверьте заголовки через
curl -Iили любой HTTP checker. - Посмотрите исходный код и убедитесь, что canonical один и правильный.
- Проверьте sitemap: в нём должны быть только канонические URL.
- В Search Console или Яндекс Вебмастере отправьте на переобход важные страницы.
Если после редиректов страница стала отдавать 302 вместо 301, это надо исправить. Временный редирект не подходит для нормализации дублей.
Частые ошибки и как их исправить
Ставят noindex вместо редиректа
Это частая подмена понятий. Если у страницы есть дубль, который не нужен пользователю, лучше убрать сам дубль через 301. noindex не решает проблему дублирования ссылочного веса и не всегда быстро вычищает URL из индекса.
Оставляют несколько canonical
Так бывает, когда canonical выводит SEO-плагин, а тема добавляет свой тег вручную. В итоге в коде два canonical, и поисковик может проигнорировать оба. Оставьте только один источник.
Меняют URL без редиректов
Если вы поменяли структуру постоянных ссылок или убрали префикс www, но не настроили 301, старые адреса останутся жить отдельно. Это почти гарантированный источник дублей и битых внешних ссылок.
Закрывают от индексации всё подряд
Иногда после борьбы с дублями закрывают и полезные рубрики, и страницы пагинации, и важные архивы. Это уже не чистка, а потеря структуры сайта. Сначала определите, какие страницы реально нужны пользователю и поиску.
Что делать для безопасности и производительности
Если вы правите редиректы и canonical вручную, не разбрасывайте код по нескольким файлам темы. Лучше вынести изменения в дочернюю тему или отдельный mu-plugin. Так обновление темы не сломает логику.
Перед правками сделайте резервную копию базы и файлов. Особенно если планируете массово менять URL через поиск и замену в базе. Для больших сайтов безопаснее сначала прогнать изменения на staging-копии.
Если дублей много из-за технического мусора, иногда помогает чистка сайта и SEO-настроек через специализированные инструменты. Например, в Clearfy Pro есть функции, которые помогают убрать часть лишних архивов и дублей без ручного редактирования шаблонов: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, что именно отключаете, чтобы не убрать полезные страницы.
Если нужен короткий рабочий чек-лист перед публикацией изменений, используйте такой порядок:
- определить канонический домен и формат URL;
- настроить 301 для старых вариантов;
- проверить canonical на ключевых шаблонах;
- убрать лишние архивы и параметры из индекса;
- обновить sitemap;
- перепроверить заголовки ответа и индексацию через 1–2 обхода поисковиком.
Когда всё сделано правильно, у страницы остаётся один основной адрес, старые варианты ведут на него без цепочек редиректов, а в индексе постепенно остаются только нужные URL.