WordPress mi, özel yazılım mı, headless CMS mi? Altyapıyı doğru seçmek

Masanızda üç teklif var. Biri "WordPress ile iki ayda bitiririz" diyor, biri "size özel yazalım, her şey tam istediğiniz gibi olsun", üçüncüsü Next.js'ten, headless CMS'ten ve göz açıp kapayıncaya kadar açılan sayfalardan söz ediyor. Üçü de kendinden emin, üçü de diğer ikisinin neden yanlış olduğunu tek cümleyle anlatabiliyor. Siz de farkında olmadan hangi altyapının işinize uyduğunu değil, hangi satıcının daha ikna edici konuştuğunu tartmaya başlıyorsunuz.

Bu yazıda üç yolu satıcı gözüyle değil, siteyi beş yıl kullanacak işletmenin gözüyle karşılaştırıyoruz: içerik ekibinin günlük işi, eklentiler ve güvenlik, hız, çok dillilik, entegrasyonlar, barındırma ve bakım, toplam sahip olma maliyetinin kalemleri ve bir gün vazgeçmek isterseniz yaşayacağınız geçiş. Sonda bir karar tablosu ve nereden başlayacağınıza dair kısa bir liste bulacaksınız.

Üç seçenek aslında ne anlama geliyor?

WordPress, içeriği yönettiğiniz paneli ve ziyaretçinin gördüğü sayfaları tek bir uygulamada birleştirir. PHP ve MySQL (ya da MariaDB) üzerinde çalışır; sayfalar seçtiğiniz temayla sunucuda üretilir, eksik kalan her işlev için bir eklenti kurulur. Burada kastettiğimiz, kendi sunucunuza kurduğunuz açık kaynak WordPress. WordPress.com ise aynı yazılımın kendi kuralları olan barındırılan sürümüdür.

Headless CMS'te bu iki parça ayrılır. İçerik bir panelde girilir ve bir API üzerinden dağıtılır; sitenin kendisi ayrı bir ön yüz uygulamasıdır ve çoğu zaman Astro ya da Next.js gibi bir çatıyla yazılır. Headless sistemler kabaca iki gruba ayrılır: Contentful gibi tamamen bulutta çalışan ticari hizmetler ve Strapi ya da Payload gibi kendi sunucunuza kurabildiğiniz açık kaynak sistemler. Sanity ikisinin arasında durur: düzenleme arayüzü Sanity Studio açık kaynaktır, içerik ise Sanity'nin barındırdığı veri deposunda tutulur.

Özel yazılımda veri modeli, yönetim paneli, yetkiler ve iş kuralları sizin için yazılır. Sıfırdan başlanmaz; Laravel, Django ya da Node.js tabanlı bir çatı kullanılır. Fark şurada: özel yazılımın hazır sistemlerdeki sınırları yoktur, ama hazır bir sistemin sunduğu hiçbir şey de kendiliğinden gelmez.

Bir de karma yollar var. WordPress'i yalnızca içerik paneli olarak kullanıp REST API ya da WPGraphQL eklentisiyle ayrı bir ön yüze bağlamak mümkün. Özel yazılmış bir bayi portalının yanında pazarlama sayfaları için headless bir CMS çalıştırmak da sık rastladığımız bir düzen. Kararı çoğu zaman "hangisi" sorusu değil, "hangi parça için hangisi" sorusu belirliyor.

İçerik ekibinizin günlük işi nasıl değişir?

Siteyi her gün kullanacak olan büyük ihtimalle siz değilsiniz; pazarlama uzmanınız, ürün sorumlunuz, belki de yeni başlamış bir stajyer. Altyapı kararının en çok hissedildiği yer onların ekranıdır.

WordPress'in blok düzenleyicisi tanıdık bir deneyim sunar. Yazarken sayfanın son hâline yakın bir görüntü görürsünüz, önizleme tek tıktır, Yönetici, Editör, Yazar ve Katılımcı gibi hazır roller vardır. Sorun genellikle özgürlüğün fazlasından çıkar: sayfa oluşturucu eklentilerle her editör kendi tasarımını yapmaya başladığında, bir yıl sonra sitede birbirine benzemeyen otuz sayfa olur.

Headless CMS'te içerik önceden tanımlanmış alanlara girilir: başlık, özet, görsel, ürün kodu, ilgili hizmetler. Tasarım ön yüzde sabittir, editör onu bozamaz. Bu tutarlılık büyük bir kazanç, ama bir bedeli var: "yazdığımı sayfada görmek istiyorum" isteği ek kurulum gerektirir. Next.js'in Draft Mode özelliği ya da Sanity'nin görsel düzenleme araçları bunu çözer, yeter ki projenin başında planlansın.

Özel yazılımda panel neyse odur; ne yazıldıysa o vardır. İyi tasarlanmış bir özel panel ekibinizin iş akışına WordPress'ten daha iyi oturabilir. Öte yandan her yeni alan, her yeni sayfa tipi bir geliştirme talebi demektir. Haftada iki duyuru yayımlayan bir ekip için bu sürtünme kısa sürede can sıkıcı hâle gelir.

Örneğin iki dilde katalog tutan, ayda birkaç haber yayımlayan orta ölçekli bir makine üreticisi düşünün. Ürün sayfaları yapılandırılmış veridir: ölçüler, belgeler, uyumlu parçalar. Haberler ise serbest metindir. Böyle bir şirkette ürünler için alan alan tanımlanmış bir model, haberler için rahat bir editör aynı anda gerekir. Üç seçenek de bunu yapabilir; fark, ne kadar emekle ve kimin emeğiyle yaptığındadır.

Eklenti bağımlılığı ve güvenlik: risk nerede birikiyor?

WordPress çekirdeği bugün oldukça sağlam; risk çevresinde toplanıyor. WordPress güvenliği üzerine çalışan Patchstack'in 2026 başında yayımladığı yıllık rapora göre 2025'te bildirilen yeni açıkların yüzde 91'i eklentilerde, yüzde 9'u temalarda çıktı. Çekirdekte bildirilen açık sayısı altıda kaldı ve hepsi düşük öncelikliydi. Yani sorun WordPress'in kendisi değil, ona eklediğiniz her parçanın ayrı bir yazarı, ayrı bir bakım ritmi ve ayrı bir riski olması.

Kırk eklentili bir site her zaman tehlikeli değildir. Tehlikeli olan; iki yıldır güncellenmemiş bir form eklentisi, korsan kopyası indirilmiş ücretli bir tema ya da "geçici" diye kurulup unutulmuş bir yedekleme aracıdır. WordPress 5.5'ten beri eklentiler için otomatik güncelleme var. Bu, güvenlik yamalarını hızlandırır, ama bir güncellemenin siteyi bozma ihtimalini de beraberinde getirir. Düzenli yedek ve güncellemeleri izleyen bir kişi bu yüzden pazarlık konusu değildir.

Headless mimaride yönetim paneli ziyaretçinin eriştiği siteden ayrıdır. Site statik olarak üretiliyorsa, saldırganın doğrudan konuşabileceği bir veritabanı bile yoktur. Bu saldırı yüzeyini ciddi biçimde küçültür ama sıfırlamaz: API anahtarları, webhook adresleri, bulut hesaplarının yetkileri ve npm paketleri üzerinden gelen tedarik zinciri riskleri yeni ödev listenizdir.

Özel yazılımda topluluk yamaları yoktur. Kullandığınız çatının güvenlik güncellemelerini birinin takip etmesi, bağımlılıkların Dependabot ya da Renovate gibi araçlarla taranması ve yayından önce bir sızma testi yapılması gerekir. Kimse bakmıyorsa, özel yazılım en eski WordPress kurulumundan bile savunmasız olabilir.

Hangisini seçerseniz seçin, şu dört kural değişmez:

• Her yönetici hesabında iki adımlı doğrulama ve yalnızca gerektiği kadar yetki.
• Geri yüklemesi denenmiş yedekler. Yedeğin var olması, çalıştığı anlamına gelmez.
• Güncellemelerden sorumlu, adı sözleşmede yazan bir kişi ya da ekip.
• Kullanılmayan eklentilerin, hesapların ve API anahtarlarının düzenli temizliği.

Hız ve çok dillilik: altyapı neyi belirler?

İkisi de teklif sunumlarında en çok iddia edilen, en az ölçülen konular. Önce hızla başlayalım.

Hız: altyapıdan mı gelir, kurulumdan mı?

Kısa cevap: ikisinden de, ama çoğunlukla kurulumdan. Hafif bir tema, sayfa önbelleği ve bir CDN ile WordPress hızlı açılır. Ağır bir sayfa oluşturucu, on iki takip kodu ve sıkıştırılmamış görsellerle en modern çatı da yavaşlar.

Astro ve Next.js gibi çatıların farkı, hızı varsayılan hâle getirmeleridir. Astro sayfaları varsayılan olarak statik HTML üretir ve tarayıcıya yalnızca etkileşim gereken bileşenlerin JavaScript'ini gönderir; Astro buna "adalar" diyor. Next.js ise sayfa bazında statik üretim, istek anında sunucuda üretim ya da belirli aralıklarla yeniden üretim arasında seçim yapmanıza izin verir. Sayfalar önceden hazırlanıp bir CDN'den sunulduğunda, ziyaretçiyi bekleten bir veritabanı sorgusu kalmaz.

Burada da bir tuzak var. İstemci tarafında gereğinden fazla JavaScript çalıştıran headless bir site, en hantal WordPress kadar ağırlaşabilir. Teknoloji etiketi tek başına hız demek değildir; karar vermeden önce rakip tekliflerin daha önce yaptığı sitelerde ölçüm yapın. Hangi ölçülere bakmanız gerektiğini "Core Web Vitals nedir?" yazımızda anlattık.

Çok dillilik: hangi altyapı kaç dili rahat taşır?

Türkçe, İngilizce ve Almanca gibi üç dilli bir site düşünüyorsanız, bu konu kararı tek başına değiştirebilir.

WordPress çekirdeğinde çok dilli içerik yönetimi yok. Resmî yol haritasında bu, dördüncü aşama olarak "çok dilli siteler için çekirdek desteği" adıyla duruyor; bugün üzerinde çalışılan aşama ise ortak düzenleme. O gün gelene kadar WPML ya da Polylang gibi eklentilerle çalışırsınız. İşi görürler, ama her dil ayrı bir kayıt gibi davranır ve eklentinin temayla, diğer eklentilerle uyumu her güncellemede yeniden sınanır.

Headless sistemlerin çoğunda yerelleştirme içerik modelinin içindedir. Contentful'da diller ortam düzeyinde tanımlanır ve hangi alanın çevrileceğini alan alan seçersiniz. Strapi 5'te uluslararasılaştırma çekirdekle gelir, Payload'da çevrilecek alanları yapılandırmada işaretlersiniz. Ön yüzde Astro'nun yerleşik i18n yönlendirmesi var, Next.js'te de dil bazlı yönlendirme yerleşik bir kalıp. hreflang etiketlerini, dil seçiciyi ve URL yapısını ise ön yüz ekibi kurar; bunlar kendiliğinden gelmez. Körfez pazarı için Arapça gibi sağdan sola yazılan bir dil eklenecekse, bu her altyapıda ayrı bir tasarım ve ön yüz işidir.

Özel yazılımda çok dillilik, baştan veri modeline eklenmesi gereken bir karardır. Sonradan eklenen dil desteği neredeyse her tabloya dokunan bir yeniden yazıma dönüşür. İki yıl sonra ikinci bir dil ihtimali bile varsa bunu keşif aşamasında söyleyin.

Entegrasyonlar, barındırma ve bakım yükü

Entegrasyonlar

Kurumsal sitelerin çoğu yalnız yaşamaz: formlar CRM'e, ürün verisi ERP'ye, bülten aboneleri e-posta aracına gider. WordPress'te hemen her şey için bir eklenti bulunur; kalitesi yazarına bağlıdır ve iki eklentinin aynı veri üzerinde çekişmesi şaşırtıcı değildir. Headless ve özel yazılımda entegrasyon kodla yazılır. Daha çok emek ister, karşılığında neyin nereye, ne zaman gittiğini tam olarak bilirsiniz. Logo, Mikro ya da SAP gibi bir ERP'den fiyat ve stok çekecekseniz bu, altyapı ne olursa olsun çoğu zaman kod gerektiren bir iştir.

Barındırma

WordPress için PHP ve MySQL çalıştıran tek bir sunucu ya da yönetilen bir WordPress barındırma hizmeti yeter. Headless kurulumda en az iki parça vardır: içerik sistemi ve ön yüz. Bunlara bir derleme ve yayın hattı ile içerik değişince siteyi yeniden üreten webhook'lar eklenir. Next.js'in kendi belgelerine göre uygulama bir Node.js sunucusunda, Docker konteynerinde, sunucu gerektiren özellikler olmadan statik dışa aktarma olarak ya da Vercel gibi platformların adaptörleriyle çalışabilir. Astro'nun statik çıktısı ise sıradan bir web sunucusunda bile yayımlanır.

Barındırma, kişisel verinin nerede durduğunu da belirler. Bulut tabanlı bir CMS kullanacaksanız içeriklerin ve form verilerinin hangi bölgede saklandığını öğrenin; yurt dışında tutulan kişisel veriler KVKK'nın yurt dışına aktarım hükümlerini gündeme getirir ve bu değerlendirmeyi hukuk danışmanınızla birlikte yapmanız gerekir. Kendi sunucunuza kurduğunuz sistemlerde veri, sizin seçtiğiniz altyapıda kalır.

Bakım

WordPress'te bakım; çekirdek, tema ve eklenti güncellemeleri, PHP sürüm yükseltmeleri ve yedeklerden oluşur. Headless tarafta çatının büyük sürüm geçişleri, Node.js sürüm takvimi ve içerik sisteminin kendi yükseltmeleri vardır. Strapi'nin 4'ten 5'e geçişi örneğin kırıcı değişiklikler içeren, kendi geçiş rehberi ve kod dönüştürme araçlarıyla gelen bir adımdı. Özel yazılımda bunların hepsi, artı "sistemi kim, ne kadar biliyor?" sorusu vardır.

Toplam sahip olma maliyeti: teklifte görünmeyen kalemler

Kurulum teklifi buzdağının görünen kısmıdır. Üç yıllık bir bakışla karşılaştırmak için aşağıdaki kalemleri her seçenek için ayrı ayrı yazdırın. Rakam istemeniz bile gerekmez; hangi kalemin var olduğunu görmek tabloyu değiştirir.

• Geliştirme ve kurulum: tasarım, ön yüz, içerik modeli, eski içeriğin taşınması.
• Lisanslar. Ücretli tema ve eklentilerin yıllık yenilemeleri, bulut CMS'lerde kullanıcı, içerik kaydı, dil ya da API kullanımına bağlı plan sınırları, kurumsal özellikler. Strapi'de tek oturum açma (SSO), inceleme iş akışları ve denetim kayıtları ücretli planlarda yer alıyor.
• Barındırma: sunucu, CDN, veritabanı, derleme dakikaları, ön yüz platformu.
• Bakım saatleri: güncellemeler, sürüm yükseltmeleri, güvenlik izleme, yedek denetimi.
• Ekibinizin zamanı. Yavaş ve karışık bir panel her gün dakikalar çalar; bunu kimse faturaya yazmaz ama siz ödersiniz.
• Geliştirme talepleri: yeni bir sayfa tipi, yeni bir alan, yeni bir entegrasyon.
• Eğitim ve belgeleme: yeni bir editör geldiğinde onu kim, hangi belgeyle eğitecek?
• Çıkış maliyeti: bir gün başka bir sisteme geçmek isterseniz harcanacak emek.

Sık gördüğümüz hata, en düşük kurulum teklifini en düşük maliyet sanmaktır. Aceleyle kurulmuş, yirmi eklentiye yaslanan bir WordPress sitesi gerçek bedelini ikinci yılında bakım saatleriyle, üçüncü yılında yeniden yapılma ihtiyacıyla çıkarır. Teklifleri satır satır okumak için "Web sitesi maliyetini neler belirler?" yazımıza da göz atabilirsiniz.

Satıcıya bağımlılık ve geçiş zorluğu

Bağımlılık tek bir şey değil; en az dört ayrı şey.

• Platform bağımlılığı: Bulut tabanlı bir CMS'te içerik o şirketin altyapısında durur. API ile dışarı alınabilir, ama fiyatlar ya da koşullar değişirse pazarlık gücünüz sınırlıdır.
• Kod bağımlılığı. Özel yazılımı tek bir ajans yazdıysa ve kaynak kod, belgeler ve sunucu erişimi onda kaldıysa, sistemin sahibi kâğıt üzerinde sizsiniz, pratikte o.
• Biçim bağımlılığı: sayfa oluşturucu eklentiler içeriği kendi kısa kodlarında ya da kendi veri biçiminde saklar. Eklentiyi kaldırdığınız gün sayfalar anlamsız kod parçalarına döner.
• Kişi bağımlılığı, yani sistemi bilen tek kişinin işten ayrıldığı gün yaşanan şey.

Açık kaynak lisanslar bu riski azaltır ama yok etmez. Yakın zamanda iki örnek yaşandı: Payload ekibi 2025'te Figma'ya katıldı, Astro'yu geliştiren şirket de Ocak 2026'da Cloudflare bünyesine geçti. İki proje de MIT lisanslı açık kaynak olarak kalacağını açıkladı ve bu güven verici. Yine de bir aracın yol haritası, onu bünyesine katan şirketin öncelikleriyle şekillenir. Seçtiğiniz aracın arkasında kimin durduğunu bilmek teknik incelemenin parçasıdır.

Geçiş zorluğu yöne göre değişir. WordPress içeriği, blok yorumlarıyla işaretlenmiş HTML olarak saklanır; bunu yapılandırılmış bir headless modele taşımak, içeriği alan alan ayrıştırmak ve temizlemek demektir. Görseller, yazar bilgileri, SEO başlıkları ve eski adreslerin yönlendirmeleri ayrı iş kalemleridir. Yönlendirme planı olmadan yapılan bir geçişin arama görünürlüğüne neler yapabileceğini "Site yenilerken SEO kaybetmemek" yazımızda ayrıntısıyla anlattık.

Karar tablosu: hangi durumda hangisi?

Aşağıdaki tablo kesin bir kural değil, sahada en sık doğru çıkan tercihlerin özeti. Durumunuz birkaç satıra birden uyuyorsa, belirleyici olan genellikle içerik ekibinin yapısı ve bakım için ayırabileceğiniz emektir.

Tabloda olmayan bir satırı da ekleyelim: "Herkes Next.js kullanıyor" ya da "WordPress eskidi" gerekçesiyle verilen kararlar. İkisi de bir gerekçe değil, bir moda gözlemi. Doğru soru, içeriği kimin, ne sıklıkla ve kaç dilde güncelleyeceği ve sistemi beş yıl boyunca kimin ayakta tutacağıdır.

Nereden başlamalı?

1. İçerik envanteri çıkarın: hangi sayfa tipleri var, kim, ne sıklıkla, hangi dillerde güncelliyor?
2. Bağlanması gereken her sistemi yazın: CRM, ERP, e-posta aracı, ödeme, harita, randevu.
3. Yukarıdaki maliyet kalemlerini her teklif için ayrı ayrı doldurtun ve üç yıllık bakın.
4. Teklif verenlere aynı soruları sorun: Güncellemeleri kim yapacak? Hesaplar kimin adına açılacak? Ayrılmak istersek içeriği nasıl alacağız?
5. Editörünüzle kısa bir deneme yapın: bir haberi ve bir ürün sayfasını iki sistemde girdirin, nerede takıldığını not edin.
6. Seçilen altyapının arkasındaki şirketi, lisansı ve son iki yılın sürüm geçmişini kontrol edin.
7. Kararı ve gerekçesini bir sayfalık bir belgeye yazın. İki yıl sonra "neden böyle yapmıştık?" sorusunun cevabı orada dursun.

AYTE Digital olarak üç yolla da site kuruyoruz ve hangisini önereceğimize, keşif görüşmesinde içerik akışınıza ve bakım kapasitenize bakarak karar veriyoruz. İsterseniz mevcut sitenizi ya da elinizdeki teklifleri birlikte gözden geçirip yukarıdaki tabloyu kendi durumunuz için dolduralım.