Если вы переименовываете запись или страницу в WordPress, менять только заголовок недостаточно: адрес тоже часто хочется привести в порядок. Проблема в том, что старый URL уже может быть в поиске, закладках и внешних ссылках. Если просто заменить slug без редиректа, часть переходов уйдёт в 404, а поисковые системы какое-то время будут видеть старую и новую версии как разные адреса.
Нормальный сценарий здесь такой: меняете slug, а со старого адреса ставите постоянный редирект 301 на новый. Тогда посетители и роботы попадают на актуальную страницу, а накопленный трафик и ссылочный вес не теряются.
Что именно меняется при смене slug
Slug — это часть URL после домена. Например, в адресе https://site.ru/kak-vybrat-temu/ slug — kak-vybrat-temu. В WordPress он формируется из заголовка, но его можно отредактировать вручную.
Менять slug имеет смысл, если:
- заголовок статьи изменился и старый адрес больше не соответствует содержанию;
- в slug есть ошибка, лишние слова или слишком длинная формулировка;
- нужно унифицировать структуру URL на сайте;
- страницу переименовали, а старый адрес выглядит неаккуратно.
Само по себе изменение slug не ломает запись в админке. Риск появляется на уровне адреса: старый URL перестаёт быть основным, и без редиректа он начинает отдавать 404.
Как изменить slug в редакторе WordPress
В блоковом редакторе Gutenberg slug меняется прямо в настройках записи или страницы. Откройте материал на редактирование и найдите блок с постоянной ссылкой. Обычно он называется Постоянная ссылка или URL.
Дальше порядок простой:
- Откройте запись или страницу в админке.
- Найдите текущий URL и нажмите на редактирование slug.
- Замените его на короткий и понятный вариант.
- Сохраните или обновите материал.
После сохранения WordPress создаст новый адрес. Если материал уже опубликован, старый URL сам по себе не перенаправится на новый, если у вас не настроен механизм редиректов на уровне сайта, темы или плагина.
Если вы работаете в классическом редакторе, логика та же: в блоке постоянной ссылки можно изменить ярлык записи перед сохранением. Важно не путать slug с названием записи: заголовок можно оставить прежним или поменять отдельно.
Что сделать до смены адреса, чтобы не потерять трафик
Перед изменением slug проверьте три вещи. Это занимает несколько минут, но экономит много времени после публикации нового адреса.
- Скопируйте старый URL целиком. Он понадобится для редиректа.
- Убедитесь, что на старый адрес уже есть переходы из поиска или внешних сайтов. Если трафика нет, риск меньше, но редирект всё равно лучше поставить.
- Проверьте, не используется ли этот URL в меню, кнопках, внутренних ссылках и в рассылках. Такие ссылки тоже желательно обновить.
Если страница уже давно в индексе, не удаляйте старый адрес и не рассчитывайте, что поисковик сам быстро поймёт переезд. Для него это новый URL, а старый без редиректа выглядит как исчезнувшая страница.
Как правильно настроить редирект со старого slug на новый
Для постоянного переезда нужен редирект 301. Это стандартный способ сообщить браузеру и поисковым системам, что страница окончательно переехала на новый адрес.
Есть несколько рабочих вариантов, и выбор зависит от того, как у вас устроен сайт.
| Способ | Когда подходит | Что важно |
|---|---|---|
| Плагин редиректов | Если не хочется править серверные файлы вручную | Проще всего для владельца сайта, но следите, чтобы редирект был именно 301 |
| .htaccess | Если сайт на Apache и есть доступ к корню сайта | Нужно аккуратно редактировать файл, ошибка может сломать сайт |
| Конфигурация Nginx | Если сайт работает на Nginx и у вас есть доступ к конфигу | Правка делается на стороне сервера, обычно через хостинг или админа |
Если вы не уверены, какой у вас сервер, проще начать с плагина. Для большинства сайтов это самый безопасный путь.
Редирект через плагин
Плагин удобен тем, что не требует правки конфигурации сервера. Вы просто указываете старый и новый адрес, а WordPress сам отдаёт 301.
Схема работы обычно такая:
- Установите плагин редиректов.
- Создайте новое правило.
- В поле источника укажите старый путь, например
/staryy-slug/. - В поле назначения укажите новый путь, например
/novyy-slug/. - Выберите тип редиректа
301. - Сохраните правило и проверьте переход.
Если на сайте уже есть плагин, который умеет управлять редиректами и SEO-настройками, можно использовать его вместо отдельного решения. Главное — не создавать несколько конфликтующих правил на один и тот же адрес.
Редирект через .htaccess на Apache
Этот вариант подходит только для сайтов на Apache или совместимом окружении, где используется файл .htaccess. Перед изменением сделайте резервную копию файла. Одна лишняя строка может привести к ошибке 500.
Для одного адреса обычно достаточно такой строки:
Redirect 301 /staryy-slug/ https://site.ru/novyy-slug/Если у вас сайт на HTTPS и с www/без www, указывайте итоговый канонический адрес именно в том виде, в каком он должен открываться. После сохранения проверьте, что старый URL отдаёт 301, а новый открывается без лишних переадресаций.
Редирект на Nginx
На Nginx редиректы настраиваются в конфигурации сервера, а не в .htaccess. Если у вас обычный shared-хостинг, доступ к конфигу может быть закрыт, и тогда проще использовать плагин или попросить поддержку хостинга добавить правило.
Типичный вариант для одного адреса выглядит так:
rewrite ^/staryy-slug/?$ https://site.ru/novyy-slug/ permanent;После изменения конфигурации сервер нужно перечитать или перезапустить, но на хостинге это обычно делает администратор. Если у вас нет уверенности, что именно править, не экспериментируйте на боевом сайте.
Как проверить, что всё работает правильно
После смены slug важно проверить не только саму страницу, но и поведение старого адреса.
Проверка должна быть такой:
- новый URL открывается с кодом 200 и показывает нужный контент;
- старый URL отдаёт 301 и сразу ведёт на новый адрес;
- внутренние ссылки на сайте уже указывают на новый slug;
- в sitemap, если он у вас есть, остался только новый URL.
Самый простой способ проверить редирект — открыть старый адрес в браузере в режиме инкогнито. Но лучше ещё посмотреть ответ сервера через инструменты разработчика, онлайн-проверку редиректов или команду curl, если вам удобно работать с консолью.
Например, для быстрой проверки можно использовать:
curl -I https://site.ru/staryy-slug/В ответе должен быть статус 301 и заголовок Location с новым адресом. Если вместо этого вы видите 200, редирект не сработал. Если 404 — старый URL уже не обрабатывается, и трафик с него потеряется.
Что делать с внутренними ссылками и индексом
Редирект решает проблему для внешнего трафика, но внутри сайта старый slug лучше заменить вручную. Это уменьшает число лишних переходов и делает структуру чище.
Проверьте:
- ссылки из других записей и страниц;
- меню и кнопки;
- хлебные крошки, если они формируются вручную;
- ссылки в блоках, виджетах и шаблонах;
- анкорные ссылки из старых материалов, если они ведут на переименованную страницу.
Если у вас есть доступ к поисковой консоли, после переезда можно отправить новый URL на переобход. Это не обязательный шаг, но он помогает поисковым системам быстрее увидеть обновление. Старый адрес при этом должен продолжать отдавать 301, а не исчезать.
Типичные ошибки при смене slug
Чаще всего проблемы возникают не из-за самого WordPress, а из-за спешки.
- Меняют slug и забывают про редирект. В итоге старые переходы упираются в 404.
- Ставят редирект 302 вместо 301. Для постоянного переезда это неверный вариант.
- Создают цепочку редиректов. Например, старый адрес ведёт на промежуточный, а потом на новый. Лучше сразу вести на конечный URL.
- Оставляют старые ссылки внутри сайта. Это лишняя нагрузка и путаница для пользователей.
- Меняют slug слишком часто. Каждый новый адрес усложняет поддержку и может сбивать индексацию.
Если материал уже хорошо ранжируется, не трогайте адрес без причины. Иногда правильнее оставить старый slug, а заголовок и текст обновить отдельно. Но если переименование действительно нужно, делайте это один раз и сразу с редиректом.
Такой порядок действий обычно решает задачу без потери трафика: меняете slug, ставите 301 со старого URL на новый, проверяете ответ сервера и обновляете внутренние ссылки. Для WordPress это стандартная и безопасная схема, если не пропускать редирект и не править серверные настройки вслепую.