Headless CMS Karşılaştırması 2026: Payload, Sanity, Strapi

Müşterilerden 2026’da en sık duyduğumuz cümlelerden biri şu: “WordPress’ten sıkıldık, headless’a geçelim diyorlar, ama hangisine?” Haklı bir soru. Çünkü “headless CMS” tek bir ürün değil; birbirinden çok farklı felsefelere sahip onlarca sistemin ortak adı.

Bu yazıda pazarın dört güçlü oyuncusunu karşılaştırıyoruz: Payload, Sanity, Strapi ve Decap. Hepsini gerçek müşteri projelerinde kullandık; hangisinin hangi senaryoda para ve zaman kazandırdığını biliyoruz.

Hızlı özet: 2026’da dört güçlü headless CMS öne çıkıyor: Payload (self-host, Next.js ile aynı repoda), Sanity (SaaS, gerçek zamanlı editör), Strapi (self-host, geniş plugin ekosistemi) ve Decap (Git tabanlı, ücretsiz). Kurumsal ve çok dilli projelerde Payload veya Sanity, küçük statik sitelerde Decap ya da doğrudan Markdown + Git daha mantıklı.

Headless CMS Nedir, Neden Tercih Ediliyor?

Headless CMS, içerik yönetimini site tasarımından ayıran sistemdir: içerik bir panelde yönetilir, API üzerinden ön yüze servis edilir. WordPress gibi klasik CMS’lerde içerik ve tasarım aynı pakettedir; headless’ta ise ön yüz tamamen size aittir.

Karar verici gözüyle bu ayrımın üç somut karşılığı var:

1. Hız. Ön yüz Next.js veya Astro ile statik/hibrit kurulduğunda Lighthouse 95+ ve LCP <1.5s rutin hedeftir. Klasik WordPress kurulumlarında bu değerlere ulaşmak eklenti savaşı gerektirir.
2. Güvenlik. Panel ile yayınlanan site ayrı katmanlarda yaşar. Ziyaretçinin gördüğü sayfalarda çalışan bir “admin” yüzeyi yoktur; saldırı alanı küçülür.
3. Çok kanallılık. Aynı içerik hem web sitesine hem mobil uygulamaya hem de üçüncü parti sistemlere tek API’den gider. İçeriği bir kez girer, her yerde kullanırsınız.

Bedeli de var: iki ayrı katman (CMS + ön yüz) demek, kurulumda daha fazla mühendislik demek. WordPress’te “tema kur, yayınla” olan iş burada bir yazılım projesidir. Bu yüzden headless kararı bir moda kararı değil, ihtiyaç kararı olmalı. WordPress’ten ayrılmayı düşünüyorsanız önce WordPress yerine ne kullanmalı yazımızdaki karar ağacına bakın.

Payload, Sanity, Strapi, Decap: Hangisi Nerede Duruyor?

Kısa cevap: Payload ve Strapi self-host (kendi sunucunuzda), Sanity SaaS (bulut hizmeti), Decap ise Git tabanlı bir ara türdür. Fiyat, veri sahipliği ve editör deneyimi bu temel ayrımdan doğrudan etkilenir.

Tabloyu tek cümleyle özetlersek: veri sahipliği ve sıfır lisans maliyeti istiyorsanız Payload, kurulum derdi istemiyorsanız Sanity, mevcut ekip Node.js API alışkanlığıyla çalışıyorsa Strapi, site küçük ve statikse Decap.

Payload CMS: Next.js’in içinde yaşayan CMS

Payload’ın 2026’daki en büyük kozu mimari: Payload 3.x doğrudan Next.js projesinin içine kuruluyor. Ayrı CMS sunucusu, ayrı deploy süreci, ayrı domain yok. İçerik şemasını TypeScript ile kod olarak tanımlıyorsunuz; admin paneli, API ve tip tanımları otomatik üretiliyor.

Bizim için kritik olan iki özellik daha var. Birincisi, alan bazlı yerelleştirme: tr/en/ar içerikleri aynı kayıtta, sekme değiştirerek yönetiliyor. İkincisi, erişim kontrolü fonksiyon olarak yazılıyor; “bu alanı sadece editör görsün” gibi kurallar kodda net duruyor. Karşılığında ödediğiniz bedel, kurulumun bir geliştirici gerektirmesi. Payload “indir-kur-çalıştır” değil, “projene göre modelle” felsefesinde.

Sanity: editör deneyiminde çıta

Sanity bir SaaS: içerik Sanity’nin bulutunda durur, siz Studio adlı editör arayüzünü kendi projenize göre özelleştirirsiniz. Gerçek zamanlı ortak düzenleme (iki editör aynı belgede aynı anda), taslak önizleme ve görsel kırpma gibi editör tarafı özelliklerde hâlâ en akıcı sistem.

Dikkat edilmesi gereken nokta fiyat eğrisi. Ücretsiz katman küçük ekipler için cömert; ama kullanıcı sayısı, API isteği ve bant genişliği büyüdükçe fatura kullanım bazlı tırmanır. Trafiği yüksek, API’ye sık vuran projelerde bu kalemi baştan modellemek gerekir. Bir de veri sahipliği konusu: içeriğiniz Sanity’nin altyapısında yaşar. Export her zaman mümkün, ama “verim kendi sunucumda dursun” diyen kurumlar için bu bir eksi.

Strapi: ekosistemi geniş, işletmesi sizde

Strapi en eski ve en bilinen açık kaynak headless CMS’lerden. Node.js üzerinde ayrı bir uygulama olarak çalışır; REST ve GraphQL API’yi kutudan verir, plugin pazarı geniştir. Framework bağımsızdır: ön yüz Next.js de olabilir, Vue da, mobil uygulama da.

Zayıf noktaları da net. Ayrı bir sunucu uygulaması olduğu için işletme yükü (güncelleme, yedek, ölçekleme) size aittir ve major sürüm geçişleri zaman zaman sancılıdır. Çoklu dil, i18n eklentisiyle kayıt bazında kopya mantığıyla çalışır; Türkçe-İngilizce senkronunu editörün disiplinine bırakır. Yine de halihazırda Strapi bilen bir ekibiniz varsa bu bilinen bir yol, kötü bir yol değil.

Decap: Git tabanlı minimalizm

Decap (eski adıyla Netlify CMS) diğer üçünden farklı bir tür: veritabanı yok. İçerik, Git reposundaki Markdown dosyalarıdır; Decap bunların üzerine web tabanlı bir düzenleme paneli koyar. Editör “Kaydet” dediğinde aslında bir Git commit’i atılır.

Bu model küçük siteler için şaşırtıcı derecede iyidir: sıfır maliyet, sıfır sunucu, sürüm geçmişi bedava. Sınırları da modelinden gelir: ilişkisel içerik (ürün-kategori-varyant gibi), medya yönetimi ve ikiden fazla dil Decap’te hızla yorucu olur. Blog + birkaç sabit sayfa olan bir Astro sitesi için ideal; e-ticaret veya kurumsal portal için değil.

Hangi Senaryoda Hangisini Seçmelisiniz?

Doğru seçim projenin büyüklüğünden çok, içeriği kimin, ne sıklıkla girdiğine bağlıdır. 90+ projede gördüğümüz desen şu:

• Çok dilli kurumsal site, veri kendi sunucumuzda kalsın: Payload. Alan bazlı tr/en/ar yönetimi ve tek repo/tek deploy avantajı burada belirleyici.
• İçerik ekibi kalabalık, editör konforu birinci öncelik: Sanity. Gerçek zamanlı düzenleme ve önizleme akışı içerik üretim hızını gözle görülür artırıyor.
• Ekip zaten Node.js API geliştiriyor, ön yüz belirsiz veya birden fazla: Strapi. Framework bağımsızlığı ve hazır plugin’ler işi hızlandırır.
• Küçük statik site, içeriği ayda birkaç kez teknik olmayan biri güncelleyecek: Decap. Maliyet sıfır, bakım neredeyse sıfır.
• İçerik + sipariş + entegrasyon iç içe (ERP, e-fatura, kargo): Payload veya Strapi gibi self-host bir sistem + özel API katmanı. Bu tür kurulumlar bizim yazılım ve entegrasyon tarafımızın en sık çalıştığı senaryo.

Bir uyarı: “en popüler olanı seçelim” refleksi headless dünyasında pahalıya patlar. Popülerlik sıralaması ile projenize uygunluk sıralaması nadiren aynıdır.

Next.js ve Astro ile Nasıl Eşleşiyorlar?

Kısa cevap: Payload, Next.js ile “aynı proje” olacak kadar iç içedir; Sanity ve Strapi her iki framework’e API ile temiz bağlanır; Decap ise doğal olarak Astro’nun content collections yapısına oturur.

Biraz açalım. Next.js tarafında Payload 3.x fiilen bir Next.js paketi gibi davranır: admin paneli /admin route’unda, içerik sorguları ise Local API ile ağ gecikmesi olmadan çalışır. ISR ve on-demand revalidation ile “editör kaydetti, sayfa saniyeler içinde güncellendi” akışı kurulur. Next.js’in karar verici açısından ne anlama geldiğini Next.js ile web sitesi yaptırmak yazısında ayrıntılı anlattık.

Astro tarafında ise denklem farklı: Astro içerik ağırlıklı, çoğunlukla statik sitelerde parlar. Sanity’nin resmi Astro entegrasyonu olgun; build sırasında içerik çekilir, site statik çıkar. Decap zaten Markdown ürettiği için Astro’nun yerel içerik sistemiyle kelimenin tam anlamıyla sıfır ek katmanla çalışır. Kendi sitemiz abdullahustun.com da WordPress’ten Astro 5’e taşınmış canlı bir örnek; içerik Markdown’da duruyor ve bu sadeliğin bakım maliyetine etkisini her ay hissediyoruz.

Markdown + Git Yeter mi? Küçük Siteler İçin Dürüst Cevap

Çoğu küçük site için: evet, yeter. Hatta daha iyidir. İçeriği yılda 10-20 kez ve çoğunlukla geliştirici güncelliyorsa, araya bir CMS koymak çözüm değil, masraftır: bir panel daha, bir bağımlılık daha, bir güncelleme yükü daha.

Markdown + Git modelinde içerik repodadır; her değişiklik commit’tir, geri almak git revert kadar basittir. Astro content collections ile şema doğrulaması bile bedavaya gelir. Bu yazıyı okuduğunuz blog tam olarak böyle çalışıyor.

CMS’in gerçekten gerekli olduğu eşik bellidir ve bizce şu üç sorudan en az ikisine “evet” demenizdir:

1. İçeriği teknik olmayan biri, haftalık veya daha sık mı girecek?
2. İçerik türleri arasında ilişki var mı (ürün-kategori, doktor-branş-hizmet gibi)?
3. Aynı içerik web dışında bir kanala da (mobil uygulama, ekran, üçüncü parti API) gidecek mi?

Üçüne de “hayır” diyorsanız, kimse size headless CMS satmasın. Markdown ile başlayın; ihtiyaç doğduğunda içerik zaten yapılandırılmış olduğu için Payload veya Sanity’ye geçiş sanıldığından kolaydır.

90+ Projeden Pratik Notlar

Karşılaştırma tabloları güzel ama sahada karar değiştiren detaylar genelde tablolara girmeyenler oluyor. Bizim projelerde tekrar tekrar karşımıza çıkanlar:

• Editör eğitimini plana koyun. En iyi CMS, editörün kullanmadığı CMS değildir. Payload ve Sanity panellerinde bile 1 saatlik kayıtlı bir eğitim videosu, ilk üç aydaki destek taleplerini ciddi azaltıyor.
• Türkçe karakter ve slug üretimini ilk gün test edin. “ı/İ” dönüşümü, slug’larda “ş/ç/ğ” temizliği her sistemde farklı davranır. Canlıya çıktıktan sonra URL değiştirmek SEO’da 301 zinciri demektir.
• Çoklu dilde “kayıt kopyalama” modeline dikkat. Kayıt bazlı i18n’de (Strapi tarzı) İngilizce sayfa güncellenip Türkçesi unutulan içerik, altı ay içinde mutlaka ortaya çıkıyor. Alan bazlı model bu hatayı yapısal olarak engelliyor.
• SaaS’ta faturayı trafiğe göre modelleyin. Sanity benzeri kullanım bazlı sistemlerde ISR/önbellek katmanı kurmadan her sayfa isteğini API’ye yollarsanız, fatura sürpriz yapar. Önbellek stratejisi baştan tasarlanmalı.
• Yedeği CMS’e emanet etmeyin. Self-host kurulumlarda veritabanı + medya klasörünün otomatik, siteden bağımsız yedeği ilk sprint’te kurulmalı. “Yedek vardır herhalde” cümlesini duyduğumuz her projede yedek yoktu.
• Migration’ı içerik temizliği fırsatı sayın. WordPress’ten headless’a taşınan sitelerde içeriğin genelde %20-30’u artık işe yaramayan sayfalardır. Taşımadan önce ayıklamak hem maliyeti hem karmaşayı düşürür.

Karar Aşamasındaysanız

Headless CMS seçimi bir kere verilen ve yıllarca yaşanan bir karar: yanlış seçim, iki yıl sonra ikinci bir migration faturası demek. Projenizin içerik akışına, ekibinize ve bütçenize göre doğru sistemi birlikte seçmek isterseniz web tasarım hizmetimize göz atabilir veya iletişim sayfasından ücretsiz 30 dakikalık görüşme planlayabilirsiniz. Hangi CMS’in size uyduğunu, satış diliyle değil, kendi projenizin gerçekleriyle konuşuruz.