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

Автор: Роман Фомин | Опубликовано: 24.08.2026

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

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

Когда проблема действительно в старых URL

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

Проверять нужно не только главные страницы. Часто «мусор» сидит в:

старых версиях записей и страниц после смены slug;
страницах вложений медиафайлов;
URL с параметрами сортировки, фильтрации или UTM;
архивах, которые дублируют основной контент;
страницах, которые уже удалены, но ещё отдаются не тем кодом ответа.

Что смотреть в первую очередь

код ответа старого URL: 200, 301, 404 или 410;
наличие канонического адреса в HTML;
есть ли старая ссылка во внутренней перелинковке;
не генерирует ли тема или плагин повторяющиеся архивы.

Диагностика: как понять, что именно индексируется

Сначала не трогайте robots.txt и мета-теги вслепую. Список проблемных URL лучше собрать из нескольких источников: Search Console, серверные логи, краулер вроде Screaming Frog, а также вручную через site: и проверку конкретных адресов.

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

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

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

И отдельно проверить, не отдаёт ли страница мета-тег robots:

curl -s https://example.com/staryj-url/ | grep -i robots

Если вы видите noindex, но страница всё равно доступна по 200, это не ошибка само по себе. Но если на старый URL ведут внутренние ссылки, лучше не ограничиваться только noindex.

Что делать: рабочая схема без лишней магии

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

Сценарий	Что делать	Компромисс
Есть новый URL	Поставить 301 со старого адреса на новый	Нужно поддерживать карту редиректов
Старый адрес не нужен, но ещё может обходиться	Отдать 410 или 404, убрать внутренние ссылки	Часть внешних ссылок потеряется
Адрес нужен технически, но не должен индексироваться	Добавить `noindex, follow` и закрыть от лишнего обхода	Не решает проблему дублирования, если есть замена

Вариант 1: редирект старого URL на новый

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

Пример для functions.php или мини-плагина, если нужно перенаправить конкретный старый адрес:

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

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    if ($request_uri === '/staryj-url/' || $request_uri === '/staryj-url') {
        wp_redirect(home_url('/novyj-url/'), 301);
        exit;
    }
});

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

Вариант 2: убрать страницу из индекса, но оставить доступной

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

add_filter('wp_robots', function ($robots) {
    if (is_page('staryj-url')) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Важно: is_page('staryj-url') сработает только если это реальная страница WordPress с таким slug. Для старых URL после переезда, которые уже не существуют как объект WP, такой подход не поможет. Тогда нужен редирект на уровне сервера или отдельная логика по запросу.

Вариант 3: отдать 410 Gone для окончательно удалённых адресов

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

add_action('template_redirect', function () {
    if (is_page('udalennaya-stranica')) {
        status_header(410);
        nocache_headers();
        include get_query_template('404');
        exit;
    }
});

Не используйте этот вариант для страниц, у которых есть актуальная замена. В таком случае 301 полезнее и для пользователя, и для поисковика.

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

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

проверьте, не дублируется ли контент в архивах категорий и тегов;
уберите внутренние ссылки на старый адрес из меню, хлебных крошек и блоков «похожие записи»;
для медиафайлов решите, нужны ли отдельные страницы вложений вообще;
если сайт генерирует URL с параметрами, задайте канонический адрес;
не закрывайте в robots.txt то, что уже должно выпасть через 301 или 410.

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

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

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

Откройте старый адрес через curl -I и убедитесь, что он отдаёт 301, 404 или 410 в зависимости от сценария.
Проверьте, что новый адрес открывается без цепочки редиректов.
Посмотрите HTML новой страницы: канонический URL должен указывать на актуальную версию.
Прогоните сайт краулером и найдите старые URL в исходящих внутренних ссылках.
В Search Console отправьте на переобход несколько проблемных адресов и посмотрите, как меняется статус.

Если старый URL всё ещё возвращает 200, значит правило не сработало или его перебивает другой плагин. Если редирект есть, но ведёт через две-три промежуточные точки, это тоже проблема: поисковику и пользователю такой маршрут не нужен.

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

Закрыли URL в robots.txt вместо редиректа

Это частая ошибка после смены структуры ссылок. Если поисковик уже знает старый адрес, запрет в robots.txt не убирает его из индекса сам по себе. Для удаления нужен либо 301 на новый адрес, либо 404/410, если замены нет.

Поставили noindex на страницу, которая должна редиректить

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

Оставили внутренние ссылки на старый адрес

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

Сделали массовый редирект на главную

Это плохая практика для SEO и для пользователей. Если у старой страницы есть тематический аналог, редирект должен вести именно на него. Массовая отправка всех старых URL на главную часто выглядит как мягкая 404 и не решает задачу.

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

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

Если вы добавляете код в тему, помните о двух вещах: после обновления темы правка может потеряться, а неаккуратный код способен сломать фронт для всех запросов. Для таких задач безопаснее вынести логику в мини-плагин или mu-plugin.

<?php
/**
 * Plugin Name: Old URL Redirects
 */

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

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    $map = [
        '/staryj-url/' => '/novyj-url/',
        '/staryj-razdel/' => '/novyj-razdel/',
    ];

    if (isset($map[$request_uri])) {
        wp_redirect(home_url($map[$request_uri]), 301);
        exit;
    }
});

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

Если нужна более широкая чистка дублей, технических архивов и SEO-мусора, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpin.ru&utm_medium=article&utm_campaign=zakryt-ot-indeksacii-starye-versii-stranic-posle-smeny-url-v-wordpress. Но даже с плагином всё равно стоит проверить коды ответа и карту редиректов вручную.

Короткий чек-лист перед публикацией

старый URL либо редиректит на новый, либо отдаёт 404/410;
новый URL открывается без цепочки редиректов;
канонический адрес указывает на актуальную страницу;
внутренние ссылки обновлены;
robots.txt не используется вместо нормального решения;
в Search Console отправлены на проверку несколько проблемных адресов;
краулер не находит старые URL в меню, хлебных крошках и контенте.

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

⭐⭐⭐⭐⭐