Redirect 302

TL;DR — Redirect 302 mengirim pengunjung dari satu URL ke URL lain secara sementara. Kode ini memberi tahu mesin pencari, “perpindahan ini tidak permanen — pertahankan URL asli di hasil pencarian.” Gunakan saat maksud Anda memang sementara (uji A/B, halaman promo, atau pemberitahuan pemeliharaan). Gunakan 301 jika Anda memindahkan halaman untuk selamanya.

Apa itu redirect 302

Redirect adalah instruksi yang mengirim siapa pun yang meminta satu URL ke URL lain. Saat server menjawab permintaan, respons itu mencakup kode status HTTP—angka tiga digit yang menjelaskan apa yang terjadi. 302 adalah salah satu kode pengalihan. Nama resminya “302 Found,” (terjemahan) “302 Ditemukan,” dan sifat utamanya dapat diringkas dalam satu kata: sementara.

Bagian “sementara” itu adalah intinya. 302 berkata: halaman ini berpindah untuk sementara, tetapi URL asli akan kembali. Karena itu, mesin pencari seharusnya mempertahankan URL asli di hasilnya dan memperlakukan tujuan sebagai pengganti sementara, bukan pengganti permanen.

Bandingkan dengan saudara permanennya, redirect 301, yang mengatakan “perpindahan ini selamanya — indeks URL baru.” Pengalaman pengunjung sama (keduanya mengirim Anda ke halaman baru), tetapi pesannya kepada mesin pencari berlawanan.

Kapan Anda benar-benar menggunakannya

302 adalah alat yang tepat ketika perpindahannya benar-benar singkat:

• Anda menjalankan uji A/B dan mengirim sebagian pengunjung ke variasi halaman.
• Anda memiliki halaman promo sementara dan akan mengembalikannya setelah promo selesai.
• Halaman sedang tidak tersedia untuk pemeliharaan, dan Anda ingin menampilkan pemberitahuan “segera kembali” (terjemahan) “segera kembali” tanpa menyerahkan posisi URL asli di penelusuran.
• Anda merutekan pengunjung berdasarkan lokasi atau perangkat (misalnya ke versi negara atau bahasa tertentu), sehingga tujuan yang tepat berubah untuk tiap pengunjung.

Dalam semua kasus ini, Anda ingin URL asli tetap berada di hasil Google—dan itulah yang diminta oleh redirect 302.

Hal yang paling sering disalahpahami

Selama bertahun-tahun, para SEO menganggap 302 berbahaya — “redirect ini tidak meneruskan nilai tautan, jangan pernah menggunakannya.” Itu mitos. Redirect 302 tetap meneruskan sinyal tautan; perbedaannya dari 301 hanya URL mana yang lebih dipilih mesin pencari untuk ditampilkan. John Mueller dari Google mengatakan bahwa 302 “memiliki reputasi buruk di kalangan SEO, padahal menurut saya itu keliru.”

Kesalahan sebenarnya bukan menggunakan 302, melainkan menggunakan 302 untuk perpindahan permanen. Jika Anda menghapus halaman secara permanen tetapi mengalihkannya dengan 302, Anda memberi tahu Google “pertahankan URL lama tetap terindeks,” (terjemahan) “pertahankan URL lama tetap terindeks,” sehingga halaman baru yang sebenarnya ingin Anda rangking mungkin tidak mengambil alih dalam waktu lama yang tidak dapat diprediksi. Untuk perpindahan selamanya, gunakan 301.

Ingin mekanisme yang tepat—bahasa Google tentang “sinyal lemah vs. kuat” (terjemahan) “sinyal lemah vs. kuat”, alasan 302 yang bertahan lama dapat berbalik dan bertindak seperti 301, serta cara Bing menanganinya? Buka tab Advanced.

TL;DR — 302 (“Found”) adalah redirect sementara. Kerangka Google yang tepat memiliki dua tahap, bukan satu: infrastruktur perayapan menyebutnya sinyal lemah bahwa target redirect harus diproses, berbeda dari sinyal kuat pada 301. Secara terpisah, pipeline pengindeksan Search tidak memakai redirect sementara sebagai sinyal bahwa target harus menjadi kanonik (target tetap dapat diindeks melalui sinyal lain). Dua mekanisme sering tercampur: penerusan sinyal tautan/PageRank (Mueller dan Illyes mengatakan nilainya tidak nol pada 302, tetapi itu pernyataan publik, bukan aturan universal yang diterbitkan secara formal) serta preferensi kanonikalisasi/pengindeksan (inilah yang benar-benar berbeda—302 memberi tahu Google untuk mempertahankan URL sumber di indeks). Jika dibiarkan cukup lama, 302 dapat “berbalik”—pola yang diamati praktisi, bukan mekanisme terdokumentasi dan tanpa jadwal yang dipublikasikan. Google merekomendasikan 302, bukan 301, untuk pengujian A/B. Kesalahan nyata adalah memakai 302 untuk perpindahan permanen; jangan pernah membangun tujuan redirect dari input pengguna yang belum diperiksa.

”Moved Temporarily” (terjemahan) “Dipindahkan Sementara” → “Found” (terjemahan) “Ditemukan” — sejarah singkat

302 lahir dengan makna yang ambigu. Dalam HTTP/1.0, kode ini disebut “Moved Temporarily,” (terjemahan) “Dipindahkan Sementara,” dan spesifikasi menyatakan bahwa client harus memakai kembali metode permintaan asli saat mengikutinya. Dalam praktiknya, browser tidak selalu begitu—banyak yang diam-diam mengubah POST menjadi GET saat redirect, bertentangan dengan spesifikasi. HTTP/1.1 mengakui kenyataan itu dengan mengganti nama 302 menjadi “Found” (terjemahan) “Ditemukan” dan menambahkan dua alternatif yang tidak ambigu: 303 (See Other), yang selalu beralih ke GET, serta 307 (Temporary Redirect), yang tidak pernah mengubah metode. Spesifikasi saat ini, RFC 9110 (2022), masih mencatat bahwa client boleh mengubah POST menjadi GET pada 302—tepat alasan 307 ada untuk kasus yang melarang perubahan itu. Untuk redirect halaman berbasis GET sehari-hari (kasus SEO), 302 dan 307 berperilaku sama bagi mesin pencari; perbedaan pelestarian metode hanya penting pada pengiriman formulir dan panggilan API. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

Untuk keperluan penelusuran, Google mengelompokkan 302 (ditemukan), 303 (lihat lainnya), dan 307 (temporary redirect) sebagai “Temporary,” (terjemahan) “Sementara,” berlawanan dengan 301 dan 308 sebagai “Permanent.” (terjemahan) “Bersifat permanen, bukan sementara.”

Keputusan ringkas jika Anda harus memilih di antaranya:

• 302—client yang mengikuti redirect dapat mengubah POST menjadi GET (RFC 9110). Ini cocok untuk redirect halaman biasa berbasis GET; hindari jika perubahan metode tidak dapat ditoleransi.
• 307—tidak pernah mengubah metode atau mengirim ulang permintaan yang berbeda. Gunakan saat pengiriman formulir atau panggilan API harus diputar ulang persis seperti dikirim.
• 303—sengaja menunjuk ke resource yang berbeda dan tidak ekuivalen, biasanya diambil dengan GET/HEAD—pola klasik “redirect setelah POST ke halaman konfirmasi”, bukan pengganti setara untuk permintaan asli.
• Caching—302 tidak otomatis dapat di-cache secara heuristik hanya karena kode statusnya (RFC 9111); kode ini disimpan/digunakan ulang hanya jika Anda menetapkan freshness atau direktif cache secara eksplisit. Jangan menganggap CDN atau browser akan meng-cache 302 polos secara default.

Sinyal lemah vs. sinyal kuat — istilah tepat dari Google

Lewati cerita rakyat dan baca bahasa Google yang sebenarnya. Dalam dokumentasi infrastruktur perayapannya, Google menyebut 302 sebagai sinyal lemah:

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (terjemahan) “Secara default, crawler Google mengikuti redirect, dan sistem Google menggunakan redirect sebagai sinyal lemah bahwa target redirect harus diproses.”

Baris 301 pada tabel yang sama identik kecuali satu kata—strong:

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (terjemahan) “Google mengikuti redirect, dan sistem Google menggunakan redirect sebagai sinyal kuat bahwa target redirect harus diproses.”

“Weak” (terjemahan) “lemah” tidak berarti “zero” (terjemahan) “nol”—tetapi kita harus tepat tentang apa yang lemah. Kedua pernyataan itu berasal dari sistem Google yang berbeda dan membahas dua tahap, bukan satu rangkaian:

• Infrastruktur perayapan (kutipan “weak signal” (terjemahan) “sinyal lemah” di atas) membahas apakah target redirect diproses—pada dasarnya, apakah crawler Google mengambil dan meninjau tujuannya.
• Pipeline pengindeksan Search adalah tahap terpisah yang datang kemudian. Aturannya berbunyi: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (terjemahan) “Googlebot mengikuti redirect, tetapi pipeline pengindeksan tidak memakai redirect sebagai sinyal bahwa target redirect harus menjadi kanonik. Halaman target tetap dapat diindeks jika ada sinyal kanonikalisasi lain.” Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search Google: Website testing

Jika dibaca bersama, 302 memberi Google dorongan lemah untuk melihat target (perayapan), tetapi pipeline pengindeksan Search tidak memperlakukan redirect yang sama sebagai suara untuk menjadikan target kanonik. Target tetap dapat berakhir terindeks dan kanonik karena sinyal lain, bukan karena 302 itu sendiri. Jangan menyederhanakannya menjadi “302 adalah suara lemah agar target menjadi kanonik”—kedua dokumentasi itu menjelaskan cakupan yang berbeda.

Dua mekanisme, bukan satu

Di sinilah banyak artikel mencampuradukkan hal yang berbeda, jadi pisahkan keduanya:

1. Penerusan sinyal tautan/PageRank tidak nol pada 302. Gary Illyes mengatakan pada 2016 bahwa Google tidak lagi menerapkan pengenceran PageRank pada redirect 301, 302, atau 30x lainnya (mengakhiri kepercayaan lama tentang “kehilangan ~15% per hop”), dan Mueller menyampaikan hal yang sama khusus untuk 302: “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (terjemahan) “berfungsi sama seperti redirect biasa… bukan berarti redirect itu tidak meneruskan PageRank atau apa pun.” Perlakukan ini sebagai pernyataan publik Google tentang pertanyaan tersebut, bukan jaminan universal yang diterbitkan secara formal — dokumentasi utama saat ini tidak merinci aturan pemindahan sinyal tautan yang tepat untuk setiap jenis redirect dalam setiap situasi.
2. Preferensi kanonikalisasi/pengindeksan adalah mekanisme yang benar-benar berbeda. 301 merupakan sinyal kuat untuk mengindeks tujuan; 302 merupakan sinyal lemah, sehingga default Google adalah tetap mengindeks sumber.

“Apakah 302 meneruskan PageRank?” dan “apakah 302 mengubah URL yang mendapat peringkat?” adalah dua pertanyaan berbeda. Jawaban pertama ya; jawaban kedua “tidak secara default.” Mencampur keduanya melahirkan mitos “302 = nol ekuitas”.

Terkait hal ini: saat Anda me-redirect URL, Google melacak kedua ujungnya. “Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” (terjemahan) “Google melacak sumber redirect (URL lama) dan target redirect (URL baru). Salah satu URL akan menjadi kanonik; pilihannya bergantung pada sinyal seperti apakah redirect bersifat sementara atau permanen. URL lainnya menjadi nama alternatif untuk URL kanonik.” Untuk 302, sumber tetap kanonik—setidaknya sebagai default saat ini. Evidence for this claim A 302 expresses temporary intent, but it does not guarantee that the source URL will always remain Google's selected canonical or that the target cannot index through other signals. Scope: redirect crawling, indexing, and canonicalization Confidence: high · Verified: 2026-07-16 Redirects and Google Search

Jika 302 dibiarkan terlalu lama — “flip” (terjemahan) “berbalik”

Bagian yang mengejutkan: redirect sementara yang tidak pernah dihapus dapat berhenti diperlakukan sebagai redirect sementara. Mueller berkata: “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (terjemahan) “jika Anda memiliki redirect 302 dalam jangka panjang, kami memperlakukannya persis seperti redirect 301.”

Mengapa itu terjadi? Ini adalah penjelasan kerja saya dari panduan kanonikalisasi Ahrefs —model mental praktisi yang dibangun dari perilaku teramati, bukan mekanisme yang dipublikasikan Google secara formal. Bayangkan sebuah timbangan: redirect permanen mengirim sinyal maju ke URL baru, sedangkan redirect sementara mengirim sinyal mundur ke URL asli. Namun:

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (terjemahan) “Jika redirect sementara dibiarkan cukup lama atau URL yang dituju sudah ada, redirect itu dapat diperlakukan sebagai redirect permanen dan mengirim sinyal ke depan. Diperlukan cukup banyak sinyal untuk membalik timbangan sinyal kanonikalisasi. Saat tautan bertambah, tautan internal diubah, URL sitemap diperbarui, dan seterusnya, lebih banyak sinyal menunjuk ke URL baru daripada URL lama, lalu pembalikan terjadi.”

Masalahnya: tidak ada yang tahu berapa lama proses itu berlangsung. Seperti yang saya tulis dalam panduan redirect, “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (terjemahan) “Tidak ada yang tahu berapa lama redirect 302 harus ada sebelum Google mulai memperlakukannya sebagai redirect 301. Biasanya beberapa minggu hingga beberapa bulan, tetapi bisa juga berhari-hari, berminggu-minggu, atau berbulan-bulan.” Google dapat bertindak lebih cepat jika mengira Anda melakukan kesalahan: “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (terjemahan) “Hal ini tidak terjadi hanya jika Google menganggap Anda keliru memakai redirect 302 untuk perpindahan permanen. Dalam kasus itu, redirect diperlakukan sebagai 301… Dalam beberapa keadaan, Google bahkan tampak memperlakukan 302 sebagai 301 sejak awal.” Jangan mengutip jumlah hari tertentu—tidak ada angka yang diterbitkan, dan angka apa pun yang beredar (termasuk “2 hari” dalam cerita rakyat Bing) belum dikonfirmasi Google.

Cara Bing memperlakukan 302 — mengamati perilaku, bukan hanya header

Bing mencapai kesimpulan yang sama melalui jalur yang sedikit berbeda, dan menyatakannya secara eksplisit. Dalam penjelasan lamanya tentang redirect, Bing menggambarkan pengamatan terhadap pola redirect selama perayapan berulang, bukan hanya mempercayai kode status: redirect yang terus mengubah tujuan diperlakukan lebih seperti 302 meskipun berlabel 301, sedangkan redirect yang selalu menunjuk tempat sama diperlakukan lebih seperti 301 meskipun berlabel 302—sistem Bing mulai “menganggapnya lebih seperti 301 saat kami terus merayapinya berulang kali.” (terjemahan) “menganggapnya lebih seperti 301 saat kami terus merayapinya berulang kali.” Ini adalah konvergensi yang sama seperti penjelasan Google, tetapi dicapai secara independen: setelah perilaku konsisten cukup lama, kedua mesin lebih mempercayai apa yang dilakukan redirect daripada klaim headernya.

Panduan lama Bing juga lebih menekankan “use 302 sparingly” (terjemahan) “gunakan 302 secukupnya” daripada Google saat ini, serta memperingatkan bahwa 302 yang disalahgunakan dapat meninggalkan nilai pada URL asli. Pelajaran praktisnya sama dengan Google: sesuaikan jenis redirect dengan maksud Anda yang sebenarnya.

Kapan 302 merupakan pilihan yang tepat

Google tidak sekadar menoleransi 302—untuk satu kasus, Google justru merekomendasikannya. Dari panduan pengujian A/B:

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (terjemahan) “Jika Anda menjalankan pengujian yang mengalihkan pengguna dari URL asli ke URL variasi, gunakan redirect 302 (sementara), bukan redirect 301 (permanen). Ini memberi tahu mesin pencari bahwa redirect ini sementara—hanya ada selama eksperimen berlangsung—dan URL asli harus tetap di indeks, bukan digantikan oleh target redirect (halaman pengujian). Redirect berbasis JavaScript juga boleh.”

Kasus penggunaan yang sah (semuanya benar-benar sementara):

• Pengujian A/B—rekomendasi eksplisit Google di atas. Namun, jangan memperpanjangnya: Google memperingatkan bahwa “if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (terjemahan) “jika kami menemukan situs menjalankan eksperimen terlalu lama tanpa alasan, kami dapat menafsirkannya sebagai upaya menipu mesin pencari dan mengambil tindakan yang sesuai.” Jalankan selama diperlukan untuk mencapai signifikansi, lalu hapus.
• Perutean geografis, perangkat, dan bahasa—tujuan yang “tepat” bergantung pada pengunjung, dan tidak ada satu URL yang boleh menggantikan sumber secara permanen. Ini memerlukan lebih dari sekadar memilih kode status: pastikan ke mana Googlebot diarahkan (biasanya tidak membawa sinyal lokasi/perangkat pengunjung nyata, jadi periksa apa yang disajikan aturan Anda kepadanya), apakah perutean bergantung pada cookie atau header yang tidak dikirim crawler, apakah kunci cache dan header Vary memisahkan varian dengan benar (agar cache tidak menyajikan halaman satu negara kepada negara lain), apakah pembaca layar atau pengunjung tanpa JavaScript tetap dapat mencapai konten, dan apakah pengunjung dapat membatalkan perutean otomatis alih-alih terjebak dalam loop redirect. Padukan dengan hreflang yang tepat pada versi terlokalisasi—redirect dan hreflang harus selaras, bukan saling bertentangan.
• Halaman pemeliharaan sementara/layanan tidak tersedia—contoh dari Google sendiri: “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” (terjemahan) “jika layanan di situs Anda sedang tidak tersedia, Anda dapat menyiapkan redirect sementara ke halaman yang menjelaskan situasinya tanpa mengorbankan URL asli di hasil pencarian.” Pikirkan keadaan yang benar-benar Anda hadapi. Jika URL itu sendiri tidak dapat dilayani sekarang (backend mati atau Anda sedang melakukan deployment), 503 Service Unavailable dengan header Retry-After pada URL yang sama sering lebih tepat—respons ini mengatakan “permintaan sementara tidak dapat dipenuhi, coba lagi nanti” tanpa mengarahkan ke mana pun. Pilih 302 saat Anda sengaja mengarahkan pengunjung ke URL penjelasan berbeda yang benar-benar berguna (halaman status atau halaman “kami akan segera kembali” dengan detail), bukan sekadar menandai URL asli tidak tersedia.
• Promosi berbatas waktu—kirim pengunjung ke halaman kampanye selama masa promosi, lalu kembalikan.
• Penyeimbangan beban/failover—arahkan traffic ke tempat lain saat origin atau pusat data sementara tidak tersedia.

Lihat tab Examples untuk contoh berdampingan yang diberi anotasi, dan tab Checklists untuk pemeriksaan awal.

Satu kesalahan yang benar-benar merugikan

Menggunakan 302 saat maksud Anda adalah perpindahan permanen. Anda memberi tahu Google untuk mempertahankan URL lama tetap terindeks, sehingga halaman baru yang ingin Anda peringkatkan mungkin tidak mengambil alih selama jangka waktu yang tidak pasti—kerugian visibilitas yang nyata, bukan teoritis. Jika halaman sudah hilang untuk selamanya, gunakan 301 (atau 308). Kesalahan terkait lainnya adalah mencampur 301 dan 302 secara tidak konsisten di dalam rantai redirect, atau—sebagai mode kegagalan redirect apa pun—tanpa sengaja menunjuk dua URL satu sama lain dan membuat loop.

Menerapkan 302

Header-lah yang penting—baris status 302 Found dan sebuah Location. Contoh PHP dari Google:

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (.htaccess) —flag R=302 yang membuatnya sementara (R=301 atau R tanpa angka akan default ke permanen):

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx—redirect mengeluarkan 302 (permanent akan mengeluarkan 301):

location = /old-path {
    return 302 https://www.example.com/newurl;
}

Apa pun stack-nya (plugin redirect WordPress, aturan CDN/edge, atau handler tingkat aplikasi), aturannya sama: redirect sisi server lebih disukai, dan Anda harus memilih kode sementara dengan sengaja—sebagian besar alat default ke 301, sehingga 302 biasanya harus ditetapkan secara eksplisit.

Satu catatan keamanan yang berlaku untuk redirect apa pun, bukan hanya 302: jika tujuan pada header Location Anda pernah dibangun dari input yang dikendalikan pengguna (misalnya parameter kueri ?next= atau ?returnUrl=), Anda memiliki bahan untuk open redirect—penyerang dapat membuat tautan di domain Anda yang justru memantulkan pengunjung ke tempat berbahaya. Jangan mengirim pengunjung ke URL apa pun yang muncul dalam parameter permintaan; gunakan allowlist untuk tujuan yang benar-benar boleh Anda redirect (kumpulan path atau origin aman yang tetap), lalu uji bagaimana logika redirect menangani input terenkode dan scheme-relative (//evil.example, %2F%2Fevil.example, serta trik serupa) sebelum mempercayainya di produksi. Cocokkan sintaks cuplikan persis setiap platform dengan versinya saat ini sebelum shipping—contoh di atas hanya ilustrasi, bukan pengganti pengujian pada server/CDN Anda sendiri.

Untuk pasangan perpindahan permanen dan perbandingan lengkap, lihat artikel saudara tentang redirect 301, 301 vs 302, serta 302 vs 307 dalam cluster ini.

AI summary

Ringkasan padat dari versi Advanced:

• 302 (“Found”) adalah redirect sementara (status HTTP 302). Kode ini meneruskan pengguna ke URL baru sambil memberi sinyal bahwa URL asli harus tetap berada di hasil pencarian.
• Kerangka Google yang tepat terbagi menjadi dua tahap, bukan satu rangkaian. Infrastruktur perayapan menyebut 302 sinyal lemah bahwa target harus diproses (diambil dan diperiksa), berlawanan dengan sinyal kuat pada 301. Secara terpisah, pipeline pengindeksan Search mengatakan redirect sementara bukan sinyal bahwa target harus menjadi kanonik, meskipun target masih dapat diindeks melalui sinyal lain. Lemah ≠ nol, dan “diproses” ≠ “dijadikan kanonik”.
• 302 vs. 303 vs. 307 secara ringkas: client dapat mengubah metode 302 dari POST→GET; 307 tidak pernah mengubah metode; 303 sengaja menunjuk ke resource berbeda yang tidak ekuivalen. Tidak satu pun yang dapat di-cache secara heuristik secara default—caching memerlukan direktif eksplisit.
• Penerusan sinyal tautan tidak nol pada 302—Mueller dan Illyes sama-sama pernah mengatakannya—tetapi itu pernyataan publik mereka, bukan aturan universal pemindahan yang diterbitkan secara formal untuk setiap skenario redirect. Preferensi kanonikalisasi/pengindeksan adalah mekanisme yang benar-benar berbeda: 301 mendorong pengindeksan ke tujuan; 302 tetap di sumber secara default.
• 302 yang berlangsung lama dapat “berbalik”. Ini pola yang diamati praktisi (Mueller dan pengalaman saya sendiri), bukan mekanisme terdokumentasi dengan jadwal terbitan—“hari, minggu, atau bulan”, tanpa angka tetap.
• Bing mengamati perilaku, bukan hanya header: redirect yang konsisten dalam perayapan berulang dapat diklasifikasikan ulang terlepas dari kode status—konvergensi yang sama seperti yang dijelaskan Google.
• Google merekomendasikan 302 (bukan 301) untuk pengujian A/B. Penggunaan sah lainnya: perutean geografis/perangkat/bahasa (periksa perlakuan Googlebot, cookie, perilaku Vary/cache, aksesibilitas, dan padukan dengan hreflang), halaman pemeliharaan sementara (bandingkan dengan 503 + Retry-After saat URL yang sama tidak dapat dilayani), promo berbatas waktu, serta penyeimbangan beban/failover. Jangan menjalankan uji A/B “terlalu lama tanpa alasan”—Google dapat membacanya sebagai tindakan menipu.
• Keamanan: jangan pernah membangun tujuan Location langsung dari input pengguna—gunakan allowlist untuk mencegah open redirect.
• Kesalahan nyata satu-satunya: menggunakan 302 untuk perpindahan permanen—URL lama dapat tetap mendapat peringkat alih-alih yang baru tanpa batas. Gunakan 301 untuk perpindahan selamanya.

Dokumentasi resmi

Dokumentasi sumber utama dari mesin pencari dan spesifikasi HTTP.

Google

• Redirect dan Google Search —tabel jenis redirect (permanen vs. sementara), rekomendasi “keep the old URL in Search results” (terjemahan) “pertahankan URL lama di hasil Search”, pelacakan URL alternatif, dan contoh implementasi PHP.
• How HTTP Status Codes Affect Google’s Crawlers —tabel 3xx dengan bahasa persis “weak signal” (terjemahan) “sinyal lemah” (302) vs. “strong signal” (terjemahan) “sinyal kuat” (301).
• Praktik terbaik pengujian A/B untuk Search —rekomendasi eksplisit Google “use a 302, not a 301” (terjemahan) “gunakan 302, bukan 301” untuk pengujian, serta peringatan agar eksperimen tidak berjalan “unnecessarily long time.” (terjemahan) “terlalu lama tanpa alasan.”

Bing / Microsoft

• Managing redirects — 301s, 302s dan canonicals (Bing Webmaster Blog) —penjelasan Bing tentang perbedaan 301/302 dan posisinya “we watch the behavior, not just the header” (terjemahan) “kami mengamati perilaku, bukan hanya header”. (Unggahan live dirender dengan JavaScript; teks verbatim dipertahankan di arsip Wayback Machine.)

HTTP spec / reference

• MDN — 302 Found dan 307 Temporary Redirect —nuansa pelestarian metode dan alasan 303/307 ada.
• RFC 9110 §15.4.3 (302 Found) —spesifikasi HTTP Semantics saat ini; mencatat bahwa client masih dapat mengubah POST→GET pada 302.

Kutipan dari sumber

Pernyataan yang tercatat dari Google dan Bing. Setiap tautan dokumentasi penelusuran langsung menuju bagian yang dikutip pada halaman sumber.

Google — perbedaan sinyal lemah dan kuat (tulang punggung akurasi)

• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (terjemahan) “Secara default, crawler Google mengikuti redirect, dan sistem Google menggunakan redirect sebagai sinyal lemah bahwa target redirect harus diproses.”—pada 302. Jump untuk quote
• “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (terjemahan) “Google mengikuti redirect, dan sistem Google menggunakan redirect sebagai sinyal kuat bahwa target redirect harus diproses.”—baris 301 pembanding pada tabel yang sama. Jump untuk quote
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (terjemahan) “Googlebot tetap mengikuti redirect; pipeline pengindeksan tidak menjadikannya sinyal untuk menetapkan target sebagai kanonik. Target masih dapat diindeks bila ada sinyal kanonikalisasi lain.” Jump untuk quote

Google — kapan menggunakan redirect sementara

• “If you just want to send users to a different page temporarily, use a temporary redirect. This will also ensure that Google isn’t influenced by the redirect which may help keep the old URL in its Search results.” (terjemahan) “Jika Anda hanya ingin mengirim pengguna ke halaman berbeda untuk sementara, gunakan redirect sementara. Ini juga memastikan Google tidak dipengaruhi redirect tersebut, yang dapat membantu mempertahankan URL lama di hasil Search.” Lompat ke kutipan
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” (terjemahan) “Saat Anda me-redirect URL, Google melacak sumber redirect (URL lama) dan target redirect (URL baru). Salah satu URL akan menjadi kanonik; pilihannya bergantung pada sinyal seperti apakah redirect sementara atau permanen.” Lompat ke kutipan

Google — pengujian A/B (302 direkomendasikan, tetapi jangan dibiarkan terlalu lama)

• “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (terjemahan) “Jika Anda menjalankan pengujian yang mengalihkan pengguna dari URL asli ke URL variasi, gunakan redirect 302 (sementara), bukan redirect 301 (permanen).” Jump untuk quote
• “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (terjemahan) “Jika kami menemukan situs menjalankan eksperimen terlalu lama tanpa alasan, kami dapat menafsirkannya sebagai upaya menipu mesin pencari dan mengambil tindakan yang sesuai.” Jump untuk quote

John Mueller, Google — meluruskan mitos “302 itu buruk”

• “302 redirects have a bad reputation among SEOs, which I think is incorrect. Because they do work the same as normal redirects as well. It’s not that they don’t pass any PageRank or anything like that. And if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (terjemahan) “Redirect 302 memiliki reputasi buruk di kalangan SEO, padahal menurut saya itu keliru. Redirect ini juga berfungsi sama seperti redirect biasa. Bukan berarti redirect tersebut tidak meneruskan PageRank atau apa pun. Jika Anda memakai redirect 302 dalam jangka panjang, kami memperlakukannya persis seperti redirect 301.” Baca transkripsinya

Bing / Microsoft — mengamati perilaku, bukan hanya header

• Bing mengatakan bahwa redirect diklasifikasikan ulang berdasarkan pola yang diamati dalam perayapan berulang: 301s yang tujuannya terus berubah dipandang lebih seperti 302s, sedangkan 302s yang selalu menunjuk ke tempat sama diperlakukan lebih seperti 301s. Arsip Bing merangkum pengamatan itu: “We sometimes see 301s changing destination each time we crawl them” (terjemahan) “Kami terkadang melihat 301s mengubah tujuan setiap kali kami merayapinya”; perlakuan dapat berubah “as we continue to crawl them again and again.” (terjemahan) “seiring kami terus merayapinya berulang kali.” Sumber arsip

301 atau 302? — checklist sebelum peluncuran

Jalankan pemeriksaan ini sebelum menerapkan redirect apa pun agar kode sesuai dengan maksud Anda:

• Apakah perpindahannya permanen? Jika URL lama tidak akan pernah kembali → 301 (atau 308), bukan 302.
• Apakah benar-benar sementara? (uji A/B, promo, pemeliharaan, perutean geografis/perangkat, failover) → 302 tepat.
• Apakah kodenya Anda tetapkan secara eksplisit? Sebagian besar alat default ke 301—pastikan 302 memang disengaja, bukan kecelakaan, dan sebaliknya.
• Uji A/B? Gunakan 302 (rekomendasi Google), dan rencanakan penghapusannya setelah uji mencapai signifikansi—jangan membiarkannya berjalan “terlalu lama tanpa alasan”.
• Gangguan sementara pada URL yang sama? Pertimbangkan 503; gunakan 302 saat Anda mengarahkan ke halaman penjelasan berbeda.
• Tanpa rantai redirect yang mencampur 301 dan 302 secara tidak konsisten—arahkan langsung ke tujuan akhir.
• Tanpa loop—periksa ulang agar dua URL tidak saling mengarahkan.
• Jika 302 “sementara” diam-diam menjadi permanen, ubah ke 301 agar sinyal sesuai kenyataan (jangan mengandalkan “pembalikan” dengan jadwal Google yang tidak diketahui).
• Verifikasi kode status aktual yang dikembalikan (curl -I, alat pengembang browser, atau pemeriksa redirect) —label plugin redirect bukan bukti header yang dikirim.

Contoh penggunaan 302 yang sah, dengan anotasi

Lima situasi ketika 302 merupakan pilihan yang tepat—dan mengapa sinyal “temporary” (terjemahan) “sementara” penting pada masing-masing situasi.

1. Pengujian A/B

GET /pricing/           → 302 → /pricing/variant-b/

Anda mengirim sebagian traffic ke variasi untuk mengukurnya. Anda ingin /pricing/—URL asli—tetap terindeks dan mempertahankan peringkat; variasi hanya sementara. Inilah kasus yang secara eksplisit direkomendasikan Google untuk 302. Hapus redirect segera setelah pengujian selesai; pengujian yang dibiarkan tanpa batas dapat dianggap menipu.

2. Penjualan atau promosi sementara

GET /shoes/             → 302 → /promo/summer-sale-shoes/

Selama kampanye berlangsung, pengunjung tiba di halaman penjualan—tetapi /shoes/ adalah URL evergreen Anda dan seharusnya merebut kembali posisinya saat promosi berakhir. 301 di sini akan menjadi kesalahan: Anda menyerahkan peringkat /shoes/ kepada halaman yang sebentar lagi dihapus.

3. Pemeliharaan atau tidak tersedia sementara

GET /booking/           → 302 → /status/booking-back-soon/

Sebuah layanan sedang tidak tersedia sebentar dan Anda mengarahkan pengguna ke halaman penjelasan. Ini contoh kasus dari Google sendiri. URL asli mempertahankan posisinya di hasil saat Anda memperbaiki masalah. (Jika URL yang sama benar-benar offline, bukan dialihkan ke tempat lain, sebuah 503 Service Unavailable sering menjadi sinyal yang lebih tepat.)

4. Perutean geografis, perangkat, atau bahasa

GET /               → 302 → /us/     (visitor in the US)
GET /               → 302 → /de/     (visitor in Germany)

Tujuan bergantung pada siapa yang meminta, jadi tidak ada satu target yang boleh menggantikan URL sumber secara permanen. Redirect sementara cocok karena jawaban yang “tepat” berubah pada setiap permintaan. (Pasangkan dengan hreflang yang benar untuk versi terlokalisasi.)

5. Penyeimbangan beban/failover

GET /app/               → 302 → /app-eu-west/     (primary origin down)

Saat origin atau pusat data sementara tidak tersedia, traffic dialihkan ke tempat lain—tetapi pengalihan itu dimaksudkan berakhir ketika sumber utama pulih. Ini sementara secara definisi.

Anti-pattern, sebagai pembanding:

GET /old-product/       → 302 → /new-product/     ❌ (permanent move!)

Ini adalah penghentian permanen yang disamarkan sebagai sementara. Akibatnya, Google dapat mempertahankan /old-product/ tetap terindeks dan mendapat peringkat alih-alih mengonsolidasikannya ke /new-product/ selama jangka waktu yang tidak dapat diprediksi. Seharusnya gunakan 301.

Dua mekanisme, bukan satu

Gunakan kerangka ini agar mitos tentang redirect tidak mencampuradukkan pertanyaan yang berbeda.

Terapkan dalam tiga langkah:

1. Nyatakan maksudnya. 302 menyatakan perpindahan sementara dan URL asli harus tetap menjadi alamat yang stabil.
2. Periksa sinyal kanonik. Tautan internal, entri sitemap, canonical, tautan eksternal, dan durasi redirect dapat memperkuat sumber atau membuat target menang.
3. Tafsirkan 302 yang berumur panjang dengan benar. Jika Google mulai memperlakukannya seperti perpindahan permanen, redirect tidak tiba-tiba mulai “meneruskan nilai”. Keseimbangan sinyal kanonik berubah sehingga URL yang memiliki bobot tersebut ikut berubah.

Pertanyaan diagnostiknya bukan “apakah 302 meneruskan PageRank?” Melainkan “URL mana yang seharusnya kanonik, dan apakah redirect bersama sinyal lain kita menyatakan hal yang sama?”

Alat untuk memeriksa redirect sementara

Alat gratis Patrick

• Redirect Checker—pastikan hop pertama benar-benar 302, periksa Location, dan temukan rantai yang mencampur kode sementara dan permanen.
• Bulk HTTP Status Code Checker—audit hingga 500 URL untuk pengujian, promosi, perutean, atau pemeliharaan, lalu ekspor respons yang tidak sesuai dengan perilaku sementara yang direncanakan.

Periksa perilaku dan durasi kanonik

• Pemeriksaan URL Google Search Console—bandingkan URL sumber dan variasi, lalu periksa mana yang dipilih Google sebagai kanonik.
• Log server/CDN—buktikan redirect terbatas pada audiens dan periode yang dimaksud, serta Googlebot tidak secara tidak sengaja menerima jalur berbeda.
• Log/konfigurasi platform eksperimen—catat awal/akhir uji, pembagian traffic, dan aturan redirect agar respons sementara tidak menjadi infrastruktur yang terlupakan.

Buktikan bahwa redirect sementara tetap sementara

Uji 1 — eksperimen benar-benar mengeluarkan 302

• Uji yang dijalankan — Periksa URL asli dengan Redirect Checker saat Anda ditugaskan ke varian yang me-redirect; ulangi dari sesi bersih jika pembagian berbasis cookie. Jalankan sebagai GET nyata, bukan hanya permintaan HEAD—penanganan server, CDN, atau aplikasi dapat berbeda, jadi pemeriksaan HEAD saja tidak membuktikan apa yang diterima pengunjung nyata (atau Googlebot). Rekam baris status mentah, nilai Location persis, dan header cache-control pada respons, bukan hanya “terjadi redirect”.
• Hasil yang diharapkan — Sumber mengembalikan 302 dengan varian yang dimaksud pada Location, dan varian tersebut selesai tanpa loop atau hop tambahan yang tidak terkait.
• Interpretasi kegagalan — 301/308 mengirim sinyal permanen; 200 yang diikuti navigasi menunjukkan redirect sisi client, bukan respons server yang direncanakan; jika HEAD dan GET mengembalikan kode status berbeda untuk URL yang sama, berarti server atau CDN menangani kedua metode secara tidak konsisten dan perlu diperiksa lebih lanjut.
• Jendela pemantauan — Segera setelah uji diaktifkan, lalu sekali setiap deployment atau perubahan perutean.
• Pemicu rollback — Sumber mengembalikan kode permanen, tujuan salah, atau kelompok pengunjung mana pun masuk loop.

Uji 2 — URL asli tetap menjadi URL kanonik

• Uji yang dijalankan — Periksa URL asli dan variasi di Google Search Console, lalu pastikan tautan internal, entri sitemap, dan tag canonical tetap mengutamakan URL asli.
• Hasil yang diharapkan — Sumber tetap menjadi kanonik yang dimaksud; variasi tidak menggantikannya sebagai halaman uji yang diindeks terpisah.
• Interpretasi kegagalan — Sinyal kanonik yang bertentangan atau redirect yang berjalan terlalu lama mendorong Google ke variasi.
• Jendela pemantauan — Periksa setelah Google merayapi ulang URL dan kembali memeriksa selama uji panjang; tidak ada hari tetap ketika 302 berbalik.
• Pemicu rollback — Variasi menjadi kanonik pilihan Google atau mulai muncul sendiri untuk kueri halaman asli.

Uji 3 — aturan sementara dihapus saat pengujian berakhir

• Uji yang dijalankan — setelah penghentian, minta URL asli dari sesi bersih dan jalankan melalui Redirect Checker.
• Hasil yang diharapkan — URL asli kembali mengembalikan konten 200 normal dan tidak ada alokasi pengujian yang mengarahkan ke variasi.
• Interpretasi kegagalan — aturan CDN, edge, aplikasi, atau eksperimen yang kedaluwarsa masih tersisa.
• Jendela pemantauan — segera setelah penghentian, lalu sekali lagi setelah cache kedaluwarsa.
• Pemicu rollback — kelompok traffic produksi mana pun masih mencapai variasi yang sudah dipensiunkan; nonaktifkan aturan lama dan hapus cache yang relevan.

Uji 4 — rantai lengkap, perilaku metode, dan kasus batas tercakup

• Uji yang dijalankan — Lacak seluruh rantai redirect dari awal sampai akhir (bukan hanya hop pertama) dan pastikan tujuan akhir mengembalikan respons sehat; jalankan ulang uji dengan parameter kueri dan pastikan parameter dipertahankan (atau sengaja dihapus), bukan diam-diam hilang; coba permintaan dengan body POST jika rute dapat menerimanya untuk melihat apakah metode bertahan atau berubah; dan jika tujuan redirect pernah berasal dari input pengguna, pastikan tujuan diperiksa terhadap allowlist, bukan menerima tujuan sembarang.
• Hasil yang diharapkan — Rantai selesai dalam jumlah hop yang kecil dan dapat diprediksi menuju halaman yang berfungsi; parameter dan metode berperilaku sesuai maksud aplikasi; tujuan di luar allowlist ditolak, bukan di-redirect.
• Interpretasi kegagalan — Rantai panjang atau berulang, parameter yang hilang dan merusak halaman tujuan, metode yang diam-diam berubah padahal tidak seharusnya, atau redirect yang mengikuti parameter ?next= sembarang (risiko open redirect) semuanya adalah temuan yang menghalangi peluncuran, bukan kosmetik.
• Jendela pemantauan — Sebelum peluncuran, dan lagi setelah perubahan apa pun pada penanganan aturan atau versi CDN/framework.
• Pemicu rollback — Salah satu kegagalan di atas muncul pada traffic produksi.
• Catatan tentang alat — Alat Pemeriksaan URL Search Console memiliki keterbatasan untuk pemeriksaan ini (mencerminkan perayapan Google sendiri dan belum tentu menampilkan header mentah live) —perlakukan sebagai sinyal tentang apa yang dilihat Google, bukan pengganti pemeriksaan respons HTTP aktual Anda sendiri.

Uji pengetahuan Anda: redirect 302

Lima pertanyaan singkat tentang apa itu 302 dan kapan menggunakannya. Pilih satu jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan