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