Headless CMS, içeriği yöneten paneli (arka uç) sitenin görünen yüzünden (ön uç) ayıran bir içerik yönetim sistemidir. Klasik bir CMS'te içerik girilen panel ile ziyaretçinin gördüğü sayfalar aynı yazılımın parçasıdır; headless yapıda ise CMS yalnızca içeriği saklar ve bir API üzerinden sunar. O içeriği web sitesi, mobil uygulama, mağaza ekranı ya da başka bir sistem alıp kendi arayüzünde gösterir. "Headless" (başsız) ifadesi, CMS'in bir "kafası", yani kendi ön yüzü olmamasından gelir.
Son yıllarda headless mimari ajans tekliflerinde sık geçmeye başladı ve beraberinde bir dizi abartılı beklenti getirdi: "Daha hızlı", "daha güvenli", "SEO için daha iyi", "geleceğe hazır". Bu iddiaların bazıları belirli koşullarda doğru, bazıları ise yanlış ya da eksik. Bu yazıda en yaygın yanlışları tek tek ele alıyor, headless CMS'in ne zaman gerçekten mantıklı, ne zaman gereksiz karmaşıklık olduğunu anlatıyoruz.
Önce kavramlar: Klasik, headless ve arada kalanlar
| Yaklaşım | Nasıl çalışır? | Örnek |
|---|---|---|
| Klasik (monolitik) CMS | Panel, veritabanı ve sayfa şablonları tek yazılımda; sayfa sunucuda oluşturulup ziyaretçiye gönderilir | Standart bir WordPress kurulumu |
| Headless CMS | CMS yalnızca içeriği saklar ve API ile sunar; ön yüz ayrı bir uygulamadır | Strapi, Sanity, Contentful, Directus gibi sistemler + Next.js, Nuxt, Astro gibi bir ön yüz |
| Hibrit / "decoupled" | Klasik CMS kendi ön yüzünü korur ama içeriği ayrıca API ile de sunar | WordPress'in REST API'si ile içeriği bir mobil uygulamaya da aktarmak |
Headless mimaride ön yüz genellikle iki şekilde oluşturulur: Sayfalar derleme anında statik HTML olarak üretilir (statik üretim) ya da her istekte sunucuda oluşturulur (sunucu tarafı oluşturma). Ön yüzün tamamen tarayıcıda JavaScript ile oluşturulması da mümkündür; ancak aşağıda göreceğimiz gibi bu yol, kurumsal siteler için çoğu zaman sorun çıkarır.
Yanlış 1: "Headless site her zaman daha hızlıdır."
Doğrusu: Hız mimariden değil, uygulamadan gelir. Statik üretilen ve bir CDN üzerinden sunulan sayfalar gerçekten çok hızlı açılabilir. Ancak aynı hız, iyi önbelleklenmiş klasik bir CMS ile de elde edilebilir. Öte yandan headless bir ön yüz, ziyaretçinin tarayıcısına büyük JavaScript paketleri gönderiyorsa, sayfa görünse bile etkileşime geç hazır olur ve Core Web Vitals değerleri kötüleşebilir.
web.dev'in web'de oluşturma (rendering) yöntemlerini anlatan rehberi de bunu vurgular: Sunucu tarafı oluşturma ve statik üretim, tarayıcıda oluşturmaya göre ilk içeriği daha hızlı gösterebilir; ama her yöntemin kendi ödünleşimi vardır. Yavaş bir siteyi hızlandırmak istiyorsanız önce PageSpeed ve Core Web Vitals rehberimizdeki adımlara bakın; sorun çoğu zaman mimaride değil, görsellerde, eklentilerde ve gereksiz kodlardadır.
Yanlış 2: "Headless SEO için daha iyidir."
Doğrusu: Arama motorları sitenin hangi CMS ile yapıldığına bakmaz; sayfanın ürettiği HTML'e, içeriğe, hıza ve teknik yapıya bakar. Headless yapı SEO'yu ne kendiliğinden iyileştirir ne de bozar. Ancak bazı riskleri vardır:
- Tarayıcıda oluşturulan içerik: Ön yüz içeriği yalnızca JavaScript çalıştıktan sonra gösteriyorsa, Google sayfayı işleyebilse de bu ek bir adımdır ve her bot JavaScript çalıştırmaz. Google'ın JavaScript SEO rehberi, sunucu tarafı oluşturmayı veya ön oluşturmayı (pre-rendering) önerir.
- Kaybolan temel işler: Klasik bir CMS'te eklentiyle kolayca yapılan meta başlık, canonical, XML site haritası, yönlendirme yönetimi ve yapısal veri, headless yapıda ön yüz ekibi tarafından ayrıca kodlanmalıdır. Unutulursa site sessizce zarar görür.
- Önizleme sorunu: İçerik editörü, yayımlamadan önce sayfanın nasıl görüneceğini göremiyorsa, hatalar canlıya çıkar.
Doğru kurulduğunda headless bir site SEO açısından çok iyi olabilir; ama bu, ekibin bu işleri bilinçli olarak yapmasına bağlıdır. Hangi temel işlerin gerektiğini teknik SEO kontrol listemizde bulabilirsiniz.
Yanlış 3: "Headless daha güvenlidir, saldırıya kapalıdır."
Doğrusu: Kısmen doğru. Statik üretilen bir ön yüzde ziyaretçinin eriştiği sunucuda veritabanı veya yönetim paneli bulunmaz; bu, saldırı yüzeyini gerçekten küçültür. Ayrıca yönetim paneli farklı bir alan adında ve erişimi kısıtlanmış şekilde tutulabilir.
Ancak risk ortadan kalkmaz, yer değiştirir: API anahtarlarının ön yüz koduna sızması, yanlış yapılandırılmış API izinleri (taslak içeriğin herkese açık olması gibi), CMS'in kendisinin güncellenmemesi ve ön yüzdeki JavaScript bağımlılıklarının açıkları. Headless bir yapıda bakım yükü azalmaz; iki ayrı sistemin bakımı yapılır. Bakımın kapsamını web sitesi bakım paketi yazımızda anlattık.
Yanlış 4: "Headless, WordPress'in yerini alan bir şeydir."
Doğrusu: Headless bir ürün değil, bir mimari yaklaşımdır. WordPress de headless olarak kullanılabilir: İçerik WordPress panelinde yönetilir, REST API üzerinden alınır ve ayrı bir ön yüzde gösterilir. Bu, içerik ekibinin alıştığı paneli korurken ön yüzü özgürleştirmenin yaygın bir yoludur. Öte yandan doğrudan headless olarak tasarlanmış sistemler (Strapi, Sanity, Contentful gibi) içerik modellemesinde daha esnek olabilir ama kendi öğrenme eğrileri vardır.
Yani soru "WordPress mi, headless mi?" değil, "Sitemiz için içerik yönetimi ile ön yüzü ayırmak gerekli mi?" olmalı. Kurumsal siteler için genel altyapı karşılaştırmasını WordPress mi, özel yazılım mı yazımızda yaptık.
Yanlış 5: "Headless, editörler için daha kolaydır."
Doğrusu: Çoğu zaman tersi geçerlidir. Klasik bir CMS'te editör bir sayfayı düzenlerken sonucu doğrudan görür. Headless bir CMS'te ise içerik genellikle yapılandırılmış alanlar (başlık, özet, görsel, metin blokları) olarak girilir; sayfanın nasıl görüneceği ön yüze bağlıdır. İyi kurulmuş bir önizleme ve iyi tasarlanmış bir içerik modeli bu farkı kapatır, ama bunlar kendiliğinden gelmez; ek geliştirme gerektirir.
Bunun bir avantajı da vardır: Yapılandırılmış içerik, editörün tasarımı yanlışlıkla bozmasını engeller ve aynı içeriğin farklı kanallarda tutarlı görünmesini sağlar. Hangi tarafın ağır bastığı, içerik ekibinizin alışkanlıklarına ve içeriğin kaç kanalda kullanılacağına bağlıdır.
Yanlış 6: "Headless daha ucuzdur" ya da "Headless çok pahalıdır."
Doğrusu: İkisi de duruma göre yanlış. Maliyeti belirleyen kalemler şunlardır:
- Geliştirme: İki ayrı katman (CMS yapılandırması ve ön yüz) geliştirilir. Basit bir kurumsal site için bu, klasik kuruluma göre genellikle daha fazla iş demektir.
- Barındırma: CMS için bir sunucu veya bulut hizmeti, ön yüz için ayrı bir barındırma ya da CDN. Bazı headless CMS'ler bulut hizmeti olarak sunulur ve kullanıcı, içerik sayısı veya API çağrısına göre ücretlendirilir.
- Bakım: İki sistemin güncellenmesi, API sürüm değişikliklerinin takibi.
- Ekip yetkinliği: Ön yüz çatısını ve API entegrasyonunu bilen geliştirici ihtiyacı. Ajansla yollarınızı ayırırsanız devralacak ekip bulmak klasik bir CMS'e göre daha zor olabilir.
Buna karşılık içeriğin web, mobil uygulama ve başka kanallarda tekrar tekrar kullanıldığı bir yapıda, her kanal için ayrı içerik yönetmek yerine tek bir merkez kurmak uzun vadede maliyeti düşürebilir.
Yanlış 7: "Headless geleceğe hazır olmak için şarttır."
Doğrusu: "Geleceğe hazır" olmanın asıl şartı, içeriğin temiz ve yapılandırılmış biçimde saklanmasıdır. İçeriği sayfa oluşturucu kodlarına gömülmemiş, düzgün alanlara ayrılmış klasik bir CMS de ileride headless yapıya geçebilir; çoğu modern CMS zaten bir API sunar. Bugün ihtiyaç duymadığınız bir mimariyi "ileride lazım olur" diye kurmak, bugünden itibaren o mimarinin bütün maliyetini taşımak demektir.
Headless ne zaman gerçekten mantıklı?
- Aynı içerik birden fazla kanalda kullanılıyorsa: Web sitesi, iOS ve Android uygulaması, mağaza içi ekranlar veya bir bayi portalı aynı ürün bilgisini, duyuruyu ya da kampanyayı gösteriyorsa. Mobil uygulama tarafında bu yaklaşımı native ve cross-platform karşılaştırmamızda anlattığımız teknolojilerle birleştirmek yaygındır.
- Ön yüz bir uygulama gibi davranıyorsa: Yoğun etkileşimli arayüzler, hesap paneli, filtreleme ve kişiselleştirme gerektiren yapılar.
- Ekipte ön yüz uzmanlığı varsa: Modern bir JavaScript çatısıyla çalışan ve SEO, erişilebilirlik ve performans konularını bilen bir ekip.
- İçerik başka sistemlerle birleşiyorsa: Ürün verisi ERP'den, fiyat bir fiyatlandırma servisinden, içerik CMS'ten geliyor ve hepsi tek bir ön yüzde birleşiyorsa. Bu tür entegrasyonların temellerini API entegrasyonu yazımızda anlattık.
- Çok sayıda site tek merkezden yönetiliyorsa: Bir marka grubunun birkaç sitesi veya farklı ülke siteleri ortak bir içerik havuzunu paylaşıyorsa.
Ne zaman gereksiz karmaşıklık?
- Beş-on sayfalık bir kurumsal tanıtım sitesi, ayda bir blog yazısı.
- İçeriğin yalnızca web sitesinde kullanıldığı, başka bir kanal planlanmayan projeler.
- İçerik ekibinin sayfaları sürükle-bırak düzenlemeye alışkın olduğu ve bunu sürdürmek istediği durumlar.
- Bütçenin ve takvimin dar olduğu, bakımı küçük bir ekibin üstleneceği projeler.
- Asıl sorunun hız veya güvenlik olduğu ve bu sorunların mevcut yapı içinde çözülebileceği durumlar.
Bu durumlarda iyi kurgulanmış, önbelleklenmiş ve bakımı yapılan klasik bir CMS ya da sade bir özel yazılım, headless mimarinin getirdiği ek katmanlara ihtiyaç duymadan aynı sonucu verir.
Karar vermeden önce sorulacak beş soru
- Bu içerik, web sitesi dışında hangi kanallarda gösterilecek? Somut bir liste var mı?
- İçerik ekibi sayfaları nasıl düzenlemek istiyor? Önizleme ihtiyacı nasıl karşılanacak?
- Meta etiketleri, site haritası, yönlendirmeler ve yapısal veri ön yüzde nasıl yönetilecek?
- CMS ve ön yüz nerede barındırılacak, toplam işletme maliyeti ne olacak?
- Bu yapıyı üç yıl sonra kim bakımını yapacak, ekip değişirse devralmak ne kadar kolay?
İlk soruya verdiğiniz cevap "yalnızca web sitesi" ise, headless yapının size sağlayacağı avantajın çok sınırlı kalması muhtemeldir.
Sık Sorulan Sorular
Headless CMS ile Jamstack aynı şey mi?
Değil ama sık birlikte anılırlar. Jamstack; önceden oluşturulmuş sayfaların CDN üzerinden sunulduğu ve dinamik işlerin API'lerle yapıldığı bir mimari yaklaşımı anlatır. Headless CMS bu yapıda içerik kaynağı olarak kullanılabilir, ancak headless bir CMS sunucu tarafı oluşturma yapan bir ön yüzle de çalışabilir.
Mevcut WordPress sitemizi headless yapıya çevirebilir miyiz?
Evet. İçerik WordPress'te kalır, REST API üzerinden okunur ve yeni bir ön yüz geliştirilir. Ancak bu, mevcut tema, eklenti ve sayfa oluşturucu işlevlerinin önemli bir kısmının ön yüzde yeniden yazılması anlamına gelir. Geçiş öncesinde hangi eklentilerin hangi işi yaptığını listelemek şarttır.
Headless CMS kendi sunucumuzda mı çalışmalı, bulut hizmeti mi?
İkisi de mümkün. Açık kaynak sistemler kendi sunucunuzda çalıştırılabilir; bu, veri üzerinde tam kontrol ama bakım sorumluluğu demektir. Bulut tabanlı hizmetler bakım yükünü alır ama kullanım bazlı ücretlendirme ve verinin bir üçüncü tarafta tutulması anlamına gelir. Kişisel veri işleniyorsa verinin nerede tutulduğu ayrıca değerlendirilmelidir.
Headless yapı e-ticaret için uygun mu?
Büyük ve çok kanallı mağazalar için uygun olabilir; ancak sepet, ödeme, stok ve kampanya gibi bütün işlevlerin API ile kurgulanması gerektiği için karmaşıklık ciddi biçimde artar. Çoğu küçük ve orta ölçekli mağaza için hazır veya klasik bir e-ticaret altyapısı daha mantıklıdır.
Özetle
Headless CMS güçlü bir araçtır ama her projenin çözümü değildir. İçeriği birden fazla kanala dağıtan, ön yüzü bir uygulama gibi çalışan ve bunu yönetecek ekibi olan projelerde gerçek avantaj sağlar. Tek bir kurumsal site için ise çoğu zaman çözdüğünden fazla iş yaratır. Kararı popüler terimlere değil, içeriğinizin nerede ve nasıl kullanılacağına göre verin.
Nexova Studio olarak web geliştirme projelerinde klasik, hibrit ve headless yapılarla çalışıyor; mimariyi projenin gerçek ihtiyacına göre öneriyoruz. Projeniz için hangi yapının mantıklı olduğunu konuşmak isterseniz bize yazın.
