Jawaban singkat: gunakan tanda hubung atau hyphen (-) untuk memisahkan kata pada URL baru, bukan underscore (_). Namun, jangan mengganti seluruh URL lama hanya demi mengikuti format tersebut. Periksa dahulu indeksasi, tautan masuk, konversi, canonical, dan kesiapan redirect. URL yang sudah bekerja dapat dipertahankan sambil standar penamaan baru diterapkan pada halaman berikutnya.
Pada 23 Oktober 2026, changelog Google Search Central mencatat klarifikasi panduan pemisah kata dalam URL. Alasannya adalah menyelaraskan dokumentasi dengan seri video The Non-Canonical Cabinet. Ini klarifikasi dokumentasi, bukan pengumuman penalti untuk situs yang memakai underscore. Panduan ini menerjemahkan perubahan tersebut menjadi prosedur audit bagi pengelola website perusahaan dan toko online Indonesia. Contoh URL menggunakan domain ilustrasi, bukan hasil audit klien Socta.
Apa yang sebenarnya diperjelas Google?
Dokumentasi URL structure best practices merekomendasikan hyphen karena membantu pengguna dan mesin pencari mengenali batas antarkata. Underscore secara historis sering menandai konsep yang perlu dipertahankan sebagai satu kesatuan, misalnya nama fungsi pemrograman format_date. Tanda hubung lebih jelas menunjukkan pemisahan kata dalam alamat halaman.
Bedakan tiga hal: rekomendasi format, masalah crawl, dan kebutuhan migrasi. Alamat dengan underscore tidak otomatis menjadi halaman yang tidak dapat diindeks. Sebaliknya, URL cantik dengan parameter tak terkendali tetap dapat menciptakan banyak versi halaman yang memboroskan crawl. Audit perlu menilai masalah nyata, bukan sekadar mencari karakter tertentu.
Untuk artikel baru, /blog/audit-url-toko-online/ merupakan pola yang mudah dibaca. Tidak perlu menambah nama kota atau seluruh variasi keyword ke slug. Pilih beberapa kata yang menjelaskan isi halaman. Judul boleh berubah ketika isi diperbarui; slug tidak harus ikut berubah setiap kali editorial memperbaiki judul.
Apakah semua URL dengan underscore harus diganti?
Tidak. Mulailah dengan daftar URL yang benar-benar dipakai, bukan daftar hasil tebakan dari nama file. Ekspor halaman dari CMS atau sitemap, lalu tambahkan data halaman arahan organik dan konversi jika akses tersedia. Pisahkan URL yang sudah dipublikasikan dari draft. Perubahan draft biasanya tidak membawa risiko kehilangan tautan publik yang sama.
Pada situs lama, penggantian slug menyentuh banyak komponen: routing, tautan internal, sitemap, canonical, tautan kampanye, serta redirect. Risiko muncul ketika satu komponen tertinggal. Misalnya, halaman baru mengarah kembali ke URL lama melalui canonical, sementara alamat lama sudah mengalihkan pengunjung ke halaman baru. Sinyal tersebut menjadi bertentangan.
Gunakan keputusan berdasarkan bukti berikut. Tabel ini rekomendasi kerja editorial, bukan aturan penilaian Google.
| Kondisi halaman | Keputusan awal | Bukti sebelum perubahan |
|---|---|---|
| Draft belum dipublikasikan | Terapkan hyphen | Tidak ada URL publik yang perlu dijaga |
| Halaman aktif, ada lead atau penjualan | Pertahankan dahulu | Landing page, konversi, tautan masuk |
| Halaman duplikat tanpa nilai mandiri | Evaluasi konsolidasi | Isi, canonical, traffic, backlink |
| URL rusak akibat kesalahan routing | Perbaiki masalah routing | Status HTTP, tujuan link, respons server |
| Migrasi CMS sudah disetujui | Sertakan pemetaan slug | Daftar lama-baru dan tes redirect |
Jika data traffic atau backlink belum tersedia, catat keterbatasannya. Tidak adanya akses data bukan bukti bahwa halaman tidak memiliki pengunjung. Hindari menghapus atau mengalihkan halaman bernilai hanya karena laporan belum dapat diambil.
Bagaimana mengaudit parameter tanpa merusak atribusi?
Pisahkan parameter yang mengubah isi dari parameter pelacakan. ?warna=hitam bisa mengubah daftar produk, sedangkan ?utm_source=newsletter biasanya mencatat sumber kunjungan. Keduanya tidak otomatis memerlukan keputusan indeksasi yang sama. Periksa keluaran halaman dan kebutuhan bisnis sebelum menulis aturan menyeluruh.
Google mendokumentasikan pola parameter umum dengan tanda sama dengan untuk pasangan kunci-nilai dan ampersand untuk memisahkan parameter. Contohnya ?kategori=sepatu&warna=hitam. Ini berbeda dari membuat sintaks kustom seperti pasangan dalam kurung yang sulit ditangani alat standar. Gunakan fasilitas routing dan URL bawaan platform bila tersedia.
Jangan menghapus semua parameter pada redirect demi membuat URL terlihat bersih. Langkah itu dapat menghilangkan informasi kampanye sebelum sistem analytics membaca sumber kunjungan. Uji satu tautan kampanye dari klik hingga halaman tujuan, lalu periksa apakah parameter yang dibutuhkan masih tersedia dan pencatatan berjalan sesuai konfigurasi persetujuan pengguna.
Untuk filter toko online, pertanyaannya bukan hanya apakah URL bisa dibuka. Apakah kombinasi filter memiliki permintaan pencarian dan pilihan produk yang cukup? Apakah ada konten yang benar-benar berbeda? Batasi kombinasi tidak berguna melalui rancangan navigasi. Jangan mempublikasikan ribuan halaman filter kosong untuk mengejar variasi keyword.
Mengapa huruf besar, fragment, dan link relatif perlu diperiksa?
Dokumentasi Google menjelaskan bahwa penanganan URL bersifat case-sensitive. /Produk/ dan /produk/ dapat diperlakukan sebagai alamat berbeda. Bila server menganggap keduanya sama, pilih satu bentuk konsisten pada link internal, canonical, dan sitemap. Pastikan keputusan itu sesuai perilaku platform; jangan menormalisasi path sensitif tanpa pemeriksaan.
Fragment seperti #spesifikasi berguna untuk melompat ke bagian pada halaman yang sama. Itu berbeda dari aplikasi yang mengganti seluruh isi produk melalui #/produk/sepatu. Google secara umum tidak mendukung fragment sebagai penentu halaman konten yang berbeda. Untuk aplikasi JavaScript, dokumentasinya menyarankan History API, dengan implementasi routing yang benar.
Periksa juga link relatif yang salah. Pada halaman bersarang, referensi tanpa path yang tepat dapat membentuk URL baru yang tidak dimaksudkan. Buka halaman dari alamat langsung, bukan hanya melalui navigasi aplikasi. Pastikan refresh, link breadcrumb, gambar, dan canonical tetap benar setelah pengunjung masuk melalui hasil pencarian.
Bagaimana menyiapkan perubahan slug yang memang diperlukan?
Buat pemetaan satu URL lama ke satu tujuan relevan. Target ideal mempertahankan maksud dan informasi utama halaman lama. Jangan mengarahkan semua halaman yang dipindah ke homepage: pengunjung yang mencari produk tertentu tidak terbantu ketika harus mengulang pencarian dari awal. Jika konten digabung, pastikan materi yang berguna ikut dipertahankan.
Gunakan permanent redirect untuk perpindahan permanen. Hindari rantai seperti alamat lama menuju slug perantara lalu baru menuju URL final. Setiap aturan perlu diperiksa terhadap aturan yang sudah ada, termasuk redirect domain, protokol, dan trailing slash. Perubahan kecil di file routing bisa menghasilkan loop bila urutan aturan tidak dipahami.
Setelah routing siap, perbarui tautan internal langsung menuju tujuan final. Redirect adalah jaring pengaman bagi link lama, bukan pengganti pemeliharaan navigasi. Perbarui juga sitemap dan canonical pada halaman tujuan. Bila ada kampanye berbayar aktif, koordinasikan penggantian URL dengan pengelola iklan agar pengujian tidak memutus halaman arahan.
Simpan daftar perubahan, penanggung jawab, dan cara rollback. Jangan menganggap build berhasil sebagai bukti domain publik sudah memakai versi terbaru. Deployment, cache, dan konfigurasi server dapat berbeda dari hasil lokal. Pemeriksaan harus mencakup alamat lama dan baru setelah versi produksi benar-benar aktif.
Checklist apa yang harus lolos sebelum dan sesudah deploy?
Lakukan pemeriksaan pada sampel kecil dahulu. Untuk website perusahaan, pilih halaman layanan dan artikel yang saling menaut. Untuk toko online, sertakan produk, kategori, serta URL berparameter. Sampel perlu mewakili perilaku routing yang berbeda, bukan hanya halaman homepage yang paling mudah dibuka.
Sebelum perubahan
- Catat URL lama, tujuan final, alasan bisnis, serta pemilik keputusan.
- Simpan status HTTP, title, H1, canonical, dan isi utama halaman.
- Periksa tautan masuk serta traffic jika datanya tersedia.
- Pastikan halaman tujuan tidak diblokir robots atau memuat noindex yang tidak disengaja.
- Uji tautan kampanye dan parameter yang diperlukan untuk atribusi.
- Pastikan aturan baru tidak bertabrakan dengan redirect yang sudah ada.
Setelah perubahan
- URL lama mengembalikan redirect permanen menuju tujuan yang benar.
- Tujuan final mengembalikan HTTP 200 dengan isi yang diharapkan.
- Canonical, sitemap, dan link internal menggunakan URL final yang konsisten.
- Tidak ada loop atau rantai tambahan pada skenario domain dan path yang diuji.
- Formulir, keranjang, serta aksi konversi tetap berfungsi pada perangkat seluler.
- Catat hasil pemeriksaan produksi, bukan hanya keluaran build lokal.
Jika Search Console tersedia, gunakan URL Inspection untuk memeriksa versi yang diketahui Google. Respons HTTP 200 dari browser tidak membuktikan halaman sudah terindeks. Sebaliknya, canonical Google yang belum berubah sesaat setelah deploy juga tidak langsung membuktikan kegagalan migrasi. Beri waktu pemrosesan dan nilai bukti secara berurutan.
Kapan audit dinyatakan berhasil?
Tentukan ukuran operasional sebelum mengubah URL: tujuan dapat dibuka, tidak ada link internal rusak, canonical konsisten, sitemap bersih, dan konversi teknis tetap berfungsi. Pantau log error serta laporan halaman arahan secara berkala. Peningkatan ranking bukan syarat untuk membuktikan redirect bekerja, apalagi janji dari penggantian underscore menjadi hyphen.
Bila hasil tidak sesuai, telusuri dari lapisan paling dekat: aturan redirect, respons halaman tujuan, markup awal, lalu data indeksasi. Hindari mengganti judul, konten, navigasi, dan slug sekaligus karena penyebab perubahan akan sulit dipisahkan. Koreksi satu kelompok masalah yang terukur sebelum memperluas cakupan.
Untuk tim Indonesia yang mengelola website melalui vendor berbeda, tetapkan satu pemilik daftar URL. Tim marketing menyatakan tujuan dan kampanye yang harus dijaga; developer menguji routing dan deployment; pengelola analytics memeriksa atribusi. Pembagian ini mencegah keputusan penamaan sederhana berubah menjadi gangguan operasional lintas tim.
Butuh mengevaluasi struktur halaman sebelum migrasi? Layanan website Socta dapat menjadi titik awal pembahasan routing, navigasi, dan konsolidasi. Mulai dari inventaris URL serta bukti masalah, bukan permintaan mengganti seluruh slug. Untuk konteks pemeriksaan lebih luas, baca panduan audit technical SEO.
Sumber primer dan tanggal pemeriksaan
- Google Search Central: Documentation updates, entri 23 Oktober 2026. Mencatat klarifikasi hyphen versus underscore dan alasannya; diakses 24 Oktober 2026.
- Google Search Central: URL structure best practices. Panduan pemisah kata, parameter, case-sensitive URL, dan fragment; diakses 24 Oktober 2026. Footer halaman saat pemeriksaan menampilkan 21 Oktober 2026, berbeda dari tanggal entri changelog.
- Google Search Central: Redirects and Google Search. Referensi redirect server dan perpindahan permanen; diakses 24 Oktober 2026. Urutan audit dan tabel keputusan dalam artikel ini adalah rekomendasi Socta, bukan kutipan aturan tambahan Google.
