429 terlalu banyak permintaan

TL;DR — 429 Terlalu Banyak Permintaan berarti server Anda memberi tahu pengunjung atau bot, “Anda meminta terlalu banyak halaman terlalu cepat—perlambat.” Ini disebut pembatasan laju. Kabar baik untuk SEO: 429 adalah satu-satunya galat dalam keluarganya yang ditangani Google dengan lunak. Alih-alih menghapus halaman Anda, Googlebot hanya mengurangi kecepatan dan merayapi situs Anda lebih pelan untuk sementara. Ini baru menjadi masalah jika server terus mengirim 429 selama berhari-hari.

Arti sebenarnya dari 429

Setiap kali browser, skrip, atau crawler mesin pencari meminta halaman dari server Anda, server menjawab dengan kode status. 200 berarti “inilah halamannya.” 429 berarti “Anda mengirim terlalu banyak permintaan dalam waktu singkat, jadi permintaan ini tidak saya layani—coba lagi nanti.”

Server menggunakan 429 dengan sengaja untuk melindungi dirinya. Jika seorang pengunjung (atau bot) terus-menerus membanjiri situs hingga memperlambatnya bagi semua orang, respons 429 adalah cara server berkata berhentilah sebentar. Respons 429 yang baik juga menyertakan header Retry-After—catatan yang memberi tahu klien berapa detik harus menunggu sebelum mencoba lagi. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Mengapa 429 adalah galat “ramah” untuk SEO

Inilah bagian yang mengejutkan banyak orang. 429 berada dalam kelompok “galat klien 4xx”, berdampingan dengan kode seperti 403 Forbidden dan 404 Not Found. Kedua kode itu menjadi kabar buruk jika terus dilihat Google—pada akhirnya Google menghapus halaman tersebut dari hasil penelusuran.

429 adalah pengecualian. Google membaca 429 sebagai server sedang sibuk, perlambat—sama seperti membaca galat server 503 atau 500. Jadi, alih-alih menghapus halaman Anda, Googlebot hanya merayapi situs lebih lambat untuk sementara. Google bahkan merekomendasikan 429 sebagai cara yang benar untuk memperlambat crawler, dan secara khusus memperingatkan agar tidak memakai 403 atau 404. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Kapan 429 menjadi masalah

429 yang muncul sesekali sepenuhnya normal dan dapat pulih sendiri—begitu server berhenti mengirimkannya, Google akan meningkatkan kembali crawl secara otomatis. Anda tidak perlu mengajukan permintaan apa pun.

Bahaya muncul ketika 429 terus bertahan. Jika Googlebot terus menerima 429 pada halaman yang sama selama lebih dari satu atau dua hari, Google mungkin mulai menghapus halaman tersebut dari indeksnya—karena dari sisi Google, situs Anda tampak rusak dan tidak tersedia selama berhari-hari. Jadi, 429 adalah alat jangka pendek, bukan pengaturan permanen.

Apa yang harus dilakukan

• Jika Anda tidak bermaksud mengirim 429 (kode itu tiba-tiba muncul di Google Search Console atau alat crawl), berarti ada pembatasan laju yang terlalu ketat—sering kali plugin keamanan, firewall (WAF), atau hosting/CDN Anda. Temukan sumbernya dan longgarkan batas agar tidak memblokir mesin pencari yang sebenarnya.
• Jika Anda memang bermaksud mengirimnya—misalnya server sedang menerima beban berat—tidak masalah, tetapi batasi waktunya dan tambahkan header Retry-After. Matikan dalam satu atau dua hari.

Ingin panduan konfigurasi server, redaksi persis dari Google, dan mitos yang sering keliru? Buka tab Advanced.

TL;DR — 429 adalah satu-satunya kode 4xx yang diperlakukan Google seperti 5xx: setelah menemukan banyak respons 500/503/429, Google membacanya sebagai sinyal server kelebihan beban dan memperlambat laju crawl Googlebot di seluruh hostname, bukan menghapus konten. Inilah satu kode yang direkomendasikan Google untuk memperlambat crawler — jangan gunakan 403 atau 404. Dokumentasi Google memberi panduan penggunaan darurat “a couple of hours, or 1–2 days” (terjemahan) “beberapa jam, atau 1–2 hari” — bukan jendela aman yang dijamin; 429 yang bertahan pada URL yang sama selama beberapa hari berisiko membuat URL dikeluarkan dari indeks. Setelah volume galat turun, laju crawl mulai meningkat lagi (tidak selalu seketika atau sepenuhnya). RFC 6585 menyatakan bahwa respons 429 SHOULD menjelaskan kondisinya dan MAY menyertakan Retry-After — mengirimkannya adalah praktik yang disarankan, bukan kewajiban kepatuhan. Batasi pembatasan pada lalu lintas yang tepat dan verifikasi identitas crawler sebelum membuat pengecualian.

Arti 429 pada tingkat protokol

Menurut definisi MDN, 429 muncul ketika klien mengirim terlalu banyak permintaan dalam jangka waktu tertentu. Mekanisme untuk meminta klien memperlambat laju permintaan ini disebut pembatasan laju. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

RFC 6585 §4 lebih presisi dibanding ringkasan umum. Representasi 429 SEBAIKNYA menjelaskan kondisi dan BOLEH menyertakan header Retry-After yang memberi klien jumlah detik konkret (RFC 9110 juga mengizinkan tanggal HTTP) untuk menunggu sebelum mencoba lagi—Retry-After adalah praktik yang disarankan, bukan kewajiban kepatuhan. Spesifikasi juga tidak menentukan bagaimana klien diidentifikasi atau bagaimana permintaan dihitung; semuanya diserahkan kepada penerbit respons (per IP, sesi, kunci API, atau sumber daya—kebijakan implementasi, bukan protokol). Satu aturan yang mudah terlewat: RFC 6585 menyatakan bahwa respons 429 TIDAK BOLEH disimpan oleh cache. Jika Anda melihat 429 yang tampak di-cache atau diputar ulang pada origin yang sehat, itu adalah perantara (CDN atau proxy) yang keliru, bukan origin yang kembali memutuskan untuk membatasi Anda.

Dalam panduan Kode Status HTTP & Dampaknya terhadap SEO, saya menjelaskannya secara sederhana: 429 adalah “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (terjemahan) “bentuk pembatasan laju untuk melindungi server karena klien mengirim terlalu banyak permintaan ke server dengan terlalu cepat.” Secara nominal ini adalah galat klien—klien dianggap keliru karena meminta terlalu banyak. Namun, justru di sinilah kisah SEO menyimpang dari spesifikasi.

Satu-satunya pengecualian di antara kode 4xx

Fakta terpenting di halaman ini: Google tidak memperlakukan 429 seperti anggota keluarga 4xx lainnya. Gary Illyes menulis posting Google Search Central khusus tentang hal ini pada Februari 2023, karena cukup banyak situs dan CDN menyalahgunakan 404 untuk memperlambat Googlebot sehingga Google harus meminta mereka berhenti.

Aturannya jelas: 429 adalah satu-satunya pengecualian dan menjadi sinyal bagi robot yang berperilaku baik, termasuk Googlebot, untuk memperlambat diri ketika server terbebani. Sebaliknya, Google mengatakan bahwa 401 dan 403 bukan alat untuk membatasi laju crawl; kode status 4xx selain 429 tidak memengaruhi laju tersebut.

Jadi, ketika 403 dan 404 menghapus konten Anda dari Search, 429 memberi Anda perlambatan sementara. Google secara harfiah mengelompokkannya dengan galat server: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (terjemahan) “Crawler Google memperlakukan kode status 429 sebagai sinyal bahwa server kelebihan beban, dan kode ini dianggap sebagai galat server.” Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Inilah yang menjadikan 429 saudara berguna dari 503 Service Unavailable (sinyal pemeliharaan/tidak tersedia sementara)—dan kebalikan persis dari 403 Forbidden, alat yang keliru untuk pembatasan laju meskipun banyak firewall menggunakannya sebagai bawaan.

Dampak laju crawl berlaku di seluruh hostname—dengan ambang

Dua cakupan berbeda sering tercampur di sini dan perlu dipisahkan. Cara Anda menghitung dan memberi kunci batas laju—per IP, sesi, kunci API, sumber daya, atau server—adalah kebijakan Anda sendiri; spesifikasi HTTP tidak menentukannya. Perilaku Google terhadap galat yang diamati adalah hal terpisah dan terdokumentasi, serta bergantung pada volume, bukan satu respons: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (terjemahan) “Infrastruktur crawling Google mengurangi laju crawl situs Anda ketika menemukan sejumlah besar URL dengan kode status respons HTTP 500, 503, atau 429.” Setelah ambang itu tercapai, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (terjemahan) “Laju crawl yang berkurang memengaruhi seluruh hostname situs Anda (misalnya subdomain.example.com), baik crawl URL yang mengembalikan galat maupun URL yang mengembalikan konten.”

Dengan kata lain, jika Anda mengembalikan 429 pada sebagian halaman (misalnya jalur API yang berat) dalam volume nyata, Googlebot memperlambat crawl seluruh hostname—termasuk halaman yang masih mengembalikan 200. Biasanya itulah efek yang diinginkan ketika tujuan Anda mengurangi beban total. Namun, satu 429 yang terisolasi pada satu jalur tidak dengan sendirinya membuktikan dampak di seluruh hostname—redaksi Google menyebut sejumlah besar respons galat, bukan satu respons saja.

Panduan 1–2 hari—saat 429 mulai berisiko

429 adalah sinyal jangka pendek, dan Google memberi panduan darurat yang konkret—bukan jendela aman yang dijamin atau batas tegas. Dari dokumentasi “reduce crawl rate”: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (terjemahan) “Jika Anda perlu segera mengurangi laju crawl untuk waktu singkat (misalnya beberapa jam atau 1–2 hari), kembalikan kode status respons HTTP 500, 503, atau 429 alih-alih 200 untuk permintaan crawl.”

Lewati jangka itu dan risikonya meningkat, meskipun Google menyampaikannya sebagai kemungkinan, bukan kepastian: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (terjemahan) “Kami tidak menyarankan melakukan ini dalam waktu lama (lebih dari 1–2 hari) karena dapat berdampak negatif pada tampilan situs Anda di produk Google… jika Googlebot mengamati kode status ini pada URL yang sama selama beberapa hari, URL itu mungkin dikeluarkan dari indeks Google.” Referensi kode status mengatakan hal serupa untuk 5xx dan 429: “already indexed URLs are preserved in the index, but eventually dropped.” (terjemahan) “URL yang sudah diindeks dipertahankan dalam indeks, tetapi pada akhirnya dikeluarkan.”*

Model risikonya, secara jujur: 429 jangka pendek berada dalam jendela penggunaan darurat yang direkomendasikan Google; 429 yang terus dikirim pada URL yang sama selama beberapa hari adalah saat bahasa Google berubah menjadi “mungkin” dan “pada akhirnya dikeluarkan”—risiko yang terdokumentasi, bukan hasil yang pasti. Dinamikanya sama dengan 503 yang berkepanjangan.

Laju crawl pulih secara otomatis

Sisi yang menenangkan: tidak ada tanda penalti yang terus mengikuti situs Anda. Setelah galat mereda, Google mengatakan “the crawl rate will automatically start increasing again.” (terjemahan) “laju crawl akan mulai meningkat lagi secara otomatis.” Anda tidak perlu mengajukan apa pun atau meminta crawl ulang. Perhatikan kata-katanya: Google mengatakan “starts increasing,” (terjemahan) “mulai meningkat,” bukan “instantly returns to your prior rate.” (terjemahan) “langsung kembali ke laju sebelumnya.” Anggap pemulihan sebagai arah yang didokumentasikan tanpa jadwal tetap atau titik akhir yang dijamin, bukan SLA.

(Bandingkan dengan masalah sebaliknya—ingin Google merayapi Anda lebih sedikit secara permanen. Jika menyajikan galat tidak memungkinkan, Google menyarankan “file a special request to report a problem with unusually high crawl rate” (terjemahan) “ajukan permintaan khusus untuk melaporkan masalah laju crawl yang sangat tinggi”—jalur manual yang dapat memakan waktu berhari-hari dan tidak dijamin. Pemulihan tidak memiliki hambatan seperti itu.)

How Bing handles 429

Bingbot banyak dilaporkan berperilaku serupa—sinyal 429/500/503 menunjukkan beban berlebih dan Bingbot mengurangi laju—meskipun saya tidak dapat mengonfirmasi sendiri redaksi terkini pada halaman bantuan Bing dalam riset ini (halamannya berupa SPA yang dirender JavaScript dan tidak menghasilkan teks statis yang dapat diambil). Perlakukan klaim kesetaraan itu sebagai laporan industri, bukan sesuatu yang telah saya verifikasi terhadap dokumentasi Bing saat ini. Yang dikonfirmasi Bing dalam panduan historisnya adalah dua kontrol proaktif yang tidak ditawarkan Google dalam bentuk yang sama:

• Crawl Control di Bing Webmaster Tools adalah kisi permintaan per detik untuk mengatur kecepatan Bingbot berdasarkan jam.
• Direktif crawl-delay pada robots.txt. Panduan Bing Webmaster saat ini mendokumentasikan nilai 1–20 detik. Ini khusus Bing; direktif ini tidak membatasi Googlebot.

Jadi, di Bing Anda dapat membatasi laju secara proaktif dengan crawl-delay atau Crawl Control, bukan secara reaktif dengan kode status. (Google menghentikan penggeser laju crawl manualnya pada 2024 dan kini sepenuhnya mengandalkan respons server Anda.)

Kapan Anda sengaja mengirim 429

Alasan yang sah untuk sengaja mengembalikan 429:

• Beban server darurat—lonjakan trafik, migrasi yang gagal, atau pemadaman ketika Anda perlu Googlebot mengurangi laju sekarang juga selama beberapa jam.
• Melindungi API dan endpoint non-HTML dari penyalahgunaan crawler/bot—crawler mesin pencari, crawler SEO pihak ketiga (Ahrefs, Screaming Frog), dan scraper semuanya dapat mencapai batas laju yang dibuat untuk menghentikan penyalahgunaan.

Yang bukan tujuan 429: memblokir secara permanen bot yang tidak Anda inginkan sama sekali. Jika Anda tidak pernah ingin sesuatu dirayapi, gunakan larangan robots.txt, bukan 429. Jika Anda ingin mempertahankan halaman tetapi mengeluarkannya dari indeks, gunakan noindex. 429 hanya berarti “nanti”, bukan “tidak pernah”.

429 yang tidak disengaja—penyebab umum

Ketika 429 muncul di laporan Page Indexing atau Crawl Stats GSC padahal Anda tidak sengaja membuatnya, sumbernya biasanya salah satu dari berikut ini—saya tidak mengetahui bukti yang baik untuk menentukan mana yang paling umum secara universal, jadi anggap ini sebagai daftar kandidat yang perlu dibuktikan atau disingkirkan, bukan diagnosis:

• Aturan WAF/firewall salah memicu pada rentang IP crawler yang sah.
• Batas laju bawaan hosting bersama atau CDN terlalu ketat untuk crawl nyata.
• Alat manajemen bot salah mengklasifikasikan Googlebot atau Bingbot sebagai trafik berbahaya.
• Middleware pembatasan laju agresif yang ditujukan untuk penyalahgunaan API ikut menangkap crawler Anda sendiri.

Sebelum mengubah ambang atau menulis aturan yang mengecualikan bot pencari nyata, tetapkan provenansinya terlebih dahulu — jangan menebak lapisan mana yang memiliki respons. Ambil header respons mentah, baris log permintaan yang tepat (bukan ringkasan dasbor), pengenal aturan atau zona pembatasan laju yang terpicu, kunci klien yang dihitung (IP, sesi, kunci API), rute, POP CDN atau lokasi edge, serta jendela waktu. Gabungan ini menunjukkan lapisan yang benar-benar mengeluarkan 429 dan apa yang dihitungnya — baru setelah itu masuk akal untuk melonggarkan batas atau menambahkan pengecualian. Verifikasi identitas crawler dengan DNS reverse-plus-forward (metode resmi Google), bukan hanya string user-agent — user-agent “Googlebot” palsu umum ditemukan. Lens Scripts memiliki perintah persisnya.

Ringkasan singkat playbook

1. Gunakan 429 atau 503 dengan Retry-After untuk memperlambat crawler—jangan pernah 403 atau 404.
2. Batasi selama beberapa jam atau 1–2 hari—setelah itu URL dapat dikeluarkan dari indeks.
3. Ingat, pembatasan berlaku di seluruh hostname dan pulih otomatis ketika galat berhenti.
4. Batasi cakupan pada trafik yang tepat dan verifikasi identitas crawler sebelum mengecualikan bot.

Ringkasan AI

Ringkasan padat dari versi Advanced:

• 429 Too Many Requests = server memberi tahu klien (browser, skrip, atau crawler) bahwa terlalu banyak permintaan dikirim terlalu cepat—“pembatasan laju”. Secara nominal ini galat 4xx klien.
• Tingkat protokol: RFC 6585 menyatakan respons 429 SEBAIKNYA menjelaskan kondisi dan BOLEH menyertakan Retry-After—disarankan, bukan wajib. Respons ini juga TIDAK BOLEH disimpan cache; 429 yang di-cache atau diputar ulang adalah bug perantara, bukan origin. Cara menghitung atau memberi kunci batas (IP, sesi, kunci API, sumber daya) adalah kebijakan Anda sendiri—spesifikasi tidak menentukannya.
• Satu pengecualian 4xx: Google memperlakukan 429 seperti galat server 5xx, bukan seperti 403/404. Google membacanya sebagai “server overloaded, slow down” (terjemahan) “server kelebihan beban, perlambat” dan memperlambat laju crawl, bukan menghapus konten.
• Google merekomendasikan 429 (serta 500/503) untuk memperlambat crawler—jangan gunakan 403 atau 404. Gary Illyes menulis posting pada 2023 yang secara khusus meminta situs/CDN berhenti memakai 404 untuk memperlambat Googlebot.
• Pembatasan berlaku di seluruh hostname, di atas ambang tertentu—redaksi Google sendiri mengaitkan dampak seluruh hostname dengan “sejumlah besar” respons 500/503/429, bukan satu 429 saja. Di atas ambang itu, halaman yang masih menyajikan 200 juga dicrawl lebih sedikit.
• Panduan 1–2 hari, bukan batas keras: dokumentasi Google memberi panduan darurat “beberapa jam atau 1–2 hari”. 429 yang bertahan beberapa hari pada URL yang sama berisiko membuat URL tersebut dikeluarkan dari indeks—“mungkin” dan “pada akhirnya”, bukan jaminan—mirip 503 yang berkepanjangan.
• Pemulihan bersifat arah, bukan seketika: hentikan pengiriman 429 dan Google mengatakan laju crawl “mulai meningkat lagi”—tanpa permintaan ulang dan tanpa penalti yang tertinggal, tetapi juga tanpa janji laju langsung pulih penuh pada jadwal tertentu.
• Percobaan ulang sisi klien: hormati Retry-After yang valid jika ada; jika tidak, RFC tidak menentukan rumus—gunakan backoff berjitter yang dibatasi, batasi percobaan, dan periksa idempotensi sebelum mengulang permintaan yang tidak idempoten.
• Batasi pembatasan pada lalu lintas yang tepat dan verifikasi identitas crawler (DNS reverse+forward) sebelum mengecualikan bot.
• Bing banyak dilaporkan mundur secara serupa pada 429, meskipun klaim kesetaraan itu belum terkonfirmasi secara independen terhadap dokumentasi Bing saat ini; panduan historis Bing memang mengonfirmasi crawl-delay dan kisi Crawl Control sebagai alternatif proaktif.
• 429 ≠ blokir: artinya “nanti”, bukan “tidak pernah”. Gunakan robots.txt untuk menjauhkan bot dan noindex untuk menghapus halaman dari indeks.

Dokumentasi resmi

Dokumentasi sumber primer dari mesin pencari dan spesifikasi HTTP.

Google

• Jangan gunakan 403 atau 404 untuk pembatasan laju — posting Gary Illyes Februari 2023; pernyataan kanonis bahwa 429 adalah pengecualian dan 403/404 merupakan alat yang keliru.
• Kurangi laju crawl Google — panduan “kembalikan 500, 503, atau 429”, jendela 1–2 hari, pembatasan seluruh hostname, dan pemulihan otomatis.
• Kode status HTTP, jaringan, dan galat DNS — cara Google menangani setiap kode; 429 dikelompokkan dengan galat server (juga tersedia di jalur lama search/docs/crawling-indexing/http-network-errors).
• Kurangi laju crawl Google—jalur permintaan khusus — jalur manual “laporkan masalah laju crawl yang sangat tinggi” ketika penyajian galat tidak memungkinkan.

Bing / Microsoft

• Crawl Control — penjadwal permintaan per detik Bingbot di Bing Webmaster Tools.
• Panduan Bingbot — panduan Bing Webmaster saat ini untuk crawl-delay (1–20 detik).

Spesifikasi HTTP

• MDN — 429 Too Many Requests — definisi protokol, Retry-After, dan dasar-dasar pembatasan laju.

Kutipan dari sumber

Pernyataan yang dicatat dari Google, Bing, dan spesifikasi HTTP. Setiap tautan adalah tautan langsung ke bagian yang dikutip pada halaman sumber.

Google — Gary Illyes, “Don’t use 403s or 404s for rate limiting” (terjemahan) “Jangan gunakan 403 atau 404 untuk membatasi laju” (Februari 2023)

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (terjemahan) “Dalam beberapa bulan terakhir, kami melihat makin banyak pemilik situs dan sejumlah jaringan pengiriman konten (CDN) yang mencoba memakai 404 dan galat klien 4xx lainnya (tetapi bukan 429) untuk mengurangi laju crawling Googlebot.” Lompat ke kutipan
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (terjemahan) “Satu-satunya pengecualian adalah 429, yang berarti ‘terlalu banyak permintaan’. Galat ini merupakan sinyal jelas bagi robot yang berperilaku baik, termasuk Googlebot kesayangan kita, bahwa ia perlu memperlambat diri karena membebani server.” Lompat ke kutipan
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (terjemahan) “Semua kode status HTTP 4xx (sekali lagi, kecuali 429) akan menyebabkan konten Anda dihapus dari Google Search.” Lompat ke kutipan
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (terjemahan) “Gunakan Search Console untuk sementara mengurangi laju crawl. Kembalikan kode status HTTP 500, 503, atau 429 kepada Googlebot ketika ia merayap terlalu cepat.” Lompat ke kutipan

Google—referensi laju crawl / kode status

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (terjemahan) “Jika Anda perlu segera mengurangi laju crawl untuk waktu singkat (misalnya beberapa jam atau 1–2 hari), kembalikan kode status respons HTTP 500, 503, atau 429 alih-alih 200 untuk permintaan crawl.” Lompat ke kutipan
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (terjemahan) “Laju crawl yang berkurang memengaruhi seluruh hostname situs Anda… Setelah jumlah galat ini berkurang, laju crawl akan mulai meningkat lagi secara otomatis.” Lompat ke kutipan
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (terjemahan) “Kami tidak menyarankan Anda melakukan ini dalam waktu lama (lebih dari 1–2 hari)… URL tersebut mungkin dikeluarkan dari indeks Google.” Lompat ke kutipan
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (terjemahan) “Crawler Google memperlakukan kode status 429 sebagai sinyal bahwa server kelebihan beban dan kode ini dianggap sebagai galat server.” Lompat ke kutipan
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (terjemahan) “Jangan gunakan kode status 401 dan 403 untuk membatasi laju crawl. Kode status 4xx, kecuali 429, tidak berpengaruh pada laju crawl.” Lompat ke kutipan

MDN — protocol definition

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (terjemahan) “Kode status respons galat klien HTTP 429 Too Many Requests menunjukkan bahwa klien telah mengirim terlalu banyak permintaan dalam jangka waktu tertentu. Mekanisme meminta klien memperlambat laju permintaan ini biasanya disebut ‘pembatasan laju’.” Lompat ke kutipan

Bing—panduan Webmaster saat ini

• Panduan Bingbot mendokumentasikan nilai crawl-delay 1–20 detik. Perlakukan ini sebagai panduan khusus Bing, bukan pembatas crawler umum.

Penguat dari industri atas pernyataan Google

• Posting Illyes Februari 2023 dikutip apa adanya oleh Search Engine Land, Search Engine Roundtable, dan Search Engine Journal — ketiganya membingkai 429 sebagai “satu-satunya pengecualian”. Ini adalah tulisan media industri tentang posting Google yang sama; sumber primernya adalah posting blog Illyes yang dikutip di atas.

Mengirim 429 yang benar—dengan Retry-After

Bagian terpenting dari respons 429 yang baik adalah header Retry-After. Header ini memberi tahu klien yang patuh—termasuk Googlebot—berapa lama harus menunggu. Nilainya dapat berupa jumlah detik atau tanggal HTTP:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Tidak menyertakan Retry-After tidak melanggar kepatuhan, tetapi menyertakannya merupakan praktik terbaik dan memberi crawler sinyal mundur yang konkret.

nginx—pembatasan laju yang mengembalikan 429

Secara bawaan, limit_req nginx mengembalikan 503. Untuk semantik yang ramah crawler, ubah menjadi 429 dan tambahkan header Retry-After. Contoh berikut mengizinkan 10 permintaan per detik per IP dengan burst kecil:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache—pembatasan laju dengan mod_ratelimit / mod_evasive

mod_ratelimit inti Apache membatasi bandwidth, bukan jumlah permintaan, sehingga pembatasan laju permintaan biasanya menggunakan mod_evasive (atau WAF). Agar respons yang dibatasi mengembalikan 429 dengan Retry-After, tetapkan secara eksplisit:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Catatan: mod_evasive versi lama membuat respons blokir bawaan 403—tepat kode yang menurut Google tidak boleh digunakan untuk pembatasan laju. Pastikan build Anda mengembalikan 429 (atau letakkan di belakang CDN/WAF yang melakukannya).

Cloudflare / CDN—pembatasan laju untuk 429

Pada lapisan CDN, atur tindakan respons aturan pembatasan laju menjadi 429 (banyak sistem memakai 403 atau tantangan sebagai bawaan). Pada aturan Rate Limiting Cloudflare, status respons ketika batas terlampaui dapat dikonfigurasi—pilih 429 dan, jika didukung, sertakan Retry-After. Prinsip yang sama berlaku pada Fastly, Akamai, atau gateway API: tindakan ketika batas terlampaui seharusnya 429 Too Many Requests, bukan 403 Forbidden.

Sisi klien: mencoba lagi setelah 429 tanpa rumus baku

Jika Anda menulis klien, RFC hanya memberi satu aturan wajib dan tidak memberi algoritme cadangan: hormati Retry-After yang valid jika tersedia. Jika tidak ada, RFC 6585 tidak menetapkan interval percobaan ulang, rumus backoff, sebaran jitter, jumlah percobaan, atau kondisi “berhasil”—itu adalah kebijakan Anda, bukan persyaratan spesifikasi. Jangan menyajikan satu rumus pun (termasuk contoh di bawah) sebagai hukum HTTP; ini hanya bawaan wajar yang dibatasi, bukan satu-satunya cara yang benar.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

Hal-hal ini penting terlepas dari angka yang Anda pilih: batas total waktu tunggu dan jumlah percobaan (jangan mencoba selamanya), jitter (agar sekumpulan klien tidak mencoba ulang serentak dan memicu batas lagi), serta pemeriksaan idempotensi sebelum mencoba ulang permintaan yang tidak aman diulang (POST yang tidak idempoten memerlukan kunci deduplikasi, bukan percobaan ulang buta).

Verifikasi bahwa bot benar-benar Googlebot sebelum mengecualikannya

Jika Anda menulis pengecualian pembatasan laju untuk mesin pencari, konfirmasikan identitas dengan pemeriksaan DNS reverse + forward—user-agent “Googlebot” palsu umum ditemukan dan string UA saja tidak membuktikan apa pun.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Jika pencarian reverse tidak berakhir pada domain Google, atau pencarian forward tidak cocok dengan IP asal, itu bukan Googlebot. Anda juga dapat mencocokkannya dengan rentang IP Google yang dipublikasikan (googlebot.json).

Mitos umum tentang 429 dan SEO

Mitos: “Setiap 429 akan merusak SEO atau mengeluarkan saya dari indeks.” Tidak. Google merancang 429 sebagai sinyal pembatasan yang aman dan diharapkan. 429 jangka pendek atau sesekali adalah normal dan dapat memperbaiki diri. Risiko deindeksasi hanya muncul jika 429 terus-menerus dikirim pada URL yang sama selama beberapa hari—panduan Google sendiri menyebut 1–2 hari.

Mitos: “429 dan 503 pada dasarnya dapat dipertukarkan untuk SEO.” Untuk pembatasan laju crawl, Google memperlakukannya secara serupa. Namun maknanya berbeda: 503 Service Unavailable adalah sinyal tradisional “tidak tersedia sementara/pemeliharaan”, sedangkan 429 secara khusus menyatakan kelebihan laju/volume. Memakai kode yang semantisnya tepat penting untuk pemantauan, alat, dan sistem hilir Anda yang membaca kode status—meskipun Googlebot mundur dengan cara yang sama.

Mitos: “Anda dapat menggunakan 403 atau 404 untuk memperlambat Googlebot seperti 429.” Posting Illyes Februari 2023 secara langsung membantahnya—hal ini cukup umum sampai Google menulis artikel khusus agar orang berhenti. 403/404 tidak berpengaruh pada laju crawl dan justru menghapus konten dari indeks. 429 adalah satu-satunya kode 4xx yang membatasi laju.

Mitos: “Membatasi laju bot pencari menyebabkan pemotongan anggaran crawl permanen.” Pengurangan itu sementara dan pulih otomatis setelah volume galat turun. Tidak ada tanda yang tertinggal pada situs setelah galat berhenti—dokumentasi Google mengatakan “will automatically start increasing again.” (terjemahan) “laju crawl akan mulai meningkat lagi secara otomatis.”

Mitos: “Jika Googlebot menerima 429, ia menyerah pada URL itu selamanya.” Google akan mencoba lagi nanti. Yang mengkhawatirkan adalah 429 yang bertahan selama beberapa hari per URL—bukan pembatasan laju sesekali atau sekali terjadi, yang cukup dihormati Googlebot sebelum kembali mencrawl.

Pertanyaan yang sering diajukan

Apakah galat 429 merusak SEO saya? Tidak dengan sendirinya. 429 jangka pendek atau sesekali hanya memperlambat Googlebot sementara dan pulih sendiri. Risiko muncul jika URL yang sama mengembalikan 429 selama beberapa hari.

Berapa lama saya dapat mengembalikan 429 sebelum Google menghapus halaman dari indeks? Dokumentasi Google mengatakan batasi hingga “a couple of hours, or 1–2 days.” (terjemahan) “beberapa jam atau 1–2 hari.” Setelah itu, “the URL may be dropped from Google’s index.” (terjemahan) “URL tersebut mungkin dikeluarkan dari indeks Google.” Anggap 1–2 hari sebagai batas atas, bukan target.

Apa perbedaan 429 dan 503 untuk SEO? Google memperlambat crawl keduanya dengan cara serupa. Namun 503 berarti “tidak tersedia sementara/pemeliharaan”, sedangkan 429 berarti “Anda mengirim terlalu banyak permintaan”. Gunakan kode yang semantisnya tepat agar pemantauan dan alat Anda membacanya dengan benar.

Haruskah saya memblokir Googlebot dengan 429 jika ingin ia mengcrawl lebih sedikit secara permanen? Tidak—429 adalah sinyal jangka pendek, bukan pengaturan permanen. Untuk pengurangan jangka panjang, Google menyarankan mengajukan permintaan khusus tentang laju crawl tinggi. Untuk sepenuhnya menjauhkan bot dari suatu ruang, gunakan robots.txt; untuk menghapus halaman dari indeks, gunakan noindex.

Apakah Bingbot menghormati 429 seperti Googlebot? Bingbot juga mundur terhadap sinyal beban berlebih seperti 429/500/503. Bing juga menawarkan kontrol proaktif yang tidak dimiliki Google—direktif crawl-delay pada robots.txt dan kisi permintaan per detik Crawl Control di Bing Webmaster Tools.

Apa itu header Retry-After dan apakah saya memerlukannya? Retry-After memberi tahu klien berapa lama menunggu sebelum mencoba lagi (jumlah detik atau tanggal HTTP). Header ini tidak wajib secara ketat, tetapi merupakan praktik terbaik dan memberi crawler sinyal mundur yang konkret.

Apakah Google melanjutkan crawl normal setelah saya berhenti mengembalikan 429? Ya, secara otomatis. Setelah volume galat turun, “laju crawl akan mulai meningkat lagi secara otomatis”. Tidak perlu permintaan ulang dan tidak ada penalti yang menetap.

Dapatkah alat WAF atau CDN tanpa sengaja mengembalikan 429 kepada Googlebot? Sangat sering. Aturan firewall agresif, batas bawaan CDN/hosting, dan alat manajemen bot dapat salah mengklasifikasikan Googlebot atau Bingbot. Verifikasi identitas crawler (DNS reverse + forward) sebelum membuat pengecualian dan longgarkan batas yang menangkap mesin pencari nyata.

Apakah 429 galat klien atau galat server? Secara teknis, ini galat klien 4xx menurut spesifikasi HTTP. Namun Google memperlakukannya sebagai galat server untuk keperluan crawl—ini satu-satunya kode 4xx yang dikelompokkan bersama 5xx.

Apa yang harus dilakukan klien jika menerima 429 tanpa header Retry-After? Tidak ada rumus yang diwajibkan HTTP—spesifikasi menyerahkannya kepada kebijakan. Bawaan yang wajar dan dibatasi: exponential backoff dengan jitter, batas keras pada total waktu tunggu dan jumlah percobaan agar tidak mencoba selamanya, serta pemeriksaan idempotensi sebelum mengulangi permintaan yang tidak aman dikirim dua kali. Lihat tab Scripts untuk pseudocode lengkap.

Apa yang harus saya lakukan terhadap 429?

Masalah umum 429

Googlebot menerima 429 tetapi pengunjung biasa tidak

Gejala: laporan crawler menunjukkan 429 sementara pemeriksaan browser mengembalikan 200. Kemungkinan penyebab: manajemen bot, aturan UA, atau pembatasan laju berbasis IP. Perbaikan: cocokkan peristiwa WAF dengan IP crawler yang terverifikasi, lalu persempit atau koreksi aturan yang bertanggung jawab; jangan izinkan daftar berdasarkan string user-agent saja.

Laju crawl seluruh hostname turun

Gejala: crawl melambat melampaui URL yang mengembalikan 429. Kemungkinan penyebab: Google menerapkan sinyal beban berlebih di seluruh hostname. Perbaikan: hentikan 429 yang tidak disengaja, pulihkan respons sukses yang stabil, dan biarkan laju crawl pulih otomatis.

Respons 429 terus berlanjut setelah insiden

Gejala: server sehat tetapi URL masih mengembalikan 429. Kemungkinan penyebab: cache CDN, aturan edge, atau keadaan pembatas yang bertahan melewati insiden. Perbaikan: nonaktifkan atau biarkan aturan sementara kedaluwarsa, hapus respons yang salah di-cache, dan verifikasi di jalur serta wilayah yang mewakili.

Retry-After tidak ada atau tidak dapat digunakan

Gejala: klien tahu bahwa ia dibatasi tetapi tidak tahu kapan boleh mencoba lagi. Kemungkinan penyebab: respons dibuat oleh aturan keamanan umum. Perbaikan: pastikan lapisan penerbit mengirim jeda yang valid atau tanggal HTTP dan uji header mentah.

Prompt: audit sebuah rate-limit aturan

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: diagnose unexplained 429s

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

alat untuk investigating 429s

• Bulk HTTP kode status Checker: test sebuah representative URL set dan export which paths currently kembalikan 429.
• header HTTP Checker: inspect Retry-After, CDN fingerprints, dan redirect hops pada limited respons.
• Googlebot Verifier: validate IP evidence sebelum membuat sebuah crawler exception.
• Log File Analyzer: segment status-code waste oleh bot dan bagian sambil menyimpan log yang diunggah di peramban.
• Search Console crawl Stats: bandingkan waktu terjadinya 429 dengan perubahan pada crawl permintaan dan host respons perilaku.

Validasi konfigurasi 429

Uji kontrak respons

Uji yang dijalankan: picu batas secara aman di lingkungan terkontrol dan periksa respons mentah. Hasil yang diharapkan: 429 dengan Retry-After yang valid serta tanpa pengalihan atau status sukses yang tidak disengaja. Interpretasi kegagalan: lapisan atau templat galat yang keliru memiliki respons. Jendela pemantauan: segera. Pemicu rollback: permintaan normal ikut dibatasi atau uji mengganggu layanan.

Uji cakupan

Uji yang dijalankan: jalankan klien yang memang dibatasi, pengguna normal, dan trafik crawler terverifikasi pada kelas URL yang mewakili. Hasil yang diharapkan: hanya trafik yang ditentukan melampaui batas. Interpretasi kegagalan: kunci pembatasan laju atau cakupan aturan terlalu luas. Jendela pemantauan: selama uji terkontrol dan propagasi edge. Pemicu rollback: rute, pengguna, atau host yang tidak terkait menerima 429.

Uji pemulihan

Uji yang dijalankan: hentikan pemicu, tunggu selama interval percobaan ulang yang dikonfigurasi, lalu ulangi permintaan. Hasil yang diharapkan: respons normal yang stabil kembali tanpa solusi manual per URL. Interpretasi kegagalan: 429 yang di-cache atau keadaan pembatas masih bertahan. Jendela pemantauan: interval yang dikonfigurasi ditambah propagasi deployment. Pemicu rollback: hostname tetap dibatasi setelah beban dasarnya hilang.

Uji penyimpanan cache

Uji yang dijalankan: tempatkan cache atau edge CDN di depan rute terbatas, picu 429, lalu minta URL yang sama lagi setelah kondisi dasar pulih. Hasil yang diharapkan: permintaan kedua dievaluasi dari awal—tidak ada 429 yang di-cache atau diputar ulang dari edge. Interpretasi kegagalan: perantara menyimpan respons yang menurut RFC 6585 tidak boleh di-cache; periksa header cache-control dan konfigurasi aturan edge, bukan origin. Jendela pemantauan: segera, pada kumpulan node/POP edge yang mewakili. Pemicu rollback: ada 429 cache yang disajikan setelah origin pulih.

Uji kebijakan percobaan ulang klien

Uji yang dijalankan: kirim klien melalui respons 429 dengan dan tanpa header Retry-After yang valid. Hasil yang diharapkan: dengan header, klien menunggu interval yang ditentukan; tanpa header, klien menerapkan kebijakan backoff berjitter yang dibatasi, menghormati jumlah percobaan maksimum, dan memeriksa idempotensi sebelum mengulang permintaan yang tidak idempoten. Interpretasi kegagalan: klien yang langsung mencoba lagi, mencoba tanpa batas, atau membabi buta mengulang permintaan tidak idempoten memiliki kebijakan retry yang rusak, bukan masalah kepatuhan HTTP. Jendela pemantauan: selama seluruh rangkaian retry yang dibatasi. Pemicu rollback: klien memicu kembali batas laju yang sama melalui percobaan ulang langsung atau tanpa batas.

Sumber yang layak Anda luangkan waktu

Tulisan saya yang terkait

• Kode Status HTTP & Dampaknya terhadap SEO — panduan lengkap saya tentang pengaruh setiap kode status terhadap SEO, termasuk posisi 429.
• Panduan Pemula untuk SEO Teknis — tempat kontrol crawl dan kode status berada dalam gambaran yang lebih besar.
• Kisah Memblokir 2 Halaman Berperingkat Tinggi dengan Robots.txt — eksperimen langsung saya tentang apa yang terjadi ketika crawler diputus.

Presentasi saya

• Cara Kerja Penelusuran (SlideShare) — penjelasan saya tentang crawling, rendering, pengindeksan, dan peringkat, termasuk cara server memberi sinyal agar crawler melambat. (Penafian tetap saya berlaku: “This is my understanding of systems… not going to be 100% complete or accurate.” (terjemahan) “Ini adalah pemahaman saya tentang sistem… tidak akan 100% lengkap atau akurat.”)

Dari industri

• Jangan gunakan 403 atau 404 untuk pembatasan laju (Google Search Central, Gary Illyes) — pernyataan kanonis bahwa 429 adalah pengecualian.
• Kurangi laju crawl Google (Google) — jendela 1–2 hari, pembatasan seluruh hostname, dan pemulihan otomatis.
• Google memperingatkan agar tidak menggunakan kode status 403 atau 404 untuk membatasi crawl Googlebot (Search Engine Land) — liputan media industri atas posting Illyes.
• Google Mengatakan Hentikan Penggunaan 403 atau 404 untuk Mengurangi Laju Crawl Googlebot (Search Engine Roundtable) — ringkasan Barry Schwartz yang membingkai 429 sebagai “satu-satunya pengecualian”.
• Google: Jangan Gunakan Respons Galat 403/404 untuk Pembatasan Laju Googlebot (Search Engine Journal) — tulisan independen ketiga tentang panduan yang sama.
• MDN — 429 Too Many Requests — definisi spesifikasi HTTP dan referensi Retry-After.
• Panduan Bingbot — panduan Bing saat ini untuk direktif crawl-delay.

Uji diri: 429 Too Many Requests

Lima pertanyaan singkat tentang cara kerja 429 dan cara Google menanganinya. Pilih jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan