Hosting Paketi Seçerken Yapılan 5 Hata ve Net Çözüm Rehberi

Hosting paketi seçimi, sadece "fiyat" ile değil; kapasite, erişim, güvenlik ve operasyon yüküyle doğrudan ilgilidir. Yanlış seçim, ilk ay sorunsuz giderken 2-3 ay sonra ortaya çıkan hız düşüşleri ve maliyet artışıyla sonuçlanır. Bu rehberde, hosting paketi seçerken yapılan 5 yaygın hatayı net kriterlerle ele alıyor; her hata için "neye bakılır" ve "nasıl çözülür" adımlarını veriyorum.

1) Trafik ve kaynakları tahmin ederken tek değişkenle düşünmek

Çoğu kullanıcı paketi “aylık ziyaret sayısı” gibi tek bir metrik üzerinden seçer. Oysa WordPress, API, görsel/stylesheet yükleri ve eşzamanlı istekler (concurrency) CPU/RAM kullanımını doğrudan etkiler. Sadece ziyaret sayısına bakmak, aynı trafik içinde farklı sayfa türlerinde ciddi sapma yaratır.

Net kontrol listesi (satın alma öncesi)

• Paket açıklamasında CPU tipi/garantisi ve RAM sınırı net mi?
• Web siteniz statik mi, dinamik mi? (ör. WordPress, WooCommerce, canlı arama)
• Önbellek (cache) kullanıyor musunuz? (sayfa cache, object cache)
• Gün içinde tepe saatler var mı? (kampanya, sosyal medya dalgası)
• Paket “limit yoktur” diyorsa, adil kullanım politikası (fair use) var mı?

Karşılaştırma: Benzer fiyatlar neden farklı performans verir?

Aşağıdaki tablo, aynı “bandwidth” algısının neden yanlış yönlendirdiğini gösterir.

Net çözüm

Mevcut siteniz varsa, son 30 günü temel alın: - CPU/RAM tepe kullanımını kontrol edin. - Veri tabanı (MySQL/MariaDB) sorgu sürelerini ve yavaş sorguları çıkarın. - Aynı anda kaç istek geldiğini (istek yoğunluğu) izleyin. Bunlar yoksa, en azından “dinamik site” senaryosu üzerinden plan yapın ve paket açıklamasındaki sınırları açıkça doğrulayın.

2) Kontrol paneli beklentisini paketin gerçek yetenekleriyle eşleştirmemek

Kontrol paneli (control panel), günlük operasyonun kalbidir: e-posta yönetimi, eklenti/tema güncellemeleri, cron işlerinin ayarlanması, log izleme ve yedeklerin yönetimi. Seçilen paket, beklediğiniz iş akışını desteklemezse sonrasında “taşıma maliyeti” oluşur.

Net hata örnekleri

• Panelde yedekleme menüsü yok veya yalnızca dosya düzeyi backup sunuluyor.
• Yönetim tarafında SSH erişimi yok (veya kısıtlı).
• Cron yönetimi, log görüntüleme gibi işlevler yok.
• E-posta tarafında SPF/DKIM/DMARC yönetimi otomatik değil; manuel yük doğuruyor.

Kontrol panelinde aramanız gereken özellikler

• Yedekleme: Dosya + veritabanı (backup) birlikte alınabiliyor mu?
• Günlük loglar: web server (nginx/apache), PHP-FPM, hata logları görüntülenebiliyor mu?
• İşlem güvenliği: panel erişimi için 2FA desteği var mı?
• Kaynak yönetimi: RAM/CPU kullanımını panelden izleyebiliyor musunuz?

Pakete göre pratik eşleştirme

Aşağıdaki hedefe göre paket türünü netleştirin: - İhtiyaç: Basit site, az otomasyon, sınırlı teknik müdahale → yönetilen hosting (managed) + temel panel fonksiyonları - İhtiyaç: Sistem düzeyi ayar, script/binary çalıştırma → daha fazla kontrol (SSH + gelişmiş cron + log) - İhtiyaç: Kaynak sınırlaması ve performans öngörülebilirliği → VDS/VPS değerlendirmesi

3) Yedekleme (backup) kavramını “tek seferlik” sanmak

Birçok kullanıcı “yedek aldılar” ifadesini duyunca rahatlar; ancak yedekleme sıklığı, saklama süresi, geri dönüş (restore) testinin yapılıp yapılmadığı netleşmez. Bu hatanın bedeli, sorun çıktığında geri dönüşün başarısız olmasıdır.

Net olması gereken 6 madde

1. Yedekleme sıklığı: Günlük mi, saatlik mi?
2. Saklama süresi: Kaç gün/hafta tutuluyor?
3. Yedek türü: Dosya + veritabanı birlikte mi?
4. Şifreleme: Yedekler taşınırken ve depoda şifreleniyor mu?
5. Geri dönüş denemesi: Sağlayıcı restore işlemi için dokümantasyon sunuyor mu?
6. Yedek bağımsızlığı: Yedekler aynı sunucuda mı, yoksa farklı depolama alanında mı?

Snapshot, gerçek backup yerine geçer mi?

“Anlık görüntü (snapshot)” bazı senaryolarda hızlı geri dönüş sağlar; fakat sadece snapshot’a güvenmek şu riskleri doğurabilir: - Uygulama tutarlılığı (application consistency) garanti edilmeyebilir. - Yedekten geri dönme süresi ve süreci belirsiz kalabilir. - Saklama politikası zayıf olabilir.

Bu yüzden paket alırken “snapshot” varsa bile şu soruyu net sorun: “Gerçek anlamda geri dönüş adımları ve saklama süreleri nasıl?”

Net çözüm

• En az günlük yedek + 7+ gün saklama hedefleyin.
• Yedek dosyalarının şifreli saklandığını doğrulayın.
• Ayda bir kez “restore test” yapın (küçük bir staging kopyasında).

4) SSL/HTTPS ve güvenlik altyapısını “sonradan hallederim” sanmak

SSL (HTTPS) kurulumu çoğu zaman zahmetsiz gibi görünür; ancak doğru paket seçilmezse SSL yenileme, otomatik doğrulama, zincir (chain) yönetimi ve HSTS gibi ayarlar gecikebilir. Bu da hem SEO hem tarayıcı güveni hem de kullanıcı deneyimini etkiler.

Net hata senaryoları

• SSL yalnızca “kurulur” denir, otomatik yenileme (auto-renewal) yoktur.
• Kontrol panelinde sertifika yönetimi yoktur; yenileme için ticket açmak gerekir.
• Let's Encrypt yerine self-signed benzeri uygulamalar önerilir.
• WAF (Web Application Firewall) veya rate limiting varsayılan değil, opsiyonel ve ücretli kalır.

Paket seçerken güvenlikte kontrol edilecek başlıklar

• SSL türü: Standart CA (Let’s Encrypt / benzeri) ve otomatik yenileme
• Sertifika yönetimi: panelde görünür mü, logları takip edilebiliyor mu?
• Güvenlik servisleri: temel WAF, bot koruması, rate limit
• Erişim: panel için erişim kısıtları ve mümkünse 2FA

5) “Ölçeklenme” planını paketin içine gömmemek

Hosting paketi seçerken en büyük hata, ölçeklenmeyi paket satın alma sürecinin dışında bırakmaktır. Trafik artsın diye beklemek yerine, hangi eşikte hangi kaynak adımının gerektiğini baştan belirlemeniz gerekir.

Net eşik mantığı (örnek)

Aşağıdaki eşikler, çoğu WordPress/benzeri dinamik web uygulaması için pratik rehberdir: - CPU tepe kullanımı sık sık %70-80 bandına çıkıyorsa - PHP süreçleri limitlere yaklaşıyorsa - Database sorguları yavaşlamaya başlamışsa - 5xx hataları veya zaman aşımları (timeout) görülüyorsa - Yükleme süreleri (özellikle TTFB) belirgin artıyorsa

Bu durumda çözüm “fiyatı artırıp bir üst pakete geçmek” olabilir; ancak bazen bu adım tek başına yetmez. Örneğin database I/O problemi varsa disk/IO karakteristiği değişmeden iyileşme sınırlı kalır.

Paket türlerine göre net yol haritası

• Paylaşımlı hosting: Küçük/orta trafik, standart gereksinimler
• VPS/VDS: Kaynak kontrolü, süreç sınırları, daha fazla konfigürasyon
• Dedicated: Yüksek tutarlılık, yoğun ve öngörülebilir performans ihtiyacı

Aşağıdaki karar tablosu, “hangisine geçmeliyim?” sorusuna net çerçeve sunar.

Net çözüm: Ölçeklenmeyi önceden yazın

Satın alırken şu 3 soruyu net cevaba bağlayın: 1. “Aynı sağlayıcıda bir üst pakete geçiş süresi ne kadar?” 2. “Geçiş sırasında veri taşıma/etki süresi nedir?” 3. “Kaynak artışı hangi metrikte oluyor (CPU/RAM/IO)?”

Bu cevaplar yoksa, ölçeklenme sürpriz maliyet doğurur.

Paketi seçmek için 10 soruluk son kontrol listesi

Satın alma öncesi sağlayıcıya veya pakete bakarak aşağıdakileri netleştirin: - Günlük kaynak limiti ve fair use var mı? - RAM/CPU ve disk türü açıkça yazıyor mu? - PHP versiyonları ve gerekli uzantılar mevcut mu? - Kontrol panelinde yedek (backup) ve geri dönüş (restore) yönetimi nasıl? - SSL otomatik yenileniyor mu? - Yedekler şifreli mi ve saklama süresi kaç gün? - Loglar (web server, PHP, sistem) erişilebilir mi? - WAF/rate limit gibi korumalar pakete dahil mi? - İşletim güvenliği için erişim kısıtları ve 2FA var mı? - Bir üst pakete geçişte kaynak artışı hangi bileşende oluyor?

Sonuç: Planı netleştir, paket seçim süresini kısalt

Hosting paketi seçerken yapılacak en büyük hata, kapasiteyi tahmin edip geçmek değil; kaynak sınırı, yedekleme/restore kabiliyeti, kontrol paneli yetenekleri ve ölçeklenme yolunu baştan netleştirmemektir. Bu rehberdeki 5 hatayı kontrol listesine göre tek tek ele alıp her maddeye “paket bunu nasıl karşılıyor?” sorusunu yanıtlayın. Son adım olarak, seçtiğiniz pakette yedek-restore ve SSL yenileme senaryolarını bir kez test planına bağlayın; böylece 2-3 hafta sonra değil, ilk günlerde doğru kararı verdiğinizi görürsünüz.