Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелких настроек: архивы тегов, пагинация, версии с ?replytocom, страницы с параметрами, дубли категорий и один и тот же контент в нескольких шаблонах. На сайте это выглядит как «всё работает», а в поиске — как размытая индексация и конкуренция страниц между собой.
Ниже — рабочий сценарий: как быстро найти источник дублей, что исправлять в первую очередь и как проверить, что после правок поисковик видит только нужные URL.
Как понять, что проблема именно в дублях
Симптомы обычно неочевидны. Падение трафика может быть связано с контентом, но если в индексе одновременно живут несколько версий одной страницы, поисковик сам выбирает каноническую версию не всегда так, как вам нужно.
Что проверить в первую очередь
- одна и та же статья открывается по разным URL: с
wwwи без, сhttpиhttps, со слешем и без; - в индексе есть страницы тегов, архивов авторов и дат, которые дублируют подборки записей;
- страницы с параметрами
?replytocom,?amp,?utm_*или внутренними фильтрами попадают в поиск; - один и тот же текст доступен через запись, архив рубрики и страницу пагинации;
- в Search Console растёт число «Просканировано, но не проиндексировано» или «Дубли, выбранная пользователем canonical-страница отличается».
Если у вас есть доступ к логам сервера, полезно посмотреть, какие URL чаще всего запрашивают роботы. Это помогает отличить реальный дубль от единичного мусорного перехода.
Диагностика: где искать дубли в WordPress
Начинать лучше не с кода, а с карты сайта и фактических URL. Частая ошибка — править canonical «на глаз», не понимая, какие версии страниц уже отдаются сервером.
Проверка через браузер и Search Console
Откройте несколько проблемных страниц и сравните:
- адрес в строке браузера;
- значение
<link rel="canonical">в исходном коде; - страницу в индексе через оператор
site:и поиск по точному заголовку; - данные в отчёте об индексировании Google Search Console.
Если canonical указывает на одну версию, а страница доступна по другой, это уже повод проверить редиректы и настройки темы/плагинов.
Проверка через WP-CLI и базу
Если есть доступ к консоли, можно быстро найти записи с одинаковым slug или подозрительными дублями в таксономиях. Это не заменяет SEO-аудит, но помогает отсеять технический мусор.
wp post list --post_type=post --fields=ID पोस्ट_title,post_name,post_statusКоманда выше в чистом виде не отфильтрует дубли, но покажет, нет ли у вас нескольких записей с очень похожими slug. Для точечной проверки удобнее выгрузить список в CSV и сравнить вручную, если сайт небольшой.
Что исправлять: сравнение подходов
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин SEO | Нужно быстро закрыть теги, архивы, пагинацию и canonical без кода | Часть логики зависит от настроек плагина и темы |
| Код в теме или mu-plugin | Нужны точечные правила для конкретного сайта | Требует тестирования после обновлений |
| Редиректы на сервере | Нужно убрать дубли домена, протокола, слеша, старых URL | Можно сломать часть маршрутов при неверном шаблоне |
Если задача типовая, чаще всего хватает комбинации: нормализовать домен и протокол, закрыть лишние архивы от индексации, а для спорных страниц задать canonical вручную.
Пошаговое решение без лишнего риска
1. Нормализуйте основной домен и протокол
Сначала убедитесь, что одна и та же страница не доступна в четырёх вариантах. На уровне сервера или хостинга должен быть один основной адрес: либо с www, либо без него, и только на https.
Если редиректы ещё не настроены, сделайте это на стороне веб-сервера. Для Apache это обычно .htaccess, для Nginx — правило в конфиге. В WordPress не стоит пытаться решать это только через PHP, если проблема именно на уровне домена.
2. Закройте от индексации архивы, которые не несут ценности
На большинстве контентных сайтов дубли создают:
- архивы тегов без уникальной структуры;
- архивы автора на сайте с одним автором;
- архивы дат, если они не используются как навигация;
- служебные страницы поиска;
- пустые или почти пустые рубрики.
Если SEO-плагин позволяет, отключите индексирование этих типов архивов. Это безопаснее, чем массово удалять их из базы: URL остаются для навигации, но не конкурируют в поиске.
3. Уберите дубли через canonical
Если одна и та же сущность доступна по нескольким адресам, canonical должен указывать на единственную основную версию. В WordPress это можно сделать через фильтр wpseo_canonical, если у вас используется Yoast SEO, или через собственную логику в шаблоне, если canonical выводится вручную.
<?php
add_filter( 'wpseo_canonical', function( $canonical ) {
if ( is_search() ) {
return home_url( '/' );
}
if ( is_singular() ) {
return get_permalink();
}
return $canonical;
} );Этот пример не «лечит всё», но показывает принцип: canonical должен быть предсказуемым и не вести на технические страницы. Если у вас другой SEO-плагин, используйте его штатный фильтр, а не пытайтесь подменять разметку через буферизацию HTML.
4. Отключите лишние версии контента в теме
Иногда дубли создаёт сама тема: выводит один и тот же блок в карточке записи, в архиве и в отдельном шаблоне. Если в шаблоне есть повторяющиеся фрагменты, лучше вынести их в один partial и контролировать вывод через условные теги WordPress.
<?php
if ( is_singular( 'post' ) ) {
get_template_part( 'template-parts/content', 'single' );
} else {
get_template_part( 'template-parts/content', 'archive' );
}Так вы не будете случайно показывать полный текст статьи в архиве, где достаточно анонса. Это одна из самых частых причин внутреннего дублирования контента.
Если дубли создают параметры в URL
Параметры вроде ?replytocom или сортировок в фильтрах часто появляются в ссылках автоматически. Не всегда нужно их полностью запрещать: иногда это ломает комментарии или навигацию. Но для индексации такие URL обычно не нужны.
Практичный вариант — оставить их для пользователя, но не давать поисковику считать их отдельными страницами. Для этого:
- проверьте, не генерирует ли тема лишние ссылки с параметрами;
- убедитесь, что canonical указывает на чистый URL без параметров;
- при необходимости закройте шаблонные страницы поиска и фильтров от индексации.
Проверка результата после внедрения
После правок важно не просто «посмотреть сайт», а проверить, что поисковый и серверный слой ведут себя одинаково.
- Откройте несколько URL с разными вариантами домена и убедитесь, что все они редиректят на один адрес.
- Посмотрите исходный код страницы и проверьте canonical.
- Прогоните сайт через краулер или хотя бы вручную проверьте архивы, пагинацию и поиск.
- В Search Console отправьте на переобход несколько ключевых страниц и посмотрите, как меняется выбранный canonical.
Если после изменений в индексе всё ещё остаются старые версии, не спешите удалять их из базы. Сначала убедитесь, что на них стоит корректный редирект или canonical, и только потом принимайте решение о физическом удалении.
Частые ошибки и как их исправить
Canonical указывает на несуществующую страницу
Это происходит после смены slug или удаления записи. В результате поисковик видит цепочку: страница есть, canonical ведёт в 404. Исправление простое: canonical должен ссылаться только на живой URL с кодом ответа 200.
Редирект сделан в WordPress, а не на сервере
Для доменных дублей это слабое место. PHP-редирект срабатывает позже, чем серверный, и иногда создаёт лишнюю нагрузку. Если задача касается протокола, домена или слеша, лучше решать её на уровне Nginx/Apache.
Закрыли от индексации всё подряд
Иногда после аудита отключают теги, рубрики, архивы и поиск одновременно. В итоге сайт теряет внутреннюю навигацию и часть полезного трафика. Закрывайте только те типы страниц, которые реально дублируют основной контент.
Удалили дубли из базы без проверки ссылок
Если удалить записи, термины или страницы, не настроив 301-редирект, вы получите битые ссылки и потерю накопленного веса. Сначала редирект, потом удаление — не наоборот.
Чек-лист перед публикацией изменений
- основной домен и протокол выбраны один раз и везде одинаковы;
- canonical на ключевых страницах ведёт на чистый URL;
- архивы тегов, авторов и дат проверены на реальную пользу;
- страницы поиска и фильтров не попадают в индекс без необходимости;
- в шаблонах нет полного дублирования контента между архивом и single;
- редиректы не создают цепочки и петли;
- после правок проверен код ответа, canonical и индексация в Search Console.
Когда стоит использовать плагин, а когда код
Если у вас типовой сайт на стандартной теме, проще начать с SEO-плагина и его настроек индексации. Если же дубли появляются из-за кастомной логики темы, фильтров, параметров URL или нестандартных архивов, надёжнее зафиксировать поведение кодом в дочерней теме или mu-plugin.
Для задач вроде чистки дублей, архивов и технических страниц иногда удобно использовать инструменты уровня Clearfy Pro, но только если вы понимаете, что именно отключаете. Автоматическая «чистка» без проверки может убрать не мусор, а полезные URL.
Главный критерий простой: если после изменения вы можете объяснить, какой URL должен остаться основным и почему, значит решение, скорее всего, выбрано правильно.