Автор: Vibe Apps Pro Team · Опубліковано: 2026-07-29
Генератор URL Slug: як створити SEO-дружні slug'и
Створюй чисті SEO-дружні URL slug'и онлайн за секунди — з транслітерацією кирилиці та пошуком дублікатів. Спробуй безкоштовний генератор просто зараз.
URL slug — це частина адреси після домену, яка називає одну конкретну сторінку: в editlyapp.com/blog/url-slug-generator-online slug — це url-slug-generator-online. Зроби його неправильно — і отримаєш /post?id=48291 або /2019/03/17/untitled-draft-copy-2; зроби правильно — і сам URL розповідає читачеві (і Google), про що сторінка, ще до кліку.
Встав назву в наш Текст у URL slug — працює на 100% у твоєму браузері, жоден символ не йде на сервер — і він переведе в нижній регістр, розставить дефіси, транслітерує й перевірить на дублікати за тебе. Нижче — точний набір правил, на яких він побудований, і чому кожне з них існує.
Правила SEO-дружнього slug
Не всі пункти важать однаково. Частина — це заявлена поведінка Google, частина — конвенції читабельності, які просто корелюють із кращим CTR. Ось повний список, у порядку реальної ваги:
- Тільки нижній регістр. Змішаний регістр створює ризик дублю URL —
/About-Usі/about-usможуть проіндексуватись як дві різні сторінки, якщо сервер не форсує редирект. - Дефіс, не підкреслення. Google читає дефіс як межу слова, а підкреслення — як символ, що зліплює слова в одне.
word-countіндексується як два слова, які можна знайти окремо;word_countможе прочитатись як єдиний токен. - Три-п'ять слів. Достатньо, щоб описати сторінку, і достатньо коротко, щоб сніпет пошуку не обрізав slug на півслові.
- Цільове ключове слово — один раз. Природно, без накопичення. Google виділяє жирним збіг у рядку URL сніпета — це підштовхує CTR, а не множить позицію в ранжуванні.
- Без дат, якщо контент не прив'язаний до часу свідомо. Датований slug на вічнозеленому гайді просто натякає читачеві, що порада могла застаріти.
- Тільки ASCII — транслітеровано, не видалено. Діакритику й нелатинські символи треба конвертувати, а не викидати, інакше сенс зникає разом із символом.
- Без подвійних чи кінцевих роздільників.
/naikrashchi-kafe--lvova-— класична ознака того, що slug редагували вручну і забули перевірити результат.
Як Google насправді використовує slug
URL — не важкоатлетичний фактор ранжування, яким його малювала SEO-література 2010-х: Hummingbird, а пізніше BERT, навчили Google набагато краще розуміти зміст сторінки напряму, з накопиченням ключів чи без нього. Що slug досі робить — це вирішує, буде клік чи ні.
Google зазвичай показує лише перші 60–70 символів шляху URL у сніпеті пошуку, перш ніж обрізати його — та сама практична, орієнтована на рендер межа, яку ми розбираємо для рядка опису в гайді з довжини meta description. Задовгий slug не карається штрафом — його просто обрізають, і читач ніколи не бачить другу половину ретельно продуманого ключового слова.
Короткий, тематичний slug — це сигнал довіри, який читач зчитує за півсекунди, задовго до того, як прочитає заголовок.
Проблема транслітерації — чому «просто нижній регістр і заміна пробілів» ламається
Наївна функція slugify — переводить рядок у нижній регістр, міняє пробіли на дефіси — прекрасно працює на Best Coffee Shops in Brooklyn. Вона розвалюється тієї ж миті, коли в назві з'являється діакритика чи нелатинський алфавіт.
Пропусти café naïve через регулярку, яка лишає тільки [a-z0-9-], і отримаєш caf-nave — é та ï просто зникають замість того, щоб конвертуватись, і слово тихо калічиться. Пропусти українську назву на кшталт Найкращі кафе Львова через той самий наївний фільтр — і кожна літера буде вирізана, залишаться голі дефіси там, де були пробіли: зламане -- замість порожнього рядка, бо наївна версія зазвичай забуває схлопнути чи обрізати ці залишки.
Ось ті самі дві назви, пропущені через наївний підхід і через реальну транслітерацію нашого генератора:
| Вхід | Наївний фільтр [a-z0-9-] | Наш генератор |
|---|---|---|
café naïve | caf-nave (діакритика тихо відкидається) | cafe-naive (NFKD прибирає діакритичний знак, лишає літеру) |
Найкращі кафе Львова | -- (кожна літера вирізана, лишаються тільки голі дефіси) | naikrashchi-kafe-lvova (транслітеровано за звучанням, повністю читабельно) |
Наш генератор коректно обробляє обидва випадки замість того, щоб просто відкидати символи:
- Unicode-нормалізація NFKD розкладає літери з діакритикою на базову літеру плюс комбінований знак, а тоді прибирає знак — café стає
cafe, naïve стаєnaive, сенс не втрачається. - Таблиця кирилиці в латиницю за українською конвенцією конвертує за звучанням, а не видаленням — г стає
h, х стаєkh, щ стаєshch— тож українська назва все одно дає читабельний, вимовний ASCII-slug, а не порожній рядок чи стіну процентного кодування.
Це має значення навіть для суто англомовних сайтів — досить, щоб псевдонім автора гостьового посту, назва продукту чи цитований бренд містили діакритичний знак, і один такий пост про café вже ловить цей баг.
Масова генерація slug — сценарій міграції
Якщо переносиш блог із WordPress, перебудовуєш каталог на Shopify чи імпортуєш CSV із 400 назвами статей у нову CMS, генерувати slug по одному в голові — це не план, а спосіб отримати три сторінки під назвою /report вже до третього імпорту.
Перемкни генератор у пакетний режим, встав по одній назві на рядок — і він конвертує весь список за один прохід. Кожен рядок звіряється з усіма іншими, і будь-який slug, що зіллється з іншим, позначається значком дубліката ще до імпорту. Це якраз той збій, який найчастіше пропускають підходи «таблиця плюс регулярка руками»: «Нарада з планування Q3» і «Нарада з планування Q3 (фінальна версія)» цілком можуть звестись до однакового slug після видалення пунктуації, і ти не помітиш цього, доки дві сторінки не зіткнуться на одному URL уже в проді.
Якщо вихідні назви прийшли з вивантаження в неоднорідному регістрі — НАЗВИ ВЕЛИКИМИ ЛІТЕРАМИ впереміш із Title Case — прогін через наш Зміна регістру не вплине на згенерований slug (він і так завжди в нижньому регістрі), але приведе до ладу саму колонку з людськочитабельними назвами в тій самій таблиці, яка все одно знадобиться для <h1> сторінки.
Рекомендована довжина slug за контекстом
Жорсткого ліміту, однакового для всіх платформ, не існує — це орієнтир, що виходить із того, як кожен контекст показує чи обробляє URL, а не системне обмеження:
| Сценарій | Рекомендована довжина | Чому |
|---|---|---|
| Стаття блогу | 3–5 слів (~40–60 символів) | Приблизно там, де сніпет пошуку Google зазвичай обрізає рядок URL |
| Сторінка товару в e-commerce | 2–4 слова (~30–50 символів) | Категорія + назва товару; артикули й варіанти належать до структурованих даних, а не до шляху |
| Сторінка документації | 2–3 слова на сегмент (~20–40 символів) | Вкладені категорійні шляхи накопичуються — тримай кожен сегмент коротким, бо довжина всього шляху сумується |
| Новина чи вічнозелена стаття | Пропусти дату, якщо матеріал не прив'язаний до конкретного моменту | Датований slug старить вічнозелений матеріал одразу, щойно змінюється рік |
Поширені помилки в slug, які легко проґавити
Зміна живого slug без редиректу. Проіндексована адреса, змінена без 301, що веде зі старого шляху на новий, втрачає історію зворотних посилань — Google фактично трактує це як нову сторінку, довіру до якої треба заробляти заново.
Накопичення ключових слів прямо в slug. /naikrashchi-deshevi-dostupni-biudzhetni-kafe-lvova-ukraina читається людиною як спам і не дає жодної переваги над /deshevi-kafe-lvova — ключове слово достатньо вжити один раз.
Автозгенеровані числові ID, які так і лишили. /product-48291 не каже читачу нічого. Технічно робочий варіант, але марнує ту частину URL, яка могла безкоштовно нести контекст.
Кінцеві чи подвійні дефіси після ручного редагування. /naikrashchi-kafe--lvova- зазвичай означає, що хтось відредагував slug вручну після генерації й не перевірив результат — прожени його ще раз через генератор замість ручного патчу.
Коли slug'и готові, швидкий прогін через Лічильник слів для заголовка й опису сторінки тримає решту метаданих у злагоді з побудованим URL — те саме ключове слово, те саме формулювання, без розбіжності між тим, що обіцяє посилання, і тим, що доставляє сторінка.