Смена slug в WordPress почти всегда оставляет следы: старая ссылка продолжает жить в поиске, в кэше браузера, в внутренних ссылках и иногда в sitemap. Если просто поменять адрес страницы и ничего не сделать, вы получаете дубль, 404 или цепочку редиректов. На небольшом сайте это быстро превращается в мусор в индексации и лишнюю нагрузку на сервер.
Ниже разберём рабочую схему: как найти старые версии URL, как правильно закрыть их через 301-редирект и canonical, что проверить после внедрения и где чаще всего ломается логика.
Когда проблема уже есть: как её диагностировать
Сначала нужно понять, что именно осталось от старого адреса. В WordPress после изменения slug старая ссылка не исчезает сама по себе из всех мест. Она может быть:
- в результатах поиска;
- во внутренних ссылках старых записей и страниц;
- в XML-sitemap, если кэш карты сайта обновился не сразу;
- в истории браузера и внешних ссылках;
- в индексируемой копии страницы, если поисковик ещё не переобходил URL.
Проверка начинается с простого: откройте старый адрес и посмотрите, что он отдаёт. Нормальный вариант — 301 Moved Permanently на новый URL. Плохие варианты — 200 OK со старым контентом, 302 без причины или 404 без редиректа, если страница уже имеет новый адрес.
Что смотреть в первую очередь
- HTTP-статус старого URL через
curl -Iили DevTools; - наличие редиректа без цепочки из нескольких шагов;
- canonical на новой странице;
- обновились ли внутренние ссылки в меню, блоках и контенте;
- нет ли старого URL в sitemap.
curl -I https://example.com/staryi-slug/Если в ответе нет 301, а страница всё ещё доступна, поисковик может считать старый и новый адрес отдельными страницами. Это и есть типичный дубль после смены slug.
Пошаговое решение: как закрыть старый URL без потери трафика
Правильная схема состоит из трёх слоёв: редирект, canonical и обновление внутренних ссылок. Один только canonical не решает проблему, если старый URL уже разошёлся по сайту. Один редирект тоже не всегда достаточно, если на новой странице остались ссылки на старый адрес.
Шаг 1. Сделайте 301-редирект со старого slug на новый
Если у вас немного страниц, редирект можно добавить вручную. Для Apache это обычно делается в .htaccess, для Nginx — в конфиге сервера. Пример для Apache:
Redirect 301 /staryi-slug/ https://example.com/novyi-slug/Если редиректов много, удобнее хранить их в плагине или в отдельном слое кода. В WordPress можно использовать стандартный хук template_redirect, но только если вы понимаете, что делаете: такой вариант подходит для небольшого числа правил и не должен превращаться в свалку условий.
add_action('template_redirect', function () {
$map = [
'/staryi-slug/' => '/novyi-slug/',
'/staryi-razdel/page/' => '/novyi-razdel/',
];
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
foreach ($map as $from => $to) {
if (strpos($request_uri, $from) === 0) {
wp_redirect(home_url($to), 301);
exit;
}
}
});Если редиректов уже десятки, лучше перенести их в серверный конфиг или использовать специализированный инструмент. На практике это надёжнее и быстрее, чем держать логику в теме.
Шаг 2. Проверьте canonical на новой странице
На новой странице canonical должен указывать на саму себя. Если там остался старый адрес, поисковик может продолжать путаться, особенно если страница доступна по нескольким вариантам URL.
В большинстве SEO-плагинов canonical ставится автоматически, но после ручных правок и миграций это стоит проверить. Откройте исходный код страницы и найдите:
<link rel="canonical" href="https://example.com/novyi-slug/" />Если canonical неправильный, сначала исправьте источник проблемы: шаблон, SEO-плагин или фильтр, который переопределяет тег.
Шаг 3. Обновите внутренние ссылки
Редирект спасает, но внутренние ссылки лучше не оставлять на старый адрес. Иначе каждый переход будет лишним запросом к серверу. Это особенно заметно на больших сайтах и в мобильной сети.
Проверьте:
- меню;
- ссылки в контенте;
- виджеты;
- хлебные крошки;
- блоки в шаблонах;
- ссылки в кастомных полях и ACF.
Если старый slug встречается в контенте массово, можно заменить его через поиск и замену в базе, но только после бэкапа. Для этого подходят инструменты уровня WP-CLI или безопасные плагины для search-replace. Нельзя делать массовую замену «на глаз» через SQL без проверки сериализованных данных.
Сравнение подходов: плагин, код или серверный редирект
Выбор зависит от масштаба задачи. Для одной-двух страниц не нужен тяжёлый стек. Для десятков старых URL лучше не размазывать правила по теме.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Серверный редирект | Много старых URL, нужен контроль | Быстро, надёжно, не зависит от темы | Нужен доступ к конфигу сервера |
| Код в WordPress | Мало правил, нет доступа к серверу | Можно внедрить быстро | Легко сломать логику и забыть про поддержку |
| Плагин редиректов | Редиректы меняются часто | Удобно для редакторов и SEO-специалистов | Дополнительная нагрузка и зависимость от плагина |
Если у вас уже стоит набор для технической чистки сайта, имеет смысл проверить, не закрывает ли он часть задачи сам. Например, Clearfy Pro умеет помогать с технической оптимизацией и удалением дублей, но редиректы всё равно нужно настраивать осознанно, а не «включить всё подряд».
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием страницы в браузере. Браузер может скрыть проблему из-за кэша.
- Проверьте старый URL через
curl -Iи убедитесь, что он отдаёт301. - Откройте новый URL и посмотрите canonical в исходном коде.
- Проверьте, что на новой странице нет внутренних ссылок на старый slug.
- Убедитесь, что старый URL не попал в sitemap.
- Посмотрите в Search Console, не растёт ли число «Страница с перенаправлением» или 404.
Если редирект работает, но поисковик всё ещё показывает старый адрес, это не всегда ошибка. Индексация обновляется не мгновенно. Важно, чтобы старый URL не возвращал контент и не был доступен без редиректа.
Частые ошибки и как их исправить
Ставят 302 вместо 301
Это частая ошибка после ручной настройки или при использовании плагинов, где тип редиректа выбран по умолчанию. Для смены slug нужен именно постоянный редирект 301. Иначе поисковик может дольше держать старый адрес в индексе.
Редирект ведёт на главную
Так делают, когда новый URL забыли или не хотят разбираться с картой соответствий. Для SEO это плохой вариант: пользователь и робот теряют контекст. Если новой страницы нет, лучше оставить 404 или 410, чем отправлять всё на главную.
Есть цепочка из нескольких редиректов
Например, старый URL сначала ведёт на промежуточный адрес, а потом — на новый. Это лишняя задержка и риск ошибок. Сведите всё к одному переходу: старый адрес должен сразу вести на финальный.
Canonical указывает не туда
Иногда редирект уже настроен, но canonical остался старым из-за кэша, шаблона или фильтра SEO-плагина. Тогда поисковик получает противоречивые сигналы. Исправляйте canonical на новой странице и очищайте кэш после правки.
Старые ссылки остаются в контенте
Редирект маскирует проблему, но не убирает её. Если в статьях и блоках остались старые URL, вы создаёте лишние запросы и усложняете поддержку. После миграции всегда делайте поиск по базе и по контенту.
Безопасность и производительность: что не стоит делать
Редиректы — это техническая зона, где легко навредить производительности. Не пишите бесконечные условия в functions.php, если можно решить задачу на уровне сервера. Не ставьте несколько плагинов редиректов одновременно: они могут конфликтовать и создавать петли.
Если редиректов много, держите их в одном месте и документируйте карту соответствий. Это поможет при следующей смене структуры сайта. Перед массовыми правками делайте резервную копию базы и файлов. Для сайтов с активной индексацией это не формальность, а способ не получить пачку 404 из-за одной опечатки.
Мини-чек-лист перед публикацией нового slug
- старый URL отдаёт
301на новый; - новая страница имеет корректный canonical;
- внутренние ссылки обновлены;
- старый адрес не остался в sitemap;
- редирект не создаёт цепочку;
- после очистки кэша старый URL всё ещё ведёт на новый;
- в Search Console нет всплеска 404 по этой странице.
Если задача повторяется регулярно, имеет смысл выстроить процесс: сначала меняете slug, затем сразу добавляете редирект, потом обновляете внутренние ссылки и только после этого отправляете страницу на переобход. Так меньше шансов оставить в индексации старую версию адреса и получить дубль на ровном месте.