Hosting seçerken neye bakıyorum?
Hosting seçiminde yalnız disk alanı ve trafik kotasına bakmak yeterli değildir.
Değerlendirdiğim başlıklar:
- CPU,
- RAM,
- disk I/O,
- PHP worker,
- database performansı,
- network,
- backup,
- güvenlik,
- uptime,
- support,
- server location,
- ölçekleme,
- staging.
Bir WordPress sitesi ile özel Laravel uygulaması aynı altyapıya ihtiyaç duymaz.
Shared hosting kötü mü?
Her zaman hayır.
Küçük ve düşük trafikli bir kurumsal site için kaliteli shared hosting yeterli olabilir.
Ancak:
- yüksek trafik,
- WooCommerce,
- ağır WordPress,
- özel uygulama,
- yoğun API,
- çok sayıda eşzamanlı kullanıcı
varsa daha fazla kaynak veya farklı mimari gerekebilir.
VPS her zaman daha iyi mi?
Hayır.
VPS size daha fazla kontrol verebilir.
Ama aynı zamanda:
- sistem güncelleme,
- firewall,
- backup,
- monitoring,
- database,
- mail,
- güvenlik
sorumluluğu getirir.
Kötü yönetilen VPS, iyi yönetilen shared hosting’den daha kötü olabilir.
Managed hosting
Managed yapı bazı projelerde:
- güncelleme,
- backup,
- monitoring,
- güvenlik,
- teknik destek
yükünü azaltabilir.
Ancak sağlayıcının gerçekten neyi yönettiği sözleşmede açık olmalıdır.
“Managed” kelimesi her firmada aynı kapsamı ifade etmez.
Doktor ve klinik sitelerinde altyapı
Sağlık sitelerinde özellikle:
- doktor fotoğrafları,
- çok dilli içerik,
- form,
- analytics,
- CRM entegrasyonu,
- randevu,
- yüksek organik trafik
altyapıyı etkileyebilir.
Ancak hosting seçimi sağlık sektörüne özel bir marka satın almak anlamına gelmez.
Asıl ihtiyaç:
güvenilir ve doğru yapılandırılmış altyapıdır.
Domain adı kimin adına kayıtlı?
Bir işletmenin alan adı:
ajansın çalışanı
veya:
web tasarımcının kişisel hesabı
üzerinde olmamalıdır.
İdeal olarak:
domain ownership
müşteri/işletmenin kontrolünde olmalıdır.
Teknik danışman:
manager / delegated access
ile çalışabilir.
Aynı prensibi:
- hosting,
- Cloudflare,
- Search Console,
- Analytics,
- Google Business Profile
gibi sistemlerde de mümkün olduğunca uygularım.
Domain kaybedilirse site de e-posta da gidebilir
Domain yalnız web sitesi adresi değildir.
Aynı domain:
- web sitesi,
- kurumsal e-posta,
- DNS,
- API,
- subdomain,
- doğrulama kayıtları
için kullanılabilir.
Domain süresinin dolması işletmenin birden fazla sistemini aynı anda etkileyebilir.
Bu nedenle:
- auto-renew,
- güvenli hesap,
- MFA,
- güncel ödeme yöntemi,
- yetkili kişiler
kontrol edilmelidir.
DNS nedir?
DNS en basit anlatımla domain adının hangi sistemlere bağlanacağını belirler.
Örneğin:
A / AAAA
Web sunucusu.
CNAME
Başka bir hostname’e yönlendirme.
MX
E-posta sunucusu.
TXT
SPF, DKIM, doğrulamalar ve farklı servis kayıtları.
DNS yanlış değiştirildiğinde:
site çalışırken e-posta bozulabilir
veya:
e-posta çalışırken site açılmayabilir.
Bu nedenle DNS değişikliklerini kayıt bazında yapıyorum.
Nameserver değişimi neden risklidir?
Nameserver değiştirirken eski DNS zone’daki tüm kayıtlar yeni sağlayıcıya taşınmazsa:
- web,
- mail,
- verification,
- subdomain,
- API
kayıtları kaybolabilir.
Bu nedenle nameserver değişiminden önce:
tam DNS inventory
çıkarılmalıdır.
Cloudflare ne sağlar?
Cloudflare gibi reverse proxy/CDN sistemleri:
- DNS,
- CDN,
- cache,
- TLS,
- WAF,
- DDoS koruması
gibi işlevler sağlayabilir.
Ancak:
“Cloudflare açık = site hızlı ve güvenli.”
denklemi yoktur.
Yanlış yapılandırma:
- cache problemi,
- redirect loop,
- SSL hatası,
- admin problemi,
- stale content
oluşturabilir.
SSL
HTTPS bugün temel gerekliliktir.
Ama SSL sertifikası olması tek başına yeterli değildir.
Kontrol:
- certificate validity,
- hostname,
- redirect,
- mixed content,
- TLS configuration.
http://
ve:
https://
versiyonları iki ayrı site gibi bırakılmamalıdır.
www / non-www
Örneğin:
https://example.com
ve:
https://www.example.com
iki farklı hostname’dir.
Bir tanesi canonical primary olarak seçilmelidir.
Diğer versiyon:
kalıcı redirect
ile primary versiyona gitmelidir.
Canonical, sitemap ve internal links aynı tercihi göstermelidir.
Kurumsal e-posta neden hosting e-postasından farklı olabilir?
Birçok hosting firması:
info@domain.com
mail hesabı sağlar.
Bu teknik olarak kurumsal e-postadır.
Ancak işletmenin ihtiyacına göre:
- Google Workspace,
- Microsoft 365,
- başka enterprise mail platformları
daha güçlü:
- security,
- collaboration,
- admin,
- audit,
- retention,
- device management
özellikleri sunabilir.
Her küçük işletmenin mutlaka Workspace veya Microsoft 365 kullanması gerekmez.
İhtiyaca göre seçilir.
SPF nedir?
SPF domain adına hangi sistemlerin e-posta göndermeye yetkili olduğunu DNS üzerinden tanımlar.
Örneğin aynı domain üzerinden:
- Google Workspace,
- CRM,
- newsletter sistemi
mail gönderiyorsa SPF kaydı bunları kapsamalıdır.
Önemli:
Aynı domain için birden fazla bağımsız SPF kaydı oluşturmak doğru değildir.
Yetkili gönderenler tek SPF politikası içinde yönetilmelidir.
DKIM nedir?
DKIM gönderilen e-postaya kriptografik imza ekler.
Alıcı sistem:
- mesajın yetkili sistem tarafından gönderildiğini,
- içerik bütünlüğünü
doğrulayabilir.
Google güncel Gmail sender guidelines içinde DKIM kullanımını e-posta kimlik doğrulamasının temel parçalarından biri olarak tanımlar.
DMARC nedir?
DMARC:
SPF ve DKIM doğrulama sonuçlarını domain alignment ile birlikte değerlendirir.
Ayrıca domain sahibinin başarısız mesajlar için politika belirlemesine yardımcı olur.
Basitleştirilmiş politika seviyeleri:
p=nonep=quarantinep=reject
Ancak doğrudan:
p=reject
ile başlamak her zaman doğru değildir.
Önce domain üzerinden gerçek mail gönderen tüm sistemlerin bilinmesi gerekir.
DMARC’ı neden hemen reject yapmıyorum?
İşletmede bilmediğiniz bir:
- CRM,
- form,
- muhasebe,
- newsletter,
- ticket
sistemi mail gönderiyor olabilir.
DMARC’ı agresif hale getirip bu sistemleri auth dışında bırakırsanız gerçek e-postalar reddedilebilir.
Bu nedenle:
inventory ↓ SPF/DKIM ↓ DMARC monitoring ↓ enforcement
sırasıyla ilerlemek daha güvenlidir.
Gmail gönderici kuralları
Google’ın güncel Gmail yönergelerinde Gmail hesaplarına mail gönderen tüm göndericiler için en az SPF veya DKIM kimlik doğrulaması istenir.
Yüksek hacimli göndericiler için:
- SPF,
- DKIM,
- DMARC,
- alignment,
- düşük spam oranı
gibi daha kapsamlı koşullar bulunur.
Kurumsal e-posta kullanan küçük işletmelerin dahi SPF, DKIM ve DMARC’ı doğru kurması iyi bir uygulamadır.
Detaylı rehber:
SPF, DKIM ve DMARC: Kurumsal E-postanız Neden Spam’e Düşüyor?
E-posta neden spam’e düşer?
Tek nedeni SPF değildir.
Sorun:
- auth,
- domain reputation,
- IP reputation,
- içerik,
- spam complaint,
- yanlış forwarding,
- mailing behaviour,
- blacklist,
- PTR,
- TLS
gibi katmanlardan oluşabilir.
Bu yüzden:
“SPF ekledik, sorun kesin çözülür.”
demiyorum.
Form e-postaları
Web sitesindeki form:
wordpress@example.com
gibi yanlış yapılandırılmış local mail üzerinden çıkıyorsa teslim sorunları yaşanabilir.
Tercih edilebilir:
- authenticated SMTP,
- transactional email provider,
- API-based delivery
gibi yöntemler.
Ancak hasta/form verisinin üçüncü taraf sistemlere aktarılması KVKK açısından ayrıca değerlendirilmelidir.
Catch-all kullanmak
Catch-all:
domain üzerindeki var olmayan adreslere gelen mailleri de yakalar.
Bazı işletmeler için pratik görünür.
Ama:
- spam,
- yanlış adres,
- güvenlik
yükünü artırabilir.
Her projede otomatik açmıyorum.
Ortak şifreli info@ hesabı
Beş çalışanın aynı:
info@clinic.com
hesabının şifresini paylaşması iyi güvenlik modeli değildir.
Alternatif:
- delegated mailbox,
- shared mailbox,
- role-based access
olabilir.
Böylece çalışan ayrıldığında ortak şifre değiştirmek zorunda kalmazsınız.
MFA
Özellikle:
- domain registrar,
- hosting,
- Cloudflare,
- kurumsal e-posta,
- admin hesaplarında
multi-factor authentication mümkün olduğunda aktif edilmelidir.
Domain hesabının ele geçirilmesi yalnız web sitesini değil e-postayı da tehlikeye atabilir.
Backup
“Hosting otomatik yedek alıyor.”
tek başına yeterli bilgi değildir.
Sorulacak:
- ne sıklıkta?
- kaç gün?
- nerede?
- database dahil mi?
- offsite mı?
- restore kim yapıyor?
- restore test edildi mi?
3-2-1 prensibi
Kritik sistemlerde genel backup yaklaşımı olarak:
- 3 kopya,
- 2 farklı ortam,
- 1 offsite
mantığı değerlendirilebilir.
Her küçük site için aynı backup mimarisi gerekli değildir.
Risk seviyesine göre uygulanır.
Restore testi
Backup yalnız dosyanın var olması değildir.
Gerçek test:
geri yüklenebiliyor mu?
sorusudur.
Özellikle production sistemi olan işletmelerde periyodik restore testi değerlidir.
Staging
Canlı sitede doğrudan:
- plugin,
- PHP,
- theme,
- major dependency
değişikliği yapmak yerine staging ortamı kullanılabilir.
Ancak staging:
- public indexlenmemeli,
- gerçek sağlık verisini gereksiz taşımamalı,
- production şifrelerini kontrolsüz kullanmamalıdır.
Site taşıma
Site taşıma iki farklı şey olabilir:
HOSTING MOVE
URL değişmez.
Sadece altyapı değişir.
SITE MIGRATION
Domain veya URL yapısı değişir.
SEO açısından aynı işlem değildir.
Detaylı rehber:
Hosting taşımasında SEO
URL değişmiyorsa ideal senaryoda Google açısından içerik adresleri aynı kalır.
Ancak şu hatalar yine sıralamayı etkileyebilir:
- yeni server yavaş,
- robots engelli,
- staging noindex production’a taşınmış,
- 500 hataları,
- DNS problemi,
- içerik eksik,
- SSL problemi.
Google hosting migration için yeni altyapının önceden hazırlanmasını ve sonrasında eski/yeni sunucudaki trafiğin izlenmesini önerir.
Domain değişiminde SEO
Domain değişiyorsa ayrıca:
- URL mapping,
- 301,
- canonical,
- sitemap,
- hreflang,
- internal links,
- Search Console
planlanmalıdır.
Google URL değişikliği içeren migration’larda eski → yeni eşleştirme ve server-side permanent redirect kullanımını önerir.
Eski hosting hemen kapatılmalı mı?
Hayır.
DNS değişikliğinden sonra bazı kullanıcılar ve sistemler bir süre eski IP’yi kullanabilir.
Google da hosting migration rehberinde eski altyapının trafiği tamamen bitmeden kapatılmamasını önerir.
TTL
Planlı DNS migration öncesinde TTL düşürülebilir.
Ama bunu migration anında yapmak geç olabilir.
DNS cache’lerin önceden yenilenmesine fırsat verilmelidir.
Zero downtime migration
Gerçek anlamda sıfır kesinti her sistemde garanti edilemez.
Ama risk azaltılabilir:
- yeni server hazırla,
- sync,
- test,
- TTL planla,
- maintenance/write freeze gerekiyorsa,
- final sync,
- DNS switch,
- monitor.
Dinamik database sistemi varsa veri senkronizasyonu ayrıca planlanmalıdır.
E-posta migration
Site taşımasıyla mail migration’ı aynı anda yapılmak zorunda değildir.
Örneğin:
hosting değişir ama mail Workspace’te kalır.
DNS zone doğru korunursa e-posta etkilenmeyebilir.
Bu nedenle:
“hosting değişti, mail de taşınacak.”
otomatik varsayım değildir.
Doktor/klinik domain migration
Sağlık sektöründe domain değiştirirken ek olarak:
- Google Business Profile,
- doktor platformları,
- sosyal profiller,
- sağlık turizmi hesapları,
- reklam landing URL,
- schema Person/Organization,
- email domain
kontrol edilmelidir.
Monitoring
Altyapı bakımında yalnız:
“site açılıyor.”
kontrolü yeterli değildir.
İzlenebilir:
- uptime,
- response time,
- SSL expiry,
- disk,
- CPU/RAM,
- error rate,
- backup status,
- email authentication.
Ben nasıl çalışıyorum?
1. INVENTORY
Domain, DNS, hosting, mail, CDN, third party.
2. OWNERSHIP
Hesapların sahibi kim?
3. RISK
Tek hata noktaları nerede?
4. BACKUP
Rollback mümkün mü?
5. PLAN
Değişiklik sırası.
6. MIGRATION
Kontrollü geçiş.
7. VERIFY
Web, mail, SEO, DNS.
8. MONITOR
Geçiş sonrası izleme.
Neleri yapmıyorum?
- müşteri domainini kendi hesabımda tutmuyorum,
- DNS zone almadan nameserver değiştirmiyorum,
- backup doğrulamadan production taşıması yapmıyorum,
- eski hosting’i DNS değişir değişmez kapatmıyorum,
- site taşımasında URL’leri gereksiz değiştirmiyorum,
- ortak admin şifresini ekip içinde dağıtmayı önermiyorum,
- hosting mailini her işletme için otomatik kötü kabul etmiyorum,
- SPF/DKIM/DMARC’ı tek başına spam garantisi gibi sunmuyorum.
Hosting değiştirmeden önce bağımlılıkları görelim.
Domain, DNS, mail, site ve SEO’yu tek altyapı haritasında çıkaralım.