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

В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за нормальной работы движка: архивы тегов, авторов, дат, пагинация, страницы вложений, параметры в URL, версии для печати, сортировки и фильтры. Проблема начинается тогда, когда поисковик видит несколько адресов с одинаковым или почти одинаковым содержимым и начинает тратить краулинговый бюджет не туда.

Если у сайта уже есть трафик, закрывать всё подряд нельзя. Ошибка в noindex, каноникале или robots.txt легко выкидывает из индекса нужные страницы. Ниже — рабочий порядок: сначала диагностика, потом точечное решение, затем проверка результата.

Откуда в WordPress берутся дубли

В типовой установке WordPress дубли появляются в нескольких местах. Часть из них полезна для навигации, но не нужна в поиске. Часть — технические страницы, которые лучше не индексировать вообще. Важно не путать «дубль» и «похожую страницу»: например, архив рубрик и отдельная запись не дублируют друг друга, а вот страницы вложений часто действительно повторяют контент записи или медиабиблиотеки.

Типовые источники дублей

• архивы тегов и авторов на небольших сайтах;
• страницы вложений медиафайлов;
• пагинация архивов и комментариев;
• URL с параметрами ?replytocom=, ?utm_, сортировками и фильтрами;
• страницы поиска по сайту;
• версии для печати и служебные шаблоны темы;
• дубли главной страницы из-за настроек канонического URL или редиректов.

Диагностика: что именно индексируется лишнее

Перед правками нужно понять, какие URL уже попали в индекс и как поисковик их видит. Самый быстрый путь — посмотреть отчёты в Google Search Console и пройтись по сайту краулером. Если доступа к GSC нет, можно хотя бы собрать список подозрительных URL через поиск по сайту и лог сервера.

Что проверить вручную

• есть ли в индексе страницы вида /tag/, /author/, /attachment/;
• появляются ли дубли с параметрами в URL;
• не индексируются ли страницы пагинации, которые не несут самостоятельной ценности;
• совпадает ли canonical на странице с основным адресом;
• не закрыт ли случайно важный раздел через noindex или Disallow.

Если используете командную строку на сервере, полезно быстро посмотреть, какие URL отдают одинаковый контент и заголовки. Например, через curl можно проверить canonical и robots meta на нескольких типовых страницах:

curl -s https://example.com/tag/news/ | grep -iE 'canonical|robots'
curl -s https://example.com/author/admin/ | grep -iE 'canonical|robots'
curl -s https://example.com/?replytocom=1 | grep -iE 'canonical|robots'

Пошаговое решение: что закрывать, а что оставить

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

Шаг 1. Закрыть страницы вложений и служебные архивы

Страницы вложений почти всегда бесполезны для поиска, если вы не строили под них отдельную стратегию. Их лучше редиректить на родительскую запись или медиафайл. Для архивов авторов и дат решение зависит от структуры сайта: на блоге с несколькими авторами они могут быть полезны, на небольшом корпоративном сайте — обычно нет.

Если вы правите тему или плагин, не делайте это через хаотичные вставки в шаблоны. Надёжнее использовать фильтры WordPress и один небольшой mu-plugin.

<?php
/**
 * Plugin Name: WPTalk SEO Cleanup
 */

add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = get_post_field('post_parent', get_queried_object_id());
        if ($parent) {
            wp_redirect(get_permalink($parent), 301);
            exit;
        }

        wp_redirect(home_url('/'), 301);
        exit;
    }
});

Этот вариант безопаснее, чем просто ставить noindex на страницы вложений: URL перестаёт быть отдельной точкой входа и не плодит мусор в обходе.

Шаг 2. Добавить noindex там, где страница нужна пользователю, но не поиску

Для страниц поиска, некоторых архивов тегов, авторов и пагинации часто достаточно noindex,follow. Это оставляет ссылки доступными для обхода, но убирает страницу из индекса. В WordPress можно сделать это через wp_robots без правки <head> вручную.

<?php
add_filter('wp_robots', function (array $robots) {
    if (is_search() || is_author() || is_date()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    if (is_paged() && !is_singular()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Если у вас уже стоит SEO-плагин, проверьте, не конфликтует ли он с этим фильтром. Два источника мета-robots на одной странице — частая причина странного поведения в индексе.

Шаг 3. Убрать параметры, которые создают мусорные URL

Параметры utm_* сами по себе не проблема, если каноникал указывает на чистый URL. Но некоторые параметры реально создают отдельные страницы или ломают кэш. Классический пример — ?replytocom= в старых темах и плагинах комментариев. Если параметр не нужен, лучше убрать его источник, а не пытаться лечить последствия.

Для WordPress можно отключить параметр комментариев через фильтр, если он используется только как технический мусор:

<?php
add_filter('comment_reply_link', function ($link) {
    return preg_replace('/replytocom=\d+/', '', $link);
});

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

Сравнение подходов: что выбрать в реальном проекте

Частая ошибка — пытаться удалить URL из индекса только через robots.txt. Если страница уже известна поисковику, запрет на обход не всегда решает задачу. Для удаления из индекса обычно нужен noindex или редирект.

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

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

Минимальный чек-лист

• открыть несколько проблемных URL в браузере и убедиться, что они редиректятся или содержат noindex;
• проверить исходный код страницы на наличие одной канонической ссылки;
• посмотреть ответ сервера через curl -I и убедиться, что нет неожиданных 200/302;
• в Search Console отправить на повторную проверку проблемные URL;
• через несколько дней сравнить отчёт по индексированию и число страниц с параметрами.

Пример быстрой проверки заголовков:

curl -I https://example.com/attachment/sample-image/
curl -I https://example.com/search/test/
curl -I https://example.com/tag/news/

Если страница должна быть закрыта, но всё ещё отдаёт 200 OK и не содержит noindex, значит правка не сработала или её перетирает тема/плагин.

Частые ошибки и как их исправить

Закрыли в robots.txt и ждёте удаления из индекса

Это самая распространённая ошибка. Disallow мешает обходу, но не всегда убирает URL из выдачи. Если страница уже в индексе, добавьте noindex или сделайте 301 на нужный адрес.

Поставили noindex на всё подряд

Иногда после установки SEO-плагина в noindex уезжают рубрики, важные записи или даже главная. Причина обычно в неверных настройках шаблонов мета-тегов или в конфликте фильтров. Проверяйте исходный код нескольких типов страниц, а не только одну.

Оставили страницы вложений без редиректа

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

Сломали каноникал на пагинации

Иногда разработчики ставят canonical со всех страниц архива на первую страницу. Это спорное решение: для некоторых сайтов оно допустимо, но часто мешает индексации полезных страниц пагинации. Сначала проверьте, есть ли у вас реальная ценность у второй и последующих страниц архива.

Безопасность и производительность: что учесть до выката

Любые правки, связанные с индексированием, лучше вносить через дочернюю тему, mu-plugin или отдельный маленький плагин. Не редактируйте ядро и не встраивайте логику в случайный шаблон, который потом обновится и затрёт изменения.

Если сайт на кэше, после изменений обязательно сбросьте:

• страничный кэш;
• объектный кэш, если он используется;
• CDN-кэш;
• кэш SEO-плагина, если он есть.

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

Если нужен более системный подход к чистке дублей и служебных страниц, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином всё равно стоит понимать, какие URL вы закрываете и почему.

Когда лучше не закрывать страницу от индексации

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

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

Если после внедрения всё ещё видите дубли, идите не от настроек, а от списка URL: что именно индексируется, какой у страницы canonical, какой ответ сервера и кто генерирует лишний адрес — тема, плагин или сам WordPress. Это быстрее, чем бесконечно переключать галочки в SEO-плагине.