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

Автор: Екатерина Волкова | Опубликовано: 17.08.2026

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

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

Какие дубли в WordPress встречаются чаще всего

В реальных проектах проблема редко сводится к одному типу. Обычно это комбинация нескольких источников:

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

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

Диагностика: как понять, где именно появляются дубли

Начинать лучше не с правок, а с проверки фактических URL. Иначе легко закрыть не то и получить просадку по трафику.

Проверьте индексацию в Search Console

В отчёте по страницам ищите:

дубли без выбранной пользователем канонической страницы;
страницы с альтернативным каноническим URL;
URL с параметрами, которые не должны индексироваться;
страницы, которые Google выбрал как дубликаты, хотя вы этого не ожидали.

Если в отчёте много адресов с параметрами или архивами, это уже сигнал, что на сайте нет жёсткой нормализации URL.

Проверьте поведение сервера и редиректов

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

curl -I https://example.com/page-name/

curl -I http://example.com/page-name

Если оба адреса отдают 200 без редиректа на один канонический вариант, это уже проблема. То же касается www/без www.

Посмотрите исходный код страницы

На проблемной странице откройте HTML и найдите тег link rel="canonical". Он должен указывать на единственный предпочтительный адрес. Если canonical отсутствует, ведёт на другой URL или меняется от страницы к странице без причины, поисковик получает противоречивый сигнал.

Что делать: пошаговое решение без лишнего риска

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

1. Зафиксируйте главный вариант URL

Сначала определите, какой адрес считается основным:

HTTPS вместо HTTP;
один вариант хоста — с www или без него;
единый формат слэша;
для записей и страниц — только один путь доступа.

Это базовая нормализация. Если её не сделать, остальные меры будут работать частично.

2. Настройте 301-редиректы на уровне сервера или WordPress

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

<?php
add_action('template_redirect', function () {
    if (is_admin() || wp_doing_ajax() || wp_is_json_request()) {
        return;
    }

    $host = wp_parse_url(home_url(), PHP_URL_HOST);
    $scheme = is_ssl() ? 'https' : 'http';
    $request_uri = $_SERVER['REQUEST_URI'] ?? '/';
    $current_url = $scheme . '://' . ($_SERVER['HTTP_HOST'] ?? $host) . $request_uri;
    $target_url  = home_url(add_query_arg([], $_SERVER['REQUEST_URI'] ?? '/'));

    // Убираем replytocom, если он есть.
    if (isset($_GET['replytocom'])) {
        $target_url = remove_query_arg('replytocom', $target_url);
        wp_safe_redirect($target_url, 301);
        exit;
    }
});

Этот пример не решает все типы дублей, но показывает принцип: лишние параметры нужно убирать, а не оставлять индексируемыми. Для www/HTTPS и слэшей лучше использовать правила веб-сервера, чтобы не нагружать WordPress на каждом запросе.

3. Закройте архивы, которые не несут ценности

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

<?php
add_action('template_redirect', function () {
    if (is_tag() || is_author()) {
        global $wp_query;
        if ($wp_query->is_main_query()) {
            status_header(404);
            nocache_headers();
            include get_query_template('404');
            exit;
        }
    }
});

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

4. Настройте canonical для страниц с параметрами

Если дубли создаются фильтрами, сортировкой или UTM-метками, canonical должен указывать на чистый URL без параметров. В WordPress это можно сделать через фильтр wpseo_canonical в Yoast SEO или аналогичный механизм вашего SEO-плагина. Если плагина нет, можно добавить свой canonical через wp_head, но только если вы понимаете, что делаете и не конфликтуете с темой или SEO-плагином.

Пример для страниц с параметрами:

<?php
add_action('wp_head', function () {
    if (!is_singular()) {
        return;
    }

    $canonical = get_permalink();
    echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
}, 1);

Если у вас уже стоит SEO-плагин, не дублируйте canonical вручную. Два тега canonical на странице — частая ошибка, из-за которой поисковик начинает игнорировать оба варианта.

Когда лучше плагин, а когда код

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

Подход	Когда подходит	Ограничения
SEO-плагин	Нужно быстро закрыть архивы, задать canonical, управлять robots и sitemap	Не всегда удобно для точечной логики редиректов и параметров
Код в теме или mu-plugin	Нужна точная нормализация URL и контроль над отдельными сценариями	Требует тестирования и понимания, где уже есть похожая логика
Серверные правила	Редиректы HTTP/HTTPS, www, слэши, часть параметров	Нужно аккуратно править конфиг и не сломать другие правила

Если задача сводится к SEO-мета и canonical, проще использовать плагин. Если нужно убрать технические дубли на уровне маршрутизации, лучше сервер или код.

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

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

Откройте старый URL и убедитесь, что он отдаёт 301 на нужный адрес.
Проверьте исходный код и найдите один корректный canonical.
Сравните URL в Search Console до и после — лишние варианты должны постепенно исчезать из обхода.
Проверьте sitemap: в него не должны попадать закрытые архивы и служебные страницы.
Протестируйте страницы с параметрами: они не должны создавать отдельные индексируемые копии.

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

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

Два canonical на одной странице

Обычно это происходит, когда canonical добавляет SEO-плагин, а разработчик — ещё и вручную в теме. Решение одно: оставить только один источник.

Редирект через 302 вместо 301

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

Закрыли архивы, но оставили их в sitemap

Такой конфликт сигналов мешает индексации. Если страница не должна индексироваться, уберите её и из карты сайта.

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

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

Удалили параметры, которые использовались для аналитики или фильтров

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

Практические советы по безопасности и производительности

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

Ещё два момента, которые часто упускают:

не правьте functions.php основной темы на боевом сайте — используйте дочернюю тему или mu-plugin;
перед массовыми редиректами сохраните список текущих URL и проверьте, не завязаны ли на них внешние ссылки.

Если на сайте уже много технических дублей, иногда проще сначала убрать самые шумные источники — параметры, архивы, вложения, старые адреса после миграции — а потом добивать оставшееся по отчётам Search Console. Такой порядок безопаснее, чем пытаться «починить SEO» одним большим изменением.

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