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

Автор: Ярослав Захаров | Опубликовано: 18.09.2026

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

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

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

Сначала стоит убедиться, что речь не о другой причине. После смены слага старый URL может:

отдавать 404 и всё равно висеть в индексе какое-то время;
редиректить на главную или на похожую страницу — это хуже, чем кажется;
открывать ту же страницу по двум адресам, если старый слаг остался в кеше, в sitemap или в внутренних ссылках;
появляться в поиске как отдельный результат с устаревшим заголовком и сниппетом.

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

Что делать после смены слага: рабочая схема

1. Настроить постоянный редирект 301 со старого URL

Самый надёжный вариант — отдать старому адресу постоянный редирект на новый. Для одиночной страницы это можно сделать в .htaccess на Apache или через конфигурацию nginx. Если у вас нет доступа к серверу, редирект можно добавить кодом в тему или мини-плагин, но лучше не размазывать такую логику по шаблонам.

Для Apache пример выглядит так:

Redirect 301 /staryj-slug/ https://example.com/novyj-slug/

Для nginx:

rewrite ^/staryj-slug/?$ https://example.com/novyj-slug/ permanent;

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

<?php
/**
 * Plugin Name: Old Slug Redirects
 */
add_action('template_redirect', function () {
    $map = [
        '/staryj-slug/' => '/novyj-slug/',
        '/eshche-odin-slug/' => '/drugoj-novyj-slug/',
    ];

    $request_uri = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

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

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

2. Убедиться, что новый адрес самоканоничен

На новой странице должен быть canonical на саму себя. В WordPress это обычно делает SEO-плагин, но если вы переопределяли шаблоны или выводите мета-теги вручную, проверьте, что там не остался старый URL. Иначе поисковик может продолжить считать старый адрес основным.

Если вы пишете свой вывод canonical, логика должна быть простой:

<link rel="canonical" href="<?php echo esc_url( get_permalink() ); ?>" />

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

3. Обновить внутренние ссылки и sitemap

Даже при правильном редиректе старый URL не должен продолжать жить внутри сайта. Проверьте:

меню;
хлебные крошки;
связанные записи;
блоки в контенте;
XML-карту сайта.

Если старый адрес остался в sitemap, поисковик будет снова и снова его обходить. После правки слага пересоберите карту сайта и отправьте её в Search Console заново.

Диагностика: как понять, что именно мешает индексации нового URL

Перед тем как что-то править массово, проверьте цепочку ответа для старого и нового адреса. Это можно сделать через curl:

curl -I https://example.com/staryj-slug/
curl -I https://example.com/novyj-slug/

Ищите три вещи:

301 Moved Permanently со старого на новый;
отсутствие цепочки из нескольких редиректов;
200 OK на новом адресе без лишних промежуточных URL.

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

Сравнение подходов: редирект, canonical и удаление из индекса

Подход	Когда использовать	Плюсы	Минусы
301-редирект	Старый URL больше не нужен	Передаёт сигнал о переезде, убирает дубликат	Нужен доступ к серверу или код
canonical	Когда есть похожие версии, но редирект невозможен	Подсказывает основной адрес	Не удаляет старый URL мгновенно
Удаление в Search Console	Нужно ускорить исчезновение из выдачи	Быстро скрывает URL в поиске	Это не замена редиректу и не решает причину

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

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

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

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

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

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

Редирект ведёт на главную

Это типичная ошибка после массовой чистки URL. Поисковик видит несоответствие: старый материал исчез, но вместо него ему показывают нерелевантную главную. Исправление простое — редирект должен вести на ближайший эквивалентный контент, а не на общую страницу.

Старый URL закрыли в robots.txt

Если адрес уже в индексе, запрет в robots.txt не удалит его быстро. Более того, поисковик может перестать видеть редирект, если вы одновременно закрыли обход и старый URL. Сначала делайте 301, потом при необходимости ограничивайте обход.

На новом адресе остался старый canonical

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

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

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

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

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

Если у вас уже есть плагин для технической чистки сайта, например Clearfy Pro, проверьте, не дублирует ли он часть логики: иногда в админке одновременно включают canonical, редиректы и отключение архивов, а потом получают конфликт настроек. В таких случаях важно оставить один источник истины для каждого типа сигнала.

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

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

Старый URL отдаёт 301 на новый.
Новый URL открывается с 200.
Canonical на новой странице указывает на неё же.
Внутренние ссылки обновлены.
Sitemap пересобран и отправлен заново.
Старый адрес не закрыт так, что поисковик не видит редирект.
Нет цепочек из нескольких переходов.

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