Headless WordPress İçin Hosting Seçimi: Nelere Dikkat Etmeli?

Headless WordPress, WordPress’in yalnızca içerik yönetim sistemi (backend) olarak çalıştığı, sitenin görünen yüzünün ise Next.js, Nuxt ya da Astro gibi ayrı bir uygulama tarafından üretildiği mimaridir. İçerik, tema yerine REST API veya WPGraphQL üzerinden çekilir. WordPress “başsız” kalır: yönetim paneli ve veritabanı durur, tema katmanı devre dışıdır.

Karar aşamasında asıl soru mimari değil altyapıdır: “Peki bunu nerede barındıracağım?” Klasik WordPress’te tek bir hosting hesabı her şeyi çözerken, headless kurulumda iki farklı teknoloji yığınını yönetmeniz gerekir. Bu yazıda hosting gereksinimlerini, önbellekleme ve SEO tuzaklarını, maliyeti ve en önemlisi kime uygun olmadığını dürüstçe ele alıyoruz.

Headless WordPress Nedir, Nasıl Çalışır?

Geleneksel WordPress’te bir ziyaretçi sayfayı istediğinde PHP devreye girer, veritabanından içerik çekilir, aktif tema bunu HTML’e dönüştürür. İçerik ile sunum aynı uygulamanın içindedir; bu “monolitik” yapı, WordPress’i bu kadar kolay kullanılabilir yapan şeyin ta kendisidir.

Headless mimaride bu zincir ikiye ayrılır:

• Backend (WordPress): İçerik üretimi, kullanıcı rolleri, medya kütüphanesi, özel alanlar. PHP ve MySQL burada çalışmaya devam eder. Genellikle cms.siteadi.com gibi bir alt alan adında durur.
• Frontend (ayrı uygulama): Ziyaretçinin gördüğü her şey. İçeriği API üzerinden çeker, HTML’e dönüştürür ve yayınlar. Ana alan adında (siteadi.com) yaşar.

Aradaki bağ bir veri sözleşmesidir: frontend içeriği ister, WordPress JSON döner. Tema yoktur, wp_head() yoktur; eklentilerin ön yüze bastığı hiçbir şey otomatik gelmez. Kazanç da bedel de tam olarak buradadır.

Klasik WordPress mi, Headless mi? Karşılaştırma

İki mimariyi soyut övgülerle değil, somut başlıklarla karşılaştırmak gerekir:

Kriter	Klasik WordPress	Headless WordPress
Performans	Sunucu tarafı önbellek (LiteSpeed/LSCache, Redis) ile çok iyi sonuç alınır. İyi ayarlanmış bir kurulumda TTFB milisaniyelerle ölçülür.	Statik üretim (SSG) ile teorik tavan daha yüksektir. Ancak kötü kurulmuş bir headless site, iyi önbelleklenmiş klasik siteden yavaş olabilir.
SEO	Varsayılan olarak güvenli. Yoast/Rank Math etiketleri, site haritası, kanonik URL’ler hazır gelir.	Riskli. Meta etiketler, site haritası ve yapısal veri frontend’de elle kurulmalıdır. İstemci taraflı render tercih edilirse indeksleme sorunu yaşanabilir.
Maliyet	Tek bir hosting paketi yeter. Yıllık maliyet öngörülebilir.	İki barındırma katmanı + geliştirme eforu. Altyapı maliyeti iki katına, geliştirme maliyeti çok daha fazlasına çıkabilir.
Karmaşıklık	Düşük. İçerik editörü tek başına sayfa yayınlayabilir.	Yüksek. Her yeni bileşen için geliştirici gerekir; dağıtım (deploy) süreci vardır.
Eklenti uyumu	Neredeyse tüm ekosistem çalışır (form, sepet, üyelik, sayfa kurucular).	Ön yüze çıktı basan eklentilerin çoğu çalışmaz; işlevleri frontend’de yeniden yazılır.
Önizleme	“Önizle” düğmesi kutudan çıkar gibi çalışır.	Ayrıca geliştirilmesi gereken bir özelliktir; taslak içerik için özel bir önizleme rotası kurulur.
Kimler için	KOBİ siteleri, kurumsal tanıtım, bloglar, standart e-ticaret, hızlı yayına girmesi gereken projeler.	Geliştirici ekibi olan, çok kanallı (web + mobil uygulama + kiosk) içerik dağıtan, uygulama benzeri arayüzler kuran markalar.

Veri Katmanı: REST API mi, WPGraphQL mi?

WordPress ile frontend arasındaki köprüyü kurmanın iki yaygın yolu vardır ve bu seçim, hosting yükünüzü doğrudan etkiler.

REST API, WordPress çekirdeğinde hazır gelir; ek eklenti gerektirmez. Basit ihtiyaçlar için yeterlidir, ancak “aşırı veri çekme” (over-fetching) sorunu vardır: yalnızca başlık ve kapak görseli istediğinizde bile uç nokta yazının tüm gövdesini ve fazlasını döner. Bir sayfa için birden fazla uç noktaya istek atmanız gerekebilir; her istek backend’de PHP çalıştırır.

WPGraphQL ise tek bir uç nokta üzerinden yalnızca istediğiniz alanları tek sorguda getirir. İç içe verilerde (yazı + yazar + kategori + özel alanlar) istek sayısını belirgin şekilde düşürür. Bedeli, sorgu karmaşıklığını sınırlamak ve önbelleklemeyi kendiniz kurgulamak zorunda kalmanızdır.

Gerekli Eklenti ve Araç Tablosu

Araç / Eklenti	Görevi	Not
WordPress REST API	Çekirdekte gelen JSON uç noktaları	Ek kurulum yok; basit projeler için yeterli
WPGraphQL	Tek uç noktadan seçici veri sorgulama	İç içe veriye ihtiyaç duyan projelerde istek sayısını düşürür
Özel alan eklentisi (ACF vb.) + GraphQL köprüsü	Yapısal içerik alanlarını API’ye açar	Editörün esnek içerik girebilmesi için pratikte zorunlu
SEO eklentisi (Yoast / Rank Math)	Meta başlık, açıklama, kanonik, şema üretimi	Headless’ta bu verinin API’ye aktarılması ve frontend’de basılması gerekir
Sunucu önbelleği (LSCache / Redis / Memcached)	Backend API yanıtlarını hızlandırır	Nesne önbelleği (object cache), tekrarlayan sorguları veritabanına gitmeden karşılar
Webhook / yeniden derleme tetikleyicisi	İçerik güncellenince frontend’i tazeler	Statik üretimde (SSG) olmazsa olmaz
JWT / uygulama parolası	Önizleme ve yazma işlemleri için kimlik doğrulama	Uç noktaları herkese açık bırakmayın

Hosting Gereksinimleri: İki Ayrı Katman

Headless WordPress’in barındırma tarafındaki asıl gerçeği şudur: tek bir hosting paketi artık yetmez, iki farklı ortamı doğru eşlemeniz gerekir.

1. Backend: PHP + MySQL Katmanı

WordPress hâlâ PHP ile çalışır ve veritabanına ihtiyaç duyar. Ancak headless kurulumda backend’in iş yükü değişir: artık HTML sayfa üretmez, JSON yanıtı döner. Bu, yükü azaltmaz; sadece biçim değiştirir. Aranacak özellikler:

• Güncel PHP sürümü ve yeterli bellek limiti: Ağır GraphQL sorguları PHP bellek limitine takılabilir.
• NVMe SSD depolama: Veritabanı sorgu gecikmesi, API yanıt süresinin en büyük bileşenlerinden biridir.
• Nesne önbelleği desteği (Redis/Memcached): Aynı sorgunun tekrar tekrar veritabanına gitmesini engeller.
• LiteSpeed + LSCache: API yanıtlarının önbelleklenmesi ve statik varlıkların hızlı sunulması için pratik bir kazanım sağlar.
• Düşük ağ gecikmesi: Frontend her derlemede yüzlerce istek atar; backend ile frontend arasındaki mesafe doğrudan derleme süresine yansır.

Bu ihtiyaçların tamamı, LiteSpeed ve LSCache ile gelen bir WordPress hosting paketiyle karşılanabilir. Trafik ve sorgu yükü büyüdüğünde ise kaynak izolasyonu için bulut sunucu ya da VDS tarafına geçmek mantıklıdır.

2. Frontend: Node.js ya da Statik Katman

Frontend’in nerede çalışacağı, seçtiğiniz render stratejisine bağlıdır:

• SSG (statik üretim): Sayfalar derleme anında üretilir, ortaya düz HTML dosyaları çıkar. Bunları barındırmak için Node.js çalıştıran bir sunucuya bile gerek yoktur; statik dosya barındırma yeterlidir. En hızlı ve en ucuz seçenektir. Bedeli: içerik değiştiğinde yeniden derleme gerekir.
• SSR (sunucu taraflı render): Her istekte HTML sunucuda üretilir. Sürekli çalışan bir Node.js süreci gerekir. Sık değişen, kişiselleştirilmiş içerikler için uygundur.
• ISR / hibrit: Statik sayfalar belirli aralıklarla ya da webhook tetiğiyle arka planda tazelenir. Pratikte en dengeli yaklaşımdır.

SSR veya hibrit bir yapı kuruyorsanız, sürekli ayakta duran bir Node.js süreci ve süreç yöneticisi gerekir; bunun için Node.js hosting ya da tam kök erişimi veren bir sunucu çözümü uygundur. Vercel ve Netlify gibi platformlar da bu işi görür; ancak backend’iniz Türkiye’de, frontend’iniz yurt dışındaysa her derlemede ortaya çıkan ağ gecikmesini hesaba katın.

Adım Adım: Headless Mimariyi Kurmak

1. Backend’i konumlandırın. WordPress’i cms.siteadi.com gibi bir alt alan adına kurun. Yönetim paneline erişimi IP kısıtı veya ek doğrulama ile koruyun.
2. Veri katmanını seçin. Basit bir blog için REST API yeterli; iç içe içerik ve özel alanlar varsa WPGraphQL kurun.
3. İçerik modelini tanımlayın. Yazı tipleri, taksonomiler ve özel alanları API’ye açık hale getirin. Bu adım atlanırsa frontend eksik veriyle kalır.
4. Frontend çatısını seçin. İçerik ağırlıklı siteler için statik üretime yatkın bir çatı; uygulama benzeri arayüzler için SSR yeteneği olan bir çatı tercih edin.
5. Render stratejisini belirleyin. Her sayfa tipi için SSG mi, SSR mi, ISR mi olacağına karar verin. Bu karar hosting faturanızı doğrudan belirler.
6. SEO verisini taşıyın. SEO eklentisinin ürettiği başlık, açıklama, kanonik ve yapısal veriyi API’den çekip frontend’de <head> içine basın. Site haritasını frontend üretmeli.
7. Önizleme rotasını kurun. Taslak içeriğin editör tarafından görülebilmesi için kimlik doğrulamalı bir önizleme uç noktası yazın.
8. Yeniden derleme tetikleyicisini bağlayın. WordPress’te içerik kaydedildiğinde frontend’e webhook gönderin; yalnızca değişen sayfalar tazelensin.
9. SSL ve alan adı yönlendirmelerini tamamlayın. Hem backend hem frontend için geçerli bir SSL sertifikası kurun; eski URL’leri yeni yapıya 301 ile taşıyın.
10. İzleme ekleyin. API yanıt süresi, derleme süresi ve hata oranını izleyin. Backend yavaşlarsa frontend derlemeleri de yavaşlar.

Önbellekleme: Headless’ın Görünmeyen Belkemiği

Headless bir site otomatik olarak hızlı değildir. Hız, üç katmanlı bir önbellek kurgusundan gelir:

• Backend nesne önbelleği: Redis ya da Memcached, tekrar eden veritabanı sorgularını karşılar; WPGraphQL sorguları bundan çok fayda görür.
• API yanıt önbelleği: Sık istenen sorguların yanıtları bir süre saklanır. Bir liste sayfası dakikada yüzlerce kez sorgulanıyorsa her seferinde PHP çalıştırmak israftır.
• Frontend çıktı önbelleği: Üretilen HTML’in saklanması; statik üretimde bu doğal olarak gerçekleşir.

Önbelleği geçersiz kılma (invalidation) kuralları da baştan yazılmalıdır: bir yazı güncellendiğinde yalnızca o yazı değil, göründüğü liste ve kategori sayfaları da tazelenmelidir. Bu detay atlandığında editör “yayınladım ama sitede görünmüyor” der.

SEO Riskleri ve Çözümleri

En sık yapılan hata, sayfayı tamamen istemci tarafında (tarayıcıda JavaScript ile) oluşturmaktır. Bu durumda arama motoru robotu ilk yanıtta boş bir iskelet görür; içeriğin işlenmesi JavaScript’in çalıştırılmasına ertelenir. Bu erteleme indekslemeyi geciktirir, bazen tamamen engeller.

Çözüm nettir: HTML sunucuda ya da derleme anında üretilmelidir. SSG veya SSR kullanıldığında robot, tıpkı klasik WordPress’te olduğu gibi dolu bir HTML alır ve sorun ortadan kalkar. Bunun yanında şu üç kalemi elle taşımanız gerekir:

• Meta etiketler ve kanonik URL’ler: Klasik kurulumda eklenti bunları otomatik basar; headless’ta API’den çekip siz basmalısınız.
• Site haritası: WordPress’in ürettiği sitemap.xml artık alt alan adındadır ve yanlış URL’leri gösterir. Frontend kendi site haritasını üretmelidir.
• Yapısal veri (JSON-LD): Şema işaretlemesi frontend bileşenlerine taşınmalıdır.

Bir de sessiz bir tuzak vardır: backend alt alan adı arama motorlarına açık kalırsa, aynı içerik iki adresten indekslenebilir. Backend’i noindex ile kapatın ve arama sonuçlarından uzak tutun.

Önizleme Sorunu ve Editör Deneyimi

Klasik WordPress’te “Önizle” düğmesi bedavadır. Headless’ta ise taslak içerik henüz frontend’e yansımamıştır; onu göstermek için ayrı bir kimlik doğrulamalı rota geliştirmeniz gerekir. Aynı şekilde sayfa kurucularla oluşturulan düzenler, form eklentileri, yorum sistemleri ve pop-up’lar da frontend’de yeniden yazılır.

Projeleri asıl batıran yer burasıdır: içerik ekibi alıştığı esnekliği kaybettiğinde, headless kurulum “geliştiriciye bağımlı” bir yapıya dönüşür. Karar verirken yalnızca geliştirici konforunu değil, editörün günlük iş akışını da hesaba katın.

Maliyet ve Karmaşıklık: Gerçekçi Tablo

Headless kurulumda maliyet üç kalemde toplanır:

• Altyapı: Backend hosting + frontend barındırma; en az iki kalem, bazen üç.
• Geliştirme: Tema seçmek yerine arayüzü sıfırdan yazmak. Klasik bir kurumsal sitenin haftalar süren işi headless’ta aylara çıkabilir.
• Bakım: İki ayrı bağımlılık ağacı, iki ayrı güvenlik yüzeyi, iki ayrı güncelleme takvimi.

Trafiğiniz büyüdükçe kaynak ihtiyacı da artar; büyüyen altyapı seçenekleriyle kaynakları kademeli artırmak, baştan devasa bir sunucu kiralamaktan daha akıllıcadır.

Headless Kime Uygun Değil?

Dürüst olalım: çoğu KOBİ, kurumsal tanıtım sitesi ve blog için headless WordPress gereksizdir. Şu durumlardaysanız uzak durun:

• Sitenizi bir geliştirici ekibi değil, tek bir içerik editörü yönetiyorsa.
• Sayfa kurucu, form, üyelik ya da e-ticaret eklentilerine bağımlıysanız.
• Performans sorununuz varsa ama bunu henüz sunucu önbelleği, görsel optimizasyonu ve iyi bir barındırma ile çözmeyi denemediyseniz.
• “Modern görünsün” dışında somut bir teknik gerekçeniz yoksa.

Gerçek şu ki, LiteSpeed ve LSCache ile düzgün önbelleklenmiş, NVMe diskler üzerinde çalışan klasik bir WordPress kurulumu, çoğu senaryoda kullanıcıyı tatmin eden hızları rahatlıkla yakalar. Headless’a geçmeden önce mevcut kurulumunuzdan alınabilecek performansın tamamını aldığınızdan emin olun.

Peki Ne Zaman Mantıklı?

Headless mimari şu durumlarda gerçekten kazandırır:

• Aynı içeriği web sitesi, mobil uygulama, dijital ekran gibi birden fazla kanala besliyorsanız.
• Uygulama benzeri, yoğun etkileşimli bir arayüz kuruyorsanız.
• Bünyenizde bu yapıyı sürdürebilecek bir frontend geliştirme ekibi varsa.
• İçerik ekibinin WordPress’te kalmasını isteyip sunum katmanını tamamen özgürleştirmek istiyorsanız.
• Çok yüksek trafikte, statik dağıtımın sağladığı dayanıklılığa ihtiyaç duyuyorsanız.

Backend’in kararlılığı bu mimaride kritik önemdedir: frontend her derlemede backend’e yaslanır, backend düşerse yeni içerik yayınlanamaz. Bu yüzden kesintisiz çalışma taahhüdü ve destek kalitesi, headless projelerde klasik kurulumlardan bile önemlidir.

Alastyr’ın barındırma altyapısı, kendisine ait İzmir veri merkezinde N+1 yedekli olarak çalışır; NVMe SSD depolama, LiteSpeed web sunucusu, %99,9 çalışma süresi taahhüdü ve 7/24 Türkçe destek standart olarak sunulur. Backend’i WordPress hosting üzerinde, frontend’i Node.js hosting ya da bulut sunucu üzerinde konumlandırarak iki katmanı da aynı veri merkezinde, düşük gecikmeyle çalıştırabilirsiniz.

Sıkça Sorulan Sorular

Headless WordPress için hangi hosting gerekir?

İki ayrı katman gerekir. Backend için PHP ve MySQL çalıştıran, tercihen NVMe diskli ve nesne önbelleği (Redis/Memcached) destekleyen bir WordPress hosting; frontend için ise SSR kullanıyorsanız Node.js çalıştırabilen bir ortam, SSG kullanıyorsanız statik dosya barındırma yeterlidir. İkisini aynı veri merkezinde tutmak derleme sürelerini kısaltır.

REST API mi WPGraphQL mi kullanmalıyım?

Basit bir blog ya da az sayıda uç noktayla çalışacak projeler için WordPress çekirdeğinde hazır gelen REST API yeterlidir. İç içe veriye (yazı + yazar + kategori + özel alanlar) ihtiyaç duyan, istek sayısını azaltmak isteyen projelerde WPGraphQL daha verimlidir; tek sorguda yalnızca istenen alanları döndürür.

Headless WordPress SEO’ya zarar verir mi?

Yanlış kurulursa evet. Sayfa tamamen istemci tarafında JavaScript ile oluşturulursa arama motoru ilk yanıtta boş bir iskelet görür ve indeksleme gecikir. SSR ya da SSG ile HTML sunucuda veya derleme anında üretildiğinde bu risk ortadan kalkar. Ayrıca meta etiketleri, kanonik URL’leri ve site haritasını frontend tarafında elle kurmanız gerekir.

Headless WordPress klasik WordPress’ten her zaman hızlı mıdır?

Hayır. Statik üretimle çok yüksek hızlara ulaşmak mümkündür, ancak kötü kurgulanmış bir headless site, LiteSpeed ve LSCache ile düzgün önbelleklenmiş klasik bir WordPress kurulumundan daha yavaş olabilir. Hız, mimariden değil önbellekleme ve render stratejisinden gelir.

Headless kurulumda eklentilerim çalışır mı?

Yönetim paneli tarafında çalışan eklentiler (özel alanlar, editör araçları, SEO veri üretimi) sorunsuz çalışır. Ancak ön yüze çıktı basan eklentiler (sayfa kurucular, form eklentileri, pop-up ve yorum sistemleri) devre dışı kalır; bu işlevlerin frontend uygulamasında yeniden yazılması gerekir.

İçerik önizleme headless WordPress’te nasıl çalışır?

Kutudan çıktığı gibi çalışmaz. Taslak içeriğin editöre gösterilebilmesi için frontend tarafında kimlik doğrulamalı özel bir önizleme rotası geliştirilir; bu rota, WordPress’ten taslak veriyi yetkili bir istekle çeker. Bu, headless projelerde en sık atlanan ve editörleri en çok zorlayan konudur.

Headless WordPress küçük işletmem için mantıklı mı?

Genellikle hayır. Tek bir editörün yönettiği, sayfa kurucu ve form eklentilerine dayanan bir KOBİ sitesinde headless mimari maliyeti ve karmaşıklığı artırır, karşılığında somut fayda vermez. Bu tür sitelerde iyi ayarlanmış bir WordPress hosting paketi çok daha iyi maliyet/fayda dengesi sunar.

Backend ile frontend farklı sunucularda olabilir mi?

Evet, hatta yaygın olan budur. Ancak aralarındaki ağ gecikmesi doğrudan derleme süresine ve SSR yanıt süresine yansır. Backend Türkiye’de, frontend yurt dışındaysa her sayfa üretiminde ek gecikme oluşur. İki katmanı da aynı veri merkezinde tutmak en öngörülebilir sonucu verir.

Headless WordPress’te güvenlik nasıl sağlanır?

Yönetim paneline erişimi IP kısıtı veya ek doğrulama ile daraltın, API uç noktalarını yetkisiz yazma işlemlerine kapatın ve önizleme için uygulama parolası ya da JWT tabanlı kimlik doğrulama kullanın. Backend alt alan adını arama motorlarına kapatın, hem backend hem frontend için geçerli SSL sertifikası kurun.