WordPress'ten headless CMS'e geçmeli miyiz? Karar ölçütleri ve gizli maliyetler

Headless CMS'e geçmek bir yükseltme değil, bir takastır. İçeriği tek bir yerde tutup web sitesi, mobil uygulama, mağaza ekranı ve iş ortağı beslemesi gibi birden çok yüzeye aynı kaynaktan servis etme imkânı kazanırsınız. Karşılığında klasik CMS'in kutudan verdiği URL yönetimi, yönlendirme, site haritası, önizleme, form, arama ve görsel işleme gibi işleri kendi ekibinizin yazmasını üstlenirsiniz. Tek bir kurumsal siteniz, içeriği kendi güncelleyen bir pazarlama ekibiniz ve kalıcı bir geliştirici kaynağınız yoksa bu takas size zarar yazar. İçerik birden fazla yüzeyde tekrar kullanılıyorsa, ön yüzü zaten bir ekip geliştiriyorsa ve içeriğiniz sayfadan çok kayıt gibi davranıyorsa takas mantıklı hale gelir.

Piyasa dengesi de kararın bir parçası. W3Techs'in 20 Eylül 2026 tarihli verisine göre WordPress, içerik yönetim sistemi bilinen sitelerin %58,8'inde, tüm web sitelerinin %40,2'sinde çalışıyor. Klasik CMS tarafı da yerinde saymıyor: Drupal, 15 Ocak 2025'te pazarlama ekipleri için kurulumdan hazır gelen Drupal CMS 1.0'ı yayımladı. Yani soru "hangisi daha modern" değil. Soru şu: sizin yayın akışınız hangisine benziyor?

Headless ne demek, ne demek değil

Klasik bir CMS'te içerik deposu, yönetim paneli ve sayfayı üreten şablon motoru aynı uygulamanın parçalarıdır. Headless mimaride bu paket ikiye ayrılır. CMS yalnızca içeriği saklar ve API üzerinden verir; sayfayı üreten ön yüz ayrı bir uygulamadır. Birinci sonuç herkesin bildiği kısım: aynı içeriğe farklı istemcilerden erişebilirsiniz. İkinci sonuç genelde geç fark ediliyor: artık CMS'in içinde "sayfa" diye bir şey yoktur. Sayfayı ön yüz kurar, dolayısıyla sayfaya ait ne varsa ön yüzün sorumluluğuna geçer.

Arada duran bir seçenek daha var. Mevcut CMS'inizi yerinde bırakıp yalnızca API'sini kullanabilirsiniz. Buna decoupled ya da headless WordPress deniyor. WordPress'te REST API çekirdekte hazır gelir, GraphQL tercih eden ekipler WPGraphQL eklentisini kurar. Editörlerin alışkanlıkları bozulmaz, ön yüz özgürleşir. Bu ara yol, tam geçişe göre çok daha az risk taşıdığı için genellikle ilk denenmesi gereken seçenektir.

Headless'ın karşılığını verdiği dört durum

• İçerik birden fazla yüzeyde gösteriliyor. Site, mobil uygulama, saha ekibinin kullandığı panel, bayi portalı ve iş ortağına giden veri beslemesi aynı ürün açıklamasını kullanıyorsa, o açıklamayı bir şablonun içine gömmek maliyetli bir hatadır.
• İçerik sayfa değil, kayıt. Ürün, şube, etkinlik, personel, fiyat listesi gibi yapılandırılmış kayıtlar alan alan modellenip sıralanabilir, filtrelenebilir ve yeniden kullanılabilir olduğunda değer kazanır. Zengin metin editörüne gömülmüş bir tablo bunu yapamaz.
• Ön yüzü zaten bir ekip geliştiriyor. Bir tasarım sisteminiz, bileşen kütüphaneniz ve bunu sürdüren geliştiricileriniz varsa CMS'in şablon motoru size yardım etmiyor, ayak bağı oluyordur.
• Birden çok pazar ve dil var. Ortak bir içerik modeli üzerinden yürüyen çok dilli yapı, her dil için ayrı kurulum yönetmekten belirgin biçimde ucuzdur. URL yapısı ve hreflang tarafındaki ayrıntıları çok dilli site mimarisi yazımızda ele almıştık.

Tersi de aynı derecede net. Tek bir kurumsal site, kampanya sayfalarını pazarlama ekibinin kendi kurduğu bir düzen ve yılda birkaç kez devreye giren bir ajans varsa headless geçişi işleri yavaşlatır. İçerik düzenlemesi elbette yine panelden yapılır, orada sorun yok. Ama yeni bir sayfa tipi, yeni bir bölüm düzeni ya da alışılmadık bir kampanya sayfası artık geliştirici işidir. Klasik CMS'te bunu pazarlama ekibi kendisi yapıyordu.

Klasik CMS'in bedava verdiği, headless'ta yazacağınız işler

Headless projelerinin bütçesi çoğunlukla burada aşılır. Aşağıdakilerin hepsi klasik CMS'te kurulumla birlikte gelir ve headless kurulumda tek tek yapılacak iş kalemidir:

• URL ve yönlendirme yönetimi. Editör bir başlığı değiştirdiğinde adres değişir. Eski adresin 404 vermemesi için yönlendirme tablosunu birinin tutması gerekir. Bu tablo CMS'te mi, ön yüzte mi, CDN'de mi duracak? Cevabı ilk günde verin, çünkü yenileme sonrası trafik kayıplarının çoğu bu tablonun eksik olmasından çıkıyor. Ayrıntısı site yenileme ve taşımada SEO yazımızda.
• Site haritası, canonical etiketi, hreflang ve robots kuralları. Hiçbiri kendiliğinden oluşmaz.
• Yapılandırılmış veri. schema.org işaretlemesini ön yüz üretir; arama ve cevap motorlarındaki görünürlük buna bağlı. Konuyu yapay zeka aramada görünürlük yazımızda açmıştık.
• Görsel işleme. Boyutlandırma, format dönüşümü ve duyarlı görsel üretimi. Bunu çözmeden Core Web Vitals tarafında iyi bir sonuç almak zor.
• Form, site içi arama ve yorum. Üçü de ayrı servis ya da ayrı geliştirme demek. Arama tarafının göründüğünden zor olduğunu site içi arama yazımızda anlatmıştık.
• Alan bazında yetki. Bir editör fiyat alanını değiştirebilmeli mi, yayın onayını kim veriyor? Klasik CMS'lerin rol modeli olgunlaşmış durumda; headless tarafında bu genelde yapılandırma işi. Modeller için yetkilendirme yazımıza bakabilirsiniz.
• Önbellek geçersiz kılma. Yayınla düğmesine basıldıktan kaç saniye sonra sayfa değişiyor? Statik üretim kullanıyorsanız cevap "yeniden derleme bitince" olabilir ve bu editör için kabul edilemez bir süre olabilir. Katmanların nasıl kurgulandığını önbellek stratejisi yazımızda ele aldık.

Bu maddelerin hiçbiri tek başına zor değil. Hepsi birlikte, ilk sürüm tahminine sonradan eklenen bir ay demek.

Önizlemeyi çözmezseniz sistem kullanılmaz

Editör, yayımlamadan önce sayfayı görmek ister. Headless CMS sayfa üretmediği için bunu tek başına yapamaz. Önizleme, ön yüzün taslak içeriği çekip render ettiği ayrı bir yol olarak kurulur ve üç şartı sağlamak zorundadır. Taslak halini göstermeli, yayındaki önbelleği atlamalı ve sayfanın gerçek halini vermeli. Başlık etiketini, görselleri ve mobil görünümü gizleyen bir önizleme editörü kör yayına zorlar.

Bunu ilk sprintte çözün, üçüncü ayda değil. Kabul ölçütü tek cümleyle yazılabilir: editör taslak bir yazıyı açar, başlığı değiştirir, önizleme adresinde değişikliği birkaç saniye içinde görür ve o adres dışarıdan erişilebilir değildir. Son şart önemli, çünkü kimlik doğrulaması olmayan bir önizleme uç noktası yayımlanmamış içeriği, fiyat değişikliklerini ve duyuru taslaklarını herkese açık hale getirir. Bu tür sızıntılar genellikle arama motorunun taslak adresi indekslemesiyle fark ediliyor.

Güvenlik tarafı: risk kaybolmaz, yer değiştirir

Eklenti ekosisteminin taşıdığı yük gerçek. Patchstack'in 2026 raporuna göre WordPress ekosisteminde 2025 yılında 11.334 yeni zafiyet kayda geçti, bir önceki yıla göre %42 artış. Bunların %91'i eklentilerde, %9'u temalarda; çekirdekte yalnızca 6 zafiyet bildirildi ve hepsi düşük öncelikliydi. Rapordaki iki rakam daha doğrudan işletme riskine işaret ediyor: zafiyetlerin %46'sı açıklandığı anda yamasızdı ve en yoğun hedeflenen zafiyetlerde ilk istismara kadar geçen ağırlıklı medyan süre 5 saat.

Çekirdek de dokunulmaz değil. Temmuz 2026'da açıklanan ve wp2shell adı verilen zincir, WordPress çekirdeğindeki iki hatayı (CVE-2026-63030 ve CVE-2026-60137) birleştirerek hiç eklenti kurulmamış bir sitede bile kimliği doğrulanmamış kod çalıştırmaya izin veriyordu. Yamalar 18 Temmuz 2026'da yayımlandı.

Buradan "headless daha güvenlidir" sonucu çıkmıyor. Risk azalmıyor, taşınıyor. Yönetim paneliniz hâlâ internete bakan bir uygulama. API anahtarlarınız artık içeriğin tamamına erişen tek anahtar. Derleme hattınız üretim ortamının parçası haline geliyor, dolayısıyla hattaki bir bağımlılık da öyle. Strapi, Payload ya da Directus gibi kendi sunucunuzda çalışan bir sistem seçtiyseniz Node bağımlılıklarını yamalama işi de sizin. Kısacası eklenti yaması yükünden kurtulup bağımlılık yaması yüküne geçiyorsunuz. İkisinin de disiplini aynı: yama ve zafiyet yönetimi ile yazılım tedarik zinciri güvenliği.

Maliyet lisansta değil, uygulamada

Karşılaştırmayı lisans ücretleri üzerinden yapmak en sık görülen hata. SaaS headless sağlayıcıları genelde kullanıcı koltuğu, ortam sayısı ve API çağrısı üzerinden fiyatlandırır; ekip büyüdükçe fatura da büyür. Ama asıl kalem başka yerde. Gerçekçi bir bütçe şu satırları içerir: içerik modelinin tasarımı, ön yüz geliştirme, önizleme altyapısı, yönlendirme yönetimi, görsel işleme servisi, arama servisi, form servisi, ön yüz barındırma ve editör eğitimi.

Mevcut içeriğin taşınması ayrı bir kalem. Birkaç bin içeriği taşımak bir dışa aktarma işlemi değil; alan eşlemesi, gömülü medyanın yeniden bağlanması, eski kısa kodların temizlenmesi ve adres adres yönlendirme haritası demek. Yaklaşımı eski sistemden yeni sisteme veri taşıma yazımızda adım adım anlattık. Bu kalemleri hesaba katmadan yapılan bir karşılaştırma headless'ı olduğundan ucuz gösterir.

Bağımlılık, sahiplik ve çıkış planı

SaaS bir headless CMS seçtiğinizde içeriğiniz başkasının veritabanında durur. Bu tek başına kötü değil, ama iki sorunun cevabını sözleşme aşamasında bilmeniz gerekir. İçeriğin tamamını hangi formatta, ne kadar sürede dışarı alabilirsiniz? Sağlayıcı API'sinde kırıcı bir değişiklik yaptığında ne kadar geçiş süresi tanıyor?

Sağlayıcının kendisi de sabit değil. Figma, açık kaynak headless CMS Payload'ın ekibini 17 Haziran 2025'te bünyesine kattığını duyurdu ve ürünün açık kaynak kalacağını belirtti. Satın almalar her zaman kötü sonuçlanmaz, ama bir aracın sahibi değiştiğinde yol haritası da değişebilir. Kendi sunucunuzda çalışan açık kaynak bir CMS bu riski azaltır, karşılığında işletme ve yama yükünü size verir. Hangi tarafı seçerseniz seçin, kararı alırken içeriğin dışa aktarma yolunu bir kez deneyin. Denenmemiş çıkış planı, plan sayılmaz.

Karar için altı soru

1. İçerik kaç yüzeyde gösteriliyor? Cevap "bir web sitesi" ise klasik CMS büyük ihtimalle doğru karar.
2. Ön yüze önümüzdeki üç yıl kim bakacak? Kalıcı bir geliştirici kaynağı yoksa headless bir teknik borçtur.
3. Pazarlama ekibi yeni bir açılış sayfasını kendi kurabilmeli mi? Evetse ya sayfa oluşturucusu olan bir klasik CMS seçin ya da headless tarafında blok tabanlı bir içerik modeli kurmayı baştan bütçeleyin.
4. İçeriğiniz sayfa mı, kayıt mı? Ürün, şube, etkinlik gibi yapılandırılmış kayıtlar headless lehine çalışır.
5. Kaç dil ve kaç pazar var? İki dili aştığınızda ortak içerik modeli ciddi bir avantaj sağlar.
6. Çıkış yolunuz ne? İçeriği dışarı almanın yolunu ve süresini bilmiyorsanız karar henüz tamamlanmamıştır.

Karar vermeden önce yapılabilecek en ucuz iş, içerik ekibinin bir hafta boyunca gerçekte ne yaptığını izlemek. Kaç kez yeni sayfa kurdular, kaç kez mevcut metni düzelttiler, kaç kez geliştiriciye ihtiyaç duydular, kaç adres değişti. Bu dört sayı, çoğu şirkette kararı sağlayıcı karşılaştırma tablolarından daha net veriyor. Wedevit olarak içerik altyapısı kararlarında mevcut yayın akışınızı ölçüyor, headless ile klasik CMS arasındaki farkı sizin sayılarınızla maliyetlendiriyor ve geçişe karar verilirse içerik modelini, önizlemeyi ve yönlendirme haritasını kuruyoruz. Tüm çalışma uzaktan yürür.