Если вы поменяли заголовок записи, а адрес остался старым или стал выглядеть неправильно, это не всегда ошибка WordPress или Cyr-To-Lat. В большинстве случаев WordPress не переписывает slug автоматически после первого сохранения записи, а плагин транслитерации влияет только на то, как slug создаётся из текста заголовка в момент сохранения. Поэтому сначала нужно понять, что именно произошло: slug не обновился сам, был зафиксирован вручную или его изменил другой плагин, импорт или пользовательский код.
Для сайта с Cyr-To-Lat это особенно важно: плагин отвечает за транслитерацию кириллицы в латиницу, но не управляет всем жизненным циклом URL. Если адрес уже создан, дальнейшее поведение зависит от того, как вы редактируете запись, какие настройки постоянных ссылок используются и не вмешивается ли в процесс другая логика.
Когда slug обновляется сам, а когда нет
В WordPress slug обычно создаётся при первом сохранении записи на основе заголовка. Если заголовок потом меняется, старый slug часто остаётся прежним. Это нормальное поведение: WordPress не хочет менять URL автоматически у уже опубликованной записи, потому что это может сломать внешние ссылки, внутренние переходы и поисковую выдачу.
Автообновление возможно только в отдельных сценариях, и на него нельзя полагаться как на стандартное правило. На практике нужно ориентироваться на такой принцип:
- новая запись без вручную заданного slug получает адрес из текущего заголовка;
- уже сохранённая запись обычно сохраняет старый slug, даже если заголовок изменился;
- если slug был задан вручную, WordPress не будет менять его сам;
- если в процессе участвует импорт, конструктор, SEO-плагин или пользовательский код, адрес может формироваться по своим правилам.
Именно поэтому после смены заголовка нельзя автоматически ожидать, что URL станет «правильным» сам по себе. Если вам нужен новый адрес, его нужно проверить и при необходимости изменить вручную.
Сначала проверьте, что именно не так с адресом
Под «неправильным slug» обычно скрываются разные ситуации. От этого зависит решение.
- Slug остался старым. Заголовок уже новый, а URL по-прежнему содержит старое слово или старую транслитерацию.
- Slug сформировался криво. В адресе появились лишние дефисы, обрезанные слова, латиница не соответствует ожидаемой транслитерации или часть символов пропала.
- Slug не меняется после повторного сохранения. Вы редактируете заголовок, но адрес остаётся прежним даже после обновления записи.
- Slug меняется не так, как ожидается. После правки заголовка WordPress или плагин подставляет другой вариант, чем вы видите в редакторе.
Если проблема только в том, что URL не совпал с новым заголовком, это обычно решается вручную. Если же slug формируется некорректно уже при создании новой записи, сначала нужно искать причину в транслитерации, настройках постоянных ссылок или конфликте с другим расширением.
Как исправить slug вручную в редакторе WordPress
Самый безопасный способ для одной записи — отредактировать slug прямо в админке. Это подходит, когда вы уже понимаете, каким должен быть новый адрес и готовы при необходимости настроить редирект со старого URL.
В классическом редакторе и в редакторе блоков WordPress логика одна и та же: откройте запись, найдите поле постоянной ссылки или ярлык записи и измените slug на нужный вариант. После этого сохраните запись и проверьте итоговый URL на фронтенде.
Если редактор показывает только часть адреса, ориентируйтесь именно на slug, а не на полный URL. Для записи важна последняя часть после домена и структуры постоянных ссылок. Например, если заголовок изменился с «Старая новость» на «Обновлённая новость», а slug остался staraya-novost, вы можете заменить его на obnovlennaya-novost.
После сохранения обязательно откройте запись в новой вкладке и проверьте, что адрес действительно изменился. Иногда редактор показывает новый slug, но фактический URL не обновляется из-за кэша, особенностей темы или вмешательства другого плагина.
Когда менять slug вручную опасно
Если запись уже опубликована и на неё есть трафик, смена slug — это не просто косметическая правка. Старый адрес перестанет быть основным, а без перенаправления посетители и поисковые роботы могут попасть на 404.
Перед изменением URL проверьте три вещи:
- есть ли на старый адрес внешние ссылки;
- используется ли этот URL во внутренних ссылках сайта;
- индексировалась ли страница поисковыми системами.
Если ответ хотя бы на один из этих пунктов положительный, после смены slug нужен 301-редирект со старого адреса на новый. Без него вы рискуете потерять часть переходов и получить цепочку проблем с индексацией.
Для единичной записи редирект можно настроить в плагине перенаправлений или на уровне сервера, если у вас есть такая возможность. Для массовой правки большого числа URL лучше сначала сделать резервную копию и проверить сценарий на копии сайта.
Почему Cyr-To-Lat может не дать ожидаемый результат
Cyr-To-Lat отвечает за транслитерацию кириллицы в латиницу, но не за все случаи изменения slug. Если адрес сформировался не так, как вы ожидали, причины обычно лежат в одном из следующих мест:
- slug был создан до установки или активации плагина;
- запись редактировали после того, как slug уже был зафиксирован вручную;
- другой плагин меняет ярлык записи или перехватывает сохранение;
- тип контента использует собственную логику формирования URL;
- запись была импортирована, и slug пришёл из исходных данных;
- в теме или плагине есть пользовательский код, который переписывает адреса.
Отдельно стоит учитывать, что изменение правил транслитерации в Cyr-To-Lat не переписывает автоматически все старые URL на сайте. Это частая ошибка ожиданий. Новые записи будут использовать новые правила при создании slug, но уже существующие адреса останутся прежними, пока вы не измените их вручную или отдельным процессом.
Как понять, что проблема не в самом slug, а в структуре постоянных ссылок
Иногда кажется, что slug «неправильный», хотя на самом деле проблема в структуре постоянных ссылок WordPress. Например, запись открывается по старому адресу, а в редакторе slug выглядит корректно. В этом случае нужно проверить настройки постоянных ссылок и убедиться, что сайт не использует устаревшую структуру или конфликтующий шаблон URL.
Если после изменения slug страница не открывается по новому адресу, а старый продолжает работать, возможны такие причины:
- кэш страницы или кэш объекта ещё отдаёт старую версию;
- сервер или CDN держит старый ответ;
- другой плагин создаёт редирект на старый URL;
- в базе осталась запись с прежним permalink;
- для этого типа контента используется отдельная структура ссылок.
В такой ситуации не стоит сразу менять slug повторно. Сначала проверьте, что именно показывает редактор, что открывается в браузере и нет ли редиректа на уровне плагина или сервера.
Пошаговая диагностика без лишнего риска
Если нужно быстро понять причину, идите от безопасных проверок к изменениям, которые затрагивают URL.
- Откройте запись в админке и посмотрите текущий slug.
- Сравните его с тем, что вы ожидаете после смены заголовка.
- Проверьте, не задан ли slug вручную.
- Очистите кэш сайта, если он используется.
- Проверьте запись в режиме инкогнито или в другом браузере.
- Если slug всё ещё не соответствует заголовку, измените его вручную и сохраните запись.
- После смены адреса проверьте, работает ли старый URL и настроен ли редирект.
Если проблема повторяется на новых записях, а не только на старых, уже есть смысл проверять конфликт с плагинами, типом контента или пользовательским кодом. Для этого полезно воспроизвести ситуацию на тестовой копии сайта, а не на рабочем проекте.
Что делать, если нужен новый slug для уже опубликованной записи
Когда адрес нужно поменять осознанно, а не просто исправить отображение, действуйте в таком порядке: сначала задайте новый slug, затем проверьте доступность страницы, потом настройте перенаправление со старого адреса. Это особенно важно для записей, которые уже попали в индекс или используются в рассылках, соцсетях и внешних ссылках.
Если вы работаете с большим сайтом, не меняйте адреса массово без плана. Сначала составьте список старых и новых URL, проверьте, как сайт реагирует на изменение slug у нескольких тестовых записей, и только потом переходите к более широким правкам. При массовой смене адресов ошибка в одном шаблоне может создать десятки 404 и цепочки редиректов.
Для большинства обычных случаев достаточно простой проверки: заголовок изменён, slug отредактирован вручную, старый адрес перенаправлен на новый, запись открывается без ошибок. Если это так, проблема решена корректно и без лишнего риска для сайта.
Если же slug продолжает формироваться неправильно даже после ручной правки, стоит проверить версию WordPress, версию Cyr-To-Lat, другие плагины, тип записи и способ создания контента. В сложных конфигурациях без этих данных точную причину не определить.