Aynı site hem siteadi.com hem de www.siteadi.com üzerinden açılıyorsa, mesele yalnız adresin uzunluğu değildir. Asıl sorun, kullanıcıların ve arama motorlarının aynı içeriği iki farklı ana bilgisayarda görmesidir. Bu da canonical sinyallerini bulanıklaştırır, link birikimini böler ve ekip içinde hangi sürümün “gerçek adres” olduğu konusunda kararsızlık yaratır. Seçim estetik görünebilir; etkisi teknik olur.
Bu yüzden “WWW mi non-WWW mü?” sorusunun doğru cevabı tek bir kalıp değildir. Bazı altyapılar kök domain üzerinde daha rahat çalışır, bazı CDN ve DNS senaryoları www tarafında daha esnek yönetilir. Fakat hangi versiyonu seçerseniz seçin, diğerini boşta bırakmak yerine tek adrese kalıcı olarak toplamanız gerekir. Apache tarafında bunu en pratik biçimde kurmak için yönlendirme kurallarını doğru üreten htaccess akışından yararlanmak işleri sadeleştirir.
Kararı sağlıklı vermek için iki şeyi ayırmak gerekir: hangi hostname'i tercih edeceksiniz ve bu tercihi bütün sistem katmanlarında nasıl tutarlı hale getireceksiniz? Çünkü sorun çoğu projede seçimden değil, yarım geçişten çıkar. İç linkler eski sürümde kalır, canonical yeni sürümü işaret eder, CDN başka host üzerinden çalışır ve ekip bir süre sonra hangi adresin resmi olduğunu yeniden tartışmaya başlar.
WWW ile non-WWW arasındaki gerçek teknik fark nedir?
www teknik olarak bir alt alan adıdır. example.com kök domain iken, www.example.com bunun ayrı bir host varyasyonudur. Bu ayrım küçük görünür; fakat DNS yönetimi, cookie kapsamı, CDN yapılandırması ve bazı proxy alışkanlıkları açısından sonuç üretir. Yani WWW yalnız süs değildir, host seviyesinde ayrı kimliktir.
Non-WWW tarafı daha kısa ve sade görünür. Marka kullanımında, basılı materyalde ve doğrudan paylaşımda bu tercih çoğu ekip için daha modern hissedilir. Buna karşılık www kullanan yapı, bazı servislerde CNAME mantığıyla daha rahat yönlendirilebilir ve kök domain üzerinde yaşanan DNS kısıtlarını kısmen hafifletebilir. Bu nedenle karar, “hangisi daha profesyonel” sorusundan çok “bizim altyapı ve marka kullanımımız için hangisi daha sürdürülebilir” sorusuyla verilmelidir.
Bir başka pratik fark da ekip alışkanlığıdır. Eski kurumsal yapılarda www daha yerleşik olabilir; yeni ürünlerde ise çıplak domain daha sık tercih edilir. Arama motoru açısından iki sürüm de çalışır. Sorun, bunların aynı anda açık bırakılmasıdır.
Cookie kapsamı ve alt alan politikası da kararın parçası olabilir. Bazı yapılarda oturum bilgisinin yalnız web katmanında kalması istenir; bazı yapılarda ise farklı alt alanlarla paylaşım gerekir. Bu karar doğrudan SEO konusu gibi görünmese de host tercihinin bakım maliyetini belirler. Yani “hangisi daha kısa” sorusu çoğu zaman yüzeydedir; alttaki operasyon kararı daha önemlidir.
Hangi yapı ne zaman daha mantıklı olur?
Eğer sıfırdan kurulan, sade alan adı kullanmak isteyen ve kök domain üzerinde özel kısıtı olmayan bir proje yürütüyorsanız non-WWW çoğu zaman yeterlidir. Kullanıcı için kısa görünür, paylaşımda rahat taşınır ve gereksiz ek katman hissi vermez. Özellikle küçük ve orta ölçekli içerik sitelerinde bu yaklaşım pratik olur.
Buna karşılık çoklu servis, CDN yönlendirmesi, farklı alt alan yönetimi ya da kurumsal DNS politikaları olan yapılarda www daha kontrollü tercih olabilir. Host ayrımı belirginleşir, kök domain ile web katmanı daha net ayrılabilir. Böyle bir senaryoda DNS kayıtlarının nasıl davrandığını ayrı görmek isterseniz, alan adının A, CNAME ve diğer kayıt yapısını birlikte incelemek kararınızı daha güvenli hale getirir.
Burada önemli olan hangisinin “daha SEO uyumlu” olduğu değildir. Tek başına böyle bir üstünlük yoktur. İyi çalışan tercih, markanın kullandığı adresle teknik yapının aynı yönde ilerlediği tercihtir. Kullanıcı www ile gördüğü markayı tarayıcıda farklı sürümde buluyorsa ya da ekip içindeki dökümanlar iki host arasında bölünüyorsa problem buradan başlar.
Mevcut bir markayı taşıyorsanız geçmiş link profilini de düşünmek gerekir. On yıldır www ile yerleşmiş bir alan adını sadece daha kısa göründüğü için değiştirmek teknik olarak yapılabilir; ama buna gerçekten ihtiyaç olup olmadığını tartmak gerekir. Bazen en iyi karar yeni bir tercih yapmak değil, mevcut doğru çalışan tercihi daha temiz hale getirmektir.
SEO tarafında sorun seçimden çok çoğaltma neden olur
Arama motoru için kritik olan, aynı içeriğin iki host altında erişilebilir olmamasıdır. Her iki sürüm açık kaldığında dış linkler bölünebilir, tarama bütçesi gereksiz tekrara gider ve canonical sinyali tek başına yetersiz kalabilir. Canonical etiket tercih bildirir; ama hatalı yapılandırılmış çift erişimi tamamen çözmez. Sunucu tarafında kalıcı yönlendirme olmadığı sürece kullanıcı da bot da yanlış hosta düşebilir.
İç linklerin davranışı da burada önemlidir. Menüde, içerik içinde, sitemap'te ya da e-posta şablonlarında eski host kaldığında arama motoruna karışık sinyal gönderirsiniz. Host değişiminden sonra hangi bağlantıların hâlâ eski yapıyı işaret ettiğini görmek için site içindeki bağlantı ağını denetlemek çoğu zaman canonical etiket kontrolünden daha öğreticidir.
Bir başka hata da yönlendirmeyi sadece ana sayfada kurup alt sayfalarda gevşek bırakmaktır. Oysa doğru kurgu, her URL'nin bire bir karşılığına 301 ile gitmesidir. /kategori/yazi adresi yeni hostta yine aynı yolu açmalıdır. Aksi halde host tercihi çözülürken sayfa eşleşmesi bozulur.
Bu da log ve rapor okumayı etkiler. Aynı içerik iki hosttan hit alıyorsa analitik tarafında landing raporları parçalanabilir, kampanya etiketleri bir hostta birikirken diğerinde dağılabilir. Teknik olarak küçük görünen bu dağınıklık, ekiplerin yanlış sayfayı sorunlu sanmasına yol açar. Host standardı, yalnız indeksleme için değil ölçüm kalitesi için de gereklidir.
Yönlendirme, canonical ve iç linkler nasıl birlikte kurulmalı?
En sağlıklı senaryoda üç katman aynı tercihi tekrarlar: sunucu yönlendirmesi, canonical etiket ve site içi linkler. Sunucu, yanlış hosta gelen isteği doğru hosta 301 ile taşır. Canonical, sayfanın tercih edilen sürümünü HTML içinde tekrarlar. Site içi linkler de yeni hostu kullanarak sistemin kendi kendine çelişmesini engeller.
Örneğin non-WWW tercih ediyorsanız Apache tarafında kurgu şöyle olabilir:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]Ters senaryoda yani www sürümünü koruyacaksanız kuralı buna göre çevirirsiniz. Host tercihi HTTPS yönlendirmesiyle birlikte düşünülmelidir; aksi halde bir kullanıcıyı önce HTTP'den HTTPS'ye, sonra host değişimine, sonra trailing slash düzenine sokarak gereksiz zincir oluşturabilirsiniz. Bu katmanların doğru sıralanması için HTTPS yönlendirme mantığını host kararıyla birlikte ele almak daha temiz sonuç verir.
Canonical etiketi ise yönlendirmeyi ikame etmez; onu destekler. Eğer canonical non-WWW gösteriyor ama kullanıcı WWW sürümünü sorunsuz açabiliyorsa yapı hâlâ gevşektir. Aynı şekilde iç linkler eski hostu taşımaya devam ediyorsa canonical yalnız başına netlik üretemez.
Burada yönlendirme zincirini kısa tutmak da önemlidir. HTTP'den HTTPS'ye, oradan non-WWW'ye, sonra slash düzeltmesine giden çok adımlı yapı teknik olarak çalışsa bile gereksiz gecikme üretir. İdeal kurgu, kullanıcıyı mümkün olduğunca tek sıçramada doğru kanonik adrese indirir. Host tercihi iyi seçilmiş ama geçiş zinciri dağınıksa kalite hâlâ yarımdır.
Geçiş sırasında en çok nerelerde kırılma olur?
En yaygın kırılma, geçişin yalnız sunucu kuralı sanılmasıdır. Oysa CDN ayarları, ters proxy davranışı, cache anahtarı, cookie kapsamı ve üçüncü parti servis callback'leri de host tercihiyle ilişkilidir. Özellikle form gönderimi, oturum yönetimi veya medya dağıtımı yapan sistemlerde eski hostun bir yerde yaşamaya devam edip etmediği kontrol edilmelidir.
İkinci kırılma Search Console ve raporlama tarafında görülür. Yeni hosta geçip eski mülkü tamamen unutmak doğru değildir; ama iki hostu da aynı anda aktif site gibi yönetmek de kafa karıştırır. Ölçümleme araçlarının hangi hostta trafik topladığını, sitemap gönderiminin hangi sürümden yapıldığını ve önemli landing sayfalarının hangi adresle dizine girdiğini geçiş sonrası yakından izlemek gerekir.
Üçüncü kırılma içerik tarafındadır. Sosyal profiller, e-posta imzaları, reklam URL'leri ve eski kampanya sayfaları yeni hosta taşınmadığında geçiş tamamlanmış görünür ama dış dünyada eski adres dolaşmaya devam eder. 301 bu trafiği toplar; yine de kendi kontrolünüzdeki adresleri güncellemek temiz yapı kurmanın parçasıdır.
CDN ve güvenlik servisleri de ayrıca kontrol edilmelidir. Bazı yapılarda origin host ile public host farklı tanımlanır ve yönlendirme kuralı CDN seviyesinde ayrı, uygulama seviyesinde ayrı davranır. Bu da bazen sonsuz döngüye, bazen de beklenmedik cache kayıtlarına yol açar. Host geçişi yalnız Apache kuralı değildir; ağ yolunun tamamı aynı kararı konuşmalıdır.
Geçiş sonrasında bir süre eski hosta gelen istekleri log üzerinden izlemek de yararlıdır. Hangi alt sayfalar hâlâ eski yapıyla çağrılıyor, hangi kampanyalar ya da dış servisler yanlış hostname gönderiyor sorusu ancak böyle görünür hale gelir. Bu görünürlük olmadan yapılan geçişler kağıt üzerinde tamamlanır; ama gerçek trafikte aylarca yamalı biçimde yaşamaya devam eder.
Kararı nasıl kalıcı ve temiz hale getirirsiniz?
Kalıcı çözüm, seçtiğiniz hostu şirket içi standart haline getirmektir. Tasarım dosyalarındaki örnek URL'ler, içerik rehberi, otomasyon şablonları, teknik dokümantasyon ve editör eğitimleri aynı adres mantığını taşımalıdır. Aksi halde birkaç ay sonra yeni içerik eski hostla açılır ve siz yönlendirme varken sorun yok sanırsınız. Oysa ideal yapı, yanlış host üretmeyen yapıdır.
Host tercihi doğru yapıldığında kullanıcı deneyimi mucizevi biçimde değişmez; ama teknik gürültü azalır. Link birikimi tek adreste toplanır, log okumak kolaylaşır, sitemap ve canonical daha net konuşur. Bu yüzden kararın kendisinden çok, o kararı ne kadar disiplinli uyguladığınız önemlidir. WWW ya da non-WWW arasında tek doğru yoktur; dağınık geçiş ile temiz geçiş arasında net bir doğru vardır.
Bu yüzden host kararını bir kez verip belgelemek gerekir. Yeni açılış sayfası, yeni içerik türü ya da yeni kampanya üretildiğinde herkes aynı adres mantığını kullanıyorsa seçim gerçekten tamamlanmış olur. En temiz yapı, arama motorunun da ekibinizin de ikinci kez düşünmek zorunda kalmadığı yapıdır.
Karar net, yönlendirme kısa ve iç linkler tutarlı olduğunda WWW tartışması günlük iş listesinde yer kaplamaz. Asıl istenen de budur: adres tercihini sürekli konuşmak değil, bir kez doğru kurup geri kalan işi içerik ve performans kalitesine bırakmak.
Temiz host standardı, küçük görünen ama sürekli yinelenen teknik borcu da ortadan kaldırır. Her yeni içerikte aynı kararı tekrar vermek zorunda kalmadığınızda ekip daha hızlı ve daha az hatayla çalışır. Bu fark zamanla büyür ve özellikle büyük içerik arşivlerinde ciddi operasyon rahatlığı sağlar.