Дубли страниц WordPress: вложения, метки, пагинация и как их закрыть

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

Как найти дубли страниц на сайте WordPress

Начинаю с Search Console, а не с плагинов. В отчёте по страницам смотрю причины, по которым адреса не попали в поиск. Мне нужны два статуса: «Дубликат без выбранной пользователем канонической версии» и «Страница является копией, Google выбрал другую каноническую версию». Если рядом с реальными статьями там висят адреса вида ?attachment_id=, /tag/ или /page/3/, источник понятен сразу.

Второй источник: оператор site:ваш-домен.ru в поиске. Общее число найденных адресов сравниваю с тем, сколько на сайте записей и страниц. Если вложений и архивов в выдаче больше, чем статей, сайт засорён.

Третий источник: сама база. Количество вложений считаю через WP-CLI:

wp post list --post_type=attachment --format=count

Если вложений сотни, а страницы вложений открыты, это сотни потенциальных дублей. Краулер вроде Screaming Frog дополняет картину: он показывает заголовки и мета-теги, совпадающие у разных адресов.

Какие дубли встречаются чаще всего и чем я их закрываю:

Далее разбираю каждую строку отдельно.

Страницы вложений: дубли от каждой картинки

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

Многие SEO-плагины умеют перенаправлять вложения сами. Прежде чем что-то добавлять, проверяю, не включён ли такой редирект: два одновременных обработчика дают цепочку из лишних перенаправлений. Если плагина нет, ставлю небольшой код в functions.php дочерней темы или в отдельный плагин:

add_action( 'template_redirect', function () {
    if ( ! is_attachment() ) {
        return;
    }
    $parent_id = wp_get_post_parent_id( get_queried_object_id() );
    $url = $parent_id ? get_permalink( $parent_id ) : home_url( '/' );
    wp_safe_redirect( $url, 301 );
    exit;
} );

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

После добавления кода проверяю старые адреса вида /?attachment_id=123 через curl -I: нужен ответ 301 и правильный Location. Сами файлы изображений в /wp-content/uploads/ при этом остаются доступными, поэтому поиск по картинкам не страдает.

Метки, рубрики и архивы: дубли контента внутри сайта

Метки самый частый источник мусора. Метка собирает анонсы записей, которые уже есть в рубрике и на главной. Если меток много, а под каждой две-три записи, получаются сотни страниц без собственной ценности. Что я делаю по порядку:

• Открываю в Search Console отчёт по эффективности и фильтрую адреса с /tag/. Если метки приносят показы и клики, их не трогаю, а наполняю описанием и оставляю в индексе.
• Если трафика нет, ставлю noindex, follow: страница остаётся для навигации, но из поиска уходит.
• Если метки заведены случайно и не используются в меню, полностью убираю их из шаблонов и чищу базу.

На сайтах с одним автором дублем главной блога становится архив автора. Здесь выбор простой: либо редирект на страницу блога, либо noindex. Архивы по датам (/2025/03/) закрываю так же, потому что искать записи по месяцам почти никто не приходит.

Если SEO-плагин уже управляет мета-роботами, настраиваю noindex в нём. Если плагина нет, подойдёт штатный фильтр wp_robots:

add_filter( 'wp_robots', function ( $robots ) {
    if ( is_tag() || is_author() || is_date() ) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }
    return $robots;
} );

Одна ловушка, на которую я натыкался: адреса, которые уже попали в индекс, нельзя закрывать в robots.txt. Робот не сможет зайти на страницу, не увидит noindex, и адрес так и останется в выдаче. Сначала noindex и ожидание, пока адреса выпадут, и только потом, если это вообще нужно, запрет в robots.txt.

Рубрики (/category/) обычно оставляю индексируемыми: у них есть смысловая роль в структуре. Закрываю лишь рубрики-пустышки без текста и с одной записью.

Пагинация и параметры URL: страницы-копии с одним содержимым

С пагинацией мне чаще всего приходится спорить с клиентами, которые прочитали, что «страницы пагинации надо закрывать». Закрывать noindex все страницы /page/2/, /page/3/ и дальше нужно не всегда: записи, лежащие глубоко в архиве, роботу проще найти именно через них. Дублем страница пагинации становится, когда у неё одинаковые заголовок и описание с первой страницей, а каноникал указывает на неё же неверно. Поэтому проверяю три вещи:

1. У страницы 2 каноникал ведёт на саму страницу 2, а не на первую. Канонизация всех страниц на первую выбрасывает записи из обхода.
2. Адрес /page/1/ перенаправляется на основной адрес архива.
3. Заголовки страниц пагинации различаются: SEO-плагин обычно добавляет к ним номер страницы.

Отдельная история с комментариями. Если на странице включена разбивка комментариев, появляются адреса вида /comment-page-2/ с тем же текстом статьи. Если комментариев немного, отключаю разбивку в настройках обсуждения. Если много, проверяю, что на таких адресах стоит каноникал на основную запись.

Параметры в URL разные по происхождению:

• utm_ метки из рекламы и рассылок создают копию любой страницы. WordPress для записей выводит каноникал на постоянную ссылку, поэтому здесь обычно достаточно проверить, что тема или плагин не затирают этот тег.
• ?replytocom= появляется из ссылок «Ответить» в комментариях. Каноникал на статью решает вопрос.
• ?s= это внутренний поиск. Результаты поиска ничего не дают поисковику, их закрываю через noindex, а для новых сайтов дополнительно запрещаю /?s= и /search/ в robots.txt.
• В WooCommerce добавляются параметры сортировки ?orderby= и фильтры. На магазинах с оплатой через Т‑Банк именно они создавали самый большой хвост адресов: каждая комбинация фильтров превращалась в отдельный URL. Каноникал на чистую категорию обязателен.

Если нужен исходный robots.txt, у меня есть шаблоны robots.txt для 7 типов сайтов и отдельный блок для ИИ-ботов, который можно адаптировать под WordPress.

Технические копии адресов: www, http и слеш на конце

Когда один и тот же материал открывается по четырём вариантам домена (http или https, с www или без), для поисковика это четыре сайта. WordPress умеет сам приводить адрес к основному через встроенный redirect_canonical: он убирает лишние варианты слеша и перенаправляет запросы вида /?p=123 на постоянную ссылку. Но на редирект между http и https, а также между www и без www он полагается на адрес сайта из настроек и на конфигурацию хостинга, поэтому рассчитывать только на ядро нельзя.

Проверяю все варианты одной командой:

curl -sI http://example.ru/ | grep -i -E "^(HTTP|location)"
curl -sI http://www.example.ru/ | grep -i -E "^(HTTP|location)"
curl -sI https://www.example.ru/ | grep -i -E "^(HTTP|location)"
curl -sI https://example.ru/ | grep -i -E "^(HTTP|location)"

Правильный результат: три варианта отвечают одним 301 сразу на основной адрес, а основной отдаёт 200. Если вижу цепочку из двух перенаправлений (например, сначала на https, затем на без www), правлю правила в .htaccess или в панели хостинга, чтобы переход был один.

Отдельно поглядываю на 404: у WordPress есть угадывание адреса по началу слага, и неправильная ссылка иногда уходит редиректом на похожую запись. Это не дубль в чистом виде, но если угадывание срабатывает на сотнях старых адресов, в отчёте появляются неожиданные соответствия, и я проверяю такие случаи руками.

Чек-лист закрытия дублей по порядку

Когда я беру сайт в работу, порядок такой, и менять его местами не стоит: сначала то, что даёт максимум лишних адресов при минимуме риска.

1. Снимаю отчёт Search Console по страницам и выписываю типы исключённых адресов.
2. Считаю вложения через WP-CLI и проверяю, открыты ли их страницы.
3. Включаю 301 с вложений на родительскую запись, проверяю через curl -I.
4. Просматриваю метки в отчёте эффективности: полезные оставляю, остальным ставлю noindex, follow.
5. Закрываю архивы автора и дат, если сайт с одним автором.
6. Проверяю каноникал и заголовки на страницах пагинации, редирект с /page/1/.
7. Проверяю параметры: utm, replytocom, поиск, сортировки WooCommerce.
8. Прогоняю четыре варианта домена, добиваюсь одного 301.
9. Проверяю карту сайта: в ней не должно быть вложений, закрытых меток и архивов.
10. Через несколько недель возвращаюсь в Search Console и сверяю, что закрытые типы адресов уходят из индекса.

Пункт про карту сайта пропускают чаще всего. Если закрытая страница лежит в sitemap, это прямой конфликт сигналов: вы одновременно просите проиндексировать адрес и запрещаете его индексировать.

Условия и возможности WordPress, Search Console и SEO-плагинов меняются, поэтому перед внедрением я сверяюсь с актуальной документацией.

Частые вопросы

Чем noindex отличается от canonical, и что выбрать для дублей?

Noindex говорит поисковику не включать страницу в выдачу. Canonical сообщает, какая страница считается основной среди похожих. Для метки без самостоятельной ценности подходит noindex, для адреса с параметрами, который отдаёт тот же контент, что и чистый, подходит canonical. Вложения лучше не закрывать тегами, а перенаправлять.

Нужно ли закрывать пагинацию целиком?

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

Сколько ждать результата после закрытия дублей?

Поисковик должен заново обойти адреса, и срок зависит от того, как часто он заходит на сайт. Для небольшого блога это обычно недели, для крупного магазина дольше. Ускорить можно, добавив исправленные адреса в карту сайта и отправив ключевые страницы на переобход в Search Console.

Что делать, если вложения уже попали в индекс?

Настроить 301 на родительскую запись и не запрещать эти адреса в robots.txt. Роботу нужно зайти по старому адресу, получить редирект и заменить его в индексе на статью. Запрет в robots.txt остановит этот процесс.