Hosting Değiştirme Zamanı Geldi mi? 8 Uyarı Sinyali ve Ölçüm Yolu

Hosting değiştirme zamanı geldiğini nasıl anlarsınız?

Hosting değiştirme zamanı, sitenizin kesinti, yavaşlık, kaynak limiti, eski yazılım, zayıf destek, güvenlik, yedek ya da fiyat konusunda ölçülebilir ve tekrarlayan sorun yaşadığı, üstelik sağlayıcının bu sorunu paket yükseltmeden ya da destek talebinden sonra da çözemediği andır. Kısacası kararı hisle değil, kayıtla verirsiniz.

Biz bu yazıda sekiz uyarı sinyalini tek tek ele alıyoruz. Her sinyal için ne göreceğinizi, nasıl ölçeceğinizi ve ne zaman ciddiye almanız gerektiğini anlatıyoruz. Ayrıca "yükseltmek mi, değiştirmek mi?" sorusu için basit bir karar ağacı veriyoruz. Taşıma adımlarının ayrıntısına girmiyoruz; o iş için ayrı bir kontrol listemiz var.

Önemli bir not: Talha Aslan ve ekibi bir hosting firması değil, dijital pazarlama ve web ekibidir. Bu nedenle burada belirli bir firmayı övmüyor ya da yermiyoruz. Teknik bilgileri resmi dokümanlara dayandırıyor, rakamları kaynağıyla veriyoruz.

Uyarı sinyallerini ölçmeden karar vermek neden risklidir?

Ölçmeden verilen karar çoğu zaman yanlış hedefe yönelir. Örneğin site yavaşsa suçu hemen hostinge atarsınız; oysa sorun ağır bir eklenti, boyutu büyük görseller ya da önbelleğin kapalı olması olabilir. Yeni sağlayıcıya geçtiğinizde aynı site aynı sorunla gelir ve para ile zaman boşa gider.

Bu yüzden önce dört basit kayıt düzeni kurmanızı öneriyoruz:

• Uptime izleme aracı: sitenizi dakikalık ya da birkaç dakikalık aralıklarla dışarıdan kontrol eden bir izleme servisi.
• Hız testi: Lighthouse, PageSpeed Insights ya da komut satırından TTFB ölçümü; aynı sayfayı farklı saatlerde test edin.
• Kaynak kullanım grafiği: panelinizdeki CPU, bellek, giriş süreci ve disk okuma grafikleri.
• Destek yanıt süresi kaydı: her talebin açılış saati, ilk yanıt saati ve çözüm saati.

Bu kayıtları iki ila dört hafta tutmanız genellikle yeterli bir tablo verir. Böylece "bence yavaş" yerine "akşam saatlerinde ilk bayt süresi sürekli yüksek" diyebilirsiniz. Üstelik bu kanıt, sağlayıcıyla konuşurken de elinizi güçlendirir.

Sinyal 1: Siteniz sık kesintiye uğruyor ve uptime düşük mü?

İlk sinyal en belirgin olanıdır: siteniz zaman zaman açılmıyor. Ziyaretçi boş sayfa, zaman aşımı ya da 5xx hata kodu görür. Bir kez yaşanan kısa kesinti her sağlayıcıda olabilir; ancak haftada birkaç kez tekrarlıyorsa bu bir örüntüdür.

Uptime oranını kendi izleme kaydınızla ölçün, sağlayıcının durum sayfasına güvenmeyin. Hızlı bir kontrol için site çöktü mü aracı işe yarar; fakat sürekli kayıt için dışarıdan izleyen bir servis gerekir.

Örnek hesap: 30 günlük bir ay 43.200 dakikadır. Yüzde 99,9 uptime, ayda yaklaşık 43 dakika kesintiye izin verir. Yüzde 99 ise yaklaşık 432 dakika, yani 7 saati aşan bir kesinti demektir. Sözleşmedeki oranı bu şekilde dakikaya çevirin.

Kesinti kaydında yalnız süreye değil, saate de bakın. Kesintiler hep gece bakım saatinde mi oluyor, yoksa gündüz trafiğin yoğun olduğu anlarda mı? Gündüz tekrarlayan kesinti, planlı bakımdan çok kapasite ya da altyapı sorununa işaret eder. Ayrıca sağlayıcının kesintiyi önceden duyurup duyurmadığını not edin; habersiz bakım da güven sinyalidir.

Kesinti SEO tarafını da etkiler. Google Search Central, 5xx ve 429 hatalarının tarayıcıları geçici olarak yavaşlattığını, kalıcı sunucu hatası veren adreslerin ise zamanla dizinden düştüğünü resmi belgesinde açıklıyor. Dolayısıyla tekrarlayan kesinti yalnız satış kaybı değil, görünürlük riski de taşır. Hatanın türünü anlamak için 503 Service Unavailable rehberimize bakabilirsiniz.

Sinyal 2: Site yavaş mı, TTFB sürekli yüksek mi?

İkinci sinyal yavaşlıktır; ancak her yavaşlık hosting kaynaklı değildir. Sunucu tarafını ayırmanın en iyi yolu TTFB, yani ilk bayt süresidir. web.dev, TTFB değerini sayfaya gitmeye başlamakla yanıtın ilk baytının gelmesi arasındaki süre olarak tanımlar.

web.dev'in TTFB rehberine göre çoğu site 0,8 saniye ya da altını hedeflemelidir; 1,8 saniyenin üstünü ise zayıf sayar. Bu süre yönlendirme, DNS sorgusu, bağlantı ve TLS el sıkışması ile sunucunun yanıt hazırlama süresini kapsar.

Komut satırından kaba bir ölçüm için şunu kullanabilirsiniz:

curl -o /dev/null -s -w "dns: %{time_namelookup}\nbaglanti: %{time_connect}\ntls: %{time_appconnect}\nilk bayt: %{time_starttransfer}\n" https://example.com/

Ölçümü günün farklı saatlerinde, önbelleği atlayan bir sayfada tekrarlayın. Eğer DNS ve bağlantı süreleri normal, ilk bayt süresi ise yüksekse sorun büyük ihtimalle sunucu ya da uygulama tarafındadır. Ardından sunucu kaynaklı yavaşlık nedenleri yazımızdaki teşhis sırasını izleyin. Ön yüz kaynaklı sorunları ayırmak için Lighthouse ile performans testi de işinize yarar.

Sinyal 3: Sürekli kaynak limiti hatası mı alıyorsunuz?

Paylaşımlı hostingde her hesabın bir CPU, bellek, eş zamanlı süreç ve disk okuma yazma sınırı vardır. Bu sınır doğal ve adildir; çünkü aynı sunucuyu başka hesaplarla paylaşırsınız. Sorun, sınıra sürekli takılmanızdır.

Belirtiler genellikle şöyledir:

• Kampanya ya da bülten gönderiminden sonra sitenin "kaynak limitine ulaşıldı" benzeri bir uyarı göstermesi.
• Yönetim panelinin yavaş açılması ve kayıt sırasında zaman aşımı.
• Cron görevlerinin yarıda kalması.
• Panelinizdeki kaynak kullanım grafiğinde sık sık tavana vuran çizgiler.

Ölçüm için panelinizdeki kaynak kullanımı ekranına bakın. Hangi kaynağın tavana vurduğunu ve bunun hangi saatlerde olduğunu not edin. Örneğin CPU her gece aynı saatte doluyorsa bir yedekleme ya da cron görevi suçlu olabilir. Bu durumda hostingi değiştirmek yerine görevi daha sakin bir saate almak ya da parçalara bölmek yeter.

Öte yandan normal trafikte bile sınıra dayanıyorsanız siteniz paketinizi aşmıştır. Bu noktada ilk soru "değiştirmeli miyim?" değil, "bir üst pakete mi geçmeliyim?" olmalıdır. Paylaşımlı ortamda hesap izolasyonunun nasıl işlediğini merak ediyorsanız CageFS yazımız konuyu açıklıyor.

Sinyal 4: Hosting güncel PHP ve yazılım sürümlerini destekliyor mu?

Dördüncü sinyal sessizdir ama tehlikelidir. Sağlayıcınız eski PHP, veritabanı ya da web sunucusu sürümlerinde takılı kalmışsa siteniz zamanla güvenlik açığı biriktirir. Ayrıca yeni eklenti ve tema sürümleri eski ortamda çalışmayı reddedebilir.

PHP'nin resmi desteklenen sürümler sayfası yaşam döngüsünü açıkça anlatır: her sürüm dalı ilk kararlı sürümünden itibaren iki yıl tam destek, ardından iki yıl yalnızca kritik güvenlik düzeltmesi alır. Dört yıl dolunca dal destek dışı kalır ve artık yama gelmez.

Nasıl ölçersiniz? Panelinizde PHP sürüm seçicisine bakın ve sunulan sürümleri resmi sayfadaki destek tablosuyla karşılaştırın. Eğer en yeni seçenek bile güvenlik desteği bitmiş bir dalsa, bu açık bir uyarıdır. cPanel kullanıyorsanız cPanel PHP sürümü değiştirme rehberimiz adımları gösterir.

Yine de önce siteyi güncel sürümde bir kopya üzerinde test edin. Bazen sorun hostingde değil, sitenin eski kodundadır; sağlayıcı yeni sürümü sunduğu hâlde site geçemez. Bu durumda yapmanız gereken hosting değiştirmek değil, kodu güncellemektir.

Sinyal 5: Destek ekibi yavaş ve yetersiz mi kalıyor?

Hosting yalnız sunucu değil, aynı zamanda sorun anında arayacağınız ekiptir. Kesinti sırasında saatlerce yanıt alamıyorsanız ya da her talebe hazır kalıp metinle dönülüyorsa, en iyi donanım bile sizi korumaz.

Bunu da ölçün. Basit bir tabloda her talep için şu alanları tutun: talebin konusu, açılış saati, ilk yanıt saati, çözüm saati ve çözümün kalıcı olup olmadığı. Birkaç hafta sonra ortalama ilk yanıt süresini ve aynı sorunun kaç kez tekrarlandığını görürsünüz.

İyi bir destek deneyimini şu belirtilerden tanırsınız:

• İlk yanıt, sözleşmede ya da sitede yazan süreye uyar.
• Yanıt, sorunun nedenini açıklar; yalnızca "çözüldü" demez.
• Teknik soruya teknik bilgiyle döner, sizi gereksiz yere yükseltmeye yönlendirmez.
• Aynı sorun tekrarladığında kök nedeni araştırır.

Destek kanallarını da kontrol edin. Yalnız e-posta ile mi yanıt veriyorlar, acil durumda telefon ya da canlı destek var mı? Sizin iş saatinizle onların çalışma saati örtüşüyor mu? Bu soruların yanıtı, özellikle e-ticaret sitelerinde doğrudan gelir kaybına dönüşür.

Sinyal 6: Güvenlik olayları ve yamasız sunucu ne anlatır?

Siteniz birden fazla kez zararlı yazılım bulaşmasıyla karşılaştıysa, e-postalarınız spam listesine düştüyse ya da sağlayıcı güvenlik güncellemelerini aylarca geciktiriyorsa, bu ciddi bir sinyaldir. Ancak burada sorumluluğu doğru ayırmanız gerekir.

Paylaşımlı hostingde işletim sistemi, web sunucusu ve sunucu düzeyindeki güvenlik duvarı genellikle sağlayıcının sorumluluğundadır. Öte yandan CMS, tema, eklenti ve yönetici parolaları sizin sorumluluğunuzdadır. Saldırıların büyük kısmı eski sürümde kalan eklentilerden ya da zayıf parolalardan gelir; bu durumda hostingi değiştirmek sorunu çözmez.

Nasıl ölçersiniz? Şunları not edin: olay tarihi, giriş yolu (biliniyorsa), sağlayıcının tepki süresi ve temizlik sonrası tekrar olup olmadığı. Ayrıca SSL sertifikanızın düzgün yenilenip yenilenmediğini SSL sorgulama aracı ile kontrol edin.

Eğer kendi tarafınızı temizlediğiniz hâlde olaylar sürüyorsa, ya da sağlayıcı aynı sunucudaki başka hesaplardan gelen bulaşmayı engelleyemiyorsa, artık hosting değiştirme seçeneği masaya gelir. Web uygulamalarında sık görülen açıkları anlamak için OWASP Top 10 yazımıza göz atabilirsiniz.

Sinyal 7: Yedekleme ve geri yükleme güvencesi var mı?

Birçok paket "otomatik yedek" der; ancak asıl soru o yedekten gerçekten geri dönüp dönemeyeceğinizdir. Yedeğin nerede tutulduğu, kaç gün geriye gittiği ve geri yüklemenin kim tarafından ne kadar sürede yapılacağı yazılı değilse, aslında güvenceniz yoktur.

Bunu ölçmenin tek dürüst yolu geri yükleme denemesidir. Bir test alt alan adı ya da kopya site üzerinde son yedeği geri yükleyin ve sürenin ne kadar tuttuğunu kaydedin. Eğer geri yükleme ek ücretliyse, günlerce sürüyorsa ya da yedek aynı sunucuda duruyorsa bu bir uyarıdır.

Şu soruların yanıtını sağlayıcınızdan yazılı olarak isteyin:

1. Yedeği hangi sıklıkla alıyorsunuz ve kaç gün saklıyorsunuz?
2. Yedek, sitenin bulunduğu sunucudan ayrı bir yerde mi duruyor?
3. Tek bir dosyayı ya da yalnız veritabanını geri yükleyebiliyor musunuz?
4. Geri yükleme ücretli mi, ne kadar sürüyor?

Yine de sağlayıcının yedeği tek güvenceniz olmamalı. Kendi kopyanızı ayrı bir yerde tutmanız gerekir; bunun mantığını web sitesi yedekleme stratejisi yazımızda anlattık.

Sinyal 8: Beklenmedik zamlar ve yenileme tuzaklarını nasıl fark edersiniz?

Son sinyal teknik değil, ticari: ilk yıl cazip görünen fiyat, yenilemede belirgin biçimde artar. Üstelik paket içeriği sessizce daralır ya da daha önce dahil olan bir özellik ek ücrete dönüşür. Bu tek başına kötü niyet anlamına gelmez; ancak bütçe planınızı bozar.

Bunu fark etmek için faturalarınızı yan yana koyun. İlk dönem fiyatı, yenileme fiyatı ve paket içeriğindeki değişiklikleri bir tabloya yazın. Sözleşmede yenileme koşullarının nerede yazdığına, iade ve iptal süresine, uzun dönem taahhüdün sizi bağlayıp bağlamadığına bakın.

Esneklik de önemlidir. Bir üst pakete geçerken kesinti olmadan geçebiliyor musunuz? Dönem ortasında paket düşürmek mümkün mü? Alan adı, SSL ya da e-posta gibi hizmetler aynı sağlayıcıya kilitli mi? Bu sorulara olumsuz yanıt alıyorsanız ileride taşınmanız zorlaşır.

Bu yazıda bilerek fiyat rakamı vermiyoruz; çünkü fiyatlar sağlayıcıya, kura ve döneme göre sürekli değişir. Sizin için önemli olan oran ve koşuldur: yenileme farkı, kilitlenme riski ve çıkış maliyeti.

Sekiz uyarı sinyalini tek tabloda nasıl özetleriz?

Aşağıdaki tablo her sinyali, ölçüm yolunu ve ilk adımı bir arada gösterir. Hosting değiştirme kararından önce bu tabloyu kendi kayıtlarınızla doldurun.

Tek bir sinyal genellikle değiştirmek için yeterli değildir. Ancak iki ya da üç sinyal aynı anda ve tekrarlayarak görünüyorsa, artık ciddi bir karar anındasınız.

Ucuz görünen pakete geçmek neden iyi bir sinyal değildir?

Bu bölüm sekiz sinyalin dışında, ama önemli. "Başka yerde daha ucuz" düşüncesi kendi başına hosting değiştirmek için iyi bir gerekçe değildir. Fiyat farkı, taşıma süresi, olası kesinti ve SEO riskiyle birlikte düşünülmelidir.

Ucuz görünen paketlerde sık rastlanan noktalar şunlardır:

• Uzun dönem ödeme şartıyla gösterilen düşük aylık fiyat.
• Yenilemede belirgin artış.
• Yedek, SSL ya da e-posta gibi kalemlerin ayrı ücretlendirilmesi.
• Kaynak sınırlarının açıkça yazılmaması.

Örneğin aylık birkaç yüz liralık fark için siteyi taşırsanız, taşımaya harcadığınız mesai ve olası bir gün kesinti bu farkı kolayca yer. Öte yandan mevcut sağlayıcınız yukarıdaki sinyallerden hiçbirini vermiyorsa, sadece fiyat için yer değiştirmek çoğu zaman gereksiz bir risktir.

Kısacası doğru soru "nerede daha ucuz?" değil, "aynı güvenceyi hangi toplam maliyetle alırım?" olmalıdır.

E-ticaret sitesinde bu sinyalleri farklı mı okumalısınız?

Evet, çünkü e-ticarette her dakikalık kesinti doğrudan sepete ve ödemeye yansır. Tanıtım sitesinde bir saatlik kesinti can sıkıcıdır; ancak kampanya günündeki bir mağazada aynı kesinti ciroyu ve reklam bütçesini birlikte yakar. Reklam tıklaması gelmeye devam eder, ziyaretçi ise hata sayfası görür.

Bu yüzden e-ticaret sitesinde eşikleri daha sıkı tutmanızı öneriyoruz. Ödeme ve sepet sayfalarını ana sayfadan ayrı izleyin; bu sayfalar önbellek dışında çalıştığı için sunucu zayıflığını ilk onlar gösterir. Ayrıca yoğun dönem öncesinde kaynak grafiğine bakın ve geçen kampanyada tavana vurup vurmadığınızı kontrol edin.

Destek ve yedek sinyalleri de mağazada daha ağır basar. Sipariş verisi her saat değişir; bu nedenle günlük yedek bile bazen yetmez. Hız ile satış arasındaki ilişkiyi merak ediyorsanız e-ticarette sayfa hızı yazımıza bakabilirsiniz. Kısacası mağaza sahibi sinyalleri daha erken ciddiye almalıdır.

Yükseltmek mi, hosting değiştirmek mi? Karar ağacı nasıl işler?

Sinyalleri gördünüz; peki şimdi ne yapacaksınız? Aşağıdaki karar ağacı, gereksiz taşımayı önlemek için sırayla sormanız gereken soruları gösterir.

1. Sorun sitenizden mi kaynaklanıyor? Eklentileri, görselleri ve önbelleği kontrol edin. Evetse önce siteyi düzeltin.
2. Sorun kaynak yetersizliği mi? Normal trafikte limite takılıyorsanız aynı sağlayıcıda bir üst pakete geçmeyi düşünün.
3. Sağlayıcı yükseltme ile sorunu çözüyor mu? Yükseltme sonrası iki hafta ölçün. Sorun geçtiyse kalın.
4. Sorun kalite ya da güven mi? Kesinti, destek, güvenlik ya da yedek sorununu daha büyük paket gidermez. Bu durumda değiştirmeyi planlayın.
5. Ticari koşullar kabul edilebilir mi? Yenileme tuzağı ya da kilitlenme varsa, teknik sorun olmasa bile çıkış planı yapın.

Yükseltme adımlarını kesintisiz yapmak için hosting paketi yükseltme rehberimizi izleyebilirsiniz. Karar ağacının ilk iki adımı çoğu zaman taşımaya gerek bırakmaz.

Sorun hostingde mi, sitenizde mi nasıl ayırt edersiniz?

Bu ayrımı yapmadan verilen her karar yarım kalır. Basit bir yöntem şudur: sunucu tarafını ve uygulama tarafını ayrı ayrı test edin.

İlk olarak sunucuda boş ya da çok hafif bir test sayfası oluşturun, örneğin yalnız düz HTML içeren bir dosya. Bu sayfanın ilk bayt süresi de yüksekse sorun sunucu, ağ ya da DNS tarafındadır. Ardından aynı ölçümü sitenizin ana sayfasında yapın. Düz sayfa hızlı, ana sayfa yavaşsa yük uygulamanızda demektir.

Şu kontroller de ayrımı netleştirir:

• Eklentileri bir kopya sitede tek tek kapatıp TTFB'nin değişip değişmediğine bakın.
• Sayfa önbelleği ve PHP opcode önbelleğinin açık olduğundan emin olun.
• Veritabanındaki ağır sorguları geliştiricinizle inceleyin.
• DNS sorgusunun hızlı ve tutarlı olduğunu kontrol edin.

Uygulama tarafındaki darboğazlar genellikle hosting değişikliğiyle kaybolmaz. Hatta daha güçlü bir sunucu bile verimsiz çalışan bir eklentiyi ancak kısa süre örtebilir. Bu nedenle teşhisi bitirmeden taşımaya başlamayın.

Sağlayıcıya kanıt dosyasını nasıl hazırlarsınız?

Hosting değiştirmeden önce mevcut sağlayıcıya bir şans vermek hem adil hem de pratiktir. Ancak bu şansı kanıtla vermeniz gerekir. Düzenli ve tarihli bir talep, belirsiz bir şikâyetten çok daha hızlı sonuç alır.

Kanıt dosyanızda şunlar bulunsun: uptime izleme raporundan kesinti tarihleri ve süreleri, farklı saatlerde yaptığınız TTFB ölçümleri, kaynak grafiğinin ekran görüntüleri ve önceki destek taleplerinin numaraları. Her maddeyi kısa ve tarihli yazın.

Talebi gönderirken net bir soru sorun: "Bu sorunun nedeni nedir ve hangi tarihe kadar çözeceksiniz?" Böylece sağlayıcının yanıtı da ölçülebilir hâle gelir. Eğer yanıt gelmezse ya da sorun çözüm tarihinden sonra sürerse, kararınızı belgelerle verdiğinizden emin olursunuz.

Ayrıca bu dosya ileride yeni sağlayıcıyla konuşurken de işe yarar. Hangi ölçümde ne beklediğinizi somut olarak söyleyebilirsiniz.

Hosting değiştirme kararı verdiyseniz taşımayı nasıl planlarsınız?

Karar netleştiyse, taşımayı panikle değil plana göre yapın. Biz burada yalnız ana hatları veriyoruz; adım adım liste için hosting değiştirme ve site taşıma kontrol listemizi kullanın.

Ana hatlar şöyledir. Önce yeni hesabı açın ve eski hesabı kapatmayın. Ardından dosyaları, veritabanını ve e-posta hesaplarını kopyalayın. Sonra siteyi yeni sunucuda, DNS değişmeden önce hosts dosyası ya da geçici adresle test edin. DNS kayıtlarının TTL değerini taşımadan önce düşürmek, geçişin daha hızlı yayılmasına yardım eder.

DNS değiştikten sonra birkaç gün iki sunucuyu da açık tutun. Böylece eski adrese düşen ziyaretçi ya da e-posta kaybolmaz. Kayıtların doğru yayıldığını DNS sorgulama aracı ile kontrol edebilirsiniz.

Taşıma tarihini de bilinçli seçin. Kampanya, indirim ya da yoğun sezon dönemlerinde taşıma yapmayın; trafiğin en düşük olduğu günü tercih edin.

Hosting değişikliğinde SEO tarafında nelere dikkat etmelisiniz?

Yalnız sunucu değişiyor, alan adı ve URL yapısı aynı kalıyorsa SEO riski genellikle düşüktür. Yine de birkaç noktayı atlamamanız gerekir; çünkü küçük bir hata bile tarama ve dizine eklemeyi etkileyebilir.

Taşıma sonrası şunları kontrol edin:

• Tüm sayfaların 200 durum kodu döndürdüğünü ve 5xx hata vermediğini.
• robots.txt dosyasının yanlışlıkla tüm siteyi engellemediğini.
• SSL sertifikasının yeni sunucuda kurulu ve geçerli olduğunu.
• Yönlendirmelerin (www, https) eski hâliyle aynı çalıştığını.
• Search Console'da tarama hatalarında ani artış olmadığını.

Eğer taşımayla birlikte alan adı, URL yapısı ya da platform da değişiyorsa iş büyür. Bu durumda SEO migration kontrol listemizi ayrıca uygulayın. Böylece yönlendirme haritası ve sıralama takibi gibi adımları atlamazsınız.

Yeni sağlayıcıyı seçerken aynı hatayı nasıl tekrarlamazsınız?

En sık yapılan hata, eski sağlayıcıdan kaçarken yalnız fiyata bakıp benzer bir sağlayıcıya düşmektir. Bunu önlemenin yolu, yukarıdaki sekiz sinyali yeni sağlayıcı için soru listesine çevirmektir.

Yani yeni sağlayıcıya şunları sorun: Uptime taahhüdünüz ne ve ihlalde ne oluyor? Kaynak sınırları açıkça yazılı mı? Hangi PHP sürümlerini sunuyorsunuz ve ne sıklıkla güncelliyorsunuz? Destek kanalları ve ilk yanıt süreniz ne? Yedek nerede duruyor ve geri yükleme nasıl işliyor? Yenileme fiyatı ve iptal koşulları neler?

Yanıtları yazılı alın ve deneme süresi ya da iade hakkı varsa ilk haftalarda kendi ölçümlerinizi yapın. Seçim kriterlerinin tamamı için web sitesi için hosting nasıl seçilir yazımızı okuyabilirsiniz.

Son olarak ihtiyacınızı doğru tanımlayın. Basit bir tanıtım sitesi ile yoğun trafikli bir e-ticaret sitesinin ihtiyacı aynı değildir. Gereğinden büyük paket para kaybıdır; gereğinden küçük paket ise birkaç ay sonra aynı sinyalleri geri getirir.

Hangi işleri kendiniz yapmamalı, sağlayıcıya ya da uzmana bırakmalısınız?

Dürüst olmak gerekirse her hosting sorununu kendiniz çözmeye çalışmamalısınız. Paylaşımlı hostingde sunucu yazılımı, işletim sistemi yamaları, donanım arızası ve ağ sorunları sağlayıcının işidir. Bu konularda kendi başınıza çözüm aramak zaman kaybıdır.

Benzer şekilde e-posta trafiği yoğun bir işletmeyseniz, e-posta taşımasını deneme yanılma ile yapmayın. MX, SPF ve DKIM kayıtlarındaki bir hata, günlerce kayıp e-posta anlamına gelebilir. Bu adımları sağlayıcının taşıma ekibiyle ya da deneyimli bir uzmanla planlayın.

Öte yandan ölçüm, kayıt tutma ve karar verme sizin elinizde kalmalıdır. Kendi VPS'ini yöneten biriyseniz sunucu güvenliği ve güncellemeleri de sizin sorumluluğunuzdadır; bu yükü taşıyamıyorsanız yönetilen hosting seçeneği daha doğru olabilir.

Ekibimiz web sitesi tarafında, yani hız, yapı ve taşıma sonrası SEO kontrolünde destek veriyor. Siteyi yeniden ele almayı düşünüyorsanız web tasarım hizmetimize göz atabilirsiniz.

Kısa kontrol listesi: bugün nereden başlamalısınız?

Bu yazıdan tek bir şey alacaksanız, ölçmeden karar vermeyin. Bugün başlayabileceğiniz adımlar şunlardır:

1. Dışarıdan bir uptime izleme servisi kurun.
2. Ana sayfa ve önemli bir alt sayfa için günde birkaç kez TTFB ölçün.
3. Panelinizdeki kaynak grafiğini haftada bir kontrol edin.
4. PHP sürümünüzü resmi destek tablosuyla karşılaştırın.
5. Destek taleplerinizi tarih ve saatle kaydedin.
6. Bir yedeği test ortamına geri yükleyin.
7. Son iki faturanızı ve sözleşmenin yenileme koşullarını okuyun.

İki ila dört hafta sonra elinizde net bir tablo olur. Sinyaller tekrarlanıyorsa önce yükseltmeyi, o da çözmüyorsa hosting değiştirme planını devreye alın. Böylece kararı his yerine veriyle vermiş olursunuz.