Online Dergi/Haber Sitesi İçin Hosting Seçimi: Net Rehber

Online dergi veya haber sitesi çalıştırırken asıl mesele “site açılıyor mu?” değil; trafiğin dalgalandığı saatlerde sayfa açılma süresini stabil tutmak, haber akışında hata/çökme riskini azaltmak ve büyüdükçe maliyeti öngörülebilir yapmak olur. Bu rehberde; WordPress/WP benzeri CMS, statik içerik (JAMstack) ve dinamik API kullanımına göre en uygun hosting mimarisini seçmeyi öğreneceksiniz. Ayrıca önbellekleme, CDN, TLS/SSL, veri tabanı (DB) ve günlük operasyon kontrolleri için net bir kontrol listesi bulacaksınız.

1) Haber siteleri için performans hedefi: Ne ölçmelisiniz?

Haber içerikleri genellikle kısa sürede viral olabilir. Bu yüzden CPU, bellek ve disk sadece “mevcut” değil; zirvede nasıl davrandığıyla anlam kazanır. Hosting seçmeden önce şu 3 metriği netleştirin:

Hedef 1: İlk bayt (TTFB) ve tam yükleme

Ana sayfa ve kategori sayfalarında TTFB (server response) hedefleyin.
Resim/JS/CSS ağırlığı yüksekse tam yükleme süresinin büyük kısmı CDN üzerinden belirlenir.

Hedef 2: Eş zamanlı istek (concurrency)

Haber çıktığında aynı anda çok kişi görür; bu durum kısa sürede eş zamanlı istek üretir.
VPS/VDS seçerken “kaç kullanıcı var”dan çok “kaç istek/saniye” perspektifiyle düşünün.

Hedef 3: Hata oranı (5xx/timeout)

502/503/504 gibi hatalar çoğu zaman tek noktadan kaynaklanır: uygulama, ters proxy (reverse proxy), DB veya disk.
Hostingte “sadece CPU”ya bakmak yerine loglardan kaynağı ayırmayı hedefleyin.

2) Doğru hosting tipini seçme: WordPress mi, statik mi?

Aşağıdaki karar akışı pratik sonuç verir. İlk adım olarak platform tipinizi seçin.

Senaryo A: WordPress / PHP tabanlı haber sitesi

WordPress, eklentiler (cache, SEO, görsel) ve DB (genellikle MySQL/MariaDB) nedeniyle tek başına “küçük web hosting”te bile yük dalgalanabilir.

Tercih sırası (genel yaklaşım): 1. Öncelikle VPS/VDS (minimum) + iyi cache katmanı 2. Trafik büyüyorsa managed DB veya dedicated mimari 3. Yük çok dalgalıysa “ölçekleme” yaklaşımı (otomatik ölçek ya da önden CDN)

Senaryo B: Statik haber (JAMstack) + API

Eğer içeriklerin büyük kısmı statik üretilebiliyorsa (ör. içerik derleme + CDN), dinamik ihtiyaçlar sınırlıdır.

Bu durumda temel hedef: - Uygulama sunucusunu az yüklemek - CDN üzerinde önbellek oranını maksimize etmek

Tercih sırası: 1. JAMstack hosting + CDN 2. Dinamik endpoint’ler için ayrı küçük VDS 3. Büyük büyüme olursa kademeli ölçek

Senaryo C: CMS + gerçek zamanlı API (arama, yorum, bülten)

Yorum, canlı arama, abonelik akışları gibi kısımlar DB ve kuyruk (queue) mantığı gerektirir.

Tercih: - Uygulama için VDS/VPS - DB için performans odaklı (IOPS/disk) kurgu - Gerekirse Redis benzeri cache katmanı

3) VDS vs VPS vs Dedicated: Net sınırlar

Haber sitelerinde seçim genelde şu üç farklı maliyet/riske dayanır: kaynak izolasyonu, performans tutarlılığı ve operasyon yükü.

Temel farklar

VPS: Paylaşımlı bir fiziksel sunucunun mantıksal bölümü. Kaynak paylaşımı ve komşu etkisi değişebilir.
VDS: Genellikle daha güçlü kaynak izolasyonu ve daha stabil performans hedefiyle anılır; sağlayıcıya göre detay değişir.
Dedicated: Sunucu tek kullanıcıya ayrılır. Zirve anlarında komşu etkisi yoktur.

Net seçim tablosu

Aşağıdaki tablo karar vermeyi kolaylaştırır. Değerler “kesin” değil, pratik eşiğe göre kılavuzdur.

Senaryo	İlk tercih	Neden	Ne zaman geçiş?
Yeni başlayan haber sitesi, 10-50k aylık görüntü	Paylaşımlı hosting + güçlü cache veya küçük VPS	Maliyet düşük, kurulum hızlı	Trafik dalgası uzuyorsa veya 5xx artıyorsa
Haftalık büyüme, saatlik zirveler	VPS/VDS	Uygulama kaynakları daha öngörülebilir	DB yavaşlaması veya timeout
Viral içerik ve yüksek concurrency	VDS + CDN	Zirvede stabilite ve log yönetimi	CPU/RAM sürekli %80+ ve disk IOPS yetersizse
7/24 yüksek trafik, SLA beklentisi	Dedicated	En stabil performans + kontrol	Maliyet artışı yerine operasyon verimliliği kazandırıyorsa

4) CDN + önbellek: Hosting fiyatından önce gelen gerçek kaldıraç

Haber sitelerinde çoğu kullanıcı görsel/JS/CSS tüketir. Bu trafiği uygulama sunucusundan almak için CDN ve cache şarttır.

Minimum mimari (dinamik içerik varsa)

CDN üzerinden statik dosyalar: görsel, CSS, JS
Uygulama tarafında sayfa/fragment cache
Tarayıcı cache ve CDN cache TTL

Cache stratejisi

Aşağıdaki kurallar doğrudan performans etkiler: - Ana sayfa ve kategori sayfalarında önbellek: dakika ölçeği - Haber detayı: içerik güncelleniyorsa “expire/refresh” stratejisi - Görseller: ayrı CDN cache politikası

Neden hosting kadar önemli?

Eğer CDN yoksa “haber basıldı” anında uygulama sunucusu hem HTML üretir hem de statikleri dağıtır. CDN ile statikler uygulama yükünü düşürür; aynı VDS ile daha fazla istek/saniye görürsünüz.

5) Veri tabanı (DB) seçimi: Disk IOPS ve bağlantı yönetimi

Haber sitesi için darboğaz sıklıkla DB olur. Hosting seçerken sadece CPU/RAM sormak yetmez; disk performansı ve bağlantı yönetimi sorulmalıdır.

Disk IOPS neden kritik?

WordPress gibi sistemlerde yoğun okuma + arama + yorum gibi ek işlemler olur.
DB’nin veri dosyaları diskten okur/yazar; IOPS düşükse gecikme büyür.

Net kontrol soruları (sağlayıcıya)

DB depolaması SSD mi yoksa HDD mi?
Sanal disk üzerinde paylaşımlı I/O var mı?
DB için IOPS/throughput ölçümü hangi koşullarda veriliyor?
Back end’de hangi cache (ör. query cache/OPcache/Redis) kullanılabiliyor?
Otomatik snapshot (anlık yedek) ve restore akışı nasıl?

Managed DB mi Self-hosted mı?

Managed DB: daha az operasyon, daha net bakım penceresi
Self-hosted DB: maksimum kontrol, ama bakım sorumluluğu sizde

Haber sitelerinde zaman kazanmak genelde kritik olduğundan; trafik ve ekip büyüklüğü sınırlıysa managed yaklaşım daha rasyonel olur. Trafik çok yüksekse ve mimariyi özel optimize edecekseniz self-hosted değerlendirilebilir.

6) TLS/SSL, domain ve güvenlik: Tek tıklık değil, mimari

Haber siteleri hızlı büyüdüğünde domain/sunum katmanı kritik olur.

Multi-domain SSL (SAN) ne zaman gerekir?

Birden fazla domain veya alt domain (haber.example.com, blog.example.com) kullanıyorsanız SAN (Subject Alternative Name) yaklaşımı pratik hale gelir. Bu sayede her domain için ayrı sertifika yönetimi karmaşası azalır.

DNS tarafında doğruluk

Doğru DNS kaydı performans ve e-posta tesliminde doğrudan etkili olur: - A/AAAA: kök domain yönlendirmesi - CNAME: alt domain yönlendirmesi - MX: e-posta teslim - TXT: SPF/DKIM/DMARC doğrulaması

7) Ölçekleme planı: “Büyüme olursa ne yapacağım?” sorusunu şimdiden yanıtlayın

Hosting seçimini sadece mevcut trafikle değil; 3 ay sonraki büyümeyle yapın.

3 aşamalı operasyon planı

Başlangıç: CDN + temel cache + küçük VDS/VPS
Büyüme: DB optimizasyonu, query iyileştirme, gerekirse managed DB
Zirve: dedicated veya daha güçlü instance + daha agresif cache

Ölçekleme sinyalleri (net işaretler)

Uygulama sunucusunda CPU uzun süre %80+.
DB yanıt süreleri (query latency) düzenli artıyor.
504 timeout artıyor ve loglarda uygulama veya proxy kaynaklı gecikme görülüyor.
Cache hit oranı düşüyor (ör. çok yeni içerik nedeniyle).

8) Net kontrol listesi: Satın almadan önce yapılacak testler

Hosting sağlayıcıyla çalışmaya başlamadan önce şu adımları planlayın:

Ön kontrol (POC)

24 saatlik küçük trafik simülasyonu
En çok ziyaret edilen 5 sayfada TTFB ve tam yükleme ölçümü
DB için en yoğun sorguları tespit

Log ve metrik kurulumu

Uygulama logları: hata kodları ve yavaş istekler
Web sunucusu/ters proxy logları: 4xx/5xx dağılımı
DB yavaş sorgu kaydı

Yedekleme (backup) planı

Günlük otomatik yedek
Dosya + DB birlikte geri yükleme testi
Geri yükleme süresini ölçün (restore RTO)

Sonuç: Kısa aksiyon planı

Online dergi/haber sitesi için en hızlı doğru sonuca giden yol; önce platform tipinizi (WordPress mi, JAMstack mi), sonra CDN + cache mimarisini netleştirmek ve ardından VDS/VPS/Dedicated seçiminde DB disk performansını sorgulamaktır. Bugün yapmanız gerekenler: (1) 5 kritik sayfada ölçüm alıp TTFB/timeout hedefi belirleyin, (2) CDN’i devreye alıp cache politikasını yazın, (3) sağlayıcıya DB için SSD/IOPS ve yedek (backup) restore testini sorun. Bu üç adımı tamamladıktan sonra hosting seçimi “fiyat” değil “ölçülebilir performans” üzerinden ilerler.