Redirect Sementara 307

TL;DR — 307 adalah redirect sementara, seperti 302: kode ini mengirim pengguna dan mesin pencari ke URL baru untuk sementara, tanpa meminta Google memindahkan peringkat URL lama ke URL baru. Perbedaannya dengan 302 hanya satu: 307 menjamin metode permintaan tidak berubah. Jika seseorang mengirim formulir (POST), metode itu tetap POST. Untuk tautan halaman-ke-halaman biasa, hal ini tidak terlihat; perbedaan ini penting bagi formulir dan aplikasi. Dan “307” yang kadang terlihat di browser saat upgrade HTTPS bukan redirect nyata sama sekali.

Apa itu redirect 307

Saat URL berpindah ke tempat lain untuk sementara—bukan permanen—server dapat menjawab dengan 307 Redirect Sementara dan menunjuk browser ke lokasi baru. Gagasan dasarnya sama dengan 302: sifatnya sementara, jadi Google tidak memperlakukannya sebagai sinyal untuk memindahkan peringkat URL lama ke URL baru seperti pada redirect permanen. Ini sinyal lemah tanpa penggabungan kanonik, bukan jaminan URL lama akan selalu mempertahankan peringkat atau tetap terindeks. Gunakan redirect sementara untuk halaman yang sedang dalam pemeliharaan, kampanye musiman, atau sesuatu yang akan dikembalikan nanti.

Apa yang membedakan 307 dari 302

Hanya ada satu perbedaan, dan kebanyakan orang tidak pernah menjumpainya. Permintaan web memiliki metode—biasanya GET (sekadar mengambil halaman), tetapi kadang POST (mengirim data, misalnya mengirim formulir). 307 menjamin browser mempertahankan metode yang sama saat mengikuti redirect. Browser lama kadang mengubah POST menjadi GET pada 302, yang dapat merusak pengiriman formulir. Aturan 307 menghilangkan risiko itu. Evidence for this claim RFC 9110 defines 307 Temporary Redirect as a temporary move and requires clients not to change the request method when following it automatically. Scope: HTTP semantics for real server 307 responses, not browser-internal HSTS displays. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.8 — 307 Temporary Redirect

Pada sebagian besar redirect—seseorang mengeklik tautan ke halaman—hal ini sama sekali tidak berpengaruh karena kedua-duanya merupakan permintaan GET.

Apakah 307 merugikan SEO?

Tidak. Dokumentasi Google menyebut 307 “equivalent to” (terjemahan) “setara dengan” 302. Keduanya sementara, jadi tidak ada yang memindahkan peringkat halaman lama ke halaman baru seperti redirect permanen (301). Tidak ada penalti tersembunyi dan tidak ada peningkatan tersembunyi—307 diperlakukan persis seperti 302.

“307” yang bukan redirect

Inilah bagian yang sering membingungkan. Jika situs memaksa HTTPS (fitur keamanan bernama HSTS), browser kadang menampilkan “307” di alat pengembang saat Anda membuka versi HTTP halaman. Server tidak pernah mengirimnya—browser membuatnya sendiri untuk menjelaskan bahwa browser langsung beralih ke versi aman. Browser bahkan menampilkan respons 0 byte, petunjuknya.

Jadi, jika alat audit atau browser menandai 307 yang mengejutkan, jangan langsung mengira server salah konfigurasi. Jendela incognito baru biasanya menghapus memori HSTS yang dipelajari browser dan menampilkan kode status sebenarnya—tetapi tidak selalu: beberapa domain masuk daftar HSTS preload bawaan browser, yang tidak dihapus oleh incognito. Redirect checker atau permintaan curl adalah cara yang lebih andal untuk melihat respons server sebenarnya.

Ingin membaca bahasa spesifikasi, pernyataan John Mueller, mekanisme HSTS secara lengkap, dan cara mengembalikan 307? Beralihlah ke tab Advanced.

TL;DR — 307 adalah redirect sementara yang menurut RFC 9110 “MUST NOT change the request method” (terjemahan) “TIDAK BOLEH mengubah metode permintaan”—satu jaminan keras yang tidak diberikan 302. Untuk SEO, ini bukan peristiwa penting: dokumentasi Google mencantumkannya sebagai “Equivalent to 302” (terjemahan) “Setara dengan 302” (sinyal sementara yang lemah), dan Mueller mengatakan pilihan 307 vs. 302 “doesn’t really matter” (terjemahan) “sebenarnya tidak penting” untuk penelusuran. Yang penting adalah apakah redirect harus bekerja untuk trafik POST/API. 307 yang benar-benar membingungkan adalah artefak HSTS: “redirect” 0 byte khusus browser yang tidak pernah dikirim server, muncul saat browser menaikkan http ke https sendiri. Ada dua kasus yang tidak berkaitan secara fungsional; tugas utamanya adalah memisahkannya.

307 memiliki dua kasus yang sepenuhnya berbeda

Inilah gagasan pengaturnya, dan berasal langsung dari panduan kode status saya, yang memuat dua entri terpisah untuk 307: “307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (terjemahan) “307 Temporary Redirect—fungsinya sama dengan redirect 302, kecuali Anda tidak dapat berganti antara POST dan GET” dan “307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP.” (terjemahan) “307 HSTS Policy—memaksa klien memakai HTTPS saat membuat permintaan, bukan HTTP.” Keduanya berbagi nomor, tetapi hampir tidak berbagi hal lain:

1. 307 sebagai redirect sementara nyata yang diterbitkan server—dipilih secara sengaja (atau menjadi default framework) untuk mempertahankan metode HTTP dan body pada permintaan non-GET.
2. 307 sebagai artefak browser HSTS—bukan respons server sama sekali. Browser menaikkan http ke https secara internal lalu melabeli upgrade itu sebagai 307.

Mencampuradukkan kedua kasus ini adalah sumber kebingungan 307 yang paling umum. Saya akan membahasnya satu per satu.

Kasus 1: 307 nyata—apa yang diwajibkan spesifikasi

RFC 9110 (spesifikasi semantik HTTP saat ini) tidak ambigu di §15.4.8:

“The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (terjemahan) “Kode status 307 (Temporary Redirect) menunjukkan bahwa sumber daya target untuk sementara berada di URI berbeda dan user agent TIDAK BOLEH mengubah metode permintaan jika melakukan pengalihan otomatis ke URI tersebut.”

“MUST NOT” itu adalah kewajiban keras, bukan saran. Bandingkan dengan bagian 302 (§15.4.3), yang mendokumentasikan kekacauan historis yang hendak diperbaiki oleh 307: “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (terjemahan) “Karena alasan historis, user agent BOLEH mengubah metode permintaan dari POST menjadi GET pada permintaan berikutnya. Jika perilaku ini tidak diinginkan, kode status 307 (Temporary Redirect) dapat digunakan.” Dengan kata lain, 307 ada khusus untuk menghapus ambiguitas POST→GET yang dahulu terjadi pada klien lama dengan 302.

MDN menyatakan versi praktis dari perbedaan yang sama:

“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. 307 and 302 responses are identical when the request method is GET.” (terjemahan) “Perbedaan antara 307 dan 302 adalah 307 menjamin klien tidak mengubah metode dan body permintaan saat permintaan yang dialihkan dibuat. Pada 302, klien lama keliru mengubah metode menjadi GET. Respons 307 dan 302 identik ketika metode permintaan adalah GET.”

Kalimat terakhir itulah yang paling penting untuk SEO. Hampir setiap redirect yang diperhatikan SEO—halaman lama menuju halaman baru—adalah permintaan GET, dan untuk permintaan GET, 307 dan 302 benar-benar identik. Jaminan mempertahankan metode hanya berpengaruh ketika metodenya bukan GET: pengiriman ulang formulir, endpoint API, target webhook, atau pengalihan POST checkout maupun autentikasi. Yang dijamin spesifikasi adalah metode dan body; spesifikasi tidak menetapkan secara otomatis bagaimana setiap klien menangani header, kredensial, atau permintaan lintas origin saat diputar ulang. Verifikasi perilaku itu pada klien yang sebenarnya, jangan mengasumsikan byte demi byte. Jika membandingkan kedua kode untuk perpindahan halaman biasa, pembahasan mendalamnya ada pada artikel 302 vs. 307 khusus; artikel ini mengasumsikan Anda sudah memahami konsep dasar redirect sementara dari pendalaman redirect 302 dan berfokus pada hal yang unik dari 307.

302 vs. 303 vs. 307 dalam satu tabel

Ketiganya berada dalam kelompok “temporary” (terjemahan) “pengalihan bersifat sementara” RFC, tetapi perilakunya berbeda pada dua sumbu yang penting—pelestarian metode dan caching:

Tidak satu pun dari ketiganya dapat di-cache secara heuristik secara default—307 (seperti 302 dan 303) memerlukan sinyal kesegaran eksplisit (Cache-Control, Expires, dan sebagainya) sebelum cache menyimpannya tanpa bertanya lagi.

Kasus 1, lanjutan: cara Google memperlakukan 307 nyata untuk SEO

Versi singkatnya: persis seperti 302. Dokumentasi HTTP Status Codes Google mencantumkan baris 307 sebagai “Equivalent to 302” (terjemahan) “Setara dengan 302”, dan baris 302 yang diwarisinya menjelaskan artinya:

“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.”

“Weak” (terjemahan) “Lemah” adalah kata kuncinya—redirect sementara tidak mengonsolidasikan kanonikalisasi ke target seperti redirect permanen. Dokumentasi Redirects and Google Search Google mengelompokkan 302, 303, dan 307 sebagai “temporary” (terjemahan) “sementara” dan menjelaskan perilakunya: “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 redirect, tetapi pipeline indexing tidak memakai redirect sebagai sinyal bahwa target redirect harus menjadi kanonik.” Halaman yang sama menyatakan: “If you just want to send users to a different page temporarily, use a temporary redirect.” (terjemahan) “Jika hanya ingin mengirim pengguna ke halaman berbeda untuk sementara, gunakan redirect sementara.”

Tepat setelah baris 307 dan 308, Google menambahkan catatan yang layak diingat:

“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) “Walaupun Google memperlakukan kode status ini dengan cara yang sama, ingatlah bahwa keduanya berbeda secara semantik. Gunakan kode status yang sesuai untuk redirect agar klien lain (misalnya e-reader dan mesin pencari lain) dapat memperoleh manfaat.”

Jadi Google mengelompokkan 307 dan 302 untuk peringkat, tetapi tetap meminta Anda memilih kode yang benar secara semantik. Itulah seluruh jawaban SEO-nya. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search John Mueller menyampaikannya lebih terus terang dalam episode 51 Search Off the Record (“Let’s talk redirects” (terjemahan) “Mari membahas redirect”), dengan menjelaskan bahwa “with 307, 308, it also forwards POST requests” (terjemahan) “dengan 307 dan 308, POST juga diteruskan”—berbeda dari 301/302, yang meneruskan GET—lalu menyimpulkan:

Mueller juga menjelaskan bahwa dari sudut pandang SEO, 307 tidak banyak berarti; pertimbangan yang lebih penting adalah apakah mekanisme itu bekerja untuk API, yang biasanya tidak perlu diindeks langsung di Search.

Tidak ada keuntungan peringkat dengan mengganti redirect sementara menjadi 307. Satu-satunya alasan yang sah adalah mempertahankan metode/body—atau preferensi future-proofing umum, yang akan saya bahas di akhir.

Kasus 1, lanjutan: default framework dan CDN

Semakin banyak pertanyaan “mengapa ini 307?” bukanlah pilihan sengaja, melainkan nilai bawaan kerangka kerja. Fungsi redirect() Next.js secara default menghasilkan 307, dan dokumentasinya menjelaskan alasannya di bawah heading “Why does redirect use 307 and 308?” (terjemahan) “Mengapa redirect memakai 307 dan 308?”: “The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests.” (terjemahan) “Metode redirect() menggunakan 307 secara default, bukan redirect sementara 302, sehingga permintaan Anda selalu dipertahankan sebagai permintaan POST.” Next.js memakai 303 khusus di dalam Server Actions dan menyediakan permanentRedirect() terpisah untuk kasus 308. Jika melihat 307 yang tidak Anda tulis sendiri, periksa apakah framework atau platform edge menetapkannya sebagai default untuk redirect non-GET—biasanya itulah jawabannya, dan biasanya benar.

Kasus 2: “phantom 307” HSTS yang tidak pernah dikirim server

Inilah wilayah yang benar-benar kurang dibahas, dan alasan artikel 307 khusus berguna. Saat situs mengirim header Strict-Transport-Security (HSTS), browser diberi tahu bahwa mulai sekarang situs hanya boleh dimuat melalui https. Pada permintaan berikutnya ke versi http, browser menaikkan ke https sendiri, tanpa berbicara dengan server—lalu menampilkan upgrade internal itu sebagai “307” di alat pengembang dan crawler.

John Mueller menjelaskan mekanismenya 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. 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) “Setelah melihat URL HTTPS dengan header HSTS (misalnya melalui redirect apa pun dari versi HTTP), Chrome akan bertindak seolah-olah melihat redirect 307 saat Anda mencoba mengakses halaman HTTP berikutnya. Server Anda tidak mengembalikan 307; Chrome hanya menampilkannya demikian untuk menjelaskan bahwa Chrome melakukan redirect untuk Anda.”

Body 0 byte adalah petunjuknya. Mueller menambahkan, “the 307 isn’t actually a redirect at all, it’s just a placeholder.” (terjemahan) “307 sebenarnya bukan redirect sama sekali, melainkan hanya placeholder.” Panduan redirect saya menjelaskan konsekuensi praktis untuk audit: “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. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code.” (terjemahan) “Saat server web mewajibkan klien memakai koneksi HTTPS (kebijakan HSTS), Google tidak melihat 307 karena status itu di-cache di browser. Akses awal (tanpa cache) kemungkinan menghasilkan kode respons server 301 atau 302. Namun browser akan menampilkan 307 pada permintaan berikutnya sehingga troubleshooting lebih sulit. Gunakan sesi Incognito baru untuk melihat kode status yang dikembalikan.”

Apa yang sebenarnya dilihat Googlebot untuk HSTS (dan bagaimana ceritanya berkembang)

Dua pernyataan Google yang terpisah lima tahun layak dibaca bersama. Pada Desember 2015, Zineb Ait Bahajji (saat itu di Google) mengatakan, menurut Search Engine Roundtable, bahwa dengan HSTS Googlebot melihat redirect 301, sedangkan 307 yang tampil di browser hanyalah “redirect internal”. Pada Oktober 2020, penjelasan Mueller dalam video Ask Google Webmasters (melalui Search Engine Journal) menegaskan bahwa Googlebot tidak berinteraksi dengan 307 semu karena itu bukan redirect nyata. Bagaimanapun, crawler tidak melihat “307” yang sama seperti manusia di alat pengembang. Perangkat dan infrastruktur crawl berubah (Fetch as Google sudah dihentikan untuk URL Inspection), tetapi poin dasarnya bertahan setidaknya satu dekade: tidak ada 307 nyata yang diterbitkan server dalam kasus HSTS. Perlakukan pernyataan 2020 sebagai panduan saat ini; pernyataan 2015 berguna sebagai sejarah.

Pelajaran operasionalnya: HSTS adalah kenyamanan browser, bukan mekanisme penemuan crawl. Pemilik situs tetap memerlukan redirect sisi server nyata (301 sungguhan) untuk http→https jika ingin jalur itu bekerja bagi crawler.

Cara Bing memperlakukan 307

Sejujurnya, ada celah dokumentasi. Saya tidak menemukan pernyataan publik Bing yang membahas 307 secara spesifik atau 307 yang dipicu HSTS. Panduan redirect Bing (tulisan 2011 Mengelola redirect—301, 302, dan kanonikal dan tulisan 2020 Migrasi Situs dengan Bing) hanya mencakup perbedaan permanen-sementara 301/302—tidak menyebut 307, 308, atau HSTS. Jadi, alih-alih menganggapnya sama dengan Google, sampaikan apa adanya: Bing belum menyatakan sesuatu yang khusus tentang 307 secara publik. Fenomenanya tetap nyata dan relevan bagi crawler apa pun mesinnya. SEO Spider Screaming Frog menyediakan toggle “Respect HSTS Policy” justru karena HSTS memengaruhi crawling—tetapi itu dokumentasi tooling, bukan pernyataan Bing.

Kapan sengaja memilih 307

Pilih 307 (alih-alih 302) setiap kali kehilangan metode atau body asli akan merusak sesuatu:

• Endpoint API dan target webhook yang menerima POST/PUT/PATCH.
• Alur pengiriman formulir (POST) yang melakukan redirect setelah pemrosesan.
• Pengalihan POST checkout/login antarhost.
• Apa pun yang membawa body permintaan yang tidak boleh hilang.

Untuk perpindahan halaman biasa, 302 dan 307 tidak dapat dibedakan oleh Google, jadi keduanya baik dari sisi SEO. Jika berurusan dengan versi permanen dari logika mempertahankan metode yang sama, itulah hubungan 301-vs-308—308 terhadap 301 seperti 307 terhadap 302.

Preferensi saya dari panduan redirect lebih tegas daripada “it doesn’t matter” (terjemahan) “tidak ada bedanya”: “my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” (terjemahan) “urutan pilihan saya adalah: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” Saya menempatkan 307 pertama di antara opsi sementara—memakainya secara konsisten berarti aman dalam hal pelestarian metode, kira-kira argumen “kelengkapan” yang juga disampaikan Mueller. Apa pun pilihan Anda, pastikan 307 nyata (atau artefak HSTS) tidak menjadi satu hop dalam rantai redirect yang lebih panjang—setiap hop tambahan menambah latensi dan mengurangi efisiensi.

Ringkasan AI

Ringkasan singkat versi Advanced:

• 307 memiliki dua kasus yang tidak berkaitan. (1) Redirect sementara nyata yang diterbitkan server dan mempertahankan metode/body HTTP; (2) artefak browser HSTS—“307” 0 byte yang tidak pernah dikirim server, muncul saat browser menaikkan http→https sendiri. Tugasnya adalah memisahkan keduanya.
• Kasus 1—jaminan spesifikasi: RFC 9110 menyatakan 307 “MUST NOT change the request method.” (terjemahan) “TIDAK BOLEH mengubah metode permintaan.” MDN menambahkan bahwa “307 and 302 responses are identical when the request method is GET” (terjemahan) “respons 307 dan 302 identik ketika metode permintaannya GET”—jadi perbedaan hanya penting untuk POST/PUT/PATCH (formulir dan API). Jaminan mencakup metode dan body; penanganan header, kredensial, dan lintas origin saat pengulangan tetap bergantung pada klien.
• 302 vs. 303 vs. 307: 302 secara historis dapat mengubah POST menjadi GET, 303 sengaja mengambil target dengan GET/HEAD, 307 tidak boleh mengubah metode—dan tidak satu pun dapat di-cache secara heuristik secara default.
• Jawaban SEO: dokumentasi Google mencantumkan 307 sebagai “Equivalent to 302” (terjemahan) “Setara dengan 302”—sinyal sementara lemah yang tidak mengonsolidasikan kanonikalisasi ke target. Mueller mengatakan untuk SEO “it doesn’t really matter” (terjemahan) “sebenarnya tidak penting”; pertanyaan sebenarnya adalah “apakah ini bekerja untuk API?”.
• Default framework: redirect() Next.js default ke 307 (303 pada Server Actions, permanentRedirect() untuk 308) demi mempertahankan POST—sumber umum 307 “tidak sengaja” yang biasanya benar.
• Kasus 2—HSTS: browser menampilkan 307 dengan body 0 byte; kode server sebenarnya biasanya 301/302. Googlebot tidak melihat 307 itu (Mueller 2020: “doesn’t interact with them” (terjemahan) “tidak berinteraksi dengannya”; Zineb 2015: “sees a 301” (terjemahan) “melihat 301”). Anda tetap memerlukan 301 sisi server nyata untuk http→https. Audit dengan redirect checker atau curl; sesi incognito baru biasanya berhasil, kecuali domain berada di daftar HSTS preload bawaan browser.
• Bing: tidak ada pernyataan publik khusus 307—ini celah dokumentasi, bukan bukti paritas.
• Preferensi: tidak ada alasan peringkat untuk beralih ke 307; urutan pilihan Patrick menempatkan 307 pertama di antara opsi sementara demi future-proofing.

Dokumentasi resmi

Dokumentasi dan spesifikasi sumber utama.

Google

• Kode Status HTTP, Error Jaringan dan DNS, serta Google Search — baris “307 (temporary redirect) — Equivalent to 302”, bahasa “weak signal” untuk 302, dan catatan “semantically different”.
• Redirect dan Google Search — mengelompokkan 302/303/307 sebagai “temporary”; pipeline indexing tidak menggunakan redirect sebagai sinyal bahwa target harus menjadi kanonik.

Bing / Microsoft

• Mengelola redirect—301, 302, dan kanonikal — panduan redirect Bing (hanya 301/302; tidak menyebut 307/HSTS).
• Migrasi situs dengan Bing — panduan migrasi yang juga hanya membahas 301/302.

Spesifikasi HTTP

• RFC 9110 §15.4.8 — 307 Temporary Redirect — “MUST NOT change the request method.” (terjemahan) “TIDAK BOLEH mengubah metode permintaan.”
• RFC 9110 §15.4.3 — 302 Found — catatan historis POST→GET yang merujuk silang ke 307.

Referensi teknis

• MDN — 307 Temporary Redirect — pelestarian metode/body; “identical when the request method is GET” (terjemahan) “identik ketika metode permintaannya GET”.

Framework

• Next.js — referensi fungsi redirect() — FAQ “Why does redirect use 307 and 308?” (terjemahan) “Mengapa redirect menggunakan 307 dan 308?”; default 307 (303 pada Server Actions).

Perangkat crawler

• Screaming Frog — Panduan SEO untuk Crawling HSTS & Redirect 307 — konfigurasi “Respect HSTS Policy” dan mekanisme HSTS.

Kutipan dari sumber

Pernyataan yang tercatat. Setiap tautan melompat ke (atau mendokumentasikan) bagian sumber yang dikutip.

Dokumentasi Google—perlakuan SEO

• “307 (temporary redirect) — Equivalent to 302.” (terjemahan) “307 (redirect sementara)—setara dengan 302.” — Google Search Central, Kode Status HTTP, Error Jaringan dan DNS, serta Google Search. Lompat ke kutipan
• “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 302 yang diwarisi 307) Lompat ke kutipan
• “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) “Walaupun Google memperlakukan kode status ini dengan cara yang sama, keduanya berbeda secara semantik. Gunakan kode yang sesuai agar klien lain dapat memperoleh manfaat.” Lompat ke kutipan
• “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 redirect, tetapi pipeline indexing tidak memakai redirect sebagai sinyal bahwa target redirect harus menjadi kanonik.” — Google Search Central, Redirect dan Google Search. Lompat ke kutipan

Spesifikasi HTTP / MDN—jaminan teknis

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (terjemahan) “Kode status 307 (Temporary Redirect) menunjukkan bahwa sumber daya target sementara berada di URI berbeda dan user agent TIDAK BOLEH mengubah metode permintaan saat melakukan pengalihan otomatis ke URI itu.” — RFC 9110, §15.4.8. Baca bagian
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (terjemahan) “Karena alasan historis, user agent BOLEH mengubah metode dari POST menjadi GET pada permintaan berikutnya. Jika tidak diinginkan, gunakan kode status 307 (Temporary Redirect).” — RFC 9110, §15.4.3 (bagian 302). Baca bagian
• “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… 307 and 302 responses are identical when the request method is GET.” (terjemahan) “Perbedaan antara 307 dan 302 adalah 307 menjamin klien tidak mengubah metode dan body; respons 307 dan 302 identik jika metodenya GET.” — MDN, 307 Temporary Redirect. Lompat ke kutipan

John Mueller, Google—SEO dan pelestarian metode

• “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, ini sebenarnya tidak penting. Lebih seperti, entahlah… Apakah ini bekerja untuk API? Biasanya API bukan sesuatu yang perlu diindeks langsung di Search.” — episode 51, “Let’s talk redirects” (17 November 2022). PDF transkrip
• “And with 307, 308, it also forwards POST requests” (terjemahan) “Dan dengan 307 dan 308, POST juga diteruskan” (dibandingkan 301/302 yang meneruskan GET). — Episode yang sama.

John Mueller, Google—“phantom 307” HSTS

• “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… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (terjemahan) “Server Anda tidak mengembalikan 307; Chrome hanya menampilkannya demikian untuk menjelaskan bahwa Chrome melakukan redirect untuk Anda… 307 sebenarnya bukan redirect sama sekali, melainkan placeholder.” — John Mueller, HTTPS & HSTS: 301, 302, or 307? (johnmu.com, awalnya Google+, Juni 2016). Lompat ke kutipan
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (terjemahan) “Singkatnya, [Googlebot] tidak berinteraksi dengannya. Redirect 307 umumnya bukan redirect nyata.” — John Mueller, Ask Google Webmasters (Oktober 2020), melalui Search Engine Journal. Lompat ke kutipan

Zineb Ait Bahajji, Google—HSTS, 2015 (dilaporkan ulang)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (terjemahan) “Dengan HSTS diterapkan, Googlebot melihat redirect 301 (coba dengan Fetch as Google). 307 hanyalah ‘redirect internal’.” — Zineb Ait Bahajji (Google), melalui Twitter, dilaporkan Search Engine Roundtable (Desember 2015). Lompat ke kutipan

307 mana yang sebenarnya saya lihat?

Hampir setiap pertanyaan tentang 307 ternyata merujuk pada salah satu dari dua hal yang sama sekali berbeda. Ikuti alurnya.

Mitos dan kesalahan yang perlu dihindari

“307 tidak meneruskan ekuitas tautan seperti 302.” Pernyataan bahwa “307 lebih buruk daripada 302” itu keliru, meski masih beredar di blog SEO besar. Dokumentasi Google memperlakukan 307 dan 302 dengan cara yang sama: keduanya adalah redirect sementara dengan “weak signal” (terjemahan) “sinyal lemah” yang tidak mengonsolidasikan kanonikalisasi, dan dokumen HTTP Status Codes Google bahkan menyebut 307 “Equivalent to 302” (terjemahan) “Setara dengan 302”. Tidak ada dasar terdokumentasi untuk mengatakan 307 meneruskan lebih sedikit daripada 302. Penjelasan Google sebenarnya berlaku untuk redirect sementara secara umum: redirect ini memang bukan sarana mengonsolidasikan sinyal peringkat ke target seperti redirect permanen. Jangan mengubah konfigurasi hanya karena klaim “307 secara khusus menahan ekuitas”.

“307 di tab Network berarti server salah mengonfigurasi redirect.” Sering kali tidak demikian. Jika HSTS aktif dan browser sebelumnya menerima header Strict-Transport-Security, browser menampilkan upgrade http→https sebagai 307 hanya untuk menjelaskan prosesnya sendiri—server tidak pernah mengirimkannya (body 0 byte adalah petunjuknya). Sesi incognito baru biasanya memperlihatkan kode sebenarnya, tetapi tidak untuk domain dalam daftar HSTS preload bawaan browser. Untuk domain seperti itu, uji dengan redirect checker atau curl (tanpa konfigurasi HSTS) sebelum memburu kesalahan konfigurasi yang sebenarnya tidak ada.

“Googlebot melihat 307 yang sama seperti yang ditampilkan browser saya untuk situs HSTS.” Tidak persis. Perwakilan Google pernah mengatakan Googlebot melihat 301 (Zineb, 2015) atau sama sekali tidak berinteraksi dengan mekanisme 307/HSTS (Mueller, 2020). Bagaimanapun, yang dilihat crawler bukan “307” yang tampak bagi manusia. Anda tetap memerlukan 301 sisi server nyata untuk http→https jika jalur tersebut perlu ditemukan melalui crawling.

“303 dan 307 pada dasarnya dapat dipertukarkan.” Keduanya berlawanan pada sumbu yang penting. 303 selalu mengganti metode menjadi GET (pola Post/Redirect/Get), sedangkan 307 menjamin metode tidak berubah. Keduanya mudah tertukar hanya karena sama-sama termasuk kelompok “temporary” (terjemahan) “kelompok yang bersifat sementara” bersama 302.

“Ubah semua redirect sementara menjadi 307 agar peringkat naik.” Tidak ada kenaikan. Satu-satunya alasan yang sah untuk memilih 307 dibandingkan 302 adalah pelestarian metode/body yang memang diperlukan (atau preferensi future-proofing secara umum). Mengubah setiap 302 menjadi 307 tidak memberi manfaat dan justru berisiko menimbulkan kesalahan.

“302 selalu mengubah POST menjadi GET, jadi 302 pada dasarnya rusak untuk formulir.” Itu berlebihan. Konversi POST→GET memang menjadi masalah pada klien lama yang tidak konsisten—itulah alasan 307 tersedia sebagai opsi yang dijamin—tetapi browser modern jauh lebih konsisten. 307 menghapus ambiguitas melalui spesifikasi, bukan berarti 302 “rusak”.

Lihat kode status sebenarnya (bukan artefak HSTS)

Browser menyembunyikan 301/302 nyata di balik 307 palsu setelah HSTS tersimpan. Secara default curl tidak menerapkan HSTS, jadi pemanggilan biasa berbicara langsung dengan server dan menunjukkan kenyataannya—jangan menjalankannya dengan file cache --hsts, karena Anda akan memasukkan kembali penulisan ulang sisi klien yang ingin diperiksa.

Lacak seluruh rantai redirect, hanya header

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

Periksa kode status satu URL tanpa mengikuti redirect

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

Konsol Chrome DevTools — temukan 307 palsu

Tempelkan ini ke tab Console. Redirect server nyata mengekspos flag redirected dan URL yang sudah di-resolve; upgrade HSTS terjadi sebelum permintaan meninggalkan browser.

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

Anda juga dapat membaca catatan HSTS Chrome langsung di chrome://net-internals/#hsts—kueri sebuah domain untuk melihat apakah static_upgrade_mode/dynamic_upgrade_mode memaksa https (itulah yang menghasilkan 307 di tab Network).

Bookmarklet — intip header cepat untuk tab saat ini

Seret bookmark yang URL-nya berisi kode berikut, lalu klik bookmark itu di halaman mana pun untuk mencatat status URL saat ini dan keadaan redirect ke Console:

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

Catatan: fetch() browser tidak dapat membaca body redirect opaque lintas origin, jadi untuk pelacakan multi-hop yang otoritatif, gunakan curl -sIL di atas sebagai sumber kebenaran.

Mengembalikan 307 nyata

Tujuan mengembalikan 307 (bukan sekadar membiarkan default framework memilihnya) adalah menjamin metode dan body tetap bertahan. Berikut beberapa cara umum untuk mengaturnya secara eksplisit.

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js (App Router) — 307 adalah default, jadi Anda sering tidak perlu menulis kodenya:

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

Seperti apa respons 307 mentah

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

Seperti apa “phantom 307” HSTS (khusus browser)

Baris statusnya sama di DevTools, tetapi perhatikan petunjuknya—respons berasal dari browser, bukan server, dan memiliki body 0 byte:

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

Jika Anda melihat Non-Authoritative-Reason: HSTS (Chrome) atau “307” 0 byte yang menghilang saat diuji dengan klien tanpa HSTS, itulah artefaknya—bukan redirect yang dikirim server. Nama header dan label DevTools yang tepat adalah detail implementasi khusus Chrome, bukan jaminan spesifikasi HTTP atau HSTS; perlakukan contoh ini sebagai ilustrasi, bukan sesuatu yang dijadikan dasar otomasi lintas browser atau versi.

Metode, durasi, dan framework sumber

Sebelum mengubah 307, saya menilainya pada tiga sumbu:

1. Metode: apakah target harus menerima metode dan body permintaan asli? Jika ya, 307 adalah redirect sementara yang mempertahankan keduanya. Redirect GET halaman-ke-halaman biasa biasanya tidak memerlukan sifat itu.
2. Durasi: apakah perpindahan itu benar-benar sementara? Pertahankan 307 hanya selama URL asli diperkirakan akan kembali. Perpindahan permanen memerlukan keputusan redirect permanen, bukan status sementara tanpa batas.
3. Sumber: apakah server mengirim 307, framework memilihnya, atau browser membuat upgrade HSTS internal? “Internal Redirect” di DevTools bukan aturan origin yang harus ditulis ulang.

Alat untuk memisahkan 307s nyata dan palsu

• Redirect Checker: lihat status yang dapat diamati server, tujuan, dan setiap hop tanpa bergantung pada keadaan HSTS satu browser.
• Redirect Chain Mapper: gunakan tampilan per-hop ketika 307 menjadi bagian dari jalur redirect yang lebih panjang.
• HTTP Header Checker: periksa Location dan Strict-Transport-Security, lalu bandingkan petunjuk edge dengan origin.
• curl: jalankan curl -I http://example.com/path di luar tampilan HSTS internal browser. Uji pelestarian POST hanya pada endpoint aman yang Anda kendalikan.
• Browser DevTools: periksa apakah entri bertuliskan “Internal Redirect” dan memiliki transfer nol byte; itu mengarah pada upgrade HSTS yang dibuat browser.

Validasi 307 setelah deployment

Uji status dan tujuan

Uji yang dijalankan: periksa sumber dengan Redirect Checker atau curl -I. Hasil yang diharapkan: satu 307 dengan Location yang dituju. Interpretasi kegagalan: lapisan lain mengubah aturan atau target. Jendela pemantauan: segera. Pemicu rollback: loop, tujuan rusak, atau hostname yang tidak diinginkan muncul.

Uji pelestarian metode

Uji yang dijalankan: kirim POST yang aman ke rute pengujian terkendali dan periksa apa yang diterima target. Hasil yang diharapkan: target menerima POST dengan body asli. Interpretasi kegagalan: perantara mengubah metode atau menyajikan kode lain. Jendela pemantauan: segera. Pemicu rollback: permintaan formulir, webhook, atau checkout kehilangan metode atau body.

Uji pemisahan HSTS

Uji yang dijalankan: bandingkan DevTools (atau sesi incognito baru) dengan permintaan curl -I tanpa cache HSTS. Hasil yang diharapkan: “Internal Redirect” browser dapat dibedakan dari respons server nyata, dan HTTP tetap memiliki redirect sisi server. Interpretasi kegagalan: HSTS menutupi aturan origin yang hilang—ingat bahwa incognito saja tidak cukup untuk domain dalam daftar HSTS preload bawaan browser, karena keadaan itu tetap ada di luar riwayat penjelajahan. Jendela pemantauan: segera. Pemicu rollback: perubahan origin menghapus redirect HTTP-ke-HTTPS yang berfungsi.

Uji diri: 307 Temporary Redirect

Lima pertanyaan singkat tentang 307, cara Google memperlakukannya, dan artefak HSTS. Pilih satu jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Sumber yang layak dibaca

Tulisan terkait saya

• 11 Jenis Redirect & Dampaknya bagi SEO — sumber definisi 307, catatan HSTS, dan urutan pilihan saya (307 / 302 / 303 di depan).
• Kode Status HTTP & Dampaknya bagi SEO — artikel saya yang memisahkan dua entri 307: kasus redirect sementara dan kasus kebijakan HSTS.
• Panduan Pemula untuk SEO Teknis — konteks yang lebih luas tentang posisi redirect.

Presentasi saya

• Cara Kerja Penelusuran (SlideShare) — penjelasan saya tentang crawling, rendering, indexing, dan ranking, termasuk cara redirect ditangani. (Disclaimer tetap saya berlaku: “This is my understanding of systems… not going to be 100% complete or accurate.” (terjemahan) “Ini pemahaman saya tentang sistem… tidak akan 100% lengkap atau akurat.”)

Dari industri

• John Mueller — HTTPS & HSTS: 301, 302, atau 307? — penjelasan pihak pertama paling jelas tentang “phantom 307” HSTS (“your server’s not returning a 307” (terjemahan) “server Anda tidak mengembalikan 307”).
• Episode 51 tentang redirect (PDF transkrip) — Mueller dan Splitt tentang alasan 307/308 ada dan mengapa “for SEO, it doesn’t really matter” (terjemahan) “untuk SEO, ini sebenarnya tidak penting”.
• Google tentang Redirect 307/HSTS (Search Engine Journal) — rangkuman video Mueller: “307 redirects are generally not real redirects” (terjemahan) “redirect 307 umumnya bukan redirect nyata”.
• Googlebot Memperlakukan Redirect 307 seperti 301? (Search Engine Roundtable) — pernyataan Zineb Ait Bahajji tahun 2015 tentang apa yang dilihat Googlebot untuk HSTS.
• MDN — 307 Temporary Redirect — referensi teknis utama untuk jaminan metode/body.
• Panduan SEO untuk Crawling HSTS & Redirect 307 (Screaming Frog) — pembahasan konfigurasi crawler terbaik tentang 307 yang digerakkan HSTS.
• Next.js — referensi redirect() — alasan framework besar menjadikan redirect non-GET default 307.

Log perubahan