Domain, Hosting ve SSL: Web Sitesi Altyapı Rehberi 2026

Bir web sitesinin altyapısı üç temel ayağa dayanır: alan adı (domain) sitenizin internetteki adresidir, barındırma (hosting) dosyalarınızın yaşadığı sunucudur, SSL/TLS sertifikası ise ziyaretçiyle sunucu arasındaki trafiği şifreleyip "güvenli bağlantı"yı sağlar. En yalın benzetmeyle: domain evinizin adresi, hosting evin kendisi, SSL de kapının kilidi ve güvenli teslimat zarfıdır. Bu üçü ayrı hizmetlerdir ama birlikte çalışır; biri eksik ya da yanlış kurulduğunda site ya hiç açılmaz, ya yavaş açılır, ya da tarayıcıda "Güvenli değil" uyarısı verir. Doğru altyapı kurulumu, web sitesi yapma sürecinin ilk üç teknik adımıdır (strateji belirlendikten hemen sonra gelir) ve sonradan değiştirmesi en pahalı katmandır; bir alan adını taşımak, hosting'i göç ettirmek veya HTTP'den HTTPS'e geçişi düzgün yapmamak, yayında olan bir sitede günler süren kesinti ve SEO kaybı doğurabilir. Bu yüzden bu üç katmanı baştan doğru kurmak, müşterilerimizde gördüğümüz en sık ihmal edilen ama en yüksek getirili işlerden biridir.

Domain, hosting ve SSL arasındaki fark nedir?

Kısa cevap: domain "nereye gidileceğini", hosting "neyin sunulduğunu", SSL ise "bağlantının güvenli olup olmadığını" belirler. Üçü farklı sağlayıcılardan alınabilir ve teknik olarak birbirinden bağımsızdır; bir araya gelmelerini sağlayan tutkal ise DNS (Alan Adı Sistemi) kayıtlarıdır. Aşağıdaki tablo üç katmanı yan yana koyar; ileride hangi sorunun hangi katmandan kaynaklandığını teşhis ederken bu ayrım çok işe yarar.

Alan adı (domain) nedir, nasıl seçilir?

Alan adı, kullanıcıların tarayıcıya yazıp sitenize ulaştığı insan-okunur addır (örneğin markaniz.com). Teknik olarak alan adı, sunucunuzun IP adresini DNS üzerinden işaret eder; yani siz akılda kalıcı bir isim yazarsınız, DNS bunu arka planda sunucunun sayısal adresine çevirir. İyi bir alan adı kısa, akılda kalıcı, marka adıyla uyumlu, telaffuzu ve yazımı kolay olmalıdır. Pratikte birkaç kuralı erken uygulamak ileride sorun çıkmasını engeller: tire ve sayı kullanmaktan kaçının (telefonda tarif etmesi zordur), marka adını birebir içersin, ve Türkçe karakter (ç, ş, ı gibi) içeren alan adlarından genel kullanımda uzak durun çünkü bunlar arka planda "punycode" denen teknik bir koda çevrilir ve yazışmalarda/linklerde karışıklık yaratır.

Hangi uzantı (TLD) seçilmeli: .com, .com.tr, .net?

Küresel güven standardı hâlâ .com'dur; ziyaretçilerin varsayılan beklentisi budur ve marka koruması açısından öncelikli alınması önerilir. Türkiye odaklı işletmeler için .com.tr yerel güven ve aidiyet sinyali verir; ancak .com.tr alımı için marka tescili veya ilgili belge gerekebilir (nic.tr kuralları). Pratik öneri: hem .com hem .com.tr alıp marka adınızı çatallanmaya karşı korumaktır; ikincil olan adı, asıl adrese 301 ile yönlendirip marka korumasında tutmak yaygın bir yaklaşımdır. Aşağıdaki tablo seçim mantığını özetler:

Alan adınızın müsait olup olmadığını ve fiyat aralığını görmek için domain sorgulama aracımızı kullanabilir, sürecin detayını domain sorgulama nasıl yapılır yazımızdan inceleyebilirsiniz. Önemli bir ilke: alan adını hosting'ten bağımsız yönetin. Domain'i ayrı bir kayıt sağlayıcıda (registrar) tutmak, ileride hosting değiştirseniz bile adresinizi taşımanızı kolaylaştırır ve sizi tek bir sağlayıcıya kilitlenmekten (vendor lock-in) korur. Müşterilerimizde sık gördüğümüz bir tuzak şudur: alan adı, siteyi yapan ajansın veya eski bir çalışanın hesabına kayıtlıdır; ilişki bittiğinde firma kendi adresine erişemez hale gelir. Bu yüzden domain'in mutlaka firma adına ve firmanın kontrol ettiği bir e-postaya kayıtlı olması, sahiplik açısından kritik bir kuraldır. Bu taşınabilirlik ve net sahiplik, ileride bir site yenileme (redesign) sürecinde de hayat kurtarır.

Hosting (barındırma) nedir, hangi tür seçilmeli?

Hosting, web sitenizin dosyalarının (kod, görsel, veritabanı) yaşadığı ve ziyaretçilere sunulduğu sunucu hizmetidir. Domain adresi yazıldığında sunucu, sayfayı oluşturup tarayıcıya gönderir; bu sunucunun hızı, konumu ve kapasitesi doğrudan sitenizin yüklenme süresini ve dolayısıyla Core Web Vitals skorunuzu belirler. Sunucu yanıt süresi yavaşsa, en büyük içeriğin görünmesi de gecikir; yani LCP (Largest Contentful Paint) doğrudan hosting kalitesinden etkilenir. "İyi" LCP eşiğinin 2,5 saniyenin altı olduğu (75. yüzdelik saha verisi) hatırlanırsa, sunucu seçiminin neden sadece "teknik bir tercih" değil, bir SEO ve dönüşüm meselesi olduğu netleşir. Üstelik tek başına LCP değil, etkileşime yanıt hızını ölçen INP (iyi eşik 200 ms altı) de sunucunun ürettiği sayfanın ağırlığından ve arka uç (backend) hızından etkilenir.

Hosting türleri arasındaki fark nedir?

Doğru tür, trafiğinize, bütçenize ve teknik kontrol ihtiyacınıza göre değişir. Başlıca seçenekler şunlardır:

• Paylaşımlı hosting (shared): Tek sunucu birçok site arasında paylaşılır. En ucuz seçenek; küçük tanıtım siteleri, başlangıç blogları için yeterlidir. Dezavantajı: aynı sunucudaki başka bir sitenin yoğunluğu sizin hızınızı etkileyebilir (komşu etkisi) ve kaynak garantisi yoktur.
• VPS (sanal özel sunucu): Sanal olarak ayrılmış garantili kaynak (CPU/RAM). Orta ölçekli, büyüyen siteler için denge noktası. Biraz teknik yönetim (sunucu güncelleme, güvenlik) gerektirir.
• Dedicated / bulut (cloud) hosting: Tam sunucu veya esnek bulut kaynağı; yüksek trafik, kurumsal ve e-ticaret için. Bulutun avantajı, ani trafik artışında kaynağı otomatik ölçekleyebilmesidir (kampanya günü çökmemek için kritik). Ölçeklenebilir ama maliyetli ve yönetimi uzmanlık ister.
• Yönetilen WordPress hosting: Güncelleme, yedek, güvenlik ve önbellekleme sağlayıcı tarafından yönetilir. WordPress tüm web'in yaklaşık %42'sini çalıştırdığından bu kategori geniştir; WordPress kullanıyorsanız bakım yükünü ciddi azaltır.
• Statik / JAMstack barındırma (Vercel, Netlify, Cloudflare Pages): Modern framework'lerle (Next.js, Astro) üretilen siteleri edge/CDN üzerinden sunar. SSL ve CDN genelde dahili gelir, kurulum dakikalar sürer. En hızlı ve en iyi ölçeklenen yaklaşım; özel yazılım projeleri için sıklıkla tercih edilir.

Bu seçenekleri trafik ve ihtiyaç ekseninde özetlemek karar vermeyi kolaylaştırır:

Hangi türü seçerseniz seçin, performansın belirleyici unsuru CDN (içerik dağıtım ağı) ve edge kullanımıdır. CDN, sitenizin statik içeriğini (görsel, CSS, JavaScript) dünyanın farklı noktalarındaki sunuculara kopyalar; böylece ziyaretçi en yakın noktadan, düşük gecikmeyle yüklenir. Mobil cihazlar küresel trafiğin yaklaşık %60'ını oluşturduğundan (2026, kaynak ve döneme göre değişebilir) ve mobil şebekeler genelde daha yavaş olduğundan, CDN ile gecikmeyi düşürmek mobil performans için kritiktir. CDN ayrıca bir güvenlik katmanı da sağlar: kötü niyetli trafiği ve botları filtreleyip DDoS saldırılarını hafifletebilir. Bu konunun pratik tarafını PageSpeed Insights iyileştirme rehberimizde ele alıyoruz; sayfa hızının doğrudan sıralamaya etkisini ise Core Web Vitals rehberinde bulabilirsiniz.

Yerli mi yurt dışı hosting mi?

Bu, Türkiye bağlamında sık sorulan bir karardır ve tek doğru cevabı yoktur. Yurt içi hosting, TR ziyaretçiye fiziksel yakınlık nedeniyle düşük gecikme sunabilir ve KVKK/veri yerelleştirme algısı açısından bazı kurumlarca tercih edilir. Ancak modern global CDN'ler (Cloudflare, Vercel edge) ile yurt dışı barındırma da içeriği TR ziyaretçiye en yakın edge noktasından hızla sunabilir; yani "yurt dışı = yavaş" eşitliği artık geçerli değildir. Kritik nokta şudur: kişisel veri işliyorsanız, bu verinin yurt dışına aktarımı KVKK kurallarına tabidir ve doğru hukuki zemine (taahhütname, yeterlilik kararı vb.) oturtulmalıdır. KVKK m.12, veri sorumlusuna teknik ve idari güvenlik tedbirleri alma yükümlülüğü getirir; sunucu konumu ve sözleşmesel güvence bu çerçevenin parçasıdır. Yani hosting kararı sadece hız değil, aynı zamanda bir veri güvenliği ve uyum kararıdır. Karar verirken sorulması gereken üç soru: (1) Ziyaretçilerimin büyük çoğunluğu nereden geliyor? (2) Hangi kişisel verileri topluyorum ve nerede saklanmaları gerekiyor? (3) CDN/edge ile gecikmeyi zaten kapatabiliyor muyum?

SSL/TLS nedir, neden zorunlu?

SSL (Secure Sockets Layer) terimi yaygın kullanılsa da bugün kullanılan güncel protokol teknik olarak TLS'tir (TLS 1.2 / 1.3). SSL/TLS sertifikası üç işi birden yapar: ziyaretçinin tarayıcısı ile sunucunuz arasındaki tüm trafiği şifreler, sunucunun kimliğini doğrular ve verinin yolda değiştirilmediğini garanti eden bütünlüğü sağlar. Adres çubuğundaki https:// ve kilit simgesi bu katmanın aktif olduğunu gösterir. Şifreleme olmadan, ortadaki bir saldırgan (örneğin halka açık bir Wi-Fi ağında) form alanına yazılan e-posta, parola veya kart bilgisini düz metin olarak okuyabilir; HTTPS tam olarak bunu engeller.

SSL artık opsiyonel değil zorunludur; bunun üç somut sebebi vardır:

1. SEO sinyali: HTTPS, Google'ın doğruladığı bir sıralama sinyalidir; HTTP'de kalan siteler dezavantajlıdır ve teknik SEO denetimlerinde otomatik olarak uyarı alır.
2. Tarayıcı uyarısı ve güven: SSL'siz sitelerde tarayıcılar adres çubuğunda "Güvenli değil" ibaresi gösterir; bu, ziyaretçi güvenini ve dönüşümü doğrudan kırar. Özellikle ödeme veya iletişim formu olan bir sayfada bu uyarı, terk oranını ciddi yükseltir.
3. Yasal/güvenlik zorunluluğu: İletişim formu, üyelik veya ödeme gibi kişisel veri toplayan her sitede şifreleme, KVKK m.12 kapsamında bir "veri güvenliği tedbiri" olarak hukuki bir gerekliliktir. Yani SSL eksikliği yalnızca teknik değil, hukuki bir risktir.

İyi haber: SSL artık maliyet engeli değildir. Let's Encrypt ile sertifika ücretsizdir ve çoğu modern hosting (özellikle yönetilen ve JAMstack barındırma) sertifikayı otomatik kurar ve otomatik yeniler. Manuel uğraşmanız gereken durumlar azalmıştır; yine de sertifikanın tüm alt alan adlarını kapsadığından (örneğin hem siteniz.com hem www.siteniz.com, hem de varsa shop.siteniz.com) ve süresi dolmadan yenilendiğinden emin olmak gerekir, çünkü süresi geçen bir sertifika siteyi tarayıcıda tamamen erişilemez gösterebilir ve bu, fark edilene kadar saatlerce satış/lead kaybına yol açar.

HTTPS'i doğru kurmanın inceliği: karışık içerik ve yönlendirme

SSL'i "kurmak" yetmez, siteyi tamamen HTTPS'e taşımak gerekir. İki tipik hata şunlardır: birincisi, sayfa HTTPS üzerinden açılırken içindeki bir görselin, yazı tipinin veya script'in hâlâ http:// ile çağrılması (karışık içerik / mixed content) — bu, kilit simgesini bozar, tarayıcı uyarısı doğurur ve bazı kaynakların hiç yüklenmemesine yol açabilir. İkincisi, HTTP adresinden HTTPS'e kalıcı (301) yönlendirme kurulmaması; bu hem kullanıcının eski linklerle güvensiz sürüme düşmesine hem de SEO açısından sayfa değerinin iki ayrı sürüm arasında bölünmesine yol açar. Üst seviye bir önlem olarak, sunucunun "bu siteyi yalnızca HTTPS üzerinden ziyaret et" talimatı verdiği HSTS başlığı da eklenebilir; bu, tarayıcının bir sonraki ziyarette doğrudan güvenli sürüme gitmesini sağlar. Bir redesign veya taşıma sırasında 301 yönlendirme disiplini, tüm bu altyapı katmanını korumanın anahtarıdır; URL yapısı değişiyorsa eski adreslerin yenisine 301 ile bağlanması, yıllarca biriken arama sıralaması ve backlink değerinin kaybedilmemesi için olmazsa olmazdır.

Üç ayağı birlikte düşünmek: kurulum sırası ve kontrol listesi

Domain, hosting ve SSL ayrı satın alınsa da birbirine bağlı çalışır. Mantıklı kurulum sırası şudur: önce alan adını alıp (tercihen bağımsız registrar'da, firma adına) sahipliğini güvenceye alın; sonra ihtiyacınıza uygun hosting'i seçin; ardından DNS kayıtlarıyla (A ve CNAME) domain'i hosting'e yönlendirin; son olarak SSL sertifikasını kurup HTTPS'i zorunlu kılın. Bu sıra, web sitesi yapma adımlarının 2, 3 ve 4. basamaklarını oluşturur ve tasarım/geliştirme aşamasından önce tamamlanmalıdır. DNS değişikliklerinin internet genelinde yayılmasının (propagation) zaman alabileceğini hesaba katın; bu yüzden canlıya geçiş gibi kritik DNS değişikliklerini yoğun olmayan saatlerde yapmak iyi bir pratiktir.

Yayına geçmeden önce altyapı tarafında şu kontrolleri yapmanızı öneririz:

• Domain: Doğru registrar'da, sahibi firma adına ve firmanın kontrol ettiği e-postaya kayıtlı; otomatik yenileme açık (alan adının süresi dolup kapılmasın).
• DNS: A/CNAME kayıtları doğru sunucuya işaret ediyor; www ve www'siz sürüm tek bir tercihe (örneğin hep www'siz) 301 ile yönlendiriliyor; e-posta kullanıyorsanız MX kayıtları ve SPF/DKIM gibi e-posta doğrulama kayıtları doğru.
• Hosting: Trafik beklentisine uygun paket; düzenli, otomatik, sürümlü ve site dışı (off-site) yedekleme aktif ve geri yükleme bir kez test edilmiş; mümkünse CDN/edge devrede.
• SSL: Sertifika tüm site ve alt alan adlarını kapsıyor; HTTP→HTTPS 301 yönlendirme var; karışık içerik (mixed content) uyarısı yok; otomatik yenileme çalışıyor.
• Güvenlik temeli: CMS, tema ve eklentiler güncel (bilinen açıkların çoğu güncellenmemiş üçüncü taraf bileşenlerden sömürülür), kullanılmayan eklentiler silinmiş, admin için güçlü parola + 2FA aktif — detaylar web güvenliği rehberinde.

Altyapı, kullanıcıların hiç görmediği ama her şeyi taşıyan temeldir; yanlış kurulduğunda yavaşlık, güvenlik açığı ve SEO kaybı olarak yıllarca geri döner. Doğru kurulduğunda ise neredeyse görünmezdir: site hızlı açılır, kilit simgesi yerindedir, arama motorları sorunsuz tarar ve siz içeriğe, tasarıma ve dönüşüme odaklanabilirsiniz. Kendi altyapınızı kurarken emin olamadığınız noktalarda ya da mevcut sitenizin domain/hosting/SSL kurgusunu gözden geçirmek için web ve yazılım hizmetlerimizden faydalanabilir, projenize özel bir yol haritası için ücretsiz analiz formumuzu doldurabilirsiniz. Doğru kurulmuş bir altyapı, üzerine inşa edeceğiniz tasarım, içerik ve dönüşüm çalışmalarının da sağlam zeminidir.

Alan Adı (Domain) Seçimi: .com mu .com.tr mi?

Alan adı, web sitenizin internetteki kalıcı adresi ve markanızın dijital kimliğidir; bu yüzden altyapı kurulumunun en kritik ilk adımıdır. Kısa cevap: kurumsal ve genel hedefli işletmeler için .com hâlâ küresel güven standardıdır ve birincil tercih olmalıdır; güçlü yerel kimlik, "Türk markası" algısı veya marka koruması isteyen firmalar ise ek olarak .com.tr alır. En sağlıklı yaklaşım çoğu durumda ikisini birden almak, birini ana adres yapıp diğerini ona yönlendirmektir. Bu bölümde uzantı seçimini, müsaitlik kontrolünü, marka uyumunu, teknik kayıt sürecini ve Türkiye'ye özgü kuralları danışman gözüyle adım adım açıyoruz. Pratik tarafta isim fikirlerinizi anında denemek için domain sorgulama aracımızı kullanabilir, sürecin detayları için domain sorgulama nasıl yapılır rehberimize göz atabilirsiniz.

Alan adı seçimi neden bu kadar önemli?

Alan adı, kullanıcının markanızla kurduğu ilk temas noktasıdır; akılda kalıcılığı, güven algısını ve hatta tıklanma oranını doğrudan etkiler. Müşterilerimizde gördüğümüz en yaygın hata, alan adını "sonra hallederiz" diye aceleye getirip yıllarca taşımakta zorlanılan bir isimle yola devam etmektir. Web sitesi yapma sürecinin mantıksal sırasında alan adı, hedef/strateji adımından hemen sonra (2. adım), hosting ve SSL kurulumundan önce gelir; çünkü hosting, e-posta, SSL sertifikası ve marka iletişimi hep bu isim üzerine inşa edilir. Bu adımı atlamadan, bütünsel altyapı resmini görmek için domain, hosting ve SSL altyapı rehberimizin tamamını ve sürecin genel akışı için web sitesi nasıl yapılır 2026 rehberini öneririz.

Alan adının teknik tarafını da bilmek, doğru karar vermeyi kolaylaştırır. Bir alan adı, kayıt anında bir tescil kuruluşu (registrar) üzerinden alınır; bu kuruluş ilgili uzantının kayıt operatörüne (örneğin .com için Verisign, .com.tr için ülke düzeyinde nic.tr) bilgilerinizi iletir. Bir kullanıcı tarayıcıya alan adınızı yazdığında, dünyaya yayılmış DNS (Domain Name System) sunucuları bu adı, sitenizin barındığı sunucunun IP adresine çevirir. Bu yüzden alan adı kaydı yalnızca bir "isim satın alma" değil, aynı zamanda DNS yönetimi, e-posta yönlendirme ve SSL doğrulamasının da çıkış noktasıdır. İyi yapılandırılmış bir alan adı; web sitesi, kurumsal e-posta ve gelecekteki alt alan adları (örneğin blog.markaadi.com veya panel.markaadi.com) için sağlam bir zemin sağlar.

Önemli bir prensip: alan adını mümkünse hosting hizmetinizden bağımsız tutun ve ayrı yönetin. Alan adıyla hosting'i tek sağlayıcıya kilitlerseniz, ileride hosting değiştirmek istediğinizde alan adınızı taşımak gereksiz biçimde zorlaşır. Alan adı kaydını ayrı bir tescil kuruluşunda tutmak; taşınabilirlik, uzun vadeli kontrol ve sağlayıcı bağımsızlığı açısından önerilir. Pratikte gördüğümüz tablo şudur: hosting'i bir sağlayıcıdan, alan adını başka bir registrar'dan alan firmalar, yıllar içinde tedarikçi değiştirirken çok daha az sorun yaşar. Çünkü en değerli dijital varlığınız olan alan adı, hangi sunucuda barındığınızdan tamamen bağımsız kalır.

Alan adına sahip olmak mı, kiralamak mı? Yenileme ve sahiplik notları

Sık karşılaştığımız bir yanlış anlama, alan adının "bir kez alınıp ömür boyu sahibi olunan" bir şey sandırılmasıdır. Gerçekte alan adları yıllık olarak kiralanır: kaydı 1 yıldan birkaç yıla kadar yapar, süre dolmadan yeniler ve böylece üzerinizde tutarsınız. Bu nedenle alan adı yönetiminde dikkat edilmesi gereken birkaç pratik nokta vardır:

• Otomatik yenilemeyi açın: Müşterilerimizde gördüğümüz en acı verici kayıplardan biri, yenileme tarihinin kaçırılıp alan adının serbest kalması ve bir başkası tarafından kapatılmasıdır. Otomatik yenilemeyi açmak ve registrar e-postalarını takip etmek bu riski büyük ölçüde ortadan kaldırır.
• İletişim e-postasını güncel tutun: Alan adı uyarıları (yenileme, doğrulama, transfer onayı) registrar'da kayıtlı e-postaya gider. Bu adres bir personelin kişisel hesabıysa ve o kişi ayrılırsa, kritik bildirimleri kaçırabilirsiniz. Kurumsal, kalıcı bir adres kullanın.
• Alan adı kilidini (registrar lock) kullanın: Yetkisiz transferleri engelleyen bu kilit, marka adınızın izinsiz başka bir registrar'a taşınmasını zorlaştırır.
• WHOIS gizliliği: Alan adı sahibi bilgileri (.com tarafında) WHOIS sorgularında görünebilir. İletişim bilgilerinizin spam ve istenmeyen aramalara açılmaması için sağlayıcınızın gizlilik korumasını değerlendirin.

Sahiplik bilinci, alan adını "kurulum gününde alınacak bir kalem" olmaktan çıkarıp markanın uzun ömürlü bir varlığı olarak görmenizi sağlar. Bu da seçim aşamasında daha sağlıklı kararlar almanıza yardımcı olur.

İyi bir alan adının özellikleri nelerdir?

İyi bir alan adı; kısa, telaffuzu kolay, akılda kalıcı ve marka adınızla birebir uyumludur. Seçim yaparken şu ölçütleri uygulamanızı öneririz:

• Kısa ve net: Telefonda söylenebilen, tek seferde doğru yazılabilen isimler tercih edilir. Uzun isimler hem akılda kalmaz hem de yazım hatasına açıktır. Pratik bir ölçü olarak, alan adının kök kısmını mümkünse kısa tutmaya çalışın.
• Marka uyumu: Alan adı, firma adınız ve sosyal medya kullanıcı adlarınızla tutarlı olmalı. Bu tutarlılık, marka bütünlüğünü ve güveni güçlendirir.
• Tire ve rakamdan kaçının: "marka-adi-2" gibi tireli/rakamlı isimler sözlü iletişimde karışıklık yaratır ("tire mi, boşluk mu?"). Mümkünse düz, tek kelimeye yakın bir yapı seçin.
• Türkçe karakter tuzağı: Alan adında ç, ğ, ı, ö, ş, ü gibi karakterler teknik olarak mümkün olsa da (IDN — Uluslararasılaştırılmış Alan Adı), pratikte yazım, paylaşım ve e-posta sorunları çıkarır. İsimde Türkçe karaktere denk gelen kelimeler için Latin karşılığını dikkatle seçin ve özellikle noktalı/noktasız "I" ayrımının nasıl yazılacağına karar verin. Örneğin "şirket" kelimesi bir isimde geçiyorsa, kullanıcıların büyük çoğunluğu "sirket" yazacaktır; ana adresinizi buna göre belirleyin.
• Yazım hatası kapanı: İnsanların sıkça yanlış yazabileceği bir isimse, yakın yazımları da almayı ve ana adrese yönlendirmeyi düşünün. Bu, hem yanlışlıkla rakibe gitmeyi önler hem de yazım hatası yapan ziyaretçiyi yine de size ulaştırır.
• Geleceğe uygunluk: Bugünkü tek bir hizmete fazla özgül bir isim (ör. yalnızca tek ürünü anlatan), büyüdüğünüzde sizi kısıtlayabilir. Marka odaklı, genişlemeye açık isimler daha sağlıklıdır. Bugün sadece web tasarımı yapan bir ajans "sadeceweb" yerine marka adını kullanırsa, yarın yazılım ve pazarlama eklediğinde alan adını değiştirmek zorunda kalmaz.
• Telaffuz ve "radyo testi": İsminizi yüksek sesle söyleyip karşıdaki kişinin doğru yazıp yazamadığını test edin. Bir reklam spotunda veya telefonda duyulduğunda tereddütsüz yazılabilen bir alan adı, pazarlamanın görünmez ama güçlü bir kazancıdır.

Bu kriterleri bir isim fikrine uygularken müsaitliği aynı anda kontrol etmek zaman kazandırır; birkaç alternatif ismi domain sorgulama aracıyla hızlıca test edip elenenleri eleyebilirsiniz. Marka kimliğinin sitenin tasarımına nasıl yansıdığını bütünsel görmek isterseniz iyi web tasarımı nasıl olmalı yazımız da iyi bir tamamlayıcıdır.

.com mu, .com.tr mi, .net mi? Uzantı nasıl seçilir?

Uzantı (TLD — Top Level Domain) seçimi, hem güven algısını hem de hedef kitlenizi yansıtmalıdır. Genel kural şudur: küresel veya genel hedefli işletmeler için .com hâlâ en güvenilir ve en çok tanınan seçenektir; Türkiye odaklı, yerel kimliğini vurgulamak isteyen markalar için .com.tr güçlü bir tamamlayıcıdır. Aşağıdaki tablo başlıca uzantıları danışman gözüyle karşılaştırır:

Marka koruması açısından yaygın ve sağlıklı yaklaşım, hem .com hem de .com.tr uzantısını birden almaktır. Böylece bir rakip veya domain spekülatörü markanızın diğer uzantısını kapamaz; ikisinden birini ana adres (kanonik) yapar, diğerini 301 yönlendirmeyle ana adrese gönderirsiniz. Burada kritik nokta: tek bir kanonik adres belirleyip tüm trafiği oraya yönlendirmek, SEO açısından otoritenin dağılmamasını sağlar. Aynı içeriğin hem .com hem .com.tr üzerinden açık kalması, arama motorları için "yinelenen içerik" sinyali yaratır ve sıralama gücünüzü ikiye böler; bu nedenle yönlendirme adımını atlamamak gerekir. Kurumsal site bağlamında bu disiplinin neden önemli olduğunu kurumsal web sitesi nasıl olmalı 2026 yazımızda daha geniş ele alıyoruz.

.com.tr almak için ne gerekiyor? (nic.tr kuralları)

.com.tr başvurusu, .com'dan farklı olarak çoğu durumda belge ister; bu, alan adının ilgili kişi/kuruma ait olduğunu doğrulamak içindir. nic.tr kurallarına göre, talep edilen isme bağlı olarak marka tescil belgesi, ticaret unvanı, vergi levhası gibi belgeler istenebilir. Pratik sonuçları şöyle özetleyebiliriz:

• Belge zorunluluğu: Firma adınızla birebir uyumlu bir .com.tr alıyorsanız genelde ticari belgenizle (vergi levhası/ticaret sicil kaydı) başvurabilirsiniz. Marka adıyla doğrudan eşleşmeyen serbest bir isim için marka tescil belgesi gerekebilir. Yani "kendi unvanınız" üzerinden başvuru çoğunlukla en pürüzsüz yoldur.
• Süreç daha resmidir: .com saniyeler içinde alınırken, .com.tr başvurusu belge doğrulaması nedeniyle biraz zaman alabilir. Bunu projenizin zaman planına dahil edin; alan adını yayın gününe bırakmayın. Belge doğrulamasının takıldığı durumlarda yayın tarihinizin ötelenmesini istemiyorsanız, bu adımı projenin en başında başlatın.
• Marka tescili avantaj sağlar: Tescilli markanız varsa hem .com.tr başvurusu kolaylaşır hem de marka korumanız güçlenir. Yeni marka kuruyorsanız tescil sürecini erken başlatmak iki yönlü fayda sağlar: hem alan adı başvurunuzu kolaylaştırır hem de isminizi hukuken koruma altına alır.
• Aynı isim, iki uzantı: .com.tr başvurusunu yaparken .com'u da paralelde almak, ileride birinin dolması riskini ortadan kaldırır. Belge süreci .com.tr tarafında ilerlerken, .com'u hemen alıp ana adres olarak yapılandırabilir, .com.tr hazır olduğunda yönlendirme stratejinizi gözden geçirebilirsiniz.

Belge gerektirmeyen, hızlı ve düşük sürtünmeli bir başlangıç istiyorsanız .com ile yola çıkıp .com.tr'yi paralelde halletmek pragmatik bir stratejidir. Yerel SEO ve marka algısı tarafında ise .com.tr'nin "Kayseri'de / Türkiye'de yerleşik firma" mesajını güçlendirdiğini, özellikle yerel hizmet veren işletmeler için değer kattığını söyleyebiliriz. Yine de tek başına uzantının bir sıralama mucizesi yaratmadığını, asıl belirleyicinin içerik kalitesi, site hızı ve yerel sinyallerin tutarlılığı olduğunu unutmamak gerekir.

Müsaitlik nasıl kontrol edilir? İsim doluysa ne yapmalı?

Bir alan adının müsait olup olmadığını öğrenmenin en hızlı yolu, isim fikirlerinizi bir sorgulama aracında denemektir. Domain sorgulama aracımız ile bir ismi farklı uzantılarda (.com, .com.tr, .net) aynı anda kontrol edip hangilerinin boş olduğunu görebilirsiniz; aracın nasıl kullanılacağına ve sonuçların nasıl yorumlanacağına dair adımları domain sorgulama nasıl yapılır yazımızda bulabilirsiniz. İdeal isminiz .com'da doluysa şu seçenekleri sırayla değerlendirin:

• İsmi yeniden kurgulayın: Markanıza yakın, kısa bir ek veya birleşik kelime (ör. sektör/şehir çağrışımı) ile yeni bir .com fikri üretin. Tireli çözümlerden mümkün olduğunca kaçının. Örneğin marka adınız doluysa, başına/sonuna sektörünüzü anlatan kısa bir kelime eklemek (yine düz yazımla) makul bir çözümdür.
• Alternatif uzantıya geçin: .com dolu ama .com.tr boşsa ve hedefiniz Türkiye ise, .com.tr'yi ana adres yapmak makul bir karardır. Bu durumda tüm pazarlama materyallerinizde tutarlı biçimde .com.tr adresini kullanın.
• Yakın yazımları toplayın: Marka isminiz net ama .com alınmışsa, sahibinin satışa açık olup olmadığını araştırmak veya farklı ama tutarlı bir varyant seçmek gerekebilir. İkinci el alan adı pazarında istenen bedeller bazen yüksek olabilir; bu yatırımın markanıza değerini soğukkanlı değerlendirin.
• Kullanılmayan eski kaydı kontrol edin: Bazı isimler kayıtlı görünse de aktif bir siteye bağlı olmayabilir. Böyle durumlarda sahiple iletişime geçmek veya kaydın süresinin dolmasını takip etmek bir seçenektir; ancak bu belirsiz bir bekleyiştir, planınızı buna bağlamayın.
• Sosyal medya tutarlılığını koruyun: Seçtiğiniz isim, kullanıcı adlarınızla da uyumlu olsun; çünkü kurumsal site bağlamında NAP ve marka tutarlılığı (firma adı-adres-telefon ve marka kimliğinin tüm dijital varlıklarda birebir aynı olması) yerel sıralamayı ve güveni doğrudan etkiler.

Pratik bir ipucu: bir isme karar vermeden önce hem alan adı müsaitliğini hem de ana sosyal medya platformlarındaki kullanıcı adı müsaitliğini birlikte kontrol edin. Alan adı boş ama sosyal medya adı kapalıysa (veya tersi), marka iletişiminizde tutarsızlık yaşarsınız. En sağlıklısı, dört bir yanda (alan adı, e-posta, sosyal hesaplar) aynı ismi tutarlı kullanabileceğiniz bir seçenekte karar kılmaktır.

Alan adı, DNS ve hosting bağlantısı nasıl kurulur?

Alan adını aldıktan sonra onu sitenizin barındığı sunucuya bağlamak için DNS kayıtlarını yapılandırırsınız. Bu, teknik gibi görünse de mantığı basittir: alan adı bir tabela, DNS ise o tabelanın hangi binayı (sunucuyu) işaret ettiğini söyleyen yönlendirme sistemidir. Temel kayıt türlerini bilmek, sağlayıcılar arası taşınmada ve sorun gidermede işinizi kolaylaştırır:

• A kaydı: Alan adını doğrudan bir sunucunun IPv4 adresine bağlar. Klasik hosting kurulumlarında en sık kullanılan kayıttır.
• CNAME kaydı: Bir alt alan adını (örn. www) başka bir alan adına işaret ettirir. Modern statik/edge platformlarında (Vercel, Netlify, Cloudflare Pages) bağlantı çoğunlukla CNAME ile kurulur.
• MX kaydı: E-posta trafiğini hangi sunucunun karşılayacağını belirler. Kurumsal e-posta kurarken doğru MX kayıtları olmadan e-postalar size ulaşmaz.
• TXT kaydı: Doğrulama (SSL, alan adı sahipliği) ve e-posta güvenliği (SPF/DKIM/DMARC) için kullanılır. E-posta teslim edilebilirliği ve "spam'e düşmeme" büyük ölçüde bu kayıtların doğru yapılandırılmasına bağlıdır.
• NS (Name Server) kaydı: Alan adının DNS'ini hangi sunucuların yönettiğini belirler. DNS'i bir CDN/güvenlik sağlayıcısına (örn. Cloudflare) taşıdığınızda NS kayıtlarını değiştirirsiniz.

DNS değişikliklerinin internet genelinde tam olarak yayılması (propagation) genelde birkaç dakikadan birkaç saate kadar sürebilir; nadiren daha uzun. Bu yüzden alan adını yeni sunucuya bağlama işlemini yayın gününün son anına bırakmayın. Alan adının, hosting'in ve SSL'in birbirine bağlı bir bütün olduğunu hatırlatalım: alan adı doğru sunucuyu işaret etmeden SSL doğrulaması da tamamlanamaz. Bu üç parçayı birlikte planlamak, sürpriz gecikmeleri önler. Hosting seçeneklerinin performans etkisini ve site hızı bağlantısını site hızı ve SEO: Core Web Vitals rehberi ile PageSpeed Insights nedir, nasıl iyileştirilir yazılarımızda bulabilirsiniz.

Alan adı, e-posta ve marka bütünlüğü

Alan adı yalnızca web sitesinin adresi değildir; aynı zamanda kurumsal e-posta kimliğinizin temelidir. info@markaadi.com gibi alan adınıza bağlı bir e-posta, ücretsiz e-posta servisleriyle (gmail/hotmail uzantılı kurumsal iletişim) kıyaslandığında çok daha güçlü bir güven ve profesyonellik sinyali verir. Müşterilerimizde gördüğümüz somut bir etki: teklif ve fatura yazışmalarında alan adına bağlı e-posta kullanan firmalar, karşı tarafta gözle görülür biçimde daha kurumsal algılanır. Bu yüzden alan adını seçerken e-postayı da düşünmek gerekir; kurumsal e-posta kurulumunun detayları için kurumsal e-posta nedir, nasıl alınır rehberimize bakabilirsiniz. Alan adı, kurumsal e-posta, hosting ve SSL'i bir bütün olarak planlamak, ileride dağınık ve birbirine bağlı sistemlerle uğraşmaktan sizi kurtarır.

Marka bütünlüğü tarafında bir hatırlatma daha: alan adınız, logonuz, sosyal medya adlarınız ve Google Business profiliniz aynı ismi yansıtmalı. Bu tutarlılık hem kullanıcı güvenini hem de yerel arama performansını destekler; özellikle B2B web sitelerinde uzun ve çok karar vericili satış döngüsü boyunca markanın her temas noktasında aynı görünmesi, güven inşasının temel taşıdır. B2B alıcı çoğu zaman karar vermeden önce sitenizi, e-postanızı, LinkedIn'inizi ve Google'daki kaydınızı kontrol eder; bu noktalardaki isim ve görünüm tutarlılığı, "ciddi ve oturmuş bir firma" izlenimini doğrudan güçlendirir.

Alan adı ile ilgili sık yapılan hatalar

Danışmanlık verdiğimiz projelerde tekrar tekrar karşılaştığımız, kolayca önlenebilir hataları derledik. Bunlardan kaçınmak, alan adınızın yıllar boyunca sorunsuz çalışmasını sağlar:

• Alan adını web tasarımcısının/ajansın kendi hesabına aldırmak: Alan adı her zaman firmanın kendi adına ve kendi erişebildiği bir hesapta kayıtlı olmalı. Aksi halde ajansla yollar ayrıldığında en kritik dijital varlığınız başkasının kontrolünde kalabilir. Biz, müşterilerimizin alan adlarını her zaman kendi adlarına kaydetmelerini öneririz.
• HTTPS ve www tutarsızlığı: Site hem http hem https, hem www hem www'suz açık kalırsa dört farklı sürüm ortaya çıkar. Tek kanonik sürümü (örn. https://www.markaadi.com) belirleyip diğerlerini 301 ile ona yönlendirin.
• Türkçe karakterli IDN alan adında ısrar: Estetik güzel görünse de e-posta ve paylaşımda sorun yaratır; Latin yazımlı bir ana adres çok daha güvenlidir.
• Yenileme tarihini takip etmemek: Yukarıda değindiğimiz gibi, otomatik yenileme kapalıysa alan adı sessizce serbest kalabilir. Bu, en pahalıya mal olan ihmallerden biridir.
• Ölçeklenemeyen, fazla dar isim seçmek: Tek hizmeti anlatan bir isim, büyüdükçe sizi yeniden markalaşmaya zorlar; bu da SEO ve tanınırlık birikiminizi sıfırlar.

Bu hatalar küçük görünse de, sonradan düzeltmek hem zaman hem de SEO değeri kaybettirir. Doğru kurulmuş bir alan adı yapısı ise, sitenizin geri kalan tüm altyapısının üzerine sağlamca oturacağı bir zemindir. İleride bir yenileme (redesign) yaparsanız bu kanonik yapı ve yönlendirme disiplini, sıralamalarınızı korumanın da anahtarı olur; bu konuda web sitesi yenileme redesign rehberi yazımız yol gösterici olabilir.

Alan adı seçiminde kısa karar rehberi

Özetlersek, alan adı kararını şu basit çerçeveyle netleştirebilirsiniz:

• Global/genel hedef + hız istiyorsanız: Belge gerektirmeyen .com ile başlayın; birincil tercih budur.
• Türkiye odaklı + yerel kimlik + marka koruması istiyorsanız: .com.tr'yi de alın; belge sürecini erken başlatın ve marka tescilini düşünün.
• İdeal .com doluysa: İsmi yeniden kurgulayın veya .com.tr'yi ana adres yapın; tireli/rakamlı çözümlerden kaçının.
• Her durumda: Tek bir kanonik adres belirleyin, diğer uzantıları ve www/http varyantlarını 301 ile ona yönlendirin, alan adını hosting'den bağımsız ve firmanın kendi adına yönetin, otomatik yenilemeyi açın.

Doğru alan adı, doğru hosting ve zorunlu SSL/TLS yapılandırmasıyla birleştiğinde sağlam bir web altyapısının temelini oluşturur; bu altyapı kararlarının işletmenize özel en doğru kombinasyonunu birlikte planlamak isterseniz ücretsiz analiz ve teklif sihirbazımızdan yararlanabilir, kurumsal kimliğinizi yansıtan bir site için özel yazılım ve web sitesi hizmetimizi inceleyebilirsiniz. Alan adı seçimi küçük bir detay gibi görünse de, markanızın yıllarca taşıyacağı bir karardır; baştan doğru kurmak, sonradan düzeltmekten her zaman daha kolaydır.

Hosting Türleri Nelerdir, Hangi Hosting Seçilmeli?

Hosting (barındırma), web sitenizin dosyalarının, veritabanının ve uygulamasının çalıştığı sunucu altyapısıdır. Kısa cevap: hosting seçimini sitenin tipi, beklenen trafik ve teknik kontrol ihtiyacınız belirler. Küçük bir tanıtım sitesi için paylaşımlı hosting yeterli, içerik ağırlıklı ve düzenli güncellenen bir site için yönetilen WordPress hosting mantıklı, yüksek trafikli ve performans-kritik bir proje için ise VPS, bulut ya da modern statik/JAMstack barındırma (Vercel, Netlify, Cloudflare Pages) doğru tercihtir. Domain ve SSL'i bu rehberin diğer bölümlerinde ele aldık; burada odak, sitenizi gerçekten "barındıran" katmandır. Yanlış hosting seçimi, en iyi tasarımı bile yavaşlatıp Core Web Vitals skorlarınızı düşürür; doğru seçim ise hız, güvenlik ve maliyet dengesini en baştan kurar.

Müşterilerimizde gördüğümüz en yaygın hata, "en ucuz paylaşımlı paket"i alıp birkaç ay sonra trafik ya da güvenlik nedeniyle sıkışmaktır. İkinci en yaygın hata ise tam tersidir: küçük bir tanıtım sitesi için gereğinden büyük bir bulut sunucusu kiralayıp her ay boşa para ödemek. Hosting kararı, sitenin bugünkü değil 12-24 aylık projeksiyonuna göre verildiğinde ikisinden de kaçınılır. Bir başka deyişle hosting, "şimdi en ucuzu hangisi" değil, "büyürken beni nerede sıkıştırmaz" sorusunun cevabıdır. Aşağıda hosting türlerini somut olarak açıyor, performans ve güvenlik etkisini ölçülebilir biçimde ortaya koyuyor, ardından Türkiye'de en çok sorulan yerli/yurt dışı hosting ve KVKK/veri yeri konusunu netleştiriyoruz.

Hosting Türleri: Paylaşımlı, VPS, Bulut, Yönetilen ve Statik

Hosting türleri temelde iki eksende ayrışır: sunucu kaynaklarını kaç kişiyle paylaştığınız (paylaşımlı → izole) ve altyapı yönetiminin kimde olduğu (sizde → sağlayıcıda). Bu iki eksen birlikte maliyeti, hızı, güvenliği ve sizin üzerinize kalan bakım yükünü belirler. Beş ana türü ve tipik kullanım senaryolarını şöyle açabiliriz:

• Paylaşımlı (shared) hosting: Tek bir fiziksel sunucu yüzlerce, bazen binlerce siteyle paylaşılır; CPU, RAM ve disk I/O ortaktır. En ucuz seçenek, teknik bilgi gerektirmez, cPanel/Plesk gibi bir panelle yönetilir; küçük tanıtım siteleri, kişisel bloglar ve düşük trafikli kurumsal sayfalar için yeterlidir. Dezavantajı: "komşu" siteler kaynağı tüketirse siteniz yavaşlar ya da geçici olarak erişilemez hale gelir (gürültülü komşu / noisy neighbor); kaynak ve yapılandırma kontrolü sınırlıdır, çoğu zaman kök (root) erişiminiz yoktur. Trafik dalgalanmalarında ilk sıkışan tür budur.
• VPS (Virtual Private Server): Bir fiziksel sunucu sanallaştırma ile bölünür; size ayrılmış, garantili CPU çekirdeği ve RAM olur. Komşunun yükü artık sizi doğrudan etkilemez. Orta düzey trafik, özel yapılandırma (kendi PHP/Node sürümünüz, özel cron'lar, özel güvenlik kuralları) ve büyüyen siteler için doğru basamaktır. Yönetilmeyen (unmanaged) VPS'te işletim sistemi, güncelleme ve güvenlik tamamen sizdedir; yönetilen (managed) VPS'te sağlayıcı bu yükün bir kısmını üstlenir ama maliyet artar.
• Dedicated / bulut (cloud) hosting: Dedicated'da tüm fiziksel sunucu yalnızca sizindir; en yüksek izolasyon ve ham performans budur, ancak donanım sabit olduğu için ani trafiği elastikçe karşılamaz. Bulut (cloud) ise kaynakları dinamik ölçekler: trafik artınca otomatik büyür (auto-scaling), düşünce küçülür ve genelde kullandığın kadar öde modeliyle faturalanır. Yüksek trafik, kampanya/indirim dönemleri ve kesintisizlik (yüksek erişilebilirlik) gerektiren projeler için idealdir. Maliyet ve yönetim karmaşıklığı en yüksek grup buradadır; çoğu zaman özel bir DevOps yetkinliği ister.
• Yönetilen WordPress hosting (managed): Sunucu yapılandırması, çekirdek/PHP güncellemeleri, sunucu seviyesi önbellek (cache), güvenlik kuralları, otomatik yedekleme ve genellikle bir staging (deneme) ortamı sağlayıcı tarafından WordPress'e özel optimize edilir. WordPress tüm web'in yaklaşık %41,9'unu, CMS kullanan sitelerin ise yaklaşık %59,5'ini çalıştırdığı için (Haziran 2026, W3Techs) bu kategori oldukça olgun ve yaygındır. Standart paylaşımlıdan pahalıdır ama bakım yükünü ciddi azaltır ve performansı baştan yüksek tutar; CMS seçiminizi WordPress'ten yana yaptıysanız çoğu durumda en rasyonel tercihtir.
• Modern statik / JAMstack barındırma: Vercel, Netlify ve Cloudflare Pages gibi platformlar; Next.js, Astro gibi framework'lerle üretilen statik/edge sitelerini global bir CDN üzerinden, ziyaretçiye en yakın "kenar" (edge) noktasından dağıtır. Geleneksel anlamda bir sunucu "kiralamaz", bir dağıtım (deployment) yaparsınız; ölçekleme platform tarafında otomatiktir. Edge ve CDN, içeriği coğrafi olarak en yakın noktadan sunarak ilk yanıt süresini ve dolayısıyla hızı belirleyici biçimde iyileştirir. Özel yazılımla geliştirilen, performans-kritik projeler için 2026'da öne çıkan yaklaşımdır.

Burada kritik bir nokta var: hosting türü tek başına hızı garanti etmez; CDN (İçerik Dağıtım Ağı) ve edge dağıtımı en az sunucu sınıfı kadar belirleyicidir. Cloudflare gibi bir CDN, hem statik içeriği (görsel, CSS, JavaScript) ziyaretçiye yakın kopyalardan sunarak hızlandırır hem de bir güvenlik katmanı (WAF — Web Uygulama Güvenlik Duvarı, DDoS azaltma, bot ve kötü trafik filtreleme) sağlar. Pratikte "orta sınıf sunucu + iyi yapılandırılmış CDN" kurulumu, çoğu zaman "güçlü sunucu + CDN'siz" kurulumdan daha iyi gerçek dünya hızı verir; çünkü ziyaretçinin coğrafi mesafesi ve sunucunun her isteği sıfırdan üretmesi ortadan kalkar. Bu yüzden hosting kararını CDN stratejisinden ayrı düşünmemenizi öneriyoruz; ikisi tek bir altyapı kararıdır.

Hosting Türleri Karşılaştırma Tablosu

Aşağıdaki tablo, beş ana hosting türünü maliyet, performans, kontrol, bakım yükü ve tipik kullanım açısından karşılaştırır. Değerler tipik durumu yansıtır; sağlayıcı, paket ve yapılandırmaya göre değişir.

Tablodan çıkan pratik kural şudur: bakım yükünü sağlayıcıya devretmek istiyorsanız yönetilen WordPress ya da statik/edge barındırma; tam teknik kontrol istiyorsanız VPS ya da bulut; bütçeniz sınırlı ve site küçükse paylaşımlı doğru başlangıçtır. Dikkat edilmesi gereken bir nüans: "teknik kontrol" ve "bakım yükü" birbirine ters orantılı görünür ama statik/edge barındırma bu ikisini ayırır; kod tarafında tam kontrol verirken altyapı bakımını sağlayıcıya bırakır. Bu yüzden framework tabanlı projelerde hem esneklik hem düşük operasyon yükü aynı anda elde edilebilir. Hangi platform üzerinde çalışacağınız da seçimi belirler; hazır site mi özel yazılım mı kararınız, doğrudan hangi hosting kategorisine yöneleceğinizi tayin eder. Örneğin Webflow, Shopify ya da Türkiye'de ikas gibi platformlarda hosting zaten platforma gömülüdür; ayrı bir sunucu kiralamaz, ayrı bir hosting faturası ödemezsiniz. Buna karşılık bu modelin bedeli platform bağımlılığıdır (vendor lock-in): altyapıyı yönetmezsiniz ama o platformdan çıkmak da zorlaşır.

Hosting Performansı Tasarımı ve SEO'yu Nasıl Etkiler?

Hosting, doğrudan kullanıcının gördüğü hıza, yani Core Web Vitals metriklerine yansır. Bu metriklerin "iyi" eşikleri saha verisinin 75. yüzdeliğinde şöyledir: LCP (Largest Contentful Paint — en büyük içeriğin görünme süresi) 2,5 saniyenin altı; INP (Interaction to Next Paint — etkileşime yanıt hızı) 200 ms'nin altı; CLS (Cumulative Layout Shift — beklenmedik kayma) 0,1'in altı. Hosting'in en doğrudan etkilediği metrik LCP'dir. Çünkü zincirin ilk halkası sunucunun ilk bayt süresidir (TTFB — Time To First Byte): tarayıcı isteği gönderdikten sonra sunucudan ilk yanıtın gelme süresi. Yavaş, uzak ya da yük altında sıkışan bir sunucu, kullanıcı daha hiçbir şey görmeden zaman kaybettirir; bu gecikme doğrudan LCP'ye eklenir. Modern bir edge/CDN kurulumu, içeriği ziyaretçiye yakın bir noktadan ve mümkünse önceden üretilmiş (statik) olarak sunarak TTFB'yi en aza indirir.

INP açısından da hosting'in dolaylı bir rolü vardır: INP, 12 Mart 2024'te FID'in (First Input Delay) yerini alarak resmî Core Web Vital oldu ve tek bir etkileşim yerine sayfadaki tüm etkileşimleri (giriş gecikmesi + işleme + sunum) ölçer. INP'yi asıl bozan ağır JavaScript'tir; ancak sunucu tarafı render (SSR) yapan kurulumlarda yavaş bir sunucu, etkileşimi tetikleyen isteklerin yanıtını da geciktirir. CLS ise büyük ölçüde tasarım/kod meselesidir (görsele yer ayırmamak, fontun geç yüklenmesi), ama bir sunucu yapılandırması olan font ve görsellerin doğru önbellek başlıklarıyla hızlı sunulması burada da yardımcı olur. Özetle hosting, üç metrikten en az birini (LCP) belirleyici biçimde, diğer ikisini dolaylı olarak etkiler.

Performansla ilgili bir diğer kritik nokta mobil deneyimdir. Mobil cihazlar küresel web trafiğinin yaklaşık %60'ını oluşturur (2026; kaynağa ve döneme göre değişir) ve Türkiye gibi pazarlarda bu oran %80'e kadar çıkabilir. Mobil cihazlar daha yavaş şebeke ve daha kısıtlı CPU kullandığı için, sunucunun ve CDN'in hızı mobilde masaüstüne göre daha da belirleyicidir; aynı gecikme, mobil kullanıcıda orantısız biçimde daha çok hissedilir. Üstelik Google artık varsayılan olarak sitenin mobil sürümünü indeksler ve sıralar (mobile-first indexing); yani mobilde yavaş bir altyapı, hem dönüşümü hem de organik sıralamayı doğrudan vurur. Hosting kararınızı verirken mobil-öncelikli tasarım hedefinizi göz önünde tutmanızı öneriyoruz. Hız sorunlarını sayısal olarak ölçmek isterseniz PageSpeed Insights ile sunucu yanıt süresinin (TTFB) LCP'ye etkisini somut olarak görebilir, lab ve saha verisini karşılaştırabilirsiniz. CWV'nin yalnızca teknik bir hijyen değil, ölçülebilir bir sıralama sinyali olduğunu da hatırlatalım: tüm eşikleri geçen siteler tipik olarak daha düşük hemen çıkma oranı ve daha iyi organik görünürlük elde eder.

Hosting ayrıca bir güvenlik ve süreklilik meselesidir. Düzenli, otomatik, sürümlü (versiyonlu) ve site dışı (off-site) yedekleme; bir saldırı, eklenti çökmesi ya da kullanıcı hatasından sonra çoğu zaman tek kurtarma yolunuzdur. Yedeğin "site dışı" olması kritiktir: yedek aynı sunucuda duruyorsa, sunucu ele geçirildiğinde ya da disk arızalandığında yedek de kaybolur. Yönetilen ve bulut hosting paketleri genellikle bu yedekleri otomatik ve sürümlü sağlarken, ucuz paylaşımlı paketlerde yedek sorumluluğu çoğu zaman sizdedir ve "sağlayıcı yedek alıyordur" varsayımı tehlikelidir. Geri yükleme (restore) sürecini de periyodik test etmek gerekir; çünkü hiç denenmemiş bir yedek, gerçekte işe yarayıp yaramadığı bilinmeyen bir yedektir. Güncel tutma da bu güvenlik resminin parçasıdır: OWASP Top 10:2025'te yazılım tedarik zinciri zafiyetleri (Software Supply Chain Failures) ilk kez ayrı bir kalem olarak listeye girdi; CMS çekirdeği, tema ve eklentilerin güncel tutulmaması, bilinen açıkların (CVE) en sık sömürüldüğü kapıdır. Bakımsız ve yedeksiz bir site, hem SEO hem güvenlik açısından hızla değer kaybeder.

Yerli Hosting mi, Yurt Dışı Hosting mi? (TR Bağlamı)

Bu, Türkiye'deki firmaların bize en sık sorduğu sorulardan biridir. Kısa cevap: tek bir doğru yok; ziyaretçi kitlenize, performans stratejinize ve veri/KVKK yaklaşımınıza göre değişir. İkisinin de güçlü yanları var:

• Yerli (yurt içi) hosting avantajları: Türkiye'deki ziyaretçiye fiziksel yakınlık sayesinde düşük gecikme (latency) ve hız; KVKK ve veri yerelleştirme algısı açısından tercih sebebi; Türkçe destek, yerel ödeme/faturalandırma kolaylığı ve TL bazlı sabit maliyet (kur dalgalanmasından etkilenmeme). .com.tr alan adıyla birlikte bütünlük algısı da bir artıdır. Yerel destek hattının saat dilimi ve dil olarak erişilebilir olması, sorun anında çözüm hızını artırır.
• Yurt dışı hosting + global CDN avantajları: Modern global CDN ve edge altyapısıyla (örneğin Cloudflare, Vercel edge) yurt dışında barındırılan bir site de Türkiye'deki ziyaretçiye çok hızlı sunulabilir; çünkü içerik fiziksel kaynak sunucudan değil, en yakın edge noktasından gelir. Genellikle daha geniş özellik seti, daha iyi ölçeklenme, daha olgun araç ekosistemi ve daha yüksek altyapı güvenilirliği sunar. Uluslararası kitleye hitap eden projelerde tek bir lokal sunucunun coğrafi sınırını aşar.

Yani "yurt dışı sunucu yavaştır" yargısı, CDN/edge çağında artık otomatik olarak doğru değildir. Asıl belirleyici, sunucunun coğrafi konumundan çok içeriğin nereden, nasıl ve hangi önbellek stratejisiyle dağıtıldığıdır. Tersine, "yurt içi sunucu her zaman daha hızlıdır" yargısı da eksiktir: CDN'siz, eski donanımlı ya da aşırı paylaşımlı bir yurt içi paket, iyi yapılandırılmış bir global edge kurulumundan yavaş kalabilir. Bizim müşterilerimizde uyguladığımız pratik yaklaşım şudur: ziyaretçi kitlesi neredeyse tamamı Türkiye olan, global CDN kullanmayan ve teknik ekibi sınırlı basit siteler için yurt içi barındırma; framework tabanlı, performans-kritik ve uluslararası kitleye de hitap eden projeler için global edge platformları tercih etmek. İki dünyanın ortası da mümkündür: yurt içi/yurt dışı fark etmeksizin kaynak sunucunun önüne bir global CDN koymak, çoğu senaryoda en sağlam kurulumdur. Karar verirken mevcut altyapınızı ya da rakiplerinizin altyapısını altyapı tespit aracımızla görmek de yön gösterebilir.

KVKK ve Veri Yeri: Hosting Seçiminde Hukuki Boyut

Hosting kararının bir de hukuki katmanı var ve bu katman Türkiye'de sık atlanır. KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) açısından kişisel veri işleyen her site bir "veri sorumlusu"dur ve veri güvenliği için teknik/idari tedbirler almak yasal zorunluluktur (KVKK m.12). Bu tedbirler HTTPS/TLS ile trafik şifreleme, depolanan verinin şifrelenmesi, erişim kontrolü, log (kayıt) tutma ve gerektiğinde veri ihlali bildirimini kapsar. Bir güvenlik açığı bu nedenle yalnızca teknik değil aynı zamanda hukuki bir risktir. Hosting seçiminin buradaki en kritik bağlantısı şudur: kişisel verinin yurt dışına aktarımı KVKK'nın özel kurallarına tabidir.

Pratikte bu, müşteri kayıtları, iletişim formu verileri, üyelik bilgileri ya da sipariş geçmişi gibi kişisel verileri yurt dışındaki bir sunucuda barındırmanın, "yurt dışına veri aktarımı" rejimine girebileceği anlamına gelir. Bu durumda KVKK'nın aktarım koşullarına uymak gerekir. Yurt içi barındırma, bu süreci algı ve uyum açısından basitleştirdiği için tercih edilir; ancak global CDN/edge kullanan modern kurulumlarda kararın özü "sunucu nerede" değil, "kişisel veri fiziksel olarak nerede tutuluyor"dur. Birçok global platform, veri merkezi bölgesini (region) seçmenize izin verir; veri işleyen bir projede bu bölgeyi Türkiye ya da AB olarak yapılandırmak, hem uyumu kolaylaştırır hem de gecikmeyi düşürür. Sağlayıcıyla bir veri işleme sözleşmesi (DPA) yapmak ve hangi alt-işleyicilerin (CDN, yedekleme, e-posta) devreye girdiğini bilmek de bu resmin parçasıdır.

Hosting kararı, sitenizin diğer yasal yükümlülükleriyle de iç içedir. KVKK aydınlatma metni, çerez politikası ve gizlilik politikası her kurumsal sitede bulunmalı; siteye girişte çerez bandı yer almalı ve zorunlu olmayan (analitik/pazarlama) çerezler için açık rıza alınmalıdır. E-ticaret varsa 6502 sayılı Tüketicinin Korunması Kanunu ve Mesafeli Sözleşmeler Yönetmeliği gereği mesafeli satış sözleşmesi, ön bilgilendirme formu ve iade/cayma koşulları eklenmelidir. Üstelik KVKK'nın güncel İlke Kararı, aydınlatma metni ile açık rıza/ticari ileti iznini AYRI AYRI düzenlemenizi pekiştirdiğinden, tek bir kutuda "hepsini kabul ediyorum" yaklaşımı hukuken sakıncalıdır. Veri toplayan formların bulunduğu bir sitede, altyapı kararıyla hukuki uyumu birlikte planlamak gerekir; çünkü verinin nerede tutulduğu ve nasıl korunduğu, bu metinlerde beyan ettiğiniz taahhütlerle tutarlı olmak zorundadır. Bu uyumun doğru kurgulanması özellikle kurumsal web siteleri için kritiktir.

Hosting Geçişi ve Kilitlenme (Lock-in): Sonradan Taşınabilir misiniz?

Hosting kararını verirken çoğu firmanın gözden kaçırdığı bir boyut, "yanlış seçersem geri dönüşü ne kadar zor" sorusudur. Cevap, seçtiğiniz türe göre dramatik biçimde değişir. Açık kaynak bir CMS'i (örneğin WordPress) standart bir paylaşımlı/VPS hosting'de çalıştırıyorsanız, kod ve veritabanı sizin elinizdedir; başka bir sağlayıcıya taşımak görece düz bir işlemdir (dosyaları ve veritabanını taşı, alan adını yönlendir, SSL'i yenile). Buna karşılık Wix, Squarespace ya da Shopify gibi kapalı platformlarda içerik ve tasarım büyük ölçüde platforma kilitlidir; çıkış yaparken metni dışa aktarabilseniz de tasarımı ve bazı işlevleri sıfırdan kurmanız gerekebilir. Statik/edge platformlarında ise kod sizin deponuzda (Git) durduğu için taşınabilirlik yüksektir; başka bir edge sağlayıcısına geçmek çoğu zaman birkaç yapılandırma değişikliğiyle mümkündür.

Hosting geçişi yaparken en kritik teknik nokta SEO'yu korumaktır. URL yapısı değişiyorsa eski adreslerden yenilerine kalıcı 301 yönlendirme kurmak şarttır; aksi halde mevcut sıralama ve geri bağlantı (backlink) değeri kaybolur. Geçiş, mümkünse trafiğin düşük olduğu bir saatte ve önce bir staging (deneme) ortamında test edilerek yapılmalı; geçiş sonrası 404 hataları, SSL geçerliliği ve Core Web Vitals takip edilmelidir. DNS yayılması (propagation) sırasında kısa bir geçiş penceresi olabileceğinden, eski sunucuyu yeni sunucu doğrulanana kadar kapatmamak iyi bir pratiktir. Bu disiplin, bir hosting değişikliğinin görünmez SEO kayıplarına dönüşmesini engeller.

Hosting Seçiminde Pratik Karar Yolu

Tüm bunları sadeleştirip somut bir karar yoluna dökelim. Hosting seçerken sırasıyla şu soruları yanıtlamanızı öneriyoruz:

1. Site tipi nedir? Basit tanıtım/blog → paylaşımlı; içerik ağırlıklı WordPress → yönetilen WordPress; özel yazılım/framework → statik/edge (Vercel/Netlify/Cloudflare Pages); hazır platform (Shopify/Wix/ikas) → ayrı hosting yok, platforma gömülü.
2. Beklenen trafik ve büyüme? Düşük ve sabit → paylaşımlı; artıyor/değişken → VPS; yüksek, ani sıçramalı veya kampanya yoğun → bulut/edge (otomatik ölçeklenen).
3. Teknik kontrol ihtiyacınız? Sunucu seviyesinde tam kontrol istiyorsanız VPS/bulut; bakımı tamamen devretmek istiyorsanız yönetilen WordPress ya da statik/edge.
4. Ziyaretçi kitlesi nerede ve CDN var mı? Neredeyse tamamı Türkiye ve CDN yok → yurt içi; uluslararası ya da önünde global CDN olacak → yurt dışı/edge de pekâlâ uygundur.
5. Hangi veriyi topluyorsunuz? Yoğun kişisel veri işliyorsanız KVKK yurt dışı aktarım kurallarını ve veri merkezi bölgesini baştan netleştirin; gerekirse bölgeyi TR/AB seçin.
6. Sonradan taşınabilirlik önemli mi? Kilitlenmeden kaçınmak istiyorsanız açık kaynak CMS ya da kodu kendi deponuzda tutan statik/edge yaklaşımı; hız ve kolaylık önceyse hazır platform.

Bu altı soruyu netleştirdiğinizde, hosting türü çoğu zaman kendiliğinden ortaya çıkar. Yine de altyapı kararı; tasarımı, performansı, güvenliği, SEO'yu ve hukuki uyumu aynı anda etkileyen bütünsel bir karardır. Yanlış başlanırsa sonradan taşıma maliyetli ve risklidir; doğru başlanırsa görünmez ama en sağlam temeli kurar. Hangi hosting ve altyapı kurgusunun sizin projeniz için en doğru olduğundan emin değilseniz, web ve yazılım geliştirme ekibimizle değerlendirme yapabilir ya da ihtiyaçlarınızı netleştirmek için ücretsiz bir altyapı ve site analizi talep edebilirsiniz. Doğru hosting seçimi, hızlı, güvenli ve KVKK-uyumlu bir sitenin görünmeyen ama en sağlam temelidir.

SSL/TLS, HTTPS ve Kurumsal E-Posta: Web Sitenizin Görünmez Altyapısı

SSL/TLS, web sitenizle ziyaretçi arasındaki tüm trafiği şifreleyen, karşı tarafın gerçekten sizin siteniz olduğunu doğrulayan ve verinin yolda değiştirilmediğini garanti eden güvenlik protokolüdür; HTTPS ise bu şifreli katman üzerinden çalışan web protokolüdür. Kısacası: HTTP düz kartpostal, HTTPS ise mühürlü zarftır. 2026 itibarıyla SSL artık "olsa iyi olur" değil, sitenizin yayında olabilmesi için pratikte zorunlu bir altyapı bileşeni. Tarayıcılar HTTPS olmayan sayfalarda "Güvenli değil" uyarısı gösteriyor, Google HTTPS'i bir sıralama sinyali olarak kullanıyor ve KVKK kapsamında kişisel veri işleyen her site için şifreli iletim teknik tedbir yükümlülüğünün bir parçası. Bu bölümde sertifikanın ne olduğunu, hangi türlerin var olduğunu, kurulumda en sık yapılan hataları ve çoğu firmanın ihmal ettiği kurumsal e-posta altyapısını net adımlarla açıklıyoruz. Konunun bütününü web sitesi güvenliği rehberimizde ele alıyoruz; bu yazı altyapı tarafının sertifika ve e-posta ayağını derinleştiriyor.

SSL ile TLS Arasındaki Fark Nedir?

Günlük dilde herkes "SSL sertifikası" der ama teknik olarak doğru terim TLS'tir (Transport Layer Security). SSL (Secure Sockets Layer) protokolün eski adıdır ve sürümleri yıllar önce güvenlik açıkları nedeniyle emekliye ayrılmıştır. Bugün tarayıcınız bir siteye bağlandığında aslında TLS kullanır; güncel ve önerilen sürümler TLS 1.2 ve TLS 1.3'tür. "SSL" terimi sektörde alışkanlıktan dolayı yaşamaya devam ediyor, sertifika satıcıları bile "SSL sertifikası" diye pazarlıyor; ama altyapı kurarken sunucunuzun TLS 1.2/1.3 desteklediğinden, eski SSL ve TLS 1.0/1.1 sürümlerinin kapalı olduğundan emin olun. Eski sürümler hem bilinen kriptografik zafiyetler taşır hem de modern tarayıcılar tarafından giderek reddedilir; sunucu yapılandırmanızda bunları aktif bırakmak, kapıyı kilitleyip pencereyi açık unutmaya benzer.

TLS üç temel işi aynı anda yapar: şifreleme (trafiği üçüncü kişiler okuyamaz), kimlik doğrulama (bağlandığınız sunucunun gerçekten o alan adının sahibi olduğunu sertifika ile doğrular) ve bütünlük (veri yolda değiştirilmediğini garanti eder). Bu üçü olmadan kullanıcının formunuza girdiği ad, telefon, kart bilgisi açık ağda okunabilir hâlde gezer. Özellikle açık Wi-Fi gibi güvensiz ağlarda HTTPS olmaması, oturum çalmaktan veri sızıntısına kadar somut risk demektir.

İşin teknik çekirdeğini bilmek altyapı kararlarınızı netleştirir: TLS bağlantısı kurulurken kısa bir "el sıkışma" (handshake) gerçekleşir. Bu aşamada sunucu sertifikasını sunar, taraflar kullanılacak şifreleme paketini (cipher suite) belirler ve oturuma özgü anahtarlar üretilir. TLS 1.3, bu el sıkışmayı TLS 1.2'ye göre ciddi biçimde sadeleştirip kısaltır; daha az gidiş-geliş demek, ilk bağlantıda daha düşük gecikme demektir. Yani TLS 1.3 yalnızca güvenlik değil, aynı zamanda bir hız tercihidir. Modern hosting ve edge platformları TLS 1.3'ü varsayılan sunar; kendi sunucunuzu yönetiyorsanız bu desteği açık tutmanız hem güvenlik hem performans kazancı sağlar.

HTTPS Neden Artık Zorunlu?

HTTPS'i bugün "opsiyonel" sayan herhangi bir profesyonel yaklaşım kalmadı. Bunun üç somut nedeni var:

• Tarayıcı uyarısı: Chrome, Safari ve Firefox, HTTPS olmayan ya da şifre/form içeren HTTP sayfalarında adres çubuğunda "Güvenli değil" ibaresi gösterir. Bu uyarı, ziyaretçinin siteden çıkıp dönüşümü kaybetmesi için fazlasıyla yeterlidir; kurumsal güveni doğrudan zedeler.
• SEO sinyali: Google, HTTPS'i bir sıralama sinyali olarak teyit etmiştir. Tek başına devasa bir etki değildir ama eşit koşullarda HTTPS'li site önde başlar; ayrıca HTTP/2 ve HTTP/3 gibi hız avantajları yalnızca HTTPS üzerinden çalışır, bu da dolaylı olarak Core Web Vitals performansını etkiler.
• Yasal/güvenlik zorunluluğu: KVKK madde 12 kişisel veri işleyen siteler için "veri güvenliği" teknik tedbirlerini yasal zorunluluk hâline getirir; şifreli iletim (HTTPS) bunun temel bileşenidir. İletişim formu olan en sade kurumsal sitede bile ziyaretçinin adı ve telefonu kişisel veridir.

Hız bağlantısını biraz daha açalım, çünkü çoğu firma "HTTPS sadece güvenlik" sanır. HTTP/2 ve HTTP/3, çok sayıda dosyayı (CSS, JS, görsel) tek bağlantı üzerinden eşzamanlı taşıyarak sayfa yüklemesini hızlandırır; ama bu protokoller tarayıcılarda yalnızca TLS üzerinden, yani HTTPS ile devreye girer. Dolayısıyla HTTPS'e geçmek, dolaylı olarak en büyük içeriğin daha erken görünmesine (LCP) katkı sağlayabilir. Yani HTTPS, güvenlik ve performansı aynı anda iyileştiren nadir altyapı kararlarından biridir; bu yüzden hız odaklı çalışmalarda da başlangıç noktasıdır. Hız tarafını ayrıntılı incelemek için PageSpeed Insights rehberimize bakabilirsiniz.

İyi haber şu: maliyet artık bir engel değil. Let's Encrypt sayesinde geçerli bir TLS sertifikası ücretsizdir ve çoğu modern hosting, Vercel/Netlify/Cloudflare Pages gibi platformlar sertifikayı otomatik üretip 90 günde bir kendiliğinden yeniler. Yani sertifika almak için ayrı para ödemek çoğu senaryoda gereksizdir. Sertifika türleri arasındaki farkı bilmek yine de önemlidir, çünkü her sertifika aynı şeyi doğrulamaz.

Sertifika Türleri: DV, OV ve EV Arasındaki Fark

TLS sertifikaları, sundukları şifreleme açısından genelde aynı güçtedir; aralarındaki fark, sertifika makamının (Certificate Authority) sahibini ne kadar derin doğruladığıdır. Yani DV ile EV arasındaki ayrım "daha güçlü şifreleme" değil, "daha derin kimlik doğrulama"dır. Üç ana doğrulama seviyesi vardır:

Pratik gerçek şu: ziyaretçilerin büyük çoğunluğu sertifika türünü ayırt etmez; tarayıcılar artık EV sertifikalar için eskiden gösterdikleri yeşil firma adı çubuğunu da büyük ölçüde kaldırdı. Bugün ister DV ister EV olsun, kullanıcı yalnızca adres çubuğundaki kilit ikonunu görür. Bu yüzden tipik bir kurumsal tanıtım sitesi, e-ticaret olmayan bir hizmet sitesi ya da blog için ücretsiz DV sertifikası fazlasıyla yeterlidir ve OV/EV'ye para harcamak çoğu durumda gereksizdir. OV/EV daha çok kurumsal satın alma politikası, denetim gereksinimi ya da finans gibi yüksek hassasiyet alanlarında anlam taşır; örneğin bir bankanın ya da kurumsal ödeme sağlayıcısının denetim raporunda EV sertifika beklentisi olabilir.

Kapsam (sertifikanın kaç alan adını koruduğu) seçimini de baştan netleştirin, çünkü yanlış kapsam sonradan ek maliyet ve uyarı üretir:

• Tekil (single-domain): Yalnızca tek bir alan adını kapsar (örn. firmaniz.com). En sık ihmal edilen ayrıntı: çoğu sertifika hem köke hem www alt alanına otomatik geçerli olmayabilir; www ve köksüz sürümün ikisini de kapsadığından emin olun, yoksa biri uyarı verir.
• Wildcard: Bir alan adının tüm alt alanlarını tek sertifikada toplar (örn. *.firmaniz.com — blog.firmaniz.com, panel.firmaniz.com vb.). Çok sayıda alt alan barındıracaksanız ekonomiktir.
• SAN / multi-domain: Birden çok farklı alan adını tek sertifikada toplar (örn. firmaniz.com + firmaniz.com.tr + firmaniz.net). Marka koruması için birden çok uzantı tutuyorsanız işinizi kolaylaştırır.

Altyapınızı kurarken kaç alt alan ve kaç farklı alan adı barındıracağınızı baştan planlayın; ileride blog, panel, portal gibi alt alanlar ekleyecekseniz wildcard tercih etmek, her yeni alt alan için ayrı sertifika uğraşından kurtarır.

Sertifika Kurulumu ve İhmal Edilen Detaylar

Sertifikayı kurmak işin yarısıdır; sık atlanan ayarlar sitenizi "yarı güvenli" bırakır, hatta bazen tamamen "güvenli değil" uyarısına düşürür. Altyapı kurulumunda şu noktalara dikkat edin:

• HTTP'den HTTPS'e kalıcı yönlendirme: Tüm http:// isteklerini https://'e 301 ile yönlendirin. Aksi halde site her iki protokolde de açık kalır, eski HTTP bağlantıları "güvenli değil" uyarısı vermeye devam eder ve aynı içerik iki ayrı adreste indekslenerek SEO açısından çift içerik riskine yol açar. Bu yönlendirme aynı zamanda site yenileme süreçlerinde kritiktir; redesign rehberimizde URL yönlendirme disiplinini ayrıca işliyoruz.
• Karışık içerik (mixed content): Sayfa HTTPS olsa bile içindeki bir görsel, script ya da iframe hâlâ http:// ile çağrılıyorsa tarayıcı sayfayı tam güvenli saymaz, kilit ikonu kırılır ve bazı kaynaklar engellenir. Bu özellikle eski temadan/eklentiden taşınan sitelerde ve harici gömülü içeriklerde görülür. Tüm kaynakları HTTPS üzerinden çağırın; tarayıcı geliştirici konsolu mixed content uyarılarını tek tek listeler.
• HSTS başlığı: Strict-Transport-Security başlığı tarayıcıya "bu siteyi her zaman HTTPS ile aç" der ve ilk istekteki açığı kapatır. İlk ziyarette kullanıcı yanlışlıkla HTTP yazsa bile tarayıcı doğrudan HTTPS'e geçer. Kurumsal sitelerde önerilir; ancak HSTS güçlü bir taahhüttür, etkinleştirmeden önce tüm alt alanlarınızın sorunsuz HTTPS sunduğundan emin olun.
• Otomatik yenileme: Let's Encrypt sertifikaları 90 gün geçerlidir. Otomatik yenileme kurulu değilse sertifika sessizce sona erer ve siteniz bir sabah "güvenli değil" uyarısıyla açılır — üstelik bunu genellikle siz değil, telefon eden bir müşteri fark eder. Yönetilen hosting ve edge platformları (Vercel, Netlify, Cloudflare Pages) bunu otomatik halleder; kendi sunucunuzu yönetiyorsanız yenilemeyi mutlaka zamanlanmış bir göreve bağlayın ve sertifika son kullanma tarihini izleyen bir uyarı kurun.
• Güvenlik başlıkları paketi: Sertifikanın yanına Content-Security-Policy, X-Content-Type-Options, Referrer-Policy gibi başlıkları eklemek, HTTPS'in koruduğu güveni tamamlar. Sertifika trafiği şifreler; bu başlıklar ise sayfa içi saldırı yüzeyini daraltır.

Kurulumdan sonra mutlaka dış bir bakış açısıyla doğrulayın: tarayıcıda kilit ikonuna tıklayıp sertifikanın geçerli, doğru alan adına ait ve süresinin uzak olduğunu görün; ayrıca hem www hem köksüz adreste, hem ana sayfada hem iç sayfalarda uyarı çıkmadığını kontrol edin. Alan adınızın doğru yapılandırılıp yapılandırılmadığını, hangi DNS kayıtlarının aktif olduğunu hızlıca görmek için domain sorgulama aracımızı kullanabilir, alan adı seçimi ve devri konusundaki ayrıntılar için domain sorgulama nasıl yapılır yazımıza göz atabilirsiniz.

Kurumsal E-Posta: Altyapının En Çok İhmal Edilen Parçası

Firmaların büyük kısmı siteye yatırım yapar ama e-postada hâlâ firmaniz@gmail.com ya da info_firma_2024@hotmail.com gibi adresler kullanır. Bu, profesyonel görünümü tek hamlede zedeleyen bir hatadır; teklif gönderdiğiniz kurumsal bir alıcının gözünde "henüz kendi alan adından e-posta kuramamış firma" algısı yaratır. Kurumsal e-posta, kendi alan adınız üzerinden çalışan e-posta hesabıdır: ad@firmaniz.com. Tıpkı sertifika gibi, kurumsal e-posta da sitenizin "görünmez güven altyapısının" parçasıdır; ziyaretçiye ve müşteriye markanın ciddi olduğunu söyler. Konunun kurulum tarafını adım adım kurumsal e-posta nedir, nasıl alınır rehberimizde ele alıyoruz; burada altyapı bağlamında neden kritik olduğunu özetliyoruz.

Kurumsal e-postanın somut faydaları:

• Güven ve marka: Kendi alan adınızla gönderilen e-posta, ücretsiz e-posta servislerinden çok daha güvenilir algılanır; teklif, fatura ve sözleşme iletişiminde profesyonellik sağlar. Aynı zamanda alan adınızın tutarlı kullanımı, yerel SEO açısından önemli olan firma kimliği bütünlüğünü pekiştirir.
• Teslim edilebilirlik (deliverability): E-postalarınızın spam klasörüne değil gelen kutusuna düşmesi için alan adınıza SPF, DKIM ve DMARC kayıtlarının doğru tanımlanması şarttır. Bunlar, gönderdiğiniz e-postanın gerçekten sizin alan adınızdan çıktığını doğrulayan DNS kayıtlarıdır; eksik olduğunda kurumsal e-postanız bile spam'e düşer. Bu üç kayıt, e-posta dünyasının TLS sertifikası gibidir: kimliği doğrular.
• Kurumsal kontrol ve süreklilik: Personel ayrıldığında hesabı kapatabilir, yeni çalışana ad@firmaniz.com açabilir, tüm yazışma geçmişini firma çatısı altında tutabilirsiniz. Kişisel Gmail hesaplarında bu kontrol sizde değildir; çalışan ayrıldığında o adrese gelen tüm müşteri yazışması da onunla gider.

SPF, DKIM ve DMARC üçlüsünü biraz somutlaştıralım, çünkü "neden müşteriye gönderdiğim mail spam'e düşüyor" sorusunun yanıtı neredeyse her zaman buradadır:

Pratikte iki yaygın yol vardır: profesyonel posta sağlayıcısı (Google Workspace, Microsoft 365 gibi) ya da hosting paketinizle gelen e-posta hizmeti. Yoğun yazışma, takvim/doküman paylaşımı, ekip hesapları ve kurumsallık önemliyse profesyonel sağlayıcılar daha sağlam bir altyapı, daha iyi spam filtresi ve daha yüksek depolama sunar; küçük hacimli ihtiyaçlarda hosting e-postası başlangıç için yeterli olabilir. Bir ara seçenek olarak, sitenizin gönderdiği işlemsel e-postaları (form bildirimi, sipariş onayı, parola sıfırlama) ayrı bir gönderim servisi üzerinden yollamak teslim edilebilirliği belirgin biçimde artırır; bu durumda o servisin de SPF/DKIM kaydını alan adınıza eklemeniz gerekir. Hangi yolu seçerseniz seçin, SPF/DKIM/DMARC kayıtlarını mutlaka kurun ve kurduktan sonra kendinize ve farklı sağlayıcılardaki adreslere deneme e-postası göndererek gelen kutusuna düştüğünü doğrulayın.

Altyapı Bir Bütündür: Domain, Hosting, SSL ve E-Posta

Bu dört bileşeni ayrı ayrı düşünmek yerine tek bir güven altyapısı olarak ele almak gerekir. Alan adınız markanızın adresidir, hosting evinizdir, SSL/TLS kapınızın kilidi, kurumsal e-posta ise resmî kimliğinizdir. Birinde yapılan ihmal diğerlerinin değerini düşürür: ücretsiz e-posta kullanan güzel bir sitenin güveni eksik kalır, sertifikası süresi dolan bir sitenin tüm SEO yatırımı bir uyarı ekranında kaybolur, yanlış yapılandırılmış DNS yüzünden hem siteniz hem e-postanız aynı anda erişilemez hâle gelebilir. Bu bileşenlerin tümü çoğunlukla aynı yerde — alan adınızın DNS bölgesinde — kesişir; bu yüzden DNS kayıtlarınızı kim yönetiyorsa altyapının kalbini de o tutar.

Türkiye bağlamında ayrıca alan adı tarafında .com en güvenilir genel seçenektir; marka koruması için hem .com hem .com.tr almak yaygın bir pratiktir (.com.tr için marka tescili/belge gerekebilir). Yurt içi mi yurt dışı barındırma sorusunda ise kesin bir "doğru" yoktur: yurt içi barındırma TR ziyaretçiye düşük gecikme ve veri yerelleştirme algısı sunarken, modern global CDN (Cloudflare, Vercel edge) ile yurt dışı barındırma da TR'ye hızlı içerik sunabilir. Kişisel verinin yurt dışına aktarımının KVKK kurallarına tabi olduğunu, bu yüzden müşteri verisi işleyen sistemlerde barındırma yeri kararının hem teknik hem hukuki bir karar olduğunu unutmayın. Site mutlaka UTF-8 ve lang="tr" tanımlı olmalı, seçilen yazı tipi Türkçe karakterleri ve özellikle noktalı/noktasız I ayrımını sorunsuz desteklemelidir.

Altyapınızı sıfırdan kuruyor ya da mevcut sitenizi taşıyorsanız, sertifika kurulumundan SPF/DKIM/DMARC ayarına, HTTPS yönlendirmelerinden hosting ve DNS seçimine kadar tüm zinciri tek elden kurmak hata payını ciddi biçimde azaltır; özellikle taşıma sırasında DNS, sertifika ve e-posta kayıtlarının yanlış sıralanması, sitenin saatlerce erişilemez kalmasına yol açan en sık nedendir. Mevcut durumunuzu değerlendirmek ve doğru altyapı kararını birlikte vermek için ücretsiz analiz formumuzu doldurabilir, kurumsal web ve yazılım projeleriniz için özel yazılım ve web sitesi hizmetimizi inceleyebilirsiniz. Güvenli, hızlı ve KVKK uyumlu bir altyapı, iyi bir tasarımın üzerine kurulduğu görünmez ama vazgeçilmez temeldir.

Doğru kurulum sırası ne olmalı, en sık nerede hata yapılır?

Doğru kurulum sırası şudur: (1) önce alan adı, (2) sonra DNS yönetimi, (3) hosting, (4) SSL/TLS sertifikası, (5) yayın ve (6) sürekli bakım. Bu sırayı bozmak, web sitesi altyapısında gördüğümüz hataların büyük çoğunluğunun kaynağı. Müşterilerimizde en sık karşılaştığımız üç sorun ise tek bir cümlede özetlenebilir: yanlış hosting seçimi, eksik veya yanlış kurulmuş SSL ve yenileme tarihinin takip edilmemesi. Aşağıda hem doğru akışı hem de bu hataların nasıl önleneceğini somut adımlarla açıyoruz. Bu üç hatanın ortak yanı, hiçbirinin "tasarım" sorunu olmaması; üçü de görünmeyen altyapı katmanında yaşanıyor, ama sonuçları doğrudan sayfanın açılış hızında, arama sıralamasında ve cironuzda kendini gösteriyor.

Adım adım doğru kurulum akışı

Sıralama keyfi değil; her adım bir öncekinin üzerine kuruluyor. Genel kabul gören mantıksal sırada altyapı kurulumu şöyle ilerler:

1. Alan adını al ve sahipliğini kendine bağla. Domain'i marka adınla uyumlu, kısa ve akılda kalıcı seçin. .com hâlâ küresel güven standardı; Türkiye için .com.tr belge/marka tescili gerektirebilir (nic.tr kuralları), .com ve .net belgesiz alınabilir. Marka koruması için hem .com hem .com.tr'yi birlikte almak yaygın bir uygulama. Domain'in WHOIS/yönetim hesabının doğrudan size ait olması kritik — ajans veya bayi hesabına kilitli kalmamalı.
2. DNS yönetimini ayrı tut. Alan adını hosting'ten bağımsız yönetmek taşınabilirlik için önerilir. Domain bir yerde, hosting başka yerde, DNS yönetimi (örneğin Cloudflare) üçüncü bir yerde olabilir; bu ayrım, ileride hosting değiştirdiğinizde sitenizi rehin almaz.
3. Hosting'i trafik ve teknolojiye göre seç. Paylaşımlı (ucuz, küçük site), VPS (orta), dedicated/bulut (yüksek trafik), yönetilen WordPress hosting veya modern statik/JAMstack barındırma (Vercel, Netlify, Cloudflare Pages) seçenekleri var. Edge/CDN, hız için belirleyici.
4. SSL/TLS sertifikasını kur ve HTTPS'i zorla. Let's Encrypt ile ücretsiz; çoğu hosting otomatik sağlar. HTTPS artık opsiyonel değil, hem Google sıralama sinyali hem de tarayıcının "güvenli değil" uyarısını önlemenin tek yolu.
5. Yayına alıp test et. Mobil uyum, hız (Core Web Vitals), 404/yönlendirme kontrolü, yasal metinler (KVKK/çerez) ve form testleri tamamlanmadan canlıya geçmeyin.
6. Bakımı bir süreç olarak kur. Güvenlik güncellemeleri, yedekleme, kırık link ve sertifika/domain yenileme takibi süreklidir.

Bu altyapı adımları, sitenin geri kalanıyla iç içe çalışır. Bütünsel kurulum akışını web sitesi nasıl yapılır rehberinde adım adım anlatıyoruz; altyapı ise o sürecin ilk dört basamağı. Domain'in müsaitlik ve uzantı kontrolünü baştan yapmak için domain sorgulama aracımızı kullanabilir, detayları domain sorgulama nasıl yapılır yazısında inceleyebilirsiniz.

Her adımın kendi içinde gözden kaçan bir "tuzağı" var. Aşağıdaki tablo, doğru akışı, en sık yapılan hatayla ve pratik kontrol noktasıyla birlikte özetliyor; bu üç sütun, bir kurulumu canlıya almadan önce hızlıca gözden geçirmenizi sağlar:

Hata 1: Ucuz ya da yetersiz hosting seçmek

En yaygın ve en pahalıya patlayan hata bu. Aylık birkaç dolarlık paylaşımlı bir paket, tek başına "kötü" değildir; sorun, siteyi yanlış pakete yerleştirmektir. Müşterilerimizde gördüğümüz tipik tablo: WordPress + ağır eklenti yığını, kalabalık bir paylaşımlı sunucuya konuyor, ardından site açılmıyor diye şikayet geliyor. Paylaşımlı sunucuda yüzlerce site aynı CPU, RAM ve disk I/O kaynağını paylaşır; aynı makinedeki bir başka sitenin trafiği patladığında, sizin siteniz de yavaşlar. Bu "kötü komşu etkisi" özellikle akşam saatlerinde ya da kampanya dönemlerinde sitenizin neden açıklanamaz biçimde yavaşladığını anlatır.

Yetersiz hosting'in doğrudan ölçülebilir bedeli performansa düşer. Core Web Vitals "iyi" eşikleri (75. yüzdelik saha verisi) belli: LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1. LCP'nin en doğrudan belirleyicilerinden biri sunucu yanıt süresidir; yavaş, aşırı yüklü bir paylaşımlı sunucu LCP'yi tek başına eşiğin üzerine taşıyabilir. Çünkü LCP, ziyaretçinin ekranındaki en büyük içeriğin (genelde hero görseli ya da ana başlık) görünme süresidir ve bu süre, tarayıcı daha tek bir piksel çizmeden önce sunucunun ilk baytı (TTFB) ne kadar gecikmeyle gönderdiğine bağlıdır. Üstelik mobil cihazlar küresel web trafiğinin yaklaşık %60'ını oluşturuyor (2026; Türkiye gibi pazarlarda %80'e çıkıyor) ve mobil bağlantıların daha yavaş olması, sunucu gecikmesini affetmez. Mobil-öncelikli indeksleme de varsayılan olduğu için, Google sitenizin yavaş mobil sürümünü sıralar; masaüstünde her şey yolundayken mobilde kaybediyor olabilirsiniz.

Hosting türlerini doğru eşleştirmek için en sık karşılaştığımız senaryoları kısa bir karar tablosuna dökelim:

Pratik karar kriterleri:

• Trafiği ve teknolojiyi eşleştirin. Statik/JAMstack bir pazarlama sitesi için Vercel/Netlify/Cloudflare Pages gibi edge barındırma genelde en hızlısıdır. Eklenti yoğun WordPress için yönetilen WordPress hosting, paylaşımlıdan çok daha stabildir.
• CDN'i pas geçmeyin. Cloudflare gibi bir CDN/edge katmanı, içeriği ziyaretçiye coğrafi olarak yakın sunarak LCP'yi düşürür; ayrıca bir WAF (Web Application Firewall) katmanı olarak kötü trafiği ve botları filtreler, DDoS'u azaltır. CDN, statik dosyaları (görsel, CSS, JavaScript) sunucunuzdan değil size en yakın düğümden çektiği için hem sunucu yükünü hem de gecikmeyi belirgin düşürür.
• Yurt içi mi, yurt dışı mı? Yurt içi hosting, TR ziyaretçiye düşük gecikme sağlar ve KVKK/veri yerelleştirme algısı açısından tercih edilir; ancak modern global CDN ile yurt dışı barındırma da TR'ye hızlı sunabilir. Kişisel verinin yurt dışına aktarımı KVKK kurallarına tabidir, bunu baştan değerlendirin.
• "Sınırsız" vaadine güvenmeyin. CPU, eşzamanlı bağlantı ve I/O limitleri çoğu zaman gizlidir; trafik artınca site yavaşlar ya da askıya alınır. Sözleşmedeki "adil kullanım" maddesini ve eşzamanlı PHP/işlem limitlerini mutlaka sorun.
• Yedekleme dahil mi, hangi sıklıkta? Bazı ucuz paketlerde yedek yoktur ya da ücretlidir. Düzenli, otomatik, sürümlü ve site dışı (off-site) yedek, saldırı veya hata sonrası tek kurtarma yolunuzdur; geri yüklemeyi periyodik test edin.

Hosting ile hız arasındaki bağ, bütün performans zincirinin yalnızca ilk halkası. Sunucu yanıtından sonra görsel/JavaScript optimizasyonu devreye girer; bu konuyu site hızı ve SEO Core Web Vitals rehberinde ayrıntılandırdık. Mevcut sitenizin nerede kaybettiğini görmek için PageSpeed Insights nasıl iyileştirilir yazısı pratik bir başlangıç. Altyapının hız üzerindeki etkisi hazır site mi özel yazılım mı kararıyla da doğrudan ilişkilidir: özel yazılım (statik/edge) genelde en hızlı ölçeklenir, ağır eklentili WordPress yavaşlayabilir. WordPress'in tüm web'in yaklaşık %41,9'unu çalıştırdığını (W3Techs, Haziran 2026) düşünürsek, eklenti şişmesinden kaynaklı yavaşlık çok yaygın bir tablo; doğru altyapı seçimi bunu en baştan önler.

Hata 2: SSL'i eksik, yanlış ya da yarım kurmak

İkinci en sık hata SSL/TLS tarafında. Burada üç ayrı yanlış görüyoruz ve üçü de farklı sonuç doğuruyor:

• Sertifika hiç yok. Site http:// üzerinden açılıyor; modern tarayıcılar "Güvenli değil" uyarısı gösteriyor, ziyaretçi kaçıyor, Google sıralama tarafında dezavantaj oluşuyor. Çözüm en basit haliyle ücretsiz Let's Encrypt sertifikası.
• Sertifika var ama HTTPS zorlanmıyor. Site hem http hem https üzerinden açılıyor; bu "karışık" durum hem güvenlik hem SEO açısından sorunlu. Tüm http trafiğini kalıcı (301) yönlendirmeyle https'e taşımak ve HSTS başlığı eklemek gerekir. HSTS (HTTP Strict Transport Security), tarayıcıya "bu siteye bundan sonra hep https ile bağlan" der ve ilk http isteğini bile engelleyerek araya girme (man-in-the-middle) riskini azaltır.
• "Karışık içerik" (mixed content) hatası. Sayfa https olduğu halde içindeki bir görsel, script ya da font hâlâ http'den çekiliyor; tarayıcı bunları bloke ediyor veya kilit ikonunu kırıyor. Yayın öncesi tüm dahili kaynakların https olması test edilmeli. Bu hata özellikle eski bir siteyi https'e taşırken, içerikteki sabit (hardcoded) http bağlantıları yüzünden ortaya çıkar.

Terminolojiye de dikkat: günlük dilde "SSL" deniyor ama teknik olarak güncel protokol TLS (TLS 1.2/1.3). İşlevi aynı: tüm trafiği şifreler, sunucunun kimliğini doğrular ve veri bütünlüğünü garanti eder. Bu üç işlev, ziyaretçinin formda girdiği parolanın, kredi kartının ya da iletişim bilgisinin yol boyunca okunmasını veya değiştirilmesini engeller. Bu, KVKK açısından da kritik. KVKK m.12, kişisel veri işleyen sitelerde "veri güvenliği" teknik/idari tedbirlerini yasal zorunluluk sayar; HTTPS, şifreleme ve erişim kontrolü bu tedbirlerin temelidir. Yani eksik SSL yalnızca teknik değil, hukuki bir risktir — kişisel veri işleyen bir sitede şifrelenmemiş trafik, bir veri ihlali yaşandığında doğrudan idari yaptırım sebebi olabilir.

Sertifika türleri arasındaki farkı da bilmek faydalı. Çoğu site için DV (Domain Validation) sertifikası — Let's Encrypt'in verdiği tür — fazlasıyla yeterlidir; sadece alan adı sahipliğini doğrular ve dakikalar içinde, ücretsiz kurulur. OV (Organization Validation) ve EV (Extended Validation) sertifikaları kurum kimliğini de doğrular; bunlar kurumsal/finansal güven sinyali isteyen siteler için ücretli alternatiflerdir, ancak tarayıcı adres çubuğundaki görsel ayrıcalıkları büyük ölçüde kalktığı için bugün çoğu işletme için DV yeterli görülür. Karar verirken "şifreleme gücü" üçünde de aynıdır; fark yalnızca kimlik doğrulama derinliğindedir.

SSL tek başına sitenizi güvenli yapmaz; sadece taşıma katmanını şifreler. Üzerine sunucu tarafı doğrulama, CSRF token, rate-limit, 2FA ve güncel tutulan bileşenler gerekir — OWASP Top 10:2025'te A02 Security Misconfiguration (yanlış yapılandırma) listede 5'incilikten 2'nciliğe yükseldi, bu da yarım yapılandırmaların ne kadar yaygın olduğunu gösteriyor. Aynı listede A03 Software Supply Chain Failures (tedarik zinciri) yeni bir madde olarak girdi; pratikte bu, güncellenmemiş veya terk edilmiş üçüncü taraf eklenti/kütüphanelerin ne kadar büyük bir risk haline geldiğinin işareti. Bütün güvenlik katmanlarını web sitesi güvenliği nasıl sağlanır yazısında ele aldık.

Hata 3: Domain ve sertifika yenilemesini takip etmemek

Üçüncü hata, en sessiz ama en yıkıcı olanı. Hem alan adının hem de SSL sertifikasının bir son kullanma tarihi vardır ve ikisinin de süresi sessizce dolar:

• Domain süresi dolarsa site komple erişilemez hale gelir; daha kötüsü, kapanma süreci sonunda alan adı serbest kalıp başkası tarafından kapılabilir — markanızla birlikte. Yıllarca biriktirdiğiniz SEO değeri ve backlink'ler bir günde sıfırlanabilir. Domain'i kapan kişi sitenizin eski trafiğini farklı bir içeriğe yönlendirebilir, hatta markanız üzerinden sizi geri satın almaya zorlayabilir.
• SSL sertifikası süresi dolarsa tarayıcı tam ekran bir güvenlik uyarısı basar ve ziyaretçi siteye giremez; e-ticarette bu, doğrudan ciro kaybı demektir. Let's Encrypt sertifikaları kısa ömürlüdür ve otomatik yenilenir, ama otomatik yenileme bir gün sessizce kırılırsa kimse fark etmez — genelde sorun, hafta sonu ya da tatilde, yani en kötü zamanda ortaya çıkar.

Önlemi basit ama disiplin ister:

• Domain ve hosting'i mümkünse otomatik yenilemeye alın; süresi dolmuş ödeme kartı, otomatik yenilemenin sessizce başarısız olmasının en yaygın nedenidir, kartın geçerlilik tarihini güncel tutun.
• Yenileme tarihlerini takvime ve birden fazla kişiye hatırlatma olarak kurun; tek kişiye bağlı bir hatırlatma, o kişi izinde ya da işten ayrıldığında işe yaramaz.
• SSL otomatik yenilemesini periyodik olarak test edin; otomatik bir izleme aracıyla sertifika son kullanma tarihini ve site erişilebilirliğini sürekli kontrol ettirin.
• Faturalandırma ve uyarı e-postalarının spam'e düşmediğinden emin olun; pek çok "süresi doldu" vakasının kökeni, kayıt firmasının uyarısının görülmemesidir.
• Domain'i kendi hesabınızda tutun; yenileme uyarıları doğrudan size gelir, araya bir bayi ya da ajans girmez.

Aynı "unutma" sorunu site yenileme (redesign) sırasında da kritik bir hataya dönüşür: URL yapısı değişiyorsa eski adreslerden yenilere kalıcı 301 yönlendirme kurmayı atlamak, yıllarca biriken sıralama ve backlink değerini kaybettirir. Yenilemeyi sıfırdan başlamak gibi planlamayın; mevcut altyapı, URL ve içerik değerini koruyarak ilerleyin — adımlarını web sitesi yenileme rehberinde anlattık.

Daha az konuşulan ama maliyetli üç altyapı hatası

Yukarıdaki üç ana hatanın yanında, müşteri devralırken sık karşılaştığımız ve telafisi zaman alan birkaç tipik hata daha var:

• DNS'in hosting'e kilitlenmesi. Alan adının DNS yönetimi doğrudan eski hosting paneline gömülüyse, hosting değiştirmek istediğinizde nameserver kontrolünü kaybedersiniz ve geçiş günlerce sürebilir. DNS'i Cloudflare gibi bağımsız bir katmanda tutmak, hosting'i tek tıkla değiştirilebilir hale getirir.
• Kurumsal e-postanın aynı sunucuya bağlanması. Web hosting'i ile e-posta hizmetini aynı paylaşımlı sunucuya yığmak hem teslimat (deliverability) hem de güvenlik açısından risklidir; e-postayı ayrı, kurumsal bir hizmette tutmak daha sağlıklıdır. Detayları kurumsal e-posta nasıl alınır yazısında ele aldık.
• www / www'suz ve büyük-küçük harf çatallanması. Sitenin hem www hem www'suz sürümden açılması, "yinelenen içerik" (duplicate content) sinyali yaratabilir; bir tanesini kanonik seçip diğerini 301 ile ona yönlendirmek ve tutarlı tek bir adres kullanmak gerekir.

Bu üç nokta küçük görünür ama altyapının taşınabilirliğini ve aramadaki netliğini doğrudan etkiler. Özellikle DNS bağımsızlığı, ileride yapacağınız her hosting ya da platform değişikliğini günler yerine dakikalara indirir.

Yayın öncesi kısa kontrol listesi

Altyapı doğru kurulduğunda canlıya geçmeden önce şunları teyit edin:

• Alan adı doğru hosting'e yönleniyor mu, DNS propagasyonu tamamlandı mı?
• SSL aktif ve http→https yönlendirmesi çalışıyor mu, HSTS başlığı var mı?
• Mixed content (karışık içerik) uyarısı var mı, tüm dahili kaynaklar https mi?
• www / www'suz ve sürüm tutarlılığı sağlanıp tek kanonik adrese 301 verildi mi?
• Mobil görünüm doğru mu ve Core Web Vitals eşikleri (LCP ≤ 2,5 sn / INP ≤ 200 ms / CLS ≤ 0,1) sağlanıyor mu?
• KVKK aydınlatma metni ile çerez politikası ve açık rıza ayrı ayrı yerinde mi (tek "kabul ediyorum" kutusu hukuken sakıncalı)?
• Formlar test edildi mi, hata mesajları net ve çözüm önerili mi?
• 404 sayfası ve gerekli yönlendirmeler doğru mu, kırık link var mı?
• Otomatik, sürümlü ve site dışı yedekleme kurulu ve geri yükleme test edildi mi?
• Domain ve SSL otomatik yenilemesi açık, yenileme tarihleri hatırlatmaya bağlandı mı?

Bu liste basit görünür ama atlanan tek madde, yayından sonra telafisi pahalı bir soruna dönüşür. Özellikle DNS propagasyonu birkaç saat ile birkaç güne kadar sürebildiği için, yayın gününü bu belirsizliğe göre planlamak gerekir.

Sonuç ve sonraki adım

Web sitesi altyapısında başarı, gösterişli kararlardan değil, doğru sıradan ve sürekli takipten gelir: önce sahipliği sizde olan bir alan adı, ayrı yönetilen DNS, ihtiyaca uygun ve CDN destekli hosting, eksiksiz kurulmuş HTTPS ve hiç aksamayan bir yenileme/bakım disiplini. Ucuz hosting, yarım SSL ve unutulan yenileme — bu üç hatayı baştan kapattığınızda sitenizin yarısını çoktan kurtarmış olursunuz. Altyapı sağlam oturduktan sonra sırada tasarım ve dönüşüm gelir; mobil uyumlu responsive tasarım ve kurumsal web sitesi nasıl olmalı yazıları bu aşama için iyi bir devam noktası.

Domain, hosting, SSL ve performans kurulumunu baştan doğru yapılandırmak ya da mevcut altyapınızdaki riskleri denetlemek isterseniz, Alis Dijital olarak özel yazılım ve web sitesi hizmetimizle tüm zinciri uçtan uca kuruyoruz. Mevcut sitenizin altyapı, hız ve güvenlik durumunu ücretsiz değerlendirmemiz için analiz formumuzu doldurabilirsiniz; size kapsama göre değişen, net bir yol haritası ve yaklaşık bütçe çıkaralım — kesin teklif için birlikte oturup ihtiyacınızı netleştiririz.