wpbook.ru wordpress WP Book

Как найти и убрать дубли страниц в WordPress без потери SEO

Дубли в 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 без параметров;
  • при необходимости закройте шаблонные страницы поиска и фильтров от индексации.

Проверка результата после внедрения

После правок важно не просто «посмотреть сайт», а проверить, что поисковый и серверный слой ведут себя одинаково.

  1. Откройте несколько URL с разными вариантами домена и убедитесь, что все они редиректят на один адрес.
  2. Посмотрите исходный код страницы и проверьте canonical.
  3. Прогоните сайт через краулер или хотя бы вручную проверьте архивы, пагинацию и поиск.
  4. В 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 должен остаться основным и почему, значит решение, скорее всего, выбрано правильно.

×

AI-плагин от WPShop.ru

анализирует конкурентов

пишет статьи

готовит SEO

генерирует изображения

и еще кое-что...
WPGPT
Плагин, который наполняет ваш сайт WordPress
Узнать больше