Yazılımcı Olmayanlar İçin Headless CMS

"Headless", hangi ürünü satın aldığınızı değil sunumun nerede yaşadığını anlatıyor. Bir içerik yönetim sistemi normalde iki iş yapıyor: içeriğinizi saklıyor ve sayfalarınızı çiziyor. Headless, birincisini koruyup ikincisinden vazgeçmesi demek — CMS isteklere yapılandırılmış veriyle yanıt veriyor, ayrı bir ön yüz de o verinin neye benzeyeceğine karar veriyor.

Bu çerçevenin işe yarar sonucu şu: hiçbir şey satın almanız gerekmeyebilir. WordPress'in çekirdeğinde zaten bir REST API var. Yani asıl karar hangi headless CMS'i alacağınız değil; bu takası isteyip istemediğiniz.

Muhtemelen zaten bir taneniz var

WordPress'in REST API dokümantasyonu onu "uygulamaların JSON nesneleri gönderip alarak WordPress sitenizle etkileşmesi için bir arayüz" diye tanımlıyor ve "WordPress Blok Düzenleyici'nin temeli" olduğunu belirtiyor — yani bir eklenti değil, düzenleyicinin kendisinin üzerinde çalıştığı şey.

Neyi mümkün kıldığını da sayıyor: "yepyeni bir etkileşimli ön yüz deneyimi kurmak" ve "WordPress içeriğinizi tamamen ayrı uygulamalara taşımak" dâhil.

Headless bu. Ekibiniz zaten WordPress biliyorsa ve editörleriniz zaten onun içinde çalışıyorsa, headless çalıştırmak kullandıkları yarıyı koruyup kullanmadıkları yarıyı değiştiriyor. Bunun amaca özel bir headless üründen iyi olup olmadığı, pazarlamaya değil içerik modelinize bağlı.

Gerçekte neyden vazgeçiyorsunuz

Kategorinin üstünden atladığı kısım bu ve maliyetin tamamı da bu.

Önizleme. Normal bir CMS'te editör Önizle'ye basıyor ve sayfayı görüyor. Headless'ta CMS'in sayfanın neye benzediğine dair hiçbir fikri yok — önizlemenin kurulması gerekiyor ve bu, genelde yayından sonra keşfedilen gerçek bir iş.

Düzen kontrolü. Bloklar, sayfa kurucular, sürükle-bırak bölümler: hepsi head'di. Headless kurulum editörlere alanlar ve ön yüzün desteklemek üzere kurulduğu düzeni veriyor. Sayfayı yeniden düzenleyebilen editör artık talep açıyor.

Ön yüz işi yapan eklentiler. Form eklentisi, galeri, çerez bandı, meta etiket üreten bir SEO eklentisi — hiçbiri artık ön yüze ulaşmıyor. Her biri geliştiricilerinizin kuracağı ya da entegre edeceği bir şeye dönüşüyor.

Sitenin var olduğu tek yer. İki sistem, iki dağıtım, iki takım erişim bilgisi ve bozulabilecek iki şey demek. Yönetilebilir ve ücretsiz değil.

Bunların hiçbiri headless'a karşı sav değil. Bunlar fatura; imzadan sonra değil önce okunmalı.

Gerçekte ne kazanıyorsunuz

Ön yüz özgürlüğü. Artık bir tema sisteminin içinde inşa etmiyorsunuz. Alışılmadık etkileşimi olan ya da uygulama gibi hissetmesi gereken bir site için savın tamamı bu.

İçeriğin yeniden kullanımı. Aynı içerik kopyalanmadan bir web sitesini, bir mobil uygulamayı, mağaza içi bir ekranı ve bir iş ortağı beslemesini besleyebiliyor. Birden fazla yüzeyi olan bir kurum için bu estetik değil yapısal — ve headless'a geçmenin en iyi tek sebebi.

Bağımsız değişim. Ön yüz, içerik taşınmadan yeniden kurulabiliyor; içerik de ön yüze dokunulmadan yeniden yapılandırılabiliyor. Birkaç yıl ölçeğinde bu ayrışmanın gerçek bir değeri var.

Türkiye'nin popüler sitelerinde başsız kullanımın ne kadar yaygın olduğunu, WordPress ile Next.js'i birlikte kullananlar dâhil, WordPress mi Next.js mi yazısında ölçtük.

Headless'ın aramada bozulma biçimi

Headless'ın doğuştan bir SEO dezavantajı yok. İstemci tarafı çizimin var ve ikisi karıştırılıyor; çünkü pek çok headless ön yüz varsayılan olarak istemcide çiziliyor.

Belirli hatalar belgelenmiş durumda. Google "bir bağlantıyı yalnızca href niteliği olan bir <a> HTML öğesiyse tarayabileceğini" söylüyor ve gezinme için diğer öğelerde JavaScript olayları kullanılmamasını öneriyor — bağlantı en iyi uygulamaları. Yapay zekâ özellikleri içinse sayfanın "dizine eklenmiş ve Google Arama'da snippet ile gösterilmeye uygun" olması gerekiyor; bunu yapay zekânın alıntılayabileceği içerik yazısında ele aldık.

Sizi beladan uzak tutan kural basit: içerik, sunucunun döndürdüğü HTML'de olmalı. Sunucuda çizilen ya da statik üretilen bir headless ön yüz bunu karşılıyor ve başka her site gibi davranıyor. İstemcide çizilen ise ziyaret eden her tarayıcı, asistan ve okuma modu aracı üzerine bir bahis.

Bu gerçekte kimin için

Headless'a geçin, eğer: aynı içeriği birden fazla yüzey tüketiyorsa; bakımını üstlenecek ön yüz geliştiricileriniz varsa; arayüz gerçekten özelse; ya da zaten bunun doğal olduğu bir yığındaysanız.

Geçmeyin, eğer: tek bir web siteniz, bir iki editörünüz, çağrılacak geliştiriciniz yoksa ve sayfaları yardım almadan yeniden düzenlemeniz gerekiyorsa. Bu durum çoğu küçük işletme sitesini tarif ediyor ve onlar için headless para götürüp hiçbir şey getirmiyor — karar çerçevesi özel kodlama mı WordPress mi ile aynı.

Meseleyi bitiren soru teknik değil: sayfayı kim, ne sıklıkla değiştiriyor? Cevap "geliştirici olmayan biri, haftalık" ise kaldırdığınız head, onun kullandığı şey.

Nerede hayır diyoruz

Tanıtım sitesi için headless önermiyoruz. Çözülmüş bir sorunu bakımı yapılan bir soruna çeviriyor.

Bulunması gereken içerik için istemcide çizilen bir ön yüz yayınlamıyoruz. Bu alanda güvenilir biçimde trafik kaybettiren tek mimari tercih ve emekle değil varsayılanla kaçınılabiliyor.

Ve headless'ı bir performans yükseltmesi olarak sunmuyoruz. İyi kurulmuş geleneksel bir siteyle iyi kurulmuş bir headless site aynı yere iniyor; fark, ekibin sonrasında ne yapabildiğinde — web sitesi yapımı rehberimizde ele aldığımız gibi.

Bağlanmadan önce beş soru

1. Bu içeriği kaç yüzey tüketiyor? Bir tane uyarı işareti.
2. Sayfayı kim, ne sıklıkla yeniden düzenliyor? Editörse ve haftalıksa, aracını elinden alıyorsunuz.
3. Önizlemeyi kim kurup sürdürecek? Dâhil değil ve editörler hemen fark ediyor.
4. Ön yüz sunucuda mı çiziliyor? Değilse içerik güvenilir biçimde taranabilir olmayabilir.
5. Formlara, banda ve SEO çıktısına ne olacak? Her biri eklentiydi, artık bir yapım kalemi.

Bunun soyut olarak değil kendi içeriğinize ve ekibinize karşı değerlendirilmesini isterseniz, siteyi kimin düzenlediğini bize anlatın — ya da iki mimariyi de nasıl kapsamlandırdığımızı web sitesi yapımı sayfasında görün.