Pengalihan 303 (Lihat lainnya)

TL;DR — 303 See Other adalah pengalihan yang mengirim browser ke halaman berbeda dan mengambilnya dengan permintaan GET (atau HEAD). Fungsi utamanya adalah pola aplikasi web: setelah Anda mengirim formulir, server mengarahkan Anda ke halaman hasil sehingga penyegaran memuat ulang halaman hasil, bukan mengirim formulir asli lagi. Hampir tidak pernah Anda sengaja memakai 303 untuk SEO—ini urusan formulir dan aplikasi, bukan pesan bahwa “halaman ini pindah”. Bagian yang jujur: Google dan Bing tidak menerbitkan panduan SEO khusus 303 karena hampir tidak ada yang perlu dijelaskan.

Apa itu pengalihan 303

Saat browser meminta halaman, server menjawab dengan kode status HTTP tiga digit. 200 berarti “inilah halamannya”. 404 berarti “tidak ditemukan”. 303 berarti “See Other” (terjemahan) “Lihat lainnya”—jangan merender hal yang diminta secara langsung; ambil URL berbeda dan ambil resource itu dengan permintaan GET atau HEAD.

Peralihan ke GET atau HEAD itulah inti 303 dan yang membedakannya dari saudara-saudaranya. Penjelasan lebih lanjut ada sebentar lagi.

Satu hal yang memang menjadi tujuan kode ini

Bayangkan Anda mengirim formulir—pesanan, komentar, atau pembayaran. Browser mengirimkannya sebagai permintaan POST. Jika server langsung menggambar halaman konfirmasi dalam respons POST, Anda menghadapi masalah: tekan refresh, dan browser bertanya “want to resend this form?” (terjemahan) “ingin mengirim formulir ini lagi?” Muat ulang tanpa berpikir, dan pesanan Anda terkirim dua kali.

303 memperbaikinya. Alurnya seperti ini:

1. Anda mengirim formulir → browser mengirim POST.
2. Server memprosesnya, lalu menjawab dengan 303 yang menunjuk ke halaman hasil.
3. Browser mengikuti 303 dengan GET baru ke halaman hasil tersebut.

Sekarang Anda berada di halaman konfirmasi biasa yang dapat diambil dengan GET. Segarkan atau tekan kembali—yang terjadi hanyalah halaman itu diambil ulang, bukan POST asli dikirim lagi. Developer menyebutnya pola Post/Redirect/Get (PRG), dan 303 adalah “redirect” (terjemahan) “pengalihan” di tengahnya. Namun perlu tepat tentang manfaatnya: PRG mencegah pemutaran ulang akibat penyegaran browser, tetapi bukan jaminan tepat-satu-kali—percobaan ulang, klik ganda, timeout, dan permintaan bersamaan masih dapat membuat pesanan atau tagihan duplikat kecuali aplikasi memiliki perlindungan sendiri (kunci idempotensi dan pemeriksaan transaksi) pada operasi tulis.

Mengapa ini jarang penting untuk SEO

303 adalah perilaku aplikasi web, bukan alat migrasi halaman. Gunakan 301 saat URL berpindah permanen dan 302 saat berpindah sementara, tetapi hampir tidak pernah gunakan 303 untuk memindahkan halaman karena bukan itu tujuan kode ini. Seperti yang saya tulis di Ahrefs: “You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.” (terjemahan) “Biasanya Anda tidak akan melihat pengalihan 303 dipakai untuk SEO, tetapi jika ada, pengalihan itu diperlakukan seperti 302/307.”

Itulah kenyataan jujur dari topik ini: Google dan Bing tidak menerbitkan panduan SEO khusus 303. Google hanya menyebutnya sekali, dalam kelompok pengalihan “temporary” (terjemahan) “sementara” bersama 302 dan 307—pengalihan itu sendiri bukan sinyal bahwa target harus menjadi kanonis seperti pengalihan permanen 301, walaupun sinyal lain masih dapat membuat halaman target diindeks. Tidak ada perilaku rahasia 303 yang perlu dipelajari. Jika alat perayapan menandai 303 di situs Anda, hampir selalu itu pola aplikasi yang disengaja (alur formulir), bukan sesuatu yang rusak dan bukan sesuatu yang perlu “diperbaiki” (terjemahan) “diperbaiki secara khusus oleh tim Anda”. Evidence for this claim Google groups HTTP 303 with temporary redirects, follows it, and does not use it as a signal that the destination should become canonical. Scope: Google Search canonicalization behavior for server-side temporary redirects. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search

Jangan menyamakannya dengan halaman rusak atau pindah

Anda akan melihat beberapa situs menjelaskan 303 sebagai keadaan ketika “the page has moved” (terjemahan) “halaman telah berpindah” atau “the browser can’t find the URL.” (terjemahan) “browser tidak dapat menemukan URL.” Itu mencampuradukkannya dengan 301/302 atau error. 303 bukan tanda ada masalah—ini respons disengaja yang dikembalikan aplikasi Anda, biasanya tepat setelah formulir diproses.

Ingin perbandingan teknis dengan 302 dan 307, apa yang sebenarnya dikatakan dokumentasi Google (dan satu kalimat singkat John Mueller tentangnya), serta pandangan developer tentang kapan harus mengembalikan kode ini? Buka tab Advanced.

TL;DR — 303 (HTTP “303 See Other”) adalah pengalihan sementara yang mengarahkan klien mengambil resource lain dengan GET atau HEAD, apa pun metode permintaan aslinya. Inilah yang menggerakkan pola Post/Redirect/Get (PRG): POST → 303 → halaman hasil GET, sehingga penyegaran mengambil ulang halaman, bukan mengirim formulir lagi. Kode ini berbeda dari 307 (yang selalu mempertahankan metode) dan 302 (yang penanganan metodenya secara historis ambigu). 303 jarang benar-benar menjadi pengalihan SEO dari halaman ke halaman—ini mekanisme aplikasi web, bukan alat migrasi URL. Google hanya mendokumentasikan 303 sebagai anggota kelompok 3xx “temporary” (terjemahan) “sementara” bersama 302 dan 307—sinyal kanonisasi lemah—dan tidak menerbitkan panduan khusus 303; Bing juga tidak memiliki panduan yang saya temukan. Jangan mengarang otoritas yang tidak ada: katakan terus terang bahwa hanya sedikit yang bisa dikatakan.

Apa sebenarnya 303 itu

303 adalah kode status HTTP yang dikembalikan di header respons, sebelum body apa pun, dengan header Location yang menunjuk ke URL yang harus diambil klien berikutnya. Semantiknya sempit dan spesifik: respons atas permintaan Anda ada di tempat lain, dan Anda harus mengambilnya dengan GET atau HEAD. Evidence for this claim RFC 9110 defines 303 See Other as directing the client to retrieve another resource identified by Location using GET or HEAD. Scope: HTTP semantics for 303 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.4 — 303 See Other

Perilaku pengambilan GET atau HEAD itulah alasan 303 ada sebagai kode tersendiri, sekaligus sumbu yang membedakan tiga pengalihan yang bersifat sementara.

303 vs. 302 vs. 307: pertanyaan tentang metode

Dari sudut pandang SEO, ketiganya adalah pengalihan “temporary” (terjemahan) “sementara”—Google mengelompokkannya sebagai sinyal lemah. Namun secara teknis, ketiganya menjawab satu pertanyaan secara berbeda: saat klien mengikuti pengalihan, metode HTTP apa yang digunakannya?

303 dan 307 diperkenalkan, salah satunya, untuk menghilangkan ambiguitas di sekitar 302. Jika Anda ingin metode dipaksa menjadi GET setelah pengiriman formulir, gunakan 303. Jika metode asli harus dibawa terus (misalnya menerbitkan ulang POST ke endpoint baru), gunakan 307. 302 adalah jalan tengah historis yang longgar dan tidak menetapkan keduanya.

Perbedaan praktis lain: respons 303 tidak dapat di-cache secara default, sedangkan 301 dapat. Ini penting jika Anda khawatir browser atau CDN menyimpan target pengalihan secara tidak tepat—dengan 303, kekhawatiran itu tidak berlaku.

Pola Post/Redirect/Get, secara tepat

PRG adalah penggunaan kanonis 303 dan merupakan pola desain yang disengaja dan benar, bukan keadaan error:

1. Klien mengirim formulir sebagai POST (membuat pesanan, memposting komentar, atau menjalankan pembayaran).
2. Server memproses efek samping, lalu mengembalikan 303 See Other dengan header Location yang menunjuk ke URL hasil yang dapat diambil dengan GET (tanda terima, konfirmasi, atau tampilan resource yang diperbarui).
3. Klien mengikuti dengan GET (atau HEAD) ke URL itu. Riwayat dan tombol refresh browser kini menunjuk ke pengambilan yang aman dan idempoten—memuat ulang atau menekan kembali mengambil halaman hasil, bukan memutar ulang POST.

Manfaatnya: penyegaran browser biasa berhenti mengirim formulir lagi—tidak ada lagi dialog “confirm form resubmission” (terjemahan) “konfirmasi pengiriman ulang formulir”. Tetap tepat tentang batasnya: PRG mencegah jalur pemutaran ulang itu, bukan setiap penulisan duplikat. PRG tidak menjamin pemrosesan tepat satu kali. Percobaan ulang, timeout, klik ganda, dan permintaan bersamaan masih dapat menyalakan POST asli dua kali, jadi operasi yang mengubah keadaan—pesanan, pembayaran, komentar—tetap memerlukan kontrol tingkat aplikasi (kunci idempotensi, batas transaksi, dan deteksi permintaan duplikat) jika duplikasi merupakan risiko. Dalam API RESTful, Anda juga akan melihat 303 setelah PUT atau DELETE untuk mengirim klien ke representasi resource yang terpengaruh.

Bagaimana Google memperlakukan 303 (dan mengapa hampir tidak ada yang perlu diperlakukan)

Inilah temuan utama yang jujur untuk topik ini: Google tidak memiliki panduan SEO khusus 303. 303 hanya muncul dalam dokumentasi pengalihan Google sebagai satu baris di tabel pengalihan “temporary” (terjemahan) “sementara”, di samping 302 dan 307. Kerangka Google untuk seluruh kelompok itu jelas: crawler mengikuti pengalihan, tetapi alur pengindeksan tidak menggunakan pengalihan itu sendiri sebagai sinyal bahwa target harus menjadi kanonis—walaupun sinyal lain masih dapat membuat Google mengindeks target. Ini berbeda dari, dan lebih sempit daripada, kanonisasi kuat yang diberikan 301 permanen.

Tulisan informal John Mueller tentang jenis pengalihan bahkan lebih jelas. Setelah membahas 301, 302, dan 307 secara rinci, ia menyingkirkan 303 dalam satu catatan: “What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them.” (terjemahan) “Bagaimana dengan 303? 304,5? Jika Anda punya preferensi kuat terhadap jenis pengalihan lain, silakan gunakan.” Pelajaran praktis yang ia tambahkan adalah bagian berguna: “We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.” (terjemahan) “Kami harus menentukan URL mana yang akan menjadi tempat mengindeks konten, jadi jika Anda juga punya preferensi kuat tentang itu, tindak lanjuti dengan sinyal kanonisasi lain.” Dengan kata lain, jika Anda memakai 303 dan peduli URL mana yang diindeks, jangan mengandalkan jenis pengalihan; dukung dengan rel="canonical", tautan internal, dan sitemap.

Dokumentasi Google juga menambahkan catatan yang perlu diingat untuk semua kode ini: meskipun Google memperlakukan keduanya sama, Google meminta Anda “keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect.” (terjemahan) “ingat bahwa keduanya berbeda secara semantik. Gunakan kode status yang sesuai untuk pengalihan.” Jadi kenyataan bahwa “SEO tidak peduli” bukan izin untuk menempelkan 303 pada perpindahan permanen—gunakan kode yang benar-benar sesuai dengan maksud Anda agar klien lain berperilaku tepat.

Bagaimana Bing memperlakukan 303

Terus terang: saya tidak menemukan panduan publik khusus Bing tentang penanganan 303 selain referensi kode status HTTP umum di bantuan Bing Webmaster Tools. Tidak ada pernyataan terverifikasi dari Fabrice Canel atau pihak Microsoft lain yang menyoroti 303. Ini adalah data “kami tidak memiliki dokumentasi tentang hal ini” yang sah, bukan celah untuk ditutup—saya tidak akan mengisinya dengan asumsi bahwa Bing sekadar meniru perilaku yang dinyatakan Google. Ketiadaan dokumentasi bukan bukti bahwa penanganannya identik; jika Anda membutuhkan jawaban pasti untuk Bing, ini tetap pertanyaan terbuka.

Apakah 303 penting untuk SEO? Jarang.

Kesimpulan jujur saya, yang sejalan dengan tulisan publik saya: 303 bukan alat migrasi halaman. Dalam “11 Types Of Redirects & Their SEO Impact” (terjemahan) “11 Jenis Pengalihan dan Dampaknya pada SEO”, saya merangkum bahwa 303 mengarahkan pengguna ke resource yang mirip dan bersifat sementara; pola ini lazim mencegah pengiriman formulir ulang setelah tombol kembali. 303 biasanya bukan alat SEO, dan jika dipakai dalam konteks itu, perlakuannya seperti 302/307.

Saya akan menandai satu ketegangan jujur dalam arsip tulisan saya sendiri. Dalam “HTTP Status Codes & Their SEO Impact” (terjemahan) “Kode Status HTTP dan Dampaknya pada SEO”, saya menjelaskan perlakuan 303 sebagai “undefined… They may be treated as 301 or 302, depending on how they function.” (terjemahan) “tidak terdefinisi… Kode ini dapat diperlakukan sebagai 301 atau 302, bergantung pada cara kerjanya.” Kini saya akan membingkainya lebih tepat: dokumentasi Google yakin bahwa 303 berada dalam kelompok sementara/lemah bersama 302 dan 307. Alasan “tidak terdefinisi” terasa benar dalam praktik adalah karena 303 sangat jarang di dunia nyata sehingga Google tidak pernah perlu menjelaskan kasus tepinya secara publik—bukan karena ada perilaku tersembunyi yang lebih kuat. Mulailah dari default terdokumentasi (lemah/sementara, dikelompokkan dengan 302/307); perlakukan kejutan sebagai akibat kelangkaan, bukan aturan rahasia.

Kapan 303 bisa penting? Hampir hanya pada situs dengan alur formulir/checkout berat atau aplikasi berbasis API yang menampilkan 303 dalam perayapan kode status. Bahkan saat itu, jawabannya biasanya “ini bekerja sesuai tujuan, biarkan”. Jika Anda sengaja memindahkan URL, jangan gunakan 303—gunakan 301 (permanen) atau 302 (sementara), dan gunakan 308/307 bila secara khusus memerlukan pelestarian metode.

303 vs. 201, 202, dan 204: memilih status yang tepat untuk penulisan

303 bukan satu-satunya pilihan setelah permintaan yang mengubah keadaan, dan mudah memilihnya karena kebiasaan. Dalam API (berbeda dari alur formulir browser), tiga kode 2xx sering lebih sesuai:

• 201 Created—permintaan membuat satu atau beberapa resource secara sinkron, dan respons harus mengidentifikasi resource utama, di header Location jika ada, atau URI target itu sendiri. Gunakan ini saat pembuatan selesai dan Anda ingin klien langsung memiliki resource baru, tanpa putaran GET terpisah.
• 202 Accepted—permintaan diterima tetapi pemrosesan belum selesai (pekerjaan antrean atau tugas asinkron). Responsnya sengaja belum menentukan hasil: jelaskan status saat ini dan, idealnya, tunjukkan monitor status yang dapat di-poll klien.
• 204 No Content—tindakan berhasil dan tidak ada lagi yang perlu dikirim: tanpa body dan tanpa pengalihan. Respons berakhir pada bagian header.

303 memiliki bentuk yang berbeda dari ketiganya: kode ini dipakai ketika klien harus mengambil resource hasil yang diidentifikasi terpisah setelah operasi tulis—paling sering pola PRG di browser. 303 bukan pengganti langsung pembuatan sinkron (201), penerimaan asinkron (202), atau keberhasilan tanpa isi (204); masing-masing menyampaikan hasil yang berbeda, sedangkan pengalihan tidak.

Mitos umum

• “A 303 means the page moved or is broken.” (terjemahan) “303 berarti halaman pindah atau rusak.” Tidak. Ini respons disengaja yang mengubah metode—biasanya setelah POST/PUT/DELETE—bukan sinyal “konten dipindahkan” atau error. Situs yang menyebutnya “the browser can’t find the URL because the page moved” (terjemahan) “browser tidak dapat menemukan URL karena halaman pindah” sedang mencampurkannya dengan 301/302 atau 404.
• “A 303 passes SEO value like a 301.” (terjemahan) “303 meneruskan nilai SEO seperti 301.” Tidak. 303 bersifat sementara/lemah, dalam kelompok yang sama dengan 302 dan 307 menurut dokumentasi Google.
• “SEOs should reach for 303 as a general redirect.” (terjemahan) “Praktisi SEO sebaiknya memakai 303 sebagai pengalihan umum.” Kode ini tidak dirancang untuk itu. Ini pola sempit formulir/API; memakainya untuk migrasi URL biasa tidak lazim.
• “Google has detailed 303-specific rules.” (terjemahan) “Google memiliki aturan khusus 303 yang terperinci.” Tidak. Hanya satu penyebutan dalam kelompok dan sikap Mueller “feel free to use them” (terjemahan) “silakan gunakan”; itulah seluruh catatannya.
• “303 and 302 are technically identical.” (terjemahan) “303 dan 302 identik secara teknis.” Keduanya setara untuk SEO, tetapi tidak sama secara teknis: 303 mengubah permintaan lanjutan menjadi GET atau HEAD, sedangkan penanganan metode 302 secara historis tidak konsisten—itulah alasan 303 dan 307 diperkenalkan untuk menghilangkan ambiguitas.

Letak pembahasan ini

303 adalah satu kode dalam kelompok pengalihan sementara. Kerabat terdekatnya adalah 302 (pengalihan sementara longgar yang sering dikelompokkan bersamanya) dan 307 (kebalikannya yang mempertahankan metode—307 mempertahankan metode, 303 beralih ke GET atau HEAD). Kode ini berbeda dari 301, pengalihan permanen yang benar-benar mengonsolidasikan sinyal peringkat dan menjalankan migrasi URL yang tidak pernah dirancang untuk dilakukan 303. Untuk keluarga lengkap—301/308 permanen, 302/303/307 sementara, 404/410 hilang, dan error 5xx—lihat cluster kode status HTTP tempat halaman ini berada.

Memvalidasi alur 303 dengan aman

Sebelum mempercayai 303 di dunia nyata, periksa tanpa mengikuti otomatis secara membabi buta: inspeksi nilai Location itu sendiri (apakah absolut, relatif, dan dapat di-resolve), perhatikan loop atau rantai pengalihan yang tidak perlu, pastikan permintaan lanjutan benar-benar memakai GET atau HEAD, lalu periksa status dan isi respons akhir. Untuk alur formulir atau API, periksa juga log aplikasi untuk memastikan operasi tulis asli tidak diputar ulang.

Satu peringatan: jangan menggeneralisasi perilaku satu klien menjadi aturan universal. Perilaku pengikutan otomatis browser, klien HTTP, dan framework berbeda menurut produk, versi, dan konfigurasi—laporan tentang satu klien/versi bernama bukan bukti untuk semuanya. Pemeriksa tingkat URL dapat mengonfirmasi bentuk pengalihan dan tujuan, tetapi tidak dapat memvalidasi idempotensi, penanganan kredensial, atau keamanan lintas asal; itu tetap memerlukan pengujian alur pengiriman yang sebenarnya.

Ringkasan AI

Ringkasan padat versi Advanced:

• 303 = HTTP “303 See Other”—pengalihan sementara yang mengarahkan klien mengambil resource lain dengan GET atau HEAD, apa pun metode permintaan aslinya.
• Kode ini ada untuk pola Post/Redirect/Get (PRG): POST (pengiriman formulir) → 303 → halaman hasil GET/HEAD. Penyegaran atau tombol kembali kemudian mengambil ulang halaman hasil, bukan mengirim POST asli lagi. Ini menghentikan pemutaran ulang khusus akibat penyegaran browser—bukan jaminan tepat-satu-kali; percobaan ulang, timeout, klik ganda, dan permintaan bersamaan masih dapat menggandakan penulisan kecuali aplikasi memiliki kontrol sendiri (kunci idempotensi, pemeriksaan transaksi).
• Metode adalah sumbu perbedaannya: 303 beralih ke GET/HEAD; 307 selalu mempertahankan metode; 302 secara historis ambigu. 303 dan 307 diperkenalkan untuk menghilangkan ambiguitas 302.
• Tidak dapat di-cache secara heuristik hanya dari statusnya (berbeda dengan 301) —resource hasil yang diambil terpisah memiliki kebijakan cache sendiri.
• Bukan pengganti 201/202/204: 303 tepat ketika klien harus mengambil resource hasil terpisah; ini bukan pengganti pembuatan sinkron (201), penerimaan asinkron (202), atau keberhasilan tanpa isi (204).
• Kenyataan SEO—katakan terus terang: Google mendokumentasikan 303 hanya sebagai satu baris dalam kelompok pengalihan “temporary” (terjemahan) “sementara” bersama 302 dan 307. Pengalihan itu sendiri bukan sinyal bahwa target harus menjadi kanonis, walaupun sinyal lain masih dapat mengindeks target—lebih sempit daripada kanonisasi yang diberikan 301 permanen. Tidak ada panduan Google khusus 303, dan tidak ada yang saya temukan dari Bing (ketiadaan dokumentasi Bing bukan bukti bahwa Bing memperlakukannya identik dengan Google). John Mueller menyingkirkannya: “What about 303? … feel free to use them,” (terjemahan) “Bagaimana dengan 303? … Jika Anda punya preferensi kuat terhadap jenis pengalihan lain, silakan gunakan,” dan menambahkan bahwa jika Anda peduli URL mana yang diindeks, dukung dengan sinyal kanonisasi lain.
• Jarang relevan untuk SEO: ini pola aplikasi web, bukan alat migrasi URL. Panduan Ahrefs saya sendiri: “You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.” (terjemahan) “Biasanya Anda tidak melihat 303 dipakai untuk SEO, tetapi jika ada, perlakuannya seperti 302/307.”
• Jangan menyamakannya dengan halaman rusak/pindah—303 disengaja, bukan error. Untuk benar-benar memindahkan URL, gunakan 301 (permanen) atau 302 (sementara), bukan 303.

Dokumentasi resmi

Dokumentasi SEO dari sumber primer tentang 303 sangat sedikit—kode ini hanya disebut sekilas dan dikelompokkan dengan pengalihan sementara lain. Berikut referensi yang relevan.

Google

• Pengalihan dan Google Search —mencantumkan HTTP 303 (see other) dalam kelompok pengalihan “temporary” (terjemahan) “sementara” bersama 302 dan 307; tidak ada catatan penanganan khusus 303.
• Dampak kode status HTTP, jaringan, dan DNS terhadap Google Search — mencantumkan 303 (see other) di bagian 3xx dan menyatakan aturan umum bahwa Google memperlakukan kode sementara sebagai sinyal lemah, sambil mengingatkan bahwa kode tersebut “semantically different” (terjemahan) “berbeda secara semantik”.

Bing / Microsoft

• Tidak ditemukan panduan khusus 303. Bantuan Bing Webmaster Tools membahas kode status HTTP secara umum, tetapi tidak menyoroti 303.

Referensi teknis (bukan sumber SEO)

• MDN—303 See Other —referensi cepat dan berguna untuk kasus PUT/POST/DELETE serta PRG, meskipun frasa “always GET” (terjemahan) “selalu GET” lebih longgar daripada spesifikasi saat ini (lihat di bawah).
• RFC 9110—HTTP Semantics, §15.4.4 —definisi teknis yang berlaku: target Location tidak ekuivalen dengan target asli, dan user agent mengambilnya dengan GET atau HEAD, bukan selalu GET.

Kutipan dari sumber

Pernyataan tercatat yang berkaitan dengan 303. Jumlahnya hanya sedikit—kelangkaan itu adalah cerita topik ini, jadi berikut adalah batas jujurnya, bukan daftar yang dipanjangkan. Setiap tautan langsung menuju bagian yang dikutip.

Google / John Mueller—catatan yang sangat singkat tentang 303

• “What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them. We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.” (terjemahan) “Bagaimana dengan 303? 304,5? Jika Anda punya preferensi kuat terhadap jenis pengalihan lain, silakan gunakan. Kami harus menentukan URL untuk mengindeks konten; jika Anda juga punya preferensi kuat tentang itu, tindak lanjuti dengan sinyal kanonisasi lain.” —John Mueller, blog pribadi, A search-engine guide to 301, 302, 307…. Ini adalah pernyataan paling langsung tentang 303 dari siapa pun di Google dan merupakan sikap meremehkan yang disengaja. Lompat ke kutipan

Google—perlakuan “kelompok sementara” yang diwarisi 303

• “By default, Google’s crawlers follow the redirect… Google systems use the redirect as a weak signal that the redirect target should be processed.” (terjemahan) “Secara default, crawler Google mengikuti pengalihan… Sistem Google menggunakan pengalihan sebagai sinyal lemah bahwa target pengalihan harus diproses.” (Penanganan pengalihan sementara yang dinyatakan Google, yaitu kelompok tempat 303 berada.) —Google Search Central, How HTTP status codes… affect Google Search. 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…” (terjemahan) “Walaupun Google memperlakukan kode status ini dengan cara yang sama, ingat bahwa keduanya berbeda secara semantik. Gunakan kode status yang sesuai untuk pengalihan…” Lompat ke kutipan

MDN—frasa umum yang perlu diluruskan

• “The method used to display this redirected page is always GET.” (terjemahan) “Metode yang dipakai untuk menampilkan halaman hasil pengalihan ini selalu GET.” —MDN, 303 See Other. Lompat ke kutipan —Ini perlu ditandai, bukan diulang tanpa kritik: spesifikasi saat ini lebih permisif daripada “always GET” (terjemahan) “selalu GET”. RFC 9110 §15.4.4 mendefinisikan pengambilan lanjutan sebagai GET atau HEAD, dan target Location sebagai resource berbeda yang tidak ekuivalen—fakta teknis yang membedakan 303 dari 307 (mempertahankan metode) dan 302 (secara historis ambigu).

Patrick (Ahrefs) —kesimpulan praktis tentang SEO

• “A 303 redirect forwards the user to a resource similar to the one requested and is a temporary form of redirect. It’s typically used for things like preventing form resubmissions when a user hits the ‘back’ button in their browser. You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.” (terjemahan) “Pengalihan 303 mengirim pengguna ke resource yang mirip dengan yang diminta dan merupakan bentuk pengalihan sementara. Biasanya digunakan untuk mencegah pengiriman formulir ulang saat pengguna menekan tombol kembali di browser. Anda biasanya tidak akan melihat 303 dipakai untuk SEO, tetapi jika ada, perlakuannya seperti 302/307.” —Patrick Stox, “11 Types Of Redirects & Their SEO Impact” (terjemahan) “11 Jenis Pengalihan dan Dampaknya pada SEO” (Ahrefs). Lompat ke kutipan

Penyalahgunaan 303 See Other

Memperlakukan 303 sebagai kode umum “halaman pindah”

303 dibuat untuk mengirim klien ke resource lain dengan GET atau HEAD, biasanya setelah permintaan yang mengubah keadaan. Gunakan 301 untuk perpindahan halaman permanen dan 302 untuk pengalihan halaman sementara biasa.

Menggunakan 303 saat metode asli harus bertahan

Kode ini sengaja membuang metode asli untuk permintaan lanjutan. Jika POST, PUT, DELETE, webhook, atau payload API harus tiba di tujuan secara utuh, gunakan 307 (sementara) atau 308 (permanen).

Menggambarkan 303 sebagai sinyal SEO permanen yang kuat

Google mengelompokkan 303 dengan pengalihan sementara, bukan 301/308. Jangan memakainya untuk mengonsolidasikan migrasi URL atau mengklaim bahwa perilakunya seperti perpindahan permanen.

Menganggap Google atau Bing menerbitkan aturan 303 yang terperinci

Google hanya memberikan perlakuan kelompok untuk pengalihan sementara, dan tidak ada panduan publik khusus Bing yang teridentifikasi dalam artikel ini. Batasi kesimpulan, jangan menutup celah dokumentasi dengan kepastian yang dibuat-buat.

Menganggap 302 dan 303 identik secara teknis

Perlakuan penelusurannya mungkin dikelompokkan, tetapi semantik metodenya berbeda. 303 menindaklanjuti dengan GET atau HEAD; 302 secara historis mengizinkan perilaku POST-ke-GET yang ambigu.

Mengklaim perilaku klien, kredensial, atau lintas asal yang universal

Jangan menyatakan sebagai fakta bagaimana “browser” atau “klien” menangani body permintaan, header, cookie, atau kredensial pada 303 tanpa menyebut klien, versi, dan konfigurasi tertentu. Perilaku pengikutan otomatis dan penerusan kredensial berbeda-beda; satu thread isu atau anekdot bukan bukti untuk semua klien, dan bukan pengganti tinjauan keamanan Anda sendiri atas alur yang sebenarnya.

Post/Redirect/Get dalam HTTP mentah

Alur sederhana ini menunjukkan pekerjaan sempit yang dilakukan 303 dengan baik.

1. Browser mengirim formulir

POST /orders HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

item=book&quantity=1

2. Server memprosesnya dan menunjuk hasil

HTTP/1.1 303 See Other
Location: /orders/confirmation

303 tidak mengulangi POST ke URL baru. Kode ini secara eksplisit memberi tahu klien untuk mengambil resource lain dengan GET (atau HEAD) —browser yang mengikuti tautan melakukannya dengan GET.

3. Browser mengambil halaman hasil yang aman

GET /orders/confirmation HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Order received</h1>

Penyegaran sekarang mengulangi GET, bukan POST yang membuat pesanan. Sebaliknya, 307 akan mempertahankan POST beserta isinya—berguna untuk memindahkan permintaan API, tetapi salah untuk hasil PRG ini.

Uji diri: 303 See Other

Lima pertanyaan singkat tentang pengalihan 303. Pilih jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan