Hosting Nedir? Türleri ve Doğru Hosting Nasıl Seçilir?

Hosting nedir ve bir site ziyaretçiye nasıl ulaşır?

Hosting, bir web sitesinin HTML, görsel, CSS ve JavaScript dosyalarının her zaman internete bağlı olacak şekilde bir sunucuda barındırılması hizmetidir. MDN, web sunucusunu iki yönüyle anlatır: donanım tarafında siteye ait dosyaları saklayan ve internete bağlanan bir bilgisayar, yazılım tarafında ise URL'leri ve HTTP protokolünü anlayan bir HTTP sunucusu vardır.

Ziyaretçi bir adres yazdığında tarayıcı önce alan adının hangi IP adresine karşılık geldiğini DNS üzerinden öğrenir, sonra o adresteki web sunucusuyla konuşur. MDN'ye göre sunucu istenen URL'ye uyan bir dosya varsa onu gönderir; yoksa içeriği dinamik üretip üretemeyeceğine bakar; ikisi de olmuyorsa çoğunlukla 404 Not Found hatası döner. Dinamik sitelerde sunucuya ek olarak bir uygulama sunucusu ve veritabanı da katılır.

Alan adı ile hosting ayrı kavramlardır ve ayrı yerlerden alınabilir. MDN'nin açıkladığı gibi alan adı satın alınmaz; bir veya birkaç yıllık kullanım hakkı için ödeme yapılır ve bu hak yenilenir. Hosting ise dosyaların fiilen durduğu yerdir. İkisini birlikte düşünmek gerekir çünkü site yalnızca alan adı doğru sunucuyu gösterdiğinde açılır.

Hosting türleri nelerdir: paylaşımlı, VPS, özel sunucu ve bulut ne demek?

Hosting türleri, sunucu kaynaklarının kaç siteyle paylaşıldığına ve ne kadar yapılandırma erişimi verildiğine göre ayrılır. Aşağıdaki tanımlar kavramsaldır; sağlayıcılar paket adlarını farklı kullanabildiği için bir paketin gerçekte ne sunduğunu paket sayfasından ve yazılı teklifinden doğrulayın.

NIST'in 2011 tarihli SP 800-145 belgesi bulut bilişimi, yapılandırılabilir bilgi işlem kaynaklarından oluşan paylaşımlı bir havuza isteğe bağlı ağ erişimi sağlayan ve bu kaynakların çok az yönetim çabasıyla hızla ayrılıp bırakılabildiği bir model olarak tanımlar. NIST sözlüğü ise sanal makineyi, tek bir ana makinenin bir veya daha fazla konuk işletim sistemi çalıştırmasını sağlayan yazılım olarak da tanımlar (SP 800-115 kaynaklı tanım); VPS adı bu sanallaştırma fikriyle ilişkilidir.

Hosting türü karar tablosu: sitenizin durumuna göre hangisi düşünülmeli?

Karar, sitenizin ne yaptığına bağlıdır, ziyaretçi sayısına tek başına değil. Web.dev, hostingin sunucu yanıt süresi için ilk düşünülmesi gereken konu olduğunu söyler ve ayrımı şöyle yapar: çoğunlukla statik dosya sunan küçük bir kişisel sitede paylaşımlı hosting büyük ihtimalle yeterlidir; kişiselleştirme, veritabanı sorguları ve yoğun sunucu işlemi olan büyük uygulamalarda hosting seçimi kritik hale gelir.

Aşağıdaki tablo bu ayrımı kendi durumunuza taşımak için bir başlangıç noktasıdır. Yalnızca paylaşımlı hostingin küçük ve statik siteler için yeterli olabileceği ve yapılandırma erişimi sorulması gerektiği web.dev'e dayanır; diğer satırlar kavramsal bir çerçevedir ve kesin bir kural değildir. Sağlayıcıyla konuşurken hangi satırda olduğunuzu söyleyebilmeniz için hazırlanmıştır.

Disk, bant genişliği, işlemci ve RAM nasıl okunmalı?

Paket tablolarındaki kaynak rakamları sitenizin gerçek ihtiyacıyla karşılaştırıldığında anlam kazanır. Disk, dosyalarınızın ve veritabanınızın kapladığı yerdir; bant genişliği belirli bir sürede aktarılan veri miktarını; işlemci ve RAM ise sayfaların üretilirken kullanılan hesaplama gücünü ve belleği ifade eder.

Web.dev, hosting sağlayıcısına sorulacak sorulardan biri olarak uygulamanıza ne kadar bellek ayrıldığını sayar ve yetersiz bellekte uygulamanın zorlanacağını, sayfaları olabildiğince hızlı sunamayacağını belirtir. Bu nedenle yalnızca disk miktarına bakmak yanıltıcı olabilir; dinamik bir sitede bellek ve işlemci sınırı daha belirleyici olabilir.

• Disk kotasına e-posta kutularının, yedek dosyalarının ve günlük kayıtlarının dahil olup olmadığını sorun.
• Sınırsız ibaresi görürseniz bunun adil kullanım koşullarını ve aşım halinde ne olacağını yazılı olarak öğrenin.
• İşlemci ve RAM için eşzamanlı işlem sınırı gibi kısıtların nasıl uygulandığını, sınır aşıldığında sitenin yavaşlayıp yavaşlamadığını ya da hata verip vermediğini sorun.
• Sitenizin bugünkü dosya ve veritabanı boyutunu ölçün; bir yıllık büyüme beklentinizi bunun üzerine ekleyin.

PHP ve veritabanı sürümleri neden hosting seçiminde önemlidir?

Sunucuda çalışan PHP sürümü desteği bitmişse site güvenlik güncellemesi almayan bir yazılımla çalışıyor demektir. PHP'nin resmî sürüm destek sayfasına göre her sürüm dalı yayımlandığı tarihten itibaren iki yıl tam destek, ardından iki yıl yalnızca kritik güvenlik düzeltmesi desteği alır; dört yıl dolunca ömrünü tamamlar ve kullanıcıların bu sürümden olabildiğince çabuk geçmesi önerilir.

Aşağıdaki tablo php.net/supported-versions sayfasından 7 Ekim 2026 tarihinde okunan durumu gösterir. Bu bilgi zamanla değişir; karar vermeden önce resmî sayfayı yeniden kontrol edin.

Sağlayıcıya iki soru yöneltin: Hangi PHP sürümlerini sunuyorsunuz ve sürümü benim değiştirebilmem mümkün mü? Web.dev de iyi bir sağlayıcının arka uç dillerini, HTTP uygulamalarını ve veritabanı yazılımlarını güncel tuttuğunu belirtir. Veritabanı yazılımının adını ve sürümünü de sorun; sürüm yükseltmesi sitenizdeki tema ve eklentilerle uyumsuzluk çıkarabileceği için değişikliği önce bir test kopyasında deneyin.

Sunucunun konumu ve hosting sitenin hızını nasıl etkiler?

Sunucu konumu hızı etkileyen etkenlerden biridir ama tek başına belirleyici değildir. Web.dev'e göre TTFB, bir sayfaya gitmeye başladığınız an ile yanıtın ilk baytının gelmeye başladığı an arasındaki süredir; yönlendirmeleri, DNS sorgusunu, bağlantı ve TLS müzakeresini ve sunucunun isteği işlemesini kapsar. Aynı kaynak, 75. yüzdelik dilimde 0,8 saniye veya altını iyi, 1,8 saniyenin üzerini zayıf olarak sınıflandırır.

Web.dev, çok iyi optimize edilmiş bir uygulamanın bile kaynak sunucudan uzaktaki kullanıcılara yüksek TTFB gösterebileceğini söyler; çözüm olarak içeriği kullanıcıya yakın uç sunuculardan sunan içerik dağıtım ağlarını (CDN) anlatır. Yani hedef kitleniz belirli bir bölgedeyse konum sorusu sormak yerindedir, ancak yavaşlığın nedeni yönlendirme zinciri, ağır bir tema ya da yetersiz bellek de olabilir.

Google'ın Core Web Vitals belgesi iyi bir deneyim için en büyük içerik öğesinin (LCP) ilk 2,5 saniye içinde yüklenmesini, etkileşim gecikmesinin (INP) 200 milisaniyenin altında kalmasını ve düzen kaymasının (CLS) 0,1'in altında olmasını hedeflemenizi önerir (belge Aralık 2025'te güncellenmiştir). Web.dev, TTFB'nin bir Core Web Vitals metriği olmadığını, dolayısıyla bu metriklerde iyi sonuç almayı engellemediği sürece 'iyi' eşiğin mutlaka tutturulmasının şart olmadığını da ekler. Önce kendi sitenizi ölçün, sonra hostingi suçlayın ya da değiştirin.

1. Sayfanızı Chrome DevTools ağ panelinde açın ve ana belge isteğinin ilk bayta kadar geçen süresine bakın.
2. Aynı ölçümü WebPageTest gibi bir araçla farklı konumlardan tekrarlayın; web.dev bu araçları ölçüm için sayar.
3. Sonucu yönlendirmeler, DNS ve bağlantı süresiyle birlikte okuyun; TTFB'nin tamamı sunucudan kaynaklanmayabilir.
4. Yavaşlık sürerse sağlayıcıyla somut bir ölçümle konuşun ve önbellek, kaynak sınırı ya da konum seçeneklerini sorun.

Yedekleme, SSL, e-posta, destek ve yenileme koşullarında neyi yazılı almalısınız?

Paket tablosunda tek satırla geçen bu maddelerin her birinde sorunun ayrıntısı önemlidir. Aşağıdaki liste, sözleşme ya da teklif aşamasında yazılı cevap istemeniz gereken noktaları toplar.

SSL için web.dev, sertifikayı kurduktan sonra HTTP'den HTTPS'e 301 yönlendirmesi yapılmasını ve site içi bağlantıların protokole bağımlı olmamasını önerir; sertifikanın pakete dahil olması yönlendirmenin kurulu olduğu anlamına gelmez. Alan adı yenileme konusunda MDN, yenilemenin başkalarının başvurularına göre öncelikli olduğunu belirtir; ancak süresi dolup yenilenmeyen alan adları sonunda yeniden alınabilir hale gelir.

• Yedekleme: Yedek alınıyor mu, ne sıklıkla, kaç gün saklanıyor, yedek sizin hesabınızla aynı sunucuda mı duruyor ve geri yükleme talebi nasıl yapılıp ne kadar sürede yanıtlanıyor? Geri yükleme hiç denenmemiş bir yedeğe güvenmeyin.
• SSL: Sertifika pakete dahil mi, yenilemesi otomatik mi, HTTP adresleri HTTPS'e yönleniyor mu? Sitenizi hem http hem https ile açarak yönlendirmeyi kendiniz görün.
• E-posta: Pakette kaç e-posta hesabı ve ne kadar kota var, gönderim sınırı uygulanıyor mu, e-postalar hosting dışında ayrı bir hizmette tutulabiliyor mu?
• Teknik destek: Hangi kanaldan (telefon, e-posta, bilet sistemi) ve hangi saatlerde ulaşılıyor, ilk yanıt süresi yazılı mı, sunucu tarafı sorunlar kimin sorumluluğunda?
• Yenileme: Yenileme tarihi, yenileme bedeli ve neleri kapsadığı nerede yazıyor, ilk yıl koşulları sonraki yıllarla aynı mı, yenileme hatırlatması hangi adrese gönderiliyor?
• Çıkış koşulları: Hesabınızı kapatırsanız dosyalarınızı ve veritabanınızı hangi biçimde ve ne kadar süre içinde indirebilirsiniz?

Hosting değiştirirken (taşıma) kontrol listesi nedir?

Hosting taşımanın temel kuralı, eski sunucuyu yenisi doğrulanmadan kapatmamaktır. Google Arama Merkezi'nin URL'leri değiştirmeden barındırma sağlayıcısı değiştirmeye ilişkin rehberi bu sıralamayı izler; aşağıdaki liste o rehberi ve genel taşıma pratiğini bir araya getirir. Rehberdeki adımlar Google ile ilgilidir; e-posta, form ve eklenti gibi başlıklar için yapılan envanter önerileri genel pratiktir.

Rehberin adımları, test kopyasının yanlışlıkla dizine girmesini ve Googlebot'un yeni sunucuya erişememesini önlemeye yöneliktir. Bu liste adresler (URL'ler) aynı kaldığında geçerlidir; alan adı ya da URL yapısı da değişiyorsa Google'ın site taşıma belgesine ayrıca bakın.

1. Envanter çıkarın: sitenin dosyaları, veritabanı, e-posta hesapları, mevcut DNS kayıtlarının listesi ve varsa zamanlanmış görevler. Taşımadan önce hepsinin ayrı bir yedeğini alın.
2. Yeni hostinge sitenin tam bir kopyasını yükleyin ve geçici bir ana makine adıyla (örneğin beta.alanadiniz.com.tr gibi bir alt alan adı) yayına açın; Google'a göre test kopyasının dizine girmemesi için sayfalara noindex kuralı ekleyin.
3. Test kopyasında sayfaları, görselleri, formları ve indirilebilir dosyaları tek tek deneyin; PHP sürümünü ve veritabanı bağlantısını kontrol edin.
4. Yeni altyapının Googlebot'un erişimini engellemediğini doğrulayın. Google, Search Console URL Denetimi aracının kullanılmasını ve güvenlik duvarı ya da DoS korumasının Googlebot'u engellemediğinin kontrol edilmesini önerir.
5. Search Console doğrulama yönteminizin (HTML dosyası, meta etiketi veya Google Analytics) yeni ortamda da çalıştığını kontrol edin.
6. Taşımadan en az bir hafta önce DNS kayıtlarının TTL değerini, Google'ın örneklediği gibi birkaç saat gibi muhafazakâr düşük bir değere çekin.
7. Geçiş gününde yeni sitedeki geçici engelleri (her şeyi engelleyen robots.txt ve noindex etiketleri) kaldırın, SSL'in ve HTTPS yönlendirmesinin çalıştığını doğrulayın, sonra DNS kayıtlarını yeni sağlayıcıya yönlendirin.
8. E-posta hesaplarını ve DNS'te tanımlı diğer kayıtları test edin; e-postanız eski sağlayıcıda tutuluyorsa ilgili kayıtların yeni DNS yapılandırmasında da bulunduğundan emin olun.
9. Hem eski hem yeni sunucunun günlüklerini izleyin; Google, tarama hızında geçici dalgalanma ve ardından birkaç günde istikrarlı artış beklenebileceğini belirtir. Search Console raporlarını da takip edin.
10. Eski sunucunun günlüklerinde trafik sıfıra indikten ve Googlebot yeni sunucuya erişebildikten sonra eski hostingi kapatın; kapatmadan önce son bir yedek alın ve alan adının yenileme tarihini kontrol edin.

Sık sorulan sorular

Kaynaklar

1. MDN: Web sunucusu nedir?
2. MDN: Alan adı nedir?
3. web.dev: Time to First Byte (TTFB)
4. web.dev: Optimize Time to First Byte
5. web.dev: Enable HTTPS on your servers
6. Google Arama Merkezi: Core Web Vitals
7. Google Arama Merkezi: URL değişmeden barındırma sağlayıcısı değiştirme
8. PHP: Supported Versions (7 Ekim 2026'da okundu)
9. NIST SP 800-145: The NIST Definition of Cloud Computing (2011)
10. NIST Sözlüğü: Virtual Machine