Как в CyrtoLat проверить и убрать дубли slug после миграции с кириллицы на латиницу

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

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

Когда проблема действительно в дублировании slug

Если CyrtoLat включён, а после сохранения записи вы видите один из этих симптомов, почти наверняка дело в конфликте slug:

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

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

Диагностика: где искать конфликт

Начинать лучше не с правки настроек, а с проверки фактических URL. В таких задачах полезно смотреть сразу на три слоя: исходный заголовок, сохранённый post_name и итоговый URL на фронтенде.

Проверка в админке

Откройте проблемную запись и сравните:

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

Если slug уже изменился после сохранения, но вы не понимаете почему, это повод проверить, не сработала ли автоподмена на уровне плагина повторно.

Проверка через базу данных

Если доступ к базе есть, быстро найдите дубли по post_name. Для MySQL это можно сделать так:

SELECT post_name, COUNT(*) AS cnt
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status NOT IN ('auto-draft', 'trash')
GROUP BY post_name
HAVING cnt > 1
ORDER BY cnt DESC, post_name;

Запрос покажет только повторяющиеся slug. Если дубли есть, дальше уже смотрите, какие записи за ними стоят:

SELECT ID, post_title, post_name, post_type, post_status
FROM wp_posts
WHERE post_name = 'primer-sluga'
ORDER BY ID DESC;

Это помогает понять, конфликтует ли новая запись со старой или проблема появилась после импорта нескольких материалов с одинаковой структурой.

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

Здесь важен порядок. Если просто переименовать slug вручную, можно потерять трафик и получить цепочку редиректов. Безопаснее идти так:

1. зафиксировать список конфликтующих записей;
2. определить, какой URL должен остаться основным;
3. переименовать только конфликтующие записи, а не все подряд;
4. проверить редиректы и канонические адреса;
5. обновить внутренние ссылки, если они указывают на старый slug.

1. Сначала снимите резервную копию

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

2. Разведите одинаковые slug вручную

Если конфликтов немного, проще всего изменить slug у второстепенных записей. В WordPress это можно сделать через редактор записи, но при большом количестве материалов удобнее использовать код или WP-CLI.

Пример безопасной правки через PHP — только для разовой административной задачи, не для постоянной логики:

add_action('admin_init', function () {
    if (!current_user_can('manage_options')) {
        return;
    }

    $post_id = 123;
    $new_slug = 'primer-stati-2';

    wp_update_post([
        'ID'        => $post_id,
        'post_name' => $new_slug,
    ]);
});

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

3. Если конфликтов много, проверьте логику автоподмены

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

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

Сравнение подходов: плагин, ручная правка, код

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

После правки не ограничивайтесь открытием одной страницы в браузере. Проверьте минимум четыре вещи:

• в базе больше нет одинаковых post_name для нужных типов записей;
• каждый проблемный URL открывается без ошибки 404;
• старые адреса ведут либо на нужную страницу, либо на понятный 301-редирект;
• внутренние ссылки в контенте не остались на старых slug.

Быстрая проверка редиректа через curl выглядит так:

curl -I https://example.com/staryi-slug/

В ответе смотрите статус. Если это 301, проверьте заголовок Location и убедитесь, что он ведёт на правильную страницу, а не на случайный дубль.

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

Оставили одинаковые slug у разных типов записей

Иногда кажется, что конфликтов нет, потому что записи относятся к разным типам. Но если в теме или плагинах есть нестандартные правила маршрутизации, одинаковые slug всё равно могут создавать путаницу. Проверьте не только post, но и страницы, вложения и кастомные типы записей.

Переименовали только одну запись и забыли про старый редирект

Если старый URL уже индексировался, после смены slug нужен понятный маршрут. Иначе поисковик и пользователи будут попадать в тупик. Проверьте, не создаёт ли CyrtoLat или другой плагин цепочку редиректов.

Массово изменили slug без проверки внутренних ссылок

Это частая ошибка после импорта. Материал открывается, но из других статей на него всё ещё ведут старые ссылки. В результате часть переходов уходит в 404, хотя сама страница существует. После массовой правки нужно пройтись по внутренним ссылкам или хотя бы по самым трафиковым материалам.

Проверяли только фронтенд, а не базу

Визуально всё может быть нормально, но в базе уже лежат дубли. Потом при следующем сохранении WordPress снова добавит суффикс, и проблема вернётся. Поэтому проверка через SQL или хотя бы через поиск по post_name — не лишняя, а обязательная.

Практические советы по безопасности и производительности

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

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

Если вам нужно не только убрать дубли, но и дальше поддерживать чистую структуру URL, имеет смысл сочетать CyrtoLat с аккуратной политикой редиректов и ручной проверкой новых материалов после импорта. Для задач по чистке дублей, индексации и технической оптимизации иногда удобно дополнительно использовать Clearfy Pro, но только если он реально закрывает вашу конкретную проблему, а не дублирует уже настроенную логику.

Короткий чек-лист перед публикацией

• Проверены все конфликтующие post_name.
• Определён основной URL для каждой группы дублей.
• Старые адреса ведут на нужные страницы через 301, а не в 404.
• Внутренние ссылки обновлены.
• Кэш очищен, а на staging всё открывается так же, как на проде.

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