{"id":1931,"date":"2026-09-16T16:22:03","date_gmt":"2026-09-16T09:22:03","guid":{"rendered":"https:\/\/achmadfarid.com\/?p=1931"},"modified":"2026-09-16T16:22:03","modified_gmt":"2026-09-16T09:22:03","slug":"struktur-url-yang-seo-friendly","status":"publish","type":"post","link":"https:\/\/achmadfarid.com\/en\/struktur-url-yang-seo-friendly\/","title":{"rendered":"Struktur URL yang SEO Friendly: Google Menaruhnya di Bab Perayapan, Bukan Bab Peringkat"},"content":{"rendered":"

Hampir setiap audit yang saya kerjakan punya satu temuan yang sama, dan pemiliknya selalu terkejut waktu saya bilang temuan itu tidak perlu diapa-apakan. URL-nya jelek. Panjang, mengandung angka, kadang masih membawa tanggal terbit dari tujuh tahun lalu. Orang yang menyewa saya biasanya sudah tahu itu jelek, sudah membaca lima artikel tentang struktur URL yang SEO friendly, dan sudah menyiapkan anggaran untuk memperbaikinya.<\/span><\/p>\n

Yang mereka belum tahu: dari semua pekerjaan teknis yang bisa mereka biayai bulan itu, menulis ulang URL yang sudah berjalan hampir selalu ada di urutan paling bawah. Bukan karena URL tidak penting. Justru sebaliknya, ia penting untuk hal yang sama sekali berbeda dari yang mereka kira.<\/span><\/p>\n

Di artikel ini saya bongkar di bab mana sebenarnya Google menaruh materi ini di dokumentasi resminya, tujuh syarat yang benar-benar tertulis di sana (beberapa di antaranya tidak pernah saya temukan di panduan berbahasa Indonesia), tiga lapis keputusan yang saya pakai untuk memisahkan mana yang wajib dirapikan sejak awal dan mana yang boleh dibiarkan jelek selamanya, dan satu aturan yang membuat saya menolak pekerjaan penulisan ulang URL lebih sering daripada menerimanya.<\/span><\/p>\n

Klien Saya Menulis Ulang 340 URL, dan Trafiknya Tidak Bergerak Sedikit Pun<\/strong><\/h2>\n

Tahun lalu saya diminta mengevaluasi hasil sebuah proyek yang sudah selesai sebelum saya masuk. Sebuah situs media niche dengan sekitar 340 artikel memutuskan merapikan permalink-nya. Struktur lama memakai tanggal dan nomor, struktur barunya bersih dan deskriptif. Pengalihan permanen dipasang satu per satu, dipetakan manual, tidak ada yang meleset. Secara eksekusi, itu pekerjaan yang rapi.<\/span><\/p>\n

Tiga bulan berjalan, trafik organiknya persis sama. Bukan turun, bukan naik. Datar.<\/span><\/p>\n

Pemiliknya bertanya apa yang salah. Jawaban saya membuat suasana rapat jadi tidak enak selama beberapa menit: tidak ada yang salah, dan itu justru masalahnya. Mereka baru saja membayar tiga minggu kerja untuk memindahkan sinyal yang nyaris tidak punya bobot, lalu berharap hasilnya terasa. Tidak ada kesalahan teknis yang bisa saya tunjuk. Yang ada hanya keputusan prioritas yang keliru sejak sebelum satu baris pun diubah.<\/span><\/p>\n

Yang membuat saya menulis artikel ini bukan kasus itu sendiri. Yang membuat saya menulis adalah waktu saya membaca ulang panduan yang jadi rujukan mereka. Semuanya benar secara teknis. Semuanya menyebut hal yang sama: URL harus pendek, deskriptif, mengandung kata kunci, pakai tanda hubung. Dan tidak satu pun dari panduan itu menyebutkan berapa besar dampaknya, atau kapan sebaiknya Anda tidak melakukannya sama sekali.<\/span><\/p>\n

Saya ikut andil di sana. Artikel-artikel awal saya tentang topik ini juga menempatkan URL sebagai tuas peringkat, karena itu yang saya pelajari dari ekosistem yang sama.<\/span><\/p>\n

Struktur URL yang SEO Friendly, Ringkasnya<\/strong><\/h2>\n

Kalau Anda datang untuk satu jawaban cepat, ini jawabannya.<\/span><\/p>\n

Struktur URL yang SEO friendly adalah alamat halaman yang bisa dibaca manusia, konsisten polanya di seluruh situs, dan tidak menciptakan alamat baru dalam jumlah tak terbatas. Berdasarkan dokumentasi resmi Google tentang URL structure, yang terakhir diperbarui 10 Desember 2025, syaratnya sebagai berikut.<\/span><\/p>\n

Pakai kata yang bisa dibaca, bukan nomor ID.<\/b> Alamat yang berisi kata nyata lebih baik daripada alamat berisi deretan angka dan kode acak.<\/span><\/p>\n

Pakai bahasa audiens Anda.<\/b> Google menyebut ini eksplisit. Kalau pembaca Anda mencari dalam bahasa Indonesia, tulis slug-nya dalam bahasa Indonesia.<\/span><\/p>\n

Pakai tanda hubung, bukan garis bawah.<\/b> Alasannya bukan estetika. Garis bawah secara historis dipakai untuk menandai konsep yang harus dibaca menyatu, misalnya di penamaan fungsi pada bahasa pemrograman, sehingga tanda hubung lebih jelas sebagai pemisah kata.<\/span><\/p>\n

Pakai sesedikit mungkin parameter.<\/b> Pangkas parameter yang tidak mengubah isi halaman.<\/span><\/p>\n

Sadari bahwa URL bersifat case sensitive.<\/b> Google memperlakukan huruf besar dan huruf kecil sebagai dua alamat berbeda dengan isi masing-masing.<\/span><\/p>\n

Susun hierarki yang logis.<\/b> Alamat sebaiknya disusun dengan cara yang paling masuk akal buat manusia, mengikuti pengelompokan topik situs Anda.<\/span><\/p>\n

Pakai persentase encoding untuk karakter non-ASCII.<\/b> Ini berlaku kalau slug Anda mengandung huruf di luar alfabet dasar.<\/span><\/p>\n

Yang tidak ada di daftar itu, dan ini yang perlu digarisbawahi: tidak ada satu baris pun yang menjanjikan kenaikan peringkat. Sisa artikel ini menjelaskan kenapa.<\/span><\/p>\n

Enam Bagian URL, dan Hanya Dua yang Sering Perlu Anda Pikirkan<\/strong><\/h2>\n

Sebelum memutuskan apa yang perlu dirapikan, ada gunanya memisahkan bagian-bagiannya. Sebuah alamat halaman terdiri dari enam komponen, dan masing-masing punya umur dan biaya perubahan yang berbeda jauh.<\/span><\/p>\n

Protokol, domain, dan subdomain<\/strong><\/h3>\n

Protokol<\/b> adalah bagian paling depan. HTTPS bukan lagi pilihan, ia baseline, dan Google memang memilih versi HTTPS di atas versi HTTP yang setara. Bagian ini diputuskan sekali dan tidak dibicarakan lagi.<\/span><\/p>\n

Domain<\/b> adalah nama situs Anda. Mengubahnya adalah proyek tersendiri dengan risiko tersendiri, bukan pekerjaan merapikan URL.<\/span><\/p>\n

Subdomain<\/b> adalah bagian di depan domain, misalnya alamat blog yang dipisah dari situs utama. Keputusan subdomain versus subfolder adalah keputusan arsitektur yang menentukan bagaimana otoritas situs Anda terkumpul atau terpecah, dan itu topik yang terlalu besar untuk ditumpangkan di sini.<\/span><\/p>\n

Direktori, slug, dan parameter<\/strong><\/h3>\n

Tiga inilah yang biasanya dimaksud orang ketika bertanya soal struktur URL.<\/span><\/p>\n

Direktori<\/b> adalah folder di tengah alamat, misalnya bagian blog pada sebuah alamat artikel. Direktori menyatakan pengelompokan. Ia jarang diubah, dan setiap kali diubah ia menyeret semua halaman di bawahnya.<\/span><\/p>\n

Slug<\/b> adalah bagian paling belakang yang menggambarkan halaman itu sendiri. Ini satu-satunya bagian yang bisa Anda tentukan bebas setiap kali membuat halaman baru, dan satu-satunya yang biayanya nol kalau Anda mengaturnya sejak awal.<\/span><\/p>\n

Parameter<\/b> adalah bagian setelah tanda tanya. Filter, urutan, pelacakan kampanye, penanda sesi. Bagian inilah yang paling berbahaya, dan hampir tidak pernah dibahas serius di panduan berbahasa Indonesia, padahal ia satu-satunya bagian yang bisa menciptakan masalah dalam skala tak terhingga.<\/span><\/p>\n

Pembagiannya jadi sederhana kalau dilihat dari sisi biaya. Slug murah dan Anda mengendalikannya penuh. Direktori mahal dan jarang perlu disentuh. Parameter tidak Anda tulis sendiri, ia dihasilkan sistem, dan justru karena itu ia paling sering luput.<\/span><\/p>\n

Google Tidak Menaruh Materi Ini di Bab Peringkat<\/strong><\/h2>\n

Ini bagian yang mengubah cara saya menjelaskan URL ke klien, dan saya sarankan Anda memeriksanya sendiri.<\/span><\/p>\n

Buka daftar isi dokumentasi Google Search Central. Halaman tentang URL structure tidak berada di bagian Ranking and search appearance. Ia berada di bagian Crawling and indexing, bertetangga dengan sitemap, robots.txt, dan kanonikalisasi. Itu bukan penempatan yang kebetulan.<\/span><\/p>\n

Kalimat pembuka halaman itu juga tidak berbicara tentang peringkat sama sekali. Yang ditulis Google: kalau URL Anda tidak memenuhi kriteria yang mereka sebutkan, Google Search kemungkinan akan merayapi situs Anda secara tidak efisien, termasuk tapi tidak terbatas pada laju perayapan yang sangat tinggi, atau tidak merayapinya sama sekali.<\/span><\/p>\n

Baca ulang bagian terakhirnya. Konsekuensi terburuk dari struktur URL yang kacau bukan peringkat yang rendah. Konsekuensi terburuknya adalah halaman Anda tidak dirayapi.<\/span><\/p>\n

Sekarang sandingkan dengan sisi peringkatnya. Soal kata kunci di dalam URL, John Mueller menyatakan pada 2016 bahwa itu faktor peringkat yang sangat kecil, bukan sesuatu yang perlu dipaksakan, dan bukan sesuatu yang menurut dia sepadan dengan usaha menata ulang situs hanya supaya kata kunci masuk ke URL. Setahun kemudian ia menyebut kata kunci di URL sebagai hal yang terlalu dibesar-besarkan untuk SEO Google, dan menyarankan memilih URL untuk manusia, bukan untuk mesin pencari. Google mengulang hal senada beberapa kali sesudahnya.<\/span><\/p>\n

Jadi kita punya dua pernyataan yang jarang dibaca berpasangan. Dari sisi peringkat, URL nyaris tidak berbobot dan menata ulang situs demi itu tidak dianjurkan oleh Google sendiri. Dari sisi perayapan, URL yang buruk bisa membuat halaman Anda tidak pernah dilihat.<\/span><\/p>\n

Yang sering terjadi di lapangan adalah orang mengerjakan sisi yang salah. Mereka menghabiskan tiga minggu memoles slug artikel yang sudah terindeks dengan baik, sambil membiarkan navigasi filter di halaman kategori menghasilkan ribuan alamat yang tidak berguna. Satu pekerjaan memindahkan sinyal kecil. Pekerjaan satunya menentukan apakah halaman terbaik Anda sempat dirayapi bulan ini.<\/span><\/p>\n

Tiga Lapis Keputusan: Pola, Slug, Parameter<\/strong><\/h2>\n

Setelah kasus 340 URL itu saya berhenti memperlakukan struktur URL sebagai satu pekerjaan. Saya memisahkannya jadi tiga lapis, karena ketiganya punya waktu pengerjaan, biaya, dan tingkat urgensi yang berbeda jauh.<\/span><\/p>\n

Lapis satu: pola situs. Diputuskan sekali, sebelum halaman pertama terbit<\/strong><\/h3>\n

Ini keputusan arsitektur, dan waktu terbaik mengerjakannya adalah sebelum situs punya trafik.<\/span><\/p>\n

Yang perlu ditetapkan: berapa lapis kedalaman yang dipakai, apakah kategori masuk ke dalam alamat atau tidak, apakah ada garis miring di akhir alamat atau tidak, dan semua huruf kecil tanpa pengecualian. Lalu tulis keputusan itu di suatu tempat yang bisa dibaca orang lain, karena masalah pola hampir selalu lahir dari dua orang yang membuat halaman dengan konvensi berbeda.<\/span><\/p>\n

Soal kedalaman, panduan yang saya pakai sederhana: alamat harus bisa dibaca dan masuk akal buat manusia, dan kalau saya butuh lebih dari tiga lapis untuk menjelaskan posisi sebuah halaman, biasanya yang bermasalah adalah pengelompokan topiknya, bukan alamatnya.<\/span><\/p>\n

Satu hal yang sering luput: konsistensi huruf. Karena Google memperlakukan huruf besar dan kecil sebagai alamat berbeda, situs yang server-nya melayani kedua versi dengan isi yang sama sedang menyediakan dua alamat untuk satu halaman, tanpa ada yang pernah memasangnya dengan sengaja.<\/span><\/p>\n

Lapis dua: slug halaman. Diputuskan setiap kali menerbitkan<\/strong><\/h3>\n

Ini lapis yang paling banyak dibahas orang dan paling murah dikerjakan, asalkan dikerjakan saat halaman dibuat.<\/span><\/p>\n

Cara saya menulis slug: ambil inti topiknya dalam tiga sampai lima kata, buang kata sambung yang tidak menambah makna, pakai bahasa Indonesia kalau pembacanya mencari dalam bahasa Indonesia, pisahkan dengan tanda hubung, dan berhenti. Tidak perlu memaksa kata kunci utuh masuk. Kalau slug yang terbaca wajar kebetulan mengandung kata kuncinya, bagus. Kalau harus dipaksa sampai terbaca kaku, tinggalkan.<\/span><\/p>\n

Satu kebiasaan yang saya sarankan: jangan menaruh tahun atau angka versi di slug untuk konten yang Anda rencanakan perbarui. Artikel yang alamatnya membawa angka tahun akan memaksa Anda memilih antara alamat yang terlihat usang atau pekerjaan pengalihan setiap Januari.<\/span><\/p>\n

Lapis tiga: parameter. Tidak Anda tulis, tapi Anda yang menanggungnya<\/strong><\/h3>\n

Ini lapis yang paling sering diabaikan dan paling mahal kalau salah.<\/span><\/p>\n

Parameter lahir dari fitur, bukan dari penulisan. Filter di halaman kategori, urutan harga, penanda sesi, parameter rujukan dari kampanye. Masing-masing terlihat sepele. Gabungannya tidak. Google menyebut secara khusus bahwa penyaringan yang bisa dikombinasikan secara aditif membuat jumlah alamat di situs meledak, karena setiap kombinasi filter menghasilkan alamat baru, padahal Googlebot cukup melihat sedikit daftar saja untuk sampai ke setiap halaman produknya.<\/span><\/p>\n

Tiga hal yang perlu Anda tetapkan di lapis ini.<\/span><\/p>\n

Pakai pemisah standar.<\/b> Tanda sama dengan untuk memisahkan nama dan nilai, tanda ampersand untuk menambah parameter berikutnya. Kalau satu nama punya beberapa nilai, koma aman dipakai. Tanda titik dua dan kurung siku sulit dikenali perayap sebagai pemisah.<\/span><\/p>\n

Buang parameter yang tidak mengubah isi.<\/b> Penanda sesi adalah contoh paling jelas, dan Google menyarankan memakai cookie sebagai gantinya.<\/span><\/p>\n

Putuskan mana yang boleh dirayapi.<\/b> Kalau alamat hasil filter tidak perlu muncul di pencarian, hentikan perayapannya. Mekanisme pemblokirannya sendiri punya jebakan yang sering salah dipahami, terutama anggapan bahwa memblokir perayapan sama dengan mencegah pengindeksan, dan saya sudah membedah bedanya di <\/span>panduan setting robots.txt yang menjelaskan kenapa Disallow hanya menghentikan perayapan dan bukan pengindeksan<\/span><\/a>.<\/span><\/p>\n

Kalau alamat hasil filter memang perlu muncul, pekerjaannya bergeser ke konsolidasi sinyal, dan di sana yang menentukan bukan lagi bentuk alamatnya melainkan apakah semua sinyal Anda menunjuk alamat yang sama. Saya urai persoalannya terpisah di <\/span>pembahasan kenapa canonical tag hanya petunjuk dan Google sering memilih URL yang berbeda dari deklarasi Anda<\/span><\/a>.<\/span><\/p>\n

Lima Hal yang Ada di Dokumen Google tapi Tidak di Panduan Indonesia<\/strong><\/h2>\n

Saya membaca ulang halaman satu Google untuk kata kunci ini sebelum menulis. Isinya seragam: enam sampai delapan ciri, contoh alamat baik dan buruk, selesai. Lima hal berikut ada di dokumentasi resmi Google dan tidak saya temukan di satu pun dari artikel itu.<\/span><\/p>\n

Fragmen tidak dipakai untuk mengubah isi halaman.<\/b> Kalau situs Anda menampilkan konten berbeda berdasarkan bagian alamat setelah tanda pagar, Google umumnya tidak mendukungnya. Ini relevan untuk situs yang dibangun dengan kerangka kerja JavaScript lama yang memakai pola itu untuk perutean. Google menyarankan memakai History API sebagai gantinya.<\/span><\/p>\n

Alamat Anda bisa berbahasa Indonesia, dan itu memang yang dianjurkan.<\/b> Banyak yang mengira slug harus bahasa Inggris supaya aman. Google menulis kebalikannya: pakai kata dalam bahasa audiens Anda. Contoh yang mereka pakai adalah kata Jerman untuk audiens Jerman dan karakter Jepang untuk audiens Jepang. Untuk situs Indonesia, artinya slug bahasa Indonesia bukan kompromi, ia justru rekomendasi.<\/span><\/p>\n

Tautan relatif yang menunjuk folder induk bisa menciptakan ruang alamat tanpa akhir.<\/b> Ini penyebab yang tidak pernah saya lihat dibahas dalam bahasa Indonesia. Kalau sebuah tautan yang menunjuk ke folder di atasnya dipasang di halaman yang salah, dan server Anda tidak membalas dengan status yang benar untuk halaman yang tidak ada, hasilnya adalah alamat palsu yang beranak terus. Google menyarankan memakai tautan relatif terhadap akar, bukan relatif terhadap folder induk.<\/span><\/p>\n

Kalender dinamis termasuk penyebab resmi ledakan alamat.<\/b> Kalender yang bisa diklik maju mundur tanpa batas tanggal akan menghasilkan alamat baru selamanya. Google menyarankan memberi atribut nofollow pada tautan ke halaman tanggal yang dibuat secara dinamis.<\/span><\/p>\n

Angka 1000 karakter itu batas, bukan target.<\/b> Beberapa panduan Indonesia mengutipnya sebagai rekomendasi panjang URL, dan itu membingungkan karena membuat orang mengira alamat 200 karakter masih aman. Alasan sebenarnya untuk memendekkan alamat bukan ambang teknis, melainkan keterbacaan buat manusia dan tampilan di cuplikan hasil pencarian.<\/span><\/p>\n

Kapan URL yang Jelek Sebaiknya Dibiarkan Saja<\/strong><\/h2>\n

Ini bagian yang membuat saya kehilangan beberapa proyek, dan saya tetap menyampaikannya di awal setiap kali.<\/span><\/p>\n

Menulis ulang alamat yang sudah berjalan bukan pekerjaan gratis. Ia mengubah setiap alamat yang pernah dibagikan orang, setiap tautan masuk yang pernah Anda dapatkan, setiap tangkapan layar di dokumentasi internal, dan setiap pengalihan yang harus dirawat seumur hidup situs. Biayanya nyata dan permanen. Imbalannya, seperti sudah dibahas di atas, sangat kecil.<\/span><\/p>\n

Aturan yang saya pakai, dan saya jalankan cukup ketat: <\/span>jangan sentuh alamat yang sudah berjalan kecuali ada kerusakan yang bisa Anda sebutkan namanya.<\/b><\/p>\n

Empat kerusakan yang layak jadi alasan<\/strong><\/h3>\n

Di luar keempat ini, menurut saya jawabannya tidak.<\/span><\/p>\n

Alamatnya menciptakan duplikat.<\/b> Satu halaman bisa dicapai lewat beberapa alamat, dan itu bukan karena parameter pelacakan melainkan karena struktur. Ini kerusakan, dan biasanya diselesaikan di lapis pola, bukan dengan menulis ulang slug satu per satu.<\/span><\/p>\n

Alamatnya menghasilkan jumlah tak terbatas.<\/b> Filter aditif, kalender tanpa batas, pencarian internal yang bisa dirayapi. Ini kerusakan yang paling layak dibayar, karena dampaknya ke perayapan nyata.<\/span><\/p>\n

Alamatnya salah secara substansi.<\/b> Slug menyebut topik yang bukan isi halamannya, biasanya sisa dari draf lama. Ini merugikan pengunjung yang membaca alamat sebelum mengklik.<\/span><\/p>\n

Anda memang sedang membangun atau memindahkan situs.<\/b> Kalau strukturnya toh akan berubah, rapikan sekalian. Biaya marginalnya mendekati nol.<\/span><\/p>\n

Yang tidak masuk daftar: alamat yang panjang tapi terbaca, alamat yang tidak mengandung kata kunci, alamat yang memakai pola berbeda dari kompetitor, dan alamat yang terlihat jelek tapi berfungsi.<\/span><\/p>\n

Tiga pemeriksaan yang membuktikan kerusakan itu ada atau tidak<\/strong><\/h3>\n

Ketiganya tidak akan muncul di panduan mana pun, karena baru terlihat saat Anda membuka alat pemeriksa.<\/span><\/p>\n

Situs Anda mungkin melayani dua versi alamat untuk setiap halaman tanpa ada yang tahu.<\/b> Ambil satu alamat halaman Anda, lalu buka lagi dengan mengganti satu huruf jadi kapital. Kalau halamannya tetap terbuka normal dan bukan halaman tidak ditemukan, server Anda sedang menyediakan dua alamat untuk satu isi. Google memang menyarankan menyeragamkan huruf supaya ia lebih mudah menyimpulkan bahwa keduanya merujuk halaman yang sama. Di banyak situs, pemeriksaan ini selesai dalam sepuluh detik dan hasilnya mengejutkan.<\/span><\/p>\n

Alamat hasil filter lebih banyak dari yang Anda kira, dan Anda bisa menghitungnya.<\/b> Kalau halaman kategori Anda punya lima filter dan masing-masing punya empat pilihan, jumlah kombinasi yang bisa dihasilkan bukan dua puluh. Ia jauh lebih besar, karena filter bisa ditumpuk. Tambahkan pilihan urutan, tambahkan paginasi, dan satu halaman kategori bisa menghasilkan ribuan alamat yang isinya saling tumpang tindih. Hitung sendiri sebelum menganggapnya tidak penting.<\/span><\/p>\n

Parameter pelacakan kampanye Anda ikut jadi alamat.<\/b> Setiap tautan kampanye yang pernah Anda sebar berpotensi terayapi kalau ada yang pernah menautkannya dari halaman publik. Ini bukan bencana dan biasanya tertangani sendiri, tapi ia menjelaskan kenapa laporan perayapan Anda memuat alamat yang tidak pernah Anda buat. Sebelum memperbaiki apa pun, pastikan dulu Anda tahu alamat itu datang dari mana.<\/span><\/p>\n

Kalau ternyata memang harus diganti<\/strong><\/h3>\n

Satu hal yang perlu diperjelas sejak awal: pekerjaannya bukan mengganti alamat, melainkan memindahkan makna. Halaman tujuan harus menjawab pertanyaan yang sama dengan halaman asalnya, dan keputusan itu lebih menentukan hasilnya daripada kode status yang Anda pilih. Cara memilih dan memasang pengalihannya sudah saya tulis terpisah di <\/span>pembahasan redirect 301 dan 302 sebagai pilihan makna, bukan pilihan angka<\/span><\/a>.<\/span><\/p>\n

Satu catatan jujur soal lapis pola. Mengubah konvensi alamat di seluruh situs hampir tidak pernah bisa dikerjakan dari dasbor CMS. Ia menyentuh aturan penulisan ulang di server, kadang di lapis jaringan pengiriman konten, dan template yang membangun tautan internal. Kalau situasi itu yang Anda hadapi, itu memang masuk pekerjaan <\/span>pembangunan dan pengembangan website<\/span><\/a>, bukan karena rumit secara SEO, tapi karena memindahkan aturan ke satu lapis yang benar butuh akses ke server.<\/span><\/p>\n

Lima Belas Menit untuk Tahu Apakah Struktur URL Anda Perlu Disentuh<\/strong><\/h2>\n

Kalau seluruh artikel ini harus dipadatkan jadi satu kalimat: struktur URL yang SEO friendly bukan tuas untuk menaikkan peringkat, ia gerbang yang menentukan apakah halaman Anda sempat dirayapi, dan gerbang itu hampir selalu ada di parameter, bukan di slug.<\/span><\/p>\n

Kalau Anda hanya sempat melakukan satu hal setelah membaca ini, lakukan yang ini. Lima belas menit cukup.<\/span><\/p>\n

Buka laporan perayapan di Search Console, atau kalau tidak ada, buka daftar alamat yang pernah dirayapi di alat audit mana pun yang Anda punya. Urutkan bukan berdasarkan trafik, tapi berdasarkan jumlah. Lalu cari pola yang berulang: alamat dengan tanda tanya, alamat yang hanya beda di satu nilai filter, alamat tanggal yang menerus. Kalau alamat semacam itu jumlahnya jauh melebihi jumlah halaman asli Anda, Anda baru saja menemukan pekerjaan yang paling berdampak bulan ini, dan itu bukan menulis ulang slug.<\/span><\/p>\n

Kalau ternyata tidak ada, situs Anda sehat di lapis ini. Mulai hari itu, satu-satunya pekerjaan URL yang tersisa adalah menulis slug yang wajar setiap kali menerbitkan halaman baru. Itu pekerjaan tiga puluh detik, bukan proyek.<\/span><\/p>\n

Dan kalau yang Anda temukan bukan satu dua pola tapi ledakan alamat yang sudah berjalan bertahun-tahun di beberapa lapis sekaligus, memetakan mana yang boleh dihentikan perayapannya, mana yang harus dikonsolidasikan, dan mana yang sebenarnya tidak apa-apa dibiarkan adalah bagian dari audit teknis yang saya kerjakan lewat <\/span>jasa SEO<\/span><\/a>. Tapi kerjakan dulu lima belas menitnya. Cukup sering hasilnya adalah kabar baik, dan saya lebih suka Anda tahu itu sebelum menghubungi siapa pun.<\/span><\/p>\n

Pertanyaan yang Sering Muncul soal Struktur URL<\/strong><\/h2>\n

Apakah URL harus mengandung kata kunci utama?<\/b><\/p>\n

Sebaiknya iya kalau slug yang wajar kebetulan memuatnya, tapi jangan dipaksakan. John Mueller menyebut kata kunci di URL sebagai faktor peringkat yang sangat kecil dan menyatakan tidak sepadan menata ulang situs hanya demi memasukkannya. Tulis slug supaya terbaca manusia, dan biarkan kata kuncinya masuk secara alami atau tidak sama sekali.<\/span><\/p>\n

Apakah saya perlu mengubah URL lama yang panjang dan berisi angka?<\/b><\/p>\n

Hampir selalu tidak, kecuali alamat itu menyebabkan kerusakan yang bisa Anda sebutkan: menciptakan duplikat, menghasilkan alamat tanpa batas, atau menyebut topik yang bukan isi halamannya. Alamat yang sekadar jelek tapi berfungsi lebih baik dibiarkan, karena biaya perawatan pengalihannya permanen sementara manfaatnya sangat kecil.<\/span><\/p>\n

Berapa panjang URL yang ideal?<\/b><\/p>\n

Tidak ada angka resmi dari Google. Batas 1000 karakter yang sering dikutip adalah batas teknis, bukan target. Patokan praktis yang saya pakai: cukup pendek untuk terbaca utuh di cuplikan hasil pencarian, dan cukup jelas sehingga orang bisa menebak isi halaman sebelum mengklik. Biasanya tiga sampai lima kata di slug sudah memenuhi keduanya.<\/span><\/p>\n

Slug sebaiknya bahasa Indonesia atau bahasa Inggris?<\/b><\/p>\n

Bahasa Indonesia, kalau pembaca Anda mencari dalam bahasa Indonesia. Dokumentasi Google menyarankan memakai kata dalam bahasa audiens Anda, dengan contoh eksplisit memakai kata Jerman untuk audiens Jerman. Anggapan bahwa slug harus bahasa Inggris supaya aman tidak punya dasar di dokumentasi mana pun.<\/span><\/p>\n

Apakah huruf kapital di URL bermasalah?<\/b><\/p>\n

Bisa jadi. Google memperlakukan alamat dengan huruf besar dan huruf kecil sebagai dua alamat berbeda dengan isi masing-masing. Kalau server Anda melayani keduanya dengan isi yang sama, Anda punya duplikat yang tidak disengaja. Google menyarankan menyeragamkan semuanya ke satu bentuk, dan huruf kecil adalah konvensi yang lazim.<\/span><\/p>\n

Parameter di URL selalu buruk untuk SEO?<\/b><\/p>\n

Tidak, parameter itu wajar dan sering diperlukan. Yang bermasalah adalah jumlahnya ketika filter bisa dikombinasikan bebas, parameter yang tidak mengubah isi halaman seperti penanda sesi, dan pemisah non-standar. Pakai tanda sama dengan dan ampersand, pangkas parameter yang tidak mengubah isi, dan putuskan secara sadar mana yang boleh dirayapi.<\/span><\/p>","protected":false},"excerpt":{"rendered":"

Hampir setiap audit yang saya kerjakan punya satu temuan yang sama, dan pemiliknya selalu terkejut waktu saya bilang temuan itu tidak perlu diapa-apakan. URL-nya jelek. Panjang, mengandung angka, kadang masih membawa tanggal terbit dari tujuh tahun lalu. Orang yang menyewa saya biasanya sudah tahu itu jelek, sudah membaca lima artikel tentang struktur URL yang SEO […]<\/p>\n","protected":false},"author":1,"featured_media":1932,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[533,531,534,530,528,113,532,529],"class_list":["post-1931","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technical","tag-crawl-efficiency","tag-hierarki-url","tag-permalink","tag-slug-artikel","tag-struktur-url","tag-technical-seo","tag-url-parameter","tag-url-seo-friendly"],"_links":{"self":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1931","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/comments?post=1931"}],"version-history":[{"count":1,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1931\/revisions"}],"predecessor-version":[{"id":1933,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1931\/revisions\/1933"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/media\/1932"}],"wp:attachment":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/media?parent=1931"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/categories?post=1931"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/tags?post=1931"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}