Hosting yenileme zamanı: 2026’da nelere dikkat etmeli?

Hosting yenileme zamanı geldiğinde asıl risk çoğu zaman “hizmetin kesilmesi” değil, bir sonraki ayda performans düşüşü, beklenmedik limit hataları veya fiyat artışları yüzünden sürpriz yaşanmaktır. 2026’da özellikle kaynak limitleri, yedekleme (backup) geriye dönük erişimi ve destek SLA’sı (hizmet yanıt garantisi) daha kritik hale geldi. Bu rehberde yenileme öncesi yapmanız gereken kontrolleri, somut karar noktalarıyla sıralıyorum.

Yenileme öncesi ilk kontrol: Fiyat, kullanım koşulu ve “otomatik zam”

Hosting yenilemelerinde en büyük fark çoğunlukla satış sayfasında değil, sözleşme ve faturalandırma koşullarında ortaya çıkar. Yalnızca “yeni fiyat”ı görmek yetmez; şu üç başlığı kontrol edin:

1) Otomatik yenileme fiyatı ve artış eşiği

• Otomatik yenileme varsa, yeni dönemde tarife artışı hangi koşulla uygulanıyor?
• “İlk yıl kampanya” mı var, yoksa aynı ücret devam ediyor mu?
• Fiyat artışı yıllık mı, dönemsel mi (ör. 1 yıl / 6 ay)?

Net hedef: Yenileme anında sürpriz yaşanmaması için, faturada görünen yenileme kalemini (ürün + ek hizmet) birebir kayıt altına alın.

2) Kullanım aşımı (resource) ücretlendirmesi

Bazı planlarda CPU/RAM bant genişliği gibi unsurlar “adil kullanım” kapsamında değerlendirir. Şu ifadeler varsa detay isteyin: - “Fair use policy” - “Burst” veya “temporary usage” - “Soft limit” / “hard limit”

Net hedef: Limit aşımlarında ek ücret mi uygulanıyor, yoksa hız mı düşüyor? “Throttling” uygulanıyorsa, bunun hangi metrikte devreye girdiğini öğrenin.

3) Destek ve ek hizmet fiyatları

Yenilemede çoğu kişi sadece ana paketi görür. Oysa sorun çıktığında kritik olan ekstra kalemler şunlardır: - Ek IP veya IP adedi - DDoS koruma paketi - Yönetilen (managed) hizmetler - Yedekleme saklama süresi uzatma

Performans yenileme sinyali: kaynak limitleri, throttling ve gecikme

Yenileme kararını, geçmiş performans verilerini kullanarak alın. Sağlayıcı paneli veya kendi izleme sistemleriniz üzerinden şu metrikleri son 30 günde inceleyin.

Hız ve gecikme için pratik metrikler

• Sayfa yüklenme süresi (özellikle TTFB: Time To First Byte)
• Sunucu hataları (4xx/5xx oranı)
• CMS/uygulama hata logları (WordPress için PHP error log)

Kaynak limitleri için kontrol edilecek metrikler

• CPU kullanımı (anlık pik ve ortalama)
• RAM kullanımı (OOM/Out of memory uyarıları var mı?)
• Disk I/O ve günlük dosya büyümesi
• Aynı anda eş zamanlı istek sayısı (özellikle trafik kampanyalarında)

Aşağıdaki tablo, “yenileme öncesi karar” mantığını netleştirir:

Yedekleme (backup) ve kurtarma testleri: “var” demek yetmez

Yedekleme konusunda en sık yapılan hata, sağlayıcı “yedek alıyoruz” dese bile kurtarma sürecini sınamadan yenilemektir. Yenileme öncesi şu soruları yanıtlayın:

Yedekleme türleri ve saklama süresi

• Günlük, haftalık ve aylık yedek var mı?
• Saklama süresi kaç gün/hafta?
• Yedekler dosya sistemi mi, yoksa veritabanı + uygulama katmanı da dahil mi?

Kurtarma RTO/RPO (kritik zaman penceresi)

• RPO: Son kayıp veri miktarı (ör. 24 saatlik yedekte en fazla 24 saat kaybedersiniz)
• RTO: Kurtarma tamamlanma süresi (site ne kadar sürede geri döner?)

Net hedef: “Yedek var” yerine, geri dönüş süresini ve kapsamını yazılı şekilde alın.

Kurtarma testini 20-30 dakikada yapın

Sözleşme imzalamadan veya yenilemeden önce, küçük bir senaryo ile test edin: - Son yedekten geri dönüş (restore) için süreç adımları dokümante mi? - Geri dönüşte DNS/erişim etkileniyor mu? - Veritabanı restore sonrası site ayarları otomatik mi manuel mi?

SSL, DNS ve domain transfer riski: yenilemede kesinti nasıl önlenir?

Yenileme dönemleri genellikle SSL yenileme ve DNS değişiklikleri için de risklidir. Özellikle son 90 gün içinde SSL süre/otomasyon değişikliği gördüyseniz, yenilemeden önce sistemi doğrulayın.

SSL doğrulaması

• Sertifika yönetimi otomatik mi (Let’s Encrypt/managed SSL)?
• Sertifika süresi bitmeden otomatik yenileniyor mu?
• Hangi anahtar (certificate) ve hangi domain kapsamı (SAN/çoklu domain) destekleniyor?

DNS TTL ve kayıtların güncelliği

• DNS kayıtlarınız (A/AAAA, CNAME, MX) doğru mu?
• TTL değerleri çok mu yüksek? Taşınma/restore sırasında yayılım süresini etkiler.

Domain “yenileme” ile hosting “yenileme”yi ayırın

Hosting yenilemesiyle domain yenilemesi farklı tarihlerde olabilir. Net takip için: - Domain expiration tarihlerini ayrı tabloda yönetin - Otomatik yenileme açık mı kapalı mı kontrol edin - Privacy/lock gibi ek ayarlar (privacy lock) etkin mi doğrulayın

Destek kalitesi: yanıt süresi, prosedür ve log erişimi

Yenileme sürecinde teknik farklar kadar süreç farkı da belirleyicidir. Sağlayıcının destek yaklaşımını test etmek için şu kriterleri ölçün:

1) İlk yanıt süresi ve çözüm yaklaşımı

• SLA var mı, yoksa “genelde” gibi ifadeler mi geçiyor?
• Destek problemi sadece “sunucu yeniden başlatıldı” düzeyinde mi çözüyor, yoksa log üzerinden kök neden analizi yapıyor mu?

2) Loglara erişim

Siz sorun anında log görebiliyor musunuz? - Web server access/error log - PHP error log - Uygulama/DB loglarına erişim

Net hedef: Yenileme sonrası yalnızca “ekip bakıyor” değil, kendi kontrol panelinizden veya destekle log doğrulaması yapılabilmesi.

3) Değişiklik yönetimi (change management)

Plan yükseltme veya kaynak artırma yapılırken: - Ne zaman yapılır (örn. bakım penceresi)? - Kesinti olur mu? - Geri alma (rollback) planı var mı?

Plan yükseltme / taşıma kararı: Ne zaman VDS, ne zaman sadece hosting yenilemesi?

Yenileme yalnızca aynı paketi uzatmak değildir. Bazen “tasarruf” gibi görünen yenileme, teknik olarak daha pahalıya mal olur: performans kaybı, ek optimizasyon süresi, kesinti riski.

Aşağıdaki karar akışını doğrudan kullanın:

Eğer bu sorunlar varsa yenilemeden önce taşıma planı yapın

• CPU/RAM limitleri sürekli aşılıyor
• Disk I/O darboğazı yaşıyorsunuz ve hız düşüyor
• DB sorguları hızlı değil ve sağlayıcının depolama sınıfı net değil
• Yedek restore işlemi test edilemiyor veya RTO/RPO belirsiz

Eğer bu sorunlar varsa plan yükseltme yeterli olabilir

• Trafik dalgalı; sadece kampanya günleri kaynak artışı oluyor
• Yedekleme kapsamı yeterli ve restore testi başarılı
• Destek log erişimi sağlıyor ve TTFB makul seviyelerde

“Kontrol listesi” ile yenileme sürecini tamamlayın

Aşağıdaki listeyi maddeler halinde uygulayın. Her madde için ekran görüntüsü veya kısa not alın.

Yenileme kontrol listesi

• [ ] Yenileme faturasında görünen toplam fiyat (domain + ek servisler dahil)
• [ ] Kaynak limitleri: CPU/RAM/bant genişliği/disk için eşikler ve aşım politikası
• [ ] Throttling var mı? Varsa hangi metrikle devreye giriyor?
• [ ] Son 30 günde CPU/RAM/DB/TTFB trendleri
• [ ] Yedekleme türü (dosya+DB), saklama süresi ve restore adımları
• [ ] Kurtarma testi: restore edilebilirlik (en az bir kez doğrulayın)
• [ ] SSL otomatik yenileniyor mu? Sertifika bitiş tarihleri ve otomasyon
• [ ] DNS kayıtları doğru mu? TTL değerleri makul mi?
• [ ] Destek SLA’sı ve log erişimi (web/PHP/DB)
• [ ] Plan yükseltme/taşıma için kesinti senaryosu (bakım penceresi)

Sonuç: Yenileme tarihine kadar “kanıt” toplayıp tek seferde karar verin

Hosting yenilemesinde hedef, fiyatı “hesaba göre” değil, teknik verilerle doğrulayıp aynı süreci bir daha yaşamamaktır. Bu yazıda geçen metrikleri ve özellikle yedekleme restore testini, throttling limitlerini ve destek log erişimini yenileme tarihinden önce netleştirin. Eğer bir madde belirsiz kalıyorsa, yenilemeyi uzatmak yerine plan yükseltme ya da taşıma için aksiyon alın; aksi halde bir sonraki dönemde performans veya kesinti maliyeti aynı tasarrufu geçer.

Yenileme öncesi kontrol listesini tamamladıktan sonra, NetKıyas’ta karşılaştırma yaparak aynı kriterlerle (limit, yedekleme, destek) seçenekleri daraltın ve kararınızı tek oturumda netleştirin.