Транслитерация для SEO: как создавать понятные ЧПУ и не плодить дубли URL

Практическое руководство по созданию стабильных SEO-адресов: правила транслитерации, дефисы, регистр, уникальность slug и 301-редиректы при изменениях.

Транслитерация в SEO нужна не для того, чтобы «понравиться поисковику» заменой кириллицы на латиницу. Её практическая задача — превратить название страницы в короткий, стабильный и понятный адрес: например, фразу «Скрытые расходы контрактного производства» в `skrytye-raskhody-kontraktnogo-proizvodstva`.

Я использую латинские slug прежде всего ради единообразия. Такие адреса удобно передавать в письме, видеть в отчётах, обрабатывать в интеграциях и переносить между системами. При этом кириллица в URL технически допустима. Ошибка начинается не с выбранного алфавита, а с непоследовательности: сегодня страница опубликована с одним адресом, завтра CMS сгенерировала другой, а старый URL исчез без редиректа.

В этой статье разберу, как создавать ЧПУ для категорий, товаров, услуг и статей, что делать со сложными буквами и когда изменение slug уже становится SEO-миграцией.

Транслитерация, перевод и ЧПУ — не одно и то же

Транслитерация передаёт символы одного алфавита символами другого. Она не переводит смысл. Слово «доставка» превращается в `dostavka`, а не в `delivery`.

ЧПУ — человекопонятный URL. В нём желательно увидеть тему страницы без расшифровки внутренних идентификаторов:

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

Обязательна ли латиница в URL в 2026 году

Нет. Поисковые системы умеют работать с национальными символами. Google прямо рекомендует использовать понятные слова на языке аудитории, в том числе транслитерированные, и при необходимости корректно кодировать не-ASCII-символы.

Поэтому вопрос не в том, «умеет ли Google индексировать кириллицу», а в том, какую политику сайт способен соблюдать годами.

Латиница обычно удобнее, когда:

• URL регулярно передают вручную;
• сайт связан с CRM, ERP, фидами и внешними API;
• адреса анализируют в таблицах и журналах;
• CMS и плагины по-разному обрабатывают кириллицу;
• проект может переезжать между платформами;
• для разработки принят единый ASCII-формат.

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

Как работает режим «Для SEO»

В инструменте Nasloy есть четыре режима: для SEO, для чтения, по ГОСТ и для ФИО. Для URL используется первый.

Он выполняет понятную последовательность:

1. Переводит кириллицу в латиницу.

2. Приводит результат к нижнему регистру.

3. Заменяет пробелы и группы служебных символов дефисами.

4. Удаляет дефисы в начале и конце.

5. Объединяет повторяющиеся дефисы.

Исходная фраза:

`SEO-продвижение промышленной компании в Москве`

Результат:

`seo-prodvizhenie-promyshlennoj-kompanii-v-moskve`

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

Открыть инструмент «Транслитерация онлайн»

Чем отличаются остальные режимы

Один алгоритм нельзя безопасно использовать для всех задач.

Для чтения

Режим сохраняет регистр и пунктуацию, поэтому подходит для обычной передачи русского текста латиницей. Он не формирует готовый URL и не удаляет все разделители.

По ГОСТ

Это практическая схема на основе ГОСТ 7.79-2000, система Б. Здесь отдельные буквы могут записываться иначе, чем в SEO-slug. Такой результат нужен для задач, где важнее заданная система соответствий, а не краткость адреса.

Для ФИО

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

Главное правило: SEO-режим используется для адресов, а документальные режимы — только в своём контексте.

Что делать с ё, й, ъ и ь

У транслитерации нет единственного универсального варианта для любой задачи. Разные стандарты по-разному передают одни и те же буквы. В SEO важнее заранее выбрать правило и не менять его между разделами.

В текущем SEO-режиме инструмента используются, в частности, такие соответствия:

Такая схема не обязана совпадать с паспортной или библиотечной. Для slug важны предсказуемость и одинаковое применение.

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

Базовые правила хорошего slug

Я использую следующий набор правил.

Один регистр

URL чувствительны к регистру. `/Catalog/` и `/catalog/` могут восприниматься как разные адреса. Для новых проектов проще использовать только нижний регистр.

Дефисы между словами

Google рекомендует дефисы, а не подчёркивания. Адрес `internet-magazin-kosmetiki` легче разделить на понятия, чем `internet_magazin_kosmetiki` или `internetmagazinkosmetiki`.

Только смысловые слова

Slug должен объяснять страницу, но не пересказывать весь H1. Обычно достаточно сущности и важного уточнения.

Слишком длинно:

`kak-pravilno-vybrat-i-zakazat-razrabotku-novogo-internet-magazina-dlya-biznesa`

Рабочий вариант:

`kak-vybrat-razrabotku-internet-magazina`

Без дат, если материал будет обновляться

Год в адресе оправдан, когда страница относится именно к конкретному периоду. Если руководство будет обновляться, дата быстро сделает URL устаревшим, даже когда заголовок и текст уже актуальны.

Без изменчивых характеристик

Цена, наличие, количество товаров и рекламная формулировка меняются. Их не следует включать в постоянный адрес категории или услуги.

Нужно ли удалять предлоги и стоп-слова

Не существует требования удалять из URL все короткие слова. Предлоги иногда помогают сохранить понятный смысл: `seo-dlya-internet-magazina` читается естественнее, чем `seo-internet-magazin`.

Я убираю слово, если после удаления смысл остаётся однозначным и адрес становится заметно короче. Но не применяю механический список стоп-слов ко всем страницам.

Особенно осторожно нужно работать с отрицанием. Удаление «не» способно перевернуть смысл. Название «почему сайт не индексируется» нельзя бездумно сокращать до `pochemu-sajt-indeksiruetsya`.

URL для категорий, товаров, услуг и статей

Разным типам страниц нужна одна политика, но разный состав slug.

Для товаров я стараюсь сохранять модель или артикул, если это устойчивый идентификатор. Маркетинговое название может измениться, а модель останется. В адрес категории не добавляю все характеристики фильтра: это быстро создаёт тысячи комбинаций.

Транслитерация не решает проблему дублей сама

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

Поэтому после генерации нужна проверка уникальности:

1. Существует ли такой URL сейчас.

2. Был ли он опубликован раньше и затем удалён.

3. Не занят ли адрес другим типом страницы.

4. Не отличается ли он только регистром или завершающим слешем.

5. Не ведёт ли на него действующий редирект.

При совпадении я добавляю устойчивое уточнение: модель, назначение, тип или артикул. Случайный порядковый номер вроде `-2` допустим технически, но редко помогает понять страницу.

Почему slug нельзя менять вслед за каждым заголовком

H1 и title можно уточнять по мере развития страницы. URL должен быть значительно стабильнее.

Допустим, статья называлась «Как создать интернет-магазин», а после обновления стала называться «Как создать интернет-магазин, готовый к SEO». Старый короткий slug может остаться прежним, если тема страницы не изменилась.

Изменение адреса затрагивает:

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

Я меняю URL только при реальной необходимости: неверная структура, грубая ошибка, смена сущности, объединение дублей или полноценная миграция.

Если адрес всё-таки нужно изменить

Простой выпуск новой страницы недостаточен. Нужен управляемый перенос.

Последовательность:

1. Зафиксировать старый и новый URL в карте переноса.

2. Настроить постоянный 301-редирект напрямую на новый адрес.

3. Изменить внутренние ссылки, чтобы они не проходили через редирект.

4. Обновить canonical на новой странице.

5. Заменить адрес в sitemap.xml.

6. Проверить изображения, hreflang и структурированные данные, если они содержат URL.

7. Не удалять редирект после первой переиндексации.

8. Контролировать 404, цепочки и трафик старого адреса.

Не стоит направлять все удалённые страницы на главную. Редирект должен вести на максимально соответствующий материал. Если подходящей замены нет, честный 404 или 410 иногда корректнее нерелевантного перенаправления.

Редизайн интернет-магазина без потери SEO и поискового трафика

Что делать с параметрами, фильтрами и метками

Транслитератор создаёт путь страницы, но не управляет URL-параметрами. UTM-метки, сортировки, идентификаторы сессий и комбинации фильтров требуют отдельной логики.

Плохая практика — прогонять целую строку с вопросительным знаком через SEO-режим и получать новый «красивый» адрес. Сначала проектируется структура:

• постоянный путь;
• допустимые параметры;
• канонический адрес;
• правила индексации;
• внутренние ссылки.

Только затем формируется slug для смысловой части пути.

Пакетная подготовка адресов

В инструмент можно вставить список названий, разместив каждое на новой строке. Это удобно для первичного каталога или контент-плана. Но итоговый список всё равно требует контроля.

Я добавляю к выгрузке колонки:

Так транслитерация становится частью карты URL, а не отдельной операцией копирования.

Типовые ошибки

1. Использовать разные схемы для одинаковых букв в соседних разделах.

2. Смешивать латиницу, кириллицу и английский перевод без правила.

3. Оставлять пробелы, подчёркивания и повторяющиеся дефисы.

4. Создавать slug длиной с полный заголовок.

5. Добавлять дату в адрес регулярно обновляемой статьи.

6. Менять URL после каждой правки H1.

7. Публиковать дубликат с новым адресом без 301-редиректа.

8. Считать порядковый номер решением любого совпадения.

9. Транслитерировать параметры и служебную часть URL.

10. Использовать режим для ФИО как официальную проверку документа.

Мой рабочий процесс

Для новых страниц я действую так:

1. Определяю тип страницы и её место в структуре.

2. Формулирую короткое устойчивое название сущности.

3. Получаю slug в SEO-режиме.

4. Убираю только действительно лишние слова.

5. Проверяю смысл и возможную двусмысленность.

6. Проверяю уникальность среди действующих и старых URL.

7. Собираю полный адрес с едиными правилами регистра и слеша.

8. При изменении существующей страницы планирую редирект до публикации.

9. После выпуска проверяю HTTP-код, canonical, внутреннюю ссылку и sitemap.

Этот процесс занимает немного времени, но защищает сайт от накопления хаотичных адресов.

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

• Slug описывает реальную тему страницы.
• Использован нижний регистр.
• Слова разделены дефисами.
• Нет повторяющихся или крайних дефисов.
• Нет случайных служебных символов.
• Адрес не зависит от временной цены или количества.
• Проверена уникальность.
• Полный URL соответствует структуре раздела.
• Для старого адреса подготовлен 301-редирект.
• Обновлены canonical, sitemap и внутренние ссылки.

Частые вопросы

Кириллица в URL вредит SEO?

Сама по себе — нет. Важнее доступность, корректное кодирование, понятная структура и отсутствие дублей. Латиницу часто выбирают из-за удобства работы и совместимости систем.

Нужно ли включать ключевой запрос целиком?

Нет. Адрес должен кратко описывать страницу. Длинный перечень слов не делает её релевантнее автоматически.

Можно ли изменить старые кириллические URL на латиницу?

Технически можно, но это миграция. Нужно оценить пользу, подготовить карту соответствий и поставить прямые 301-редиректы. Без веской причины стабильные адреса лучше сохранить.

Дефис или нижнее подчёркивание?

Для разделения слов рекомендован дефис. Это также соответствует режиму «Для SEO» в инструменте.

Что делать, если два названия дают одинаковый slug?

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

Авторитетный источник

Google Search Central: рекомендации по структуре URL

Вывод

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

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

Создать SEO-slug в инструменте Nasloy