Headless WordPress + Next.js Hosting Mimarisi: Ayrı Frontend ve API Sunucuları

Headless WordPress + Next.js Mimarisi Neden Bu Kadar Popüler?

WordPress yıllardır içerik yönetimi tarafında standart haline geldi. Ancak modern frontend dünyasında React, Next.js, Vue gibi framework’ler; SEO dostu server-side rendering (SSR), statik site üretimi (SSG) ve güçlü bileşen yapılarıyla oyunun kurallarını değiştirdi. İşte bu noktada Headless WordPress + Next.js ikilisi devreye giriyor: WordPress’i sadece bir API sağlayıcısı (headless CMS) olarak kullanıp, tüm kullanıcı arayüzünü Next.js ile sunmak.

Bu yaklaşım özellikle ajanslar, SaaS ürünleri, yüksek trafikli içerik siteleri ve kurumsal projelerde ciddi avantaj sağlıyor: Daha esnek frontend, çok daha iyi performans, ayrı ölçeklendirme imkânı ve daha kontrollü bir mimari. Fakat iş sadece kod yazmakla bitmiyor; doğru hosting mimarisi kurmadığınız sürece bu avantajları tam olarak hissedemiyorsunuz.

Bu yazıda DCHost ekibi olarak, gerçek projelerde kullandığımız yaklaşımlara dayanarak ayrı frontend (Next.js) ve API (WordPress) sunucularını nasıl kuracağınızı adım adım anlatacağım. DNS ve SSL stratejisinden, cache ve CDN kullanımına; CI/CD, güvenlik ve ölçeklendirmeye kadar uzanan, pratik ve uygulanabilir bir rehber olacak. Hedefimiz; “tek sunucuda her şey” mimarisinden kontrollü, gözlemlenebilir ve kolay yönetilebilir bir headless yapıya geçmenizi kolaylaştırmak.

Mimariyi Tasarlamak: Ayrı Frontend ve API Sunucuları

Temel bileşenler

Önce kafamızda mimariyi netleştirelim. Tipik bir Headless WordPress + Next.js kurulumunda şu bileşenler yer alır:

• WordPress API sunucusu: PHP + web sunucusu (Nginx/Apache), MySQL/MariaDB, REST API veya GraphQL sunan katman.
• Next.js frontend sunucusu: Node.js üzerinde çalışan, SSR/SSG/ISR yapan, son kullanıcıya HTML sunan katman.
• Veritabanı: Genellikle WordPress sunucusunda ya da ayrı bir veritabanı sunucusunda çalışan MySQL/MariaDB.
• CDN ve cache katmanı: HTML, görseller, statik dosyalar ve API yanıtlarını hızlandıran önbellek katmanı.
• DNS ve SSL katmanı: Alan adlarını doğru sunuculara yönlendiren ve HTTPS’yi sağlayan katman.

Bu bileşenleri ister tek bir güçlü DCHost dedicated sunucuda, ister birkaç DCHost VPS üzerinde dağıtarak kurabilirsiniz. Önemli olan, rollerin net ayrılması ve gelecekte ölçeklendirmeye uygun bir tasarım kurmanız.

Alan adı yapısını belirlemek

Headless mimaride en çok kullanılan alan adı stratejileri şunlar:

• www + api alt alan adı: www.alanadiniz.com (Next.js), api.alanadiniz.com (WordPress)
• root domain + alt alan: alanadiniz.com (Next.js), cms.alanadiniz.com (WordPress)
• Farklı domain’ler: kurumsal-site.com (Next.js), icerik-paneli.com (WordPress – genelde admin erişimi için)

Genel olarak önerdiğimiz yapı: www.alanadiniz.com üzerinde Next.js, api.alanadiniz.com veya cms.alanadiniz.com üzerinde WordPress. Böylece güvenlik, CORS kuralları ve ölçeklendirme tarafında işleri sade tutmak kolaylaşıyor.

WordPress API Sunucusunu Kurmak ve Optimizasyon İpuçları

Rolü: İçerik yönetimi ve API sağlayıcısı

Headless senaryoda WordPress’i artık kullanıcıya HTML üreten bir sistem olarak değil, veri sağlayan bir API sunucusu olarak düşünmelisiniz. Yani performans kriterleriniz “sayfa ne kadar hızlı render ediyor?” değil, “API ne kadar hızlı cevap veriyor?” haline geliyor.

Bu nedenle WordPress sunucunuzda şu noktalara odaklanmalısınız:

• PHP-FPM, OPcache, MySQL/MariaDB ayarlarının API odaklı optimize edilmesi
• Nesne önbelleği (Redis/Memcached) ile query yükünün azaltılması
• WordPress çekirdeği ve eklentilerin gereksiz çıktılar üretmemesi (no-theme rendering)
• Güvenlik sertleştirmesi ve saldırı yüzeyinin daraltılması

WordPress tarafındaki detaylı sunucu ayarları için hazırladığımız WordPress için sunucu tarafı optimizasyon rehberini mutlaka gözden geçirmenizi öneririm; oradaki ayarların büyük bölümü headless mimaride de birebir geçerli.

Hosting seçimi: Paylaşımlı mı, VPS mi, dedicated mı?

Teorik olarak headless WordPress’i paylaşımlı hosting’te de çalıştırabilirsiniz, ancak pratikte API trafiği arttıkça VPS veya dedicated daha mantıklı hale geliyor. Çünkü:

• API istekleri genellikle frontend tarafından yoğun ve burst şeklinde gelir.
• Webhook, cron ve arka plan işleriniz (örn. görsel optimizasyonu) CPU ve disk kullanır.
• Cache katmanlarını (Redis, özel Nginx kuralları) özgürce ayarlamak istersiniz.

Biz DCHost tarafında çoğu headless projeyi NVMe diskli VPS üzerinde, trafik yükseldiğinde ise veritabanını ayrı bir VPS’e veya dedicated sunucuya ayırarak ölçeklendiriyoruz.

API odaklı WordPress yapılandırması

Headless kullanımda dikkat etmeniz gereken bazı WordPress adımları:

• Temayı minimal tutun: Hatta mümkünse sadece admin arayüzünü gösteren, frontend’i hiç çalıştırmayan bir “headless” tema kullanın.
• REST API veya GraphQL seçimi: Klasik REST API çoğu senaryoda yeterli. Daha karmaşık sorgular için WPGraphQL gibi çözümler kullanılabiliyor.
• Gereksiz eklentileri kapatın: Özellikle frontende HTML/JS enjekte eden eklentiler headless senaryoda sadece yük olur.
• Nesne önbelleği: API çağrılarınızın çoğu aynı verileri okuyacağı için Redis ile kalıcı object cache büyük fark yaratır.

Güvenlik ve erişim kısıtlamaları

Artık WordPress siteniz doğrudan ziyaretçi trafiği almıyor; esas trafiği Next.js uygulamanızdan gelen API istekleri oluşturuyor. Bu da size şu güvenlik imkânlarını veriyor:

• WordPress admin panelini IP kısıtlaması veya VPN arkasına alma
• wp-login.php, xmlrpc.php gibi uç noktaları tamamen kapatma ya da ek koruma ekleme
• Yalnızca belirli origin’lere (örn. www.alanadiniz.com) izin veren CORS politikaları uygulama

WordPress güvenliğini sertleştirmek için oluşturduğumuz WordPress güvenlik sertleştirme kontrol listesi de bu senaryoda oldukça işinize yarar.

Next.js Frontend Sunucusunu Kurmak

Next.js nasıl çalışıyor, sunucudan ne bekliyor?

Next.js; SSR, SSG, ISR ve sadece API route’ları gibi farklı çalışma modları sunar. Hosting açısından ana fark şuradan gelir:

• SSG/ISR ağırlıklı siteler: Build sırasında HTML dosyaları üretilir, sonrasında statik dosya gibi servis edilir.
• SSR ağırlıklı siteler: Her istek geldiğinde Node.js tarafında render yapılır; CPU ve RAM kullanımı süreklidir.

Bu nedenle Next.js için genelde aşağıdaki gibi bir yol izliyoruz:

• Node.js uygulamasını pm2 veya systemd ile arka planda koşturmak
• Önüne Nginx koyarak TLS terminasyonu ve gzip/brotli sıkıştırması yapmak
• Gerekirse CDN ile görsel ve statik dosyaları kenarlara (edge) taşımak

Node.js uygulamalarını canlıya alma tarafında ayrıntılı bir rehbere ihtiyacınız varsa Node.js’i canlıya alırken pm2, Nginx ve SSL ile kurulum rehberimizi mutlaka inceleyin; Next.js de temelde aynı mantıkla çalışıyor.

Kaynak planlama: vCPU, RAM ve disk

Next.js tarafında ihtiyacınız olan kaynaklar:

• vCPU: SSR oranı yüksek sitelerde 2–4 vCPU başlangıç için iyi bir aralık. Daha yoğun projelerde yatayda birden fazla Node süreci çalıştırmak isteyebilirsiniz.
• RAM: 2 GB altına inmemek mantıklı; 4 GB ve üzeri, hem build süreçleri hem SSR için konfor alanı sağlar.
• Disk: Çoğunlukla kod + build çıktıları ve loglar için kullanılır. NVMe disk, özellikle build aşamalarında belirgin hız kazandırır.

Next.js – WordPress iletişimi: Ortak sözleşme

İki sunucu da ayrı çalıştığı için aralarında net bir API sözleşmesi (contract) olması gerekir:

• WordPress hangi endpoint’lerde ne formatta veri döndürecek?
• Yetkilendirme (JWT, Basic Auth, uygulama şifreleri vs.) nasıl yapılacak?
• Önbelleğe alınabilirlik: Hangi endpoint ne kadar süre cache’lenecek?

Next.js tarafında tipik bir örnek:

const API_URL = process.env.NEXT_PUBLIC_API_URL

export async function getPost(slug) {
  const res = await fetch(`${API_URL}/wp-json/wp/v2/posts?slug=${slug}`)
  if (!res.ok) throw new Error('API hata döndürdü')
  const data = await res.json()
  return data[0]
}

.env dosyanızda sadece API URL’ini değiştirerek staging ve production ortamlar arasında geçiş yapabilirsiniz:

# .env.production
NEXT_PUBLIC_API_URL=https://api.alanadiniz.com

# .env.staging
NEXT_PUBLIC_API_URL=https://staging-api.alanadiniz.com

DNS, SSL ve Alan Adı Yapılandırması

DNS kayıtları: Temel şema

Tipik bir kurulum için DNS tarafında şunları yaparsınız:

• A kaydı: www.alanadiniz.com → Next.js VPS/dedicated IP
• A kaydı: api.alanadiniz.com → WordPress VPS/dedicated IP
• Gerekirse staging ve preview alt alan adları (staging.alanadiniz.com gibi)

DNS tarafında doğru kayıt türleri ve sık yapılan hatalar hakkında tazelenmeye ihtiyaç duyarsanız, DNS kayıtları A’dan Z’ye rehberimiz işinizi oldukça kolaylaştırır.

SSL stratejisi: Ayrı sertifika, ayrı uç nokta

Next.js ve WordPress için genellikle ayrı SSL sertifikaları kullanırız:

• www.alanadiniz.com için bir sertifika (Next.js sunucusunda sonlandırılır)
• api.alanadiniz.com için ayrı bir sertifika (WordPress sunucusunda sonlandırılır)

Her iki sunucuda da HTTPS zorunlu hale getirerek; hem kullanıcı güvenliğini hem de SEO tarafını korursunuz. Sertifika türleri, HSTS ve tarayıcı uyarılarını çözmek için SSL sertifika hataları rehberimize göz atabilirsiniz.

CORS ve güvenlik başlıkları

API sunucusu ile frontend ayrı domainlerde olduğu için CORS ayarlarını doğru yapmak şart:

• Access-Control-Allow-Origin olarak yalnızca Next.js domain’inizi (örn. https://www.alanadiniz.com) tanımlayın.
• Gerekiyorsa kimlik doğrulamalı endpoint’ler için ek başlıklar (credentials, headers) ayarlayın.
• Preflight (OPTIONS) isteklerinin gereksiz yük oluşturmasını engellemek için Nginx seviyesinde basit optimizasyonlar yapın.

Ek olarak, HTTP güvenlik başlıklarını HSTS, CSP, X-Frame-Options gibi ayarlarla güçlendirmek, hem WordPress hem Next.js tarafında faydalı olur. Bunun için HTTP güvenlik başlıkları rehberimiz işin teorik ve pratik kısmını bir arada sunuyor.

Cache, CDN ve Performans İyileştirme Stratejileri

Next.js katmanında cache

Next.js zaten ISR ve SSG ile kendi içinde cache mekanizmaları sunuyor. Yine de şunlara dikkat etmek gerekiyor:

• SSG sayfalar için uzun süreli cache-control başlıkları kullanın.
• Dinamik SSR sayfalar için kısa süreli, stale-while-revalidate stratejileri uygulayın.
• Görselleri mümkün olduğunca Next.js Image bileşeni üzerinden optimize edin.

WordPress API için cache

WordPress’in API endpoint’leri genellikle okunabilir ve cache’lenebilir veri üretir. Burada üç katmanlı bir strateji kullanabilirsiniz:

1. Uygulama içi cache: WordPress tarafında nesne önbelleği (Redis/Memcached).
2. Reverse proxy cache: Nginx veya özel bir cache katmanı ile /wp-json isteklerini kısa süreli (5–60 saniye) cache’e almak.
3. CDN cache: CDN üzerinden API yanıtlarını bölgesel olarak önbelleğe almak (özellikle global kullanıcı varsa çok faydalı).

CDN entegrasyonu

Headless mimaride CDN kullanmak neredeyse zorunlu hale geliyor; çünkü hem Next.js statik dosyalarını hem WordPress ortam dosyalarını (uploads klasörü) kenara taşımak, gecikmeyi ciddi oranda azaltıyor. WordPress tarafında CDN cache kuralları, HTML cache bypass ve WooCommerce gibi dinamik kısımlarda nelere dikkat etmeniz gerektiğini WordPress için CDN önbellek kuralları rehberimizde oldukça detaylı anlattık; headless projelerde de aynı mantık işliyor.

Dağıtım (Deploy), Ortam Ayrımı ve CI/CD

WordPress için ortam stratejisi

Headless projelerde staging ortamı kritik önem taşıyor. Çünkü içerik editörleri, tasarımcılar ve geliştiriciler çoğu zaman paralel çalışıyor. Tipik bir kurgu şöyle olabilir:

• prod-api.alanadiniz.com → canlı WordPress
• staging-api.alanadiniz.com → test/staging WordPress

Staging ortamında tema/eklenti güncellemelerini, yeni API endpoint’lerini ve içerik yapılarını güvenle test ettikten sonra canlıya alırsınız. WordPress tarafında staging kurulum adımlarını adım adım anlattığımız WordPress staging ortamı rehberi burada da birebir uygulanabilir.

Next.js için CI/CD akışı

Next.js kodu tipik olarak Git üzerinde tutulur ve otomatik deploy (CI/CD) ile sunucuya aktarılır. DCHost üzerinde sık kullandığımız yaklaşım özetle şöyle:

1. Git deposuna push → CI/CD pipeline tetiklenir.
2. Pipeline build alır (npm install, npm run build).
3. Build çıktıları (örneğin .next, public) hedef sunucuya rsync/scp ile kopyalanır.
4. pm2 veya systemd üzerinden zero-downtime restart yapılır.

Git tabanlı dağıtımı nasıl kuracağınızı adım adım görmek için hazırladığımız Git ile otomatik deploy rehberi, hem cPanel/Plesk hem de VPS senaryolarında size sağlam bir temel sunar.

Blue/Green ve preview ortamları

Daha ileri seviye projelerde; Next.js için blue/green deployment veya feature branch’lere özel preview ortamları kurmak isteyebilirsiniz. Örneğin:

• mavi.alanadiniz.com → aktif canlı sürüm
• yesil.alanadiniz.com → yeni sürüm, test aşamasında

Traffic switch işlemini DNS veya Nginx seviyesinde ağırlıklı yönlendirme ile yapabilirsiniz. DCHost VPS üzerinde rsync + sembolik sürümlerle sıfır kesinti CI/CD nasıl kurulur sorusunun cevabı için de sıfır kesinti CI/CD rehberimizi inceleyebilirsiniz.

Güvenlik, İzleme ve Ölçeklendirme

Saldırı yüzeyini azaltmak

Ayrı frontend ve API sunucusu kullanmanın en güzel yanlarından biri; her katmanın sadece kendi işini yapması ve güvenlik politikalarının daha net uygulanabilmesidir:

• Next.js sunucusu: Sadece HTTP(S) trafiği kabul eder; admin panel yok, PHP yok, klasik WordPress açıkları yok.
• WordPress sunucusu: Mümkün olduğunca sadece Next.js origin’lerinden gelen API isteklerine yanıt verir; yönetim paneli ayrı IP veya VPN arkasındadır.

Temel VPS güvenlik adımlarını (güçlü SSH, firewall, güncel paketler, Fail2ban vb.) atlamamak için VPS sunucu güvenliği rehberimize göz gezdirebilirsiniz.

İzleme ve loglama

İki ayrı sunucu olduğu için izleme tarafı daha da önemli hale geliyor. Pratikte şunları öneriyoruz:

• Next.js için response time, error rate ve Node.js process sağlığı (CPU/RAM) takibi
• WordPress API için PHP-FPM kuyruğu, veritabanı gecikmeleri, 5xx hata oranı
• İki katman arasındaki timeout ve bağlantı hatalarını loglama

Uzun vadede merkezi loglama (örn. Grafana Loki + Promtail) ve metrik toplama (Prometheus) kurduğunuzda, headless mimarideki olası darboğazları çok daha hızlı tespit edebilirsiniz.

Ölçeklendirme senaryoları

Başlangıçta her şeyi tek bir güçlü VPS üzerinde bile çalıştırabilirsiniz. Ancak trafik büyüdükçe şunları sırayla yapmanız mantıklı olur:

1. Veritabanını ayrı bir VPS veya dedicated sunucuya ayırmak.
2. WordPress API sunucusunu sadece PHP + Nginx olarak sadeleştirmek, media dosyalarını obje depolamaya (S3 uyumlu) taşımak.
3. Next.js katmanını yatayda ölçeklemek; birden fazla Node.js süreci ve arada bir load balancer kullanmak.
4. CDN tarafında coğrafi önbellekleme ve akıllı cache-key stratejileriyle origin yükünü azaltmak.

Bu noktada DCHost tarafında; artan kapasite ihtiyaçlarınıza göre VPS → dedicated → colocation çizgisinde büyüyebileceğiniz esnek bir altyapı sunuyoruz. Mimarinizi baştan bu esnekliğe göre tasarlarsanız, ileride “taşıma korkusu” yaşamazsınız.

Örnek Senaryo: İçerik Odaklı Bir Headless Proje

Somutlaştırmak için gerçek hayata çok yakın bir senaryoyu kısaca özetleyelim:

• Proje: Yüksek trafikli teknoloji blogu + bülten + mikro landing sayfalar
• Backend: Headless WordPress (REST API), 2 vCPU / 4 GB RAM DCHost VPS
• Frontend: Next.js, 2 vCPU / 4 GB RAM DCHost VPS
• Veritabanı: Başlangıçta WordPress VPS üzerinde, trafik artınca ayrı DB VPS’e taşınıyor.
• CDN: Next.js statik dosyaları ve WordPress media dosyaları için aktif

Bu projede:

• WordPress sadece editörler ve yazarlar tarafından kullanılıyor, doğrudan ziyaretçi almıyor.
• Next.js herkese açık yüz; SEO, hız ve UX bu katmanda optimize ediliyor.
• API istekleri için hem Redis nesne önbelleği hem de Nginx mikro önbellekleme kullanılıyor.
• Deploy süreci Git push → CI build → DCHost VPS’e otomatik rsync + zero-downtime restart şeklinde işliyor.

Sonuç ve DCHost ile Sonraki Adımlar

Headless WordPress + Next.js mimarisi ilk bakışta karmaşık görünebilir; fakat doğru parçalara böldüğünüzde son derece yönetilebilir, hatta uzun vadede bakım maliyeti daha düşük bir yapıya dönüştüğünü görürsünüz. Ayrı frontend ve API sunucuları sayesinde hem güvenliği hem performansı hem de ölçeklendirmeyi katman katman ele alabiliyorsunuz.

Bu yazıda; mimari tasarımdan DNS/SSL yapılandırmasına, cache stratejilerinden CI/CD ve güvenliğe kadar üretim ortamında çalışabilir bir headless hosting mimarisini nasıl kurabileceğinizi anlattım. Bundan sonraki adım, gerçek projeniz için kapasite ve mimari planını netleştirmek. Bu konuda DCHost ekibi olarak; NVMe VPS, dedicated sunucu ve colocation seçeneklerimizle, hem küçük çaplı MVP’lerde hem de yüksek trafikli üretim ortamlarında yanınızdayız.

Yeni bir headless projeye başlayacaksanız ya da mevcut WordPress sitenizi Next.js ile modernleştirmeyi düşünüyorsanız; doğru kaynak planlaması ve kesintisiz geçiş için bizimle iletişime geçebilir, blogumuzdaki diğer rehberlerle (özellikle Node.js uygulamalarını nerede host etmeli ve CPU, RAM ve trafik planlama rehberi) teknik yol haritanızı adım adım şekillendirebilirsiniz.