Pengalihan 302 vs. 307

TL;DR — 302 dan 307 sama-sama pengalihan sementara: keduanya mengirim pengunjung ke tempat lain untuk sementara, sementara URL asli tetap menjadi URL yang diperhitungkan. Google memproses keduanya dengan cara yang sama, jadi tidak ada perbedaan SEO yang berarti. Perbedaan teknisnya: 307 harus mempertahankan jenis permintaan (pengiriman formulir tetap menjadi pengiriman formulir, bukan berubah menjadi pengambilan halaman biasa), sedangkan 302 secara historis membiarkan perubahan itu terjadi. Gunakan 302 biasa untuk pengalihan normal; gunakan 307 ketika mengalihkan formulir atau API yang mengirim data—dan jangan menganggap “307 sebagai default di mana-mana” (terjemahan) “307 sebagai default di mana-mana” bebas dari konsekuensi.

Arti sebenarnya 302 dan 307

302 dan 307 sama-sama merupakan pengalihan: Anda meminta satu URL lalu mendarat di URL yang berbeda. Angka tersebut adalah kode status HTTP yang dikirim server, dan membawa pesan untuk browser serta mesin pencari.

• 302—“Found” (terjemahan) “Ditemukan” (sementara). Ini adalah pengalihan sementara asli. Pesannya: “go here for now, but the old address is still the real one—I’ll be back.” (terjemahan) “buka alamat ini untuk sementara, tetapi alamat lama tetap yang sebenarnya—saya akan kembali.”
• 307—“Temporary Redirect.” (terjemahan) “Pengalihan Sementara.” Pesannya sama—sementara, URL lama tetap diperhitungkan— dengan satu janji tambahan: browser harus mengulangi permintaan Anda persis, termasuk apakah permintaan itu GET (hanya mengambil halaman) atau POST (mengirim data seperti formulir).

Jadi, keduanya bersaudara. Cara yang berguna untuk mengatakannya: 307 adalah 302 yang juga menjamin browser tidak diam-diam mengubah pengiriman formulir Anda menjadi permintaan halaman biasa.

Apakah ini penting untuk SEO?

Tidak dengan cara yang biasanya dikhawatirkan pemilik situs. Dokumentasi Google sendiri mencantumkan 307 sebagai “equivalent to 302” (terjemahan) “setara dengan 302” untuk cara crawler memproses dan mengikuti pengalihan. Keduanya adalah sinyal “sementara”, jadi secara default Google tidak menganggap tujuan sebagai halaman kanonis hanya karena Anda mengalihkannya ke sana. Dokumentasi Google tidak menjelaskan apakah 302 dan 307 meneruskan jumlah nilai tautan yang identik atau berbeda—yang dinyatakan dengan jelas adalah bahwa tidak satu pun kode memberikan sinyal sumber kepada tujuan seperti yang dilakukan pengalihan permanen. Jika seseorang mengatakan 307 “meneruskan nilai lebih sedikit” daripada 302, minta sumbernya—Google belum menerbitkan pernyataan seperti itu.

Jadi, kapan saya memakai masing-masing?

• Gunakan 302 biasa untuk pengalihan sementara sehari-hari—halaman penjualan musiman, pengujian A/B, halaman pemeliharaan, atau mengirim seseorang ke beranda khusus negara.
• Gunakan 307 ketika hal yang dialihkan mengirim data—pengiriman formulir, panggilan API, login, atau POST checkout. Janji 307 (mempertahankan metode dan data persis seperti semula) benar-benar penting karena 302 biasa dapat membiarkan browser lama mengubah POST menjadi GET dan membuang datanya.

Satu hal yang sering membingungkan

Terkadang Anda membuka alat pengembang di browser dan melihat 307 yang tidak pernah Anda atur. Biasanya itu bukan pengalihan server sungguhan—browser Anda sendiri meningkatkan tautan http:// menjadi https:// (fitur keamanan bernama HSTS) dan menampilkannya kepada Anda sebagai 307. Server Anda tidak pernah mengirimkannya. Penjelasan selengkapnya ada di tab Advanced.

Ingin memahami gambaran lengkap—sejarah spesifikasi, penjelasan Google dan Mueller, “307 semu” HSTS, serta default framework yang sering mengejutkan developer? Buka tab Advanced.

TL;DR — 302 dan 307 sama-sama pengalihan sementara, dan Google memprosesnya dengan cara yang sama— dokumentasinya menyebut 307 “equivalent to 302” (terjemahan) “setara dengan 302”, sedangkan Mueller mengatakan “for SEO, it doesn’t really matter” (terjemahan) “untuk SEO, perbedaannya tidak terlalu penting” untuk pasangan sementara maupun permanen. Tidak satu pun kode menjadi sinyal bahwa tujuan harus menjadi kanonis, dan Google belum menerbitkan pembagian PageRank atau nilai tautan yang dinyatakan di antara keduanya. Perbedaan sebenarnya adalah pelestarian metode: pengikutan otomatis 307 harus mempertahankan metode permintaan yang sama (POST tetap menjadi POST), sedangkan 302 membiarkan klien mengubah POST menjadi GET—byte isi, kredensial, dan perilaku lintas asal tetap bergantung pada klien, jadi verifikasi dan jangan berasumsi. Pilih 307 ketika hilangnya metode akan merusak sesuatu—API, formulir, alur POST/webhook/checkout/auth—tetapi waspadai pemutaran ulang non-idempoten (pembayaran atau panggilan pesanan yang dialihkan dapat terkirim lagi). 302 biasa cocok untuk pengalihan GET biasa, termasuk rekomendasi eksplisit Google untuk pengujian A/B. Waspadai “307 semu” HSTS (terjemahan) “307 semu” (label UI Chrome, bukan jaminan protokol), detail framework (Next.js mendokumentasikan 303 untuk Server Actions dan 307 di konteks lain—periksa versi Anda, jangan menggeneralisasi ke platform lain), serta fakta bahwa Bing tidak memiliki panduan 302-vs-307 khusus. Urutan pilihan saya sendiri untuk pengalihan sementara adalah 307 / 302 / 303 di atas meta/HTTP refresh—tetapi menjadikan 307 default tidak bebas biaya, jadi periksa header cache, dukungan klien lama, dan perlindungan idempotensi terlebih dahulu.

Keduanya sementara—itulah titik awalnya

Sebelum hal lain: 302 dan 307 berada dalam kategori yang sama. Google mengelompokkan 302 (Found), 303 (See Other), dan 307 (Temporary Redirect) sebagai “temporary redirects” (terjemahan) “pengalihan sementara”, dan perilakunya untuk semua kode itu sama— “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (terjemahan) “Googlebot mengikuti pengalihan, tetapi alur pengindeksan tidak menggunakan pengalihan itu sebagai sinyal bahwa target pengalihan harus menjadi kanonis.” Dalam istilah sederhana, pengalihan sementara secara default mempertahankan URL sumber sebagai kanonis; pengalihan itu tidak memberikan sinyal sumber kepada tujuan seperti yang dilakukan pengalihan permanen (301/308).

Ini persis perbandingan tingkat permanen satu tingkat di bawahnya: 301/308 adalah pasangan permanen, 302/307 adalah pasangan sementara, dan logika “kode dengan angka lebih tinggi mempertahankan metode” (terjemahan) “kode dengan angka lebih tinggi mempertahankan metode” identik pada kedua pasangan.

Perbedaan sebenarnya: pelestarian metode dan isi

Berikut perbedaan yang benar-benar penting, dalam satu kalimat: ketika klien otomatis mengikuti 307, spesifikasi HTTP saat ini (RFC 9110) mewajibkan klien mempertahankan metode permintaan yang sama; 302 membiarkan klien mengubah POST menjadi GET. Itu adalah jaminan tingkat spesifikasi tentang metode, bukan jaminan menyeluruh atas setiap byte isi, kredensial, atau penanganan lintas asal, yang tetap bergantung pada klien tertentu yang menerapkan pengalihan. Verifikasi hal-hal itu dengan permintaan nyata, alih-alih menganggap 307 memutar ulang semuanya secara identik di setiap kasus.

Mengapa ambiguitas itu ada adalah kisah sejarah spesifikasi yang layak diceritakan, karena banyak tulisan menyatakan faktanya tanpa menjelaskan mengapa. Pada era HTTP/1.0, teks spesifikasi 302 secara teknis mengatakan klien tidak boleh mengubah metode permintaan saat mengikuti pengalihan—namun browser awal (Netscape, lalu semua browser lain) mengabaikannya dan diam-diam mengubah metode non-GET, terutama POST, menjadi GET pada 302. Perilaku yang tidak konsisten tetapi universal itu menjadi standar de facto. HTTP/1.1 (RFC 2616, 1999, yang kemudian digabungkan ke RFC 7231 dan RFC 9110 saat ini) meresmikan pemisahan menjadi dua kode eksplisit untuk mengakhiri kebingungan:

• 303 (See Other)—mengambil target pengalihan dengan GET atau HEAD (bukan sekadar “selalu GET” (terjemahan) “selalu GET”—RFC 9110 mengizinkan salah satu metode aman), sebagai perilaku yang dimaksud untuk “POST, then redirect to a result page you can safely reload.” (terjemahan) “POST, lalu beralih ke halaman hasil yang dapat Anda muat ulang dengan aman.”
• 307 (Temporary Redirect)—metode dipertahankan secara ketat saat pengikutan otomatis, sesuai spesifikasi; RFC 9110 tidak memaksa setiap klien untuk mengikuti pengalihan sama sekali.

MDN merangkum dampak praktisnya dengan jelas: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (terjemahan) “Perbedaan antara 307 dan 302 adalah bahwa 307 menjamin klien tidak mengubah metode dan isi permintaan saat permintaan hasil pengalihan dibuat. Pada 302, klien lama keliru mengubah metode menjadi GET.” Jadi 307 bukan menambahkan kemampuan baru, melainkan menghapus ambiguitas—versi yang dijamin spesifikasi dari perilaku yang seharusnya sudah dilakukan 302 oleh klien yang patuh. Browser modern jauh lebih konsisten daripada kekacauan era Netscape, tetapi 307 menghapus ambiguitas berdasarkan spesifikasi, bukan kebiasaan.

Perbandingan berdampingan:

Dua catatan presisi perlu diingat. Izin RFC untuk mengubah metode pada 302 menyebut POST, bukan setiap metode—jangan menggeneralisasinya menjadi “302 always breaks PUT/DELETE” (terjemahan) “302 selalu merusak PUT/DELETE” tanpa memeriksa klien tertentu. Selain itu, tidak satu pun kode otomatis dapat di-cache hanya karena statusnya: RFC 9111 tidak mencantumkan 302 atau 307 sebagai status yang dapat di-cache secara heuristik berdasarkan status saja—caching tetap bergantung pada header Cache-Control/Expires, bukan kode pengalihan yang Anda pilih.

Definisi Ahrefs yang saya tulis sendiri sejalan dengan bagian pelestarian metode: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (terjemahan) “Pengalihan 307 sama dengan pengalihan 302, kecuali metode HTTP (POST, GET) dari permintaan asli dipertahankan saat pengalihan dilakukan.”

Apakah Google memperlakukan 302 dan 307 secara berbeda untuk SEO?

Tidak—dan Google sangat jelas tentang hal ini. Ini adalah topik yang sudah mapan dan hampir tidak kontroversial, seperti halnya 301-vs-308.

Dalam dokumentasi kode status HTTP Google, baris 302 menyatakan bahwa crawler Google mengikuti pengalihan dan menggunakannya sebagai sinyal lemah bahwa target harus diproses, sedangkan baris 307 secara harfiah berbunyi “Equivalent to 302” (terjemahan) “Setara dengan 302”. Google kemudian menambahkan catatan yang berlaku sama untuk pasangan 302/307 dan 301/308: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (terjemahan) “Google memperlakukan kode status ini dengan cara yang sama, tetapi keduanya tetap berbeda secara semantik. Pilih kode yang tepat agar klien lain (misalnya pembaca elektronik dan mesin pencari lain) dapat memanfaatkannya.”

Itulah jawaban tentang pemrosesan crawler. Google memperlakukan keduanya dengan cara yang sama saat Googlebot mengambil dan mengikuti pengalihan, dan hanya meminta Anda memilih kode yang benar secara semantik agar klien non-Google berperilaku baik. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Ada satu nuansa yang perlu dijelaskan dengan tepat karena sering terlewat. Kesetaraan pemrosesan crawler adalah klaim yang terpisah dari hasil pengindeksan. Dokumentasi pengalihan dan Google Search mengelompokkan 302, 303, dan 307 sebagai “temporary redirects” (terjemahan) “pengalihan sementara” dan menyatakan bahwa “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (terjemahan) “alur pengindeksan tidak menggunakan pengalihan sebagai sinyal bahwa target pengalihan harus menjadi kanonis.” Itu adalah jaminan yang nyata dan berguna—tetapi bukan janji bahwa URL sumber akan terus mendapat peringkat, atau bahwa tujuan tidak akan pernah diindeks melalui sinyal lain. Perlakukan “302 dan 307 diproses dengan cara yang sama” serta “tidak satu pun menjadi sinyal kanonis ke target” sebagai dua pernyataan yang terpisah dan sama-sama benar—bukan klaim bahwa kedua kode meneruskan PageRank atau nilai tautan yang identik, karena dokumentasi Google tidak menyatakannya.

John Mueller mengatakan hal yang sama dengan kata-katanya sendiri. Dalam episode “Search Off the Record” (terjemahan) “Search Off the Record” bertajuk “Let’s talk redirects” (terjemahan) “Mari membahas pengalihan”, Martin Splitt bertanya langsung mengapa 307 dan 308 ada di samping 301 dan 302. Mueller menjawab: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (terjemahan) “Belakangan ini saya perlu mengeceknya. Biasanya 301 dan 302 meneruskan permintaan GET.” … “And with 307, 308, it also forwards POST requests.” (terjemahan) “Pada 307 dan 308, permintaan POST juga diteruskan.” Lalu ada kutipan yang menjawab pertanyaan SEO: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (terjemahan) “Menurut saya, untuk SEO itu tidak terlalu penting. Pertanyaannya lebih seperti: apakah ini berfungsi untuk API? Biasanya API bukan sesuatu yang perlu diindeks langsung di Search.”

Perhatikan kerangka penjelasannya: seluruh alasan memilih 307 dibandingkan 302 adalah pertanyaan fungsional (“apakah ini berfungsi untuk API?”), bukan pertanyaan peringkat. Tidak ada sumber primer yang kredibel yang menyatakan keunggulan SEO untuk salah satu kode.

Apakah Bing memperlakukan 302 dan 307 secara berbeda?

Sejujurnya: Bing belum mengatakannya. Panduan pengalihan publiknya (tulisan 2011 “Managing redirects – 301s, 302s and canonicals” (terjemahan) “Mengelola pengalihan—301, 302, dan kanonis” dan tulisan 2020 “Website Migration with Bing” (terjemahan) “Migrasi situs dengan Bing”) hanya membahas pembagian permanen-vs-sementara 301-vs-302 dan tidak pernah menyebut 307 atau 308. Berbeda dari topik 301-vs-308—yang memiliki pernyataan langsung dari Fabrice Canel—saya tidak menemukan pernyataan perwakilan Bing yang khusus membahas 302 versus 307.

Jadi saya akan menyatakannya apa adanya, bukan mengasumsikan keduanya setara: tidak ada pernyataan Bing yang secara khusus membedakan 302 dan 307. Ada perilaku Bing yang terdokumentasi dan relevan untuk pembahasan pengalihan sementara: jika Bingbot melihat 302 yang sama cukup sering berturut-turut, Bingbot mulai memperlakukannya seperti 301 dan mengkonsolidasikan sinyal ke depan—tetapi Bing belum mengonfirmasi secara publik bahwa perilaku itu berlaku untuk 307 yang berulang. Anggap ini sebagai celah dokumentasi yang nyata, bukan fakta tentang 307.

Kapan 307 menjadi pilihan yang benar secara teknis

Gunakan kode yang mempertahankan metode untuk pengalihan apa pun yang akan rusak jika metode atau isi permintaan asli hilang:

• API dan endpoint webhook—permintaan POST/PUT/DELETE yang harus tiba di URL baru dengan metode dan payload tetap utuh.
• Pengiriman formulir (alur POST)—seperti kata Mueller, “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (terjemahan) “jika ada—hampir bisa saya sebut konfigurasi yang rusak—formulir di satu domain dan hasilnya diteruskan ke domain lain, gunakan 307 atau 308.”
• Serah-terima POST untuk checkout, pembayaran, dan login/autentikasi—di mana pun kehilangan isi secara diam-diam akan menggagalkan transaksi.

Ada satu catatan keselamatan penting: jaminan pelestarian metode 307 berlaku dua arah. Jika permintaan asli tidak idempoten—tagihan pembayaran, pengiriman pesanan, atau tindakan lain yang menimbulkan efek samping—pengikutan otomatis 307 akan mengirim ulang permintaan persis itu ke URL baru. Biasanya itulah yang diinginkan, tetapi percobaan ulang klien atau rantai pengalihan dapat mengirim panggilan non-idempoten lebih dari sekali. Pasang kontrol idempotensi (kunci idempotensi atau pemeriksaan pengiriman duplikat) pada endpoint penerima; jangan menganggap pengalihan saja membuat pengiriman ulang aman.

Salah satu alasan developer menemui 307 tanpa memilihnya adalah beberapa framework dan platform edge menjadikan kode yang mempertahankan metode sebagai default untuk permintaan non-GET. Next.js adalah contoh yang paling jelas dan terdokumentasi—fungsi redirect() mengembalikan 303 ketika dipanggil dari Server Action dan 307 di konteks lain yang didukung, menurut referensi API saat ini. Periksa dokumentasi versi Next.js Anda, jangan menganggap satu kode berlaku di seluruh framework. Framework lain, CDN, dan load balancer berbeda menurut produk dan versi—verifikasi status aktual yang dikembalikan platform, bukan menebaknya dari platform yang tampak serupa. Melihat 307 atau 303 yang tidak terduga sering berarti platform sengaja memperhatikan metode, bukan salah konfigurasi—tetap konfirmasi pada penyiapan Anda.

Kapan 302 menjadi default yang pragmatis

Pengalihan sementara standar pada permintaan GET biasa—tidak ada metode yang perlu dipertahankan, sehingga jaminan 307 tidak memberi manfaat tambahan:

• Pengalihan geografis/bahasa (dengan catatan biasa: jangan sepenuhnya memblokir konten berdasarkan wilayah).
• Pengujian A/B dan split test—panduan pengujian situs Google secara eksplisit menyarankan 302, bukan 301, untuk variasi pengujian yang dialihkan karena pengalihannya bersifat sementara.
• Pengalihan mode pemeliharaan atau “segera kembali”—tetapi hanya jika ada resource nyata untuk menjadi tujuan; jika seluruh situs tidak tersedia, panduan Google mengarahkan ke 503 (service unavailable), bukan pengalihan. Jika yang dialihkan adalah permintaan non-GET—panggilan checkout atau API yang menuju halaman pemeliharaan—307 akan mengirim ulang permintaan itu ke URL baru, dan itu tidak otomatis aman bila memiliki efek samping. Jangan memakai 307 karena kebiasaan sebelum memeriksanya.
• Pengalihan seluler↔desktop (m-dot)—contoh Mueller sendiri untuk kasus ketika 302 secara khusus merupakan kode yang tepat: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (terjemahan) “pengalihan 302 adalah pilihan yang tepat karena lain kali seseorang datang, Anda tidak benar-benar tahu apakah ia menginginkan versi seluler atau desktop.” Tujuan yang tepat bergantung pada pengunjung, jadi ini bukan perpindahan permanen.

”307 semu” HSTS—307 yang tidak pernah dikirim server Anda

Bagian ini layak berdiri sendiri karena topiknya sama sekali berbeda dari memilih kode pengalihan. Mencampuradukkan keduanya menimbulkan kebingungan nyata saat orang melakukan debug pada rantai pengalihan.

Jika situs mengirim header HSTS (Strict-Transport-Security) melalui HTTPS, browser mengingatnya dan pada percobaan berikutnya ke versi http:// akan meningkatkan permintaan menjadi https:// sendiri—URI ditulis ulang sebelum permintaan menyentuh jaringan. Versi Chrome saat ini menampilkan peningkatan internal itu di DevTools sebagai 307, tetapi tidak ada server yang menerbitkannya. Label persis, jumlah byte, atau tampilan header bergantung pada versi Chrome, bukan persyaratan spesifikasi HTTP atau HSTS—jangan menganggap label “307” akan sama di setiap browser atau versi mendatang. John Mueller menjelaskannya di situs pribadinya: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (terjemahan) “Setelah melihat URL HTTPS dengan header HSTS (misalnya melalui pengalihan apa pun dari versi HTTP), Chrome akan bertindak seolah-olah melihat pengalihan 307 saat Anda mencoba mengakses halaman HTTP lagi.” Lalu klarifikasi utamanya: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (terjemahan) “Server Anda tidak mengembalikan 307; Chrome hanya menampilkannya demikian untuk menjelaskan bahwa Chrome yang melakukan pengalihan untuk Anda.”

Saya pernah menandai hal yang sama dalam tulisan kode status saya—bahkan ada arti terpisah “307 HSTS Policy” (terjemahan) “307 Kebijakan HSTS” (memaksa klien memakai HTTPS) dari “307 Temporary Redirect” (terjemahan) “307 Pengalihan Sementara”. Nuansa SEO-nya: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (terjemahan) “Saat server web mewajibkan klien hanya memakai koneksi HTTPS (kebijakan HSTS), Google tidak akan melihat 307 karena pengalihan itu tersimpan di cache browser.” Jadi, jika Anda melihat 307 di tab Network yang tidak pernah dikonfigurasi, sebelum mencari aturan pengalihan yang salah, periksa apakah HSTS hanya sedang meningkatkan HTTP menjadi HTTPS.

Mitos umum

• “307 doesn’t meneruskan same SEO value sebagai 302.” (terjemahan) “307 tidak meneruskan nilai SEO yang sama dengan 302.” Tidak didukung—dokumentasi Google sendiri menyebut 307 “Equivalent untuk 302” (terjemahan) “Setara dengan 302” untuk cara pengalihan diproses, dan tidak satu pun kode diperlakukan sebagai sinyal bahwa tujuan harus menjadi kanonis. Namun Google belum menerbitkan rumus PageRank atau nilai tautan yang tepat untuk salah satu kode, jadi jangan mengklaim perpindahan nilai yang persis sama (atau berbeda); klaim akuratnya adalah Google memproses keduanya dengan cara yang sama.
• “302 is the safer/recommended choice because it’s clearer cara pencarian engines treat it.” (terjemahan) “302 lebih aman atau lebih direkomendasikan karena perlakuan mesin pencari terhadapnya lebih jelas.” Itu berlebihan. Perlakuan Google atas 307 sama-sama terdokumentasi (“Equivalent untuk 302”) —ini bukan kasus satu kode lebih dipahami mesin pencari. Jika ada, 307 memberi jaminan fungsional (pelestarian metode/isi) yang tidak diberikan 302. (Sebagian panduan pihak ketiga menyatakan sebaliknya; lihat catatan di tab Resources.)
• “A 307 in my browser’s Network tab means my server misconfigured sebuah pengalihan.” (terjemahan) “307 di tab Network peramban berarti server saya salah mengonfigurasi pengalihan.” Sering kali salah—jika HSTS aktif dan Anda sebelumnya membuka versi HTTPS, 307 itu adalah peningkatan HTTP→HTTPS oleh Chrome sendiri, bukan respons server.
• “302s always convert POST to GET, so never use a 302 for a form.” (terjemahan) “302 selalu mengubah POST menjadi GET, jadi jangan pernah memakai 302 untuk formulir.” Ini berlebihan untuk peramban modern. Konversi POST→GET memang masalah nyata pada klien lama—itulah alasan 307 ada sebagai opsi yang dijamin, bukan bukti bahwa setiap 302 saat ini membuang data POST. 302 bersifat ambigu, bukan selalu rusak.
• “Switch all your temporary redirects to 307 for a rankings boost.” (terjemahan) “Ubah semua pengalihan sementara menjadi 307 demi kenaikan peringkat.” Salah dan hanya menambah perubahan yang tidak perlu—tidak ada keuntungan peringkat. Satu-satunya alasan yang sah memilih 307 adalah kebutuhan nyata untuk mempertahankan metode/isi (atau kesiapan masa depan).
• “303 and 307 are basically the same.” (terjemahan) “303 dan 307 pada dasarnya sama.” Tidak—303 secara eksplisit memaksa metode pengikutan menjadi GET (dibuat untuk pola POST-lalu-pengalihan-ke-halaman-hasil), sedangkan 307 menjamin pelestarian metode. Keduanya mudah tertukar karena dicantumkan bersama.

Rekomendasi saya

Untuk pengalihan sementara, urutan implementasi pilihan saya adalah 307 / 302 / 303, di atas meta refresh (0) dan HTTP refresh (0). Perhatikan bahwa saya menempatkan 307 di atas 302—bukan karena membantu SEO (tidak), melainkan karena jika selalu memakai kode yang mempertahankan metode, Anda jarang perlu mengingat untuk menggantinya nanti: pengalihan GET biasa tetap berfungsi sebagai 307, dan saat Anda mengalihkan formulir atau API, Anda sudah terlindungi. Itu alasan kelengkapan, bukan kebijakan tanpa biaya—307 sebagai default tetap memerlukan disiplin cache-control yang sama seperti pengalihan lain, harus bekerja untuk klien lama yang benar-benar Anda dukung, dan memerlukan perlindungan idempotensi pada target yang bukan pengambilan GET biasa. Mueller menyampaikan alasan kelengkapan yang sama: “if you always use them, then you’re always safe.” (terjemahan) “jika Anda selalu menggunakannya, Anda selalu aman.” Meski begitu, 302 biasa sepenuhnya baik, dan untuk kasus m-dot tertentu 302 secara teknis adalah pilihan yang lebih benar.

Letak pembahasan ini

302 dan 307 adalah dua kode pengalihan sementara 3xx, dan masing-masing memiliki pembahasan mendalam di cluster ini, bersama pasangan permanen (301, 308), saudara yang selalu memakai GET (303), serta perbandingan saudaranya—301-vs-308 (logika pelestarian metode yang sama, satu tingkat di atas) dan 301-vs-302 (permanen-vs-sementara) —ditambah bahaya operasional, rantai pengalihan, dan loop pengalihan. Untuk seluruh keluarga respons server, lihat hub Kode Status HTTP; jenis pengalihan juga merupakan salah satu sinyal kanonisasi yang dibahas dalam kanonisasi.

Ringkasan AI

Ringkasan singkat versi Advanced:

• Keduanya adalah pengalihan sementara. 302 dan 307 secara default mempertahankan URL sumber sebagai kanonis— tidak satu pun memberikan sinyal sumber kepada tujuan seperti pengalihan permanen 301/308.
• Google memproses keduanya dengan cara yang sama. Dokumentasinya menyebut 307 “equivalent untuk 302” (terjemahan) “setara dengan 302”, dan Mueller berkata “for SEO, it doesn’t really matter.” (terjemahan) “untuk SEO, perbedaannya tidak terlalu penting.” Namun ini adalah klaim tentang pemrosesan crawler, bukan rumus PageRank atau nilai tautan—Google belum menerbitkan rumus untuk salah satu kode, jadi jangan mengklaim perpindahan nilai yang persis sama (atau berbeda), dan jangan menganggap “diproses sama” menjamin sumber terus mendapat peringkat atau tujuan tidak pernah diindeks melalui sinyal lain.
• Perbedaan sebenarnya adalah pelestarian metode. Pengikutan otomatis 307 harus mempertahankan metode yang sama (POST tetap POST); 302 membiarkan klien mengubah POST menjadi GET. 307 ditambahkan di HTTP/1.1 (RFC 2616 → 7231 → 9110) untuk menutup ambiguitas itu—tetapi byte isi, kredensial, dan perilaku lintas asal tetap bergantung pada klien, dan izin konversi RFC menyebut POST secara khusus, bukan semua metode non-GET.
• Gunakan 307 untuk API, formulir, alur POST/webhook/checkout/auth—tetapi waspadai pemutaran ulang non-idempoten (panggilan pembayaran atau pesanan dapat dikirim ulang saat dialihkan; tambahkan perlindungan idempotensi). Gunakan 302 untuk pengalihan GET biasa—geografis/bahasa, rekomendasi eksplisit Google untuk pengujian sebuah/B, serta contoh seluler↔desktop dari Mueller. Pengalihan pemeliharaan bergantung pada ada tidaknya resource nyata sebagai tujuan; saat seluruh layanan padam, respons 503 sering lebih tepat.
• Default kerangka kerja bergantung pada versi dan konteks, bukan aturan universal. berikutnya.js mendokumentasikan 303 untuk server Actions dan 307 di konteks lain—periksa versi Anda, jangan menganggap kerangka kerja atau CDN lain berperilaku sama.
• “307 semu” HSTS: 307 di tab Network peramban sering merupakan Chrome yang meningkatkan HTTP→HTTPS sendiri (HSTS), bukan respons server—dan label “307” persisnya adalah pilihan UI khusus versi Chrome, bukan persyaratan spesifikasi HTTP/HSTS. Mueller: “Your server’s tidak returning sebuah 307, Chrome is just showing it untuk Anda sebagai such.” (terjemahan) “server Anda tidak mengembalikan 307; Chrome hanya menampilkannya demikian.”
• Bing: tidak ada panduan 302-vs-307 khusus—jangan mengasumsikan kesetaraan, dan jangan menganggap perilaku “302 berulang → diperlakukan sebagai 301” berlaku untuk 307.
• Tidak satu pun kode otomatis dapat di-cache hanya dari statusnya (RFC 9111) —caching tetap bergantung pada header Cache-Control/Expires yang eksplisit.
• Urutan pilihan Patrick untuk pengalihan sementara: 307 / 302 / 303 di atas meta/HTTP refresh—meskipun menjadikan 307 default di mana-mana tidak bebas biaya; periksa header cache, dukungan klien lama, dan perlindungan idempotensi dulu.

Dokumentasi resmi

Dokumentasi dan spesifikasi dari sumber primer.

Google

• Kode status HTTP, kesalahan jaringan dan DNS, serta Google pencarian —baris 302 tentang “weak signal” (terjemahan) “sinyal lemah”, baris 307 “Equivalent untuk 302” (terjemahan) “Setara dengan 302”, serta catatan bahwa keduanya berbeda secara semantik dan kode yang tepat harus digunakan.
• Pengalihan dan Google pencarian —mengelompokkan 302, 303, dan 307 sebagai “temporary redirects” (terjemahan) “pengalihan sementara” dan menjelaskan pengaruhnya terhadap kanonisasi.
• Episode 51—Mari membahas pengalihan —“pencarian Off Record” (terjemahan) “acara SOTR”, episode 51, dan “Let’s talk redirects” (terjemahan) “Mari membahas pengalihan” (John Mueller dan Martin Splitt) —diskusi yang direkam tentang alasan 307/308 ada dan kapan keduanya penting.
• John Mueller—panduan mesin pencari tentang 301, 302, 307, dan pengalihan lain —perilaku pengindeksan 302 (URL sumber “R” cenderung diindeks; pengalihan tidak di-cache).
• John Mueller—307 —penjelasan tentang “307 semu” HSTS.

Bing / Microsoft

• Mengelola pengalihan—301, 302, dan kanonis (Oktober 2011) —kerangka Bing: 301 untuk permanen dan 302 untuk sementara (tidak menyebut 307).
• Migrasi situs dengan Bing (Desember 2020) —panduan perpindahan situs umum (sekali lagi, tidak ada pernyataan khusus tentang 307).

Spesifikasi

• MDN—307 sementara pengalihan —definisi pelestarian metode/isi serta catatan sejarah tentang klien lama yang mengubah metode menjadi GET.
• RFC 9110—HTTP Semantics —§15.4.8 “307 Temporary Redirect” dan §15.4.3 “302 Found”, yaitu teks spesifikasi terkini untuk kedua kode.

Kutipan dari sumber

Pernyataan tercatat dari Google, beserta spesifikasinya. Jika halaman sumber mendukungnya, setiap tautan adalah tautan mendalam yang langsung melompat ke bagian yang dikutip.

Dokumentasi Google—307 setara dengan 302

• “Equivalent untuk 302.” (terjemahan) “Setara dengan 302.” (baris 307) —Google pencarian Central. Lompat ke kutipan
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use status code itu’s appropriate untuk pengalihan jadi other clients (untuk example, e-readers, other pencarian engines) may benefit dari it.” (terjemahan) “Walaupun Google memperlakukan kode status ini dengan cara yang sama, ingat bahwa keduanya berbeda secara semantik. Gunakan kode yang tepat agar klien lain (misalnya pembaca elektronik dan mesin pencari lain) dapat memperoleh manfaatnya.” Lompat ke kutipan
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use pengalihan sebagai sebuah sinyal itu pengalihan target seharusnya be canonical.” (terjemahan) “Googlebot mengikuti pengalihan, tetapi alur pengindeksan tidak menggunakannya sebagai sinyal bahwa target pengalihan harus menjadi kanonis.” (pengalihan sementara, termasuk 302/303/307) Lompat ke kutipan

John Mueller, Google (episode 51, “Search Off the Record” (terjemahan) “acara SOTR”—“Let’s talk redirects”* (terjemahan) “Mari membahas pengalihan”; PDF transkrip resmi, dikutip berdasarkan bagian yang relevan—tidak ada halaman HTML dengan teks jangkar yang cocok, jadi tautan mendalam #:~:text= tidak tersedia untuk kutipan ini)*

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (terjemahan) “Saya baru-baru ini harus memeriksanya. Biasanya, pada 301 dan 302, yang diteruskan adalah permintaan GET.” … “And with 307, 308, it also forwards POST requests.” (terjemahan) “Pada 307 dan 308, permintaan POST juga diteruskan.”
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (terjemahan) “Jika Anda memiliki API yang memakai permintaan POST, atau konfigurasi yang hampir bisa disebut rusak karena formulir berada di satu domain dan hasilnya diteruskan ke domain lain, gunakan 307 atau 308.”
• Dari sisi kelengkapan, penggunaan kedua kode secara konsisten biasanya aman. Perbedaan utamanya bukan SEO, melainkan apakah pengalihan harus berfungsi untuk API. API biasanya tidak perlu diindeks langsung di Search.
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (terjemahan) “Untuk pengalihan semacam itu [seluler/desktop], dari sudut teknis 302 adalah pilihan yang tepat karena lain kali seseorang datang, Anda tidak benar-benar tahu apakah ia menginginkan versi seluler atau desktop.” PDF transkrip

John Mueller, Google (johnmu.com—“307 semu” HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (terjemahan) “Setelah melihat URL HTTPS dengan header HSTS (misalnya melalui pengalihan apa pun dari versi HTTP), Chrome akan bertindak seolah-olah melihat pengalihan 307 saat Anda mencoba mengakses halaman HTTP lagi.”
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (terjemahan) “Server Anda tidak mengembalikan 307; Chrome hanya menampilkannya demikian untuk menjelaskan bahwa Chrome yang melakukan pengalihan untuk Anda.” Baca artikelnya

MDN—perbedaan pelestarian metode

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (terjemahan) “Perbedaan antara 307 dan 302 adalah bahwa 307 menjamin klien tidak mengubah metode dan isi permintaan saat permintaan hasil pengalihan dibuat. Pada 302, klien lama keliru mengubah metode menjadi GET.” Lompat ke kutipan

Pengalihan sementara mana: 302 atau 307?

Karena keduanya sementara dan setara untuk SEO, seluruh keputusan bermuara pada satu pertanyaan—apakah permintaan tersebut membawa metode atau isi yang wajib Anda pertahankan?

Catatan tentang jalur “belum yakin”: Google memproses 307 dengan cara yang sama seperti 302, dan 307 juga bekerja baik untuk pengalihan GET biasa, jadi menjadikannya default bukan kesalahan—tetapi tidak otomatis bebas biaya. Pastikan header cache Anda benar, periksa bahwa klien lama yang masih didukung menangani 307 secara dapat diprediksi, dan jika permintaan yang dialihkan memiliki efek samping (panggilan non-GET ke API), jangan biarkan 307 otomatis mengirim ulang permintaan itu tanpa perlindungan idempotensi.

Kesalahan pengalihan sementara yang perlu dihindari

Memilih 302 karena 307 dianggap meneruskan nilai lebih sedikit

Google mendokumentasikan 307 sebagai setara dengan 302 untuk penelusuran. Pilih di antara keduanya berdasarkan perilaku permintaan, bukan peringkat.

Menganggap 302 selalu lebih aman karena lebih lama

Klien lama membuat penanganan metode pada 302 menjadi ambigu. Jika isi POST, PUT, DELETE, webhook, atau API harus tetap utuh, gunakan 307 untuk jaminan pelestarian yang eksplisit.

Menganggap setiap 307 di DevTools adalah aturan server

Chrome dapat menampilkan peningkatan HSTS internal sebagai 307 meskipun server tidak pernah mengembalikannya. Ulangi permintaan dengan pemeriksa sisi server atau curl sebelum mengubah konfigurasi pengalihan.

Mengklaim setiap 302 mengubah POST menjadi GET

Perilaku historis itu diizinkan dan ambigu, bukan jaminan pada setiap klien modern. Gunakan 307 saat Anda memerlukan kepastian; jangan menggambarkan semua implementasi 302 sebagai rusak.

Mengganti setiap 302 dengan 307 demi keuntungan SEO

Tidak ada keuntungan peringkat. Ubah kode hanya ketika mempertahankan metode/isi meningkatkan ketepatan perilaku, atau ketika default framework yang lebih aman memang sesuai.

Menyamakan 303 dengan 307

Keduanya berlawanan secara fungsional dalam penanganan metode: 303 sengaja mengubah pengikutan berikutnya menjadi GET; 307 mempertahankan metode dan isi permintaan asli.

Mendiagnosis 307 tak terduga atau alur 302 yang rusak

DevTools menampilkan Internal Redirect / 307 yang tidak jelas

Gejala: Navigasi http:// muncul sebagai 307 di Chrome, tetapi tidak ada aturan pengalihan yang dibuat.

Kemungkinan penyebab: HSTS meningkatkan permintaan di dalam browser sebelum permintaan mencapai server.

Perbaikan: Periksa inisiator dan header entri tersebut, lalu kirim permintaan yang tidak otomatis mengikuti pengalihan langsung ke URL HTTP dengan alat sisi server—bukan browser, karena jendela Incognito baru pun dapat menerapkan status HSTS bawaan. Jangan menganggap curl sebagai baseline netral otomatis; curl dapat memiliki penyimpanan HSTS sendiri yang dikonfigurasi, jadi catat cara Anda menjalankannya. Jika respons server mentah berbeda dari tampilan DevTools, jangan “memperbaiki” 307 semu; audit pengalihan HTTP→HTTPS server yang sebenarnya secara terpisah, dan ulangi setiap permintaan non-GET sebagai pengujian terkontrol tersendiri—permintaan HEAD yang otomatis mengikuti pengalihan tidak dapat membuktikan perilaku POST/isi.

POST kehilangan isi setelah pengalihan sementara

Gejala: Formulir, webhook, login, atau panggilan API tiba di tujuan sebagai GET atau tanpa payload.

Kemungkinan penyebab: Sumber memakai 302, sehingga klien boleh mengubah metode, atau perantara menulis ulang respons.

Perbaikan: Gunakan 307 untuk perpindahan sementara, lalu ulangi permintaan uji yang aman dan pastikan di log tujuan bahwa metode, tipe isi, dan isi permintaan tiba secara utuh.

Platform mengeluarkan 307 meski Anda memilih pengalihan generik

Gejala: Framework atau platform edge mengembalikan 307 alih-alih 302 yang diharapkan.

Kemungkinan penyebab: Platform memilih kode sementara yang mempertahankan metode, sering kali untuk permintaan non-GET.

Perbaikan: Pastikan perpindahan itu benar-benar sementara dan mempertahankan permintaan memang tepat. Jika ya, pertahankan kode ini—Google memperlakukan kedua kode dengan cara yang sama. Ubah hanya jika semantik aplikasi atau kompatibilitas klien memerlukan respons lain.

302 vs. 307 sekilas

Aturan praktis: halaman sementara dengan GET biasa → keduanya berfungsi; permintaan sementara non-GET yang harus tiba utuh → 307.

Alat untuk mengidentifikasi pengalihan yang benar-benar diterima

Alat gratis Patrick

• Bulk HTTP Status Code Checker—kirim permintaan sisi server untuk hingga 500 URL dan tinjau kode serta rantai yang sebenarnya. Alat ini sangat membantu membedakan respons server dari tampilan 307 internal HSTS Chrome saja.

Memeriksa perilaku permintaan

• Redirect Checker—telusuri satu sumber melalui setiap lompatan dan pastikan apakah server memulai dengan 302 atau 307.
• Panel Network DevTools browser—periksa inisiator dan apakah Chrome menandai entri sebagai pengalihan internal; jangan menganggap itu saja sebagai bukti respons server.
• curl dan log aplikasi—kirim POST aman ke staging dan pastikan tujuan menerima metode serta isi yang sama; jika Anda mengonfigurasi curl dengan penyimpanan HSTS sendiri (--hsts), perhitungkan itu saat membaca hasil. Alat yang hanya menampilkan status tidak dapat membuktikan isi payload tiba.

Uji diri: 302 vs. 307

Lima pertanyaan tentang dua pengalihan sementara dan hal yang benar-benar membedakannya. Pilih jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Sumber daya yang layak dibaca

Tulisan terkait saya

• 11 Jenis Pengalihan dan Dampaknya pada SEO —“11 Types dari Redirects & mereka SEO Impact” (terjemahan) “11 Jenis Pengalihan dan Dampaknya pada SEO” (Ahrefs, bersama Joshua Hardwick) —ulasan lengkap saya tentang setiap jenis pengalihan. Di sini saya menjelaskan urutan implementasi pilihan untuk pengalihan sementara—307 / 302 / 303 > meta refresh 0 / HTTP refresh 0—dan menyatakan putusan SEO dengan jelas: “untuk SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want untuk be swapping antara GET dan POST.” (terjemahan) “Untuk SEO sama saja, tetapi jika data dikirim melalui formulir yang dialihkan, Anda tidak ingin menukar GET dan POST.”
• Kode Status HTTP dan Dampaknya pada SEO —“HTTP Status Codes & mereka SEO Impact” (terjemahan) “Kode Status HTTP dan Dampaknya pada SEO” (Ahrefs) —referensi saya untuk semua kode status, termasuk dua arti 307 yang berbeda (Pengalihan Sementara dan 307 Kebijakan HSTS) serta catatan bahwa dengan HSTS, “Google won’t see the 307 because it’s cached in the browser.” (terjemahan) “Google tidak akan melihat 307 karena tersimpan di cache peramban.”
• Panduan Pemula untuk SEO Teknis —” Beginner’s Guide untuk Technical SEO” (terjemahan) “Panduan Pemula untuk SEO Teknis”—tempat pengalihan berada dalam gambaran yang lebih besar.

Presentasi saya

• Patrick Stox di SlideShare dan Speaker Deck — presentasi SEO teknis saya, beberapa di antaranya membahas pengalihan dan kanonisasi. (Penafian tetap saya berlaku: “This is my understanding of systems… not going to be 100% complete or accurate.” (terjemahan) “Ini adalah pemahaman saya tentang sistem… tidak akan 100% lengkap atau akurat.”)

Resmi

• Google—kode status HTTP, kesalahan jaringan dan DNS —“HTTP status codes, network dan DNS errors, dan Google pencarian” (terjemahan) “Kode status HTTP, kesalahan jaringan dan DNS, serta Google pencarian”; baris “Equivalent untuk 302” (terjemahan) “Setara dengan 302” dan catatan “semantically different, use the right code” (terjemahan) “berbeda secara semantik, gunakan kode yang tepat”.
• Google—pengalihan dan Google pencarian —“Redirects dan Google pencarian” (terjemahan) “Pengalihan dan Google pencarian”; mengelompokkan 302/303/307 sebagai pengalihan sementara.
• Episode 51—Mari membahas pengalihan —“pencarian Off Record” (terjemahan) “acara SOTR”, “Let’s talk redirects” (terjemahan) “Mari membahas pengalihan” (Google pencarian Relations, episode 51) —diskusi Mueller/Splitt yang menjadi sumber kutipan di atas.

Dari industri

• John Mueller—307 —penjelasan paling jelas tentang “307 semu” HSTS: 307 yang ditampilkan peramban tetapi tidak pernah dikirim server.
• MDN—307 sementara pengalihan —definisi bersih tentang pelestarian metode/isi dan catatan sejarah tentang klien lama.
• sebuah SEO’s guide untuk redirects (pencarian Engine Land, Helen Pollitt) — ikhtisar umum yang solid tentang keluarga pengalihan.
• URL Redirects untuk SEO: sebuah Technical Guide (pencarian Engine Journal) —panduan teknis lain yang baik.
• Mitos yang perlu diluruskan: halaman “302 vs 307” Conductor menyarankan memakai 302 di atas 307 karena “it’s clear how search engines treat the 302 redirect.” (terjemahan) “jelas bagaimana mesin pencari memperlakukan pengalihan 302.” Nasihat itu bertentangan dengan dokumentasi Google sendiri, yang secara eksplisit menyebut 307 “Equivalent untuk 302” (terjemahan) “Setara dengan 302”—perlakuan 307 sama terdokumentasinya. Jangan menganggap “302 is the safer SEO choice” (terjemahan) “302 adalah pilihan SEO yang lebih aman” sebagai otoritatif; penggerak keputusan satu-satunya adalah apakah Anda perlu mempertahankan metode/isi.
• r/TechSEO —komunitas untuk men-debug pengalihan dan kanonisasi.

Log perubahan