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

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

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

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

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

• старый адрес открывается без редиректа и отдаёт 200 OK;
• в индексе одновременно видны старый и новый URL;
• на старой версии остался контент, но canonical указывает не туда;
• внутренние ссылки, хлебные крошки или sitemap всё ещё ведут на старый slug;
• страница была скопирована вручную, и у неё появился дубль с другим адресом.

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

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

Дальше проверьте заголовки ответа. Это можно сделать через DevTools, curl или любой HTTP-проверщик:

curl -I https://example.com/staryy-slug/

Важны три вещи: код ответа, наличие Location при редиректе и отсутствие цепочки из нескольких перенаправлений.

Какой вариант выбрать: редирект, canonical или noindex

Для старого slug почти всегда базовый вариант — 301 редирект на новый URL. Это переносит пользователей и сигнал для поисковика на актуальную страницу. Но бывают случаи, когда редирект не нужен или невозможен: например, если старый адрес уже используется в другом контексте, а контент на нём должен остаться доступным, но не индексироваться.

Если задача именно в переезде страницы на новый slug, canonical и noindex — это не замена редиректу, а вспомогательные меры. Они помогают, когда старый адрес уже успел попасть в индекс или когда на сайте есть технические дубли.

Пошаговое решение: как убрать старый URL из индекса

1. Настройте 301 с старого slug на новый

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

add_action('template_redirect', function () {
    if (is_page('staryy-slug')) {
        wp_redirect(home_url('/novyy-slug/'), 301);
        exit;
    }
});

Этот вариант подходит, если slug менялся вручную и нужно быстро закрыть конкретный адрес. Если переездов много, лучше делать редиректы на уровне Nginx/Apache или через отдельный плагин редиректов, чтобы не раздувать тему.

2. Уберите старый адрес из внутренних ссылок

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

• вставках из старых страниц и записей;
• кастомных полях;
• шаблонах ACF или Elementor;
• ручных HTML-блоках;
• XML-карте сайта, если она собирается не из актуальных данных.

3. Обновите sitemap и отправьте его заново

Если sitemap генерируется SEO-плагином, проверьте, что старый URL там больше не фигурирует. После этого отправьте карту сайта в Search Console. Это не гарантирует мгновенное удаление старого адреса, но ускоряет переобход.

4. Если старый URL не нужен — отдайте 410 или 404

Иногда страницу не надо переадресовывать, потому что новый аналог отсутствует и контент устарел. Тогда лучше вернуть 410 Gone, если удаление окончательное, или 404, если страница просто исчезла. Для WordPress это можно сделать через шаблонную логику:

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

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

Диагностика: почему старый slug всё ещё в выдаче

Если редирект уже есть, а старый адрес всё равно висит в поиске, причина обычно одна из следующих:

• редирект настроен только для части URL, например без учёта слэша в конце;
• есть цепочка http → https → www → новый slug вместо одного перехода;
• страница доступна по нескольким адресам из-за настроек постоянных ссылок;
• canonical у старой версии указывает на саму себя;
• поисковик ещё не переобошёл URL после изменения.

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

Как проверить, что решение сработало

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

1. Откройте старый URL в режиме инкогнито.
2. Проверьте код ответа через curl -I или DevTools.
3. Убедитесь, что редирект ведёт сразу на новый адрес без промежуточных шагов.
4. Посмотрите исходный код новой страницы: canonical должен указывать на неё саму.
5. Проверьте sitemap и внутренние ссылки на наличие старого slug.
6. В Search Console запросите проверку нового URL и переобход старого, если он ещё в индексе.

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

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

Редирект сделан через плагин, но страница всё равно открывается

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

Старый URL закрыли noindex, но он остался в индексе

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

Canonical указывает на новый адрес, но старый URL всё равно ранжируется

Canonical — это подсказка, а не жёсткая команда. Если на старом URL есть полноценный контент, поисковик может не сразу выбрать каноническую версию. В таких случаях редирект надёжнее.

Редиректов стало слишком много и сайт тормозит

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

Практика безопасности и поддержки

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

• держать редиректы в отдельном mu-plugin;
• вести список старых slug и новых адресов в таблице;
• проверять редиректы после миграций и массовых правок;
• не закрывать важные страницы noindex без понимания, как это повлияет на внутреннюю перелинковку.

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

Мини-чек-лист перед публикацией нового slug

• старый URL отдаёт 301 на новый;
• новый URL открывается с кодом 200;
• canonical на новой странице указывает на неё саму;
• внутренние ссылки обновлены;
• sitemap содержит только актуальный адрес;
• нет цепочки редиректов;
• старый URL не возвращает 200 OK.

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