Puan
18
Çözümler
0
- Katılım
- 3 Kas 2025
- Mesajlar
- 99
- Tepkime puanı
- 0
Headless WordPress İçin Hosting Seçimi: API, Önbellek ve Yayınlama Gereksinimleri
WordPress’in içerik yönetimini kullanıp ziyaretçilerin gördüğü arayüzü ayrı bir uygulamayla oluşturabilirsiniz. Headless WordPress adı verilen bu yaklaşım, tasarım ve geliştirme tarafında geniş hareket alanı sağlar.Ancak hosting seçerken yalnızca “WordPress çalışıyor mu?” sorusuna bakmak yeterli olmaz. İçeriğin nasıl çekildiği, sayfaların nerede üretildiği ve güncellemelerin ziyaretçilere nasıl ulaştığı da değerlendirilmelidir.
Başarılı bir headless proje için içerik yönetimi, API ve arayüzün birlikte çalışacağı bir altyapı gerekir. Bu yapı her projede daha hızlı, daha ucuz veya daha güvenli değildir; doğru ihtiyaçlarla eşleştiğinde fayda sağlar.
Headless WordPress Nasıl Çalışır?
Klasik WordPress’te içerik yönetimi ve ziyaretçiye sunulan sayfalar aynı uygulamanın içinde bulunur. Tema, WordPress verilerini kullanarak sayfanın görünümünü oluşturur.Headless yapıda ise iki uygulama sorumluluğu ayrılır:
- WordPress: İçerikleri, kullanıcı yetkilerini, medyayı ve içerik alanlarını yönetir.
- Frontend uygulaması: API’den aldığı verilerle ziyaretçilerin gördüğü sayfaları oluşturur.
cms.ornek.com, ziyaretçi sitesi ise ornek.com adresinde çalışabilir. Next.js, Nuxt veya Astro gibi araçlar sunum katmanında kullanılabilir.Bu ayrım iki farklı sunucu kiralamanızı zorunlu kılmaz. Uygun yapılandırılmış tek bir sunucuda iki uygulama da çalışabilir. Ayrı hizmetler kullanmak ise kaynakların ve yayınlama süreçlerinin bağımsız yönetilmesini kolaylaştırabilir.
Ayrıca headless kurulum, WordPress’in tema sistemini otomatik olarak kapatmaz. Ziyaretçi trafiğinin hangi uygulamaya ulaşacağı ve WordPress’in mevcut sayfalarının nasıl ele alınacağı ayrıca yapılandırılır.
Klasik WordPress ile Headless Arasındaki Farklar
| Konu | Klasik WordPress | Headless WordPress |
|---|---|---|
| Sayfa görünümü | WordPress teması üzerinden oluşturulur | Ayrı uygulamada oluşturulur |
| Yayınlama | İçerik çoğunlukla doğrudan siteye yansır | Önbellek yenileme veya derleme gerekebilir |
| Eklenti çıktıları | Tema ve WordPress sayfalarıyla bütünleşir | Frontend için ek entegrasyon gerekebilir |
| SEO | WordPress ve eklentiler üzerinden yönetilir | Verilerin ziyaretçi sayfalarında uygulanması gerekir |
| Bakım | WordPress kurulumu ağırlıklıdır | WordPress ve frontend birlikte yönetilir |
| Hosting | PHP ve veritabanı altyapısı gerekir | Frontend’in çalışma biçimi ek ihtiyaçları belirler |
Performansı yalnızca bu tabloya göre değerlendirmeyin. Ağır JavaScript kullanan, gereksiz API istekleri yapan bir headless site; iyi optimize edilmiş klasik WordPress sitesinden daha yavaş olabilir.
REST API mi, WPGraphQL mi?
WordPress ile frontend arasında veri taşımak için iki yaygın seçenek vardır.WordPress REST API
REST API, WordPress’in içinde bulunur. Yazılar, sayfalar ve medya gibi içeriklere ilgili uç noktalardan erişilebilir.REST API’nin her istekte bütün içeriği göndermesi zorunlu değildir.
_fields parametresiyle dönecek alanları seçebilirsiniz:/wp-json/wp/v2/posts?_fields=id,slug,title,excerptİlişkili verilerin bir kısmını aynı yanıtta almak için
_embed de kullanılabilir. Bu seçenekler yanıt boyutunu ve ayrı istek ihtiyacını azaltabilir.WPGraphQL
WPGraphQL, WordPress’e GraphQL desteği ekleyen bir eklentidir. İçeriği bir şema üzerinden sorgulamanıza olanak tanır.Yazı, yazar, kategori ve başka ilişkili alanları seçerek istemek, bazı arayüzlerde veri erişimini kolaylaştırabilir. Bununla birlikte tek HTTP isteği, otomatik olarak düşük sunucu yükü anlamına gelmez. Derin ilişkiler ve büyük listeler sorguyu pahalı hâle getirebilir.
Seçimi gerçek ekranlarınız üzerinden yapın. İhtiyaç duyulan veriyi, sorgu süresini, önbellekleme imkânlarını ve ekibin deneyimini karşılaştırın.
Özel içerik türlerinin veya alanların API’de görünmesi de ayrıca hazırlanmalıdır. REST tarafında içerik türleri için
show_in_rest gibi ayarlar kullanılır; GraphQL tarafında şemaya uygun tanımlar gerekir. ACF gibi bir özel alan eklentisi her projede zorunlu değildir.WordPress Tarafında Hosting Seçerken Nelere Bakılmalı?
Headless yapıda WordPress hâlâ PHP ve MySQL veya MariaDB kullanır. Tema üzerinden ziyaretçi sayfası üretmemesi, sunucu yükünün kendiliğinden ortadan kalkacağı anlamına gelmez.API istekleri, yönetim paneli, görsel işleme ve zamanlanmış görevler kaynak tüketmeye devam eder.
Hosting paketinde şu özellikleri değerlendirin:
- PHP uyumluluğu: WordPress ve kullandığınız eklentilerle uyumlu, desteklenen sürümler sunulmalı.
- CPU ve bellek kapasitesi: API sorgularını ve eşzamanlı işlemleri karşılayabilmeli.
- PHP işlem kapasitesi: Aynı anda gelen isteklerin ne kadarının işlenebildiği bilinmeli.
- Veritabanı performansı: Yavaş sorguların incelenebilmesi ve uygun kaynakların bulunması önemli.
- Nesne önbelleği: Redis veya Memcached gerekiyorsa pakette gerçekten kullanılabilmeli.
- API erişimi: Güvenlik duvarı, bot koruması ve oran sınırları uygulamanın isteklerini engellememeli.
- Yedek ve geri yükleme: Dosyalarla birlikte veritabanı da korunmalı.
- Kayıtlar ve izleme: PHP hatalarına ve erişim kayıtlarına ulaşılabilmeli.
Başlangıç kapasitesini yalnızca aylık ziyaretçi sayısıyla belirlemeyin. Statik sayfa sunan bir projede ziyaretçi trafiği WordPress’e çok az ulaşabilirken, sürekli API kullanan bir uygulama daha az ziyaretçiyle daha fazla yük oluşturabilir.
Frontend Hostingini Sayfa Üretim Biçimine Göre Seçin
Frontend’in ihtiyaçları, sayfaların nasıl oluşturulduğuna bağlıdır.| Yaklaşım | Sayfalar nasıl oluşur? | Hosting ihtiyacı |
|---|---|---|
| Statik üretim / SSG | Yayınlama sırasında HTML dosyaları hazırlanır | Statik dosya sunabilen ortam |
| Sunucu tarafında üretim / SSR | Gerekli sayfa çıktısı sunucuda oluşturulur | Uygun uygulama çalışma ortamı |
| ISR veya hibrit yapı | Üretilmiş sayfalar belirli kurallarla yenilenir | Kullanılan özelliği destekleyen platform |
Statik üretim
Frontend uygulaması derlenir ve ortaya çıkan dosyalar yayınlanır. Derleme için kullanılan araçlar yayın sunucusunda sürekli çalışmak zorunda değildir.Örneğin Next.js’in statik dışa aktarma özelliğiyle üretilen HTML, CSS ve JavaScript dosyaları statik içerik sunabilen bir web sunucusunda barındırılabilir. Ancak sunucu gerektiren özellikler bu dağıtım biçiminde kullanılamaz.
SSR
Dinamik sayfa üretimi için uygulamanın çalışabileceği bir ortam gerekir. Kendi sunucunuzda Node.js kullanabilirsiniz; desteklenen yönetilen platformlar farklı dağıtım seçenekleri de sunabilir.Next.js belgeleri Node.js, Docker, statik dışa aktarma ve platform adaptörlerini ayrı seçenekler olarak açıklar. Dolayısıyla her SSR projesinde sizin yöneteceğiniz sürekli bir Node.js süreci bulunması şart değildir.
ISR ve hibrit yapı
Önceden oluşturulan sayfalar zaman aralığıyla veya içerik değişikliğiyle yenilenebilir. Ancak platformun bu özelliği desteklemesi gerekir.Örneğin Next.js’te yalnızca statik dosyaları dışa aktarıp yayınlamak, ISR desteği sağlamaz. Hosting seçerken “Next.js destekliyoruz” ifadesinin hangi özellikleri kapsadığını öğrenin.
API Önbelleği ile Sayfa Önbelleğini Ayırın
Headless projelerde farklı önbellek katmanları bulunabilir:- Nesne önbelleği: WordPress’in sık kullanılan verilerini tutar.
- API yanıt önbelleği: Aynı sorgunun sonucunu yeniden kullanır.
- Frontend önbelleği: Oluşturulan sayfa veya bileşen çıktısını saklar.
- CDN önbelleği: İçeriği ziyaretçiye yakın noktalardan sunar.
WPGraphQL için Smart Cache gibi çözümler bulunur. Etiketlere göre temizleme ve CDN entegrasyonu, hostingin desteklediği yapılandırmayla birlikte değerlendirilmelidir.
Asıl önemli konu, içerik değişince hangi sonuçların yenileneceğidir. Bir yazı güncellendiğinde yazının yanında ana sayfa, kategori listesi ve ilgili içerik alanları da etkilenebilir.
Taslakları veya kullanıcıya özel yanıtları ortak önbelleğe koymayın. Yanlış önbellekleme, henüz yayınlanmamış ya da özel içeriğin başka ziyaretçilere görünmesine neden olabilir.
İçerik Yayınlama Sürecini Baştan Tasarlayın
Editörün WordPress’te “Yayınla” düğmesine basmasıyla ziyaretçinin yeni içeriği görmesi arasında başka işlemler bulunabilir.Statik veya önbellekli yapıda şu akış hazırlanmalıdır:
- WordPress’te içerik yayınlanır, güncellenir veya kaldırılır.
- Frontend’e ilgili değişiklik bildirilir.
- Gerekli sayfalar yeniden oluşturulur veya önbellekleri yenilenir.
- İşlemin sonucu kayıt altına alınır.
- Hata varsa yeniden deneme veya bildirim devreye girer.
Başarısız bir derlemede son çalışan sürümün korunması ve önceki yayına dönülebilmesi de önemli hosting özellikleridir.
Headless WordPress’te SEO Nasıl Korunur?
Google JavaScript çalıştırabilir. Bu yüzden istemci tarafında oluşturulan her site indekslenmez demek doğru değildir. Yine de önemli içeriğin ilk HTML yanıtında bulunması, kullanıcılar ve tarayıcılar açısından avantaj sağlar.Google, sunucu tarafında veya önceden üretimi yararlı bulur; bütün botların JavaScript çalıştırmadığını da belirtir. SSR veya SSG kullanmak ise diğer SEO hatalarını otomatik çözmez.
Ziyaretçi sitesinde şunları kontrol edin:
- Sayfaya özel başlık ve açıklamalar.
- Ana alan adını gösteren canonical adresleri.
- Doğru HTTP durum kodları.
- Tarayıcıların takip edebileceği bağlantılar.
- Yayındaki adresleri içeren site haritası.
- Uygun yapısal veri ve sosyal paylaşım etiketleri.
- Eski adreslerden gereken yönlendirmeler.
Site haritası frontend’de oluşturulabilir veya mevcut sistem doğru ziyaretçi adreslerini üretecek şekilde uyarlanabilir. WordPress tarafında kalan içerik sayfalarının indekslenme davranışını da ayrıca planlayın.
Önizleme ve Eklenti Uyumluluğunu Test Edin
Headless projelerde editör deneyimi kolayca gözden kaçabilir. Taslak yazının ziyaretçi tasarımında gösterilmesi için önizleme entegrasyonu gerekir.Bu entegrasyon:
- Kullanıcının yetkisini kontrol etmeli.
- Doğru taslak veya revizyonu getirmeli.
- Genel önbellekten ayrılmalı.
- Önizleme durumunu editöre göstermeli.
Eklentiler için de “Hepsi çalışır” veya “Hiçbiri çalışmaz” şeklinde karar vermeyin. İçerik yönetimi işlevleri kullanılabilir; form, yorum, sayfa oluşturucu ve üyelik özelliklerinde ek API veya arayüz entegrasyonu gerekebilir.
Mevcut HTML çıktısını kullansanız bile ilgili stil, JavaScript ve etkileşimleri test etmelisiniz.
API Güvenliği Nasıl Sağlanmalı?
Yayındaki içeriklerin API üzerinden herkese açık okunması normal olabilir. Taslaklara, özel verilere ve yönetim işlemlerine erişim ise uygun yetkilendirme gerektirir. WPGraphQL de WordPress’in kullanıcı ve yetki sistemini kullanır.Sunucudan sunucuya erişimde WordPress uygulama parolaları HTTPS üzerinden kullanılabilir. JWT zorunlu değildir; ihtiyaç duyulursa uygun entegrasyonla değerlendirilir. Yönetim yetkili parolaları tarayıcıya gönderilen JavaScript içinde saklamayın.
Tarayıcı doğrudan başka alan adındaki API’ye erişiyorsa CORS yapılandırmasını kontrol edin. CORS, tarayıcı erişim davranışını düzenler; kimlik doğrulamanın yerini tutmaz.
Hosting Sağlayıcısına Sorulacak Sorular
Satın almadan önce şu konuları netleştirin:- REST ve GraphQL isteklerine uygulanan sınırlar neler?
- İstenen PHP sürümü ve eklentiler destekleniyor mu?
- Kalıcı nesne önbelleği kullanılabiliyor mu?
- Frontend’in SSR, ISR ve önizleme özellikleri destekleniyor mu?
- Derleme süresi, eşzamanlı derleme ve trafik sınırları neler?
- Hata kayıtlarına ve kaynak kullanımına erişilebiliyor mu?
- Staging, yedekleme ve önceki sürüme dönüş sunuluyor mu?
- WordPress ve frontend sorunlarında destek kapsamı ne?
