502 Gateway Buruk

TL;DR — 502 Bad Gateway berarti satu server meminta server lain mengirimkan halaman Anda, tetapi menerima jawaban yang buruk. Biasanya server “depan” (terjemahan) “front” itu adalah CDN atau proxy, sedangkan server “belakang” (terjemahan) “back” adalah situs web Anda yang sebenarnya (origin). Error ini berada di hosting/infrastruktur Anda—bukan di Google Search Console. 502 yang berlangsung singkat biasanya membawa risiko SEO praktis yang terbatas, meskipun Google tidak menerbitkan durasi “safe” (terjemahan) “aman” yang pasti. Masalahnya menjadi lebih besar semakin lama error tersebut berlangsung.

Apa itu 502 Bad Gateway

Saat Anda memuat halaman, permintaan sering kali tidak langsung menuju situs web Anda. Permintaan melewati perantara—CDN (seperti Cloudflare), load balancer, atau reverse proxy (seperti Nginx). Perantara itu meneruskan permintaan ke server Anda yang sebenarnya, menunggu respons, lalu meneruskannya kembali kepada pengunjung.

502 Bad Gateway adalah respons yang ditampilkan perantara ketika meminta halaman dari server Anda tetapi menerima sesuatu yang tidak valid—atau tidak menerima apa pun. Dalam istilah sederhana: server depan tidak mendapatkan jawaban yang baik dari server belakang. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Itulah nuansa pentingnya. 502 tidak otomatis berarti situs web Anda mati. Server Anda mungkin sehat dan menjawab permintaan langsung dengan baik, tetapi jika proxy di depannya tidak dapat menjangkaunya (karena timeout, setelan yang salah, atau CDN sedang bermasalah), pengunjung tetap melihat 502.

Perbedaannya dari kode-kode sejenis

Anda akan melihat beberapa error 5xx yang tampak mirip:

• 500 — kode situs web Anda sendiri mengalami error saat membangun halaman.
• 502 — proxy di depan situs mendapatkan respons buruk dari situs tersebut.
• 503 — situs Anda sengaja tidak tersedia (pemeliharaan terencana atau kelebihan beban).
• 504 — proxy menunggu server Anda, tetapi timeout tanpa jawaban sama sekali.

Kode-kode ini berkaitan, tetapi menunjuk ke tempat berbeda yang perlu diperiksa.

Apakah 502 merugikan SEO Anda?

Biasanya tidak banyak—selama tidak berlangsung lama. Crawler Google (Googlebot) memperlakukan 502 seperti error 5xx lainnya: laju crawl diperlambat sebanding dengan jumlah URL Anda yang mengalami error, lalu dinaikkan kembali setelah situs mulai merespons dengan 2xx. Google tidak menerbitkan durasi “safe” (terjemahan) “aman” yang pasti, tetapi 502 singkat—beberapa menit hingga beberapa jam—membawa risiko praktis jauh lebih kecil daripada error yang terus terjadi. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Risiko nyata muncul ketika 502 terus berulang atau tetap aktif dalam waktu lama. Rumusan Google sendiri menyatakan bahwa URL yang “persistently” (terjemahan) “terus-menerus” mengembalikan error server akan dihapus—Google tidak mendefinisikannya sebagai jumlah hari tertentu. John Mueller dari Google pernah menyebut “multiple days” (terjemahan) “beberapa hari” secara informal sebagai kira-kira titik ketika halaman mulai keluar, dan halaman biasanya kembali setelah situs pulih. Namun, anggap itu sebagai pembacaan kasar satu orang atas insiden tertentu, bukan aturan resmi.

Apa yang harus dilakukan

• Jangan mencoba “fix” (terjemahan) “memperbaiki” 502 di Search Console. Search Console hanya melaporkan 502 setelah kejadian. Perbaikannya dilakukan pada CDN, proxy, atau server Anda.
• Periksa apakah masalah hanya terjadi pada Anda atau pada semua orang. Jika internet secara umum baik tetapi situs Anda mati, masalahnya ada di penyiapan Anda. Jika CDN besar sedang mengalami pemadaman, mungkin itu sama sekali bukan kesalahan Anda—tidak ada yang dapat diperbaiki di pihak Anda selain menunggu.
• Lihat halaman status host atau CDN dan log server Anda. Di situlah jawaban sebenarnya berada.

Ingin diagnosis lapis demi lapis (CDN vs. proxy vs. origin), penjelasan persis dokumentasi Google, dan rangkuman ucapan John Mueller saat pemadaman Cloudflare November 2025? Buka tab Advanced.

TL;DR — 502 adalah kegagalan lapisan proxy/gateway: RFC 9110 §15.6.3 mendefinisikannya sebagai gateway atau proxy yang menerima respons tidak valid dari server inbound. Kode ini berbeda dari 500 (aplikasi origin mengalami error) dan 503 (origin sengaja tidak tersedia). Dokumentasi Google mengelompokkan 500, 502, dan 503 dalam perlakuan 5xx yang sama—laju crawl turun sebanding dengan jumlah URL yang error, konten 5xx diabaikan, dan error yang terus-menerus membuat halaman keluar dari indeks. Pemulihan berlangsung bertahap setelah 2xx kembali, meskipun Google tidak menerbitkan linimasa tetap. Durasi penting, tetapi tidak ada ambang resmi: lonjakan singkat jauh lebih kecil risikonya, sedangkan error yang terus berulang menempatkan halaman pada risiko nyata—ucapan informal Mueller pada November 2025 menyebut kira-kira beberapa hari, bukan SLA terdokumentasi. Diagnosis harus dilakukan per lapisan—CDN, reverse proxy, atau origin—dengan mengorelasikan bukti di antara hop, bukan hanya mempercayai halaman error bermerek.

Apa yang sebenarnya ditandakan 502

RFC 9110 §15.6.3 mendefinisikan 502 secara spesifik: gateway atau proxy menerima respons tidak valid dari server inbound yang diaksesnya ketika mencoba memenuhi permintaan. Batas spesifikasi itu penting — ia mengidentifikasi lokasi gateway mengamati kegagalan, bukan selalu hop yang menyebabkannya. Status 502 adalah bukti kegagalan pada batas tersebut, bukan bukti aplikasi origin rusak. Perbedaan itu yang dikaburkan banyak tulisan pesaing tentang “13 ways to fix it” (terjemahan) “13 cara memperbaikinya”, sehingga diagnosis di bawah disusun berlapis, bukan datar.

Bandingkan kode 5xx yang mudah tertukar:

• 500 Internal Server Error — aplikasi origin sendiri mengalami error (bug kode, exception yang tidak ditangani, atau kehabisan sumber daya). Origin menjawab, dan jawabannya adalah “I broke.” (terjemahan) “Saya rusak.”
• 502 Bad Gateway — proxy menerima jawaban salah format atau tidak valid dari upstream (RFC 9110 §15.6.3).
• 503 Service Unavailable — origin sengaja tidak tersedia; ini kode yang disengaja dan disarankan Google untuk “come back later” (terjemahan) “kembali lagi nanti” saat pemeliharaan terencana, idealnya dengan header Retry-After.
• 504 Gateway Timeout — proxy menunggu upstream tetapi mendapat tidak ada jawaban sebelum timeout berakhir (RFC 9110 §15.6.5). (502 = jawaban buruk; 504 = tidak ada jawaban tepat waktu.)

Kesimpulan praktisnya: 503 adalah kode yang Anda pilih dengan sengaja; 502 adalah kode yang terjadi pada Anda ketika infrastruktur gagal.

Cara Googlebot menangani 502

Inilah bagian yang perlu didasarkan pada dokumentasi Google yang sebenarnya, bukan klaim samar “it can hurt rankings” (terjemahan) “ini dapat merugikan peringkat” yang Anda baca di tempat lain. Dokumen HTTP and network errors Google mencantumkan 502 (bad gateway) sebagai kode 5xx dan memberi semua kode 5xx perlakuan yang sama:

• Laju crawl turun secara proporsional. Google menurunkan laju crawl situs, dan penurunannya sebanding dengan jumlah URL individual yang mengembalikan error server. Beberapa 502 berdampak kecil; 502 di seluruh situs adalah perintah tegas untuk “slow down” (terjemahan) “melambat”.
• Konten 5xx diabaikan. Apa pun yang diterima Google dari URL yang mengembalikan 5xx diabaikan—Google tidak akan mengindeks halaman error 502 sebagai konten Anda.
• Pemeliharaan indeks bersifat sementara. URL yang sudah terindeks pada awalnya tetap berada di indeks, tetapi pipeline pengindeksan Google menghapus URL yang terus-menerus mengembalikan error server.
• Pemulihan otomatis dan bertahap. Setelah server kembali merespons dengan 2xx, Google secara bertahap menaikkan laju crawl. Untuk pemulihan biasa, tidak diperlukan pengiriman ulang, permintaan pertimbangan ulang, atau aksi “validate fix” (terjemahan) “validasi perbaikan”—tombol itu hanya meminta Google memeriksa kembali lebih cepat.

Inti terpentingnya: 502 diperlakukan sama seperti 500 dan 503. Kode ini bukan “less serious” (terjemahan) “kurang serius” hanya karena berasal dari lapisan proxy/CDN, bukan aplikasi origin. Tidak ada keringanan 502 yang terdokumentasi. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Durasi adalah keseluruhan ceritanya

Apakah 502 benar-benar merugikan Anda bergantung pada berapa lama berlangsungnya—tetapi Google tidak menerbitkan durasi aman atau ambang keluarnya halaman yang pasti. Jadi, anggap penjelasan berikut sebagai konteks praktis, bukan SLA:

• Lonjakan singkat (beberapa menit hingga beberapa jam) → penurunan laju crawl Google mengikuti jumlah URL yang error, sehingga lonjakan kecil dan singkat biasanya berdampak praktis terbatas dan umumnya tidak perlu dikejar di Search Console. Dokumentasi Google tidak secara formal mengecualikan error singkat—ini soal tingkat keparahan, bukan batas tegas.
• Error yang terus berulang atau tetap aktif → inilah rentang ketika bahasa Google tentang “persistently return a server error” (terjemahan) “terus-menerus mengembalikan error server” berlaku, dan halaman dapat mulai keluar dari indeks. Google tidak mendefinisikan “persistently” (terjemahan) “terus-menerus” sebagai jumlah hari tertentu. Komentar publik Mueller (di bawah) secara informal menyebut multiple days (terjemahan) “beberapa hari”, dengan pemulihan cukup cepat setelah situs sehat—tetapi itu pembacaan praktisi atas satu insiden, bukan aturan terdokumentasi yang dapat diandalkan untuk setiap situs atau CDN.

Hal ini secara longgar sesuai dengan pemadaman Cloudflare November 2025, ketika gelombang situs mengeluarkan error 5xx bukan karena kesalahan mereka sendiri. Balasan publik Mueller di Bluesky menyatakan bahwa crawl 5xx melambat tetapi “ramps back up” (terjemahan) “kembali meningkat”—lihat tab Quotes untuk redaksi persis dan catatan sumber, termasuk komentar terpisah tentang “multiple days” (terjemahan) “beberapa hari” yang disampaikan melalui rangkuman pihak ketiga, bukan diverifikasi terhadap utas asli. Pemadaman singkat yang dikonfirmasi penyedia mendekati kasus terbaik: terlihat, biasanya pulih sendiri, dan setelah penyedia mengonfirmasi pemulihan serta respons 2xx Anda kembali, tindakan wajar biasanya menunggu, bukan mengubah infrastruktur secara reaktif.

Mendiagnosis 502 berdasarkan lapisan

Karena 502 adalah kegagalan komunikasi antarserver, cara tercepat menemukannya adalah menelusuri tumpukan dari bawah ke atas—CDN, lalu reverse proxy, lalu origin—alih-alih menjalankan checklist datar. (Tab Decision Trees berisi panduan langkah demi langkah ini.)

Satu peringatan sebelum mulai: halaman error bermerek, nama penyedia di header, atau “look” (terjemahan) “tampilan” pemadaman hanyalah satu sinyal bukti, bukan bukti hop mana yang gagal. Korelasikan dengan header respons, ID permintaan/trace, dan log bertanda waktu di kedua sisi hop sebelum menyimpulkan “it’s the CDN” (terjemahan) “ini CDN” atau “it’s my origin.” (terjemahan) “ini origin saya.”

Lapisan CDN/edge

• Timeout upstream: node edge tidak mendapat respons dari origin tepat waktu.
• Edge sama sekali tidak dapat menjangkau origin—kegagalan resolusi DNS, kegagalan handshake SSL/TLS, atau firewall/keamanan origin yang memblokir rentang IP CDN.
• Penyebab terdokumentasi berbeda-beda menurut penyedia: dokumentasi troubleshooting Cloudflare menjelaskan skenario konektivitas origin dan timeout khusus jaringan edge-nya, sementara CloudFront AWS mendokumentasikan penyebab TLS, DNS, port, dan fungsi origin sendiri. Periksa dokumentasi CDN Anda, jangan menganggap daftar penyebab satu penyedia berlaku untuk penyedia lain.
• Pemadaman penyedia CDN sendiri (Cloudflare, Fastly, AWS, dan lainnya)—peristiwa 502 massal di situs-situs yang tidak berkaitan, tanpa hubungan dengan kesehatan server Anda. Konfirmasikan melalui halaman status penyedia, bukan hanya branding pada halaman error.

Lapisan reverse proxy/load balancer (Nginx, Apache mod_proxy, HAProxy)

• Timeout backend atau koneksi ditolak.
• Blok upstream proxy_pass salah konfigurasi dan menunjuk ke tempat yang keliru.
• Pool backend habis—semua worker upstream sedang sibuk.
• Ketidakcocokan SSL/TLS antara proxy dan backend.

Lapisan server origin

• Aplikasi/PHP-FPM crash atau restart, atau OOM kill (batas memori terlampaui).
• Koneksi database habis.
• Deployment/restart yang menyebabkan ketidaktersediaan singkat.
• WAF atau plugin keamanan memblokir IP proxy atau crawler yang sah seolah-olah penyerang. Ini yang sulit dideteksi karena browser biasa tetap berfungsi sementara proxy (atau Googlebot) mendapat 502.

Pola terakhir itu patut ditekankan: jika hanya Googlebot atau hanya permintaan melalui CDN yang mendapat 502 sementara browser biasa tidak, Anda sedang melihat blokir khusus bot atau masalah respons yang bervariasi, bukan pemadaman sebenarnya. Uji langsung ke origin dibandingkan melalui CDN, dan verifikasi apa yang benar-benar dilihat Googlebot dengan pengujian langsung Inspeksi URL di Search Console, bukan mengasumsikan dampak berkelanjutan dari laporan error server (5xx) yang mungkin sudah kedaluwarsa.

Memperbaiki dan mencegah 502

Perbaikan bergantung pada lapisan, dan pihak yang harus melakukannya berbeda menurut peran:

• Pengunjung — tidak ada yang perlu diperbaiki. Muat ulang sekali, coba jaringan lain jika menduga masalah lokal, dan jika tidak, tunggu; perubahan di browser tidak dapat memperbaiki kegagalan antarserver.
• Pemilik situs tanpa akses infrastruktur — konfirmasikan cakupan, lalu periksa halaman status/log terlebih dahulu (lihat checklist di bawah). Setelah itu eskalasikan ke host, dukungan CDN, atau tim pengembang, bukan menebak-nebak perbaikan.
• Pemilik host/CDN/aplikasi — perbaiki konfigurasi proxy/upstream, tingkatkan timeout dan kapasitas backend jika origin adalah bottleneck, serta jadwalkan deployment bertahap agar restart tidak mengganggu seluruh pool. Perlakukan allowlisting WAF, perubahan firewall, dan edit konfigurasi proxy/upstream sebagai perubahan yang memerlukan persetujuan—terapkan hanya setelah log dan bukti penyedia menunjukkan kegagalan firewall atau kontrol akses; allowlisting CDN atau crawler bukan perbaikan 502 generik.

Untuk pencegahan, hal-hal membosankan justru paling efektif: pemantauan uptime dengan alert, pemantauan log error server dan proxy, memantau Host status statistik crawl serta tren Server error (5xx) di Search Console, dan mengorelasikan lonjakan dengan halaman status penyedia CDN dan DNS agar Anda dapat membedakan “my problem” (terjemahan) “masalah saya” dari “their outage” (terjemahan) “pemadaman mereka” dalam hitungan detik.

Kode terkait yang perlu dibedakan berada tepat di sebelahnya dalam cluster ini: error origin 500, 503 yang disengaja, dan timeout 504.

Ringkasan AI

Ringkasan singkat versi Advanced:

• 502 = kegagalan lapisan proxy/gateway. RFC 9110 §15.6.3 mendefinisikannya sebagai gateway atau proxy yang menerima respons tidak valid dari server inbound—bukti kegagalan pada batas tersebut, bukan bukti hop mana (CDN, proxy, atau origin) yang menyebabkannya. Origin dapat sehat sementara pengunjung tetap melihat 502.
• Penyebabnya berbeda, tetapi keluarga dokumentasinya sama. 500 (aplikasi origin error), 502 (proxy menerima jawaban buruk, RFC §15.6.3), 503 (origin sengaja tidak tersedia), 504 (proxy tidak mendapat jawaban tepat waktu, RFC §15.6.5). Dokumentasi Google mengelompokkan 500, 502, dan 503 dalam satu perlakuan 5xx—tidak ada kesetaraan khusus per status di luar aturan keluarga itu.
• Respons Googlebot: laju crawl turun sebanding dengan jumlah URL yang error, konten 5xx diabaikan, URL terindeks dipertahankan dalam jangka pendek tetapi dihapus jika error terus-menerus, dan crawl kembali meningkat bertahap setelah 2xx pulih. Google tidak menerbitkan durasi aman atau linimasa pemulihan yang dijamin.
• Durasi penting, tetapi tidak ada ambang resmi. Lonjakan singkat membawa risiko praktis jauh lebih kecil; error yang terus berulang adalah risiko nyata. Komentar informal Mueller pada November 2025 menyebut halaman mulai keluar sekitar “multiple days” (terjemahan) “beberapa hari”, dengan pemulihan yang cukup cepat—anggap itu pembacaan praktisi atas satu insiden, bukan SLA terdokumentasi.
• Diagnosis dilakukan dengan mengorelasikan bukti di seluruh lapisan, bukan hanya mempercayai branding: CDN (timeout, kegagalan DNS/SSL, pemadaman penyedia—Cloudflare dan AWS CloudFront masing-masing mendokumentasikan penyebab khusus platform) → reverse proxy (proxy_pass buruk, pool habis, koneksi ditolak) → origin (crash app/PHP-FPM, OOM, koneksi DB habis, WAF memblokir IP proxy/crawler). Cocokkan header, ID trace, dan log bertanda waktu di kedua sisi hop sebelum menyimpulkan lapisan yang gagal.
• Perbaikannya tidak seragam untuk semua kasus. GSC hanya melaporkan 502 setelah kejadian dan tidak dapat memperbaikinya. Pengunjung juga tidak dapat memperbaikinya; pemilik situs tanpa akses infrastruktur harus melakukan eskalasi, bukan mengedit konfigurasi. Perubahan destruktif—allowlisting WAF, firewall, atau proxy—harus mengikuti bukti log/penyedia, bukan tebakan respons pertama. Jika hanya Googlebot atau permintaan melalui CDN yang mendapat 502, curigai blokir khusus bot, bukan pemadaman global.

Dokumentasi resmi

Dokumentasi sumber utama tentang cara mesin pencari menangani error 5xx, termasuk 502.

Google

• Cara kode status HTTP memengaruhi crawler Google — dokumentasi kanonis; mencantumkan 502 (bad gateway) bersama 500 dan 503 serta menjelaskan perlakuan laju crawl/pengindeksan yang sama.
• Cara menangani waktu henti situs yang direncanakan — mengapa 503 (bukan 502, 404, atau 200) adalah kode yang tepat untuk waktu henti disengaja, dengan header Retry-After. Berguna untuk membedakan 502 dan 503.
• Spesifikasi robots.txt — menangani galat server — cara Google memperlakukan 5xx pada berkas robots.txt itu sendiri.

Spesifikasi

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — definisi tingkat spesifikasi: gateway atau proxy menerima respons tidak valid dari server inbound yang diakses ketika mencoba memenuhi permintaan. Ini mengidentifikasi batas tempat kegagalan diamati, bukan hop yang menyebabkannya.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — Bing menampilkan masalah crawl sisi server (kelas 5xx), termasuk kegagalan konektivitas, dalam laporan error crawl-nya.

Kutipan dari sumber

Pernyataan Google yang tercatat. Setiap tautan mengarah langsung ke bagian yang dikutip.

Google — cara penanganan 5xx (termasuk 502)

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (terjemahan) “Error server 5xx dan 429 mendorong crawler Google untuk sementara memperlambat crawl. Dalam Google Search, URL yang sudah terindeks dipertahankan dalam indeks, tetapi akhirnya dihapus.” — Google Search Central, How HTTP status codes affect Google’s crawlers. Lompat ke kutipan
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (terjemahan) “Google menurunkan laju crawl situs. Penurunan laju crawl sebanding dengan jumlah URL individual yang mengembalikan error server. Dalam Google Search, pipeline pengindeksan Google menghapus dari indeks URL yang terus-menerus mengembalikan error server.” — dokumen yang sama, baris tabel untuk 500, 502, dan 503. Lompat ke kutipan
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (terjemahan) “Setelah server kembali merespons dengan kode status 2xx, Google secara bertahap menaikkan laju crawl situs.” — dokumen yang sama. Lompat ke kutipan

John Mueller, Google (Bluesky, 18 November 2025—menjawab utas tentang lonjakan 5xx akibat pemadaman Cloudflare)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (terjemahan) “Ya. 5xx = crawl Google melambat, tetapi akan kembali meningkat.” Lihat posting
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (terjemahan) “Jika tetap 5xx selama beberapa hari, halaman mungkin mulai keluar, tetapi bahkan setelah itu halaman akan kembali cukup cepat.” Disampaikan melalui tulisan Matt G. Southern di Search Engine Journal tentang pertukaran yang sama; konfirmasikan terhadap utas asli sebelum menganggapnya final. Baca liputan

Checklist respons 502 Bad Gateway

Saat 502 muncul—di browser, pemantauan, atau laporan Server error (5xx) Search Console—gunakan daftar ini. Tag peran: [Apa pun] berlaku baik Anda memiliki akses infrastruktur maupun tidak; [Pemilik Host/CDN/Aplikasi] membutuhkannya.

• [Apa pun] Pastikan error nyata dan masih terjadi—reproduksi URL sekarang; laporan Server error (5xx) dapat tertinggal dari gangguan singkat yang sudah pulih.
• [Apa pun] Periksa cakupan—satu URL, satu bagian, atau seluruh situs? (Dampak crawl mengikuti jumlah URL yang error.)
• [Apa pun] Periksa halaman status penyedia CDN/DNS untuk pemadaman seluruh penyedia sebelum menyentuh konfigurasi sendiri.
• [Pemilik Host/CDN/Aplikasi] Uji langsung ke origin vs. melalui CDN—jika origin menjawab 2xx secara langsung tetapi CDN mengembalikan 502, masalah berada di edge atau di antaranya.
• [Pemilik Host/CDN/Aplikasi] Periksa apakah hanya bot/IP CDN yang mendapat 502 sementara browser baik-baik saja—ini mengarah pada kemungkinan blokir WAF/firewall, bukan pemadaman. Konfirmasikan di log firewall/WAF sebelum melakukan allowlisting; allowlisting bukan perbaikan generik dan harus mengikuti bukti, bukan mendahuluinya.
• [Pemilik Host/CDN/Aplikasi] Baca log error proxy (Nginx/Apache/HAProxy) untuk timeout upstream atau entri koneksi ditolak.
• [Pemilik Host/CDN/Aplikasi] Baca log origin untuk crash aplikasi, OOM kill, atau kehabisan koneksi DB di sekitar cap waktu.
• [Apa pun] Verifikasi apa yang dilihat Googlebot dengan pengujian langsung Inspeksi URL GSC.
• [Pemilik Host/CDN/Aplikasi] Terapkan perbaikan khusus lapisan hanya setelah log/bukti penyedia menunjuk ke lapisan itu—perubahan WAF, firewall, timeout, dan konfigurasi proxy adalah perubahan infrastruktur, bukan tebakan respons pertama.
• [Apa pun] Setelah diperbaiki, biarkan pemulihan berlangsung—respons 2xx secara bertahap menaikkan crawl; Google tidak menerbitkan linimasa pemulihan yang pasti. Gunakan “Validate Fix” (terjemahan) “Validasi Perbaikan” hanya untuk meminta pemeriksaan ulang lebih cepat, bukan sebagai “fix” (terjemahan) “perbaikan”.
• [Pemilik Host/CDN/Aplikasi] Pastikan ke depan Anda memakai 503 (bukan 502) untuk downtime yang direncanakan.

Apakah 502 saya merupakan masalah CDN, proxy, atau origin?

502 adalah kegagalan di antara server, jadi diagnosis dilakukan dengan menelusuri tumpukan, bukan menebak. Mulailah dari edge dan bergerak ke dalam.

Q1. Apakah penyedia CDN atau DNS Anda melaporkan pemadaman saat ini?

• Ya → kemungkinan besar ini pemadaman seluruh penyedia (peristiwa Cloudflare November 2025 adalah contoh textbook). Biasanya tidak ada yang perlu diperbaiki di pihak Anda. Pastikan origin sehat, lalu tunggu pemulihan—laju crawl Google akan kembali meningkat bertahap setelah respons 2xx pulih, meskipun tidak ada linimasa pasti yang dipublikasikan. Berhenti di sini.
• Tidak → lanjutkan.

Q2. Apakah origin menjawab 2xx pada permintaan langsung (melewati CDN/proxy)?

• Tidak—origin juga gagal → masalah berada di lapisan origin. Periksa crash app/PHP-FPM, OOM kill, kehabisan koneksi database, atau deployment yang buruk di log. Bergantung pada cara proxy melihatnya, hal ini juga dapat muncul sebagai 500 atau 504. Berhenti di sini.
• Ya—origin sehat secara langsung, tetapi CDN/proxy mengembalikan 502 → lanjutkan. Origin baik-baik saja; sesuatu di depannya tidak bisa mendapatkan respons yang bersih.

Q3. Apakah browser biasa berfungsi sementara hanya Googlebot/IP CDN yang mendapat 502?

• Ya → curigai blokir WAF atau firewall yang memperlakukan rentang IP proxy atau crawler sebagai penyerang. Konfirmasikan terlebih dahulu di log firewall/WAF, lalu allowlist rentang IP CDN yang sah dan crawler yang terverifikasi—jangan melakukan allowlist tanpa konfirmasi itu. Berhenti di sini.
• Tidak—semua orang melalui proxy mendapat 502 → lanjutkan.

Q4. Apa yang ditunjukkan log reverse proxy untuk upstream?

• Timeout / koneksi ditolak → proxy dapat menjangkau backend, tetapi tidak mendapat respons yang valid dan tepat waktu → masalah kapasitas backend atau timeout (pool habis atau timeout terlalu ketat). Tingkatkan kapasitas/timeout atau perbaiki backend yang lambat.
• Host/DNS salah atau handshake SSL gagal ke upstream → salah konfigurasi proxy → perbaiki blok proxy_pass/upstream atau penyiapan TLS proxy↔backend.

Apa pun lapisannya, pembersihan SEO sama dan sebagian besar berjalan otomatis. Setelah URL mengembalikan 2xx, Google melanjutkan crawl secara otomatis—tidak perlu pengiriman ulang.

Mitos dan kesalahan 502 yang harus dihindari

• Mitos: “502 is a Google/SEO problem I fix in Search Console.” (terjemahan) “502 adalah masalah Google/SEO yang saya perbaiki di Search Console.” Tidak. 502 adalah kegagalan hosting/infrastruktur; Search Console hanya melaporkannya setelah kejadian. Perbaikan ada di CDN, proxy, atau origin. “Validate Fix” (terjemahan) “Validasi Perbaikan” hanya meminta Google memeriksa ulang—tidak memperbaiki apa pun.
• Mitos: “A 502 always means my server is down.” (terjemahan) “502 selalu berarti server saya mati.” Tidak. Origin dapat mengembalikan 2xx pada permintaan langsung sementara pengunjung melihat 502 melalui CDN—karena timeout, konfigurasi upstream yang buruk, atau pemadaman CDN sendiri. Uji langsung ke origin sebelum menganggap server Anda crash.
• Mitos: “502 is less serious than 500 for SEO.” (terjemahan) “502 kurang serius daripada 500 untuk SEO.” Tidak. Dokumentasi Google memberi 500, 502, dan 503 penurunan laju crawl yang sama serta penghapusan indeks yang sama pada error yang terus-menerus. Tidak ada keringanan 502 yang terdokumentasi.
• Mitos: “A one-time 502 will deindex my page.” (terjemahan) “Satu kali 502 akan menghapus halaman saya dari indeks.” Tidak. Crawl melambat lalu kembali meningkat. Halaman keluar dari indeks jika error terus-menerus—dokumentasi Google memakai kata itu tanpa mendefinisikan jumlah hari pasti. Komentar informal Mueller pada November 2025 menyebut sekitar multiple days (terjemahan) “beberapa hari”, dan halaman yang keluar akan “pop back in fairly quickly” (terjemahan) “kembali cukup cepat”—anggap ini pembacaan praktisi atas satu insiden, bukan ambang resmi.
• Mitos: “502 and 503 mean the same thing.” (terjemahan) “502 dan 503 berarti hal yang sama.” Tidak. 503 adalah kode disengaja “service unavailable” (terjemahan) “layanan tidak tersedia” untuk pemeliharaan terencana (dengan header Retry-After); 502 adalah kegagalan proxy yang tidak disengaja. Mencampuradukkan keduanya dalam pemantauan menyembunyikan insiden nyata di balik jendela pemeliharaan yang diharapkan.
• Mitos: “Clearing my browser cache fixes a site-wide 502.” (terjemahan) “Menghapus cache browser memperbaiki 502 di seluruh situs.” Itu saran untuk pengunjung yang memecahkan tampilan mereka sendiri. Jika CDN/proxy/origin benar-benar gagal, tindakan di browser tidak mengubah apa pun bagi orang lain.
• Anti-pattern: menekan “Validate Fix” (terjemahan) “Validasi Perbaikan” berulang kali dan menyegarkan GSC. Saat terjadi lonjakan sementara (atau pemadaman CDN), langkah tercepat dan benar sering kali adalah tidak melakukan apa pun selain memastikan pemulihan. Google menangani kenaikan crawl kembali secara otomatis.

Playbook insiden: situs mengembalikan 502

1. Konfirmasi cakupan. Periksa satu URL terdampak dengan Website Down Checker lalu uji beberapa URL dengan Bulk HTTP Status Code Checker. Jika hanya browser Anda yang gagal, bereskan masalah jaringan lokal atau DNS sebelum mengeskalasi insiden seluruh situs. Jika banyak URL publik mengembalikan 502, lanjutkan.
2. Catat respons yang gagal. Simpan waktu, URL, status, header respons, dan ID permintaan CDN apa pun. Jika galat berselang, ulangi permintaan dan jangan menganggap satu percobaan ulang yang berhasil sebagai pemulihan.
3. Identifikasi gateway — anggap branding sebagai satu sinyal, bukan bukti. Baca header dan halaman galat bermerek untuk sidik jari CDN, reverse proxy, atau load balancer, tetapi konfirmasikan dengan halaman status penyedia dan log Anda sebelum menyimpulkan hop yang gagal; halaman dan header bermerek bersifat spesifik penyedia dan tidak selalu membuktikan penyebab. Jika penyedia melaporkan pemadaman, ikuti jalur insidennya; jika tidak, lanjutkan menuju origin.
4. Bandingkan edge dan origin. Minta hostname publik secara normal, lalu kirim hostname yang sama langsung ke IP origin yang diketahui dengan curl --resolve. Jika origin berhasil sementara edge mengembalikan 502, periksa konektivitas CDN-ke-origin, TLS, dan konfigurasi proxy. Jika keduanya gagal, lanjutkan ke log aplikasi dan origin.
5. Korelasikan log berdasarkan waktu. Penolakan koneksi atau kegagalan TLS menunjuk ke batas gateway/origin; respons upstream yang cacat atau tertutup mendadak menunjuk ke layanan origin. Perbaiki lapisan yang gagal, bukan Search Console.
6. Verifikasi pemulihan. Jalankan kembali pemeriksaan publik dan origin langsung pada URL yang representatif. Jika respons 2xx stabil, pantau log dan Search Console sementara Googlebot melanjutkan crawling otomatis. Jika 502 berulang, kembali ke langkah 4 dengan cap waktu baru, bukan menaikkan percobaan ulang secara membabi buta.

Prompt: mengklasifikasikan batch kegagalan 502 berdasarkan lapisan

Tempel CSV yang berisi URL, cap waktu, status, header respons, hasil edge publik, hasil origin langsung, dan cuplikan log yang cocok. Hapus rahasia, cookie, header otorisasi, serta alamat origin privat terlebih dahulu.

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

Harapkan antrean triase, bukan laporan akar masalah yang definitif. Validasi setiap pemeriksaan yang disarankan terhadap header dan log langsung.

Mereproduksi 502 publik

Jalankan ini di shell macOS/Linux. Perintah ini mencetak header respons tanpa mengunduh isi dan tidak mengikuti pengalihan, sehingga Anda melihat respons pertama.

curl -sS -D - -o /dev/null https://www.example.com/affected-path

Padanan PowerShell:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

Jika aplikasi menangani HEAD secara berbeda, gunakan GET biasa dan buang isi respons:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

Bandingkan rute CDN dengan origin yang diketahui

Ganti 203.0.113.10 dengan IP origin yang Anda kendalikan. --resolve mempertahankan hostname publik untuk header Host HTTP dan nama TLS saat terhubung ke IP tersebut.

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

Jangan mengekspos origin yang terlindungi atau melemahkan firewall hanya untuk menjalankan pengujian ini. Jalankan dari jaringan yang sudah diotorisasi. 502 publik ditambah keberhasilan origin langsung mempersempit kegagalan ke jalur CDN/proxy; kegagalan pada kedua jalur mengarahkan Anda ke origin atau aplikasi.

Alat untuk mempersempit penyebab 502

• Website Down Checker — konfirmasikan apakah URL dapat dijangkau dari vantage point Cloudflare eksternal dan catat waktu, pengalihan, serta bukti DNS terbatas. Alat ini menjawab “apakah hanya terjadi pada saya?” sebelum Anda mengubah infrastruktur.
• Bulk HTTP Status Code Checker — uji sekumpulan URL perwakilan, lihat jalur pengalihan dan latensi lengkap, lalu ekspor hasilnya. Gunakan untuk membedakan kegagalan satu rute dari insiden 502 yang lebih luas.
• Dasbor CDN atau load balancer Anda — cocokkan ID permintaan dan cap waktu dari respons yang gagal dengan log edge dan status penyedia.
• Log aplikasi dan server origin — pastikan apakah upstream menerima permintaan dan apakah mengembalikan, mereset, atau memformat respons secara keliru. Inilah yang mengubah hipotesis lapisan menjadi akar masalah.

Tidak ada alat yang dapat mengidentifikasi lapisan yang gagal hanya dari 502. Bandingkan bukti edge publik dengan permintaan origin langsung yang diotorisasi dan log bertanda waktu.

Uji diri: 502 Bad Gateway

Lima pertanyaan singkat tentang arti 502 dan dampaknya pada SEO. Pilih jawaban untuk setiap pertanyaan, lalu periksa.

Sumber yang layak Anda baca

Tulisan saya yang terkait

• Panduan lengkap kode status HTTP untuk SEO — posisi 502 dan keluarga 5xx lainnya, serta arti setiap kode bagi mesin pencari.
• Panduan pemula SEO teknis — hubungan kesehatan server dan crawl dengan gambaran yang lebih besar.
• Robots.txt dan SEO: semua yang perlu Anda ketahui — relevan karena 5xx pada berkas robots.txt Anda ditangani secara khusus.

Dari industri

• Dampak kode status HTTP pada crawler Google (Google Search Central) — sumber utama: 502 (bad gateway) dikelompokkan bersama 500/503, dengan redaksi laju crawl/pengindeksan yang tepat.
• Cara menangani waktu henti situs yang direncanakan (Google Search Central) — perbedaan 503 dan 502 serta alasan 503 adalah kode untuk downtime yang disengaja.
• Pemadaman Cloudflare memicu lonjakan 5xx: dampaknya bagi SEO (Matt G. Southern, Search Engine Journal) — pemadaman November 2025 sebagai studi kasus dunia nyata, dengan komentar Mueller.
• 502 Bad Gateway: referensi MDN (MDN Web Docs) — definisi kode status pada tingkat spesifikasi yang netral.
• 502 Bad Gateway §15.6.3 — RFC (IETF) — spesifikasi semantik HTTP yang mendasari.
• Cara memperbaiki error 502 Bad Gateway (Kinsta) — panduan troubleshooting menyeluruh dari sudut pandang host untuk perbaikan browser/pemilik situs.
• 502 bad gateway: arti dan cara memperbaikinya (Webflow) — ikhtisar penyebab dan perbaikan untuk pengembang.

Log perubahan