Headless CMS Nedir?

“Baş” neden ayrıldı?

Geleneksel bir CMS'te içerik veritabanı, şablonlar ve HTML üretimi aynı uygulamanın içindedir: editör yazıyı kaydeder, CMS de sayfayı kendi tema sistemiyle oluşturup ziyaretçiye gönderir. Headless yaklaşımda bu zincir ortadan bölünür. CMS yalnızca içerik deposu ve yönetim paneli olarak kalır; içeriği yapılandırılmış veri hâlinde bir API üzerinden sunar. Sayfayı kimin, nasıl üreteceği tamamen ayrı bir projenin, yani frontend'in işidir.

Bu ayrımın asıl gerekçesi kanal çeşitliliğidir. Aynı ürün açıklaması web sitesinde, mobil uygulamada, mağaza içi ekranlarda ve bir iş ortağının sisteminde gösterilecekse, içeriği belirli bir sayfa şablonuna bağlı olmadan saklamak gerekir.

Bir yayının yolculuğu

Tipik bir kurulumda frontend, içeriği derleme sırasında veya istek anında CMS'ten çeker. GraphQL destekleyen bir CMS'e gönderilen sorgu şöyle görünebilir:

query {
  articles(locale: "tr", first: 10) {
    title
    slug
    summary
    publishedAt
  }
}

Frontend bu veriyi alır ve sayfaları üretir. Yaygın yöntemlerden biri sayfaları derleme anında statik HTML'e dönüştürmektir (SSG). Editör yeni bir yazı yayımladığında CMS bir webhook gönderir; frontend de ilgili sayfaları yeniden üretir ya da ISR gibi bir yöntemle yalnızca değişen sayfaları tazeler. Böylece hem statik sayfa hızı hem de güncel içerik elde edilir.

Hangi projelerde anlam kazanır?

• Aynı içerik birden fazla kanala dağıtılıyorsa.
• Tasarım ve etkileşim, hazır bir temanın sınırlarını aşan özel bir ön yüz gerektiriyorsa.
• Birden fazla marka veya ülke sitesi ortak bir içerik havuzundan besleniyorsa.
• Ekipte frontend geliştirme ve bakımını üstlenebilecek bir yetkinlik varsa.

Görünmeyen bedeller

Headless mimari esneklik kazandırırken geleneksel CMS'in “bedava” verdiği bazı şeyleri geri alır:

• Önizleme: Editör, kaydetmeden önce sayfanın nasıl görüneceğini görmek ister. Bunun için frontend'de ayrıca bir önizleme modu kurulmalıdır.
• Sayfa kurgusu: Editörler sürükle-bırak ile sayfa düzenleyemeyebilir; düzen genellikle geliştiricinin tanımladığı bileşenlerle sınırlıdır.
• SEO alanları: Başlık etiketi, meta açıklama, canonical, site haritası, yönlendirmeler ve yapılandırılmış veri CMS'ten kendiliğinden gelmez; içerik modeline alan olarak eklenmeli ve frontend'de doğru üretilmelidir.
• Render stratejisi: Sayfalar yalnızca tarayıcıda JavaScript ile oluşturulursa arama motoru ve yapay zekâ tarayıcıları içeriği geç ya da eksik görebilir. Bu riskler JavaScript SEO başlığında ayrıntılı ele alınır; çoğu projede sunucu tarafı veya statik üretim tercih edilir.
• İki sistem: CMS ve frontend ayrı ayrı barındırılır, güncellenir ve izlenir.

Sık yapılan hata: içeriği sayfaya göre modellemek

Headless projelerde en pahalıya patlayan karar, içerik modelini sayfa tasarımına göre kurmaktır: “Ana sayfa” adında, içinde serbest HTML alanları bulunan tek bir kayıt gibi. Bu model ilk tasarım değişikliğinde ya da ikinci kanalda işe yaramaz. Sağlam bir model, içeriği anlamına göre böler (ürün, uzman, şube, SSS maddesi) ve sayfalar bu parçaları bir araya getirir. Zengin metin alanları da mümkün olduğunca HTML yerine yapılandırılmış bloklar olarak saklanmalıdır; aksi hâlde içerik başka bir kanala taşınırken yeniden temizlenmesi gerekir.