İçindekiler
- 1 www mi Çıplak Alan Adı mı? Asıl Sorun Sandığınızdan Farklı
- 2 www ve Çıplak Alan Adı Arasındaki Gerçek Fark Nedir?
- 3 Canonical Domain Nedir ve Neden Kritik?
- 4 SEO Açısından www vs Çıplak Alan Adı
- 5 Doğru 301 Yönlendirme Stratejisi: Tüm Yollar Tek Adrese
- 6 HTTPS, HSTS ve Canonical Domain İlişkisi
- 7 Farklı Senaryolar İçin www / Non-www Karar Rehberi
- 8 cPanel, Paylaşımlı Hosting ve VPS/Dedicated Ortamlarında Uygulama
- 9 Sık Yapılan Hatalar ve Kısa Kontrol Listesi
- 10 Özet ve DCHost Tarafında Nasıl Yardımcı Oluyoruz?
www mi Çıplak Alan Adı mı? Asıl Sorun Sandığınızdan Farklı
Yeni bir alan adı açarken ya da yıllardır yayında olan bir projeyi taşırken karşınıza mutlaka şu soru çıkar: www mi kullanalım, yoksa çıplak alan adı (non-www) mı? Dışarıdan bakınca bu sadece estetik bir tercih gibi görünür; oysa işin içinde canonical domain, 301 yönlendirme, HTTPS ve HSTS, tarayıcı önbelleği, hatta uzun vadeli SEO stratejisi var. DCHost tarafında hem küçük kurumsal sitelerde hem yüksek trafikli projelerde en çok müdahale ettiğimiz yanlışlardan biri, yanlış kurgulanmış domain yönlendirmeleri ve eksik HSTS ayarları.
Bu yazıda; www / non-www seçiminin teknik farklarını, canonical domain kavramını, doğru 301 kurulumunu, HSTS’in ne zaman açılması gerektiğini ve tüm bunların SEO’ya etkisini adım adım, pratik örneklerle toparlayacağız. Amacımız, alan adınız için tek, temiz ve kalıcı bir adres stratejisi belirlemenize yardımcı olmak. Yazının sonunda, hem paylaşımlı hosting hem de VPS/dedicated ortamlarında doğrudan uygulayabileceğiniz bir kontrol listesi ve karar rehberi bulacaksınız.
www ve Çıplak Alan Adı Arasındaki Gerçek Fark Nedir?
Önce terimleri netleştirelim:
- Çıplak alan adı (root / apex domain): ornek.com
- www alt alan adı: www.ornek.com (teknik olarak bir subdomain)
Kullanıcı açısından ikisi de aynı site gibi görünür; ama DNS ve tarayıcı dünyasında durum farklıdır.
DNS tarafında farklar
Çıplak alan adında (ornek.com) geleneksel DNS sunucularında CNAME kullanamazsınız; genellikle A veya AAAA kaydı ile doğrudan IP adresine işaret etmeniz gerekir. www alt alan adında ise CNAME, başka bir hostname’e (örneğin CDN ya da reverse proxy) yönlendirmek için rahatça kullanılabilir.
Modern DNS sağlayıcılarında ALIAS/ANAME gibi özel kayıt türleriyle apex domain’i de esnek bir hedefe işaret etmek mümkün olsa da, hâlâ birçok mimaride www kullanmak esneklik kazandırır. Özellikle CDN, WAF, çok bölgeli mimari gibi yapılarda www alt alanını canonical yapmak işleri basitleştirebilir.
Cookie domain kapsamı da önemli bir farktır:
- Cookie’yi .ornek.com için ayarlarsanız, hem ornek.com hem de tüm alt alanlarda (www.ornek.com, api.ornek.com vb.) geçerli olur.
- Cookie’yi sadece www.ornek.com için ayarlarsanız, ornek.com üzerinde geçerli olmaz.
Bu, özellikle statik içerik için ayrı CDN alt alanları kullanıyorsanız ve gereksiz cookie taşımak istemiyorsanız işinize yarar. www’yi site için, statik.ornek.com’u statikler için kullanıp cookie kapsamını doğru tasarlayabilirsiniz.
Canonical Domain Nedir ve Neden Kritik?
Canonical domain, sitenizin arama motorları ve tarayıcılar gözünde “resmi” ana adresidir. Temel hedef, şu varyasyonların hepsinin tek bir adreste birleştirilmesidir:
- http://ornek.com
- http://www.ornek.com
- https://ornek.com
- https://www.ornek.com
Doğru kurulumda kullanıcı hangi adresi yazarsa yazsın, saniyenin altında sürede tek, tutarlı bir URL’ye 301 ile yönlendirilmelidir. Çoğu projede bizim tavsiyemiz, HTTPS zorunlu ve tek bir host adı seçmektir:
- Tercih 1: https://ornek.com
- Tercih 2: https://www.ornek.com
SEO tarafında canonical kavramı sadece yönlendirmeyle bitmiyor. HTML içinde kullanılan <link rel="canonical"> etiketleri de bu resmi adresi teyit eder. Ancak öncelik her zaman 301 yönlendirmede olmalı, rel=”canonical” ise destekleyici bir sinyal olarak düşünülmelidir.
URL değişiklikleriyle ilgili daha derin bir teknik rehbere ihtiyacınız varsa, hazırladığımız SEO kaybı olmadan URL yapısını değiştirme ve 301 yönlendirme rehberini mutlaka gözden geçirin.
SEO Açısından www vs Çıplak Alan Adı
Arama motorları için kritik olan şey, tutarlılık ve tekliktir. www ya da non-www seçiminin tek başına SEO’da “daha iyi” ya da “daha kötü” olduğuna dair bir kural yok; asıl önemli olan:
- Tüm varyasyonların tek bir canonical host’a 301 ile yönlendirilmesi
- İç linklerin, sitemap.xml’in ve canonical etiketlerin bu host ile uyumlu olması
- Google Search Console ve benzeri araçlarda doğru propertylerin tanımlanması
Yanlış kurulumun tipik sonuçları
DCHost’ta sık gördüğümüz hatalar şunlar:
- www ve non-www varyasyonlarının bazen 301, bazen 302 ile birbirine atlaması
- http → https yönlendirmesinin sadece bir varyasyonda olması (örneğin http://ornek.com yönleniyor, ama http://www.ornek.com yönlenmiyor)
- Canonical etiketi https://www.ornek.com iken siteyi https://ornek.com’a taşımak ve güncellemeyi unutmak
- Alan adı değişimi sırasında eski domenin www ve non-www varyasyonlarını eksik yönlendirmek
Sonuçta Google tarafında “aynı içeriğin farklı host isimlerinde farklı URL’ler” olarak görünmesi, link otoritesinin parçalanması, hatta nadiren de olsa duplicate content problemlerine yol açabiliyor.
Alan adı değişimi gibi büyük operasyonlara hazırlanıyorsanız, alan adı değiştirirken SEO kaybetmemek için hazırladığımız rehber de işinizi ciddi anlamda kolaylaştıracaktır.
Doğru 301 Yönlendirme Stratejisi: Tüm Yollar Tek Adrese
Şimdi işin en kritik ve pratik kısmına gelelim: hangi adresi seçerseniz seçin, diğer tüm varyasyonlar oraya kalıcı (301) yönlendirme ile akmalı. Örnek bir karar:
- Canonical domaininiz: https://www.ornek.com
Bu durumda ideal yönlendirme matrisi:
- http://ornek.com → 301 → https://www.ornek.com
- http://www.ornek.com → 301 → https://www.ornek.com
- https://ornek.com → 301 → https://www.ornek.com
Yani HTTP → HTTPS, non-www → www aynı anda çözülmeli, tek seferde yönlendirilmelidir. Kullanıcı ya da bot, asla 2–3 adımlı yönlendirme zincirine maruz kalmamalı.
Apache (.htaccess) için örnek 301 kuralları
Aşağıdaki örnek, canonical domain olarak https://www.ornek.com seçildiği senaryoya göredir:
RewriteEngine On
# HTTP'yi HTTPS'e ve non-www'yi www'ye tek adımda yönlendir
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www.ornek.com$ [NC]
RewriteRule ^(.*)$ https://www.ornek.com/$1 [L,R=301]
Bu kuralla birlikte hem http://ornek.com hem de http://www.ornek.com ile https://ornek.com, doğrudan https://www.ornek.com adresine 301 ile taşınır.
Nginx için örnek 301 kuralları
Benzer mantığı Nginx üzerinde tipik olarak şöyle uygularız:
server {
listen 80;
server_name ornek.com www.ornek.com;
return 301 https://www.ornek.com$request_uri;
}
server {
listen 443 ssl http2;
server_name ornek.com;
ssl_certificate /etc/ssl/certs/ornek.com.pem;
ssl_certificate_key /etc/ssl/private/ornek.com.key;
return 301 https://www.ornek.com$request_uri;
}
server {
listen 443 ssl http2;
server_name www.ornek.com;
ssl_certificate /etc/ssl/certs/ornek.com.pem;
ssl_certificate_key /etc/ssl/private/ornek.com.key;
# Asıl site konfigürasyonu burada
root /var/www/ornek;
}
Burada da HTTP’den gelen tüm istekler ve HTTPS üzerindeki non-www istekler, tek adımda canonical host’a döndürülüyor.
Apache ve Nginx tarafında daha gelişmiş senaryolar (alt dizin değiştirme, dil klasörü yakalama vb.) için, detaylı kurallar anlattığımız 301 yönlendirme rehberimizi inceleyebilirsiniz.
HTTPS, HSTS ve Canonical Domain İlişkisi
Artık HTTP kullanmak pratikte kabul edilebilir değil; HTTPS zorunlu kabul ediliyor. Burada devreye HSTS (HTTP Strict Transport Security) giriyor. HSTS, tarayıcıya “Bu domaine sadece HTTPS üzerinden bağlan, asla HTTP deneme” mesajı veren bir HTTP başlığıdır.
HSTS nasıl çalışır?
Tipik bir HSTS başlığı şu şekildedir:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- max-age=31536000 → 1 yıl boyunca bu kuralı hatırla
- includeSubDomains → Tüm alt alanlarda da sadece HTTPS kullanılacağını varsay
- preload → Tarayıcıların HSTS preload listesine dahil olmak için sinyal
Buradaki kritik nokta: HSTS’in etkisi domain bazındadır. especially includeSubDomains ve preload kullandığınızda, hem ornek.com hem de www.ornek.com (ve tüm alt alanlar) geri dönüşü zor bir şekilde HTTPS’e kilitlenir.
HSTS açmadan önce dikkat edilmesi gerekenler
DCHost tarafında HSTS’i üretimde açmadan önce mutlaka şu checklist’i uyguluyoruz:
- Hem ornek.com hem de www.ornek.com için geçerli, hatasız SSL sertifikası
- Tüm HTTP isteklerinin kalıcı 301 ile HTTPS’e yönlendirilmesi
- www / non-www canonical kararı netleşmiş ve her yerde (sitemap, canonical tag, iç linkler) uygulanmış
- En az birkaç hafta boyunca farklı tarayıcılarda ve cihazlarda test yapılmış
HSTS ve diğer HTTP güvenlik başlıklarını daha derinlemesine ele aldığımız HTTP güvenlik başlıkları rehberimiz de özellikle teknik ekibiniz için oldukça faydalı olacaktır. Ayrıca sırf HTTP→HTTPS geçiş süreci için adım adım hazırladığımız HTTP’den HTTPS’e geçiş rehberinde de HSTS ve 301 etkileşimini detaylı olarak anlattık.
Farklı Senaryolar İçin www / Non-www Karar Rehberi
Şimdi işin teorisini pratik senaryolara dökelim. Hangi durumda hangi seçimi öneriyoruz?
1. Yeni kurulan kurumsal site / blog
Yeni bir site kuruyorsanız ve özel bir teknik gereksiniminiz yoksa iki yol da geçerli:
- Marka sade görünüm seviyorsanız: canonical → https://ornek.com
- İleride CDN, WAF, çoklu alt alan gibi planlarınız varsa: canonical → https://www.ornek.com
Önemli olan, kararı en başta verip bir daha değiştirmemek. Hosting tarafında domain kurulumunu yaparken, DCHost panelinizde eklediğiniz alan adının www ve non-www varyasyonlarını aynı dizine işaret edecek şekilde ayarlayın ve az önceki 301 senaryosunu uygulayın.
2. CDN ve çoklu alt alan kullanılan projeler
Eğer:
- statik.ornek.com veya cdn.ornek.com gibi alt alanlardan statik dosya servis edecekseniz,
- api.ornek.com, panel.ornek.com gibi ayrı uygulamalarınız varsa,
- İleride çok bölgeli DNS ve CDN senaryolarına gitmeyi düşünüyorsanız,
Bu tip yapılarda www canonical kullanmak genellikle daha esnektir. Çünkü:
- www.ornek.com’u CDN veya reverse proxy arkasına almak kolaydır (CNAME ile)
- ornek.com’u sadece www’ye yönlendiren minimal bir layer olarak tutabilirsiniz
Global ölçekli projelerde GeoDNS ve çok bölgeli hosting mimarisi gibi çözümleri düşünüyorsanız, domain mimarinizi en baştan bu esnekliğe göre tasarlamak büyük avantaj sağlar.
3. Halihazırda index almış, yıllardır yayında olan site
Eğer siteniz 3–5 yıldır yayındaysa ve Google’da yüzlerce / binlerce sayfa index aldıysa, en iyi seçim genellikle şu anki durumu korumaktır. Yani:
- Bugün Google’da sayfalarınız ağırlıklı olarak https://www.ornek.com/… şeklindeyse, canonical olarak www’yi bırakın.
- Non-www ağırlıklıysa, canonical’ı non-www korumak daha az risklidir.
Bu durumda yapılacak iş, mevcut seçimi sertleştirip netleştirmektir:
- Tüm HTTP varyasyonlarını doğru 301 ile canonical’a taşımak
- Canonical etiketleri ve sitemap’i güncellemek
- HSTS ve güvenlik başlıklarını düzgünce eklemek
Yeni markaya geçiş gibi daha radikal operasyonlarda ise, hem eski hem yeni alan adlarını kapsayan bir strateji gerekir. Bunun için marka değişiminde alan adı taşıma rehberimizi izlemeniz, SEO ve e-posta tarafında riskleri ciddi biçimde azaltır.
cPanel, Paylaşımlı Hosting ve VPS/Dedicated Ortamlarında Uygulama
cPanel / Paylaşımlı Hosting’te pratik kurulum
DCHost paylaşımlı hosting paketlerinde tipik akış şu şekilde olur:
- Alan adını ana hesap domaini olarak ekleyin.
- SSL’yi (Let’s Encrypt veya ücretli sertifika) hem ornek.com hem de www.ornek.com için etkinleştirin.
- cPanel içindeki “Yönlendirmeler” bölümünden, non-www → www (veya tersi) 301 yönlendirmesini tanımlayın.
- Gerekirse .htaccess içine az önce verdiğimiz daha kapsamlı kuralları ekleyin.
Bu aşamada Google Search Console’a doğru host varyasyonunu eklemeyi, sitemap.xml içerisinde de canonical domaini kullanmayı unutmayın. Eğer web hosting kavramlarına yeniyseniz, domain, DNS, sunucu ve SSL’in birlikte nasıl çalıştığını anlattığımız rehber aklınızdaki birçok temel soruyu temizleyecektir.
VPS / dedicated sunucularda manuel konfigürasyon
VPS veya dedicated bir sunucuda çalışıyorsanız, web sunucunuzu (Nginx, Apache, LiteSpeed vb.) bizzat siz yapılandırıyorsunuz demektir. Bu durumda:
- Tüm server block / virtual host tanımlarını gözden geçirin
- HTTP (80) portundaki tüm domain varyasyonlarını tek bir HTTPS host’a 301 ile yönlendirin
- HTTPS host’lar içinde de non-www → www (veya tersini) net bir kuralla sabitleyin
- HSTS, HTTPS redirect ve canonical domainin çelişmediğinden emin olun
Yeni bir VPS aldıysanız ve henüz başlangıçtaysanız, yeni VPS’te ilk 24 saatte neler yapılmalı rehberimizde güvenlik ve temel ayarları; VPS sunucu güvenliği rehberimizde ise daha ileri seviye koruma adımlarını bulabilirsiniz.
Sık Yapılan Hatalar ve Kısa Kontrol Listesi
En sık gördüğümüz hatalar
- 301 yerine 302/307 kullanmak: Geçici yönlendirme kodları (302, 307) uzun vadede canonical sinyalini zayıflatabilir.
- Yönlendirme zinciri oluşturmak: http://ornek.com → http://www.ornek.com → https://www.ornek.com gibi iki adımlı yönlendirmeler TTFB’yi uzatır, SEO ve performansı olumsuz etkiler.
- HSTS’i erken açmak: SSL veya yönlendirme problemleri devam ederken HSTS + preload devreye almak, kullanıcıları geri döndürmesi zor hatalarla karşı karşıya bırakabilir.
- Canonical/URL değişimini parça parça yapmak: Bir gün yönlendirme, bir gün sitemap, bir hafta sonra canonical tag değiştirmek yerine planlı ve tek seferde değişiklik yapmak gerekir.
- İkincil alan adlarını unutmuk: .com.tr, .net, eski marka domaini gibi alanların da www/non-www varyasyonlarının eksiksiz 301 ile yeni canonical’a taşınması gerekir.
Birden fazla alan adını aynı siteye yönlendirme konusunu daha derinlemesine ele aldığımız park alan adı, 301 ve canonical stratejileri rehberine de mutlaka göz atmanızı öneririz.
Hızlı kontrol listesi
Aşağıdaki listeyi, canlıya çıkmadan önce veya mevcut siteyi iyileştirirken checklist olarak kullanabilirsiniz:
- Canonical domain kararı net mi? (https://ornek.com veya https://www.ornek.com)
- http://ornek.com → tek adımda canonical’a 301 ile gidiyor mu?
- http://www.ornek.com → tek adımda canonical’a 301 ile gidiyor mu?
- https://ornek.com → tek adımda canonical’a 301 ile gidiyor mu?
- HTML <head> içinde rel=”canonical” etiketi canonical domain ile uyumlu mu?
- sitemap.xml içinde tüm URL’ler canonical domain ile mi başlıyor?
- Google Search Console’da doğru host varyasyonu tanımlı mı?
- SSL sertifikası hem ornek.com hem www.ornek.com için geçerli mi?
- HSTS kullanıyorsanız, yönlendirme ve sertifikalar tam olarak sorunsuz mu?
HTTP durum kodlarının SEO etkisini ve 301/302 farklarını daha iyi anlamak istiyorsanız, HTTP durum kodları ve SEO rehberi de güzel bir tamamlayıcı kaynak olacaktır.
Özet ve DCHost Tarafında Nasıl Yardımcı Oluyoruz?
www mi yoksa çıplak alan adı mı sorusunun tek bir doğru cevabı yok; ama her senaryo için değişmeyen iki kural var: tutarlılık ve basitlik. Önce markanıza ve teknik mimarinize uygun bir canonical host seçin, ardından tüm HTTP/HTTPS, www/non-www varyasyonlarını bu adrese tek adımda 301 ile toplayın. Sonra SSL ve HSTS ile bu kararı güvence altına alın; sitemap, canonical etiketleri ve Search Console ayarlarıyla da arama motorlarına net bir sinyal verin.
DCHost olarak paylaşımlı hosting, VPS, dedicated sunucu ve colocation altyapımızda, günlük operasyonlarda en çok dokunduğumuz alanlardan biri tam da bu domain ve yönlendirme katmanı. İster yeni bir proje başlatıyor olun, ister yıllardır çalışan bir siteyi taşıyor olun; doğru canonical domain, 301 ve HSTS ayarlarıyla hem SEO tarafında hem de kullanıcı deneyiminde uzun vadeli bir rahatlık sağlamak mümkün. Mevcut sitenizi gözden geçirmek isterseniz, yukarıdaki checklist’i uygulayın; takıldığınız bir noktada ise DCHost destek ekibine konfigürasyon detaylarıyla birlikte ulaşmanız yeterli.
Doğru ayarlanmış bir alan adı ve yönlendirme katmanı; güçlü bir altyapı, sağlıklı DNS ve güvenli HTTPS üçlüsünün olmazsa olmaz tamamlayıcısıdır. Bu katmanı bir kere temiz kurduğunuzda, yıllarca tekrar düşünmek zorunda kalmazsınız.
