Anda membuka editor Gutenberg, mencoba menyimpan, dan muncul pesan bahwa penyimpanan gagal. Atau sebuah plugin menampilkan error seperti ini:
Daftar Isi
- Jawaban Singkat
- Apa yang Sebenarnya Terjadi di Balik rest_no_route?
- Persiapan dan Backup
- Langkah 1: Uji REST API Inti
- Langkah 2: Simpan Ulang Permalink dan Periksa URL Situs
- Langkah 3: Cari Plugin atau Aturan Keamanan yang Memblokir
- Langkah 4: Isolasi Konflik Plugin dan Tema
- Langkah 5: Kasus Khusus Pengembang dan Jenis Konten Kustom
- Verifikasi Hasil
- Troubleshooting Lanjutan
- FAQ
- Kesimpulan
- Referensi
{
"code": "rest_no_route",
"message": "No route was found matching the URL and request method",
"data": { "status": 404 }
}
Kode rest_no_route berarti satu hal yang spesifik: WordPress menerima permintaan ke REST API, tetapi tidak menemukan rute yang cocok dengan URL dan metode permintaan itu. Rute itu tidak terdaftar — entah karena plugin atau jenis konten yang menyediakannya tidak aktif, karena permalink belum di-flush, atau karena sesuatu di server memblokir permintaan sebelum sampai ke WordPress. Kabar baiknya, sebagian besar kasus selesai tanpa menyentuh kode, dengan urutan pemeriksaan dari yang paling mudah ke yang paling dalam.
Jawaban Singkat
Mulai dari pemeriksaan paling cepat: buka https://domain-anda/wp-json/wp/v2/posts di browser. Jika hasilnya JSON mentah, REST API inti Anda sehat dan masalahnya ada pada rute plugin tertentu. Jika hasilnya halaman HTML, halaman login, atau error, sesuatu memblokir REST API. Setelah itu, simpan ulang permalink di Settings, Permalinks, lalu nonaktifkan plugin satu per satu untuk menemukan konfliknya, dan periksa plugin keamanan atau firewall server yang membatasi akses ke /wp-json/. Untuk pengembang, ingat satu aturan: permintaan internal lewat kode PHP tidak memakai awalan /wp-json/, sedangkan permintaan dari browser memakainya.
Apa yang Sebenarnya Terjadi di Balik rest_no_route?
REST API WordPress bekerja seperti buku alamat rute: setiap plugin, tema, dan jenis konten mendaftarkan rute-rutenya saat WordPress dimuat — misalnya /wp/v2/posts untuk posting, atau /nama-plugin/v1/... untuk rute kustom plugin. Ketika permintaan masuk, WordPress mencocokkannya dengan daftar itu. Jika tidak ada yang cocok, ia mengembalikan rest_no_route dengan status 404. Penyebabnya terbagi menjadi empat kelompok: rute tidak pernah didaftarkan (plugin nonaktif, jenis konten tidak mengaktifkan REST API), rute terdaftar tetapi permalink bermasalah sehingga permintaan tidak sampai ke handler yang benar, rute diblokir di tengah jalan (plugin keamanan, ModSecurity, aturan firewall, atau Cloudflare), dan URL situs yang tidak cocok (alamat WordPress http vs https yang berbeda dengan alamat yang diakses).
Persiapan dan Backup
- Catat dulu di mana tepatnya error muncul: saat menyimpan di Gutenberg, saat memakai fitur plugin tertentu, atau saat aplikasi eksternal memanggil API. Lokasi error mempersempit tersangka.
- Buat cadangan situs sebelum menonaktifkan plugin massal atau mengedit file server, supaya Anda bisa kembali bila perubahan justru memperburuk keadaan.
- Jika Anda akan mengedit file
.htaccess(Apache) atau konfigurasi Nginx, salin dulu file itu. Untuk Nginx, misalnya:
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak
Perubahan pada file konfigurasi server tanpa cadangan adalah cara tercepat mengubah satu masalah menjadi dua masalah.
Langkah 1: Uji REST API Inti
Buka https://domain-anda/wp-json/ di browser (ganti domain-anda dengan domain Anda). Hasil yang sehat adalah dokumen JSON yang mencantumkan namespace seperti wp/v2. Kemudian buka https://domain-anda/wp-json/wp/v2/posts: hasil yang sehat adalah daftar posting dalam format JSON. Jika kedua alamat ini sehat tetapi rute plugin tertentu mengembalikan rest_no_route, masalahnya spesifik pada plugin itu — lanjut ke Langkah 4. Jika alamat inti saja sudah gagal, masalahnya ada di lapisan yang lebih dasar: permalink, keamanan, atau server — lanjut ke Langkah 2 dan 3. Selain itu, buka Tools, Site Health di dashboard: WordPress sendiri melaporkan bila REST API bermasalah, dan laporan itu adalah titik awal yang cepat sebelum Anda membongkar apa pun.
Langkah 2: Simpan Ulang Permalink dan Periksa URL Situs
Buka Settings, Permalinks, dan klik Save Changes tanpa mengubah apa pun. Tindakan ini mem-flush aturan rewrite WordPress — mendaftarkan ulang bagaimana URL diterjemahkan menjadi permintaan — dan sering kali langsung memperbaiki rute yang "hilang" setelah migrasi, perubahan struktur permalink, atau pembaruan plugin. Setelah itu, periksa Settings, General: WordPress Address dan Site Address harus cocok dengan alamat yang benar-benar Anda akses, termasuk http vs https dan www vs non-www. Ketidakcocokan di sini membuat permintaan API dialihkan atau ditolak, dan Gutenberg menampilkan kegagalan simpan padahal halaman depan terlihat normal.
Untuk server Apache, pastikan file .htaccess di folder WordPress masih memuat aturan rewrite standar dan direktori WordPress mengizinkan override. Untuk Nginx, pastikan server block memuat aturan penerusan ke index.php, misalnya:
location / {
try_files $uri $uri/ /index.php?$args;
}
Setelah mengubah konfigurasi server, uji dulu dengan sudo nginx -t sebelum me-reload, dan jangan membuka port tambahan apa pun untuk "mengatasi" masalah ini — masalah rute tidak diselesaikan dengan membuka port.
Langkah 3: Cari Plugin atau Aturan Keamanan yang Memblokir
Plugin keamanan (seperti Wordfence dan sejenisnya), aturan ModSecurity di server, dan aturan firewall Cloudflare adalah tersangka klasik: mereka sering membatasi akses ke /wp-json/ atau menghapus header otorisasi yang dibutuhkan permintaan API. Periksa log plugin keamanan Anda untuk entri yang menyentuh wp-json, lalu cari pengaturan seperti "Restrict REST API" atau "Disable REST API" dan longgarkan untuk administrator, atau masukkan rute plugin yang bermasalah ke daftar yang diizinkan. Jika Anda memakai Cloudflare, periksa aturan firewall yang memblokir jalur /wp-json/. Jika hosting Anda mengaktifkan ModSecurity dengan aturan yang agresif, hubungi penyedia hosting dan minta mereka memeriksa log ModSecurity untuk permintaan API Anda — aturan server seperti ini tidak bisa diperbaiki dari dashboard WordPress.
Langkah 4: Isolasi Konflik Plugin dan Tema
Jika REST API inti sehat tetapi satu plugin mengembalikan rest_no_route, nonaktifkan semua plugin, uji rute itu lagi, lalu aktifkan kembali satu per satu sambil menguji setiap kali. Plugin yang ketika diaktifkan membuat error kembali adalah pelakunya. Periksa juga apakah plugin itu sudah diperbarui ke versi terbaru: rute yang tidak terdaftar sering kali disebabkan plugin yang kedaluwarsa atau tidak kompatibel dengan versi WordPress Anda. Bila plugin itu penting dan tidak bisa diganti, hubungi pengembangnya dengan menyertakan pesan error lengkap dan langkah yang sudah Anda coba — informasi itu mempercepat dukungan mereka. Sebagai pembanding, aktifkan sementara tema default WordPress (misalnya Twenty Twenty-Five) untuk memastikan temanya bukan penyebab; bila error hilang dengan tema default, konfliknya ada di tema Anda.
Langkah 5: Kasus Khusus Pengembang dan Jenis Konten Kustom
Dua kasus khusus layak disebut karena sering menghabiskan waktu berjam-jam. Pertama, jenis konten kustom (custom post type) tidak muncul di REST API secara default: pendaftarannya harus menyertakan show_in_rest => true, kalau tidak, permintaannya akan mengembalikan rest_no_route meskipun jenis konten itu tampil normal di dashboard. Ini urusan kode tema atau plugin Anda, bukan pengaturan dashboard. Kedua, permintaan internal lewat kode PHP: ketika kode memanggil API dari dalam WordPress sendiri, URL-nya tidak memakai awalan /wp-json/. Kode yang menulis /wp-json/nama-plugin/v1/endpoint di dalam permintaan internal akan gagal, sedangkan /nama-plugin/v1/endpoint akan berhasil — awalan itu hanya dipakai untuk permintaan HTTP dari luar.
Verifikasi Hasil
Perbaikan berhasil bila rute yang bermasalah mengembalikan JSON yang benar, bukan error rest_no_route, dan Gutenberg bisa menyimpan posting tanpa pesan gagal. Uji dari dua sisi: dari browser (buka URL /wp-json/ rute tersebut) dan dari alur kerja yang semula gagal (simpan posting di Gutenberg atau jalankan fitur plugin yang semula error). Jika rute inti sehat tetapi satu plugin tetap gagal setelah semua langkah, kemungkinan besar plugin itu sendiri yang tidak mendaftarkan rutenya dengan benar, dan langkah berikutnya adalah dukungan pengembang plugin, bukan perubahan server lebih lanjut.
Troubleshooting Lanjutan
| Situasi | Langkah berikutnya |
|---|---|
| Seluruh REST API gagal, bukan satu rute | Simpan ulang permalink, periksa URL situs, lalu periksa plugin keamanan dan ModSecurity |
| Hanya satu plugin yang gagal | Perbarui plugin itu, isolasi konflik satu per satu, hubungi pengembangnya bila perlu |
| Custom post type tidak muncul di API | Pastikan pendaftarannya memakai show_in_rest => true (perlu perubahan kode) |
| Permintaan internal PHP gagal tetapi browser berhasil | Hapus awalan /wp-json/ dari URL permintaan internal |
FAQ
Apakah rest_no_route berarti REST API dimatikan?
Belum tentu. Kode ini berarti satu rute spesifik tidak ditemukan. Bila rute inti seperti /wp/v2/posts masih sehat, REST API Anda hidup dan masalahnya ada pada rute plugin atau jenis konten tertentu.
Apakah menyimpan ulang permalink benar-benar bisa memperbaiki?
Ya, cukup sering. Permalink yang tidak di-flush membuat permintaan tidak diterjemahkan ke handler yang benar, sehingga rute yang sebenarnya terdaftar tetap tidak ditemukan.
Kenapa Gutenberg gagal simpan padahal situs terlihat normal?
Karena Gutenberg menyimpan lewat REST API. Halaman depan bisa terlihat sempurna sementara permintaan API diblokir oleh plugin keamanan, firewall, atau ketidakcocokan URL situs.
Kesimpulan
rest_no_route adalah pesan bahwa rute yang diminta tidak terdaftar, bukan bahwa WordPress Anda rusak total. Uji dulu REST API inti, simpan ulang permalink, periksa URL situs, singkirkan pemblokir di plugin keamanan dan server, lalu isolasi konflik plugin satu per satu. Dalam sebagian besar kasus, salah satu langkah itu mengembalikan rute yang hilang — dan Gutenberg pun kembali bisa menyimpan seperti biasa.
Referensi
- WordPress.org Support — "rest_no_route error": akar masalah pada endpoint plugin yang tidak terdaftar, pemeriksaan per peran pengguna, dan simpan ulang permalink — https://wordpress.org/support/topic/rest_no_route-error-2/ (dibuka 28 Okt 2026).
- Redirection — "WordPress REST API": kode rest_no_route dan rest_forbidden, pengaruh header otorisasi, dan arti kode HTTP 301/401/403/404/500 pada REST API — https://redirection.me/support/problems/rest-api/ (dari hasil pencarian 28 Okt 2026).