Generator Slug

Ubah judul apa pun menjadi URL slug yang bersih dan SEO-friendly

Slug generator mengubah judul halaman atau teks apa pun menjadi string pendek, huruf kecil, dan aman-URL yang menamai sebuah halaman — bagian setelah garis miring terakhir dalam sebuah alamat. Ketik judul dan URL slug generator ini membangun slug secara langsung: mengubah teks jadi huruf kecil, mengganti spasi dengan tanda hubung, mentransliterasi huruf beraksen, menghapus tanda baca, dan menggabungkan pemisah berulang menjadi satu tanda hubung yang bersih.

Jadi 'My First Blog Post!' langsung menjadi my-first-blog-post, siap disalin. Tidak ada yang perlu diinstal dan tidak ada akun untuk dibuat — tempel judul, sesuaikan opsinya, dan ambil hasilnya. Pratinjau diperbarui di setiap ketukan tombol, menampilkan slug jadi di dalam URL contoh sehingga Anda bisa melihat persis bagaimana tampilannya di address bar.

Apa yang membuat slug baik untuk SEO

Slug yang baik itu pendek, mudah dibaca, dan dibangun di sekitar kata kunci utama Anda. Mesin pencari menampilkan slug di hasil pencarian dan memakainya sebagai sinyal ranking, jadi kejelasan lebih penting daripada kelengkapan. Jaga tetap huruf kecil, pisahkan kata dengan tanda hubung — bukan garis bawah, yang dibaca Google sebagai menggabungkan dua kata alih-alih memisahkannya — dan potong kata-kata pengisi.

Aktifkan Remove stop words untuk secara otomatis menghapus kata seperti a, the, of, dan to — 'The Best Tips for a Healthy Diet' menjadi best-tips-healthy-diet, slug SEO-friendly yang lebih padat. Jaga slug di bawah 60 karakter jika memungkinkan. Atur panjang maksimum untuk memotong judul panjang ke seluruh kata sehingga Anda tidak pernah berakhir dengan fragmen rusak seperti how-to-bake-cre.

Aksen, simbol, dan teks non-Inggris

ASCII biasa adalah alfabet aman untuk URL, jadi apa pun di luar a–z, 0–9, dan tanda hubung perlu ditangani. Alat slugify ini mentransliterasi karakter beraksen ke padanan ASCII terdekatnya — é→e, ñ→n, ü→u, ç→c — dan memperluas huruf yang tidak punya padanan tunggal: ß→ss, æ→ae, ø→o.

'Niño Piñata Soirée' menjadi nino-pinata-soiree. Simbol dihapus, dan toggle opsional menulis ulang & menjadi and, sehingga 'Salt & Pepper' menjadi salt-and-pepper alih-alih diam-diam menghilangkan kata tersebut. Untuk bahasa seperti Cina atau Arab tanpa transliterasi langsung, sebagian besar platform CMS menangani slug lokal secara native — alat ini berfokus pada kasus skrip Latin di mana aksen adalah masalah utama.

Pembuatan slug massal dan opsi format

Butuh lebih dari satu slug? Beralih ke mode Bulk, tempel daftar judul — satu per baris — dan bulk slug generator mengembalikan satu slug per baris. Salin semua atau unduh file .txt. Setiap opsi yang Anda atur (penghapusan stop word, pemisah, panjang maksimum, huruf kecil, ekspansi ampersand) diterapkan secara konsisten di seluruh batch.

Ini praktis untuk migrasi blog ke CMS baru, mengisi kalender konten dengan struktur permalink yang direncanakan, atau menghasilkan slug dari daftar nama produk sebelum halamannya dibuat. Tanpa batas rate, tanpa langganan, dan tanpa upload — seluruh batch berjalan lokal di browser Anda, sehingga bahkan ratusan judul diproses dalam waktu kurang dari satu detik. Pilih pemisah tanda hubung atau garis bawah, atur panjang maksimum untuk menjaga permalink tetap rapi, atau pertahankan huruf kapital jika platform Anda membutuhkannya.

Perbandingan dengan it-tools.tech, 10015.io, dan slug generator lainnya

Sebagian besar alat slug online gratis mencakup dasar-dasarnya: huruf kecil, ganti spasi dengan tanda hubung, hapus tanda baca. it-tools.tech dan 10015.io keduanya melakukan ini, tetapi tidak ada yang menawarkan penghapusan stop word, pemisah yang bisa dikonfigurasi, atau mode bulk. GoToolsOnline menambahkan beberapa opsi tetapi tetap membutuhkan reload halaman untuk setiap konversi. Library khusus seperti slugify (npm) dan python-slugify lebih mumpuni tetapi membutuhkan penulisan kode.

Alat ini berada di antara keduanya: menangani transliterasi aksen, filter stop word, pilihan pemisah, panjang maksimum, dan ekspansi ampersand melalui UI langsung tanpa menginstal apa pun. Mode bulk mengisi celah bagi siapa pun yang perlu memproses daftar. Dan karena semuanya berjalan client-side di browser Anda, menempel judul halaman yang belum dipublikasikan tidak membawa risiko privasi — tidak ada judul yang dikirim ke server mana pun atau dicatat di mana pun.

Anatomi URL dan RFC 3986: apa yang ada di mana dalam sebuah alamat

URL memiliki lima bagian yang didefinisikan oleh RFC 3986, standar internet yang mengatur bagaimana alamat web disusun: skema (https://), authority (example.com), path (/blog/my-post), query string opsional (?ref=home), dan fragment opsional (#comments). Slug hidup di dalam path — bagian yang mengidentifikasi resource spesifik di server.

RFC 3986 mendefinisikan sekumpulan karakter tak-terbatas (unreserved) yang aman disertakan di bagian mana pun dari URL tanpa perlu percent-encoding: 26 huruf kapital dan 26 huruf kecil ASCII, digit 0–9, dan empat simbol tanda hubung (-), garis bawah (_), titik (.), dan tilde (~). Selain itu — spasi, aksen, &, ?, #, / yang dipakai di luar peran delimiternya — harus di-percent-encode menjadi urutan hex %XX. Spasi, misalnya, menjadi %20. Perhatikan bahwa tanda plus (+) bukan pengganti spasi universal: tanda ini merepresentasikan spasi hanya di dalam query string application/x-www-form-urlencoded (data formulir HTML), bukan di path URL. Menulis path seperti /my+blog+post secara teknis salah di luar konteks query dan bisa membingungkan server yang mem-parsing path secara harfiah.

Batas panjang URL browser juga perlu diketahui saat membangun URL berpaginasi atau berfilter yang panjang. Internet Explorer membatasi URL pada 2.048 karakter; Chrome dan Firefox modern menangani hingga sekitar 8.192 karakter sebelum memotongnya. Untuk slug secara spesifik, kendalanya bukan browser tetapi snippet mesin pencari: Google biasanya menampilkan 60–70 karakter URL di halaman hasil, sehingga slug lebih panjang dari itu terpotong dalam tampilan meskipun secara teknis tetap berfungsi.

Tanda hubung vs garis bawah: sikap definitif Google

Pilihan antara tanda hubung dan garis bawah bukan sekadar preferensi gaya — ini punya efek konkret dan terkonfirmasi terhadap bagaimana Google mengindeks halaman Anda. John Mueller dari Google telah menyatakan secara eksplisit dan berulang kali bahwa tanda hubung diperlakukan sebagai pemisah kata sementara garis bawah bertindak sebagai penggabung kata. Dalam praktiknya ini berarti slug word-count-tool diindeks sebagai tiga kata terpisah — «word», «count», dan «tool» — dan bisa cocok dengan salah satunya secara individual. Slug word_count_tool diindeks sebagai satu token gabungan, «wordcounttool», dan hanya akan cocok dengan pencarian bentuk gabungan yang persis itu.

Konsekuensinya bagi SEO langsung: slug bertanda hubung rangking untuk setiap kata kunci di segmen path, sementara yang bergaris bawah secara efektif menyembunyikan kata-kata itu dari indeks pencarian kecuali pencari mengetik bentuk gabungannya. Ini alasan definitif mengapa setiap CMS besar memakai tanda hubung secara default: WordPress, Drupal, Ghost, Shopify, Hugo, dan Jekyll semuanya menghasilkan slug bertanda hubung dari judul posting kecuali Anda mengubah pengaturannya. Gunakan garis bawah hanya dalam konteks yang secara eksplisit membutuhkannya, seperti identifier pemrograman, nama kolom database, atau parameter API internal yang tidak akan pernah muncul dalam URL yang bisa dirayapi.

Di luar pertanyaan tanda hubung vs garis bawah, panduan URL Google yang lebih luas adalah menjaga slug tetap pendek, deskriptif, dan stabil. Hindari ID numerik auto-generated seperti /p?id=12345 jika memungkinkan — slug yang bisa dibaca manusia membantu Googlebot memahami topik halaman bahkan sebelum membaca kontennya. Dan setelah halaman dipublikasikan dan diindeks, mengubah slug sebaiknya jadi pilihan terakhir: bahkan redirect 301 yang benar hanya meneruskan sekitar 90–99% link equity ke URL baru, dan tautan eksternal yang mengarah ke alamat lama butuh waktu berminggu-minggu hingga berbulan-bulan untuk diperbarui di indeks.

Slug internasional dan strategi transliterasi

Karakter non-ASCII dalam URL secara teknis legal berdasarkan standar Internationalized Resource Identifier (IRI), dan browser modern seperti Chrome dan Firefox akan menampilkan bentuk Unicode yang di-decode — sehingga slug seperti /café-paris ditampilkan dengan terbaca alih-alih sebagai /%C3%A9. Namun, permintaan HTTP yang mendasarinya tetap mengirimkan bentuk percent-encoded, dan alat lama, pemendek tautan, serta klien email terkadang merusak karakter yang di-encode. Untuk domain secara spesifik, hostname non-ASCII ditangani oleh encoding Punycode (misalnya münchen.de → xn--mnchen-3ya.de), sistem terpisah dari encoding path.

Sebagian besar platform CMS dan library slug secara default memakai transliterasi: memetakan setiap karakter beraksen atau non-Latin ke padanan ASCII terdekatnya sebelum menghasilkan slug. Ini menghasilkan URL yang aman secara universal — niño-pinata menjadi nino-pinata — dengan mengorbankan ejaan aslinya. Untuk skrip Arab, Ibrani, dan CJK (Cina, Jepang, Korea), di mana tidak ada pemetaan Latin satu-ke-satu yang bermakna, transliterasi tidak praktis. Pendekatan umumnya adalah memakai sistem transliterasi romanisasi (Pinyin untuk Mandarin, Hepburn untuk Jepang, ALA-LC untuk Arab), menyertakan slug lokal dan bahasa Inggris sekaligus, atau mengizinkan slug Unicode penuh dan mengandalkan server serta CDN untuk menanganinya dengan benar.

Shopify, WordPress (dengan plugin lokal yang tepat), dan Contentful semuanya mendukung slug Unicode secara native dan membiarkan browser mendekodenya untuk ditampilkan. Persyaratan teknisnya adalah server tidak melakukan double-encoding pada path yang masuk, header Accept-Language dan tag canonical diatur secara konsisten, dan logika redirect apa pun membandingkan URL yang sudah di-decode sehingga /caf%C3%A9 dan /café tidak diperlakukan sebagai dua halaman berbeda. Untuk sebagian besar konten skrip Latin, transliterasi ASCII tetap menjadi default yang lebih sederhana dan aman.

Tabrakan slug dan cara CMS menyelesaikan judul duplikat

Ketika dua halaman berbagi judul yang sama — atau judul yang menghasilkan slug yang sama setelah pemrosesan — terjadi tabrakan slug (slug collision). Resolusi universalnya adalah pemberian akhiran berurutan: postingan pertama mendapat my-post, yang kedua mendapat my-post-2, yang ketiga my-post-3, dan seterusnya. WordPress telah melakukan ini sejak versi 2.0; AutoSlugField Django (via django-autoslug), Str::slug Laravel dengan pengecekan keunikan, dan gem FriendlyId Rails semuanya menerapkan pola yang sama. Ini mencegah error server tetapi menghasilkan slug yang membawa angka tanpa makna semantik.

Alternatifnya adalah menambahkan fragmen hash atau UUID pendek — my-post-a3f2 — yang menghindari pola kenaikan yang bisa ditebak dan membuat slug unik tanpa menyiratkan urutan apa pun. Beberapa platform menggabungkan prefiks tanggal ke dalam struktur URL (/2024/06/my-post/) untuk menghindari tabrakan sepenuhnya, karena judul yang sama yang dipublikasikan di bulan berbeda hidup di path yang berbeda. URL dengan prefiks tanggal bekerja baik untuk situs berita dan jurnalisme tetapi menciptakan URL yang panjang dan membuat konten evergreen terlihat usang di hasil pencarian.

Untuk situs yang telah berjalan lama dengan ribuan artikel, strategi tabrakan yang dipilih sejak awal menjadi mahal untuk diubah kemudian. Jika slug sudah diindeks dan ditautkan, beralih dari akhiran numerik ke hash — atau dari flat ke URL berprefiks tanggal — membutuhkan redirect 301 untuk setiap alamat yang berubah, jeda perayapan berminggu-minggu saat Googlebot memprosesnya, dan tautan internal yang diperbarui di seluruh konten. Saran praktisnya adalah menentukan strategi tabrakan sebelum peluncuran, menjadikannya bagian dari konfigurasi CMS Anda, dan memperlakukan slug yang sudah dipublikasikan sebagai identifier permanen. Mengganti nama demi estetika jarang sepadan dengan gangguan SEO-nya.