Как убрать дубли страниц из-за trailing slash в WordPress

Дубли URL с и без слеша в конце — типичная техническая проблема на WordPress-сайте после миграции, смены темы, подключения CDN или ручных правок в .htaccess. Для пользователя это выглядит незаметно, а для поисковика — как две разные страницы с одинаковым содержимым. В итоге распыляются сигналы, появляются лишние URL в индексе и иногда ломается каноникал.

Ниже разберём, как понять, что проблема именно в trailing slash, где она обычно возникает и как исправить её без лишних побочных эффектов.

Когда проблема действительно в слеше, а не в другом дубле

Сначала важно не перепутать trailing slash с другими видами дублей: параметрами ?utm=, пагинацией, архивами автора или страницами поиска. Если в индексе есть пары вида /page и /page/, а содержимое одинаковое, это почти всегда вопрос настройки формирования URL и редиректов.

Признаки в логах и в поиске

• одна и та же страница открывается по двум адресам: со слешем и без него;
• в Search Console или другом краулере видны дубли с одинаковым title и description;
• внутренние ссылки ведут вразнобой: часть шаблонов отдаёт URL без слеша, часть — со слешем;
• после редиректа цепочка выглядит как /page → /page/ → ещё один редирект на HTTPS или www;
• канонический URL в HTML не совпадает с фактическим адресом страницы.

Диагностика: где искать источник дублей

В WordPress trailing slash обычно задаётся на уровне постоянных ссылок, но на практике мешают ещё и серверные правила, плагины кеша, ручные редиректы и тема, которая генерирует ссылки через home_url() без нормализации.

Проверьте три слоя: настройки WordPress, сервер и шаблоны.

1. Настройки постоянных ссылок

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

2. Ответ сервера

Проверьте, какой URL считается основным:

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

Если сервер отдаёт 301 на /page/, это нормально, но цепочка должна быть короткой. Если сначала идёт редирект на www, потом на HTTPS, потом на слеш — это уже лишняя нагрузка и лишний шум для краулера.

3. Генерация ссылок в теме и плагинах

Если в шаблоне вручную собирают URL через конкатенацию строк, легко получить смесь вариантов. Например, часть кода использует home_url('/about'), а часть — get_permalink(). Для записей и страниц лучше опираться на штатные функции WordPress, а не собирать адреса вручную.

Пошаговое решение без лишних редирект-цепочек

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

Шаг 1. Зафиксируйте формат в WordPress

Если сайт работает на стандартных постоянных ссылках, сохраните настройки ещё раз. Это обновит rewrite rules. После этого проверьте, что get_permalink() и the_permalink() возвращают единый вариант URL.

Шаг 2. Нормализуйте внутренние ссылки

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

function wpbest_normalize_trailing_slash( $url ) {
    $url = trim( $url );

    if ( empty( $url ) ) {
        return $url;
    }

    $parts = wp_parse_url( $url );
    if ( empty( $parts['path'] ) ) {
        return untrailingslashit( $url );
    }

    $path = untrailingslashit( $parts['path'] ) . '/';

    $scheme   = isset( $parts['scheme'] ) ? $parts['scheme'] . '://' : '';
    $host     = isset( $parts['host'] ) ? $parts['host'] : '';
    $port     = isset( $parts['port'] ) ? ':' . $parts['port'] : '';
    $query    = isset( $parts['query'] ) ? '?' . $parts['query'] : '';
    $fragment = isset( $parts['fragment'] ) ? '#' . $parts['fragment'] : '';

    return $scheme . $host . $port . $path . $query . $fragment;
}

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

Шаг 3. Добавьте единый редирект на канонический вариант

Если на сайте уже накопились дубли, нужен 301-редирект с неправильного варианта на правильный. Делать это лучше на уровне WordPress, только если серверные правила не справляются или если нужно точечно обработать отдельные типы URL.

add_action( 'template_redirect', function () {
    if ( is_admin() || wp_doing_ajax() || is_feed() ) {
        return;
    }

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';
    if ( $request_uri === '' ) {
        return;
    }

    // Не трогаем корень сайта.
    if ( $request_uri === '/' ) {
        return;
    }

    $parsed = wp_parse_url( home_url( add_query_arg( array(), $request_uri ) ) );
    if ( empty( $parsed['path'] ) ) {
        return;
    }

    $path = $parsed['path'];
    $canonical_path = trailingslashit( $path );

    if ( $path !== $canonical_path ) {
        $target = home_url( $canonical_path );

        if ( ! empty( $parsed['query'] ) ) {
            $target .= '?' . $parsed['query'];
        }

        wp_safe_redirect( $target, 301 );
        exit;
    }
} );

Этот пример упрощённый и подходит не для всех схем. Если у вас есть специальные правила для файлов, API-эндпоинтов или нестандартных маршрутов, их нужно исключить отдельно.

Шаг 4. Проверьте canonical и sitemap

После редиректов важно убедиться, что в <link rel="canonical"> и в sitemap попадает только один вариант URL. Иначе поисковик может продолжить видеть дубли даже при корректном 301.

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

Сравнение подходов: плагин, код или сервер

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

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

• проверьте curl -I для обоих вариантов URL;
• убедитесь, что неправильный адрес отдаёт 301, а не 200;
• сравните canonical в исходном коде страницы;
• посмотрите, что в sitemap остался только один вариант;
• пройдите сайт краулером и найдите пары URL с одинаковым контентом.

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

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

Редирект сделан, но дубли остались

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

Появилась цепочка из нескольких 301

Обычно это следствие того, что отдельно настроены HTTPS, www и trailing slash. Решение — собрать все правила в один канонический сценарий и убрать промежуточные редиректы.

Сломались файлы или API-маршруты

Если вы без фильтрации применили редирект ко всему подряд, можно задеть /wp-json/, статические файлы или нестандартные endpoints. Такие маршруты нужно явно исключать из логики редиректа.

Каноникал не совпадает с редиректом

Это бывает, когда SEO-плагин или тема генерирует canonical отдельно. Проверьте шаблон <head> и настройки SEO-модуля. Один URL должен быть главным и для редиректа, и для canonical.

Что стоит учесть для безопасности и производительности

Редиректы лучше держать простыми и предсказуемыми. Сложные регулярки в .htaccess или на уровне PHP могут добавить лишнюю нагрузку и усложнить отладку. Если сайт большой, сначала тестируйте правила на staging-копии.

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

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

Для сайтов, где много технических дублей и нужна системная чистка SEO-ошибок, иногда удобнее подключить инструмент вроде Clearfy Pro, но только как часть общей настройки, а не вместо понимания причины дублей.

Главная проверка простая: один URL должен открываться напрямую, второй — стабильно вести на него по 301, а в HTML и sitemap не должно оставаться противоречий. Если это выполнено, проблема trailing slash закрыта не косметически, а технически.