Headless CMS nedir, ne zaman gerekir — ne zaman gereksizdir
Headless CMS bir moda değil, belirli bir problemin çözümü. Hangi durumda WordPress yeterli, hangi durumda içeriği sunumdan ayırmak gerekiyor?
Geleneksel bir CMS iki işi birden yapar: içeriği saklar ve o içeriği HTML’e çevirip yayınlar. Headless CMS ikincisini bırakır. İçeriği saklar, düzenleme arayüzünü verir ve içeriği bir API üzerinden sunar. Sayfayı nasıl çizeceğinize siz karar verirsiniz.
“Headless” kelimesi buradan geliyor: gövde (içerik) durur, baş (sunum katmanı) kesilir.
Neyi çözüyor, neyi çözmüyor
Headless mimari üç somut problemi çözer:
Aynı içeriği birden fazla yere basmak. Web sitesi, mobil uygulama, mağaza içi ekran, ortak API. İçerik tek yerde durur, her istemci kendi ihtiyacına göre okur. Geleneksel CMS’te bu, aynı metnin üç yerde ayrı ayrı güncellenmesi demektir.
Sunum katmanını özgür bırakmak. Tema sisteminin izin verdiği kadarını değil, istediğinizi yaparsınız. Performans bütçesi sizin kontrolünüzdedir; bilmediğiniz bir eklentinin sayfaya 300 KB script eklemesi olmaz.
Yapısal çok dillilik. Diller birbirinin çevirisi değil de farklı yapıdaki sayfalarsa, eklenti tabanlı çeviri katmanları bunu “eksik çeviri” sayar ve sizi tek şablona zorlar. Headless’ta dil, içerik modelinin bir alanıdır.
Çözmediği şeyler de var: içerik üretmeyi kolaylaştırmaz, SEO’yu kendiliğinden iyileştirmez, maliyeti düşürmez.
Gerçek maliyeti
Headless’ın en çok atlanan tarafı, geleneksel CMS’in bedava verdiği şeyleri sizin yazmak zorunda kalmanız:
- Önizleme. Editör taslağı yayımlamadan nasıl görecek?
- Medya kütüphanesi ve görsel türevleri.
- Sürüm geçmişi ve geri alma.
- Rol bazlı yetki.
- Yönlendirme yönetimi (bir sayfanın adresi değiştiğinde 301).
- Site içi arama.
WordPress bunların hepsini kutudan çıkar hâlde verir. Headless’ta ya bunları sunan (ve aylık ücreti olan) bir hizmet seçersiniz ya da kendiniz yazarsınız. İkisi de bedava değildir.
Önizleme özellikle kritiktir. Editör yazdığı şeyin nasıl görüneceğini göremiyorsa sistemi kullanmaz; bu, headless projelerinin en sık takıldığı yerdir.
Karar tablosu
| Durum | Öneri |
|---|---|
| Tek dilli, tek kanal, standart blog | Geleneksel CMS |
| İçeriği ayda birkaç kez değişen kurumsal site | Statik site + Markdown |
| Aynı içerik web + mobil uygulamada | Headless |
| Beş dil, diller yapısal olarak farklı | Headless |
| Sıkı performans hedefi ve tam kontrol ihtiyacı | Headless veya statik |
| İçerik ekibi teknik değil ve destek bütçesi yok | Geleneksel CMS |
| Ürün kataloğu bir ERP’den geliyor | Headless |
Son satır önemli: içeriğin asıl kaynağı zaten başka bir sistemse, CMS’in sunum yapması gereksiz bir katmandır.
Ara seçenek: statik site üreticisi
İki uç arasında sık atlanan bir orta yol var. İçerik Markdown dosyaları olarak depoda dururken sayfalar derleme anında HTML’e çevrilir.
Bu, teknik bir ekip için en ucuz ve en hızlı seçenektir: veritabanı yok, çalışan sunucu yok, saldırı yüzeyi neredeyse yok. Değişiklikler sürüm kontrolünde, geri almak bir komut.
Kısıtı net: içeriği düzenleyecek kişi Git kullanmak zorunda. İçerik ekibiniz teknik değilse bu seçenek düşer — ya da üzerine bir düzenleme arayüzü eklersiniz, ki o noktada headless’a doğru yürümüş olursunuz.
Seçimden önce sorulacak beş soru
- İçeriği kim düzenleyecek? Teknik olmayan biri düzenleyecekse önizleme ve medya kütüphanesi pazarlık konusu değildir.
- Kaç kanal tüketecek? Tek kanalsa headless’ın en büyük gerekçesi ortadan kalkar.
- Diller birbirinin çevirisi mi? Değilse geleneksel CMS’in çeviri eklentileri size dar gelecek.
- İçerik ne sıklıkla değişiyor? Ayda birkaç kez ise statik üretim yeter; günde onlarca ise düzenleme arayüzü şart.
- Bakımı kim yapacak? Headless kurulum daha fazla parça demektir; bakacak kimse yoksa bu parçalar zamanla bozulur.
Özet
Headless CMS, içeriğin birden fazla yere gitmesi ya da sunum üzerinde tam kontrol gerekmesi hâlinde doğru karardır. Tek bir web sitesi için seçildiğinde genellikle çözdüğünden fazla iş yaratır.
Karar kriteri mimari zarafet değil şudur: içerik kaç yere gidiyor, ve onu düzenleyen kişi ne kadar teknik?
