Как в CyrtoLat отключить автоподмену в slug для отдельных слов и сохранить нужные URL

Сценарий типичный: сайт уже живёт на латинских slug, но в отдельных названиях есть слова, которые CyrtoLat подменяет не так, как нужно. В результате в URL появляются нежелательные транслитерации, меняются привычные адреса или приходится вручную править каждый новый slug после сохранения записи.

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

Когда нужна точечная настройка, а не полное отключение

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

Точечное исключение полезно, если:

• в slug есть брендовые или технические слова, которые нельзя транслитерировать стандартно;
• часть URL уже проиндексирована и менять её рискованно;
• нужно сохранить единый формат для раздела, но убрать автоподмену только для отдельных терминов;
• редакторы часто создают записи через админку, и ручная правка slug занимает слишком много времени.

Диагностика проблемы: что именно ломает CyrtoLat

Перед настройкой важно понять, где возникает нежелательная подмена. Обычно проблема видна в одном из трёх мест:

1. в редакторе записи после сохранения slug меняется автоматически;
2. в уже опубликованной записи новый slug создаётся при редактировании заголовка;
3. в массовом импорте часть слов транслитерируется не так, как ожидает редакция.

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

Что проверить до изменений

• какие именно слова подменяются неправильно;
• затрагивает ли это только новые записи или уже существующие;
• есть ли на сайте редиректы со старых URL;
• используются ли дополнительные плагины для SEO или редиректов, которые могут вмешиваться в slug.

Как отключить автоподмену для отдельных слов

В CyrtoLat такой сценарий обычно решается через настройки исключений или через фильтр, если требуется более точная логика. На практике удобнее сначала попробовать штатный механизм плагина, а код использовать только там, где нужно поведение для конкретного проекта.

Если в интерфейсе плагина есть список исключаемых слов, добавляйте туда только те токены, которые реально должны оставаться без автоподмены. Не стоит заносить целые фразы, если достаточно одного устойчивого слова: так меньше риск случайно сломать другие slug.

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

add_filter('sanitize_title', function ($title, $raw_title, $context) {
    if ($context !== 'save') {
        return $title;
    }

    // Пример: сохраняем бренд как есть в латинском виде.
    $replacements = array(
        'cyrtolat' => 'cyrtolat',
        'seo'       => 'seo',
    );

    foreach ($replacements as $from => $to) {
        if (strpos($title, $from) !== false) {
            $title = str_replace($from, $to, $title);
        }
    }

    return $title;
}, 10, 3);

Этот пример не подменяет работу CyrtoLat целиком, а лишь показывает принцип: если стандартная обработка даёт нежелательный результат, можно точечно поправить итоговый slug. В реальном проекте список исключений лучше держать минимальным и документировать его для редакторов.

Если нужно исключить только один раздел

Когда проблема касается не всех записей, а только одного типа контента, не размазывайте правила по всему сайту. Лучше ограничить логику конкретным post type или таксономией. Так вы не создадите побочный эффект для других разделов.

Например, если в новостях slug должен транслитерироваться стандартно, а в справочнике — сохранять часть терминов без изменений, настройка должна быть разной для этих сущностей. Это удобнее поддерживать и проще проверять после обновлений.

Пошаговое решение без поломки уже опубликованных URL

Менять правила транслитерации на живом сайте нужно аккуратно. Если slug уже в индексе, любое изменение может затронуть внутренние ссылки, sitemap и внешние переходы.

1. Соберите список слов, которые нужно исключить из автоподмены.
2. Проверьте, где эти слова встречаются: в новых записях, старых URL или в обоих случаях.
3. Сначала внесите настройку для одного тестового материала.
4. Сохраните запись и сравните slug до и после.
5. Если всё корректно, применяйте правило к остальным материалам.
6. После изменения проверьте редиректы и карту сайта.

Если у вас есть доступ к тестовой среде, сначала повторите настройку там. Это особенно важно, когда на сайте уже есть SEO-плагины, кэширование и внешние интеграции, которые могут скрыть реальный результат.

Пример проверки через WP-CLI

Если нужно быстро убедиться, что slug сохранился так, как ожидается, можно посмотреть запись через WP-CLI. Это не заменяет ручную проверку в админке, но помогает отловить расхождения после массового обновления.

wp post list --post_type=post --fields=ID पोस्ट_title पोस्ट_name

Если в вашей среде WP-CLI настроен корректно, в колонке post_name вы увидите фактический slug. Сравните его с ожидаемым значением после применения исключения.

Как проверить, что решение сработало

Проверка должна быть не формальной, а прикладной. Достаточно пройтись по нескольким точкам:

• новая запись сохраняется с нужным slug;
• редактирование заголовка не ломает уже заданный URL;
• внутренние ссылки ведут на актуальный адрес;
• старый URL, если он менялся, отдаёт корректный редирект;
• в sitemap нет неожиданно изменённых адресов.

Откройте запись в браузере в режиме инкогнито и проверьте, что URL совпадает с ожидаемым. Затем посмотрите исходный код страницы или карту сайта, если она генерируется автоматически. Это помогает понять, не остался ли старый адрес где-то в кеше или в SEO-плагине.

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

Исключение слишком широкое

Самая частая ошибка — добавить в исключения слишком общий фрагмент. В итоге плагин перестаёт корректно обрабатывать не только нужное слово, но и другие slug, где этот фрагмент встречается как часть более длинного термина. Исправление простое: сузить правило до конкретного токена или конкретного типа записи.

Меняют slug без редиректа

Если адрес уже был опубликован и проиндексирован, новый slug без 301-редиректа создаёт битые ссылки и теряет накопленный трафик. После изменения URL всегда проверьте, что старый адрес перенаправляется на новый, а не отдаёт 404.

Путают транслитерацию и ручной slug

Иногда редактор вручную правит slug, а потом снова сохраняет запись, и автоподмена возвращает нежелательный вариант. В таком случае нужно либо закрепить ручной slug, либо исключить конкретное слово из обработки.

Не учитывают кэш

После изменения настроек старый slug может ещё какое-то время показываться из-за страницы в кэше, объектного кэша или CDN. Перед проверкой очистите кэш на всех уровнях, иначе можно сделать ложный вывод, что настройка не сработала.

Практика безопасности и поддержки

Если вы вносите код, лучше не править functions.php активной темы напрямую. Для точечных правил безопаснее использовать мини-плагин или mu-plugin: так настройка не пропадёт после обновления темы.

Ещё один полезный приём — хранить список исключений в одном месте и не разносить его по нескольким сниппетам. Чем меньше рассеянной логики, тем проще отлаживать конфликт с SEO-плагинами, импортом и редактором блоков.

Если вам нужен именно набор технических SEO-инструментов вокруг чистки дублей, редиректов и служебной оптимизации, в экосистеме WPShop можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но для задачи с slug он не заменяет CyrtoLat, а лишь может быть полезен рядом с ним в части общей технической гигиены сайта.

Короткий чек-лист перед выкладкой на прод

• исключения добавлены только для нужных слов;
• тестовая запись сохраняет правильный slug;
• старые URL не потеряли редиректы;
• кэш очищен на сайте и на CDN;
• в sitemap и внутренних ссылках нет расхождений;
• настройка не затрагивает другие типы записей.

Если после внедрения slug всё ещё меняется не так, как нужно, проверьте, не перехватывает ли сохранение другой плагин или кастомный код. В таких случаях проблема часто не в CyrtoLat, а в том, что итоговый sanitize_title фильтруется ещё раз на стороне темы или SEO-модуля.