Mengatasi Error 400 Bad Request di WordPress: Penyebab, Diagnosis, dan Cara Memperbaikinya untuk Publisher Indonesia

Error 400 Bad Request di WordPress adalah pesan bahwa server menolak memproses permintaan dari browser karena permintaan itu sendiri dianggap salah — misalnya alamat URL yang cacat, cookie yang rusak atau terlalu besar, atau aturan penulisan ulang di file .htaccess yang keliru. Berbeda dengan error 404 yang berarti halaman tidak ditemukan, error 400 berarti halamannya mungkin ada, tetapi cara browser memintanya tidak bisa dipahami server. Kabar baiknya, sebagian besar kasus 400 bisa diperbaiki tanpa menyentuh kode: mulai dari membersihkan cookie dan memeriksa URL, lalu berlanjut ke permalink, .htaccess, plugin, dan batas header server. Artikel ini menjelaskan definisi resminya, dampaknya bagi publisher, cara mendiagnosis dari polanya, tujuh penyebab paling umum beserta perbaikan masing-masing, urutan perbaikan lengkap, dan cara mencegahnya kambuh.

Poin Kunci

• Error 400 berarti server tidak dapat atau tidak mau memproses permintaan karena dianggap ada kesalahan di sisi klien, menurut RFC 9110 bagian 15.5.1 — misalnya sintaks permintaan cacat, framing pesan tidak valid, atau routing yang menipu.
• Error 400 berbeda dari 404 (halaman tidak ada), 401 (belum login), 403 (dilarang), 413 (badan permintaan terlalu besar), 414 (URL terlalu panjang), dan 431 (header terlalu besar).
• Google tidak mengindeks URL yang mengembalikan kode 4xx, dan URL yang sudah terindeks lalu mengembalikan 400 akan dihapus dari indeks seiring waktu — jadi error 400 pada halaman artikel adalah masalah SEO, bukan sekadar gangguan tampilan.
• Penyebab paling umum di WordPress: cookie atau cache browser yang rusak, URL atau query string yang salah, file .htaccess rusak, struktur permalink bermasalah, konflik plugin atau aturan keamanan, upload melebihi batas, dan parameter REST API yang tidak valid.
• Urutan perbaikan yang aman: mulai dari sisi browser (URL, cookie, mode privat), lalu sisi WordPress (permalink, plugin, tema), dan terakhir sisi server (.htaccess, batas header) — selalu dengan cadangan sebelum mengedit file server.
• Batas header bawaan server cukup kecil: Apache membatasi satu field header hingga 8.190 byte, sedangkan nginx memakai buffer awal 1 KB dan buffer besar 4 x 8 KB — cookie yang menumpuk mudah melewati batas ini.
• REST API WordPress mengembalikan 400 dengan kode rest_invalid_param bila parameter tidak valid, misalnya per_page di luar rentang 1 sampai 100.

Daftar Isi

1. Apa Itu Error 400 Bad Request (dan Bukan Apa)
2. Mengapa Error 400 Berbahaya bagi Publisher Indonesia
3. Cara Mendiagnosis: Baca Polanya Sebelum Memperbaiki
4. Penyebab 1: URL atau Query String yang Salah
5. Penyebab 2: Cookie dan Cache Browser yang Rusak atau Terlalu Besar
6. Penyebab 3: File .htaccess Rusak
7. Penyebab 4: Struktur Permalink Rusak
8. Penyebab 5: Plugin, Tema, atau Aturan Keamanan yang Memblokir Request
9. Penyebab 6: Upload File Melebihi Batas Server
10. Penyebab 7: REST API dan Parameter Tidak Valid
11. Urutan Perbaikan Lengkap Langkah demi Langkah
12. Cara Mencegah Error 400 Kambuh
13. Kapan Harus Menghubungi Hosting
14. FAQ
15. Kesimpulan
16. Sumber Resmi yang Dirujuk

Apa Itu Error 400 Bad Request (dan Bukan Apa)

Error 400 Bad Request adalah kode status HTTP dari keluarga 4xx, yaitu keluarga kode untuk kesalahan yang dianggap berasal dari sisi klien. Definisi resminya ada di RFC 9110 bagian 15.5.1, spesifikasi HTTP Semantics yang diterbitkan IETF pada Juni 2022 dan menggantikan RFC 7231. Bunyinya: kode status 400 menunjukkan server tidak dapat atau tidak mau memproses permintaan karena sesuatu yang dianggap sebagai kesalahan klien, misalnya sintaks permintaan yang cacat, framing pesan permintaan yang tidak valid, atau routing permintaan yang menipu.

Terjemahan praktisnya sederhana: browser mengirim sebuah permintaan, server membacanya, lalu memutuskan bahwa permintaan itu tidak berbentuk sebagaimana mestinya, sehingga server menolaknya sebelum melakukan apa pun. Halaman tidak diproses, formulir tidak dikirim, dan aksi di wp-admin tidak dijalankan. Server tidak mengatakan halamannya hilang atau aksesnya dilarang — server mengatakan permintaannya sendiri bermasalah.

Penting untuk membedakan 400 dari kode lain yang sering tertukar dengannya, karena salah membaca kode berarti salah memperbaiki. Tabel berikut merangkum perbedaannya menurut definisi resmi masing-masing.

Perbedaan antara 400, 413, 414, dan 431 layak dicatat karena dalam praktik WordPress keempatnya saling beririsan. Server lama dan sebagian konfigurasi shared hosting masih mengembalikan 400 untuk header yang terlalu besar, padahal kode yang lebih tepat adalah 431. Begitu pula upload yang terlalu besar kadang tampil sebagai 400 pada beberapa konfigurasi, padahal kode yang lebih tepat adalah 413. Karena itu, saat mendiagnosis, jangan hanya membaca angka 400 — baca juga teks yang menyertainya. Pesan seperti “Request Header Or Cookie Too Large” atau “Size of a request header field exceeds server limit” adalah petunjuk yang jauh lebih berharga daripada angka itu sendiri.

Ada pula variasi pesan 400 yang mungkin Anda temui. Variasinya antara lain “400 Bad Request” polos tanpa penjelasan, “400 Bad Request – Invalid URL”, “400 Bad Request – Request Header or Cookie Too Large”, dan pada beberapa server “400 Bad Request: The request could not be understood by the server due to malformed syntax”. Semuanya berakar pada definisi yang sama, tetapi masing-masing menunjuk ke penyebab yang berbeda. Pesan “Invalid URL” mengarah ke alamat yang salah ketik atau query string yang rusak. Pesan “Request Header or Cookie Too Large” mengarah ke cookie yang menumpuk. Pesan polos tanpa penjelasan menuntut diagnosis dari polanya: di mana error itu muncul, kapan muncul, dan pada aksi apa.

Satu hal lagi yang perlu dipahami sejak awal: error 400 hampir selalu menunjuk ke satu permintaan tertentu, bukan ke seluruh situs. Situs Anda biasanya tetap bisa dibuka di halaman lain, dan pengunjung lain mungkin tidak mengalami apa-apa. Inilah yang membedakannya dari error 500 atau white screen yang melumpuhkan seluruh situs. Jika error 400 hanya muncul pada satu halaman, penyebabnya hampir pasti ada pada URL atau tautan menuju halaman itu. Jika hanya muncul saat Anda login ke wp-admin, penyebabnya hampir pasti ada pada cookie, sesi, atau plugin. Jika muncul saat menyimpan artikel atau mengunggah gambar, penyebabnya hampir pasti ada pada ukuran permintaan atau aturan keamanan. Pola inilah yang akan dipakai sebagai kompas diagnosis pada bagian ketiga artikel ini.

Mengapa Error 400 Berbahaya bagi Publisher Indonesia

Bagi publisher, error 400 bukan sekadar pesan yang mengganggu. Ia punya tiga dampak nyata: terhadap SEO, terhadap pendapatan iklan, dan terhadap kepercayaan pembaca.

Dampak pertama adalah SEO. Google menjelaskan dalam dokumen resminya “How HTTP status codes affect Google’s crawlers” bahwa Google tidak menggunakan konten dari URL yang mengembalikan kode 4xx. URL yang mengembalikan 400 tidak diindeks, dan URL yang sebelumnya sudah terindeks lalu mulai mengembalikan 400 akan dihapus dari indeks seiring waktu, sementara frekuensi crawl ke URL itu berangsur menurun. Dokumen yang sama, terakhir diperbarui 4 Februari 2026, menegaskan bahwa semua kode 4xx kecuali 429 diperlakukan sama: crawler Google memberi tahu sistem pemrosesan berikutnya bahwa konten itu tidak ada. Artinya, satu artikel yang mendadak mengembalikan 400 sama saja dengan artikel yang hilang dari Google — pelan-pelan, tetapi pasti. Jika error 400 terjadi pada halaman beranda atau halaman kategori karena .htaccess yang rusak, kerusakannya lebih luas lagi: bukan satu artikel, melainkan seluruh bagian situs yang terdampak.

Dampak kedua adalah pendapatan iklan. Iklan AdSense hanya tampil pada halaman yang berhasil dimuat dengan status 200. Halaman yang mengembalikan 400 tidak menampilkan konten, sehingga tidak ada ruang iklan yang terisi dan tidak ada tayangan yang tercatat. Lebih dari itu, error 400 yang muncul saat Anda menyimpan artikel atau mengunggah gambar di editor WordPress dapat menggagalkan alur kerja redaksi: draf tidak tersimpan, gambar gagal diunggah, dan jadwal terbit terganggu. Untuk publisher yang menerbitkan setiap jam, gangguan kecil yang berulang seperti ini menumpuk menjadi kehilangan yang nyata.

Dampak ketiga adalah kepercayaan pembaca dan mitra. Pembaca yang mengklik tautan dari media sosial atau hasil pencarian lalu disambut pesan “400 Bad Request” jarang mencoba kedua kali. Mereka menutup tab dan beralih ke situs lain. Jika tautan yang rusak itu dibagikan di grup WhatsApp atau Facebook, kerusakannya berlipat: setiap orang yang mengklik mendapat pengalaman yang sama. Bagi publisher kecil yang sedang membangun reputasi, kesan pertama yang rusak seperti ini sulit diperbaiki.

Ada satu nuansa yang perlu dijaga agar tidak panik berlebihan. Error 400 yang hanya muncul di browser Anda sendiri — misalnya karena cookie lama di laptop Anda — tidak memengaruhi Google maupun pembaca lain. Googlebot mengirim permintaan yang bersih, tanpa cookie lama Anda. Karena itu, sebelum menyimpulkan situs Anda bermasalah, selalu uji dari mode privat atau perangkat lain. Jika halaman terbuka normal dari mode privat, masalahnya ada di browser Anda, bukan di situs Anda. Bagian diagnosis di bawah akan memandu pengujian ini secara sistematis.

Cara Mendiagnosis: Baca Polanya Sebelum Memperbaiki

Prinsip diagnosis error 400 adalah: jangan mulai dengan mengedit file server. Mulailah dengan mencatat pola, karena pola mempersempit kemungkinan penyebab dari puluhan menjadi satu atau dua. Sebelum menyentuh apa pun, catat tujuh hal ini: URL persis yang memunculkan error, teks pesan error selengkapnya, aksi yang sedang dilakukan saat error muncul, waktu kemunculannya, browser dan perangkat yang dipakai, jaringan yang dipakai, dan perubahan terakhir pada situs (plugin baru, perubahan permalink, migrasi, atau update tema).

Setelah itu, jalankan empat pengujian cepat berikut. Pengujian ini tidak memperbaiki apa pun, tetapi memberi jawaban yang menentukan langkah selanjutnya.

Pertama, uji dari mode privat atau incognito. Buka URL yang sama di jendela privat. Jika halaman terbuka normal, penyebabnya hampir pasti cookie atau cache di browser utama Anda. Mode privat tidak mengirim cookie lama dan tidak memakai cache lama, sehingga hasil ini menjadi bukti yang kuat.

Kedua, uji dari browser dan perangkat lain. Buka URL yang sama dari browser berbeda atau dari ponsel. Jika error hanya muncul di satu browser, penyebabnya ada di browser itu — ekstensi, cookie, atau cache. Jika error muncul di semua browser dan perangkat, penyebabnya ada di sisi server atau situs, bukan di perangkat Anda.

Ketiga, uji URL yang bersih. Hapus semua yang ada setelah tanda tanya (?) pada URL, lalu muat ulang. Query string yang panjang, parameter pelacakan yang rusak, atau karakter yang salah encode sering menjadi penyebab 400. Jika URL bersih terbuka normal, penyebabnya ada pada query string, bukan pada halamannya.

Keempat, uji halaman lain di situs yang sama. Jika hanya satu halaman yang error, penyebabnya ada pada URL, permalink, atau tautan menuju halaman itu. Jika semua halaman error, penyebabnya ada pada .htaccess, konfigurasi server, atau sesuatu yang memengaruhi seluruh situs. Jika hanya wp-admin yang error tetapi halaman publik normal, penyebabnya ada pada cookie sesi, plugin keamanan, atau aturan yang hanya berlaku untuk area admin.

Tabel berikut merangkum cara membaca hasil pengujian tersebut.

Satu alat lagi yang sangat membantu adalah tab Network pada DevTools browser. Tekan F12, buka tab Network, lalu muat ulang halaman yang error. Klik baris permintaan yang berstatus 400, lalu lihat bagian Headers dan Response. Di sana Anda bisa melihat ukuran header Cookie, URL persis yang dikirim, dan kadang pesan penjelasan dari server. Jika ukuran header Cookie mencapai ribuan byte, Anda sudah menemukan tersangkanya. Jika URL yang dikirim mengandung karakter aneh seperti % yang tidak diikuti dua digit heksadesimal, Anda juga sudah menemukan tersangkanya. Diagnosis yang baik membuat perbaikan menjadi singkat; perbaikan tanpa diagnosis membuat Anda menebak-nebak.

Penyebab 1: URL atau Query String yang Salah

Penyebab paling sederhana dari error 400 adalah URL yang tidak terbentuk dengan benar. Server menerima alamat yang tidak bisa ditafsirkan, lalu menolaknya. Penyebabnya bisa sesederhana satu karakter yang salah.

Karakter yang tidak di-encode dengan benar adalah pemicu yang paling sering. URL hanya boleh mengandung karakter tertentu; karakter lain harus diubah menjadi bentuk persen-encoding, misalnya spasi menjadi %20. Jika URL mengandung karakter seperti kurung kurawal { }, kurung siku, spasi mentah, atau tanda persen % yang tidak diikuti dua digit heksadesimal, server dapat menolak permintaan itu sebagai malformed. Dokumentasi Cloudflare tentang error 400 menegaskan hal ini: permintaan yang mengandung karakter khusus yang tidak di-encode dengan benar akan dikembalikan sebagai HTTP Error 400.

Query string yang rusak adalah pemicu kedua. Tautan yang disalin dari email, dokumen, atau pesan chat kadang ikut menyertakan karakter tambahan, atau terpotong di tengah. Parameter pelacakan seperti ?utm_source= yang nilainya mengandung karakter aneh, atau URL dengan dua tanda tanya ??, atau parameter yang sama ditulis dua kali dengan nilai yang bertentangan, semuanya bisa memicu 400 pada server yang ketat. Demikian pula URL yang terlalu panjang: server memiliki batas panjang baris permintaan, dan URL yang melewatinya ditolak — pada sebagian server dengan 400, pada sebagian lain dengan 414.

Perbaikannya berurutan dan murah. Pertama, periksa URL di address bar secara visual: cari spasi, karakter aneh, tanda persen yang menggantung, atau tanda tanya ganda. Kedua, hapus seluruh query string — semua yang ada setelah tanda ? — lalu muat ulang. Jika halaman terbuka, masalahnya ada pada query string, dan Anda tidak perlu menyentuh situs sama sekali. Ketiga, jika URL berasal dari tautan di situs lain, periksa tautan sumbernya: mungkin tautan itu memang salah ketik sejak awal, dan yang perlu diperbaiki adalah tautannya, bukan situs Anda. Keempat, jika URL dibuat oleh plugin — misalnya plugin berbagi sosial atau pelacak afiliasi yang menambahkan parameter otomatis — nonaktifkan sementara plugin itu dan uji lagi.

Sebagai publisher, periksa juga tautan internal Anda sendiri. Tautan yang dibuat dengan menyalin URL dari address bar saat sedang login kadang ikut menyertakan parameter admin atau nonce yang sudah kedaluwarsa. Tautan seperti itu bekerja saat Anda yang mengkliknya dalam sesi yang sama, tetapi mengembalikan 400 bagi pembaca lain atau bagi Googlebot. Kebiasaan yang aman: selalu salin URL dari halaman publik dalam mode logout, bukan dari dalam editor atau wp-admin.

Penyebab 2: Cookie dan Cache Browser yang Rusak atau Terlalu Besar

Jika error 400 hanya muncul saat Anda login ke wp-admin atau hanya di satu browser, penyebab yang paling mungkin adalah cookie. WordPress sangat bergantung pada cookie: sesi login, nonce keamanan, preferensi editor, dan data plugin semuanya disimpan sebagai cookie. Jika cookie itu rusak, kedaluwarsa, atau menumpuk hingga melewati batas server, server menolak permintaan sebelum WordPress sempat memprosesnya.

Ada tiga cara cookie menyebabkan 400. Pertama, cookie yang korup atau kedaluwarsa. Cookie sesi login yang tidak lagi cocok dengan sesi di server membuat WordPress mengirim permintaan yang ditolak, terutama pada aksi yang membutuhkan nonce — misalnya menyimpan artikel, mengunggah media, atau mengubah pengaturan. Gejalanya khas: Anda masih bisa melihat halaman publik, tetapi setiap aksi di wp-admin gagal dengan 400.

Kedua, cookie yang terlalu banyak atau terlalu besar. Setiap cookie yang tersimpan untuk sebuah domain dikirim ulang pada setiap permintaan ke domain itu. Situs yang memakai banyak plugin pelacak, alat analitik, obrolan langsung, dan layanan pihak ketiga dapat menumpuk puluhan cookie. Masing-masing cookie memang kecil, tetapi jumlahnya bertambah. RFC 6265, spesifikasi cookie HTTP, menyatakan bahwa agen pengguna seharusnya mendukung setidaknya 4.096 byte per cookie — tetapi batas itu adalah batas per cookie, bukan batas total header. Total header Cookie yang dikirim browser bisa mencapai belasan kilobyte, dan di situlah server menolaknya.

Ketiga, batas header server yang memang kecil. Apache HTTP Server membatasi ukuran satu field header melalui direktif LimitRequestFieldSize, yang nilai bawaannya adalah 8.190 byte. Jika satu field header — biasanya field Cookie — melewati batas itu, Apache langsung mengembalikan 400 Bad Request. Dokumentasi Apache menjelaskan bahwa batas ini ada untuk mengurangi risiko serangan denial-of-service, dan direktif ini dapat dipasang di konfigurasi server atau di dalam blok VirtualHost. Sementara itu nginx memakai pendekatan buffer: client_header_buffer_size bawaan 1 KB untuk buffer awal, dan large_client_header_buffers bawaan 4 buffer berukuran 8 KB. Jika satu header tidak muat dalam buffer-buffer itu, nginx mengembalikan 400 dengan pesan “Request Header Or Cookie Too Large”. Tabel berikut merangkum batas-batas ini agar mudah dibandingkan.

Perbaikan dari sisi browser bersifat segera dan aman. Pertama, hapus cookie khusus untuk domain situs Anda saja — tidak perlu menghapus seluruh riwayat browsing. Di Chrome, caranya melalui Settings, lalu Privacy and Security, lalu Cookies and other site data, lalu See all site data, lalu cari domain Anda dan hapus. Di Firefox, caranya melalui Settings, lalu Privacy & Security, lalu Cookies and Site Data, lalu Manage Data. Setelah cookie domain dihapus, login kembali ke wp-admin. Pada sebagian besar kasus, langkah ini saja sudah menyelesaikan masalah.

Kedua, hapus cache browser untuk situs itu, atau lakukan hard refresh dengan Ctrl+Shift+R (Windows/Linux) atau Cmd+Shift+R (Mac). Cache yang menyimpan salinan lama halaman admin atau file JavaScript editor dapat mengirim permintaan yang tidak lagi cocok dengan kondisi server saat ini.

Ketiga, uji dengan menonaktifkan ekstensi browser. Ekstensi pemblokir iklan, VPN, atau pengelola kata sandi kadang menambahkan header atau mengubah cookie dengan cara yang memicu 400. Jika error hilang setelah ekstensi dimatikan, aktifkan kembali satu per satu untuk menemukan pelakunya.

Jika masalahnya adalah batas header server, perbaikannya ada di sisi server dan memerlukan akses konfigurasi — sesuatu yang biasanya hanya bisa dilakukan oleh hosting atau pemilik VPS. Menaikkan LimitRequestFieldSize di Apache menjadi 16.384 byte, atau menaikkan large_client_header_buffers di nginx menjadi 4 16k, adalah perbaikan yang umum. Namun perlu dicatat: menaikkan batas ini sedikit meningkatkan risiko serangan denial-of-service, karena header yang lebih besar mengonsumsi lebih banyak memori server. Karena itu, naikkan seperlunya saja, dan utamakan memperbaiki akar masalahnya — yaitu mengurangi jumlah dan ukuran cookie yang dipasang situs Anda. Tinjau plugin yang memasang cookie: apakah semuanya masih diperlukan? Apakah cookie pelacak pihak ketiga benar-benar memberi nilai? Mengurangi cookie adalah perbaikan permanen; menaikkan batas adalah perbaikan sementara.

Satu catatan khusus untuk pengguna Cloudflare atau CDN lain: lapisan CDN dapat menambahkan headernya sendiri sebelum meneruskan permintaan ke server asal. Jika server asal Anda memakai batas yang ketat, header tambahan dari CDN dapat mendorong total melewati batas. Dalam kasus seperti ini, membersihkan cookie tetap menjadi langkah pertama, dan jika tidak berhasil, mintalah hosting memeriksa log error server untuk melihat field header mana yang melewati batas.

Penyebab 3: File .htaccess Rusak

File .htaccess adalah file konfigurasi Apache yang mengendalikan penulisan ulang URL, pengalihan, dan berbagai aturan server untuk situs WordPress Anda. Satu baris yang salah di file ini dapat membuat seluruh situs — atau bagian tertentu — mengembalikan 400. File ini rentan rusak karena banyak pihak menulis ke dalamnya: WordPress sendiri saat Anda menyimpan pengaturan permalink, plugin keamanan, plugin cache, plugin pengalihan, dan Anda sendiri saat mengedit manual.

Kerusakan yang paling umum adalah aturan penulisan ulang yang bertentangan. Misalnya, plugin keamanan menambahkan aturan yang memblokir pola URL tertentu, sementara plugin lain menambahkan aturan yang menulis ulang pola yang sama. Hasilnya adalah permintaan yang ditulis ulang menjadi bentuk yang tidak valid, lalu ditolak server dengan 400. Kerusakan lain adalah karakter yang tidak sengaja masuk saat mengedit — satu karakter yang hilang atau tertukar dapat membuat seluruh blok aturan tidak terbaca. Kerusakan ketiga adalah aturan lama yang tertinggal dari plugin yang sudah dihapus: aturannya masih aktif, tetapi merujuk ke file atau direktori yang sudah tidak ada.

Cara mendiagnosisnya relatif mudah, tetapi cara memperbaikinya menuntut kehati-hatian. Sebelum menyentuh apa pun, unduh salinan .htaccess yang ada sekarang sebagai cadangan. File ini terletak di direktori root instalasi WordPress Anda, di samping wp-config.php. Perhatikan bahwa namanya diawali titik, sehingga sebagian pengelola file menyembunyikannya secara bawaan — aktifkan opsi “tampilkan file tersembunyi” di File Manager hosting Anda.

Setelah cadangan diamankan, ganti isi .htaccess dengan aturan bawaan WordPress saja, lalu uji situs Anda. Aturan bawaan WordPress untuk permalink adalah sebagai berikut:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Jika error 400 hilang setelah penggantian ini, penyebabnya sudah pasti ada pada aturan lama di .htaccess. Kembalikan aturan tambahan sedikit demi sedikit — satu blok setiap kali — sambil menguji situs, hingga Anda menemukan blok yang memicu error. Blok itulah yang perlu diperbaiki atau dihapus. Jika error tetap ada meski .htaccess sudah berisi aturan bawaan saja, penyebabnya bukan di file ini; kembalikan file cadangan Anda dan lanjutkan ke penyebab berikutnya.

Tiga aturan kerja yang wajib dipegang saat mengedit .htaccess. Pertama, jangan pernah mengedit tanpa cadangan — file ini dieksekusi oleh server pada setiap permintaan, sehingga kesalahan kecil berdampak instan ke seluruh situs. Kedua, jangan menempelkan potongan aturan dari internet tanpa memahami apa yang dilakukannya; banyak potongan yang beredar ditulis untuk konfigurasi server yang berbeda. Ketiga, jika situs Anda berjalan di nginx, bukan Apache, file .htaccess tidak berlaku sama sekali — aturan penulisan ulang ada di konfigurasi nginx, dan mengedit .htaccess tidak akan berpengaruh apa pun. Dalam hal ini, mintalah hosting memeriksa konfigurasi nginx Anda.

Penyebab 4: Struktur Permalink Rusak

Permalink adalah struktur URL permanen artikel Anda, misalnya namadomain.com/judul-artikel/. WordPress menyimpannya sebagai aturan penulisan ulang, dan jika aturan itu rusak atau tidak sinkron dengan .htaccess, permintaan ke artikel dapat ditolak sebagai 400 — terutama bila URL mengandung karakter yang tidak lagi cocok dengan pola aturan.

Permalink rusak biasanya muncul setelah salah satu dari empat peristiwa: perubahan struktur permalink di Pengaturan, migrasi situs ke domain atau server baru, pemulihan dari cadangan, atau update plugin yang menulis ulang aturan permalink. Gejalanya khas: halaman beranda masih terbuka, tetapi artikel dan halaman tertentu mengembalikan 400, atau sebaliknya — artikel lama terbuka tetapi artikel baru yang diterbitkan setelah perubahan gagal dimuat.

Perbaikannya adalah yang paling mudah di antara semua penyebab pada sisi server. Masuk ke wp-admin, buka Pengaturan, lalu Permalink. Tanpa mengubah apa pun, klik tombol Simpan Perubahan. Tindakan ini memaksa WordPress menulis ulang aturan permalink ke .htaccess (pada server Apache) dan menyegarkan aturan internalnya. Uji kembali artikel yang error. Pada banyak kasus, langkah ini saja sudah cukup.

Jika menyimpan ulang permalink tidak menyelesaikan masalah, periksa dua hal. Pertama, pastikan struktur permalink tidak mengandung karakter yang bermasalah, seperti spasi atau karakter khusus pada awalan kustom. Struktur “Nama kiriman” (/%postname%/) adalah pilihan yang paling aman dan paling umum untuk publisher. Kedua, periksa apakah ada plugin yang memodifikasi permalink secara otomatis — misalnya plugin yang menambahkan awalan kategori atau tanggal ke URL. Nonaktifkan sementara plugin semacam itu dan uji lagi.

Catatan penting untuk publisher: jangan mengubah struktur permalink situs yang sudah berjalan hanya karena error 400. Mengubah struktur permalink mengubah seluruh URL artikel Anda, dan setiap URL lama yang sudah terindeks Google atau dibagikan di media sosial akan rusak kecuali Anda memasang pengalihan 301 untuk semuanya. Jika permalink lama masih baik, perbaiki aturan yang rusak, jangan ganti strukturnya.

Penyebab 5: Plugin, Tema, atau Aturan Keamanan yang Memblokir Request

Ketika browser dan URL sudah bersih tetapi error 400 tetap muncul, tersangka berikutnya adalah sesuatu di dalam WordPress yang mengubah atau menolak permintaan sebelum sempat diproses: plugin, tema, atau aturan keamanan.

Plugin keamanan dan firewall adalah penyebab yang paling sering di kelompok ini. Plugin seperti Wordfence, Sucuri, atau All In One WP Security memasang aturan yang memeriksa setiap permintaan masuk. Jika sebuah permintaan cocok dengan pola yang dianggap mencurigakan — misalnya query string yang mengandung kata kunci tertentu, atau header yang tidak biasa — plugin dapat menolaknya. Pada sebagian konfigurasi, penolakan ini tampil sebagai 400, bukan 403. Demikian pula ModSecurity, firewall aplikasi web di tingkat server yang dipakai banyak hosting, dapat menolak permintaan yang melanggar aturannya dengan kode 400. Gejalanya khas: error muncul pada aksi tertentu saja, misalnya menyimpan artikel yang mengandung potongan kode atau karakter khusus di dalam isinya, sementara halaman lain normal-normal saja.

Plugin cache dan optimasi juga bisa menjadi penyebab. Plugin cache yang menyimpan salinan lama respons server dapat menyajikan ulang respons 400 yang sebenarnya sudah tidak relevan. Plugin optimasi yang menggabungkan atau meminifikasi file JavaScript dan CSS kadang menghasilkan permintaan ke file gabungan dengan URL yang sangat panjang, sehingga server menolaknya. Plugin pengalihan (redirect) yang konfigurasinya saling bertentangan dapat menulis ulang URL menjadi bentuk yang tidak valid.

Tema yang rusak atau tidak kompatibel lebih jarang menjadi penyebab, tetapi mungkin terjadi: tema yang memanggil endpoint admin-ajax dengan parameter yang salah, atau tema yang menambahkan skrip yang mengirim permintaan cacat setiap kali halaman dimuat.

Cara mendiagnosisnya adalah dengan menonaktifkan plugin secara sistematis. Jika Anda masih bisa masuk ke wp-admin, nonaktifkan semua plugin, lalu uji halaman yang error. Jika error hilang, aktifkan kembali plugin satu per satu sambil menguji, hingga pelakunya ketemu. Jika Anda tidak bisa masuk ke wp-admin karena error 400, nonaktifkan plugin melalui File Manager atau FTP: buka direktori wp-content/plugins, lalu ubah nama folder plugin yang dicurigai — misalnya dari wordfence menjadi wordfence-off. WordPress akan menganggap plugin itu tidak ada. Kembalikan nama foldernya setelah pengujian selesai, kecuali plugin itu terbukti menjadi penyebab.

Untuk aturan keamanan server seperti ModSecurity, Anda tidak bisa memperbaikinya sendiri dari wp-admin. Periksa log error di panel hosting Anda, atau mintalah tim hosting memeriksa log ModSecurity pada waktu error terjadi. Log itu mencatat aturan mana yang memicu penolakan, dan hosting dapat menonaktifkan aturan spesifik yang terlalu agresif tanpa mematikan perlindungan secara keseluruhan. Jangan meminta hosting mematikan ModSecurity sepenuhnya — itu seperti melepas pintu karena kuncinya macet.

Satu pola yang patut dikenali: error 400 yang hanya muncul saat menyimpan artikel dengan isi tertentu — misalnya artikel yang mengandung potongan kode HTML, shortcode, atau karakter seperti <script> — hampir selalu disebabkan aturan keamanan yang menganggap isi itu sebagai serangan injeksi. Solusinya bukan menghapus isi artikel, melainkan menyesuaikan aturan keamanannya, atau menyimpan artikel dalam beberapa tahap. Jika Anda sering menulis artikel teknis yang mengandung kode, sampaikan hal ini ke hosting agar aturan yang relevan disesuaikan.

Penyebab 6: Upload File Melebihi Batas Server

Mengunggah gambar atau file ke Media Library adalah salah satu aksi yang paling sering memunculkan error 400 pada publisher. Penyebabnya adalah ukuran permintaan yang melewati batas yang ditetapkan server atau PHP.

Ada tiga batas yang bekerja bersamaan. Pertama, upload_max_filesize di PHP, yaitu ukuran maksimum satu file yang boleh diunggah. Kedua, post_max_size di PHP, yaitu ukuran maksimum seluruh badan permintaan POST — termasuk file dan field formulir. Ketiga, batas di tingkat server web, misalnya LimitRequestBody di Apache atau client_max_body_size di nginx. Jika salah satu batas ini terlampaui, server menolak permintaan. Pada sebagian konfigurasi, penolakan ini tampil sebagai 400 Bad Request; pada konfigurasi lain tampil sebagai 413 Content Too Large. Keduanya menunjuk ke akar yang sama: permintaan Anda terlalu besar untuk batas yang berlaku.

Gejalanya mudah dikenali: upload file kecil berhasil, upload file besar gagal; atau upload satu gambar berhasil, tetapi upload banyak gambar sekaligus gagal. Perlu dicatat bahwa post_max_size harus lebih besar daripada upload_max_filesize, karena badan POST memuat file ditambah data formulir. Jika post_max_size lebih kecil dari ukuran file, upload akan gagal meski file itu sendiri masih di bawah upload_max_filesize.

Perbaikannya dimulai dari sisi konten: kompres gambar sebelum mengunggah. Gambar hasil kamera ponsel sering berukuran 3 sampai 8 MB; setelah dikompres ke format WebP atau JPEG berkualitas sedang, ukurannya bisa turun di bawah 200 KB tanpa perbedaan visual yang berarti bagi pembaca. Kompresi adalah perbaikan yang selalu benar — ia mempercepat situs, menghemat penyimpanan, dan menghindari batas upload sekaligus.

Jika file memang harus besar — misalnya dokumen PDF atau video pendek — periksa dan sesuaikan batasnya. Nilai batas saat ini bisa dilihat di wp-admin pada menu Media, lalu Tambah Baru, di bagian bawah halaman yang menampilkan “Ukuran maksimum berkas unggahan”. Untuk mengubahnya, Anda memerlukan akses ke konfigurasi PHP: melalui pengaturan PHP di panel hosting (cPanel, hPanel, atau sejenisnya), atau dengan menambahkan baris pada file .htaccess untuk server Apache, atau pada php.ini bila Anda mengelola VPS sendiri. Nilai yang umum dipakai publisher adalah upload_max_filesize 32 MB dan post_max_size 64 MB, tetapi angka yang tepat bergantung pada kebutuhan Anda — jangan menaikkan tanpa alasan, karena batas yang terlalu longgar memperbesar risiko penyalahgunaan upload.

Sebagai patokan praktik, bukan aturan resmi: untuk artikel blog biasa, gambar di bawah 500 KB per file dan total upload per aksi di bawah 8 MB jarang menimbulkan masalah pada hosting bersama. Jika Anda rutin mengunggah file yang lebih besar dari itu, pertimbangkan mengunggahnya melalui File Manager hosting atau FTP, bukan melalui Media Library.

Penyebab 7: REST API dan Parameter Tidak Valid

Publisher modern sering tidak menyadari bahwa editor blok WordPress (Gutenberg) bekerja melalui REST API di belakang layar. Setiap kali Anda menyimpan artikel, mengunggah gambar, atau mengubah pengaturan di editor, browser mengirim permintaan JSON ke endpoint seperti /wp-json/wp/v2/posts. Jika permintaan itu mengandung parameter yang tidak valid, WordPress mengembalikan 400 — dan di editor, kegagalan ini tampil sebagai pesan samar seperti “Updating failed” atau “Publishing failed”.

WordPress REST API memakai skema JSON untuk memvalidasi parameter. Bila sebuah parameter tidak lolos validasi — misalnya tipenya salah, nilainya di luar rentang yang diizinkan, atau parameter wajib tidak ada — responsnya adalah objek error dengan kode rest_invalid_param dan status 400. Contoh yang didokumentasikan dengan baik: parameter per_page pada endpoint daftar hanya menerima bilangan bulat dari 1 sampai 100. Meminta per_page=101 mengembalikan respons {"code":"rest_invalid_param","message":"Invalid parameter(s): per_page","data":{"status":400}}. Contoh lain: membuat pengguna dengan parameter yang tidak valid mengembalikan rest_invalid_param dengan status 400, sebagaimana tercatat dalam dokumentasi resmi kelas WP_REST_Users_Controller di developer.wordpress.org.

Penyebab lain pada kelompok ini adalah nonce yang kedaluwarsa. Nonce adalah token keamanan sekali pakai yang disertakan pada permintaan terautentikasi, baik melalui parameter _wpnonce maupun header X-WP-Nonce. Nonce WordPress berlaku dalam jendela waktu tertentu; jika Anda membuka editor, meninggalkannya lama, lalu menyimpan, nonce itu mungkin sudah kedaluwarsa dan permintaan ditolak dengan 400 atau 403. Solusinya sederhana: muat ulang halaman editor dan coba simpan lagi. Jika Anda memakai Application Password untuk mengakses REST API, pastikan kredensialnya masih berlaku dan permintaan dikirim melalui HTTPS — WordPress menolak Application Password pada koneksi yang tidak terenkripsi.

Diagnosis untuk kelompok ini memakai DevTools. Buka tab Network, lakukan aksi yang gagal, lalu cari permintaan ke /wp-json/ yang berstatus 400. Klik permintaan itu dan baca isi responsnya: WordPress biasanya menjelaskan parameter mana yang tidak valid dan mengapa. Pesan itu adalah petunjuk yang paling langsung menuju perbaikan. Jika responsnya menyebut parameter tertentu, perbaiki parameter itu di kode atau plugin yang mengirimnya. Jika responsnya menyebut nonce, muat ulang halaman. Jika semua permintaan REST API gagal — termasuk permintaan dasar ke /wp-json/ — masalahnya lebih mendasar: permalink, plugin keamanan yang memblokir REST API, atau hosting yang menonaktifkan endpoint tersebut. Dalam hal ini, uji endpoint dasar https://namadomain.com/wp-json/ di browser: respons JSON yang valid berarti REST API hidup; pesan 400 atau 404 berarti ada yang memblokirnya.

Urutan Perbaikan Lengkap Langkah demi Langkah

Setelah memahami ketujuh penyebab di atas, berikut adalah urutan perbaikan yang disarankan — disusun dari yang paling mudah dan paling aman, menuju yang paling dalam. Ikuti secara berurutan, dan berhenti segera setelah error hilang. Jangan melompat ke langkah server sebelum langkah browser dicoba, karena sebagian besar kasus 400 selesai pada tiga langkah pertama.

Langkah 1 — Periksa URL. Lihat address bar. Hapus query string setelah tanda ? dan muat ulang. Jika halaman terbuka, selesai: masalahnya ada pada query string. Jika URL disalin dari tempat lain, ketik ulang secara manual.

Langkah 2 — Uji mode privat. Buka URL yang sama di jendela privat atau incognito. Jika terbuka normal, masalahnya ada pada cookie atau cache browser utama Anda. Lanjut ke langkah 3. Jika tetap error, masalahnya bukan di browser Anda; lanjut ke langkah 4.

Langkah 3 — Hapus cookie dan cache domain. Hapus cookie khusus untuk domain situs Anda, lalu hapus cache browser. Login kembali ke wp-admin dan uji aksi yang tadi gagal. Jika berhasil, selesai. Jika gagal, nonaktifkan ekstensi browser satu per satu dan uji lagi.

Langkah 4 — Uji dari perangkat dan jaringan lain. Buka URL dari ponsel atau jaringan yang berbeda. Jika error hanya muncul di satu jaringan — misalnya hanya di Wi-Fi kantor — kemungkinan ada proxy atau firewall jaringan yang mengubah permintaan Anda. Jika error muncul di mana-mana, masalahnya ada di sisi situs.

Langkah 5 — Simpan ulang permalink. Di wp-admin, buka Pengaturan, lalu Permalink, lalu klik Simpan Perubahan tanpa mengubah apa pun. Uji kembali artikel yang error.

Langkah 6 — Nonaktifkan plugin. Nonaktifkan semua plugin, uji, lalu aktifkan kembali satu per satu. Beri perhatian khusus pada plugin keamanan, cache, pengalihan, dan optimasi. Jika satu plugin terbukti menjadi penyebab, periksa pengaturannya atau cari penggantinya — jangan sekadar membiarkannya nonaktif tanpa rencana.

Langkah 7 — Ganti tema sementara. Aktifkan tema bawaan WordPress seperti Twenty Twenty-Five dan uji. Jika error hilang, masalahnya ada pada tema Anda. Periksa pembaruan tema atau hubungi pengembangnya.

Langkah 8 — Periksa .htaccess. Unduh cadangannya, lalu ganti isinya dengan aturan bawaan WordPress seperti yang ditunjukkan pada bagian keenam artikel ini. Uji. Jika error hilang, kembalikan aturan tambahan sedikit demi sedikit hingga menemukan blok yang bermasalah.

Langkah 9 — Periksa batas upload dan header. Jika error muncul saat mengunggah, kompres file dan periksa upload_max_filesize serta post_max_size. Jika pesan error menyebut header atau cookie terlalu besar, mintalah hosting memeriksa LimitRequestFieldSize (Apache) atau large_client_header_buffers (nginx) dan log error server.

Langkah 10 — Periksa log error server. Di panel hosting, buka error log dan cari entri pada waktu error terjadi. Log biasanya mencatat penyebab persisnya — aturan ModSecurity yang terpicu, field header yang melewati batas, atau direktif yang salah. Bawa informasi ini saat menghubungi hosting; log yang spesifik membuat bantuan datang lebih cepat.

Langkah 11 — Pulihkan dari cadangan bila perlu. Jika error muncul setelah perubahan besar — migrasi, update, atau instalasi plugin — dan tidak satu pun langkah di atas berhasil, pulihkan situs dari cadangan terakhir yang diketahui baik. Ini adalah jalan terakhir, bukan yang pertama, karena pemulihan dapat menghapus perubahan yang dibuat setelah cadangan itu.

Selama seluruh proses, catat apa yang Anda ubah dan kapan. Catatan sederhana — “10.15: nonaktifkan Wordfence, error hilang” — jauh lebih berharga daripada ingatan. Jika akhirnya Anda harus menghubungi hosting, catatan itu memungkinkan mereka membantu tanpa mengulang diagnosis dari nol.

Cara Mencegah Error 400 Kambuh

Memperbaiki error 400 adalah separuh pekerjaan; separuh lainnya adalah memastikan ia tidak kembali minggu depan. Pencegahan yang efektif sebagian besar berupa kebiasaan, bukan alat mahal.

Pertama, jaga kebersihan cookie dan cache secara berkala. Sebagai pemilik situs, Anda login ke wp-admin setiap hari dan memakai banyak plugin yang memasang cookie. Jadwalkan pembersihan cookie domain Anda sendiri sebulan sekali, atau segera setelah Anda mengganti plugin keamanan atau analitik. Pembaca Anda tidak perlu melakukan ini — cookie mereka hanya menumpuk bila situs Anda memasang terlalu banyak.

Kedua, audit plugin secara berkala. Setiap tiga bulan, buka daftar plugin dan tanyakan tiga hal untuk masing-masing: apakah masih dipakai, apakah masih diperbarui pengembangnya, dan apakah fungsinya tumpang tindih dengan plugin lain. Plugin yang tidak dipakai sebaiknya dihapus, bukan sekadar dinonaktifkan, karena plugin nonaktif yang tertinggal masih dapat menulis aturan ke .htaccess. Dua plugin dengan fungsi yang sama — misalnya dua plugin cache atau dua plugin keamanan — adalah sumber konflik yang paling umum.

Ketiga, terapkan perubahan satu per satu. Jangan memasang tiga plugin, mengubah permalink, dan mengedit .htaccess dalam satu sesi. Setiap perubahan diuji dulu sebelum perubahan berikutnya dilakukan. Dengan cara ini, bila error muncul, Anda langsung tahu perubahan mana yang menjadi penyebabnya.

Keempat, buat cadangan sebelum perubahan besar. Cadangan lengkap — file dan database — sebelum migrasi, sebelum mengganti tema, dan sebelum mengubah .htaccess atau konfigurasi server. Cadangan yang baik membuat langkah pemulihan menjadi hitungan menit, bukan hitungan jam.

Kelima, kompres gambar sebagai kebiasaan, bukan sebagai perbaikan darurat. Tetapkan standar di redaksi Anda: tidak ada gambar yang diunggah tanpa dikompres, dan tidak ada gambar yang melebihi 500 KB kecuali ada alasan khusus. Kebiasaan ini mencegah masalah batas upload sekaligus mempercepat situs.

Keenam, pantau Search Console. Google Search Console melaporkan halaman yang mengembalikan kode 4xx pada laporan Page Indexing. Periksa laporan ini seminggu sekali. Jika sebuah URL yang sebelumnya baik tiba-tiba muncul sebagai error, Anda menangkap masalahnya saat masih kecil — sebelum URL itu dihapus dari indeks.

Ketujuh, batasi jumlah cookie pihak ketiga. Setiap layanan yang Anda pasang — analitik, obrolan langsung, pemutar video, tombol berbagi — berpotensi menambah cookie. Tinjau daftarnya setahun sekali dan hapus layanan yang tidak lagi memberi nilai. Semakin sedikit cookie, semakin jauh jarak Anda dari batas header server.

Kapan Harus Menghubungi Hosting

Tidak semua error 400 bisa — atau seharusnya — diperbaiki sendiri. Hubungi tim dukungan hosting bila Anda menemui salah satu dari tanda berikut.

Pertama, error muncul di semua halaman dan semua perangkat, termasuk halaman yang tidak pernah Anda ubah. Ini menandakan masalah di tingkat server atau konfigurasi, bukan di konten Anda.

Kedua, Anda tidak memiliki akses untuk mengubah konfigurasi yang dibutuhkan. Menaikkan LimitRequestFieldSize, menyesuaikan large_client_header_buffers, atau menonaktifkan aturan ModSecurity tertentu hanya bisa dilakukan oleh hosting pada paket shared hosting. Jangan mencoba mengakali batasan ini dengan trik yang tidak didokumentasikan.

Ketiga, log error server menunjukkan penyebab yang tidak Anda kenali — misalnya aturan keamanan yang terpicu oleh pola yang tidak Anda pahami, atau galat pada modul server. Sertakan kutipan log dan waktu kejadian saat menghubungi dukungan; informasi ini mempercepat penyelesaian secara dramatis.

Keempat, error muncul kembali dalam beberapa jam setelah Anda perbaiki, tanpa perubahan apa pun dari sisi Anda. Pola kambuh seperti ini menandakan ada proses otomatis — misalnya cron plugin, sinkronisasi, atau aturan keamanan yang diperbarui hosting — yang menulis ulang konfigurasi Anda.

Saat menghubungi hosting, sampaikan lima informasi ini: URL persis yang error, teks pesan error selengkapnya, waktu kejadian, hasil pengujian Anda (mode privat, perangkat lain, URL bersih), dan kutipan log error bila ada. Dukungan yang menerima informasi lengkap dapat langsung memeriksa sisi server tanpa meminta Anda mengulang diagnosis yang sudah Anda lakukan.

FAQ

Apakah error 400 sama dengan error 404?

Tidak. Error 404 berarti server tidak menemukan halaman pada URL yang diminta — permintaannya sah, tetapi tujuannya tidak ada. Error 400 berarti server menolak permintaan itu sendiri karena dianggap cacat — misalnya URL salah bentuk, cookie rusak, atau header terlalu besar. Halaman yang dituju mungkin ada dan baik-baik saja, tetapi cara browser memintanya bermasalah. Perbaikannya pun berbeda: 404 diperbaiki dengan memperbaiki tautan atau memasang pengalihan, sedangkan 400 diperbaiki dengan memperbaiki permintaan, cookie, atau konfigurasi server.

Mengapa error 400 hanya muncul saat saya login ke wp-admin, tetapi halaman publik normal?

Karena wp-admin memakai jauh lebih banyak cookie dan permintaan terautentikasi daripada halaman publik. Cookie sesi login, nonce keamanan, dan data plugin semuanya dikirim pada setiap permintaan admin. Jika cookie itu rusak atau menumpuk hingga melewati batas header server, server menolak permintaan admin tetapi tetap melayani halaman publik yang tidak memakai cookie sebanyak itu. Mulailah dengan menghapus cookie domain Anda dan menguji dari mode privat.

Apakah menghapus cookie akan membuat saya logout dari semua situs?

Tidak, bila Anda hanya menghapus cookie untuk domain situs Anda. Penghapusan yang ditargetkan pada satu domain hanya memengaruhi situs itu; Anda akan diminta login ulang ke situs itu saja. Yang membuat Anda logout dari semua situs adalah perintah “hapus semua cookie”. Karena itu, selalu hapus cookie per domain, bukan seluruhnya, kecuali Anda memang sengaja ingin membersihkan semuanya.

Apakah menaikkan LimitRequestFieldSize atau large_client_header_buffers aman?

Menaikkan batas header dari nilai bawaan — misalnya Apache dari 8.190 byte menjadi 16.384 byte, atau nginx dari 4 x 8 KB menjadi 4 x 16 KB — adalah praktik yang umum dan umumnya aman bila dilakukan seperlunya. Namun batas ini ada untuk melindungi server dari serangan denial-of-service yang memakai header raksasa, sehingga menaikkannya secara berlebihan meningkatkan risiko. Aturan yang baik: naikkan secukupnya untuk kebutuhan nyata Anda, dan utamakan mengurangi jumlah serta ukuran cookie sebagai perbaikan permanen.

Mengapa formulir atau upload saya memunculkan error 400 padahal filenya kecil?

Karena penyebabnya mungkin bukan ukuran file, melainkan isi atau cara pengirimannya. Formulir yang mengandung karakter khusus, shortcode, atau potongan kode dapat ditolak oleh aturan keamanan seperti ModSecurity. Upload yang gagal meski filenya kecil dapat disebabkan nonce yang kedaluwarsa — misalnya Anda membuka halaman upload lama lalu mengunggah — atau plugin yang mengubah permintaan. Coba muat ulang halaman dan unggah lagi; bila tetap gagal, periksa log keamanan atau nonaktifkan sementara plugin keamanan untuk menguji.

Apakah error 400 membuat artikel saya hilang dari Google?

Bila error 400 terjadi pada URL artikel dan dibiarkan, ya — secara bertahap. Google tidak mengindeks URL yang mengembalikan kode 4xx, dan URL yang sudah terindeks lalu mengembalikan 400 akan dihapus dari indeks seiring waktu, dengan frekuensi crawl yang berangsur menurun. Karena itu, error 400 pada artikel yang sudah terbit harus ditangani segera, dan Search Console sebaiknya diperiksa berkala agar masalah seperti ini tertangkap sejak dini. Sebaliknya, error 400 yang hanya terjadi di browser Anda sendiri karena cookie lama tidak memengaruhi Google sama sekali.

Kesimpulan

Error 400 Bad Request adalah pesan bahwa server menolak permintaan karena permintaan itu dianggap cacat — bukan karena halamannya hilang, bukan karena akses Anda dilarang, dan bukan karena servernya rusak. Definisi resminya di RFC 9110 bagian 15.5.1, dan dampaknya bagi publisher nyata: URL yang mengembalikan 400 tidak diindeks Google, artikel yang sudah terindeks dapat dihapus dari indeks, iklan tidak tampil, dan pembaca pergi.

Kabar baiknya, diagnosis error 400 mengikuti pola yang bisa dibaca. Satu URL yang error menunjuk ke URL itu sendiri. Error yang hanya muncul di wp-admin menunjuk ke cookie atau plugin. Error saat menyimpan atau mengunggah menunjuk ke ukuran permintaan atau aturan keamanan. Error di semua halaman menunjuk ke .htaccess atau konfigurasi server. Dan perbaikannya mengikuti urutan yang aman: mulai dari browser, lalu WordPress, lalu server — selalu dengan cadangan sebelum mengedit file.

Tujuh penyebab yang dibahas dalam artikel ini — URL yang salah, cookie yang rusak atau terlalu besar, .htaccess yang rusak, permalink yang bermasalah, plugin atau aturan keamanan, upload yang melebihi batas, dan parameter REST API yang tidak valid — mencakup hampir semua kasus 400 yang dihadapi publisher WordPress. Kuasai urutan diagnosis dan perbaikannya, biasakan pencegahan seperti audit plugin berkala dan kompresi gambar, dan pantau Search Console setiap minggu. Dengan begitu, error 400 berhenti menjadi gangguan yang menghabiskan seharian, dan berubah menjadi masalah kecil yang selesai dalam hitungan menit.

Untuk memahami kode error WordPress lainnya, baca juga panduan seri ini: Mengatasi Error 401 Unauthorized di WordPress, Mengatasi Error 403 Forbidden di WordPress, Mengatasi Error 404 dan Redirect Loop di WordPress, Mengatasi Error 429 Too Many Requests di WordPress, Mengatasi Error 502 Bad Gateway di WordPress, Mengatasi Error 503 Service Unavailable di WordPress, Mengatasi Error 504 Gateway Timeout di WordPress, dan Mengatasi Error WordPress Paling Umum: White Screen, Error 500, dan Gagal Koneksi Database.

Sumber Resmi yang Dirujuk

1. RFC 9110 (IETF), Bagian 15.5.1 — definisi kode status 400 Bad Request: server tidak dapat atau tidak mau memproses permintaan karena dianggap ada kesalahan klien (sintaks cacat, framing tidak valid, atau routing menipu). https://www.rfc-editor.org/rfc/rfc9110#section-15.5.1
2. Google Search Central — “How HTTP status codes affect Google’s crawlers”: URL 4xx tidak diindeks; URL yang sudah terindeks lalu mengembalikan 4xx dihapus dari indeks seiring waktu; frekuensi crawl berangsur menurun; terakhir diperbarui 4 Februari 2026. https://developers.google.com/search/docs/crawling-indexing/http-network-errors
3. MDN Web Docs — “400 Bad Request”: penyebab umum meliputi sintaks permintaan yang cacat, framing pesan yang tidak valid, dan routing yang menipu. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
4. Cloudflare Docs — “Error 400”: permintaan yang mengandung karakter khusus yang tidak di-encode dengan benar akan dikembalikan sebagai HTTP Error 400; merujuk ke RFC 9110. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-400/
5. Apache HTTP Server Documentation — direktif LimitRequestFieldSize: membatasi ukuran satu field header permintaan; nilai bawaan 8.190 byte; bila terlampaui, Apache mengembalikan 400 Bad Request. https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize
6. nginx Documentation — large_client_header_buffers dan client_header_buffer_size: buffer awal 1 KB, buffer besar bawaan 4 x 8 KB; header yang tidak muat dikembalikan sebagai 400 “Request Header Or Cookie Too Large”. https://nginx.org/en/docs/ngx_http_core_module.html#large_client_header_buffers
7. RFC 6265 (IETF), Bagian 6.1 — agen pengguna seharusnya mendukung setidaknya 4.096 byte per cookie. https://www.rfc-editor.org/rfc/rfc6265#section-6.1
8. WordPress Developer Resources — REST API Handbook, Schema: parameter yang tidak lolos validasi skema mengembalikan error rest_invalid_param dengan status 400; parameter per_page hanya menerima 1 sampai 100. https://developer.wordpress.org/rest-api/extending-the-rest-api/schema/
9. WordPress Developer Resources — WP_REST_Users_Controller::create_item(): parameter pengguna yang tidak valid mengembalikan rest_invalid_param dengan status 400. https://developer.wordpress.org/reference/classes/wp_rest_users_controller/create_item/
10. PHP Manual — upload_max_filesize dan post_max_size: batas ukuran file unggahan dan ukuran total badan permintaan POST. https://www.php.net/manual/en/ini.core.php