Web Sitesi İçin Hosting Nasıl Seçilir? Sunucu Seçiminde Kritik Noktalar

Hosting seçimi, bir web sitesinin hızını, güvenliğini ve arama motorundaki görünürlüğünü sessizce belirleyen kararlardan biridir. 2012'den beri müşterilerimin sitelerini kurarken ve taşırken hep aynı hatayı görüyorum: firmalar paket fiyatına ve "sınırsız" etiketine bakıyor, kaynak sınırlarını, yedek politikasını ve destek kalitesini atlıyor. Bu yazıda sunucu seçerken baktığım kriterleri sırayla anlatıyorum. Herhangi bir firmayı önermiyorum; bunun yerine teklifleri kendiniz değerlendirebileceğiniz bir çerçeve veriyorum.

Hosting seçimi nasıl yapmalısınız, neye göre karar vermelisiniz?

Hosting seçimi, sitenizin trafik, yazılım, güvenlik ve bütçe ihtiyacına uygun sunucu türünü, konumunu ve hizmet koşullarını belirleme işidir. Önce ihtiyacı ölçer, sonra paylaşımlı, VPS, bulut veya yönetilen seçenekleri kaynak, yedek, destek ve SLA maddelerine göre karşılaştırırsınız. Fiyat en son bakacağınız kriterdir.

Pratikte bu işi dört soruya indiriyorum. Sitenizin aylık ziyaretçisi ve en yoğun saatteki eş zamanlı kullanıcı sayısı nedir? Hangi yazılımı çalıştırıyorsunuz: basit bir kurumsal site mi, WordPress mi, yoksa sepetli bir e-ticaret altyapısı mı? Sunucu yönetimini kim üstlenecek? Bir saatlik kesinti size kaça mal oluyor?

Bu soruların cevabı netleştiğinde seçenek sayısı kendiliğinden daralır. Örneğin ayda birkaç bin ziyaret alan bir tanıtım sitesi için bulut kümesi kurmak gereksiz maliyettir. Öte yandan kampanya dönemlerinde trafiği birden katlanan bir mağazayı ucuz paylaşımlı pakete sıkıştırmak, satışın en değerli anında sitenin çökmesi demektir.

Paylaşımlı, VPS, bulut ve yönetilen hosting arasındaki fark nedir?

Dört model arasındaki temel fark, kaynakları kiminle paylaştığınız ve sunucu yönetiminin kimde olduğudur. Aşağıdaki tablo, müşterilerime ilk görüşmede gösterdiğim sade karşılaştırmadır. Rakamsal performans vermiyorum, çünkü aynı model farklı sağlayıcıda çok farklı sonuç verebilir.

Kısacası paylaşımlı paket en kolay başlangıçtır, ama komşu sitelerin yükünden etkilenirsiniz. VPS size özgürlük verir, fakat güncelleme ve güvenlik sorumluluğunu da yükler. Bulut esneklik sağlar; yine de faturayı ve mimariyi takip edecek birini ister. Yönetilen hizmet ise bu yükü sağlayıcıya devretmenin bedelidir.

Paylaşımlı hosting kimler için yeterlidir?

Paylaşımlı hosting, tek sunucuyu yüzlerce siteyle bölüştüğünüz modeldir. Düşük trafikli kurumsal siteler, kişisel bloglar ve yeni başlayan projeler için çoğu zaman yeterlidir. Kontrol paneli, e-posta ve SSL genellikle hazır gelir; dolayısıyla teknik bilgi gerektirmez.

Sorun, kaynakların gerçekte ne kadar ayrıldığını bilmemenizdir. "Sınırsız disk" veya "sınırsız trafik" ifadeleri pazarlama dilidir. Sözleşmenin adil kullanım bölümünde CPU süresi, eş zamanlı işlem sayısı ve dosya sayısı (inode) gibi gizli sınırlar yazar. Siteniz bu sınırlara takıldığında hata sayfası görürsünüz, ama panelde "sınırsız" yazmaya devam eder.

Bu yüzden paylaşımlı paket alırken şu üç şeyi yazılı sorun:

• Hesap başına CPU ve RAM sınırı nedir, aşınca ne olur?
• Eş zamanlı işlem (entry process) ve inode sınırı kaçtır?
• Aynı sunucuda yaklaşık kaç hesap var?

Cevap vermekten kaçınan bir sağlayıcı, büyüdüğünüzde de size şeffaf davranmayacaktır. Açık cevap veren ise en azından sınırın nerede olduğunu baştan gösterir.

Bir de komşu etkisi var. Aynı sunucudaki başka bir site saldırıya uğrarsa veya ani bir trafik alırsa, sizin siteniz de yavaşlayabilir. Ayrıca paylaşılan IP adresi, nadiren de olsa e-posta teslimatında sorun yaratır. Bu riskler küçük bir tanıtım sitesi için genellikle kabul edilebilir düzeydedir; yine de sitenin gelir getirdiği noktada yeniden değerlendirmeniz gerekir.

VPS ne zaman mantıklı hale gelir?

VPS, fiziksel bir sunucunun sanal parçalara bölünüp her parçanın size ayrıldığı modeldir. Belirli bir CPU çekirdeği, RAM ve disk payı sizindir; ayrıca işletim sistemine tam erişiminiz olur. Böylece özel yazılım kurabilir, PHP sürümünü ve önbellek katmanını kendiniz ayarlayabilirsiniz.

Benim deneyimimde VPS'e geçiş sinyalleri genellikle şunlardır: paylaşımlı pakette kaynak uyarısı almaya başlarsınız, yoğun saatlerde yönetim paneli yavaşlar ya da çalıştırmak istediğiniz bir servis (örneğin Node.js veya özel bir kuyruk sistemi) pakete sığmaz. Bu sinyaller tek başına değil, birlikte geldiğinde geçişi ciddi olarak düşünürüm.

Ancak VPS "yönetimsiz" geliyorsa, işletim sistemi güncellemesi, güvenlik duvarı, yedek ve izleme tamamen sizin işinizdir. Teknik ekibi olmayan bir firmanın yönetimsiz VPS alıp aylarca güncelleme yapmaması, sahada en sık gördüğüm güvenlik açıklarından biridir. Kısacası VPS'i, onu yönetecek kişiyi de belirlediğinizde seçin.

Bulut sunucu her site için doğru tercih midir?

Hayır, bulut her site için doğru tercih değildir. Bulut altyapısı, kaynakları ihtiyaca göre büyütüp küçültmenize ve bileşenleri (veritabanı, dosya depolama, önbellek) ayrı servislere dağıtmanıza izin verir. Bu esneklik trafiği dalgalı ve mimarisi karmaşık projeler için değerlidir.

Öte yandan bulut faturası kullanım bazlıdır. Trafik çıkışı, depolama, anlık yedek ve yük dengeleyici gibi kalemlerin her biri ayrı ücret doğurur. Bu nedenle bütçe kontrolü yapmadan açılan bulut hesapları, ay sonunda sürpriz faturalara dönüşebilir. Ben bulut projelerinde ilk gün bütçe alarmı kurmayı zorunlu tutuyorum.

Basit bir kurumsal site veya küçük bir blog için bulut mimarisi çoğu zaman gereksiz karmaşıklıktır. Yani bulutu "modern olduğu için" değil, ölçeklenme ihtiyacınız somut olduğu için seçmelisiniz. Kampanya dönemlerinde trafiği birkaç katına çıkan e-ticaret siteleri ve SaaS ürünleri bu ihtiyacın en tipik örnekleridir.

Yönetilen hosting ek ücrete değer mi?

Yönetilen hostingde sunucunun kurulumu, güncellemesi, güvenlik yamaları, yedekleri ve çoğu zaman performans ayarı sağlayıcının sorumluluğundadır. Siz yalnız sitenizle ilgilenirsiniz. Bazı sağlayıcılar bunu belirli bir yazılıma, örneğin WordPress'e özel ayarlı paketlerle sunar.

Değip değmediğini anlamak için basit bir karşılaştırma yapıyorum. Aynı işi içeride yapmanın maliyeti nedir? Bir çalışanın ayda birkaç saatini sunucu bakımına ayırması, dışarıdan bir sistem yöneticisine ödenen ücret ve olası bir güvenlik olayının maliyeti toplandığında, yönetilen hizmetin farkı çoğu zaman makul kalır.

Yine de "yönetilen" kelimesinin sağlayıcıdan sağlayıcıya farklı anlama geldiğini unutmayın. Bu yüzden sözleşmede şu sorulara açık cevap arayın: eklenti ve tema güncellemelerini de yapıyorlar mı, yoksa yalnız sunucu katmanını mı? Hacklenen bir siteyi temizlemek hizmete dahil mi? Performans sorununda kod tarafına da bakıyorlar mı?

Sunucu konumu site hızını ve SEO'yu nasıl etkiler?

Sunucu ile ziyaretçi arasındaki fiziksel mesafe, her isteğin gidiş dönüş süresini doğrudan etkiler. Hedef kitleniz Türkiye'deyse, Türkiye'ye veya yakın bir Avrupa merkezindeki sunucu, çok uzak bir veri merkezine göre ilk bayt süresini kısaltır.

Google, ilk bayt süresi (TTFB) için web.dev rehberinde 0,8 saniye ve altını iyi bir hedef olarak gösterir. TTFB tek başına sıralama faktörü değildir, ama LCP gibi Core Web Vitals metriklerinin üstüne biner. Dolayısıyla yavaş başlayan bir sunucu, sonraki tüm optimizasyonların etkisini sınırlar. Hızın sıralamayla ilişkisini site hızının SEO üzerindeki etkisi yazısında ayrıca anlattım.

Çok ülkeye hitap eden bir site için tek sunucu konumu yetmeyebilir. Bu durumda statik dosyaları bir içerik dağıtım ağı (CDN) üzerinden sunmak, sunucu konumunun etkisini büyük ölçüde azaltır. Ancak CDN, yavaş çalışan bir veritabanını veya kötü bir sorguyu düzeltmez; yalnız mesafe sorununu çözer.

Veri konumu KVKK açısından neden önemlidir?

Siteniz form, üyelik veya sipariş üzerinden kişisel veri topluyorsa, bu verinin hangi ülkede saklandığı hukuki bir sorudur. 6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verilerin yurt dışına aktarımını belirli şartlara bağlar. Güncel düzenlemeleri ve rehberleri KVKK'nın resmi sitesinden takip edebilirsiniz.

Ben hukuk danışmanı değilim ve bu konuda nihai kararı avukatınıza bırakmanızı öneririm. Yine de sunucu seçerken sağlayıcıya şu soruları sormanızı tavsiye ederim: verim hangi ülkede, hangi veri merkezinde duruyor? Sağlayıcı yedekleri başka bir ülkeye kopyalıyor mu? Sağlayıcı alt yüklenici kullanıyor mu?

Bu soruların cevabı aydınlatma metninize ve varsa aktarım süreçlerinize doğrudan yansır. Dolayısıyla teknik ekip ile hukuk tarafının sunucu kararını birlikte vermesi, sonraki düzeltmelerden çok daha ucuzdur.

CPU, RAM ve disk ihtiyacını nasıl hesaplarsınız?

Kesin bir formül yok, ama mevcut verilerinizden gerçekçi bir tahmin çıkarabilirsiniz. İlk adım, analitik aracınızda en yoğun saatteki eş zamanlı kullanıcı sayısına bakmaktır. Aylık toplam ziyaretten çok bu tepe değer belirleyicidir, çünkü sunucu ortalamada değil zirvede zorlanır.

İkinci adım, sayfa başına sunucu işini anlamaktır. Önbellekten dönen statik bir sayfa neredeyse hiç CPU harcamaz. Buna karşılık sepet, arama ve filtre sayfaları her istekte veritabanına gider. Bu yüzden aynı ziyaretçi sayısında e-ticaret sitesi, tanıtım sitesine göre çok daha fazla kaynak ister.

• Disk türü: NVMe veya SSD olmayan bir teklifi bugün ciddiye almayın.
• RAM: veritabanı ve önbelleğin rahat sığacağı pay bırakın.
• CPU: çekirdek sayısı kadar, çekirdeğin paylaşılıp paylaşılmadığını da sorun.
• Trafik: aylık veri çıkışı sınırını ve aşım ücretini öğrenin.

Son olarak büyüme payı bırakın. Benim saha tecrübeme dayalı başlangıç önerim, tepe yükte kaynakların yaklaşık yarısını kullanacak bir paketle başlamaktır; bu bir garanti değil, ama ani trafik artışında nefes alanı sağlar.

Hosting seçiminde yedekleme politikasını nasıl sorgularsınız?

Hosting seçiminde en çok ihmal edilen konu yedektir. "Günlük yedek var" cümlesi tek başına bir şey söylemez. Yedeğin nerede tutulduğu, kaç gün geriye gittiği ve geri yüklemenin ne kadar sürdüğü asıl sorulardır.

Aynı sunucuda tutulan yedek, sunucu diski arızalandığında veya hesap ele geçirildiğinde yedekle birlikte kaybolabilir. Bu nedenle sağlayıcının yedeği farklı bir fiziksel sisteme, tercihen farklı bir konuma kopyalayıp kopyalamadığını sorun. Ayrıca kendi tarafınızda da sağlayıcıdan bağımsız, düzenli bir yedek tutun.

1. Yedek sıklığı nedir: günlük mü, saatlik mi?
2. Sağlayıcı kaç gün geriye dönük yedek saklıyor?
3. Yedek aynı sunucuda mı, ayrı bir sistemde mi?
4. Geri yükleme ücretli mi, kim yapıyor, ne kadar sürüyor?
5. Tek bir dosyayı veya yalnız veritabanını geri almak mümkün mü?

Pratikte ben bir yedeği ancak geri yükleyip test ettiğimde güvenilir sayarım. Yılda en az bir kez, test ortamına tam geri yükleme deneyin. Böylece kriz anında ilk kez deneme yapmak zorunda kalmazsınız.

Uptime garantisi ve SLA sözleşmesinde neye bakmalısınız?

SLA, sağlayıcının erişilebilirlik ve destek için verdiği yazılı taahhüttür. Tekliflerde genellikle yüzde 99,9 gibi bir uptime oranı görürsünüz. Bu oranın pratikte ne anlama geldiğini hesaplamak ise size kalır.

Örnek hesap: 30 günlük bir ay 43.200 dakikadır. Yüzde 99,9 erişilebilirlik, ayda yaklaşık 43 dakikaya kadar kesintiye izin verir. Yüzde 99 ise yaklaşık 7 saat 12 dakika demektir. Aradaki fark küçük bir yüzde gibi görünür, ama bir e-ticaret sitesi için hafta sonu akşamı yaşanan birkaç saatlik kesinti ciddi kayıptır.

Ancak oran kadar önemli olan, taahhüdün ihlal edildiğinde ne olacağıdır. Çoğu SLA, ihlal durumunda yalnız o ayın ücretinin bir kısmını kredi olarak iade eder. Yani kaybettiğiniz satışı değil, sunucu ücretinin bir parçasını geri alırsınız. Ayrıca planlı bakımların kesinti hesabına dahil olup olmadığını ve kredi için başvuru süresini sözleşmede kontrol edin.

Teknik destek kalitesini satın almadan önce nasıl test edersiniz?

Destek kalitesini anlamanın en iyi yolu, satın almadan önce destek kanalına gerçek bir teknik soru sormaktır. Satış ekibine değil, teknik destek kanalına yazın. Cevabın ne kadar sürede geldiğine ve sorunuzu gerçekten anlayıp anlamadığına bakın.

Örneğin şu tür sorular işe yarar: "PHP sürümünü site bazında değiştirebilir miyim?", "Sunucu hata günlüklerine erişimim olacak mı?", "Gece yarısı bir kesintide kime, hangi kanaldan ulaşırım?" Hazır metinle dönen, sorunuzu okumadan başka bir sayfaya yönlendiren destek, kriz anında da aynı şekilde davranacaktır.

Ayrıca desteğin hangi dillerde ve hangi saatlerde verildiğini sorun. Yurt dışı bir sağlayıcıyla çalışacaksanız, gece saatinde İngilizce teknik yazışma yapacak birinin ekibinizde olup olmadığını düşünün. Destek, sunucu donanımından çok daha sık hissedeceğiniz bir hizmettir. Bu nedenle kararı verirken destek deneyimine, en az donanım özellikleri kadar ağırlık verin. Ben de teklif karşılaştırırken destek testini ayrı bir puan olarak tabloya ekliyorum.

Güvenlik özellikleri arasında hangileri vazgeçilmezdir?

Bugün SSL sertifikası temel bir gerekliliktir; çoğu sağlayıcı ücretsiz sertifikayı otomatik yeniler. Ancak güvenlik yalnız SSL'den oluşmaz. Sağlayıcının sunucu katmanında hangi korumaları sunduğunu ve hangilerini size bıraktığını netleştirmeniz gerekir.

• Web uygulama güvenlik duvarı (WAF) veya en azından temel saldırı filtreleme.
• Hesaplar arası izolasyon: paylaşımlı sunucuda komşu site hacklendiğinde sizin siteniz de zarar görüyor mu?
• Kötü amaçlı yazılım taraması ve temizleme desteği.
• Kontrol paneli için iki adımlı doğrulama.
• Güncel PHP ve veritabanı sürümleri, eski sürümlerin ne zaman kapatılacağına dair plan.

Öte yandan en güçlü sunucu bile güncellenmemiş bir eklentiyi korumaz. Sahada gördüğüm hacklenme vakalarının büyük kısmı sunucu değil, uygulama katmanından geliyor. Dolayısıyla güvenliği sağlayıcı ile sizin aranızda paylaşılan bir sorumluluk olarak görün.

Sunucu hataları Google taramasını nasıl etkiler?

Sunucunuz sık sık hata veriyorsa, bu durum yalnız ziyaretçiyi değil Googlebot'u da etkiler. Google'ın HTTP ve ağ hataları dokümantasyonuna göre 5xx hataları ve 429 yanıtları, Googlebot'un tarama hızını düşürmesine yol açar. Hatalar uzun süre devam ederse, daha önce dizine eklenmiş adresler de dizinden düşebilir.

Bu yüzden planlı bakım sırasında sitenin 503 durum kodu döndürmesi, 200 kodlu bir "bakımdayız" sayfası göstermesinden daha doğrudur. Böylece Google sayfanın geçici olarak ulaşılamadığını anlar. Teknik tarafın diğer temel adımlarını teknik SEO rehberinde topladım.

Pratikte Search Console'daki tarama istatistikleri raporunu ayda bir kontrol etmenizi öneririm. Sunucu yanıt süresinde ani bir yükselme veya hata oranında artış görürseniz, bu genellikle hosting tarafında bir darboğazın ilk işaretidir. Sitenizin genel performansını ölçmek için Google Lighthouse ile performans testi de iyi bir başlangıç noktasıdır.

Domain, DNS ve e-posta aynı yerde mi olmalı?

Hepsini tek sağlayıcıda toplamak başta pratik görünür, ama tek bir hata noktası da yaratır. Hosting hesabınız askıya alındığında veya sağlayıcıyla anlaşmazlık yaşadığınızda, domain ve e-posta da aynı hesaba bağlıysa işiniz tamamen durur.

Bu nedenle ben müşterilerime domaini hosting firmasından ayrı, güvenilir bir kayıt firmasında ve şirketin kendi adına kayıtlı tutmalarını öneririm. E-postayı da mümkünse ayrı bir iş e-postası hizmetinde barındırmak, sunucu taşımalarında e-posta kesintisini önler. Mevcut DNS kayıtlarınızı DNS sorgulama aracıyla birkaç saniyede görebilirsiniz.

Ayrıca sağlayıcının IPv6 desteğini de kontrol edin. Mobil operatörlerin bir kısmı IPv6 ağlar kullanıyor; sitenizin bu ağlardan sorunsuz açıldığını IPv6 testi ile doğrulayabilirsiniz. Küçük bir ayrıntı gibi görünür, ama bazı kullanıcılar için yavaşlık veya erişim sorunu olarak geri döner.

E-ticaret sitesinde hosting seçimi neden farklıdır?

E-ticaret sitesi, tanıtım sitesinden farklı olarak her ziyarette sunucuya daha fazla iş yükler. Sepet, stok kontrolü, arama, filtre ve ödeme adımı önbellekten dönmez; her istek veritabanına gider. Dolayısıyla aynı ziyaretçi sayısında mağaza, kurumsal siteye göre belirgin biçimde daha güçlü bir altyapı ister.

Ayrıca mağazada kesintinin maliyeti doğrudan ölçülebilir. Kampanya gecesi yarım saatlik bir çökme, o yarım saatte gelecek siparişlerin tamamını götürür. Üstelik reklam bütçesi akmaya devam ettiği için tıklamalar boşa gider. Bu yüzden mağaza sahiplerine kampanyadan önce sunucu kapasitesini sağlayıcıyla birlikte gözden geçirmelerini öneririm.

• Kampanya öncesi sağlayıcıya beklenen trafik artışını yazılı bildirin.
• Ödeme sayfasını ve sepeti önbellek dışında tutun, geri kalanı önbelleğe alın.
• Ürün görsellerini sıkıştırın ve mümkünse CDN üzerinden sunun.
• Veritabanı yedeğini kampanyadan hemen önce ayrıca alın.

Mağaza altyapısının diğer ayaklarını e-ticaret danışmanlığı sürecinde birlikte ele alıyorum; sunucu bu resmin yalnız bir parçasıdır.

WordPress sitesi için hosting seçerken neye dikkat etmelisiniz?

WordPress, Türkiye'de kurumsal sitelerin önemli bir kısmında kullandığım ve sık karşılaştığım bir altyapıdır. Kendisi hafif bir yazılımdır; asıl yükü eklentiler, tema ve veritabanı sorguları oluşturur. Bu nedenle WordPress için sunucu seçerken PHP sürümü, nesne önbelleği ve veritabanı performansı öne çıkar.

Örneğin sağlayıcının güncel ve desteklenen bir PHP sürümü sunup sunmadığına, sürümü site bazında değiştirmenize izin verip vermediğine bakın. Ayrıca Redis veya Memcached gibi bir nesne önbelleği seçeneği, yoğun sayfalarda veritabanı yükünü azaltır. Otomatik güncelleme ve hazır kurulum araçları ise kolaylıktır, zorunluluk değildir.

Yine de şunu unutmayın: yavaş bir WordPress sitesinin sebebi çoğu zaman sunucu değil, gereksiz eklentiler ve optimize edilmemiş görsellerdir. Dolayısıyla sunucuyu değiştirmeden önce sitenin kendisini ölçün. Bazen doğru ayarlanmış bir önbellek eklentisi, daha pahalı bir pakete geçmekten çok daha fazla fark yaratır.

Hosting seçimi yaparken en sık hangi hatalara düşüyorsunuz?

Sahada tekrar tekrar gördüğüm hataları bir liste halinde toplayayım. Bunların çoğu teknik bilgi eksikliğinden değil, karar anında yanlış soruya odaklanmaktan kaynaklanıyor.

• İlk yılın indirimli fiyatına bakıp yenileme fiyatını sormamak.
• "Sınırsız" pakette adil kullanım sınırlarını okumamak.
• Yedeği yalnız sağlayıcıya bırakıp kendi kopyasını tutmamak.
• Domaini ajansın veya çalışanın kişisel hesabına kaydettirmek.
• Yönetimsiz VPS alıp güncelleme sorumlusunu belirlememek.
• Sözleşmeden çıkışta veri teslim şeklini sormamak.

Özellikle yenileme fiyatı konusu can sıkıcıdır. Birçok sağlayıcı ilk dönem için belirgin indirim yapar, yenilemede ise liste fiyatına döner. Bu yüzden karşılaştırmayı ilk yıl üzerinden değil, en az üç yıllık toplam maliyet üzerinden yapmanızı öneririm.

Hosting değiştirirken SEO'yu nasıl korursunuz?

Sunucu taşıma, adres yapısı değişmese bile risk taşır. Dosyaların eksik kopyalanması, veritabanı karakter seti sorunları, eski sunucuda unutulan yönlendirme kuralları ve yanlış DNS ayarı en sık karşılaştığım sorunlardır. Dolayısıyla taşımayı planlı ve adım adım yapmanız gerekir.

1. Taşımadan birkaç gün önce DNS kayıtlarının TTL değerini düşürün.
2. Yeni sunucuda siteyi geçici bir adresle veya hosts dosyasıyla test edin.
3. Yönlendirme kurallarının yeni sunucuda çalıştığını kontrol edin.
4. DNS'i yönlendirin ve eski sunucuyu birkaç gün açık tutun.
5. Search Console'da tarama hatalarını ilk haftalarda yakından izleyin.

Yönlendirmelerin doğru çalıştığını yönlendirme denetleyici ile tek tek doğrulayabilirsiniz. Adres yapısını da değiştireceğiniz daha kapsamlı bir geçişte site taşıma kontrol listesi işinizi kolaylaştırır.

Hosting seçimi için teklif karşılaştırma listesi nasıl olmalı?

Birden fazla teklifi yan yana koyduğunuzda, her birine aynı soruları sormanız karşılaştırmayı adil kılar. Aşağıdaki liste, benim müşterilerimle kullandığım sade kontrol listesidir. Her maddeye yazılı cevap isteyin; sözlü vaat, anlaşmazlık anında işe yaramaz.

• Sunucu türü, konumu ve veri merkezinin bulunduğu ülke.
• CPU, RAM, disk türü ve adil kullanım sınırları.
• Yedek sıklığı, saklama süresi, yedeğin konumu ve geri yükleme şartları.
• SLA oranı, ihlal durumunda tazmin şekli ve planlı bakım kuralı.
• Destek kanalları, çalışma saatleri ve ortalama ilk yanıt süresi.
• Güvenlik katmanları ve hack sonrası temizlik desteği.
• İlk dönem ve yenileme fiyatı, üç yıllık toplam maliyet.
• Sözleşme bitişinde verilerin size hangi formatta teslim edileceği.

Bu listeyi doldurduğunuzda çoğu zaman en ucuz teklifin gerçekte en pahalı olduğunu görürsünüz. Çünkü eksik kalan her madde, ileride ek ücret veya zaman kaybı olarak geri döner.

Web tasarım projesinde hosting kararını kim vermeli?

İdeal durumda hosting kararını, sitenin teknik ihtiyaçlarını bilen geliştirici ile işletmenin bütçe ve risk kararlarını veren kişi birlikte verir. Tek başına ajansa bırakılan karar bazen ajansın alışkanlığına göre şekillenir; tek başına işletmeye bırakılan karar ise çoğu zaman yalnız fiyata göre verilir.

Benim web tasarım projelerimde yaklaşımım şudur: sunucu hesabını müşterinin adına açarız, erişim bilgileri müşteride kalır, ben yetkili kullanıcı olarak çalışırım. Böylece iş ilişkisi bittiğinde bile müşteri kendi altyapısının sahibi olmaya devam eder. Bu yaklaşımı her işletmeye öneririm, kiminle çalışırsanız çalışın.

Ayrıca sitenin organik performansını düzenli izleyen bir SEO danışmanlığı süreciniz varsa, sunucu kaynaklı sorunları çok daha erken yakalarsınız. Çünkü tarama hataları ve yanıt süresi artışı, ziyaretçi şikâyetinden önce raporlara yansır.

Sonuç: doğru hosting kararını nasıl verirsiniz?

Özetle doğru sunucu, en güçlü veya en ucuz olan değil, ihtiyacınıza ve yönetim kapasitenize uyan sunucudur. Önce trafiğinizi ve yazılımınızı tanıyın, sonra modeli seçin, ardından yedek, SLA ve destek maddelerini yazılı olarak karşılaştırın. Fiyatı ise üç yıllık toplam maliyet olarak değerlendirin.

Son olarak kararınızı kalıcı sanmayın. Siteniz büyüdükçe ihtiyaç da değişir; bugün yeterli olan paylaşımlı paket, iki yıl sonra darboğaz olabilir. Bu yüzden yılda bir kez performans verilerinize, hata raporlarınıza ve faturanıza bakıp sunucu kararını yeniden gözden geçirin. Böylece hosting, işinizin arkasında sessizce çalışan bir altyapı olarak kalır.

Kararsız kaldığınız noktada küçük bir test de yapabilirsiniz. Birçok sağlayıcı iade süresi veya deneme dönemi sunar. Bu sürede sitenizin bir kopyasını kurup yanıt süresini, panel kullanımını ve desteğin tepkisini kendiniz ölçün. Böylece karar, reklam metnine değil kendi gözleminize dayanır.