Panduan Trailing Slash

TL;DR — Trailing slash adalah karakter / di akhir URL—example.com/page/ dibandingkan dengan example.com/page. Pada beranda, karakter ini sama sekali tidak membedakan URL (example.com = example.com/). Di tempat lain, keduanya merupakan URL yang berbeda bagi Google. Pilih satu format, alihkan versi lainnya ke format itu, dan gunakan tautan secara konsisten. Tidak ada pilihan yang “paling benar”—konsistensilah yang terpenting.

Apa itu trailing slash

Trailing slash adalah garis miring ke depan yang berada tepat di akhir alamat web:

example.com/page/     ← with a trailing slash
example.com/page      ← without a trailing slash

Hanya itu—satu karakter. Namun, satu karakter tersebut dapat membuat sebuah halaman terlihat sebagai dua URL berbeda bagi mesin pencari.

Satu pengecualian: beranda Anda

Hanya ada satu tempat di mana trailing slash benar-benar tidak berpengaruh, yaitu domain root tanpa path. example.com dan example.com/ selalu diperlakukan sebagai hal yang sama. Anda dapat menuliskannya dengan salah satu cara dan Google tetap melihat URL yang sama. Alasan teknisnya dibahas di tab Lanjutan; secara praktis, Anda tidak perlu mengkhawatirkan slash pada beranda.

Di tempat lain, URL-nya berbeda

Begitu ada path setelah domain, slash menjadi penting. example.com/shoes dan example.com/shoes/ adalah dua URL terpisah. Jika keduanya memuat halaman yang sama dan Anda belum memberi tahu mesin pencari versi mana yang dipilih, Anda dapat memiliki URL duplikat—konten yang sama di dua alamat sehingga sinyalnya terbagi, bukan terkonsolidasi pada satu alamat.

Apa yang perlu dilakukan

Anda tidak perlu memperdebatkan format mana yang “lebih baik”. Keduanya dapat digunakan. Yang penting adalah memilih satu dan menggunakannya secara konsisten:

• Tentukan: memakai slash atau tanpa slash.
• Buat versi lainnya dialihkan ke versi pilihan Anda.
• Gunakan versi pilihan itu pada semua tautan internal.
• Cantumkan hanya versi pilihan tersebut di sitemap XML.

Satu hal yang perlu diperhatikan: jangan menganggap penambahan slash pada URL yang menyerupai file selalu aman. Tindakan itu membuat path berbeda; apakah path tersebut memuat, dialihkan, atau menghasilkan error bergantung pada server dan aplikasi.

Ingin memahami sejarah slash, cuplikan konfigurasi Apache, Nginx, dan IIS untuk menerapkannya, keunikan REST API, serta alasan saya biasanya menyarankan agar Anda tidak mengubah URL? Buka tab Lanjutan.

TL;DR — example.com dan example.com/ identik—domain root adalah satu-satunya aturan universal. Di tempat lain, /page dan /page/ merupakan URL berbeda; jika keduanya aktif tanpa konsolidasi, muncullah URL duplikat. Format yang dipilih tidak penting. Terapkan satu format dengan pengalihan 301 sebagai sinyal kanonisasi yang kuat—trailing slash hanyalah satu dari sekitar 40 sinyal—lalu dukung dengan tag canonical ketika pengalihan tidak memungkinkan, tautan internal yang konsisten, dan entri sitemap. Waspadai path file (page.html/ adalah path berbeda yang perilakunya bergantung pada server), REST API (framework seperti Flask dapat memperlakukan /resource dan /resource/ sebagai rute berbeda), garis miring ganda, serta rantai pengalihan HTTPS/www. Saran saya tetap sama: jangan memaksakan perubahan kecuali konfigurasi itu memang menimbulkan masalah.

Apa itu trailing slash, dan dari mana asalnya

Trailing slash adalah garis miring ke depan di akhir URL. Seperti yang saya tulis dalam panduan trailing slash Ahrefs, “A trailing slash is a forward slash (”/”) placed at the end of a URL such as domain.com/ or domain.com/page/.” (terjemahan) “Trailing slash adalah garis miring ke depan yang ditempatkan di akhir URL seperti pada dua contoh tersebut.”

Dahulu, slash memiliki makna khusus. Folder memakai trailing slash, sedangkan file tidak. Slash menjadi cara server menyatakan “ini adalah direktori, wadah bagi hal lain”, bukan satu file seperti index.html. Perbedaan itu kini lebih bersifat historis: pada kebanyakan sistem modern, URL tidak menunjuk langsung ke file, melainkan ke rekaman dalam basis data. CMS mengarahkan /blog/trailing-slash/ ke sebuah baris basis data, bukan folder pada hard drive. Karena itu, makna direktori-versus-file sebagian besar berubah menjadi konvensi pemformatan.

Konvensinya memudar, tetapi perilaku server yang dahulu melahirkannya tidak sepenuhnya hilang. Dari sinilah masalah mekanis berikut berasal.

Satu aturan universal: pengecualian domain root

Inilah satu aturan yang berlaku di mana pun: trailing slash pada domain root tanpa path tidak berpengaruh. example.com dan example.com/ adalah URL yang sama.

Ini bukan sekadar aturan SEO, melainkan cara kerja HTTP. Permintaan beranda secara teknis adalah permintaan untuk /; slash setelah hostname selalu ada, meski browser menyembunyikannya di bilah alamat. John Mueller menjelaskan bahwa slash pada root hadir secara implisit dan tersirat untuk kanonisasi. Jadi, bagi Google, https://example.com secara fungsional sama dengan https://example.com/. Tidak ada URL kedua yang perlu dialihkan pada root; keduanya adalah sumber daya yang sama. Versi sederhana saya: domain.com = domain.com/—“These URLs are treated exactly the same and it doesn’t matter which version you use.” (terjemahan) “URL-URL ini diperlakukan sama persis dan versi mana yang Anda gunakan tidaklah penting.”

Di lokasi lain, kesetaraan tersebut tidak berlaku.

Di tempat lain, URL-nya benar-benar berbeda

Begitu ada path setelah domain, slash menjadi bagian nyata dari URL. Seperti yang saya tulis: untuk setiap kasus selain trailing slash tepat setelah domain root, URL dengan trailing slash diperlakukan sebagai URL terpisah. Karena itu, example.com/shoes dan example.com/shoes/ adalah dua alamat berbeda.

Jika keduanya memuat konten yang sama dan tidak ada yang dikonsolidasikan ke versi lain, Anda menciptakan URL duplikat—masalah yang diselesaikan oleh kanonisasi. Pada kebanyakan konfigurasi, hal ini tidak menjadi bencana karena tag canonical yang merujuk diri sendiri atau penanganan duplikat Google biasanya memilih satu versi. Namun, “biasanya” bukan “selalu”. Membiarkannya berarti mengandalkan tebakan Google alih-alih memberi sinyal yang jelas.

Masalah yang tetap ada: jangan tambahkan slash pada file nyata

Makna file-versus-direktori telah memudar, tetapi perilaku mekanisnya belum. Pada kebanyakan kasus, jika trailing slash ditambahkan pada file seperti .html, .php, .js, .css, .pdf, atau .jpg, file itu tidak akan dimuat. Contoh Mueller adalah https://www.google.com/humans.txt dibandingkan dengan https://www.google.com/humans.txt/. Menambahkan slash pada path file nyata menghasilkan URL berbeda yang biasanya tidak mengarah ke file tersebut—sering kali 404 atau ditangani secara keliru. Jadi, aturan “tambahkan slash di mana-mana” justru merusak URL yang berakhir dengan nama file. Itulah sebabnya aturan server di bawah harus mengenali file.

REST API memiliki perilaku berbeda

Hampir semua artikel trailing slash berasumsi bahwa /page dan /page/ pada frontend CMS menyajikan konten yang sama dan hanya perlu dikonsolidasikan. Asumsi itu tidak berlaku untuk REST API.

Banyak framework API memperlakukan /resource dan /resource/ sebagai rute yang benar- benar berbeda, bukan dua tampilan duplikat. Flask adalah contoh terdokumentasi yang jelas: jika rute didefinisikan dengan trailing slash, permintaan tanpa slash otomatis dialihkan ke versi berslash. Jika rute didefinisikan tanpa trailing slash, permintaan berslash menghasilkan 404, kecuali perilaku tersebut dilonggarkan dengan strict_slashes=False. Express, Django REST Framework, dan framework lain memiliki konvensi serta pengaturannya sendiri. Jangan menganggap toleransi slash pada CMS juga berlaku pada lapisan API. Frontend headless dapat toleran terhadap slash sementara API- nya ketat; yang satu menimbulkan duplikasi SEO, sedangkan yang lain memicu 404 di aplikasi.

Pilih satu format dan terapkan—pengalihan dahulu, canonical sebagai cadangan

Jawaban jujur untuk “slash atau tanpa slash?” adalah bahwa pilihan formatnya tidak penting. Menggunakan trailing slash atau tidak lebih merupakan preferensi pribadi. Perwakilan Google telah lama menyarankan hal yang sama: gunakan satu versi URL secara konsisten—tautkan ke versi itu, alihkan ke sana, pakai di sitemap, dan tetapkan sebagai URL canonical. “Konsisten” adalah kata kuncinya. Semua sinyal kanonisasi harus selaras:

• Semua tautan internal memakai format pilihan.
• Sitemap hanya mencantumkan versi pilihan.
• Tag canonical menunjuk ke versi pilihan.
• Pengalihan mengirim versi lainnya ke versi pilihan.

Untuk sinyal yang paling kuat, pengalihan jauh lebih kuat daripada tag canonical saja. Trailing slash hanya satu dari banyak sinyal kanonisasi yang dipertimbangkan Google. Gary Illyes pernah menyebut lebih dari dua puluh, dan pada 2025 Google membicarakan sekitar empat puluh; daftar lengkapnya saya bahas dalam panduan kanonisasi. Illyes menyatakan, “301 redirect, or any sort of redirect actually, should be much higher weight when it comes to canonicalization than whether the page is on an http URL or https.” (terjemahan) “Pengalihan 301, atau pengalihan jenis apa pun, seharusnya memiliki bobot jauh lebih tinggi dalam kanonisasi daripada apakah halaman berada di URL HTTP atau HTTPS.” Google juga menegaskan bahwa canonical adalah petunjuk, bukan aturan dan “may choose a different page as canonical than you do.” (terjemahan) “dapat memilih halaman canonical yang berbeda dari pilihan Anda.” Jadi, gunakan pengalihan bila bisa; gunakan canonical hanya jika pengalihan benar-benar tidak memungkinkan, misalnya pada hosting bersama tanpa akses konfigurasi server, CDN/edge tanpa dukungan rewrite, atau sistem lama yang harus mempertahankan kedua versi.

Menerapkannya dalam konfigurasi server

Detail implementasi terpenting—dan yang paling sering salah pada cuplikan siap salin— adalah aturan harus mengenali file dan direktori. Aturan tidak boleh menghapus slash dari direktori nyata atau menambahkannya ke file nyata. Aturan Apache saya menggunakan guard !-d (bukan direktori) dan !-f (bukan file); versi Nginx dan IIS menerapkan logika yang sama. Cuplikan lengkap untuk kedua arah pada ketiga server tersedia di tab Skrip.

Detail lain yang mudah terlewat: aturan “hapus trailing slash” harus mengecualikan root. Permintaan beranda adalah permintaan untuk /. Jika slash dihapus dengan pola naif ^(.*)/$, aturan mencocokkan hasilnya sendiri dan mengalihkan / ke /. Itu adalah 301 ke URL yang sama dan, tergantung server serta klien, dapat membentuk loop. Karena root merupakan satu-satunya tempat slash tidak berpengaruh, kecualikan secara eksplisit. Mesin apa pun yang digunakan juga harus meneruskan string kueri asli tanpa perubahan; jangan hilangkan ?utm_source=... atau parameter serupa saat mengalihkan slash.

• Apache — .htaccess dengan mod_rewrite, menggunakan guard !-d / !-f.
• Nginx — aturan rewrite ... permanent (atau return 301), dengan try_files untuk menangani file dan direktori nyata.
• IIS — modul URL Rewrite, dinyatakan sebagai blok <rule> di web.config.

Apa pun servernya, tangani seluruh keputusan dalam satu aturan agar tidak menumpuk beberapa hop pengalihan. Masalah ini dibahas lagi pada bagian jebakan umum.

Default CMS dan platform

Kebanyakan orang tidak pernah menyentuh konfigurasi server karena platform sudah memilih format. Anda hanya perlu mengetahui pilihannya lalu menstandarkan seluruh sinyal padanya.

• WordPress secara default menambahkan trailing slash pada struktur permalink “Post name”. Pengaturannya berada di Settings > Permalinks. Seperti yang saya tulis, “/%postname%/ would add the trailing slash to URLs /%postname% would remove the trailing slash from URLs.” (terjemahan) “Struktur pertama menambahkan trailing slash pada URL, sedangkan struktur kedua menghapusnya.” Mengubah struktur khusus berlaku surut pada seluruh situs. Itu adalah perubahan URL dengan semua risiko yang menyertainya.
• Platform lain berbeda-beda. Shopify, Squarespace, Wix, dan generator situs statis memiliki default serta kemampuan perubahan masing-masing, yang kadang terbatas. Jangan berasumsi; periksa platform Anda, lalu selaraskan tautan internal, canonical, dan sitemap dengan URL yang benar-benar dihasilkannya.

Jebakan umum

Beberapa pola kegagalan yang sering muncul bersama ketidakkonsistenan trailing slash:

• Jebakan canonical yang merujuk diri sendiri. Nasihat “setiap halaman harus memiliki canonical yang merujuk dirinya” menjadi masalah ketika pengembang membuat kedua versi, berslash dan tanpa slash, masing-masing menunjuk dirinya sendiri. Dua halaman sama-sama menyatakan “sayalah canonical” sehingga tidak ada konsolidasi. Salah satunya harus dialihkan atau dikanoniskan ke yang lain.
• Garis miring ganda (//). Aturan yang menambahkan slash tanpa memeriksa slash yang sudah ada dapat menghasilkan example.com//page/. Menurut RFC 3986, ini sah secara teknis. Illyes berkata, “From a puritan perspective, that’s not an issue… the forward slash is a separator and is OK to appear in the URL path as many times as you like.” (terjemahan) “Dari sudut pandang puritan, itu bukan masalah; slash adalah pemisah dan boleh muncul di path URL sebanyak yang Anda mau.” Namun, ia langsung menambahkan, “From a usability perspective it’s probably not the greatest idea, and it may also confuse some crawlers.” (terjemahan) “Dari sisi kegunaan, itu mungkin bukan ide terbaik dan juga dapat membingungkan sejumlah crawler.” Hindari garis miring ganda.
• Rantai pengalihan. Pengalihan slash sering menumpuk dengan HTTP→HTTPS, non-www→www atau sebaliknya, serta normalisasi huruf besar-kecil. Satu permintaan dapat melewati tiga atau empat 301. Setiap hop mengurangi efisiensi crawl dan menambah latensi. Jika konfigurasi server memungkinkan, selesaikan protokol, host, slash, dan kapitalisasi dalam satu pengalihan. Perbarui pula tautan internal agar langsung menuju URL akhir.
• Perbedaan ketegasan mesin pencari. Pengujian independen menemukan bahwa Bing cenderung merayapi dan mengindeks satu versi dari pasangan slash/tanpa slash, sedangkan Google merayapi keduanya lalu menyaring satu. Anggap ini alasan untuk menjaga kerapian, bukan aturan resmi Bing.

Beberapa mitos yang perlu dihentikan

• “Ada format slash yang paling benar untuk SEO.” Tidak ada, kecuali pada root yang memang tidak membedakan apa pun. Konsistensi lebih penting daripada pilihan.
• “Trailing slash selalu berarti direktori saat ini.” Itu makna historis. Kebanyakan URL sekarang adalah rekaman basis data, meski server masih dapat dikonfigurasi seperti dahulu—itulah sebabnya path file masih bermasalah jika diberi slash.
• “Ketidakkonsistenan otomatis membagi peringkat atau ekuitas tautan menjadi dua.” Klaim itu tidak bersumber. Yang akurat: URL duplikat membagi sinyal ke dua alamat, bukan mengonsolidasikannya ke satu; ini efek nyata, tetapi bukan hukum 50/50.
• “Tag canonical sudah cukup; pengalihan tidak diperlukan.” Canonical hanyalah petunjuk yang dapat diabaikan Google, sedangkan 301 jauh lebih kuat. Alihkan bila bisa.

Haruskah URL yang ada diubah? Biasanya tidak

Jika situs sudah bekerja dan Anda hanya ingin merapikannya, jawaban saya sama seperti untuk perubahan URL pada umumnya: “There’s always a risk with changes, so unless your setup is causing issues I wouldn’t try to force a change to your URLs.” (terjemahan) “Perubahan selalu membawa risiko; jika konfigurasi Anda tidak menimbulkan masalah, saya tidak akan memaksakan perubahan URL.” Mengubah format slash di seluruh situs adalah migrasi URL penuh: setiap URL menerima 301, tautan internal perlu diperbarui, dan selalu ada biaya pemrosesan ulang serta risiko pengalihan yang salah. Perubahan layak dilakukan bila ada masalah nyata—kedua versi terindeks dan memecah sinyal halaman, API ketat slash menolak permintaan pengguna, atau rantai pengalihan berantakan. Perubahan tidak layak hanya agar URL “terlihat benar”. Konfigurasikan situs baru secara konsisten sejak awal; biarkan situs yang berfungsi tetap bekerja.

Topik ini berdekatan dengan artikel lain dalam klaster struktur situs: struktur URL sebagai induknya, kanonisasi sebagai mekanisme penyelesaian varian slash duplikat, arsitektur situs, dan struktur situs. Tautan antartopik akan terbentuk otomatis.

Ringkasan AI

Versi ringkas dari tab Lanjutan:

• Trailing slash adalah / di akhir URL (example.com/page/ dibandingkan dengan example.com/page). Secara historis, slash menandakan “direktori, bukan file”; kini kebanyakan URL merupakan rekaman basis data sehingga makna itu memudar.
• Pengecualian domain root adalah satu-satunya aturan universal: example.com = example.com/. Slash setelah hostname hadir secara implisit untuk kanonisasi; tidak ada yang perlu dialihkan pada root.
• Di tempat lain, /page ≠ /page/—keduanya URL berbeda. Jika sama-sama aktif tanpa konsolidasi, sinyal URL duplikat akan terbagi.
• Masalah mekanis yang bertahan: menambahkan slash pada path file nyata seperti page.html/ atau logo.png/ tidak memuat file; itu URL berbeda dan biasanya rusak.
• REST API berbeda dari CMS: banyak framework, misalnya Flask melalui strict_slashes, menganggap /resource dan /resource/ sebagai rute berbeda. Satu arah dapat dialihkan, sedangkan arah sebaliknya gagal. Jangan terapkan asumsi CMS pada API.
• Format mana pun boleh, asalkan konsisten. Tautan internal, sitemap, canonical, dan pengalihan harus selaras.
• Utamakan pengalihan; gunakan canonical sebagai cadangan. Trailing slash hanya satu dari sekitar 40 sinyal kanonisasi. Pengalihan 301 lebih kuat daripada canonical, dan canonical adalah “petunjuk, bukan aturan”.
• Aturan server harus mengenali file: Apache memakai mod_rewrite dengan guard !-d/!-f, Nginx memakai rewrite/try_files, dan IIS memakai URL Rewrite di web.config. Kedua arah tersedia di tab Skrip.
• Default CMS: WordPress menambahkan slash melalui /%postname%/; ubah melalui Settings > Permalinks. Platform lain perlu diperiksa satu per satu.
• Jebakan: kedua varian memiliki canonical ke dirinya sendiri; garis miring ganda yang sah menurut RFC 3986 tetapi “dapat membingungkan crawler”; rantai pengalihan HTTPS/www/kapitalisasi; dan kecenderungan Bing mengindeks satu varian.
• Perlukah URL yang ada diubah? Biasanya tidak—jangan memaksakan perubahan jika konfigurasi tidak menimbulkan masalah.

Dokumentasi resmi

Dokumentasi sumber primer dari mesin pencari. Google tidak pernah menerbitkan halaman pusat bantuan khusus trailing slash seperti untuk hreflang. Panduan yang relevan tersebar di dokumentasi kanonisasi, struktur URL, dan posting blog tahun 2010.

Google

• Memakai slash atau tidak — posting asli Google tentang topik ini (Maile Ohye, 2010; dipastikan masih aktif pada 2026-07-18): Google memperlakukan URL berslash dan tanpa slash secara terpisah, salah satunya dapat dipilih, dan root tidak dapat dialihkan “even if you’re Chuck Norris” (terjemahan) “bahkan jika Anda Chuck Norris”.
• Apa itu kanonisasi URL — posisi trailing slash dalam panduan saat ini: penanganan URL duplikat, sinyal kanonisasi, serta canonical sebagai “petunjuk, bukan aturan”.
• Cara menetapkan URL canonical — perbandingan pengalihan, tag canonical, dan penyertaan sitemap beserta kekuatan relatifnya (pengalihan kuat; sitemap lemah).
• URL structure best practices — panduan URL umum mengenai IETF STD 66, encoding, tanda hubung, dan kapitalisasi; tidak ada bagian khusus trailing slash, tetapi aturan terkait tetap berlaku.

Bing / Microsoft

• Lebih baik daripada canonical: normalisasi URL — cara Bing Webmaster Tools menggabungkan varian URL menggunakan sinyal normalisasi proaktif, bukan hanya mengandalkan rel=canonical.
• Panduan Webmaster Bing — panduan umum kebersihan URL: pendek, kaya kata kunci, dan tanpa variabel sesi; tidak membahas trailing slash secara khusus.

Kutipan dari sumber

Pernyataan resmi yang tercatat. Jika halaman sumber sulit diperiksa otomatis—misalnya dirender dengan JavaScript atau memblokir pengambilan langsung—kutipan diteruskan secara verbatim melalui liputan sekunder dan ditandai di bawah. Konfirmasikan dengan halaman aktif sebelum menganggapnya final.

Gary Illyes, Google — garis miring ganda (Search Engine Journal, verbatim)

• “From a puritan perspective, that’s not an issue. If you look at RFC 3986, section 3, the forward slash is a separator and is OK to appear in the URL path as many times as you like, even repeatedly.” (terjemahan) “Dari sudut pandang puritan, itu bukan masalah. Jika melihat RFC 3986 bagian 3, slash adalah pemisah dan boleh muncul di path URL sebanyak yang Anda mau, bahkan berulang kali.” Buka kutipan
• “From a usability perspective it’s probably not the greatest idea, and it may also confuse some crawlers.” (terjemahan) “Dari sisi kegunaan, itu mungkin bukan ide terbaik dan juga dapat membingungkan sejumlah crawler.” Buka kutipan

Gary Illyes, Google — bobot sinyal kanonisasi (Search Engine Journal, verbatim)

• “We employ, I think, over twenty signals, we use over twenty signals, to decide which page to pick as canonical from a dupe cluster.” (terjemahan) “Saya kira kami menggunakan lebih dari dua puluh sinyal untuk menentukan halaman canonical dari sebuah klaster duplikat.” Buka kutipan
• “301 redirect, or any sort of redirect actually, should be much higher weight when it comes to canonicalization than whether the page is on an http URL or https.” (terjemahan) “Pengalihan 301, atau jenis pengalihan apa pun, seharusnya berbobot jauh lebih tinggi dalam kanonisasi daripada apakah halaman memakai URL HTTP atau HTTPS.” Buka kutipan

Google — canonical adalah petunjuk (dokumentasi Search Central, verbatim)

• “Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.” (terjemahan) “Google dapat memilih halaman canonical yang berbeda dari pilihan Anda karena berbagai alasan. Menyatakan preferensi canonical adalah petunjuk, bukan aturan.” Buka kutipan

Maile Ohye, Google — posting asli tahun 2010 (Search Central Blog, verbatim; dipastikan aktif 2026-07-18)

• “Rest assured that for your root URL specifically, https://example.com is equivalent to https://example.com/ and can’t be redirected even if you’re Chuck Norris.” (terjemahan) “Khusus untuk URL root, yakinlah bahwa kedua bentuk alamat tersebut setara dan tidak dapat dialihkan, bahkan jika Anda Chuck Norris.” Buka kutipan

• “Google treats each URL above separately (and equally) regardless of whether it’s a file or a directory, or it contains a trailing slash or it doesn’t contain a trailing slash.” (terjemahan) “Google memperlakukan setiap URL di atas secara terpisah dan setara, baik berupa file maupun direktori, serta baik mengandung trailing slash maupun tidak.” Buka kutipan

  Sumber ini sebelumnya ditandai perlu ditinjau karena pengambilan terdahulu hanya mengembalikan navigasi. Pada pemeriksaan ulang langsung, posting bertanggal 2010 dengan nama Maile Ohye masih aktif di URL aslinya; kedua baris di atas disalin verbatim dari halaman saat ini.

John Mueller, Google — pengecualian domain root (blog “randoms” miliknya, verbatim; dipastikan aktif 2026-07-18)

• “The slash after a hostname or domain name is irrelevant, you can use it or not when referring to the URL, it ends up being the same thing. However, a slash anywhere else is a significant part of the URL and will change the URL if it’s there or not.” (terjemahan) “Slash setelah hostname atau nama domain tidak berpengaruh; Anda dapat menggunakannya atau tidak dan hasilnya sama. Namun, slash di lokasi lain merupakan bagian penting URL dan mengubah URL berdasarkan ada atau tidaknya.” Buka kutipan

  johnmu.com memblokir pengambilan langsung saat brief diteliti, tetapi sekarang dapat diakses. Kutipan ini adalah susunan kata persis dari posting tahun 2017—tulisan ulang jawaban Google+ terdahulu—termasuk penjelasan bahwa hal tersebut “is not SEO-specific, but just how websites work” (terjemahan) “bukan khusus SEO, melainkan cara kerja situs web”, berdasarkan sintaks permintaan HTTP, bukan aturan mesin pencari.

Patrick Stox (saya) — dari panduan trailing slash Ahrefs (kata-kata saya sendiri)

• “A trailing slash is a forward slash (”/”) placed at the end of a URL such as domain.com/ or domain.com/page/.” (terjemahan) “Trailing slash adalah garis miring ke depan di akhir URL seperti pada dua contoh tersebut.” Sumber
• “These URLs are treated exactly the same and it doesn’t matter which version you use.” (terjemahan) “URL-URL ini diperlakukan sama persis dan versi mana yang Anda gunakan tidaklah penting.” (tentang domain.com = domain.com/)
• “In most cases, if you add a trailing slash to a file such as .html, .php, .js, .css, .pdf, .jpg, etc., it won’t load the file.” (terjemahan) “Pada kebanyakan kasus, penambahan trailing slash ke jenis file yang disebutkan membuat file tersebut tidak dapat dimuat.”
• “Whether you choose to use a trailing slash or not is more of a personal preference than anything.” (terjemahan) “Memilih memakai trailing slash atau tidak lebih merupakan preferensi pribadi.”
• “There’s always a risk with changes, so unless your setup is causing issues I wouldn’t try to force a change to your URLs.” (terjemahan) “Perubahan selalu membawa risiko; jika konfigurasi Anda tidak menimbulkan masalah, saya tidak akan memaksakan perubahan URL.”

Daftar periksa audit trailing slash

Pemeriksaan cepat untuk memastikan satu format telah dipilih dan semua sinyal selaras:

• Satu format telah dipilih—slash atau tanpa slash—untuk seluruh situs, kecuali domain root yang tidak terpengaruh.
• Versi lainnya dialihkan dengan 301 ke versi pilihan di seluruh situs.
• Aturan pengalihan mengenali file dan direktori—tidak menghapus slash dari direktori nyata atau menambahkannya ke file nyata (.pdf, .jpg, .css, dll.).
• Semua tautan internal memakai format pilihan tanpa mencampur kedua varian.
• Sitemap XML hanya mencantumkan versi pilihan.
• Tag canonical menunjuk ke versi pilihan; kedua varian tidak sama-sama memiliki canonical yang merujuk dirinya sendiri.
• Tidak ada rantai pengalihan—normalisasi slash digabungkan dengan HTTPS/www/ kapitalisasi menjadi satu hop, dan tautan internal menuju URL akhir.
• Tidak ada garis miring ganda (//) akibat aturan rewrite yang keliru.
• Default CMS telah diperiksa—Anda tahu apakah platform menghasilkan trailing slash, misalnya WordPress dengan /%postname%/, dan semua sinyal cocok.
• Lapisan API diperiksa terpisah—untuk REST API, pastikan perilaku strict_slashes atau padanannya, bukan mengasumsikan perilaku CMS.
• Pemeriksaan singkat GSC—tidak ada status “Duplicate, Google chose different canonical than user” yang tak terduga dari varian slash, dan keduanya tidak sama- sama terindeks.

Ringkasan praktis trailing slash

Apakah slash berpengaruh di sini?

Terapkan dengan alat yang tepat

Kekuatan sinyal—mengapa pengalihan didahulukan

• Pengalihan 301 — kuat; bobotnya melampaui sinyal HTTPS menurut Illyes.
• rel="canonical" — petunjuk, bukan aturan; Google dapat mengabaikannya.
• Trailing slash adalah satu dari sekitar 40 sinyal kanonisasi; tidak istimewa, tetapi tetap harus selaras.

Fakta cepat

• Domain root: example.com = example.com/. Selalu.
• Default WordPress: trailing slash aktif (/%postname%/); ubah melalui Settings > Permalinks.
• Garis miring ganda (//) sah menurut RFC 3986, tetapi “may confuse some crawlers” (terjemahan) “dapat membingungkan sejumlah crawler”; hindari.
• Aturan server harus mengenali file/direktori (!-f / !-d pada Apache).
• Jangan ubah format situs yang bekerja hanya agar rapi: “unless your setup is causing issues I wouldn’t try to force a change to your URLs.” (terjemahan) “jika konfigurasi Anda tidak menimbulkan masalah, saya tidak akan memaksakan perubahan URL.”

Menerapkan aturan trailing slash—konfigurasi server

Berikut aturan siap salin untuk kedua arah pada tiga server utama. Syarat yang tidak dapat ditawar: aturan harus mengecualikan file dan direktori nyata, sehingga tidak menghapus slash dari folder atau menambahkannya pada style.css. Pilih satu arah; jangan terapkan keduanya. Idealnya, gabungkan aturan ini dengan pengalihan HTTPS/www yang sudah ada agar seluruh normalisasi selesai dalam satu hop.

Apache (.htaccess, mod_rewrite)

Hapus trailing slash (canonical = tanpa slash):

RewriteEngine On
# Don't touch the root: "/" is the homepage, and stripping its slash
# with the pattern below would redirect "/" to "/" — a same-URL loop.
RewriteCond %{REQUEST_URI} !^/$
# Don't touch real directories (they legitimately end in /)
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]

Tambahkan trailing slash (canonical = dengan slash):

RewriteEngine On
# Don't touch real files (.jpg, .css, .pdf, etc.)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

Guard !-d pada aturan “hapus” mencegah rusaknya permintaan direktori; guard !-f pada aturan “tambah” mencegah penambahan slash ke file nyata. Logika pengenalan file/direktori ini harus dibawa ke versi Nginx dan IIS. Pengecualian root pada aturan “hapus” diperlukan karena tanpa itu pola mencocokkan / milik beranda dan menulis ulang ke /—301 dengan URL identik yang oleh sebagian klien dianggap sebagai loop, bukan operasi kosong. mod_rewrite meneruskan string kueri asli secara default jika target tidak memiliki kueri sendiri. Anda tidak memerlukan QSA; jangan menambahkan ? literal pada substitusi karena itu akan menghapus kueri.

Nginx (rewrite / try_files)

Hapus trailing slash:

# Strip a trailing slash on anything that isn't a real directory.
location / {
    # If the request maps to a real file or directory, serve it as-is.
    if (-e $request_filename) {
        break;
    }
    rewrite ^/(.*)/$ /$1 permanent;
    try_files $uri $uri/ /index.php?$query_string;
}

Tambahkan trailing slash:

location / {
    # Only add a slash when the path has no file extension (i.e. not a real file).
    if ($uri ~ ^(.*[^/])$) {
        rewrite ^(.*[^/])$ $1/ permanent;
    }
    try_files $uri $uri/ /index.php?$query_string;
}

Nginx tidak memiliki operator !-f/!-d milik Apache. Sebagai gantinya, -e $request_filename memeriksa apakah path ada di disk, dan pemeriksaan ekstensi menjaga file/direktori nyata tetap utuh. Pemeriksaan -e juga melindungi root dari pengalihan ke dirinya sendiri karena root dipetakan ke direktori yang ada dan menjalankan break sebelum rewrite. Namun, jangan menjadikannya pengganti dokumentasi; uji root secara eksplisit setelah penerapan. Sesuaikan fallback try_files dengan aplikasi Anda—baris /index.php mengasumsikan PHP dan harus diganti jika backend berbeda.

IIS (modul URL Rewrite, web.config)

Hapus trailing slash:

<rewrite>
  <rules>
    <rule name="Remove trailing slash" stopProcessing="true">
      <match url="(.*)/$" />
      <conditions>
        <add input="{REQUEST_FILENAME}" matchType="IsFile"      negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
      </conditions>
      <action type="Redirect" url="{R:1}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

Tambahkan trailing slash:

<rewrite>
  <rules>
    <rule name="Add trailing slash" stopProcessing="true">
      <match url="(.*[^/])$" />
      <conditions>
        <add input="{REQUEST_FILENAME}" matchType="IsFile"      negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
      </conditions>
      <action type="Redirect" url="{R:1}/" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

Kondisi IsFile / IsDirectory IIS yang dinegasikan setara dengan !-f / !-d pada Apache—guard yang sama dengan sintaks berbeda. redirectType="Permanent" menghasilkan 301.

WordPress (tidak memerlukan konfigurasi server)

Pada WordPress, Anda biasanya tidak perlu memakai aturan di atas. Atur format melalui Settings > Permalinks: /%postname%/ menambahkan trailing slash dan /%postname% menghapusnya. Mengubah struktur khusus menulis ulang URL di seluruh situs, jadi perlakukan ini sebagai migrasi URL—lengkap dengan pengalihan dan pembaruan sitemap—bukan perubahan kosmetik.

Yang tidak boleh dilakukan

Berikut pola berulang yang membuat penanganan trailing slash gagal:

• Membiarkan kedua varian memiliki canonical ke dirinya sendiri. Nasihat “setiap halaman memerlukan canonical yang merujuk diri sendiri” diterapkan terlalu harfiah: /page menunjuk /page dan /page/ menunjuk /page/. Keduanya mengaku sebagai canonical sehingga tidak ada konsolidasi. Gabungkan salah satu varian ke varian pilihan melalui pengalihan atau canonical.
• Memakai canonical sebagai pengganti pengalihan yang tersedia. Canonical adalah petunjuk yang dapat diabaikan Google; 301 merupakan sinyal kuat. Jika Anda mengendalikan server, lakukan pengalihan dan jangan puas dengan sinyal yang lebih lemah.
• Aturan slash yang tidak mengenali file/direktori. Menambahkan slash tanpa pandang bulu merusak style.css menjadi style.css/; menghapusnya tanpa pandang bulu merusak permintaan direktori nyata. Selalu gunakan guard !-f/!-d, atau IsFile/IsDirectory di IIS serta -e/pemeriksaan ekstensi di Nginx.
• Menumpuk pengalihan. Hop terpisah untuk HTTPS, www, dan slash membuat satu permintaan melewati tiga atau empat 301. Gabungkan menjadi satu aturan dan perbarui tautan internal agar langsung mencapai URL akhir.
• Rewrite keliru yang menghasilkan garis miring ganda. Aturan yang menambahkan / tanpa memeriksa slash yang sudah ada menghasilkan example.com//page/. Ini sah menurut RFC 3986, tetapi “may confuse some crawlers” (terjemahan) “dapat membingungkan sejumlah crawler”.
• Menambahkan slash ke file nyata. /document.pdf/ dan /logo.png/ adalah URL berbeda yang tidak memuat file. Perilaku historis direktori-versus-file masih berdampak di sini.
• Menganggap API berperilaku seperti CMS. Frontend toleran slash dapat berada di atas API ketat yang menolak versi “salah”. Periksa perilaku framework secara terpisah.
• Mengubah format situs yang sudah bekerja demi kerapian. Ini migrasi URL penuh dengan risiko nyata. Jika tidak ada masalah, biarkan; terapkan konsistensi sejak awal pada situs baru.

Sumber yang layak dibaca

Tulisan terkait saya

• Trailing Slash: Dipakai atau Tidak? — panduan asli saya tentang pengecualian domain root, masalah path file, permalink WordPress, dan cuplikan Apache untuk menambah/menghapus slash. Artikel ini adalah pendalaman lanjutannya.
• Google Menggunakan Sekitar 40 Sinyal Kanonisasi — alasan trailing slash hanya satu dari banyak sinyal dan pengalihan lebih kuat daripada tag canonical saja.
• Parameter URL: Panduan Lengkap untuk Praktisi SEO — topik kebersihan URL terkait yang juga sering menciptakan URL duplikat.
• Pengalihan untuk SEO: Panduan Sederhana tetapi Lengkap — mekanisme pengalihan untuk konsistensi slash dan cara menghindari rantai pengalihan.
• Panduan SEO Teknis untuk Pemula — posisi kebersihan URL dalam gambaran SEO teknis yang lebih luas.

Presentasi saya

• Kursus Kilat SEO Teknis (SlideShare, Beer & SEO Meetup) — struktur URL dan kanonisasi dalam konteks.
• Kanonisasi untuk SEO — BrightonSEO, April 2023 (SlideShare) — model pengelompokan dan pemilihan yang menentukan varian slash pemenang.

Dari industri

• Memakai slash atau tidak (Google Search Central Blog, Maile Ohye, 2010) — posting dasar Google: URL berbeda, pilih salah satu, lalu konsolidasikan.
• Google Menjawab Dampak Garis Miring Ganda pada SEO (Search Engine Journal) — Illyes mengenai //: sah menurut RFC 3986 tetapi “may confuse some crawlers” (terjemahan) “dapat membingungkan sejumlah crawler”.
• Cara Google Memilih Halaman Canonical (Search Engine Journal) — Illyes mengenai lebih dari 20 sinyal kanonisasi dan bobot pengalihan yang melampaui HTTPS.
• Trailing Slash dan SEO: Kiat Singkat serta Jebakan (Positional) — ulasan terkini yang menekankan pembaruan tautan internal agar tidak membentuk rantai.
• Lebih Baik daripada Canonical: Normalisasi URL (Bing Webmaster Blog) — pendekatan normalisasi proaktif Bing untuk menggabungkan varian URL.
• Menghapus Ekstensi HTML dan Trailing Slash pada Konfigurasi Nginx (Sean C Davis) — referensi praktis rewrite/try_files Nginx.
• IIS: Menambah/Menghapus Trailing Slash (RewriteGuide) — aturan modul URL Rewrite IIS untuk kedua arah.

Kegagalan trailing slash yang umum

Kedua versi mengembalikan 200

Gejala: /page dan /page/ memuat konten yang sama tanpa pengalihan. Kemungkinan penyebab: Aplikasi merutekan kedua bentuk, tetapi edge atau server tidak menerapkan format pilihan. Perbaikan: Pilih format yang saat ini dominan, tambahkan pengalihan permanen satu hop dari varian lain, lalu selaraskan canonical, tautan internal, dan sitemap.

Aturan slash membuat rantai pengalihan

Gejala: Satu permintaan mengubah HTTP menjadi HTTPS, lalu hostname, kemudian slash dalam hop terpisah. Kemungkinan penyebab: Aturan normalisasi independen berjalan berurutan. Perbaikan: Gabungkan semuanya agar setiap varian langsung menuju URL akhir dengan HTTPS, host pilihan, dan format slash pilihan.

URL file atau rute API mulai gagal

Gejala: Aset, nama file, atau endpoint API menghasilkan error setelah normalisasi slash global. Kemungkinan penyebab: Aturan bergaya direktori diterapkan pada rute dengan semantik berbeda. Perbaikan: Kecualikan file nyata dan namespace API, lalu uji kelas rute tersebut secara terpisah sebelum mengaktifkan kembali aturan.

Alat untuk normalisasi slash

• Redirect Chain Mapper — tampilkan setiap hop normalisasi dan tentukan apakah aturan HTTPS, hostname, dan slash dapat digabungkan.
• Redirect Checker — periksa singkat pasangan slash dan tanpa slash setelah penerapan.
• Canonicalization Checker — bandingkan sinyal pengalihan, canonical, dan kemampuan pengindeksan ketika kedua bentuk URL pernah terekspos.
• Crawler seluruh situs — temukan tautan internal dan entri sitemap yang masih menghasilkan format bukan pilihan; pemeriksaan pengalihan saja tidak memperbaiki sumbernya.

Verifikasi pasangan URL yang representatif

Pengujian: Minta /path dan /path/ dengan Redirect Chain Mapper. Hasil yang diharapkan: Format pilihan dimuat normal dan varian lainnya dialihkan secara permanen dalam satu hop. Interpretasi kegagalan: Aturan normalisasi hilang, terbalik, atau bertumpuk dengan aturan pengalihan lain. Jendela pemantauan: Segera setelah penerapan. Pemicu rollback: URL pilihan mengalami loop, dialihkan dari halaman tujuan, atau tidak lagi mengembalikan respons berhasil.

Verifikasi pengecualian kelas rute

Pengujian: Periksa contoh halaman HTML, file nyata, endpoint API, URL dengan string kueri, dan domain root. Hasil yang diharapkan: Rute halaman dinormalisasi secara konsisten, sedangkan kelas yang dikecualikan mempertahankan perilakunya dan root selesai tanpa loop. Interpretasi kegagalan: Rewrite global mencocokkan lebih banyak path dari yang dimaksud. Jendela pemantauan: Segera, di setiap lingkungan yang perilaku rutingnya berbeda. Pemicu rollback: Aset atau API gagal, atau URL mana pun masuk ke loop.

Uji pemahaman: Trailing Slash

Lima pertanyaan singkat tentang perilaku trailing slash dan cara menerapkan satu format. Pilih jawaban untuk masing-masing pertanyaan, lalu periksa hasilnya.

Log perubahan