Как закрыть старые версии страниц в WordPress от индексации

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

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

Как понять, что в индексе остались старые версии

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

• в Google Search Console есть URL с пометкой «Просканировано, но не проиндексировано» или «Дубликат, выбранная пользователем каноническая страница отличается»;
• в выдаче находятся адреса со старой структурой, например с ?replytocom=, /page/2/, /amp/ или с параметрами фильтров;
• поиск по сайту показывает одну и ту же страницу по нескольким URL;
• в логах или аналитике видны переходы на адреса, которые уже не используются в меню и внутренних ссылках.

Если у вас есть доступ к Search Console, начните с отчёта по индексированию и ручной проверки конкретного URL через инструмент проверки страницы. Это быстрее, чем гадать по симптомам.

Что именно закрывать: noindex, canonical или редирект

Для старых страниц есть три рабочих подхода, и они не взаимозаменяемы. Выбор зависит от того, нужен ли URL пользователю и есть ли у него замена.

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

Пошаговое решение через код и настройки WordPress

1. Закройте технические архивы через robots meta

Если нужно убрать из индекса архивы автора, даты, результаты поиска или страницы вложений, проще всего добавить noindex на уровне шаблона. В WordPress это можно сделать через фильтр wp_robots. Ниже пример для темы или мини-плагина:

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

    if ( is_attachment() ) {
        $robots['noindex'] = true;
        $robots['follow']  = true;
    }

    return $robots;
} );

Этот вариант хорош тем, что он не зависит от SEO-плагина и работает на уровне WordPress. Но если у вас уже есть Yoast SEO, Rank Math или другой SEO-плагин, проверьте, не конфликтует ли он с собственными настройками robots.

2. Настройте canonical для дублей с параметрами

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

<?php
add_filter( 'get_canonical_url', function( $canonical, $post ) {
    if ( is_singular() && $post instanceof WP_Post ) {
        return get_permalink( $post );
    }

    return $canonical;
}, 10, 2 );

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

3. Сделайте 301 редирект для устаревших адресов

Когда URL уже заменён новым, нужен редирект. Самый безопасный способ — через template_redirect или через серверную конфигурацию. Для WordPress-подхода можно использовать wp_redirect(), если редиректов немного и они понятны:

<?php
add_action( 'template_redirect', function() {
    if ( is_page() && get_queried_object_id() === 123 ) {
        wp_redirect( home_url( '/novaya-stranica/' ), 301 );
        exit;
    }
} );

Здесь важно не делать цепочки редиректов. Старый URL должен вести сразу на финальный адрес. Если редиректов много, лучше вынести их в серверный конфиг или использовать проверенный плагин редиректов, а не размножать логику в functions.php.

Диагностика после внедрения

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

• Откройте исходный код страницы и найдите <meta name="robots" или заголовок X-Robots-Tag, если он задаётся сервером.
• Проверьте canonical: он должен вести на основную версию, а не на параметризованный адрес.
• Если настроен редирект, убедитесь, что ответ сразу отдаёт 301, а не 302.
• В Search Console отправьте URL на повторную проверку и посмотрите, как меняется статус через несколько дней.

Для быстрой проверки с сервера удобно использовать curl:

curl -I https://example.com/staryj-url/

В ответе смотрите код статуса и заголовки. Если страница должна быть закрыта от индексации, но при этом открываться пользователю, ищите X-Robots-Tag: noindex или мета-тег robots в HTML. Если нужен редирект, в заголовках должен быть Location.

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

Закрыли страницу в robots.txt вместо noindex

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

Поставили noindex, но оставили внутренние ссылки

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

Сделали редирект на нерелевантную страницу

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

Смешали canonical и noindex без понимания задачи

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

Чек-лист перед публикацией изменений

• Проверен список URL, которые нужно закрыть или перенаправить.
• Для каждой страницы выбран один сценарий: редирект, canonical или noindex.
• Нет цепочек редиректов и циклов.
• Внутренние ссылки обновлены на новые адреса.
• Проверен исходный код и HTTP-заголовки.
• В Search Console отправлены важные URL на повторную проверку.

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

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

Ещё один практичный момент: не ставьте несколько SEO-плагинов одновременно в надежде, что один «добавит canonical», а другой «закроет дубли». В реальности они часто конфликтуют и выводят разные robots-метки. Если нужен более аккуратный контроль над дублями и служебными страницами, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином всё равно стоит проверить итоговый HTML и заголовки вручную.

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