Headless WordPress Adalah: Cara Kerja, Biaya & Batasnya

Satu instalasi WordPress sebenarnya mengerjakan dua pekerjaan yang berbeda. Pekerjaan pertama adalah menyimpan dan mengatur konten: artikel, halaman, gambar, kategori, dan pengguna, semuanya tersusun rapi di dalam database. Pekerjaan kedua adalah merangkai konten itu menjadi halaman yang bisa dibuka pengunjung, dan pekerjaan kedua inilah yang dijalankan oleh tema.

Penggabungan dua pekerjaan tersebut yang membuat WordPress mudah dipakai sampai menopang 40,7% dari seluruh website di dunia. Penggabungan itu pula yang membatasinya. Selama tampilan diurus tema, Anda terikat pada PHP dan pada urutan berkas template yang sudah ditentukan WordPress. Headless WordPress adalah cara memisahkan kedua pekerjaan itu: WordPress tetap mengurus konten, sementara tampilannya dibangun terpisah dan mengambil data lewat sebuah penghubung. Artikel ini membahas cara kerjanya, keuntungannya, biayanya, dan bagian yang paling jarang dihitung orang — apa saja yang justru berhenti bekerja setelah pemisahan itu.

Apa Itu Headless WordPress?

Headless WordPress adalah susunan ketika WordPress dipakai hanya sebagai tempat mengelola konten. Tampilan yang dilihat pengunjung dibangun terpisah, lalu menarik datanya lewat API (Application Programming Interface) — penghubung yang memungkinkan dua aplikasi saling bertukar data.

Istilah headless secara harfiah berarti "tanpa kepala". Kepala di sini merujuk pada lapisan tampilan, yakni bagian yang dilihat manusia. Melepas kepala tidak berarti mematikan badannya. WordPress tetap berjalan penuh, wp-admin tetap bisa dibuka, dan penulis tetap bekerja seperti biasa. Yang berubah hanya satu: hasil tulisan itu tidak lagi digambar oleh tema WordPress.

Tiga istilah sering tertukar dalam pembahasan ini, dan membedakannya akan menghemat banyak salah paham:

1. Headless CMS: kategori CMS yang memang dirancang tanpa lapisan tampilan sejak awal. Strapi, Sanity, Contentful, dan Directus masuk di kelompok ini. Mereka tidak pernah punya tema untuk dilepas.
2. Headless WordPress: WordPress — sebuah CMS tradisional yang punya tema — yang dijadikan headless oleh penggunanya. Ini bukan sifat bawaan, melainkan cara memakai.
3. Decoupled: istilah yang lebih longgar untuk arsitektur apa pun yang memisahkan penyimpanan data dari penyajiannya. Setiap susunan headless bersifat decoupled, tetapi tidak sebaliknya.

Perbedaan nomor satu dan nomor dua itulah yang menentukan seluruh isi artikel ini. WordPress tradisional membawa tema, plugin, dan seluruh perkakas tampilan sebagai satu paket. Karena WordPress lahir dengan kepala, melepasnya berarti ada bagian yang ditinggalkan — dan bagian itu bisa dihitung.

Cara Kerja Headless WordPress: Empat Tahap

Alur kerjanya berjalan dalam empat tahap yang berurutan.

Tahap pertama, penulis menyimpan konten seperti biasa. Tidak ada yang berubah di sisi redaksi. Artikel ditulis di editor blok, gambar diunggah ke media library, kategori dan tag dipasang seperti sedia kala.

Tahap kedua, WordPress menyediakan konten itu sebagai data mentah. Kemampuan ini masuk ke inti WordPress pada versi 4.7 yang dirilis 6 Desember 2016. Sejak saat itu setiap instalasi otomatis membuka REST API di alamat /wp-json/wp/v2/, tanpa perlu plugin apa pun. Anda bisa membuktikannya sekarang juga di situs sendiri:

curl -s "https://situs-anda.com/wp-json/" \
  | head -c 400

Balasannya berupa JSON — format teks terstruktur yang mudah dibaca program. Untuk mengambil artikel, alamatnya /wp-json/wp/v2/posts.

Empat tahap headless WordPress: penulis menyimpan konten, WordPress membuka JSON, frontend menarik, halaman terbit.

Tahap ketiga, aplikasi frontend menarik data itu. Aplikasi ini berdiri sendiri, biasanya dibangun dengan React, Next.js, Astro, atau Nuxt. Ia memanggil alamat tadi, menerima JSON, lalu menyusunnya menjadi halaman.

Tahap keempat, halaman disajikan ke pengunjung. Penyusunannya bisa dilakukan di muka saat proses build (halaman jadi berkas statis) atau saat pengunjung meminta halaman. Pilihan ini menentukan hampir seluruh untung-ruginya, dan akan kita bahas lagi di bagian biaya.

Perlu diperhatikan: dalam susunan headless, situs WordPress asli Anda tetap dapat diakses publik kecuali sengaja ditutup. Banyak orang mengira alamat lama otomatis mati setelah frontend baru berdiri. Kalau dibiarkan, Anda justru punya dua situs dengan konten identik.

Dua Pintu Data: REST API Bawaan dan WPGraphQL

Ada dua jalan untuk mengeluarkan konten WordPress, dan pilihannya berdampak langsung pada jumlah data yang dikirim.

Jalan pertama adalah REST API bawaan, yang di dokumentasi resmi disebut WordPress REST API. Ia sudah ada di setiap instalasi dan dokumentasinya mencakup 21 jenis sumber daya. Pada instalasi nyata yang kami ukur, ia mendaftarkan 154 rute di dalam ruang nama wp/v2 saja. Kelemahannya terletak pada apa yang disebut over-fetching, yakni terkirimnya data yang sebenarnya tidak diminta. Satu objek artikel membawa 29 field sekaligus, termasuk seluruh isi HTML dan tautan relasi.

Angkanya mudah diukur sendiri. Pada instalasi yang kami uji, permintaan sepuluh artikel penuh menghasilkan balasan 333.148 byte. Permintaan yang sama dengan parameter _fields untuk membatasi kolom hanya menghasilkan 5.569 byte — hampir 60 kali lebih ringan, atau penghematan 98,3%.

S="https://situs-anda.com/wp-json/wp/v2"
curl -s "$S/posts?per_page=10" | wc -c

Ada pula batas keras yang perlu Anda ketahui sejak awal: parameter per_page hanya menerima angka 1 sampai 100. Mengisi 101 akan dibalas galat HTTP 400 bertanda rest_out_of_bounds. Untuk situs berisi 5.000 artikel, artinya minimal 50 permintaan hanya untuk menyusun satu daftar lengkap.

Jalan kedua adalah WPGraphQL, plugin yang menambahkan satu alamat tunggal tempat frontend menyebutkan persis kolom yang dibutuhkan. Ia menyelesaikan masalah over-fetching sekaligus mengurangi jumlah permintaan. Namun statusnya perlu dipertimbangkan jujur. Ia plugin pihak ketiga dengan 30.000 pemasangan aktif per September 2026, dan versi 2.22.2-nya membutuhkan minimal WordPress 6.0 serta PHP 7.4.

Dua pintu data headless WordPress: REST API bawaan mengirim 333.148 byte, turun jadi 5.569 byte memakai _fields.

Rekomendasi kami sederhana. Kalau frontend Anda hanya menampilkan daftar artikel dan halaman detail, REST API bawaan dengan _fields sudah memadai dan satu ketergantungan lebih sedikit. Kalau satu layar membutuhkan lebih dari tiga jenis data sekaligus — artikel, penulis, kategori, dan produk terkait, misalnya — WPGraphQL menghemat cukup banyak permintaan untuk sepadan.

Ringkasan perbedaan keduanya:

Kelebihan Headless WordPress dan Syaratnya

Empat keuntungan berikut nyata, tetapi masing-masing punya syarat yang jarang disebutkan bersamaan:

1. Halaman bisa jauh lebih cepat, dengan syarat: kecepatan tidak datang dari kata "headless", melainkan dari cara halaman disajikan. Keuntungan besar baru muncul kalau frontend memakai pra-render menjadi berkas statis lalu menyebarkannya lewat CDN. Frontend headless yang tetap memanggil API pada setiap kunjungan justru bisa lebih lambat daripada WordPress biasa yang di-cache dengan benar.
2. Kebebasan penuh memilih teknologi tampilan: Anda tidak lagi terikat pada PHP dan struktur tema. Next.js, Astro, Nuxt, SvelteKit, Gatsby, atau Vue sama-sama bisa dipakai, dan pembaruan tampilan tidak lagi menyentuh backend sama sekali.
3. Satu konten untuk banyak kanal: konten yang sama bisa disajikan ke website, aplikasi mobile, layar informasi di toko, atau mitra yang menarik data Anda. Inilah alasan paling kuat yang benar-benar sulit dijawab WordPress biasa.
4. Permukaan serangan publik mengecil: wp-admin tidak perlu lagi berada di domain utama, dan celah pada tema tidak lagi relevan karena temanya tidak dipakai. Catatannya, alamat /wp-json tetap terbuka kecuali Anda batasi, sehingga sebagian permukaan itu hanya berpindah, bukan hilang.

Yang Ikut Hilang Saat Kepala Dilepas

Bagian ini yang paling menentukan apakah headless WordPress cocok untuk Anda. Empat hal berikut benar-benar berhenti bekerja, dan besarnya bisa diukur.

Seluruh tampilan blok Gutenberg tidak ikut terkirim

REST API mengirimkan isi artikel dalam field content.rendered. Isinya HTML lengkap dengan kelas seperti wp-block-paragraph dan wp-block-quote. Yang tidak ikut terkirim adalah CSS yang membuat kelas-kelas itu berarti.

Kami mengukurnya pada satu halaman artikel WordPress yang sedang tayang. Halaman itu menyajikan 28 blok <style> berisi total 59.361 byte CSS, ditambah 6 berkas stylesheet terpisah. Respons REST API untuk artikel yang sama memuat nol byte di antaranya — tanpa satu pun tag <style>, <link rel="stylesheet">, maupun <script>.

Artinya seluruh tampilan blok harus ditulis ulang oleh pengembang frontend. Pekerjaan itu lebih berat daripada terdengar, karena sebagian nama kelas dibangkitkan saat halaman dirender. Salah satu contoh yang kami temukan berbunyi wp-container-core-buttons-is-layout-b192c3d7; bagian akhirnya berubah antar halaman, sehingga tidak bisa dicocokkan dengan CSS statis yang ditulis sekali.

Headless WordPress kehilangan 59.361 byte CSS blok Gutenberg: halaman utuh membawanya, respons REST API nol byte.

Semua keluaran wp_head() berhenti

wp_head() adalah fungsi yang dipanggil dari berkas header.php milik tema. Tanpa tema, fungsi itu tidak pernah dijalankan, dan seluruh isinya lenyap sekaligus:

• tag canonical penanda alamat resmi sebuah halaman
• sitemap bawaan di /wp-sitemap.xml, yang ada di WordPress sejak versi 5.5 pada 11 Agustus 2020
• penanda oEmbed yang membuat tautan situs Anda tampil sebagai kartu di aplikasi lain
• seluruh meta description, Open Graph, dan data terstruktur dari plugin SEO

Konsekuensinya jelas: tanggung jawab SEO teknis pindah sepenuhnya ke tim frontend. Plugin SEO tetap bisa dipasang dan tetap menghitung skor di dalam wp-admin. Namun hasilnya tidak sampai ke halaman yang dilihat Google, kecuali Anda sendiri yang menjembatani datanya.

Pratinjau, shortcode, dan plugin sisi tampilan

Tombol "Pratinjau" di editor mengarah ke tema, sehingga ia berhenti berguna kecuali frontend Anda membangun mekanisme pratinjau sendiri. Nasib serupa menimpa shortcode, formulir kontak, kotak komentar bawaan, dan setiap plugin yang bekerja dengan menyisipkan sesuatu ke halaman. Semuanya perlu diganti dengan pekerjaan tangan.

Bobot ekosistem yang ditinggalkan

Angka-angka ini menjelaskan mengapa keputusan tersebut tidak ringan. Direktori resmi WordPress memuat 67.491 plugin dan 8.648 tema. Elementor, Yoast SEO, dan Contact Form 7 masing-masing terpasang di lebih dari 10 juta situs, sementara WooCommerce di lebih dari 7 juta.

Bandingkan dengan sisi headless-nya: WPGraphQL 30.000 pemasangan, dan Faust.js — perkakas Next.js resmi dari WP Engine — hanya 1.000 pemasangan. Perbandingannya sekitar satu banding tiga ratus. Plugin bernama Headless Mode bahkan terakhir diperbarui pada 18 Juli 2024 dan hanya diuji sampai WordPress 6.6.7. Versi terbaru saat artikel ini ditulis sudah 7.1. Frontity, kerangka kerja headless WordPress yang dulu paling banyak dibicarakan, sudah tidak dikembangkan lagi setelah timnya bergabung ke Automattic.

Angka ekosistem di atas bukan alasan untuk menolak headless. Ia alasan untuk memastikan tim Anda siap membangun sendiri apa yang biasanya sudah tersedia sebagai plugin.

Biaya dan Kebutuhan Hosting Headless WordPress

Empat pos biaya berikut jarang masuk perhitungan awal, padahal ketiganya berjalan terus setiap bulan.

1. Dua lingkungan, bukan satu: Anda membayar dan merawat backend WordPress sekaligus tempat frontend berjalan. Backend headless umumnya butuh kontrol penuh untuk mengatur cache dan pembatasan akses API, sehingga VPS Indonesia lebih sesuai daripada hosting bersama. Anggarkan minimal dua kali biaya hosting sebelumnya.
2. Waktu build yang bertambah: pada strategi pra-render, setiap perubahan konten memicu pembangunan ulang halaman. Situs 500 artikel biasanya selesai dalam hitungan menit; situs 5.000 artikel bisa memakan puluhan menit kecuali Anda menerapkan pembangunan bertahap. Redaksi yang menerbitkan sepuluh artikel sehari akan merasakannya.
3. Pekerjaan invalidasi cache: ketika artikel diperbarui, ada dua sampai tiga lapis cache yang harus tahu — cache API, cache frontend, dan cache CDN. Mekanisme ini tidak datang sendiri dan harus dibangun serta diuji.
4. Orang yang merawat frontend: ini pos terbesar dan paling sering diabaikan. Tema WordPress bisa diganti operator konten dalam hitungan menit. Frontend buatan sendiri membutuhkan pengembang yang tersedia setiap kali tampilan perlu berubah.

Kapan Headless WordPress Sepadan dan Kapan Tidak

Berikut kriteria yang bisa Anda pakai untuk memutuskan, dengan ambang yang konkret.

Headless WordPress sepadan bila konten dipakai lintas kanal, tidak sepadan bila situs hanya di bawah 200 halaman.

Sepadan bila minimal dua dari empat kondisi ini terpenuhi:

• Konten yang sama dipakai di lebih dari satu kanal, misalnya website dan aplikasi mobile.
• Ada minimal satu pengembang frontend tetap di tim, bukan vendor sesekali.
• Tampilan yang Anda tuju tidak bisa dicapai tema mana pun tanpa penulisan ulang besar.
• Trafiknya besar sementara struktur halamannya sederhana, sehingga pra-render benar-benar menguntungkan.
• Anda menjalankan toko WooCommerce yang tampilannya harus berbeda jauh dari tema mana pun, dan tim Anda sanggup membangun ulang alur keranjang serta pembayaran.

Tidak sepadan bila salah satu kondisi ini muncul:

• Situs berisi di bawah 200 halaman dan tampil di satu kanal saja. Pekerjaan membangun ulang tampilan blok tidak akan terbayar.
• Redaksi bergantung pada pratinjau dan penyuntingan visual sehari-hari.
• Tidak ada pengembang frontend yang bisa dihubungi ketika tampilan perlu diubah.
• Keluhannya soal kecepatan, padahal belum pernah mencoba caching yang benar. Pada banyak kasus, layanan web hosting dengan cache yang disetel benar dan CDN di depannya sudah menyelesaikan masalahnya dengan biaya jauh lebih kecil.

Kesalahan yang paling sering kami temui adalah memilih headless untuk mengejar kecepatan. Kecepatan hampir selalu bisa dicapai lebih murah. Alasan yang benar-benar kuat hanya satu: konten Anda memang perlu keluar ke banyak tempat sekaligus.

Langkah Awal Menguji Headless di Situs Anda

Empat langkah berikut bukan tutorial pembangunan penuh, melainkan uji kelayakan yang bisa Anda selesaikan dalam satu sore sebelum memutuskan.

Langkah #1: Pastikan REST API Situs Anda Menjawab

Buka alamat berikut dan pastikan balasannya berupa JSON, bukan halaman galat. Sebagian plugin keamanan menutup akses ini secara diam-diam.

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://situs-anda.com/wp-json/"

Kode 200 berarti pintu datanya terbuka.

Langkah #2: Ukur Berat Data Situs Anda Sendiri

Bandingkan dua permintaan berikut. Selisihnya memperlihatkan seberapa besar over-fetching yang harus Anda tangani nanti.

S="https://situs-anda.com/wp-json/wp/v2/posts"
curl -s "$S?per_page=10" | wc -c
curl -s "$S?per_page=10&_fields=id,title" \
  | wc -c

Langkah #3: Hitung Kebutuhan Data per Layar

Buka rancangan halaman depan Anda, lalu hitung ada berapa jenis data di dalamnya. Kalau jawabannya tiga ke bawah, REST API bawaan sudah cukup. Kalau empat ke atas, pertimbangkan WPGraphQL sejak awal supaya tidak berpindah jalur di tengah pengerjaan.

Langkah #4: Tentukan Cara Render Sebelum Menulis Kode

Putuskan lebih dulu apakah halaman dibangun di muka atau saat diminta. Keputusan ini memengaruhi biaya, waktu terbit, dan strategi cache — dan mengubahnya belakangan berarti menulis ulang sebagian besar frontend.

Pertanyaan Seputar Headless WordPress

Apakah headless WordPress pasti lebih cepat?

Tidak otomatis. Kecepatan datang dari pra-render dan penyebaran lewat CDN, bukan dari pemisahan itu sendiri. Frontend headless yang memanggil API di setiap kunjungan bisa lebih lambat daripada WordPress biasa dengan cache yang disetel benar.

Apakah headless WordPress gratis?

Perangkat lunaknya gratis, susunannya tidak. Anda tetap membayar hosting untuk WordPress, ditambah tempat frontend berjalan, ditambah waktu pengembang untuk membangun apa yang tadinya disediakan tema dan plugin.

Bagaimana nasib SEO setelah WordPress dijadikan headless?

Seluruh urusan SEO teknis berpindah ke frontend. Canonical, meta description, data terstruktur, dan sitemap harus dibangun ulang, karena semuanya dulu keluar lewat wp_head() milik tema. Plugin SEO tetap bisa dipasang, tetapi datanya perlu Anda jembatani sendiri ke frontend.

Apakah REST API sebaiknya dinonaktifkan demi keamanan?

Dokumentasi resmi WordPress menyarankan untuk tidak menonaktifkannya, karena wp-admin sendiri bergantung pada API tersebut. Langkah yang dianjurkan adalah membatasi akses anonim lewat filter rest_authentication_errors, bukan mematikannya. Untuk penulisan data, WordPress menyediakan Application Passwords sejak versi 5.6.

Kenapa permintaan frontend saya ditolak dengan galat CORS?

Kendala ini muncul di hampir setiap proyek headless, dan penyebabnya biasanya bukan WordPress. Sejak awal WordPress sudah memantulkan asal permintaan pada header Access-Control-Allow-Origin, lengkap dengan Access-Control-Allow-Credentials dan Vary: Origin. Yang perlu Anda perhatikan justru daftar header yang diizinkan, karena isinya tetap: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, dan Content-Type. Header khusus di luar lima itu akan ditolak browser sampai Anda menambahkannya sendiri. Tersangka berikutnya adalah plugin keamanan atau firewall di depan situs yang membuang header tersebut. Periksa balasan mentahnya lebih dulu sebelum menambal apa pun:

O="https://frontend-anda.com"
curl -I -H "Origin: $O" \
  "https://situs-anda.com/wp-json/wp/v2/posts"

Perhatikan juga Access-Control-Expose-Headers pada balasan itu. Ia menyebut X-WP-Total dan X-WP-TotalPages, dua header yang memuat jumlah artikel dan jumlah halaman — tanpa keduanya frontend Anda tidak bisa membangun penomoran halaman.

Apa bedanya dengan headless CMS seperti Strapi atau Sanity?

Headless CMS adalah kategori yang lebih luas, dan Strapi, Sanity, Payload, maupun Storyblok termasuk di dalamnya. Semuanya dirancang tanpa lapisan tampilan sejak awal, sehingga tidak ada yang perlu dilepas dan tidak ada tampilan blok yang perlu ditulis ulang. Sebaliknya, WordPress membawa serta editor yang sudah dikenal redaksi, riwayat konten bertahun-tahun, dan kemampuan kembali memakai tema kalau keputusannya berubah. Pilihannya bergantung pada mana yang lebih mahal bagi Anda: membangun ulang tampilan, atau memindahkan konten dan melatih ulang redaksi.

Kesimpulan

Headless WordPress memindahkan pekerjaan tampilan dari tema ke tim Anda, lengkap dengan seluruh konsekuensinya. CSS blok harus ditulis ulang, keluaran wp_head() harus digantikan, dan ada dua lingkungan yang harus dirawat. Imbalannya nyata bagi yang benar-benar membutuhkannya: kebebasan penuh atas tampilan dan satu sumber konten untuk banyak kanal sekaligus.

Pakailah headless kalau konten Anda memang perlu keluar ke lebih dari satu tempat dan ada pengembang frontend yang merawatnya. Kalau yang Anda kejar hanya kecepatan, perbaiki dulu caching dan CDN pada WordPress yang sudah ada. Hasilnya biasanya setara, dengan biaya jauh lebih kecil. Semoga artikel ini membantu.