Mengatasi Error 429 Too Many Requests di WordPress: Penyebab, Diagnosis, dan Cara Memperbaikinya untuk Publisher Indonesia

Error 429 Too Many Requests adalah pesan dari server bahwa Anda mengirim terlalu banyak permintaan dalam waktu yang terlalu singkat. Berbeda dengan error 500-an yang menandakan server sedang bermasalah, 429 justru menandakan server masih sehat tetapi sengaja menahan Anda: sebuah mekanisme pengaman bernama rate limiting sedang bekerja. Bagi pengunjung, 429 terasa seperti situs yang tiba-tiba menolak melayani. Bagi pemilik situs WordPress, 429 yang muncul berulang adalah tanda ada sesuatu yang membanjiri server — bot yang menyerang halaman login, plugin yang melakukan polling tanpa henti, aturan Cloudflare yang terlalu ketat, atau batasan dari hosting yang sudah terlampaui.

Artikel ini menjelaskan error 429 dari nol sampai tuntas untuk publisher Indonesia: apa artinya menurut standar resmi, bagaimana rate limiting bekerja, mengapa error ini berbahaya bagi SEO dan pendapatan iklan, cara mendiagnosis sumbernya dari header dan log, sampai perbaikan konkret di sisi hosting, Cloudflare, dan WordPress. Semua klaim resmi dirujuk ke dokumen standar dan dokumentasi penyedia layanan; semua angka batas dan durasi yang bukan berasal dari dokumen resmi diberi label patokan praktik agar Anda tidak salah mengartikannya sebagai aturan baku.

Poin Kunci

• Error 429 Too Many Requests didefinisikan dalam RFC 6585: klien mengirim terlalu banyak permintaan dalam jangka waktu tertentu, dan server memintanya melambat.
• Header Retry-After adalah petunjuk resmi berapa lama harus menunggu sebelum mencoba lagi, dalam hitungan detik atau tanggal HTTP; patuhi angka ini sebelum melakukan apa pun.
• 429 bukan blokir permanen dan bukan tanda situs diretas, tetapi bila dibiarkan berhari-hari, Google dapat menurunkan laju crawl dan bahkan menghapus URL dari indeks.
• Penyebab paling umum di WordPress: serangan brute force ke wp-login.php dan xmlrpc.php, plugin atau WP-Cron yang melakukan request berulang, aturan rate limiting Cloudflare (Error 1015), dan batas request dari hosting.
• Diagnosis dimulai dari pertanyaan sederhana: siapa yang dibatasi, endpoint mana yang memicu, dan lapisan mana yang menjawab — server, CDN, atau plugin.
• Perbaikan yang benar menargetkan lapisan penyebabnya, bukan mematikan semua perlindungan: amankan login, perbaiki rule Cloudflare, rapikan plugin, dan hanya naikkan batas bila ada bukti batasnya memang terlalu rendah.

Daftar Isi

1. Apa Itu Error 429 Too Many Requests
2. Bagaimana Rate Limiting Bekerja di Balik Layar
3. Mengapa Error 429 Berbahaya untuk Publisher
4. Penyebab Error 429 Paling Umum di WordPress
5. Diagnosis Langkah demi Langkah: Menemukan Sumber 429
6. Perbaikan Cepat untuk Pengunjung yang Kena 429
7. Memperbaiki Rate Limit di Sisi Server dan Hosting
8. Mengamankan wp-login.php dan xmlrpc.php dari Serangan Bot
9. Mengatasi Error 429 dari Cloudflare (Termasuk Error 1015)
10. Mengatasi 429 yang Disebabkan Plugin, WP-Cron, dan REST API
11. Error 429 dan Googlebot: Memakai 429 dengan Benar untuk SEO
12. Checklist Pencegahan Jangka Panjang
13. FAQ
14. Kesimpulan
15. Sumber resmi yang dirujuk

1. Apa Itu Error 429 Too Many Requests

Error 429 Too Many Requests adalah kode status HTTP kelas 4xx, artinya kesalahannya berada di sisi klien — bukan karena server rusak, melainkan karena klien mengirim permintaan melebihi batas yang diizinkan. Definisi resminya ada dalam RFC 6585, dokumen standar yang diterbitkan IETF pada April 2012: “the user has sent too many requests in a given amount of time”, atau pengguna telah mengirim terlalu banyak permintaan dalam jangka waktu tertentu. Kode ini lahir karena HTTP/1.1 versi awal tidak memiliki kode khusus untuk pembatasan laju; sebelum 2012, server yang membatasi request terpaksa memakai kode lain seperti 403 atau 503 yang maknanya kurang tepat.

Perbedaan mendasar 429 dengan kode error lain yang sering muncul di WordPress perlu dipahami sejak awal, karena salah mengenali kode berarti salah memperbaiki. Error 403 Forbidden berarti server memahami permintaan Anda tetapi menolak memberi akses, biasanya karena izin file, aturan keamanan, atau alamat IP yang diblokir — tidak ada hubungannya dengan seberapa sering Anda meminta. Error 503 Service Unavailable berarti server untuk sementara tidak mampu melayani permintaan, misalnya karena sedang kelebihan beban atau dalam perawatan. Error 504 Gateway Timeout berarti server perantara menunggu terlalu lama jawaban dari server asal. Sementara 429 berarti server mampu melayani, tetapi Anda — atau alamat IP Anda, atau akun Anda — sudah melewati kuota permintaan yang diizinkan dalam jendela waktu tertentu. Server tidak rusak; ia hanya meminta Anda menunggu.

Satu hal penting dari RFC 6585: respons 429 tidak boleh disimpan oleh cache. Alasannya masuk akal — bila cache menyimpan respons 429, pengunjung lain bisa ikut menerima pesan pembatasan yang sebenarnya ditujukan untuk orang lain. Selain itu, RFC 6585 menyatakan respons 429 boleh menyertakan header Retry-After yang memberitahu berapa lama klien harus menunggu sebelum mencoba lagi. Header ini bersifat opsional menurut standar, tetapi dalam praktiknya menjadi petunjuk paling berharga saat Anda menghadapi 429: bila ada, patuhi angka itu; bila tidak ada, Anda harus menebak dengan jeda yang masuk akal dan backoff bertahap.

Bagi publisher, konteksnya begini. Satu kali membuka halaman artikel WordPress bukan satu request. Satu tampilan halaman adalah puluhan request: dokumen HTML, stylesheet, JavaScript, font, gambar, dan panggilan latar seperti admin-ajax atau REST API. Artinya, aturan yang menghitung setiap request mentah bisa terpicu oleh perilaku yang terlihat normal — misalnya membuka banyak tab sekaligus, me-refresh berkali-kali, atau menjelajah cepat dari satu artikel ke artikel lain. Di sisi lain, bot jahat memang sengaja mengirim ratusan request per menit ke halaman login. Rate limiting harus membedakan keduanya, dan ketika gagal membedakan, pengunjung asli yang menjadi korban. Itulah mengapa diagnosis 429 selalu dimulai dari pertanyaan: request siapa, ke endpoint mana, dan seberapa cepat.

2. Bagaimana Rate Limiting Bekerja di Balik Layar

Rate limiting adalah aturan yang menghitung jumlah permintaan dari satu identitas — biasanya alamat IP, tetapi bisa juga akun pengguna, kunci API, atau cookie — dalam satu jendela waktu, lalu menolak permintaan yang melewati ambang. Identitas dan jendela inilah yang menentukan apakah seseorang terkena 429 atau tidak. Dua pengunjung dari jaringan kantor yang sama bisa berbagi satu alamat IP publik, sehingga hitungan mereka tercampur. Sebaliknya, satu pengguna yang memakai VPN bisa berbagi alamat IP dengan ratusan orang asing. Inilah alasan 429 kadang muncul padahal Anda merasa baru membuka situs sekali: Anda mungkin sedang berbagi alamat IP dengan orang lain yang sedang agresif, atau jaringan Anda sedang ramai.

Ada dua model jendela yang paling umum dipakai. Jendela tetap (fixed window) menghitung request dalam blok waktu yang kaku, misalnya 100 request per menit dari pukul 10:00 sampai 10:01, lalu hitungan direset. Kelemahannya, seseorang bisa mengirim 100 request di detik terakhir menit pertama dan 100 lagi di detik pertama menit berikutnya, sehingga dalam dua detik ada 200 request. Jendela geser (sliding window) menghitung request dalam rentang yang terus bergerak, misalnya 100 request dalam 60 detik terakhir kapan pun, sehingga celah itu tertutup. Model lain yang populer adalah token bucket: setiap identitas memiliki ember berisi token yang terisi perlahan, dan setiap request mengambil satu token; bila ember kosong, request ditolak sampai token terisi lagi. Anda tidak perlu menghafal modelnya, tetapi memahami konsep ini membantu saat membaca dokumentasi hosting atau CDN: angka seperti “100 request per menit” selalu disertai pertanyaan lanjutan — per apa, dalam jendela seperti apa, dan apa yang terjadi saat terlampaui.

Ketika batas terlampaui, server menjawab dengan status 429 dan, bila dikonfigurasi dengan baik, menyertakan header tambahan. Header yang paling penting adalah Retry-After. Menurut RFC 9110, header ini berisi salah satu dari dua bentuk: angka detik yang harus ditunggu, misalnya Retry-After: 120 yang berarti tunggu 120 detik, atau tanggal HTTP, misalnya Retry-After: Wed, 21 Oct 2026 07:28:00 GMT yang berarti coba lagi setelah waktu tersebut. Selain Retry-After, banyak layanan menambahkan header non-standar seperti X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset yang memberitahu sisa kuota dan kapan kuota pulih. Header-header ini masih berupa konvensi yang berbeda-beda antar penyedia, dan IETF masih mengerjakan standarisasi lewat draf RateLimit — jadi jangan mengandalkan namanya, tetapi bila tersedia, bacalah: angka Remaining: 0 dan Reset adalah konfirmasi langsung bahwa kuota Anda habis.

Respons 429 yang baik juga menyertakan isi yang menjelaskan batas mana yang terlewati. Cloudflare, misalnya, menampilkan halaman Error 1015 “You are being rate limited” beserta Ray ID — kode unik yang bisa dilacak di dasbor untuk mengetahui aturan mana yang memicu. Nginx yang dikonfigurasi dengan limit_req_status 429 akan menjawab 429 alih-alih 503 bawaan, supaya klien dan alat monitoring bisa membedakan pembatasan laju dari gangguan server. Sebaliknya, respons 429 yang buruk tidak menyertakan apa pun selain kode status, sehingga Anda harus menebak dari log. Prinsip diagnosisnya sama di semua kasus: temukan siapa yang menjawab 429 — server asal, CDN, atau aplikasi — karena hanya lapisan itulah yang bisa mengubah aturannya.

Satu kesalahpahaman yang perlu diluruskan: menaikkan batas atau mematikan rate limiting bukanlah perbaikan. Rate limiting ada untuk melindungi server dari kehabisan sumber daya dan dari serangan. Bila batas dinaikkan tanpa memahami siapa yang membanjiri server, bot akan kembali membanjiri dengan volume lebih besar. Perbaikan yang benar adalah menemukan sumber banjirnya, lalu membatasi sumber itu secara spesifik — atau, bila sumbernya adalah pengunjung asli, barulah batas untuk pola lalu lintas yang sah itu dilonggarkan.

3. Mengapa Error 429 Berbahaya untuk Publisher

Bagi situs berita atau blog yang hidup dari iklan, 429 bukan sekadar pesan error teknis. Dampaknya menyentuh tiga hal sekaligus: pengalaman pembaca, pendapatan iklan, dan visibilitas di Google. Ketiganya saling terkait, dan kerugiannya membesar bila error dibiarkan berhari-hari.

Dampak pertama adalah pengalaman pembaca. Pengunjung yang melihat halaman 429 tidak bisa membaca artikel Anda. Bila ia baru pertama kali datang dari Google atau media sosial, kemungkinan besar ia tidak akan kembali mencoba — ia akan kembali ke hasil pencarian dan membuka situs lain. Untuk situs yang mengandalkan traffic organik, setiap sesi yang gagal adalah pembaca yang hilang. Lebih buruk lagi bila 429 muncul secara sporadis dan hanya menimpa sebagian pengunjung: Anda mungkin tidak menyadarinya selama berminggu-minggu, sementara sebagian pembaca diam-diam pergi. Alat monitoring uptime biasa sering tidak menangkap ini, karena halaman utama mungkin tetap menjawab 200 untuk alat monitoring sementara pengunjung dari jaringan tertentu terus mendapat 429.

Dampak kedua adalah pendapatan iklan. Iklan AdSense dan jaringan iklan lain dimuat lewat request tambahan setelah halaman terbuka. Bila request ke server dibatasi, halaman mungkin terbuka setengah, iklan gagal dimuat, atau skrip iklan ikut terkena pembatasan. Halaman yang tidak menampilkan iklan berarti impresi yang hilang, dan impresi yang hilang berarti pendapatan yang hilang — tanpa ada peringatan pelanggaran kebijakan apa pun. Selain itu, bila Googlebot juga menerima 429 saat merayapi halaman, Google bisa menilai halaman tersebut tidak dapat diakses, yang berpengaruh pada proses indexing seperti dijelaskan di bagian 11.

Dampak ketiga, dan yang paling serius dalam jangka panjang, adalah SEO. Google Search Central secara eksplisit mendokumentasikan perilaku Googlebot terhadap 429. Dalam panduan “Reduce the Google crawl rate” yang ditulis ulang pada 6 Oktober 2026, Google menjelaskan bahwa bila crawler menemui sejumlah besar respons 500, 503, atau 429, Google akan menurunkan laju crawl untuk seluruh hostname — bukan hanya URL yang error, tetapi juga URL yang masih normal. Laju crawl akan naik lagi secara otomatis setelah jumlah error berkurang. Namun ada batasnya: panduan yang sama memperingatkan agar respons error semacam ini tidak dipertahankan lebih dari satu sampai dua hari, karena bila Googlebot melihat kode error yang sama pada URL yang sama selama beberapa hari, URL tersebut dapat dihapus dari indeks Google. Dengan kata lain, 429 yang dibiarkan lebih dari dua hari dapat berubah dari masalah sementara menjadi kehilangan halaman di hasil pencarian.

Angka “satu sampai dua hari” itu penting dan resmi dari Google, tetapi jangan salah membacanya. Google tidak mengatakan setiap 429 selama dua hari pasti menghapus URL; yang dikatakan adalah risiko penghapusan muncul bila error bertahan beberapa hari pada URL yang sama. Praktiknya: 429 yang muncul beberapa jam karena lonjakan traffic atau serangan bot biasanya pulih sendiri dan tidak meninggalkan kerusakan SEO permanen, asalkan penyebabnya diperbaiki dan server kembali menjawab 200. Sebaliknya, 429 yang muncul karena aturan Cloudflare yang salah sasaran dan dibiarkan seminggu penuh adalah masalah serius. Karena itu, begitu Anda tahu 429 muncul di situs Anda, perlakukan sebagai prioritas — bukan darurat yang membuat panik, tetapi bukan pula hal yang bisa ditunda sampai sempat.

Ada satu sisi lain yang justru positif: 429 adalah alat darurat resmi yang disediakan Google untuk pemilik situs. Bila server Anda sedang kritis dan Googlebot ikut membebani, Anda boleh sengaja menjawab crawl Google dengan 429 (atau 500/503) selama beberapa jam sampai satu-dua hari, lengkap dengan header Retry-After, agar Google melambat. Bagian 11 membahas cara memakai alat ini dengan benar — dan kapan pemakaian itu justru merugikan.

4. Penyebab Error 429 Paling Umum di WordPress

Penyebab 429 di WordPress hampir selalu jatuh ke salah satu dari enam kelompok berikut. Mengenali kelompoknya adalah separuh diagnosis, karena setiap kelompok diperbaiki di tempat yang berbeda.

4.1 Serangan brute force ke wp-login.php dan xmlrpc.php

Ini penyebab paling umum di situs WordPress mana pun. Bot mencoba kombinasi username dan password yang bocor atau umum terhadap /wp-login.php dan /xmlrpc.php sepanjang hari, di hampir semua situs WordPress. WordPress core tidak membatasi jumlah percobaan login yang gagal, sehingga bot bisa mencoba tanpa henti kecuali ada lapisan lain yang menghentikannya. Bila hosting atau plugin keamanan Anda memasang rate limiting untuk merespons serangan ini, batas itu bisa ikut menangkap lalu lintas sah — misalnya Anda sendiri yang beberapa kali salah mengetik password, atau beberapa editor yang login bersamaan dari satu jaringan kantor. Gejalanya khas: 429 muncul saat membuka halaman login atau wp-admin, sementara halaman artikel biasa tetap normal.

Endpoint xmlrpc.php patut mendapat perhatian khusus. XML-RPC adalah API jarak jauh lama yang juga menerima username dan password, dan dipakai oleh aplikasi mobile WordPress lama serta Jetpack. Secara historis, metode system.multicall di dalamnya bisa dipakai untuk menguji banyak password dalam satu request, sehingga menjadi penguat serangan brute force. Sejak WordPress 4.4, perilaku itu sudah dibatasi — percobaan login pertama yang gagal dalam satu request multicall membuat panggilan berikutnya ikut gagal — tetapi xmlrpc.php tetap menjadi pintu login kedua yang perlu dibatasi seperti wp-login.php. Bila Anda tidak memakai aplikasi mobile WordPress atau Jetpack, menutup endpoint ini sepenuhnya adalah pilihan yang masuk akal dan direkomendasikan panduan hardening WordPress.

4.2 Plugin atau integrasi yang melakukan request berulang

WordPress modern sangat bergantung pada request latar: admin-ajax.php untuk fitur dinamis tema dan plugin, REST API (/wp-json/) untuk editor blok dan integrasi, serta wp-cron.php untuk tugas terjadwal. Bila salah satu plugin rusak, salah konfigurasi, atau terjebak loop, ia bisa mengirim request yang sama berulang kali dalam hitungan detik — ke server sendiri maupun ke layanan luar — dan memicu rate limiting di hosting, di plugin keamanan, atau di API pihak ketiga. Contoh pola yang sering terjadi: plugin impor yang menarik feed tanpa jeda, plugin sinkronisasi stok yang mem-poll setiap beberapa detik, plugin statistik yang memanggil endpoint sendiri berulang kali, atau tugas cron yang gagal dan dijadwalkan ulang tanpa henti sehingga menumpuk. Gejalanya: 429 muncul di jam-jam tertentu yang cocok dengan jadwal tugas, atau muncul bersamaan dengan lonjakan beban CPU di hosting.

4.3 Aturan rate limiting Cloudflare atau CDN lain

Bila situs Anda berada di balik Cloudflare, sebagian 429 tidak berasal dari server Anda sama sekali, melainkan dari aturan rate limiting yang Anda — atau pemilik situs — buat sendiri di dasbor Cloudflare. Cloudflare menjawab dengan Error 1015 beserta status HTTP 429 ketika sebuah request melewati ambang aturan tersebut. Ciri khasnya: ada header cf-ray pada respons, dan halaman error bermerek Cloudflare. Penyebab paling sering adalah aturan yang menghitung semua request termasuk aset statis — padahal satu tampilan halaman bisa berisi puluhan request gambar, CSS, dan font — atau aturan yang menghitung per alamat IP di jaringan yang dipakai bersama banyak orang, seperti jaringan kantor, kampus, atau operator seluler. Aturan yang terlalu luas juga bisa menangkap polling latar situs sendiri, misalnya Heartbeat API WordPress yang memeriksa draf otomatis setiap beberapa puluh detik.

4.4 Batasan request dari hosting

Hosting bersama (shared hosting) dan paket hosting murah biasanya memiliki batas tersembunyi: jumlah request per menit, jumlah proses PHP bersamaan, atau batas CPU. Bila situs Anda mendapat lonjakan traffic — misalnya artikel viral atau dibagikan di grup besar — batas ini terlampaui dan hosting mulai menjawab 429 atau 503. Pada sebagian penyedia, batas ini tidak terdokumentasi secara terbuka dan hanya terlihat dari log atau dari jawaban tim dukungan. Gejalanya: 429 muncul saat traffic naik, hilang saat traffic turun, dan tidak terkait dengan endpoint tertentu. Ini juga alasan mengapa 429 bisa muncul bersamaan dengan error 503 atau 504 di periode yang sama: ketiganya adalah gejala server yang kewalahan, hanya penyebab dan lapisannya berbeda.

4.5 Bot, scraper, dan crawler yang agresif

Selain Googlebot, ada banyak crawler lain yang mengunjungi situs Anda: bot SEO, scraper konten, bot AI yang mengumpulkan data latih, dan alat monitoring. Sebagian mematuhi robots.txt, sebagian tidak. Satu scraper yang membuka ratusan halaman per menit dari satu alamat IP bisa memicu rate limiting hosting atau Cloudflare — dan bila aturan dihitung per IP, pengunjung asli yang kebetulan berbagi IP yang sama ikut terkena. Gejala khas: log akses dipenuhi request dari satu atau beberapa alamat IP dengan user agent yang sama, sering kali pada pola URL berurutan seperti arsip tanggal atau halaman kategori.

4.6 Jaringan yang dipakai bersama: VPN, kantor, dan operator seluler

Penyebab ini sering luput karena bukan kesalahan situs Anda. Bila Anda memakai VPN, alamat IP keluar VPN dipakai bersama ratusan pengguna lain; bila salah satu dari mereka agresif, seluruh pengguna IP itu bisa terkena 429. Hal yang sama berlaku untuk jaringan kantor, kampus, Wi-Fi publik, dan operator seluler yang memakai CGNAT — teknologi yang membuat banyak pelanggan berbagi satu alamat IP publik. Dalam kasus ini, 429 hanya menimpa Anda (dan orang-orang di jaringan yang sama), sementara pengunjung lain baik-baik saja. Diagnosisnya mudah: coba buka situs dari jaringan lain, misalnya beralih dari Wi-Fi ke data seluler, dan lihat apakah error hilang.

5. Diagnosis Langkah demi Langkah: Menemukan Sumber 429

Diagnosis 429 yang baik mengikuti urutan dari luar ke dalam: mulai dari apa yang terlihat di browser, lalu ke header, lalu ke log. Jangan langsung mengubah konfigurasi sebelum tahu lapisan mana yang menjawab 429.

Langkah 1: Baca pesan dan header responsnya

Buka alat pengembang browser (biasanya tombol F12), masuk ke tab Network, lalu muat ulang halaman yang error. Klik request yang berstatus 429 dan baca header responsnya. Tiga hal yang dicari: pertama, nilai Retry-After — bila ada, itulah waktu tunggu resmi yang diminta server. Kedua, header cf-ray — bila ada, respons berasal dari Cloudflare, bukan server Anda, sehingga perbaikan dilakukan di dasbor Cloudflare. Ketiga, header X-RateLimit-* atau pesan isi respons yang menyebut nama aturan atau layanan — misalnya nama plugin keamanan atau nama aturan WAF. Bila halaman error menampilkan merek Cloudflare beserta Ray ID, catat Ray ID itu: di dasbor Cloudflare, menu Security Events bisa difilter berdasarkan Ray ID untuk melihat aturan mana yang memicu, request apa yang cocok, dan karakteristik penghitungannya.

Langkah 2: Tentukan polanya — siapa, kapan, dan di mana

Tanyakan empat hal dan catat jawabannya sebelum melangkah: (1) Apakah 429 menimpa semua pengunjung atau hanya sebagian? Bila hanya sebagian, kemungkinan besar masalahnya ada di alamat IP atau jaringan mereka, bukan di situs. (2) Apakah 429 muncul di semua halaman atau hanya endpoint tertentu seperti wp-login, wp-admin, atau wp-json? Bila hanya di endpoint tertentu, penyebabnya hampir pasti aturan yang menyasar endpoint itu. (3) Kapan mulai muncul — apakah bersamaan dengan instalasi plugin baru, perubahan aturan Cloudflare, atau lonjakan traffic? (4) Apakah error hilang sendiri setelah beberapa menit? Pola hilang-timbul yang mengikuti jam sibuk mengarah ke batas hosting atau lonjakan traffic, sedangkan 429 yang menetap mengarah ke aturan yang salah konfigurasi.

Langkah 3: Periksa log akses dan log keamanan

Log adalah bukti, bukan tebakan. Di log akses server, hitung request berulang ke wp-login.php, xmlrpc.php, wp-cron.php, admin-ajax.php, dan /wp-json/ dalam rentang waktu singkat. Perintah baris perintah sederhana bisa membantu bila Anda punya akses SSH, misalnya menghitung alamat IP dengan request terbanyak dalam satu jam terakhir. Tetapi bila Anda memakai shared hosting tanpa SSH, panel hosting biasanya menyediakan penghitung pengunjung atau log mentah yang bisa diunduh. Di sisi plugin keamanan, periksa log pemblokiran: plugin seperti Wordfence dan Limit Login Attempts Reloaded mencatat alamat IP yang diblokir beserta alasannya. Bila log menunjukkan satu alamat IP mengirim ratusan request login dalam beberapa menit, Anda sudah menemukan pelakunya — dan perbaikannya adalah memblokir atau membatasi IP itu, bukan menaikkan batas global.

Langkah 4: Uji dari jaringan dan perangkat berbeda

Buka situs dari data seluler bila sebelumnya memakai Wi-Fi, atau sebaliknya. Buka juga dari browser lain atau mode penyamaran untuk menyingkirkan kemungkinan cookie atau ekstensi. Bila error hilang saat berganti jaringan, penyebabnya adalah alamat IP Anda yang ikut terhitung bersama pengguna lain — solusinya menunggu sampai jendela pembatasan berakhir, bukan mengubah situs. Bila error tetap muncul di semua jaringan dan perangkat, penyebabnya ada di sisi server atau CDN. Uji tambahan: buka satu halaman artikel biasa dan satu endpoint seperti /wp-login.php secara terpisah. Bila hanya login yang error, masalahnya ada di pembatasan login; bila semua halaman error, masalahnya ada di batas global hosting atau CDN.

Langkah 5: Periksa Search Console dan status crawl

Bila Anda pemilik situs, buka Google Search Console dan periksa laporan Crawl Stats serta Page Indexing. Google mencatat kapan crawler menerima 429 dan URL mana yang terdampak. Bila grafik menunjukkan lonjakan 429 bertepatan dengan waktu Anda mengubah aturan Cloudflare atau menginstal plugin baru, Anda menemukan korelasinya. Periksa juga apakah halaman yang terdampak sudah mulai keluar dari indeks — ini menentukan seberapa mendesak perbaikan Anda. Langkah ini penting karena 429 sering tidak terlihat dari sisi pemilik situs: halaman utama mungkin baik-baik saja untuk Anda, sementara Googlebot dari alamat IP-nya sendiri terus menerima 429.

Tabel 1: Membandingkan 429 dengan kode error WordPress lain

Tabel 2: Tanda-tanda untuk mengenali sumber 429

6. Perbaikan Cepat untuk Pengunjung yang Kena 429

Bagian ini untuk Anda yang sedang menjadi pengunjung — pembaca situs orang lain, atau pemilik situs yang terkunci dari wp-admin situs sendiri. Langkah-langkahnya sederhana dan tidak membutuhkan akses server.

Pertama, patuhi Retry-After bila tersedia. Bila halaman error atau header menyebutkan angka detik, tunggu selama itu sebelum mencoba lagi. Me-refresh berulang justru memperpanjang pembatasan, karena setiap refresh adalah request baru yang ikut dihitung — dan bila jendela hitung memakai model geser, refresh berulang bisa memperpanjang masa tunggu tanpa henti. Sebagai patokan praktik, bila tidak ada angka resmi, tunggu 60 detik untuk percobaan pertama, lalu 5 menit bila masih error, lalu 15–30 menit; jangan me-refresh setiap beberapa detik.

Kedua, jangan membuka banyak tab sekaligus dan jangan memakai alat unduh massal pada situs itu. Setiap tab yang memuat halaman adalah puluhan request. Bila Anda membuka sepuluh artikel sekaligus di tab baru, Anda sendiri yang memicu pembatasan. Tutup tab lain, buka satu halaman, dan tunggu sampai termuat penuh sebelum membuka berikutnya.

Ketiga, coba ganti jaringan. Beralih dari Wi-Fi ke data seluler — atau sebaliknya — akan mengubah alamat IP publik Anda, sehingga hitungan rate limit dimulai dari nol. Bila Anda memakai VPN, matikan sementara dan coba tanpa VPN, karena alamat IP keluar VPN sering dipakai bersama banyak orang. Bila error hilang setelah ganti jaringan, masalahnya bukan di situs, melainkan di alamat IP lama Anda yang sedang ikut terhitung.

Keempat, bersihkan cache dan cookie hanya bila langkah di atas tidak berhasil. Membersihkan cache tidak memperbaiki 429, karena 429 bukan masalah cache — tetapi cookie sesi yang rusak kadang membuat browser mengulang request autentikasi berkali-kali. Ini langkah kecil yang murah dan kadang membantu, tetapi jangan menjadikannya langkah pertama.

Kelima, bila Anda adalah pemilik situs dan terkunci dari wp-admin, jangan panik dan jangan langsung mematikan plugin keamanan lewat FTP tanpa diagnosis. Pertama coba akses dari jaringan lain; bila berhasil, berarti IP Anda yang diblokir sementara dan akan pulih sendiri. Bila semua jaringan gagal, barulah gunakan akses file manager hosting untuk menonaktifkan sementara plugin pembatas login — dan aktifkan lagi segera setelah Anda masuk, dengan aturan yang sudah diperbaiki. Bila Anda tidak yakin, hubungi dukungan hosting dan sebutkan alamat IP Anda serta waktu kejadian; mereka bisa memeriksa log dan membuka blokir dari sisi server.

Catatan penting: jangan pernah memakai trik untuk mengakali rate limiting situs orang lain — misalnya memutar alamat IP atau mempercepat request dengan sengaja. Selain melanggar ketentuan layanan situs tersebut, perilaku itu justru memperkuat alasan situs memblokir Anda. Rate limiting adalah mekanisme perlindungan yang sah, dan cara yang benar untuk menghadapinya adalah menunggu atau menghubungi pemilik situs.

7. Memperbaiki Rate Limit di Sisi Server dan Hosting

Bila diagnosis menunjukkan sumber 429 ada di hosting atau server, perbaikan dilakukan di lapisan itu — bukan di WordPress. Ada tiga skenario umum, tergantung seberapa besar kendali Anda atas server.

7.1 Bila Anda memakai shared hosting

Di shared hosting, Anda tidak bisa mengubah konfigurasi web server sendiri. Langkah pertama adalah menghubungi dukungan hosting dengan data yang sudah Anda kumpulkan: kapan 429 mulai muncul, endpoint apa yang terdampak, dan apakah bertepatan dengan lonjakan traffic. Tanyakan tiga hal secara spesifik: apakah ada batas request per menit atau batas proses PHP bersamaan pada paket Anda, apakah batas itu yang sedang terlampaui, dan berapa ambangnya. Jawaban ini menentukan langkah berikutnya: bila batas terlampaui karena lonjakan traffic yang sah, solusinya bisa berupa caching yang lebih baik atau naik paket; bila batas terlampaui karena bot, solusinya adalah memblokir bot itu di level hosting atau CDN, bukan menaikkan batas.

Sementara menunggu jawaban hosting, kurangi beban yang Anda kendalikan. Aktifkan caching halaman penuh bila belum aktif, karena halaman yang tersaji dari cache tidak membebani PHP dan tidak menambah hitungan proses. Periksa apakah ada tugas terjadwal yang berjalan terlalu sering, dan matikan sementara integrasi yang memanggil situs Anda dari luar tanpa jeda. Bila situs Anda memakai layanan monitoring uptime yang memeriksa situs setiap menit dari banyak lokasi, longgarkan intervalnya sebagai patokan praktik — misalnya dari setiap 1 menit menjadi setiap 5 menit — karena setiap pemeriksaan adalah request yang ikut dihitung.

7.2 Bila Anda memakai VPS dengan Nginx

Di Nginx, rate limiting diatur dengan modul limit_req. Contoh konfigurasi yang umum dipakai untuk melindungi halaman login — dan dikutip dari panduan keamanan WordPress yang beredar — adalah sebagai berikut, sebagai ilustrasi konfigurasi, bukan angka baku:

limit_req_zone $binary_remote_addr zone=wplogin:10m rate=10r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    limit_req_status 429;
}

Baris pertama (di blok http) mendefinisikan zona bernama wplogin sebesar 10 MB yang menghitung request per alamat IP dengan laju 10 request per menit. Blok kedua (di blok server, di atas lokasi PHP umum) menerapkan zona itu ke halaman login dengan toleransi lonjakan 5 request sekaligus, dan request yang melewati batas dijawab 429.

Angka 10 request per menit dengan burst 5 adalah patokan praktik yang wajar untuk login manusia — orang sungguhan jarang login lebih dari beberapa kali dalam satu menit — tetapi angka ini harus disesuaikan dengan kebutuhan Anda. Bila tim redaksi Anda bekerja dari satu jaringan kantor dan sering login bersamaan, angka yang terlalu ketat akan mengunci mereka sendiri. Sebaliknya, angka yang terlalu longgar tidak menghentikan bot. Prinsipnya: batasi hanya endpoint yang memang perlu dibatasi — wp-login.php dan xmlrpc.php — dan jangan menerapkan batas ketat ke seluruh situs, karena satu tampilan halaman saja sudah berisi puluhan request.

Satu hal teknis yang sering luput: bila situs Anda berada di balik Cloudflare atau CDN lain, Nginx akan melihat alamat IP Cloudflare, bukan alamat IP pengunjung asli, kecuali Anda mengonfigurasi modul real IP. Akibatnya, semua pengunjung terhitung sebagai satu identitas dan batas tercapai dengan sangat cepat. Pastikan Nginx menerima header CF-Connecting-IP atau X-Forwarded-For yang benar sebelum menyimpulkan aturan rate limiting Anda bekerja dengan benar.

7.3 Bila Anda memakai Apache atau LiteSpeed

Apache tidak bisa menghitung request per IP dari .htaccess saja; pembatasan laju yang sesungguhnya membutuhkan modul server seperti mod_evasive atau ModSecurity, yang konfigurasinya menjadi wewenang pengelola server atau hosting. Yang bisa Anda lakukan dari .htaccess adalah memblokir akses ke file tertentu sepenuhnya — misalnya menolak semua akses ke xmlrpc.php bila tidak dipakai — tetapi itu pemblokiran, bukan pembatasan laju. Untuk LiteSpeed, yang dipakai banyak hosting Indonesia, tersedia fitur perlindungan bawaan di panel hosting; periksa menu keamanan di panel Anda sebelum mengutak-atik file konfigurasi. Bila hosting Anda tidak menyediakan pengaturan ini, minta bantuan dukungan hosting dan sebutkan secara spesifik endpoint yang ingin dibatasi.

Tabel 3: Pilihan perbaikan menurut lapisan sumber 429

8. Mengamankan wp-login.php dan xmlrpc.php dari Serangan Bot

Karena serangan brute force adalah penyebab 429 paling umum di WordPress, mengamankan dua endpoint ini adalah perbaikan dengan dampak terbesar. Tujuannya bukan sekadar menghentikan 429, tetapi menghentikan banjir request di sumbernya sehingga batas rate limiting tidak lagi tercapai.

Langkah pertama adalah membatasi percobaan login. WordPress core tidak membatasi percobaan login yang gagal, jadi perlindungan ini harus ditambahkan lewat plugin atau server. Plugin Limit Login Attempts Reloaded adalah pilihan populer yang tersedia gratis di direktori plugin WordPress.org: ia mengunci alamat IP setelah sejumlah percobaan gagal dan mencatatnya di log. Alternatifnya, plugin keamanan menyeluruh seperti Wordfence menyediakan pengaturan pembatasan percobaan login sekaligus pembatasan crawler, beserta log yang mudah dibaca. Pilih satu plugin dan pakai secara konsisten — memasang dua plugin pembatas login sekaligus bisa saling bertabrakan dan menghasilkan pemblokiran ganda yang sulit didiagnosis. Sebagai patokan praktik, kunci IP setelah beberapa kali gagal dalam waktu singkat dan beri masa kunci yang cukup lama untuk menghentikan bot, tetapi cukup singkat agar pengguna asli yang salah mengetik password tidak terkunci seharian; angka pastinya sesuaikan dengan pengaturan bawaan plugin yang Anda pakai, dan catat angka itu agar bisa dievaluasi.

Langkah kedua adalah mengaktifkan autentikasi dua faktor (2FA) untuk semua akun administrator. 2FA tidak langsung menghentikan 429, tetapi menghentikan nilai serangan brute force: sekalipun bot berhasil menebak password, ia tetap tidak bisa masuk tanpa kode dari ponsel Anda. Plugin Two Factor yang dikelola kontributor WordPress.org mendukung aplikasi authenticator, kode email, dan kode cadangan. Dengan 2FA aktif, Anda bisa lebih tenang melonggarkan sedikit batas login untuk pengguna asli, karena lapisan keamanan utama sudah bukan lagi sekadar password.

Langkah ketiga adalah menutup xmlrpc.php bila tidak dipakai. Periksa dulu apakah ada yang memakainya: aplikasi mobile WordPress versi lama dan Jetpack adalah pengguna utama. Bila tidak ada, blokir file ini di level server — di Nginx dengan location = /xmlrpc.php { deny all; }, di Apache dengan blok <Files "xmlrpc.php"> Require all denied </Files> — karena pemblokiran di level server menghentikan request sebelum PHP berjalan, sehingga lebih hemat sumber daya daripada membiarkan plugin yang menanganinya. Bila Anda memakai filter xmlrpc_enabled di WordPress, ketahuilah batasnya: filter itu hanya menonaktifkan metode yang membutuhkan autentikasi, sementara pingback dan metode sistem tetap menjawab. Karena itu, pemblokiran di level server adalah cara yang lebih tuntas. Bila Jetpack atau aplikasi mobile memang dipakai, jangan menutupnya; batasi saja seperti wp-login.php dan pantau lognya.

Langkah keempat adalah mengurangi permukaan serangan login secara umum: jangan memakai username admin yang sudah ditebak semua bot, pakai password panjang yang unik untuk setiap akun dan simpan di pengelola password, dan pertimbangkan membatasi akses wp-login.php berdasarkan alamat IP bila tim Anda bekerja dari alamat tetap. Terakhir, tinjau application password di menu Users → Profile dan cabut yang tidak dikenal — application password melewati pembatasan login dan 2FA, sehingga satu kredensial yang bocor bisa menjadi sumber banjir request yang tidak terdeteksi oleh aturan login biasa.

9. Mengatasi Error 429 dari Cloudflare (Termasuk Error 1015)

Bila diagnosis menunjukkan header cf-ray pada respons 429, perbaikan dilakukan di dasbor Cloudflare, bukan di WordPress. Penting untuk memahami satu hal dulu: Error 1015 bukan keputusan Cloudflare tentang situs Anda — itu adalah aturan rate limiting yang Anda (atau pemilik situs) buat sendiri dan sedang bekerja sesuai konfigurasinya. Bila pengunjung asli terkena, aturan itu sedang menghitung hal yang salah, bukan sedang melindungi Anda.

Langkah pertama adalah menemukan aturan yang memicu. Di dasbor Cloudflare, buka Security → Events, lalu filter berdasarkan Ray ID dari halaman error yang diterima pengunjung. Hasil filter menunjukkan nama aturan, request yang cocok, dan karakteristik penghitungan — apakah dihitung per alamat IP, per cookie, atau per header lain. Tanpa informasi ini, mengubah aturan hanyalah tebakan.

Setelah aturan ditemukan, periksa lima kesalahan konfigurasi yang paling sering membuat pengunjung asli terkena 1015. Pertama, aturan menghitung semua request, bukan hanya endpoint yang penting. Satu tampilan halaman bisa berisi puluhan request aset statis — gambar, CSS, font, JavaScript — sehingga ambang seperti “100 request per menit” bisa tercapai oleh satu pengunjung yang membuka dua artikel. Perbaikannya: batasi cakupan aturan ke endpoint yang memang perlu dilindungi, seperti halaman login, endpoint pencarian, atau rute API yang mahal, dan kecualikan aset statis. Kedua, aturan menghitung polling latar sebagai aktivitas pengguna. Heartbeat API WordPress, pengecekan draf otomatis, dan skrip tema yang mem-poll bisa menambah puluhan request per menit tanpa disadari. Ketiga, aturan menghitung per alamat IP di jaringan bersama. Jaringan kantor, kampus, dan operator seluler bisa menempatkan ratusan pengguna di satu alamat IP publik; ambang yang masuk akal untuk satu pengguna menjadi terlalu kecil untuk ratusan pengguna. Pertimbangkan menghitung berdasarkan cookie atau karakteristik lain bila tersedia di paket Anda, atau naikkan ambang untuk aturan yang dihitung per IP. Keempat, aturan mencakup seluruh situs. Rate limiting adalah alat yang ditargetkan; aturan yang cocok dengan semua path hampir selalu salah sasaran. Kelima, aturan menghitung hanya request yang gagal — misalnya beberapa kali salah password bisa memicu aturan yang menghitung request gagal, sehingga pengguna asli yang salah mengetik tiga kali ikut terblokir.

Bila aturan sudah diperbaiki tetapi pengunjung masih terkena, periksa durasi blokir dan karakteristik penghitungannya di pengaturan aturan. Sebagai patokan umum dari panduan Cloudflare, durasi blokir bawaan berbeda menurut paket, dan pemilik paket yang lebih tinggi bisa mengatur durasi sendiri atau memilih memblokir hanya request yang melewati batas. Jangan menaikkan ambang secara membabi buta sebagai jalan pintas: menaikkan ambang membuat gejala lebih jarang tanpa memperbaiki kemampuan aturan membedakan bot dari manusia. Perbaiki dulu cakupannya, baru sesuaikan ambangnya berdasarkan data dari dasbor Rate Limiting Analytics, yang menampilkan berapa banyak request yang diblokir dan aturan mana yang paling sering memicu.

Satu hal terakhir: jangan mematikan Cloudflare atau melewatinya (misalnya dengan mengarahkan DNS langsung ke origin) hanya untuk menghilangkan 429. Cara itu memang menghilangkan error, tetapi juga menghilangkan seluruh perlindungan — dan bila sumber banjirnya adalah bot, banjir itu akan langsung menghantam server Anda. Perbaiki aturannya; jangan buang perisainya.

10. Mengatasi 429 yang Disebabkan Plugin, WP-Cron, dan REST API

Bila log menunjukkan banjir request berasal dari dalam situs sendiri — dari plugin, tugas terjadwal, atau integrasi — perbaikannya ada di WordPress, dan metodenya adalah isolasi: cari pelakunya satu per satu.

Mulailah dari WP-Cron. WordPress menjalankan tugas terjadwal lewat request loopback ke wp-cron.php setiap kali ada kunjungan, dan plugin bisa menambahkan tugasnya sendiri ke jadwal ini. Bila satu tugas gagal dan dijadwalkan ulang tanpa henti, atau bila tugas berjalan terlalu sering, request loopback menumpuk dan bisa memicu pembatasan — baik dari hosting maupun dari aturan keamanan server yang memblokir loopback. Panduan loopback di developer.wordpress.org menyarankan isolasi plugin, pengujian dengan tema bawaan, dan melibatkan hosting bila aturan keamanan server memblokir loopback. Praktiknya: periksa daftar tugas terjadwal dengan plugin seperti WP Crontrol, cari tugas yang berjalan sangat sering atau yang selalu gagal, dan longgarkan jadwalnya atau matikan tugas yang tidak perlu. Sebagai patokan praktik, tugas yang berjalan setiap menit sebaiknya dipertanyakan — kebanyakan tugas pemeliharaan cukup berjalan setiap jam atau setiap hari. Bila traffic situs Anda tinggi, pertimbangkan mengganti WP-Cron semu dengan cron sungguhan di server yang berjalan pada jadwal tetap, sehingga tugas tidak lagi bergantung pada kunjungan pengunjung dan tidak menumpuk.

Lalu periksa plugin satu per satu. Metode yang paling dapat diandalkan adalah menonaktifkan semua plugin, memeriksa apakah 429 hilang, lalu mengaktifkan kembali satu per satu sambil memantau log. Lakukan ini di situs staging atau di jam sepi, dan buat cadangan dulu — jangan menonaktifkan plugin di situs live pada jam sibuk tanpa rencana. Perhatikan khususnya plugin impor dan sinkronisasi, plugin statistik dan analitik yang memanggil endpoint sendiri, plugin keamanan yang terlalu agresif memindai setiap request, serta plugin cache yang salah konfigurasi sehingga justru memicu regenerasi cache berulang. Bila satu plugin terbukti menjadi sumber banjir, periksa pengaturannya dulu: sering kali ada opsi interval polling atau batas percobaan yang bisa dilonggarkan. Bila tidak ada, cari alternatif atau hubungi pengembang plugin tersebut.

Periksa juga REST API dan admin-ajax.php. Editor blok WordPress memakai REST API untuk menyimpan dan memuat, dan banyak plugin menambahkan endpoint kustom di /wp-json/. Bila endpoint kustom dipanggil berulang kali oleh skrip tema — misalnya pencarian langsung (live search) yang mengirim request setiap kali pengguna mengetik satu huruf — banjir bisa terjadi dari pengunjung asli yang mengetik cepat. Perbaikannya ada di sisi skrip: tambahkan debounce, yaitu jeda singkat setelah pengguna berhenti mengetik sebelum request dikirim, sebagai patokan praktik sekitar beberapa ratus milidetik. Untuk admin-ajax.php, periksa plugin mana yang mendaftarkan aksi AJAX dan seberapa sering aksi itu dipanggil; alat Query Monitor bisa membantu melihat request AJAX beserta pemicunya.

Terakhir, periksa integrasi luar yang memanggil situs Anda. Layanan monitoring uptime, alat SEO yang merayapi situs, plugin backup yang menarik data lewat REST API, dan aplikasi pihak ketiga yang memakai application password — semuanya adalah sumber request yang sah tetapi bisa berlebihan. Tinjau interval dan frekuensi masing-masing, dan longgarkan yang terlalu agresif. Bila satu integrasi membutuhkan volume tinggi, beri ia kredensial khusus dengan peran rendah dan, bila memungkinkan, izinkan alamat IP-nya secara eksplisit di aturan rate limiting agar tidak tercampur dengan lalu lintas umum.

11. Error 429 dan Googlebot: Memakai 429 dengan Benar untuk SEO

Bagian ini membahas dua sisi yang berlawanan: 429 yang merugikan SEO Anda, dan 429 yang justru bisa Anda pakai sebagai alat darurat resmi dari Google.

Sisi pertama: 429 yang tidak disengaja dan merugikan. Bila aturan Cloudflare atau hosting Anda menjawab Googlebot dengan 429, Google akan membaca sinyal itu sebagai permintaan untuk melambat. Menurut panduan “Reduce the Google crawl rate” dari Google Search Central, bila crawler menemui sejumlah besar respons 500, 503, atau 429, Google menurunkan laju crawl untuk seluruh hostname — termasuk URL yang masih menjawab normal. Akibatnya, halaman baru lebih lambat ditemukan, perubahan harga atau konten lebih lama tampil di hasil pencarian, dan halaman yang dihapus lebih lama hilang dari indeks. Bila kondisi ini bertahan beberapa hari pada URL yang sama, URL tersebut dapat dihapus dari indeks. Karena itu, aturan rate limiting Anda tidak boleh menjawab Googlebot dengan 429. Periksa aturan Cloudflare dan WAF Anda: pastikan Googlebot tidak masuk dalam cakupan aturan yang ketat, dan verifikasi crawler Google dengan benar — Google mendokumentasikan cara memverifikasi crawler-nya lewat reverse DNS atau daftar alamat IP resmi, karena string user agent bisa dipalsukan oleh bot jahat yang menyamar sebagai Googlebot.

Sisi kedua: 429 sebagai rem darurat yang disengaja. Google secara eksplisit merekomendasikan cara ini bila server Anda sedang kritis — misalnya sedang kelebihan beban atau dalam pemadaman — dan crawl Google ikut memperparah keadaan. Caranya: untuk waktu singkat, beberapa jam sampai satu-dua hari, jawab request crawl Google dengan status 500, 503, atau 429, alih-alih 200. Dengan 503 atau 429, Anda bisa menambahkan header Retry-After untuk memberitahu kapan crawler boleh kembali — contoh dari Google: Retry-After: 120 atau tanggal HTTP seperti Retry-After: Wed, 21 Oct 2026 07:28:00 GMT. Setelah jumlah error berkurang, Google akan menaikkan lagi laju crawl secara otomatis. Penting untuk memahami batasnya: cara ini hanya untuk keadaan darurat singkat. Jangan mempertahankannya lebih dari satu-dua hari, jangan menerapkannya ke seluruh situs untuk pengguna manusia — hanya untuk crawler — dan hapus aturan itu segera setelah server pulih. Bila Anda tidak bisa menyajikan error ke crawler karena keterbatasan infrastruktur, Google menyediakan jalur permintaan khusus untuk melaporkan masalah laju crawl yang luar biasa tinggi, dengan menyebutkan laju optimal untuk situs Anda; permintaan ini dievaluasi dalam beberapa hari dan tidak bisa dipakai untuk meminta laju yang lebih tinggi.

Satu perubahan penting yang perlu diketahui: sejak Januari 2024, Google sudah tidak lagi menyediakan setelan manual untuk menurunkan laju crawl di Search Console. Alat lama itu dihapus karena sistem Googlebot kini bereaksi hampir seketika terhadap beban server — melambat sendiri begitu melihat error 5xx yang persisten atau respons yang melambat. Artinya, panduan lama yang menyuruh Anda mengatur crawl rate di Search Console sudah kedaluwarsa; cara yang berlaku sekarang adalah respons error darurat seperti dijelaskan di atas, atau permintaan khusus ke Google. Bila Anda membaca tutorial lama yang masih menyebut setelan crawl rate di Search Console, abaikan bagian itu.

Untuk memantau dampak 429 terhadap crawl, gunakan laporan Crawl Stats di Search Console. Perhatikan kolom host status dan grafik respons berdasarkan kode status: lonjakan 429 yang bertepatan dengan perubahan aturan adalah bukti langsung aturan Anda mengenai Googlebot. Setelah perbaikan, pantau sampai grafik kembali normal selama beberapa hari, dan periksa kembali halaman yang sempat terdampak di laporan Page Indexing untuk memastikan tidak ada yang terhapus dari indeks.

12. Checklist Pencegahan Jangka Panjang

Perbaikan 429 yang bertahan lama bukanlah satu tindakan, melainkan kebiasaan. Gunakan checklist berikut sebagai rutinitas berkala — misalnya sebulan sekali, atau setiap kali ada perubahan besar di situs.

• Pantau log secara berkala. Luangkan waktu memeriksa alamat IP dengan request terbanyak dan endpoint yang paling sering diakses. Bot baru muncul setiap saat; log adalah sistem peringatan dini Anda.
• Batasi hanya endpoint yang perlu. Terapkan rate limiting yang ketat ke wp-login.php dan xmlrpc.php, tetapi jangan menerapkan batas ketat ke seluruh situs. Satu tampilan halaman sudah berisi puluhan request.
• Jaga aturan Cloudflare tetap sempit. Setiap kali menambah aturan baru, periksa cakupannya: endpoint tertentu, bukan seluruh situs; kecualikan aset statis; periksa karakteristik penghitungan (IP, cookie, atau header).
• Perbarui dan rapikan plugin. Hapus plugin yang tidak dipakai, perbarui yang dipakai, dan uji plugin baru di staging sebelum masuk ke situs live. Plugin yang ditinggalkan adalah sumber loop yang paling umum.
• Rapikan jadwal cron. Tinjau tugas terjadwal secara berkala; longgarkan tugas yang berjalan terlalu sering dan pertimbangkan cron sungguhan di server untuk situs dengan traffic tinggi.
• Aktifkan 2FA untuk semua admin. Dengan 2FA, serangan brute force kehilangan nilainya dan Anda bisa lebih tenang mengatur batas login.
• Siapkan halaman error 429 yang informatif. Bila memungkinkan, sediakan halaman error kustom yang menjelaskan bahwa pengunjung terlalu cepat mengirim request dan diminta menunggu — bukan halaman kosong. Halaman yang jelas mengurangi kebingungan dan mengurangi refresh berulang.
• Dokumentasikan ambang Anda. Catat berapa batas yang Anda pakai di hosting, Cloudflare, dan plugin, beserta alasannya. Tanpa catatan, perubahan di masa depan akan kembali menjadi tebakan.
• Uji setelah setiap perubahan. Setelah mengubah aturan apa pun, uji dari beberapa jaringan dan periksa Search Console dalam beberapa hari berikutnya. Perubahan yang tidak diuji adalah sumber 429 berikutnya.

FAQ

Apakah error 429 berarti situs saya diblokir permanen?

Tidak. Error 429 bersifat sementara dan berbasis jendela waktu: setelah jendela berakhir, request Anda dilayani lagi. Yang permanen adalah pemblokiran IP oleh firewall atau plugin keamanan setelah pelanggaran berulang, dan itu biasanya ditandai dengan 403, bukan 429. Bila 429 muncul terus-menerus selama berhari-hari, penyebabnya hampir pasti aturan yang salah konfigurasi atau banjir request yang belum dihentikan — bukan blokir permanen.

Berapa lama error 429 hilang?

Tergantung jendela yang dipakai aturan tersebut. Bila respons menyertakan header Retry-After, angka itulah jawabannya: misalnya Retry-After: 60 berarti tunggu 60 detik. Bila tidak ada header, sebagai patokan praktik kebanyakan pembatasan berakhir dalam beberapa menit sampai satu jam setelah Anda berhenti mengirim request. Bila 429 bertahan lebih dari satu jam padahal Anda sudah berhenti, kemungkinan ada aturan lain yang memblokir IP Anda lebih lama, atau banjir dari jaringan Anda masih berlangsung — coba ganti jaringan untuk memastikan.

Apakah error 429 menurunkan ranking Google?

Tidak secara langsung sebagai faktor ranking, tetapi dampaknya nyata. Bila Googlebot menerima 429 dalam jumlah besar, Google menurunkan laju crawl untuk seluruh hostname, sehingga halaman baru lebih lambat diindeks dan perubahan lebih lama tampil. Bila error bertahan beberapa hari pada URL yang sama, URL tersebut dapat dihapus dari indeks. Jadi 429 tidak menurunkan ranking halaman yang sudah terindeks secara instan, tetapi merusak proses crawl dan indexing yang menjadi fondasi visibilitas Anda.

Mengapa saya kena 429 padahal baru membuka situs sekali?

Kemungkinan besar Anda berbagi alamat IP dengan orang lain. VPN, jaringan kantor, kampus, Wi-Fi publik, dan operator seluler yang memakai CGNAT menempatkan banyak pengguna di satu alamat IP publik yang sama. Bila salah satu pengguna di IP itu agresif — atau sedang diserang bot — seluruh pengguna IP itu ikut terhitung. Coba buka situs dari jaringan lain; bila error hilang, masalahnya ada di alamat IP lama Anda, bukan di situs.

Apakah mematikan Cloudflare memperbaiki error 429?

Mungkin menghilangkan gejalanya, tetapi itu bukan perbaikan. Bila 429 berasal dari aturan Cloudflare, mematikan Cloudflare memang menghentikan error itu — tetapi juga menghilangkan seluruh perlindungan, dan banjir request yang tadinya ditahan di edge akan langsung menghantam server Anda. Perbaiki aturannya: persempit cakupan ke endpoint tertentu, kecualikan aset statis, dan periksa karakteristik penghitungannya. Hanya matikan aturan tertentu setelah Anda tahu aturan mana yang memicu dan mengapa.

Kapan saya harus menghubungi hosting?

Hubungi hosting bila diagnosis Anda mengarah ke batas server: 429 muncul di semua halaman saat traffic naik, hilang saat traffic turun, tidak terkait endpoint tertentu, dan tidak ada header cf-ray yang menunjukkan CDN. Sertakan data saat menghubungi: kapan mulai muncul, endpoint yang terdampak, alamat IP Anda, dan tangkapan layar header respons bila ada. Tanyakan apakah ada batas request per menit atau batas proses PHP pada paket Anda dan berapa ambangnya. Bila batas memang terlampaui oleh traffic yang sah, diskusikan caching yang lebih baik atau naik paket — bukan sekadar meminta batas dinaikkan tanpa rencana.

Kesimpulan

Error 429 Too Many Requests adalah server yang meminta Anda melambat, bukan server yang rusak. Definisi resminya dalam RFC 6585 jelas: terlalu banyak permintaan dalam jangka waktu tertentu. Header Retry-After dalam RFC 9110 memberi tahu berapa lama menunggu. Google Search Central mendokumentasikan bahwa 429 yang dibiarkan berhari-hari dapat menurunkan laju crawl dan menghapus URL dari indeks, sehingga error ini tidak boleh dibiarkan. Cloudflare mendokumentasikan bahwa Error 1015 berasal dari aturan yang Anda buat sendiri, sehingga perbaikannya ada di dasbor Anda.

Untuk publisher WordPress, urutan kerja yang benar adalah: baca header dan kenali lapisan yang menjawab, tentukan pola siapa dan di mana, periksa log untuk menemukan pelakunya, lalu perbaiki di lapisan itu — amankan login dan tutup xmlrpc yang tidak dipakai, persempit aturan Cloudflare, rapikan plugin dan jadwal cron, dan hanya hubungi hosting bila bukti mengarah ke batas server. Jangan mematikan perlindungan, jangan menaikkan batas tanpa bukti, dan jangan me-refresh berulang saat menjadi pengunjung. Dengan diagnosis yang tepat, sebagian besar kasus 429 selesai dalam satu sesi perbaikan — dan dengan checklist berkala di bagian 12, kasus berikutnya bisa dicegah sebelum pengunjung Anda sempat merasakannya.

Sumber resmi yang dirujuk

1. RFC 6585, Section 4 — “429 Too Many Requests”: definisi kode status 429, anjuran menyertakan header Retry-After, dan larangan menyimpan respons 429 di cache. https://www.rfc-editor.org/rfc/rfc6585#section-4
2. RFC 9110, Section 10.2.3 — “Retry-After”: dua bentuk nilai header Retry-After (detik dan tanggal HTTP). https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3
3. MDN Web Docs — “429 Too Many Requests”: penjelasan kode status dan contoh respons dengan Retry-After: 3600. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429
4. Google Search Central — “Reduce the Google crawl rate” (ditulis ulang 6 Oktober 2026): penggunaan 500/503/429 sebagai rem darurat crawl, penurunan laju crawl seluruh hostname, contoh Retry-After, dan peringatan tidak lebih dari 1–2 hari agar URL tidak dihapus dari indeks. https://developers.google.com/search/docs/crawling-indexing/reduce-crawl-rate
5. Cloudflare Docs — “Error 429”: definisi 429 menurut Cloudflare, batas API Cloudflare, dan penjelasan bahwa 429 untuk pengunjung situs berasal dari aturan rate limiting. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-429/
6. WordPress.org — “Hardening WordPress”: panduan resmi keamanan WordPress, termasuk pembatasan percobaan login dan penanganan xmlrpc.php. https://wordpress.org/documentation/article/hardening-wordpress/
7. WordPress Developer Resources — panduan loopback: rekomendasi isolasi plugin, pengujian tema bawaan, dan keterlibatan hosting bila aturan keamanan server memblokir loopback. https://developer.wordpress.org/
8. Google Search Central Blog — penghapusan setelan crawl rate limiter di Search Console (Januari 2024) dan peralihan ke reaksi otomatis Googlebot terhadap beban server. https://developers.google.com/search/blog