Mengatasi Error 406 Not Acceptable di WordPress: Penyebab, Diagnosis, dan Cara Memperbaikinya untuk Publisher Indonesia

Error 406 Not Acceptable di WordPress biasanya muncul tiba-tiba: halaman yang kemarin terbuka normal mendadak menampilkan pesan “Not Acceptable!” atau “An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security.” Bagi publisher Indonesia, error ini bukan sekadar gangguan teknis kecil. Ia bisa mengunci Anda keluar dari wp-admin, menggagalkan penyimpanan artikel di editor Gutenberg, memblokir bot dan alat audit, sampai membuat halaman penting tidak bisa dirayapi Google. Kabar baiknya, penyebabnya hampir selalu bisa dilacak dalam waktu singkat, dan sebagian besar perbaikannya tidak memerlukan keahlian pemrograman. Artikel ini menjelaskan arti kode 406 menurut standar resmi RFC 9110, membedakannya dari error 4xx lain, lalu memandu diagnosis dan perbaikan langkah demi langkah — dari sisi pengunjung, dari sisi server, sampai kapan Anda sebaiknya menghubungi dukungan hosting.

Poin Kunci

• Error 406 Not Acceptable berarti server memiliki konten untuk URL yang diminta, tetapi tidak ada satu pun “representasi” (format, bahasa, atau encoding) yang cocok dengan preferensi yang dikirim klien melalui header negosiasi — dan server tidak mau mengirim representasi bawaan.
• Definisi resminya ada di RFC 9110 bagian 15.5.7; header yang berperan adalah Accept, Accept-Language, Accept-Encoding, dan (sebagai warisan) Accept-Charset.
• Di WordPress pada shared hosting Indonesia, penyebab paling umum bukanlah negosiasi konten murni, melainkan ModSecurity — firewall aplikasi web di level server yang memakai status 406 sebagai penolakan saat sebuah rule mendeteksi pola yang dianggap mencurigakan.
• Diagnosis tercepat: baca isi pesan error, uji URL yang sama dengan curl memakai beberapa nilai header Accept, lalu periksa log ModSecurity di cPanel atau tanyakan rule ID yang terpicu kepada hosting.
• Jangan mematikan ModSecurity secara permanen sebagai “perbaikan”. Matikan hanya sementara untuk menguji, lalu aktifkan kembali dan minta hosting memasukkan pengecualian (whitelist) untuk rule yang terbukti false positive.
• Error 406 yang menimpa halaman publik bisa merusak SEO karena Googlebot menerima status error, bukan konten; error 406 yang menimpa REST API bisa membuat editor Gutenberg gagal menyimpan dan plugin gagal bekerja.
• Selalu buat cadangan (backup) file .htaccess sebelum mengeditnya, dan uji setiap perubahan dari mode penyamaran (incognito) agar cache lama tidak mengaburkan hasil.

Daftar Isi

1. Apa Itu Error 406 Not Acceptable?
2. Cara Kerja Content Negotiation: Server dan Browser “Berdiskusi” soal Format
3. Penyebab Error 406 di WordPress: dari ModSecurity sampai MultiViews
4. Dampak Error 406 bagi Publisher Indonesia
5. Diagnosis: Cara Menemukan Akar Masalah dalam 15 Menit
6. Perbaikan untuk Pengunjung: yang Bisa Dilakukan dari Sisi Browser
7. Perbaikan 1: Menangani ModSecurity di cPanel dan Hosting
8. Perbaikan 2: Menonaktifkan MultiViews dan Merapikan .htaccess
9. Perbaikan 3: Memperbaiki Header Accept dan Endpoint REST API
10. Perbaikan 4: Plugin, Tema, dan CDN yang Memicu 406
11. Pencegahan: Agar Error 406 Tidak Kembali
12. Kapan Harus Menghubungi Dukungan Hosting

1. Apa Itu Error 406 Not Acceptable?

Error 406 Not Acceptable adalah kode status HTTP kelas 4xx (client error) yang didefinisikan dalam RFC 9110, standar semantik HTTP yang diterbitkan IETF. Definisi resminya pada bagian 15.5.7 berbunyi: server tidak memiliki representasi terkini dari resource yang diminta yang dapat diterima oleh user agent, berdasarkan field negosiasi proaktif yang diterima dalam permintaan, dan server tidak bersedia menyediakan representasi bawaan (default). Kalimat itu terdengar teknis, tetapi maknanya bisa disederhanakan menjadi satu analogi.

Bayangkan Anda memesan makanan di restoran dan berkata, “Saya hanya mau makan yang berbahan ayam, tanpa gluten, dan disajikan dingin.” Dapur restoran itu punya banyak hidangan, tetapi tidak satu pun yang memenuhi ketiga syarat sekaligus, dan koki tidak mau mengganti pesanan Anda dengan hidangan lain tanpa persetujuan. Jawaban yang Anda terima adalah penolakan sopan: “Maaf, tidak ada yang cocok.” Itulah 406. URL-nya ada, kontennya ada, tetapi tidak ada versi konten yang cocok dengan syarat yang diajukan klien — dan server menolak menebak-nebak.

1.1. Kata kunci yang perlu dipahami: representasi

Dalam HTTP, sebuah “resource” (misalnya satu URL artikel) bisa memiliki beberapa “representasi”: versi HTML untuk browser, versi JSON untuk aplikasi, versi bahasa Indonesia dan bahasa Inggris, atau versi terkompresi gzip dan versi tanpa kompresi. Klien menyatakan preferensinya lewat header negosiasi, server memilih representasi yang paling cocok, dan bila tidak ada yang cocok sama sekali, server yang ketat akan menjawab 406. Perlu dicatat, banyak server justru memilih jalan yang lebih ramah: mengirim representasi bawaan dengan status 200. MDN Web Docs mencatat bahwa dalam praktiknya error 406 sangat jarang dipakai untuk negosiasi murni, karena sebagian besar server lebih memilih mengirim representasi default daripada menolak. Fakta ini penting: bila Anda sering melihat 406 di WordPress, kemungkinan besar penyebabnya bukan negosiasi murni, melainkan lapisan keamanan server — dan itu dibahas tuntas pada bagian 3.

1.2. Bedanya 406 dengan error 4xx lain

Kesalahan umum adalah menganggap semua kode 4xx sama saja. Padahal setiap kode menunjuk akar masalah yang berbeda, dan salah menduga artinya bisa membuat Anda memperbaiki hal yang tidak rusak. Tabel berikut merangkum perbedaannya menurut RFC 9110 dan dokumentasi MDN.

Kode status	Arti singkat	Perbedaan dari 406
400 Bad Request	Permintaan tidak dapat dipahami server karena sintaks yang rusak	400 soal bentuk permintaan yang cacat; 406 soal permintaan yang sah tetapi preferensinya tidak dapat dipenuhi
401 Unauthorized	Permintaan memerlukan autentikasi	401 soal siapa Anda; 406 soal format apa yang Anda minta
403 Forbidden	Server memahami permintaan tetapi menolak mengizinkannya	403 adalah penolakan izin; 406 adalah kegagalan menemukan representasi yang cocok
404 Not Found	Server tidak menemukan resource untuk URL itu	404 berarti resource-nya tidak ada; 406 berarti resource-nya ada tetapi versinya tidak cocok
405 Method Not Allowed	Metode HTTP (misalnya POST) tidak diizinkan untuk resource itu	405 soal metode yang dipakai; 406 soal format respons yang diminta
415 Unsupported Media Type	Format badan permintaan yang dikirim klien tidak didukung server	415 soal format yang dikirim klien; 406 soal format yang diminta klien untuk respons
429 Too Many Requests	Terlalu banyak permintaan dalam waktu singkat	429 soal laju permintaan; 406 soal kecocokan representasi

Perbedaan yang paling sering membingungkan adalah 406 dengan 415. Keduanya menyangkut format, tetapi arahnya berlawanan. Pada 415, masalahnya ada pada apa yang dikirim klien ke server (misalnya mengunggah file dengan Content-Type yang tidak didukung). Pada 406, masalahnya ada pada apa yang diminta klien dari server (header Accept yang menuntut format yang tidak tersedia). Bila Anda mengunggah gambar dan mendapat 415, periksa format file yang diunggah. Bila Anda membuka halaman atau endpoint API dan mendapat 406, periksa header negosiasi dan lapisan keamanan server.

1.3. Seperti apa pesan 406 di layar

Tampilan pesan 406 tidak dibakukan, sehingga wujudnya berbeda-beda tergantung server dan hosting. Tiga varian yang paling sering ditemui publisher Indonesia adalah sebagai berikut.

Pertama, pesan klasik Apache dengan ModSecurity: “Not Acceptable! An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security.” Bila Anda melihat kalimat “This error was generated by Mod_Security”, penyebabnya hampir pasti ModSecurity, bukan negosiasi konten. Ini adalah petunjuk paling berharga di seluruh proses diagnosis, jadi jangan diabaikan.

Kedua, pesan generik browser atau WordPress: “406 Not Acceptable” polos, kadang disertai teks “nginx” atau nama server. Varian ini lebih samar dan membutuhkan pemeriksaan header untuk memastikan pemicunya.

Ketiga, 406 yang tidak terlihat sebagai halaman error sama sekali: editor Gutenberg menampilkan “Updating failed” atau “Publishing failed”, plugin menampilkan pesan “REST API tidak merespons”, atau alat audit SEO melaporkan URL mengembalikan status 406. Dalam kasus ini, status 406 hanya terlihat bila Anda membuka tab Network di DevTools browser atau memeriksa log server.

2. Cara Kerja Content Negotiation: Server dan Browser “Berdiskusi” soal Format

Content negotiation adalah mekanisme standar HTTP di mana klien dan server menyepakati bentuk terbaik dari sebuah resource sebelum resource itu dikirim. Mekanisme ini diatur pada bagian 12 RFC 9110 dan dijelaskan dengan ringkas dalam panduan content negotiation MDN. Memahami mekanisme ini membantu Anda membedakan 406 yang “asli” dari 406 yang sebenarnya adalah blokir keamanan.

2.1. Empat header negosiasi proaktif

Klien menyampaikan preferensinya melalui header permintaan. MDN mencantumkan tiga header utama, dan RFC 9110 menambahkan satu header warisan. Tabel berikut merangkum keempatnya beserta contoh nilainya.

Header	Yang dinegosiasikan	Contoh nilai
Accept	Tipe media (format) respons	text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
Accept-Language	Bahasa alami respons	id-ID, id;q=0.9, en-US;q=0.8, en;q=0.7
Accept-Encoding	Metode kompresi (content coding) respons	gzip, deflate, br
Accept-Charset	Set karakter respons (warisan, jarang dipakai browser modern)	utf-8, iso-8859-1;q=0.5

Header Accept adalah yang paling sering menjadi pemicu 406. Browser biasa mengirim daftar panjang yang diakhiri wildcard */*, artinya “bila tidak ada yang cocok, kirim apa saja”. Karena itu, browser biasa hampir tidak pernah menerima 406 murni. Sebaliknya, skrip, bot, alat audit, dan klien API sering mengirim header Accept yang sempit — misalnya hanya Accept: application/xml — sehingga peluang terjadinya ketidakcocokan jauh lebih besar. Inilah alasan sebuah halaman bisa terbuka normal di browser Anda tetapi mengembalikan 406 saat diakses oleh alat tertentu.

2.2. Nilai kualitas (q-value) dan wildcard

Setiap nilai dalam header negosiasi dapat diberi bobot kualitas (quality value) berupa angka desimal dari 0 sampai 1, ditulis sebagai q=. Nilai yang tidak diberi q dianggap memiliki bobot 1,0, alias paling disukai. Nilai q=0 memiliki arti khusus: “tipe ini tidak dapat diterima sama sekali”. Contohnya, Accept: application/xml; q=1, application/json; q=0 berarti klien hanya mau XML dan secara eksplisit menolak JSON. Bila server hanya menyediakan JSON, jawabannya adalah 406.

Wildcard */* berarti “semua tipe media dapat diterima”, dan * pada Accept-Language berarti “semua bahasa dapat diterima”. Wildcard adalah pengaman: selama ada wildcard dengan bobot di atas nol, server selalu punya sesuatu untuk dikirim, sehingga 406 tidak terjadi. Karena itulah, salah satu pemeriksaan diagnosis yang paling cepat adalah menguji URL yang sama dengan header Accept: */*. Bila URL itu mengembalikan 200 dengan wildcard tetapi 406 dengan header sempit, masalahnya terkonfirmasi sebagai negosiasi. Bila tetap 406 meski dengan wildcard, masalahnya hampir pasti berada di lapisan keamanan server.

2.3. Negosiasi proaktif dan reaktif

RFC 9110 membedakan dua gaya negosiasi. Negosiasi proaktif (server-driven) adalah yang dibahas di atas: server memilih satu representasi berdasarkan header permintaan, dan bila tidak ada yang cocok, server menjawab 406. Negosiasi reaktif (agent-driven) adalah gaya yang lebih ramah: server menjawab 300 Multiple Choices disertai daftar varian yang tersedia, lalu klien memilih salah satunya. Dalam praktik WordPress sehari-hari, Anda jarang berurusan langsung dengan keduanya, karena WordPress sendiri umumnya tidak melakukan negosiasi konten untuk halaman artikel biasa. Yang lebih sering terjadi adalah Apache dengan modul mod_negotiation dan opsi MultiViews yang mengaktifkan negosiasi untuk file di folder tertentu — ini dibahas pada bagian 8.

2.4. Apa yang seharusnya dikirim server bersama 406

RFC 9110 menyatakan bahwa server yang mengembalikan 406 sebaiknya (should) menyertakan badan respons berisi daftar karakteristik representasi yang tersedia beserta pengenalnya, agar user agent dapat memilih alternatif. MDN mencatat hal yang sama. Dalam praktik, Apache yang memakai mod_negotiation memang melakukan ini: badan respons 406-nya mencantumkan varian yang tersedia, misalnya report.html dan report.json beserta tipe medianya. Sebaliknya, ModSecurity tidak melakukan ini sama sekali; badan responsnya hanya berisi pesan penolakan generik. Perbedaan ini adalah petunjuk diagnosis yang berguna: bila badan respons 406 mencantumkan daftar varian, Anda berhadapan dengan negosiasi Apache yang asli. Bila badan respons hanya berisi pesan “generated by Mod_Security”, Anda berhadapan dengan blokir keamanan.

3. Penyebab Error 406 di WordPress: dari ModSecurity sampai MultiViews

Setelah memahami definisi resminya, kini saatnya melihat kenyataan di lapangan. Pada instalasi WordPress di shared hosting, 406 murni karena negosiasi konten relatif jarang. Sebagian besar kasus berasal dari lima pemicu berikut, diurutkan dari yang paling sering ditemui menurut berbagai panduan praktisi hosting dan dokumentasi penyedia hosting.

3.1. ModSecurity memblokir permintaan (penyebab nomor satu)

ModSecurity adalah firewall aplikasi web (WAF) sumber terbuka yang berjalan di server Apache dan dipakai luas oleh penyedia shared hosting, termasuk di Indonesia. Ia memeriksa setiap permintaan yang masuk terhadap sekumpulan rule — yang paling umum adalah OWASP Core Rule Set (CRS) — dan memblokir permintaan yang polanya menyerupai serangan, misalnya injeksi SQL atau cross-site scripting (XSS). Ketika sebuah rule terpicu, ModSecurity secara historis mengembalikan status 406 disertai pesan “This error was generated by Mod_Security”.

Masalahnya, rule keamanan bersifat heuristik: ia menebak berdasarkan pola, dan tebakan itu bisa salah. Inilah yang disebut false positive. Aktivitas normal seorang publisher yang sering salah dikenali sebagai serangan antara lain:

• Menyimpan artikel yang mengandung potongan kode, query SQL, atau tag HTML di dalam isi postingan — editor WordPress mengirim seluruh isi artikel lewat POST, dan rule bisa mengira itu upaya injeksi.
• Mengirim formulir kontak atau komentar yang berisi karakter khusus, tanda kutip, atau kata-kata yang masuk daftar pola serangan.
• Login ke wp-admin dari IP yang sebelumnya tercatat dalam daftar berisiko, atau setelah beberapa kali percobaan login yang gagal.
• Menginstal atau mengaktifkan plugin yang melakukan panggilan HTTP dengan pola yang tidak biasa, misalnya Jetpack yang menghubungkan situs self-hosted ke WordPress.com.
• Mengakses situs lewat VPN atau jaringan dengan IP yang dibagikan banyak pengguna dan pernah disalahgunakan.

Ciri khas 406 dari ModSecurity: ia sering muncul hanya pada aksi tertentu — misalnya hanya saat menyimpan artikel, hanya saat login, atau hanya pada satu halaman yang mengandung kata tertentu — sementara halaman lain di situs yang sama terbuka normal. Bila pola itu Anda kenali, hampir bisa dipastikan ModSecurity adalah pelakunya, dan perbaikan yang tepat ada pada bagian 7, bukan pada pengaturan format konten.

3.2. Content negotiation Apache dan opsi MultiViews

Apache memiliki modul mod_negotiation yang, bila diaktifkan lewat opsi MultiViews di .htaccess atau konfigurasi server, memungkinkan server memilih file berdasarkan header Accept permintaan. Contohnya, sebuah folder berisi laporan.html dan laporan.json; dengan MultiViews aktif, permintaan ke /laporan tanpa ekstensi akan membuat Apache memilih salah satu file berdasarkan header Accept. Bila klien meminta tipe yang tidak tersedia — misalnya Accept: image/png — Apache menjawab 406 dan mencantumkan varian yang tersedia di badan respons.

Pada WordPress, MultiViews jarang dibutuhkan karena sistem permalink WordPress sudah menangani URL tanpa ekstensi melalui rewrite rule. Namun opsi ini kadang aktif secara bawaan di konfigurasi hosting, atau diaktifkan oleh plugin dan tema tertentu. Bila 406 Anda muncul pada URL tanpa ekstensi file dan badan responsnya mencantumkan daftar varian, periksa bagian 8.

3.3. Header Accept yang terlalu sempit dari klien atau plugin

Klien API, skrip otomatisasi, dan sebagian plugin WordPress mengirim header Accept yang mereka tentukan sendiri. Bila nilainya terlalu sempit atau salah ketik — misalnya meminta application/xml dari endpoint yang hanya menyediakan JSON, atau meminta tipe vendor yang tidak dikenal — server yang ketat akan menjawab 406. Skenario yang umum ditemui publisher:

• Plugin yang menarik data dari API pihak ketiga (misalnya layanan email marketing, agregator konten, atau alat SEO) dengan header Accept yang tidak sesuai dengan format yang disediakan API tersebut.
• Skrip cron atau alat monitoring yang memakai curl tanpa header Accept yang wajar, sehingga server menganggap permintaan itu tidak dapat dipenuhi.
• Peramban (browser) lama atau ekstensi browser yang mengubah header permintaan secara agresif.
• Pengaturan Accept-Language yang terlalu ketat pada situs multibahasa, misalnya klien meminta bahasa yang tidak tersedia di situs dan server tidak menyediakan bahasa bawaan.

3.4. Plugin keamanan dan firewall WordPress

Selain ModSecurity di level server, plugin keamanan di level WordPress — misalnya Wordfence, Sucuri, atau All In One WP Security — juga dapat memblokir permintaan. Sebagian besar plugin ini mengembalikan 403, tetapi konfigurasi tertentu atau kombinasi dengan rule server dapat menghasilkan 406. Gejala yang mengarah ke plugin: error hilang saat semua plugin dinonaktifkan, lalu muncul kembali saat satu plugin tertentu diaktifkan. Diagnosis dengan mode aman plugin dibahas pada bagian 10.

3.5. CDN, reverse proxy, dan WAF pihak ketiga

Bila situs Anda berada di balik Cloudflare atau CDN lain, lapisan tambahan ini dapat ikut memengaruhi status yang diterima pengunjung. Dokumentasi resmi Cloudflare menyatakan secara eksplisit bahwa Cloudflare tidak menghasilkan error 406 secara langsung, tetapi dapat meneruskan (proxy) respons 406 dari server asal (origin). Artinya, bila Anda memakai Cloudflare dan melihat 406, sumber masalahnya tetap di server asal atau di rule WAF yang Anda aktifkan di dashboard Cloudflare — bukan di Cloudflare itu sendiri. Hal yang sama berlaku untuk reverse proxy lain: proxy jarang menjadi sumber 406, tetapi dapat mempersulit diagnosis karena respons yang Anda lihat sudah melewati satu lapisan tambahan. Saat mendiagnosis, selalu uji juga koneksi langsung ke server asal bila memungkinkan, atau nonaktifkan sementara mode proxy untuk mengisolasi lapisan mana yang bermasalah.

3.6. Masalah encoding dan bahasa pada konten tertentu

Pemicu yang lebih jarang tetapi nyata adalah Accept-Encoding dan Accept-Language. Misalnya, server dikonfigurasi hanya melayani konten terkompresi tertentu sementara klien menolak semua encoding yang ditawarkan, atau situs multibahasa tidak menyediakan bahasa bawaan sehingga permintaan dengan Accept-Language yang sangat ketat gagal. Pemicu ini jarang berdiri sendiri; biasanya ia muncul bersamaan dengan konfigurasi server yang tidak biasa atau plugin multibahasa yang salah konfigurasi. Bila 406 hanya muncul pada halaman berbahasa tertentu atau pada file media dengan encoding khusus, arahkan pemeriksaan ke sini.

4. Dampak Error 406 bagi Publisher Indonesia

Bagi pemilik situs berita atau blog monetisasi, 406 bukan sekadar pesan error yang memalukan. Dampaknya menyentuh tiga hal yang paling berharga bagi publisher: peringkat pencarian, pendapatan iklan, dan kemampuan mengelola situs itu sendiri.

4.1. Dampak pada SEO dan perayapan Google

Googlebot meminta halaman Anda dengan header Accept standar yang menyertakan wildcard, sehingga dalam kondisi normal Googlebot jarang menerima 406 murni. Namun 406 dari ModSecurity berbeda: rule keamanan tidak peduli siapa yang meminta. Bila rule terpicu oleh pola URL atau parameter tertentu, Googlebot pun bisa menerima 406 saat merayapi halaman itu. Akibatnya, Google Search Console akan mencatat error perayapan (crawl error) pada URL tersebut, halaman bisa keluar dari indeks, dan peringkatnya merosot. Yang lebih berbahaya, 406 yang bersifat sporadis — kadang muncul, kadang tidak, tergantung parameter permintaan — membuat diagnosis dari Search Console saja menjadi sulit, karena laporan error terlihat tidak konsisten. Karena itu, begitu Search Console menunjukkan URL yang gagal dirayapi dengan status 4xx, segera uji URL itu dengan curl memakai beberapa variasi header seperti pada bagian 5.

4.2. Dampak pada pendapatan AdSense

Iklan AdSense dimuat melalui JavaScript yang meminta resource dari server Google, tetapi halaman Anda sendiri harus berhasil dimuat terlebih dahulu agar iklan tampil. Bila halaman artikel mengembalikan 406, pengunjung tidak melihat konten maupun iklan, sehingga tayangan (impression) dan klik pada halaman itu hilang. Lebih jauh, bila 406 menimpa halaman-halaman penting secara berkala — misalnya halaman yang sedang viral atau halaman yang dirujuk dari media sosial — kerugian pendapatannya bisa terasa dalam hitungan hari. Selain itu, permintaan iklan yang gagal berulang dapat memengaruhi metrik viewability dan fill rate yang Anda pantau di laporan AdSense. Jadi, 406 yang dibiarkan berlarut-larut bukan hanya masalah teknis, melainkan kebocoran pendapatan yang nyata.

4.3. Dampak pada pengelolaan situs: editor dan REST API

Dampak yang paling sering membuat publisher panik adalah 406 yang menimpa wp-admin atau REST API WordPress. Gejalanya bermacam-macam: tombol “Perbarui” di editor Gutenberg berputar tanpa henti lalu menampilkan “Updating failed. The response is not a valid JSON response”; penyimpanan draft gagal; widget dan blok tertentu tidak dapat dimuat; plugin yang bergantung pada REST API menampilkan pesan error. Penyebabnya sama: permintaan POST yang dikirim editor mengandung isi artikel yang memicu rule ModSecurity, sehingga server menjawab 406 dan editor tidak menerima JSON yang diharapkan. Bila Anda mengalami gejala ini, jangan langsung menyalahkan plugin atau tema. Uji dulu dengan menyimpan artikel yang isinya hanya satu paragraf teks polos. Bila artikel polos tersimpan normal tetapi artikel berisi kode atau karakter khusus gagal, ModSecurity hampir pasti pelakunya, dan solusinya ada pada bagian 7.

4.4. Dampak pada pengunjung dan kepercayaan pembaca

Pengunjung yang menemui halaman error cenderung menganggap situs tidak terurus atau tidak aman, lalu pergi dan tidak kembali. Dalam konteks media Indonesia yang persaingannya ketat, satu halaman error pada artikel yang sedang dibagikan di WhatsApp atau Facebook bisa memutus rantai penyebaran artikel itu. Pengunjung yang gagal login — misalnya anggota komunitas atau kontributor — juga akan menghubungi Anda dengan keluhan yang sulit dijelaskan bila Anda sendiri tidak tahu bahwa penyebabnya adalah 406. Karena itu, deteksi dini dan perbaikan cepat sama pentingnya dengan perbaikan itu sendiri, dan bagian 11 membahas cara memantaunya secara rutin.

5. Diagnosis: Cara Menemukan Akar Masalah dalam 15 Menit

Diagnosis yang baik mengikuti satu prinsip: ubah satu variabel dalam satu waktu, lalu catat apa yang berubah. Urutan berikut dirancang agar Anda menemukan akar masalah tanpa menebak-nebak, dan tanpa mengubah konfigurasi apa pun sebelum penyebabnya jelas.

5.1. Langkah 1: baca pesan error dengan teliti

Jangan langsung menutup halaman error. Salin seluruh teks pesan dan periksa tiga hal. Pertama, apakah ada kalimat “This error was generated by Mod_Security”? Bila ada, lanjutkan langsung ke pemeriksaan ModSecurity pada langkah 4. Kedua, apakah badan respons mencantumkan daftar varian file yang tersedia (misalnya report.html dan report.json)? Bila ada, penyebabnya adalah negosiasi Apache atau MultiViews, dan perbaikannya ada pada bagian 8. Ketiga, apakah error hanya muncul pada aksi tertentu — login, menyimpan artikel, mengirim formulir — atau pada semua halaman? Catat polanya, karena pola adalah petunjuk yang paling jujur.

5.2. Langkah 2: periksa dari sisi pengunjung

Buka URL yang bermasalah di jendela penyamaran (incognito) tanpa login. Bila halaman terbuka normal saat tidak login tetapi error saat login, masalahnya terkait sesi, cookie, atau permintaan yang hanya terjadi setelah autentikasi. Coba juga dari browser lain dan, bila memungkinkan, dari jaringan lain (misalnya beralih dari Wi-Fi ke data seluler). Bila error hilang saat berganti jaringan, IP Anda kemungkinan masuk daftar blokir sementara di server atau WAF — ini sering terjadi setelah beberapa kali percobaan login yang gagal atau setelah memakai VPN dengan IP yang dibagikan banyak pengguna.

5.3. Langkah 3: periksa header dengan DevTools browser

Di Chrome atau Firefox, tekan F12, buka tab Network, centang “Disable cache”, lalu muat ulang halaman yang bermasalah. Klik permintaan yang berstatus 406 dan periksa dua panel: Request Headers dan Response Headers. Pada Request Headers, perhatikan nilai Accept, Accept-Language, dan Accept-Encoding. Pada Response Headers, perhatikan nilai Server (Apache, nginx, LiteSpeed, atau Cloudflare) dan apakah ada header Content-Type yang aneh. Informasi ini menentukan langkah berikutnya: header Accept yang sempit mengarah ke perbaikan klien, sedangkan server Apache dengan pesan ModSecurity mengarah ke perbaikan server.

5.4. Langkah 4: uji dengan curl memakai beberapa header

Alat curl adalah cara paling jujur untuk menguji negosiasi, karena Anda mengendalikan penuh header yang dikirim. Bila Anda memakai Windows, perintah ini dapat dijalankan di PowerShell atau Windows Terminal; di macOS dan Linux, gunakan Terminal. Uji URL yang sama dengan empat variasi berikut, ganti https://bangekomedia.com/contoh-halaman/ dengan URL Anda yang sebenarnya.

Perintah pertama memakai header Accept yang luas, seperti yang dikirim browser biasa:

curl -i -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" https://contoh-situs.com/halaman/

Perintah kedua memakai wildcard penuh:

curl -i -H "Accept: */*" https://contoh-situs.com/halaman/

Perintah ketiga memakai header sempit yang hanya meminta JSON:

curl -i -H "Accept: application/json" https://contoh-situs.com/halaman/

Perintah keempat memakai header sempit yang hanya meminta XML:

curl -i -H "Accept: application/xml" https://contoh-situs.com/halaman/

Cara membaca hasilnya: bila perintah pertama dan kedua mengembalikan 200 tetapi perintah ketiga atau keempat mengembalikan 406, masalahnya terkonfirmasi sebagai negosiasi konten — server tidak menyediakan format yang diminta. Bila keempat perintah mengembalikan 406, termasuk yang memakai wildcard, masalahnya bukan negosiasi, melainkan blokir di level server, dan pemeriksaan ModSecurity adalah langkah berikutnya. Bila hanya perintah dengan header tertentu yang gagal, Anda sudah menemukan header pemicunya.

Untuk menguji endpoint REST API WordPress, ganti URL-nya dengan endpoint API, misalnya https://contoh-situs.com/wp-json/wp/v2/posts. Endpoint REST API WordPress secara resmi mengembalikan JSON; dokumentasi resmi WordPress REST API menyebutkan bahwa respons endpoint berupa JSON. Bila endpoint itu mengembalikan 406 saat diminta dengan Accept: application/json, masalahnya hampir pasti berada di lapisan keamanan server atau plugin, bukan di WordPress itu sendiri.

5.5. Langkah 5: periksa log ModSecurity dan log error server

Bila Anda memiliki akses cPanel, buka bagian Security, lalu klik ModSecurity dan pilih “View History” atau riwayat pemblokiran pada domain yang bermasalah. Riwayat ini mencantumkan rule yang terpicu beserta nomor rule-nya (rule ID). Catat rule ID, URL yang diblokir, dan waktunya. Informasi ini adalah “barang bukti” yang Anda perlukan saat menghubungi hosting: dukungan teknis dapat menonaktifkan atau mengecualikan rule tertentu jauh lebih cepat bila Anda menyertakan rule ID yang tepat, dibandingkan bila Anda hanya berkata “situs saya error 406”.

Bila Anda tidak memiliki akses ke log ModSecurity — misalnya hosting Anda memakai panel kustom seperti hPanel Hostinger — periksa menu log error atau hubungi dukungan dan minta mereka memeriksa rule ModSecurity yang terpicu pada URL dan waktu kejadian. Sertakan zona waktu (WIB) dan URL lengkap agar mereka dapat menemukan entri log yang tepat. Bila Anda tidak menemukan entri apa pun di log ModSecurity, itu sendiri adalah informasi: penyebabnya kemungkinan bukan ModSecurity, melainkan negosiasi, plugin, atau CDN, dan Anda dapat melanjutkan ke langkah 6.

5.6. Langkah 6: uji isolasi plugin dan tema

Bila log server bersih, lakukan uji isolasi. Nonaktifkan semua plugin, lalu uji kembali URL yang bermasalah. Bila error hilang, aktifkan plugin satu per satu sambil menguji setiap kali, sampai error muncul kembali — plugin terakhir yang diaktifkan adalah pelakunya. Bila error tetap ada meski semua plugin nonaktif, ganti tema sementara ke tema bawaan WordPress (misalnya Twenty Twenty-Five) dan uji lagi. Bila error hilang setelah ganti tema, penyebabnya ada pada tema atau pada kode kustom di file functions.php. Uji ini memang memakan waktu, tetapi ia memberikan kepastian, dan kepastian jauh lebih murah daripada menebak-nebak lalu mengubah konfigurasi yang tidak bersalah. Catatan penting: lakukan uji ini di luar jam sibuk atau memakai plugin mode pemeliharaan, agar pengunjung tidak melihat situs dalam keadaan setengah mati.

6. Perbaikan untuk Pengunjung: yang Bisa Dilakukan dari Sisi Browser

Bila Anda adalah pengunjung yang menemui 406 — atau publisher yang ingin memastikan masalahnya bukan di sisi pengunjung — langkah-langkah berikut adalah yang paling murah dan paling cepat, dan sebaiknya dicoba sebelum menyentuh konfigurasi server.

6.1. Muat ulang dan bersihkan cache

Tekan Ctrl+F5 (Windows/Linux) atau Cmd+Shift+R (macOS) untuk memuat ulang halaman tanpa memakai cache. Bila masih error, bersihkan cache dan cookie khusus untuk situs tersebut melalui pengaturan browser, lalu coba lagi. Cache yang usang kadang menyimpan header atau respons lama yang tidak lagi sesuai dengan konfigurasi server saat ini, dan membersihkannya menghilangkan variabel itu dari diagnosis.

6.2. Coba browser dan perangkat lain

Buka URL yang sama di browser lain, atau di perangkat lain. Bila halaman terbuka normal di browser lain, penyebabnya ada pada ekstensi, pengaturan, atau profil browser pertama. Nonaktifkan ekstensi satu per satu — terutama ekstensi pemblokir iklan, VPN, dan pengubah header — sampai halaman terbuka. Ekstensi yang mengubah header Accept atau User-Agent secara agresif adalah pemicu 406 yang sering tidak disadari.

6.3. Nonaktifkan VPN dan periksa jaringan

VPN dan proxy mengubah alamat IP serta kadang mengubah header permintaan. Bila Anda memakai VPN, matikan sementara dan coba lagi. Sebaliknya, bila Anda mengakses dari jaringan kantor atau kampus yang memakai proxy dengan header yang dimodifikasi, coba dari jaringan seluler. Bila error hilang setelah berganti jaringan, masalahnya ada pada IP atau header yang dikirim jaringan tersebut, dan solusinya adalah menghubungi administrator jaringan atau menunggu pemblokiran IP berakhir.

6.4. Periksa pengaturan bahasa browser

Bila 406 hanya muncul pada situs multibahasa, periksa daftar bahasa yang diprioritaskan di pengaturan browser Anda. Daftar yang terlalu ketat — misalnya hanya satu bahasa yang tidak tersedia di situs — dapat memicu kegagalan negosiasi bahasa pada server yang dikonfigurasi ketat. Tambahkan bahasa Inggris sebagai bahasa kedua, atau atur ulang daftar bahasa ke bawaan browser, lalu coba lagi.

7. Perbaikan 1: Menangani ModSecurity di cPanel dan Hosting

Bila diagnosis menunjuk ModSecurity, inilah bagian terpenting artikel ini. Ingat satu prinsip yang tidak boleh dilanggar: menonaktifkan ModSecurity secara permanen bukanlah perbaikan, melainkan membuka pintu. ModSecurity melindungi situs Anda dari injeksi SQL, XSS, dan serangan otomatis lainnya. Tujuan yang benar adalah menemukan rule yang salah memblokir (false positive), lalu mengecualikan rule itu saja, sementara perlindungan lainnya tetap berjalan.

7.1. Uji dengan menonaktifkan ModSecurity sementara

Di cPanel, buka bagian Security, klik ModSecurity, lalu matikan (Off) untuk domain yang bermasalah saja — bukan untuk seluruh akun bila Anda memiliki banyak domain. Uji kembali URL atau aksi yang sebelumnya error. Bila error hilang, ModSecurity terkonfirmasi sebagai penyebab. Segera aktifkan kembali ModSecurity, lalu lanjutkan ke langkah 7.2. Jangan biarkan ModSecurity mati lebih lama dari waktu yang diperlukan untuk pengujian. Bila hosting Anda memakai panel kustom tanpa menu ModSecurity — misalnya hPanel Hostinger — minta dukungan hosting untuk menonaktifkan sementara rule yang dicurigai, atau untuk memeriksa log dan memberi tahu rule ID yang terpicu.

7.2. Nonaktifkan rule tertentu, bukan seluruh firewall

Cara yang benar adalah menonaktifkan rule yang spesifik. Dari riwayat ModSecurity di cPanel, catat rule ID yang terpicu, lalu gunakan fitur pengecualian rule pada domain tersebut, atau minta dukungan hosting untuk memasukkan rule itu ke daftar pengecualian (whitelist) untuk domain Anda. Sebagian hosting menyediakan menu “ModSecurity Tools” atau “ConfigServer ModSecurity Control” untuk keperluan ini. Bila rule ID yang terpicu adalah rule generik yang sering menimbulkan false positive pada WordPress — misalnya rule yang mendeteksi pola SQL dalam isi artikel — dukungan hosting yang berpengalaman biasanya langsung mengenali dan dapat mengecualikannya dalam hitungan menit.

7.3. Perbaiki konten atau plugin yang memicu rule

Kadang rule yang terpicu sebenarnya bekerja dengan benar, tetapi dipicu oleh sesuatu yang bisa Anda ubah. Contoh yang paling sering: artikel yang berisi contoh query SQL lengkap, potongan kode dengan kata kunci yang masuk daftar pola serangan, atau formulir yang mengirim data dengan karakter khusus. Solusinya bukan mematikan rule, melainkan mengubah cara konten disajikan: tampilkan contoh kode sebagai gambar atau di dalam blok kode dengan karakter yang di-escape, pecah query SQL panjang menjadi beberapa bagian, atau ganti kata pemicu dengan sinonim. Bila pemicunya adalah plugin tertentu — misalnya plugin formulir atau page builder yang mengirim data dengan pola yang dikenali sebagai serangan — perbarui plugin itu ke versi terbaru, karena pengembang plugin yang baik biasanya sudah menyesuaikan format permintaannya agar tidak memicu rule WAF umum. Bila plugin sudah terbaru dan masih memicu rule, hubungi pengembang plugin dan sertakan rule ID-nya.

7.4. Cara .htaccess yang sering diajarkan — dan risikonya

Banyak tutorial di internet menyarankan menambahkan kode berikut ke file .htaccess untuk mematikan ModSecurity:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

Kode ini berasal dari era ModSecurity versi 1 dan tidak lagi berfungsi pada ModSecurity versi 2 atau 3 yang dipakai hosting modern; pada sebagian server, menambahkannya justru dapat memicu error 500 karena direktifnya tidak dikenali. Varian yang lebih baru memakai SecRuleEngine Off, tetapi banyak penyedia hosting memblokir override ModSecurity melalui .htaccess demi keamanan seluruh server. Karena itu, jangan mengandalkan cara ini. Cara yang didukung dan aman adalah melalui menu ModSecurity di panel hosting atau melalui permintaan ke dukungan hosting. Bila sebuah tutorial bersikeras bahwa .htaccess adalah satu-satunya jalan, anggap itu sebagai tanda bahwa tutorial tersebut sudah kedaluwarsa.

7.5. Bila Anda tidak memiliki akses ke pengaturan ModSecurity

Pada hosting managed WordPress atau panel kustom, Anda mungkin tidak menemukan menu ModSecurity sama sekali. Dalam situasi ini, kirim tiket ke dukungan hosting dengan format berikut: URL lengkap yang error, waktu kejadian beserta zona waktu, pesan error persis seperti yang tampil di layar, rule ID bila Anda mengetahuinya, dan hasil uji Anda (misalnya “error hilang saat ModSecurity dimatikan sementara” atau “error hanya terjadi saat menyimpan artikel yang mengandung kode SQL”). Tiket yang berisi kelima informasi ini biasanya ditangani jauh lebih cepat daripada tiket yang hanya berisi “situs saya error 406, tolong perbaiki”.

8. Perbaikan 2: Menonaktifkan MultiViews dan Merapikan .htaccess

Bila diagnosis menunjukkan negosiasi Apache yang asli — badan respons mencantumkan daftar varian — perbaikan yang tepat adalah mematikan MultiViews dan memeriksa file .htaccess.

8.1. Menonaktifkan MultiViews

Tambahkan baris berikut di awal file .htaccess di root WordPress Anda, sebelum blok # BEGIN WordPress:

Options -MultiViews

Baris ini mematikan negosiasi konten berbasis nama file untuk direktori tersebut. Simpan, lalu uji kembali URL yang bermasalah. Bila error hilang, Anda sudah menemukan penyebabnya. Perlu diingat, MultiViews jarang dibutuhkan oleh WordPress, karena permalink sudah ditangani oleh rewrite rule; mematikannya hampir tidak pernah merusak fungsi situs normal. Namun, bila situs Anda memakai aplikasi lain di subfolder yang mengandalkan negosiasi nama file, uji subfolder itu juga setelah perubahan.

8.2. Memeriksa dan merapikan file .htaccess

File .htaccess yang rusak atau berisi rule dari plugin lama adalah sumber masalah yang sering terlewat. Sebelum mengedit apa pun, unduh salinan .htaccess sebagai cadangan. Kemudian periksa isinya dan cari hal-hal berikut:

• Baris Options +MultiViews atau Options MultiViews yang mengaktifkan negosiasi — ubah menjadi Options -MultiViews atau hapus baris itu.
• Blok rewrite dari plugin yang sudah tidak terpasang, yang dapat mengarahkan permintaan ke lokasi yang salah.
• Aturan Header set atau RewriteCond yang memfilter User-Agent atau header Accept secara agresif.
• Direktif ModSecurity lama seperti SecFilterEngine yang tidak lagi dikenali dan dapat memicu error 500.

Bila Anda ragu dengan isi file, cara paling aman adalah mengganti .htaccess dengan versi bawaan WordPress yang bersih, lalu menambahkan kembali kustomisasi yang Anda kenali satu per satu. Versi bawaan WordPress untuk permalink adalah sebagai berikut:

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

Setelah mengganti file, buka Pengaturan > Permalink di wp-admin dan klik “Simpan Perubahan” tanpa mengubah apa pun, agar WordPress menulis ulang rule permalink-nya. Kemudian uji kembali URL yang bermasalah.

8.3. Memeriksa konfigurasi server di luar .htaccess

Bila Anda mengelola VPS atau server sendiri, periksa juga konfigurasi virtual host Apache. Opsi MultiViews dapat diaktifkan di level direktori pada file konfigurasi utama, sehingga mengubah .htaccess saja tidak cukup bila konfigurasi utama mengizinkan override yang berbeda. Periksa direktif Options dan AllowOverride pada konfigurasi virtual host Anda. Pada server Nginx, tidak ada MultiViews, sehingga 406 pada Nginx hampir selalu berasal dari aplikasi, WAF, atau konfigurasi try_files dan proxy yang salah mengarahkan permintaan — periksa blok location yang menangani URL tersebut.

9. Perbaikan 3: Memperbaiki Header Accept dan Endpoint REST API

Bila pemicunya adalah header Accept yang dikirim klien atau plugin, perbaikannya berada di sisi pengirim permintaan, bukan di server.

9.1. Perbaiki header Accept pada skrip dan integrasi

Periksa skrip, cron job, atau integrasi pihak ketiga yang memanggil situs Anda. Pastikan header Accept yang dikirim sesuai dengan format yang disediakan endpoint. Aturan praktisnya:

• Untuk endpoint REST API WordPress (/wp-json/...), kirim Accept: application/json.
• Untuk halaman web biasa, kirim header browser standar: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
• Jangan mengirim header Accept yang hanya berisi satu tipe sempit kecuali Anda yakin endpoint menyediakan tipe itu.
• Selalu sertakan User-Agent yang wajar dan dapat dikenali, karena sebagian WAF memblokir permintaan tanpa User-Agent atau dengan User-Agent kosong, dan sebagian memakai status 406 untuk penolakan itu.

Contoh perintah curl yang benar untuk menguji endpoint REST API WordPress:

curl -i -H "Accept: application/json" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://contoh-situs.com/wp-json/wp/v2/posts

Bila perintah ini mengembalikan 200 dengan badan JSON, endpoint Anda sehat dan masalah sebelumnya berasal dari header yang dikirim klien lain.

9.2. Memperbaiki REST API yang mengembalikan 406

Bila endpoint REST API mengembalikan 406 bahkan dengan header yang benar, lakukan pemeriksaan berikut secara berurutan. Pertama, periksa apakah permalink dalam keadaan sehat: buka Pengaturan > Permalink dan simpan ulang, karena permalink yang rusak dapat membuat permintaan ke /wp-json/ diteruskan secara salah. Kedua, nonaktifkan plugin keamanan dan plugin yang memodifikasi REST API, lalu uji lagi. Ketiga, periksa apakah ada rule ModSecurity yang memblokir jalur /wp-json/ — ini cukup umum, karena sebagian rule menganggap pola pada URL API sebagai serangan. Keempat, bila Anda memakai plugin yang membatasi akses REST API hanya untuk pengguna login, pastikan pengecualian yang benar sudah diatur untuk aplikasi yang membutuhkannya. Dokumentasi resmi WordPress REST API menjelaskan bahwa endpoint mengembalikan JSON dan bahwa autentikasi diperlukan untuk operasi tulis; endpoint baca publik tidak memerlukan autentikasi, sehingga 406 pada endpoint baca publik hampir selalu berasal dari lapisan di luar WordPress.

9.3. Memperbaiki editor Gutenberg yang gagal menyimpan

Gejala “Updating failed. The response is not a valid JSON response” pada editor Gutenberg sering kali adalah 406 yang menyamar. Langkah perbaikannya mengikuti urutan yang sama: simpan artikel berisi teks polos untuk menguji apakah isi artikel yang memicu rule; bila artikel polos berhasil tetapi artikel berisi kode gagal, pemicunya adalah ModSecurity dan perbaikannya ada pada bagian 7; bila keduanya gagal, periksa permalink, nonaktifkan plugin, dan periksa log server. Satu langkah tambahan yang sering membantu adalah memeriksa apakah plugin keamanan memblokir metode POST ke wp-admin/post.php atau ke /wp-json/wp/v2/posts — tambahkan pengecualian untuk kedua jalur itu di plugin keamanan Anda, atau minta hosting mengecualikan rule yang bersangkutan.

10. Perbaikan 4: Plugin, Tema, dan CDN yang Memicu 406

Bila server bersih dan header benar, giliran komponen WordPress itu sendiri yang diperiksa.

10.1. Uji isolasi plugin dengan benar

Nonaktifkan semua plugin melalui wp-admin, atau bila wp-admin tidak dapat diakses, ganti nama folder /wp-content/plugins/ menjadi /wp-content/plugins-nonaktif/ melalui File Manager atau FTP — WordPress akan menganggap semua plugin nonaktif. Uji kembali URL yang bermasalah. Bila error hilang, kembalikan nama folder, lalu aktifkan plugin satu per satu sambil menguji setiap kali. Plugin yang paling sering menjadi pelaku adalah plugin keamanan, plugin firewall, plugin cache yang memodifikasi header respons, plugin multibahasa yang mengatur negosiasi bahasa, dan plugin yang menambahkan endpoint API kustom. Setelah pelaku ditemukan, perbarui plugin itu, periksa pengaturannya (terutama pengaturan yang membatasi tipe konten atau bahasa), atau ganti dengan alternatif yang setara bila pengembangnya tidak lagi merespons.

10.2. Periksa tema dan kode kustom

Tema yang menambahkan header kustom, memaksa tipe konten tertentu, atau mendaftarkan endpoint dengan format respons yang terbatas dapat memicu 406 pada halaman tertentu. Uji dengan mengganti tema sementara ke tema bawaan WordPress. Bila error hilang, periksa file functions.php dan file template tema Anda, terutama kode yang memakai add_filter pada header respons atau yang mengatur Content-Type secara manual. Kode kustom yang memanggil status_header(406) atau yang mengembalikan 406 secara eksplisit pada kondisi tertentu juga patut dicurigai — cari string “406” di seluruh file tema dan plugin kustom Anda.

10.3. Periksa CDN dan WAF pihak ketiga

Bila Anda memakai Cloudflare, periksa tiga hal di dashboard-nya. Pertama, periksa menu Security > Events untuk melihat apakah ada rule WAF yang memblokir permintaan ke URL yang bermasalah. Kedua, periksa apakah ada Page Rule atau Transform Rule yang mengubah header Accept atau Accept-Encoding. Ketiga, uji dengan mengaktifkan mode Development (bypass cache) atau dengan menjeda Cloudflare sementara (Pause Cloudflare) untuk memastikan apakah error berasal dari Cloudflare atau dari server asal. Ingat pernyataan resmi Cloudflare: Cloudflare tidak menghasilkan 406 secara langsung, tetapi meneruskan respons 406 dari origin — jadi bila error tetap muncul saat Cloudflare dijeda, sumbernya ada di server asal. Pada CDN lain, periksa pengaturan kompresi dan negosiasi encoding: sebagian CDN yang memaksa Brotli atau format tertentu dapat berkonflik dengan server asal yang tidak mendukung encoding itu.

11. Pencegahan: Agar Error 406 Tidak Kembali

Memperbaiki 406 sekali saja tidak cukup; tanpa pencegahan, ia akan kembali saat Anda menerbitkan artikel dengan pola yang sama, menginstal plugin baru, atau saat hosting memperbarui rule ModSecurity-nya. Lima kebiasaan berikut menjaga situs Anda tetap aman dari 406 yang berulang.

11.1. Pantau Search Console dan log server secara rutin

Periksa laporan Page Indexing di Google Search Console setidaknya seminggu sekali. URL yang tiba-tiba berstatus error layak diuji dengan curl pada hari yang sama, bukan minggu depan. Bila hosting Anda menyediakan log error, periksa entri 406 di sana secara berkala dan catat URL serta rule ID yang berulang. Pola yang berulang adalah sinyal bahwa ada satu rule yang perlu dikecualikan secara permanen, bukan ditambal setiap kali.

11.2. Dokumentasikan setiap pengecualian rule

Setiap kali hosting mengecualikan sebuah rule untuk Anda, catat rule ID, tanggal, alasan, dan URL yang terdampak di dokumen internal Anda. Dokumentasi ini menghemat waktu luar biasa saat Anda pindah hosting atau saat hosting memperbarui rule set-nya dan pengecualian lama hilang. Tanpa dokumentasi, Anda akan mengulang seluruh proses diagnosis dari nol.

11.3. Uji artikel yang mengandung kode sebelum diterbitkan

Bila Anda rutin menerbitkan tutorial yang berisi potongan kode, query SQL, atau karakter khusus, biasakan menyimpan artikel sebagai draft dan mengujinya terlebih dahulu. Bila penyimpanan draft gagal dengan error 406, Anda tahu sebelum artikel itu tayang — dan Anda dapat menyesuaikan penyajian kode (misalnya memecah query panjang atau menampilkan kode sebagai gambar) sebelum pembaca menemukannya dalam keadaan rusak. Kebiasaan kecil ini mencegah skenario terburuk: artikel viral yang tidak bisa disimpan atau halaman penting yang tiba-tiba error di mata Googlebot.

11.4. Jaga plugin, tema, dan rule tetap diperbarui

Perbarui WordPress, tema, dan plugin secara teratur, dan lakukan di lingkungan staging bila memungkinkan. Pembaruan sering kali memperbaiki cara plugin mengirim permintaan agar tidak lagi memicu rule WAF. Sebaliknya, beri tahu hosting Anda bila Anda menginstal plugin baru yang melakukan panggilan API intensif, agar mereka dapat menyesuaikan rule bila diperlukan. Jangan menunda pembaruan keamanan dengan alasan “situs masih berjalan normal” — justru saat normal itulah pembaruan paling aman dilakukan.

11.5. Buat cadangan sebelum mengubah konfigurasi server

Setiap perubahan pada .htaccess, konfigurasi ModSecurity, atau pengaturan WAF harus didahului cadangan. Simpan salinan .htaccess sebelum dan sesudah perubahan, dan catat tanggal perubahannya. Bila sebuah perubahan justru menimbulkan error baru — misalnya error 500 setelah mengedit .htaccess — Anda dapat memulihkan cadangan dalam hitungan detik, tanpa harus mengingat persis apa yang Anda ubah.

12. Kapan Harus Menghubungi Dukungan Hosting

Tidak semua 406 dapat diperbaiki dari sisi WordPress. Hubungi dukungan hosting bila Anda menemui salah satu situasi berikut:

• Pesan error secara eksplisit menyebut ModSecurity, tetapi Anda tidak memiliki akses ke menu ModSecurity atau riwayat rule di panel hosting.
• Error hilang saat ModSecurity dimatikan sementara, tetapi Anda tidak dapat menentukan rule ID yang terpicu.
• Error hanya terjadi pada jalur tertentu seperti wp-admin atau /wp-json/ dan semua uji isolasi plugin dan tema sudah dilakukan tanpa hasil.
• Error muncul setelah hosting melakukan pemeliharaan, migrasi server, atau pembaruan rule set — ini menandakan perubahan di sisi server, bukan di situs Anda.
• Anda mengelola banyak domain dalam satu akun dan 406 muncul di beberapa domain sekaligus, yang mengarah ke konfigurasi server, bukan ke satu situs.

Saat menghubungi dukungan, sertakan lima informasi ini agar tiket Anda ditangani cepat: URL lengkap yang error; waktu kejadian beserta zona waktu (misalnya 10 November 2026 pukul 07.00 WIB); pesan error persis seperti yang tampil; hasil uji curl Anda, termasuk header mana yang memicu 406; dan rule ID ModSecurity bila Anda menemukannya di log. Dukungan hosting yang baik dapat mengecualikan rule yang terbukti false positive dalam hitungan menit bila menerima informasi selengkap ini. Bila dukungan menolak mengecualikan rule tanpa penjelasan, atau menyarankan Anda mematikan ModSecurity secara permanen, pertimbangkan untuk meminta eskalasi ke tim teknis senior — mematikan firewall secara permanen bukanlah solusi yang dapat diterima untuk situs produksi.

FAQ

Apakah error 406 berbahaya bagi SEO situs saya?

Ya, bila dibiarkan. Selama Googlebot menerima status 406 pada sebuah URL, Google tidak dapat mengindeks konten halaman itu dan dapat menurunkannya dari hasil pencarian. Namun 406 yang hanya menimpa satu aksi — misalnya penyimpanan artikel dari wp-admin — tidak memengaruhi halaman publik dan tidak berdampak pada SEO. Yang menentukan adalah URL mana yang mengembalikan 406: halaman publik yang dirayapi Google adalah yang paling kritis.

Apakah mematikan ModSecurity aman untuk memperbaiki 406?

Tidak sebagai solusi permanen. Mematikan ModSecurity menghilangkan perlindungan terhadap injeksi SQL, XSS, dan serangan otomatis lainnya. Cara yang benar adalah mematikan sementara hanya untuk menguji, lalu mengaktifkan kembali dan mengecualikan rule tertentu yang terbukti menimbulkan false positive. Bila hosting Anda menyarankan mematikan ModSecurity selamanya, minta penjelasan tertulis dan pertimbangkan pendapat kedua.

Mengapa 406 hanya muncul saat saya menyimpan artikel, padahal halaman lain normal?

Karena isi artikel yang Anda simpan mengandung pola yang dikenali rule ModSecurity sebagai serangan — biasanya potongan kode, query SQL, atau karakter khusus. Rule memeriksa badan permintaan POST, dan hanya permintaan yang mengandung pola itu yang diblokir. Solusinya adalah menyesuaikan penyajian kode di artikel atau meminta hosting mengecualikan rule yang bersangkutan, seperti dijelaskan pada bagian 7.

Apa bedanya 406 dengan 403? Keduanya sama-sama penolakan, bukan?

Keduanya memang sama-sama penolakan, tetapi alasannya berbeda. Kode 403 berarti server menolak memberi Anda akses ke resource itu, biasanya karena izin atau aturan keamanan. Kode 406 berarti resource-nya ada, tetapi tidak ada versi (format, bahasa, atau encoding) yang cocok dengan preferensi yang Anda ajukan. Bila Anda menerima 403, periksa izin dan autentikasi; bila menerima 406, periksa header negosiasi dan rule ModSecurity.

Apakah Cloudflare bisa menyebabkan error 406?

Menurut dokumentasi resmi Cloudflare, Cloudflare tidak menghasilkan error 406 secara langsung, tetapi dapat meneruskan respons 406 dari server asal Anda. Bila Anda memakai Cloudflare dan melihat 406, periksa rule WAF di dashboard Cloudflare dan, yang lebih penting, periksa ModSecurity di server asal. Menjeda Cloudflare sementara adalah cara cepat untuk memastikan lapisan mana yang menjadi sumber masalah.

Berapa lama biasanya perbaikan 406 memakan waktu?

Bila penyebabnya adalah header Accept yang salah pada skrip Anda, perbaikannya bisa selesai dalam hitungan menit. Bila penyebabnya adalah rule ModSecurity dan Anda sudah mengetahui rule ID-nya, dukungan hosting biasanya dapat mengecualikannya dalam hitungan menit sampai beberapa jam. Bila penyebabnya belum diketahui dan memerlukan uji isolasi plugin dan tema, siapkan waktu satu sampai dua jam. Yang paling lama adalah 406 yang bersifat sporadis dan sulit direproduksi — di sinilah log server dan dokumentasi waktu kejadian menjadi sangat berharga.

Kesimpulan

Error 406 Not Acceptable sering terlihat membingungkan karena pesannya berbicara tentang “representasi” yang tidak ditemukan, sementara kenyataan di WordPress lebih sering berbicara tentang firewall server yang memblokir permintaan normal. Kuncinya adalah membedakan kedua hal itu sejak awal: baca pesan error dengan teliti, uji URL dengan curl memakai beberapa variasi header Accept, dan periksa log ModSecurity. Bila pesan menyebut ModSecurity, tangani rule-nya — jangan mematikan firewall secara permanen. Bila badan respons mencantumkan daftar varian, periksa MultiViews dan .htaccess. Bila endpoint REST API yang gagal, periksa header dan permalink. Dan bila semua uji sudah dilakukan tetapi penyebabnya tetap tidak ditemukan, hubungi dukungan hosting dengan data lengkap, bukan dengan dugaan.

Bagi publisher Indonesia, nilai sebenarnya dari memahami 406 bukan sekadar bisa memperbaiki satu halaman error, melainkan mencegah halaman itu error di hadapan Googlebot dan pembaca pada saat yang paling tidak tepat. Pantau Search Console secara rutin, dokumentasikan setiap pengecualian rule, dan uji artikel yang mengandung kode sebelum diterbitkan. Dengan tiga kebiasaan itu, 406 berubah dari masalah yang menakutkan menjadi sekadar catatan kecil dalam rutinitas pengelolaan situs Anda.

Sumber resmi yang dirujuk

1. RFC 9110: HTTP Semantics, bagian 15.5.7 (406 Not Acceptable) dan bagian 12 (Content Negotiation) — https://www.rfc-editor.org/rfc/rfc9110.html
2. MDN Web Docs: 406 Not Acceptable — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/406
3. MDN Web Docs: Content negotiation — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Content_negotiation
4. MDN Web Docs: Accept (header) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept
5. Cloudflare Docs: Error 406 (Cloudflare tidak menghasilkan 406 secara langsung, tetapi meneruskan respons origin) — https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-406/
6. WordPress Developer Resources: REST API Handbook (endpoint mengembalikan JSON) — https://developer.wordpress.org/rest-api/
7. Apache HTTP Server Documentation: mod_negotiation dan Content Negotiation — https://httpd.apache.org/docs/2.4/mod/mod_negotiation.html
8. ModSecurity / OWASP Core Rule Set: dokumentasi proyek ModSecurity dan CRS — https://github.com/owasp-modsecurity/ModSecurity dan https://coreruleset.org/