Alamat sebuah halaman web jarang bertahan selamanya. Struktur permalink diubah supaya lebih rapi, situs pindah ke HTTPS setelah sertifikat terpasang, dua artikel yang bertumpang tindih digabung, atau perusahaan berganti nama domain. Masalahnya, alamat lama tidak ikut hilang begitu saja. Ia masih tersimpan di bookmark pengunjung, masih tercetak di brosur, masih ditautkan situs lain, dan masih tercatat di indeks mesin pencari. Di sinilah redirect bekerja: sebagai penerus alamat yang memastikan siapa pun yang datang lewat jalan lama tetap sampai ke tujuan.
Redirects Adalah Instruksi Pindah Alamat dari Server
Redirects adalah instruksi yang dikirim server untuk mengalihkan permintaan dari satu alamat ke alamat lain secara otomatis, tanpa pengunjung perlu mengklik apa pun. Dalam bahasa Indonesia, redirect artinya pengalihan. Anda mungkin juga menemukannya sebagai kata kerja "redirecting", tulisan singkat yang muncul sepersekian detik sebelum halaman berpindah.
Diringkas dalam satu kalimat, redirect adalah pengalihan yang dijalankan browser atas perintah server. Yang membedakannya dari tautan biasa adalah siapa yang mengambil keputusan. Pada tautan, pengunjung yang memilih untuk pindah. Pada redirect, servernya yang memutuskan, dan browser menjalankannya tanpa bertanya.
Alurnya terjadi dalam dua perjalanan bolak-balik. Browser meminta alamat lama, server tidak mengirim halaman apa pun melainkan membalas dengan kode 3xx disertai header Location yang berisi alamat baru, lalu browser mengulang permintaannya ke alamat itu. Seluruh proses berlangsung dalam puluhan hingga ratusan milidetik, sehingga pengunjung hanya melihat URL di bilah alamat berganti sendiri.
Balasan itu bisa dilihat langsung dari terminal:
curl -sI https://situsanda.co.id/lama \
| grep -iE 'HTTP/|location'Hasilnya dua baris: kode statusnya, lalu alamat tujuan. Kalau keduanya tidak muncul, tidak ada redirect yang terpasang di alamat itu.
Tiga Lapis Tempat Redirect Bisa Dipasang
Pengalihan bisa dipasang di tiga lapis berbeda, dan perbedaannya bukan soal selera melainkan soal kapan ia dijalankan.
- Lapis HTTP: server membalas dengan kode 3xx dan header
Location. Ini terjadi sebelum satu byte pun isi halaman dikirim, sehingga paling cepat dan paling andal. - Lapis HTML: halaman tetap dikirim utuh, lalu di dalam
<head>ada tag<meta http-equiv="refresh">yang memerintahkan browser berpindah. Pengalihan baru berjalan setelah halaman selesai dimuat. - Lapis JavaScript: pengalihan ditulis sebagai
window.locationdi dalam skrip. Ia berjalan saat skrip dieksekusi, yang berarti bergantung pada apakah skrip itu berhasil dimuat dan dijalankan.
Bentuk lapis kedua sederhana:
<meta http-equiv="refresh"
content="0; url=/alamat-baru">Urutan di atas sekaligus urutan keandalannya. Google menyatakan pengalihan sisi server adalah yang paling besar kemungkinannya ditafsirkan dengan benar, disusul meta refresh, lalu JavaScript. Menariknya, Google tetap membaca ketiganya sebagai sinyal — dan angka detik pada meta refresh menentukan artinya. Meta refresh nol detik dibaca sebagai pengalihan permanen, sedangkan meta refresh dengan jeda lebih dari nol detik dibaca sebagai sementara.
Tiga lapis redirect: HTTP berjalan sebelum halaman dikirim, meta refresh setelah dimuat, JavaScript saat skrip jalan.
Kalau sebuah halaman memasang lebih dari satu lapis sekaligus, yang menang adalah lapis HTTP, karena ia sudah selesai bekerja sebelum halaman sempat terkirim. Dua lapis lainnya tidak akan pernah dijalankan.
Membaca Kode 3xx: Sembilan Angka dan Artinya
Seluruh kode pengalihan berada di kelompok 3xx. RFC 9110, dokumen resmi yang mendefinisikan semantik HTTP sejak Juni 2022, mencatat sembilan angka di rentang itu — tetapi tidak semuanya masih relevan.
| Kode | Nama resmi | Status |
|---|---|---|
| 300 | Multiple Choices | jarang dipakai |
| 301 | Moved Permanently | permanen |
| 302 | Found | sementara |
| 303 | See Other | sementara |
| 304 | Not Modified | bukan pengalihan |
| 305 | Use Proxy | usang |
| 306 | (Unused) | dicadangkan |
| 307 | Temporary Redirect | sementara |
| 308 | Permanent Redirect | permanen |
Tiga baris di tabel itu perlu penjelasan supaya tidak menyesatkan. 304 memang berada di kelompok 3xx, tetapi ia tidak memindahkan pengunjung ke mana pun — ia hanya memberi tahu browser bahwa salinan yang tersimpan di cache masih berlaku. 305 dinyatakan usang oleh RFC 9110, dan 306 disebut "no longer used, and the code is reserved" alias tidak lagi dipakai serta angkanya dicadangkan.
Dalam praktik sehari-hari Anda hanya akan berurusan dengan empat angka. Status 301 dan kode 302 adalah dua yang paling sering muncul, disusul 307 dan 308. Pembagiannya dua sumbu. Sumbu pertama permanen versus sementara: 301 dan 308 permanen, 302 dan 307 sementara. Sumbu kedua adalah nasib method permintaan, dan itu pembahasan bagian berikutnya.
Satu catatan soal 308: RFC 9110 menandainya sebagai kode yang "much younger (June 2014)" dibanding saudara-saudaranya, sehingga masih ada perangkat lama yang tidak mengenalinya. Untuk browser modern hal ini tidak jadi persoalan, tetapi untuk API yang dipakai klien tua, 301 lebih aman.
Nasib Method POST Saat Redirect Terjadi
Pertanyaan yang wajar muncul: kalau 301 sudah permanen dan 302 sudah sementara, kenapa masih perlu 307 dan 308? Jawabannya ada pada apa yang terjadi ketika permintaan yang dialihkan bukan permintaan biasa.
Saat Anda membuka halaman, browser mengirim permintaan bermetode GET yang sekadar meminta isi. Saat Anda menekan tombol kirim pada formulir, yang dikirim adalah POST beserta data isiannya. Tiga kode tertua di daftar itu punya kebiasaan mengubah POST menjadi GET di tengah jalan, dan data isiannya hilang bersamaan.
RFC 9110 menyebutnya apa adanya sebagai warisan sejarah. Pada bagian 301 tertulis catatan bahwa untuk alasan historis, user agent (perangkat lunak yang mengakses web, umumnya browser) boleh mengubah method permintaan dari POST menjadi GET. Kalau perilaku itu tidak diinginkan, gunakan 308 sebagai gantinya. Catatan yang persis sama muncul pada 302, dengan saran memakai 307.
Perilaku ini kami uji langsung dengan curl 8.7.1. Sebuah server HTTP kecil dibuat untuk membalas tiap kode ke satu alamat tujuan yang sama, dan alamat itu mencetak method yang benar-benar diterimanya:
301 : METHOD=GET
302 : METHOD=GET
303 : METHOD=GET
307 : METHOD=POST
308 : METHOD=POSTHasilnya persis seperti yang dinyatakan spesifikasi. Digabungkan dengan sifat cache yang dibahas di bagian berikutnya, keempat kode utamanya bisa diringkas begini:
Redirect 301, 302, dan 303 mengubah POST menjadi GET sehingga data isian hilang; 307 dan 308 mempertahankan POST.
| Kode | Method POST | Boleh di-cache |
|---|---|---|
| 301 | jadi GET | ya |
| 302 | jadi GET | tidak |
| 303 | jadi GET | tidak |
| 307 | tetap POST | tidak |
| 308 | tetap POST | ya |
Ada satu jebakan saat menguji sendiri. Perintah curl -X POST memaksa method tetap POST di seluruh perjalanan, sehingga 301 pun akan terlihat mempertahankan POST dan bug yang sedang Anda cari justru tersembunyi. Untuk menguji perilaku sebenarnya, jangan pakai -X; cukup kirim datanya dan biarkan curl alami:
curl -sL -d "a=1" \
https://situsanda.co.id/kirimAturan praktisnya sederhana. Untuk halaman biasa yang diakses lewat GET, 301 dan 302 sudah memadai. Untuk endpoint API atau alamat yang menerima kiriman formulir, pakai 308 dan 307 supaya kiriman datanya tidak menguap di tengah jalan.
Kenapa Redirect 301 Sulit Dibatalkan
Penyebab kepanikan yang satu ini tercatat rapi di spesifikasi. RFC 9110 menyatakan balasan 301 bersifat heuristically cacheable, artinya browser dan proxy boleh menyimpannya meski server tidak pernah menyuruh menyimpan. Ketentuan yang sama berlaku untuk 308. Sebaliknya, 302, 303, dan 307 tidak punya sifat itu.
Anggap Anda salah memasang 301 dari /produk ke /produk-baru, lalu menyadarinya sepuluh menit kemudian dan mencabut aturannya. Browser pengunjung yang sudah menyimpannya tetap melompat ke alamat yang salah. Servernya sudah benar, tetapi pengunjungnya tidak pernah bertanya lagi ke server. Membersihkannya berarti meminta tiap pengunjung mengosongkan cache browsernya sendiri, sesuatu yang mustahil dikendalikan.
Ada dua cara menghindari kondisi itu, dan keduanya perlu diputuskan sebelum aturannya dipasang:
- Pakai 302 selama Anda masih ragu. Kode sementara tidak disimpan browser secara diam-diam, sehingga mencabutnya berlaku seketika. Naikkan ke 301 setelah struktur alamat benar-benar final.
- Batasi umur simpannya secara eksplisit. Kalau 301 memang harus dipasang sejak awal, sertakan header
Cache-Control: max-age=3600supaya browser hanya menyimpannya satu jam alih-alih menebak sendiri berapa lama.
Untuk menguji ulang aturan yang sudah tersimpan, buka alamatnya lewat jendela penyamaran atau langsung dengan curl. Keduanya tidak membaca cache browser Anda, sehingga yang terlihat adalah balasan server yang sesungguhnya.
Redirect di Mata Mesin Pencari: Angka yang Perlu Dipegang
Satu anggapan lama perlu diluruskan lebih dulu. Anggapan bahwa 301 "mewariskan nilai SEO" sementara 302 "membuangnya" sudah tidak berlaku sejak 26 Juli 2016. Pada tanggal itu Gary Illyes dari Google menyatakan pengalihan 30x apa pun tidak lagi menyusutkan PageRank. Alasan sesungguhnya memilih 301 bukan soal pewarisan nilai, melainkan soal kanonikalisasi. Kode 301 memberi tahu Google alamat mana yang harus dianggap sebagai versi resmi (canonical) sebuah halaman, sedangkan 302 tidak.
Google membagi kode pengalihan menjadi dua kelompok berdasarkan sinyal itu. Kelompok permanen berisi 301, 308, meta refresh nol detik, dan pengalihan lewat properti location JavaScript. Kelompok sementara berisi 302, 303, 307, dan meta refresh dengan jeda. Googlebot mengikuti keduanya, tetapi hanya kelompok pertama yang dipakai sebagai penanda halaman kanonik.
Selebihnya adalah angka yang bisa langsung Anda pegang:
- 10 hop — batas maksimal rantai pengalihan (redirect chain) yang diikuti Googlebot. Lewat dari itu, halamannya ditandai bermasalah dan tidak diindeks.
- Maksimal 3, dan harus di bawah 5 — jumlah lompatan yang disarankan Google kalau rantai memang tidak terhindarkan. Idealnya nol: alihkan langsung ke tujuan akhir.
- Minimal 1 tahun — lama redirect sebaiknya dipertahankan setelah pemindahan alamat, sesuai panduan resmi Google untuk perpindahan situs. Untuk alamat yang masih menerima kunjungan, biarkan permanen.
Rantai panjang muncul tanpa disadari karena aturan ditumpuk bertahun-tahun tanpa dirapikan. Contoh yang paling umum terjadi setelah migrasi HTTPS: http://situs.co.id melompat ke http://www.situs.co.id, lalu ke https://www.situs.co.id, baru ke halaman tujuan. Tiga lompatan untuk sesuatu yang seharusnya satu. Perbaikannya adalah menggabungkan aturan penyeragaman www dan aturan HTTPS menjadi satu aturan yang langsung menuju bentuk akhir.
Rantai redirect http ke www ke https butuh tiga lompatan; langsung ke tujuan cukup satu. Google menyarankan di bawah 3.
Memeriksa rantai bisa dilakukan tanpa alat khusus:
curl -sIL https://situsanda.co.id \
| grep -iE 'HTTP/|^location'Setiap pasang baris yang muncul mewakili satu lompatan. Kalau ada lebih dari dua pasang sebelum baris HTTP/2 200, rantai Anda layak dirapikan. Alat redirect checker daring mengerjakan hal yang sama dengan tampilan yang lebih rapi.
Cara Memasang Redirect di Hosting dan Server
Cara redirect domain ke domain lain, atau memindahkan satu halaman ke halaman lain, punya empat jalur. Urutannya di bawah dimulai dari yang paling tidak menuntut pengetahuan teknis.
Langkah #1: Lewat menu Redirects di cPanel
Cara paling aman untuk pemula: tidak ada berkas yang perlu disunting manual. Di dalam layanan web hosting berbasis cPanel, menu Redirects ada di grup Domains. Anda memilih domainnya, mengisi alamat asal dan alamat tujuan, memilih jenis Permanent (301) atau Temporary (302), lalu menyimpan. cPanel yang menuliskan aturannya ke berkas konfigurasi. Langkahnya kami bahas di panduan cara setting redirect melalui cPanel.
Langkah #2: Lewat berkas .htaccess
Untuk server Apache dan LiteSpeed, aturan ditulis di berkas .htaccess yang diletakkan di folder utama website. Bentuk paling sederhananya satu baris:
Redirect 301 /lama.html /baru.htmlUntuk pengalihan berpola — misalnya memaksa seluruh alamat ke HTTPS — dibutuhkan modul rewrite:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ \
https://%{HTTP_HOST}/$1 [R=301,L]Penanda R=301 menentukan kodenya dan L menghentikan pemrosesan aturan berikutnya. Dua kebutuhan paling umum adalah pengalihan ke HTTPS dan penyeragaman alamat dengan atau tanpa www. Langkahnya kami bahas di panduan redirect HTTP ke HTTPS dan redirect www ke non-www.
Langkah #3: Lewat konfigurasi Nginx
Nginx tidak membaca .htaccess, jadi aturannya ditulis di blok server dan server perlu dimuat ulang setelahnya:
server {
listen 80;
server_name lama.co.id;
return 301 https://baru.co.id$request_uri;
}Variabel $request_uri membawa serta sisa alamatnya, sehingga lama.co.id/artikel mendarat di baru.co.id/artikel, bukan di halaman depan.
Langkah #4: Lewat domain manager atau plugin
Kalau yang dipindahkan adalah seluruh domainnya dan domain lama tidak punya hosting sama sekali, pengalihan bisa diatur dari panel pengelolaan domain tanpa menyewa hosting untuk domain itu. Langkahnya ada di panduan redirect domain melalui domain manager. Untuk pemindahan alamat di dalam satu situs WordPress, plugin pengalihan lebih praktis karena bisa memetakan pola alamat lama ke pola baru sekaligus. Kasus paling umumnya adalah setelah struktur permalink atau slug diubah.
Ketika Redirect Bermasalah: Loop, Rantai, dan Redirect Notice
Tiga gejala berikut sering dianggap satu masalah yang sama, padahal penyebab dan penanganannya berbeda.
Redirect loop terjadi ketika alamat A mengalihkan ke B dan B mengalihkan balik ke A, sehingga tidak pernah ada halaman yang benar-benar terkirim. Browser memutus rantai itu sendiri lalu menampilkan galat too many redirects — di Chrome tertulis ERR_TOO_MANY_REDIRECTS, di peramban lain berbunyi senada. Batas pemutusnya 20 lompatan pada Chromium maupun Firefox, sementara curl berhenti di lompatan ke-50 dengan pesan Maximum (50) redirects followed.
Penyebab paling sering di Indonesia adalah kombinasi Cloudflare dan pemaksaan HTTPS di sisi server. Dalam mode SSL Flexible, Cloudflare menghubungi server asal lewat HTTP biasa. Kalau server asal punya aturan yang memaksa setiap permintaan HTTP menjadi HTTPS, permintaan Cloudflare ikut dialihkan, lalu Cloudflare menghubunginya lagi lewat HTTP, begitu seterusnya. Dokumentasi Cloudflare menyatakannya tegas: jangan gunakan mode Flexible kalau server asal memaksa HTTPS. Perbaikannya adalah menaikkan mode SSL ke Full atau Full (strict).
Redirect loop muncul saat CDN mode Flexible memanggil server yang memaksa HTTPS; browser berhenti di lompatan ke-20.
Rantai yang terlalu panjang bukan galat — halamannya tetap terbuka. Setiap lompatan menambah satu perjalanan bolak-balik ke server, dan pada koneksi seluler yang tersendat tiga lompatan berarti waktu tunggu yang terasa. Cara mendeteksinya sudah dijelaskan di bagian sebelumnya.
Redirect Notice sama sekali bukan masalah pada website Anda. Ini halaman antara milik Google yang muncul dengan alamat berpola google.com/url?q= ketika Anda mengklik tautan keluar. Google memakainya untuk memeriksa alamat tujuan lebih dulu; kalau aman pengunjung diteruskan otomatis, kalau mencurigakan barulah peringatan ditampilkan. Tidak ada yang perlu diperbaiki dari sisi pemilik situs.
Sisi Lain Redirect yang Perlu Anda Pertimbangkan
Redirect memecahkan masalah nyata, tetapi ia bukan tindakan tanpa konsekuensi.
- Setiap pengalihan menambah waktu tunggu. Satu lompatan berarti satu perjalanan tambahan ke server sebelum isi halaman mulai dikirim. Pada satu atau dua lompatan efeknya kecil, tetapi ia menumpuk dan paling terasa di jaringan seluler.
- Aturan yang menumpuk tanpa catatan sulit dibongkar. Setelah beberapa tahun, berkas konfigurasi bisa berisi puluhan aturan yang tidak jelas lagi asal-usulnya. Karena aturan lama tidak boleh sembarangan dihapus, biasakan mencatat tanggal dan alasannya sebagai komentar di sebelah tiap aturan.
- Pengalihan yang tujuannya diatur pengunjung bisa disalahgunakan. Kalau situs Anda punya alamat seperti
situsanda.co.id/go?url=yang meneruskan ke alamat mana pun yang diisikan di parameternya, penyerang bisa memasang alamat situs palsu di sana. Yang terlihat calon korban adalah tautan bernama domain Anda yang tepercaya, padahal ujungnya halaman phising.
Kelemahan ketiga itu punya nama resmi: open redirect. Ia terdaftar sebagai CWE-601 di katalog kerentanan MITRE, dan dipetakan ke kategori A01 (Broken Access Control) pada OWASP Top Ten 2021 dan 2025. MITRE menyarankan tiga mitigasi yang sebaiknya dipakai berlapis. Saring tujuan dengan daftar alamat yang diizinkan, ganti parameter alamat dengan ID tetap yang menunjuk ke tujuan yang sudah disetujui, dan tampilkan halaman peringatan sebelum pengunjung diteruskan keluar. Pendekatan ketiga itulah yang Anda lihat sebagai Redirect Notice milik Google.
Pertanyaan yang Sering Muncul
Apa bedanya redirect domain dan domain alias?
Redirect domain memindahkan pengunjung, sehingga alamat di bilah browser berubah menjadi domain tujuan. Domain alias tidak memindahkan siapa pun — dua domain berbeda menyajikan isi yang sama dan alamat yang diketik pengunjung tetap tampil apa adanya. Istilah lain yang sering tertukar, yaitu park, point, dan addon domain, kami bandingkan di panduan park domain.
Apakah redirect membuat website jadi lambat?
Satu pengalihan menambah kira-kira satu perjalanan bolak-balik ke server, umumnya puluhan hingga ratusan milidetik. Angka itu tidak terasa oleh pengunjung. Yang terasa adalah rantai berlapis, jadi jaga jumlah lompatan tetap di bawah tiga.
Bisakah domain dialihkan tanpa menyewa hosting?
Bisa, lewat panel pengelolaan domain. Pengalihannya ditangani di sisi penyedia, sehingga domain itu tidak membutuhkan ruang hosting sendiri.
Apa arti tulisan "redirecting" yang muncul sekilas di layar?
Itu tanda pengalihan dipasang di lapis HTML atau JavaScript, bukan di lapis HTTP. Halamannya sudah terkirim lebih dulu, lalu browser diperintahkan berpindah — karena itu tulisannya sempat terlihat. Pesan sejenis seperti "please wait, redirecting" atau "redirect occurred" artinya sama saja.
Apakah redirect bisa dipakai untuk menyembunyikan alamat asli?
Tidak. Redirect justru mengubah alamat di bilah browser menjadi alamat tujuan. Teknik yang menahan alamat asal tetap tampil adalah URL masking, yang bekerja dengan membingkai halaman tujuan di dalam halaman asal — cara kerja dan keterbatasannya berbeda sama sekali.
Berapa lama redirect perlu dibiarkan aktif?
Google menyarankan minimal satu tahun setelah pemindahan alamat. Untuk alamat lama yang masih menerima kunjungan atau masih ditautkan situs lain, biarkan aktif seterusnya.
Kesimpulan
Redirects adalah instruksi pindah alamat yang dikirim server sebelum halaman terkirim, dan memilih kodenya cukup dijawab dengan dua pertanyaan: apakah perpindahannya permanen, dan apakah method permintaan harus dipertahankan. Untuk halaman biasa yang sudah final, 301 adalah jawabannya; selama struktur alamat masih mungkin berubah, 302 lebih aman karena tidak menempel di browser pengunjung. Untuk alamat yang menerima kiriman formulir atau dipakai sebagai endpoint API, 308 dan 307 yang menjaga datanya tetap utuh.
Selebihnya soal kerapian. Alihkan langsung ke tujuan akhir, jaga rantai tetap di bawah tiga lompatan, dan catat alasan tiap aturan. Jangan pernah membiarkan alamat tujuan ditentukan dari parameter yang bisa diisi siapa saja. Semoga artikel ini membantu.
