Kurumsal Domainlerde WWW ve Non-WWW Yönlendirme Analizi

Bir kurumsal web sitesinde aynı sayfanın hem www hem de non-www adresinden açılması ilk bakışta küçük bir teknik ayrıntı gibi görünebilir. Fakat işin içine HTTPS, canonical, sitemap, CDN, cookie, Search Console, OAuth callback adresleri ve yıllar içinde birikmiş backlinkler girdiğinde bu küçük tercih bütün domain mimarisini etkileyebilir. On yıllık web altyapısı ve teknik SEO deneyimimde, sıralama problemi gibi görünen bazı durumların aslında iki hostname'in farklı sinyaller üretmesinden, gereksiz redirect chain'lerinden veya eski hostun hâlâ dahili bağlantılarda kullanılmasından kaynaklandığını birçok kez gördüm. Kurumsal Domainlerde WWW ve Non-WWW Yönlendirme Analizi bu nedenle yalnızca “www mi daha iyi?” sorusunun cevabı değildir; doğru canonical hostun seçilmesi, diğer varyasyonların tek adımda bu hosta taşınması ve bütün teknik sinyallerin aynı URL standardını göstermesi gerekir. Bu rehberde kurumsal sitelerde www ve non-www yönlendirmesi nasıl yapılır, www mi non-www mi SEO için daha iyi, www non-www 301 yönlendirme ve canonical URL nasıl yapılandırılır ve www ile non-www kaynaklı duplicate content indeksleme ve HTTPS sorunları nasıl önlenir sorularını üretim ortamı perspektifiyle ele alacağız.

WWW ve Non-WWW Nedir?

WWW ve non-www aynı registrable domain altında kullanılan iki farklı hostname biçimidir. Örneğin www.example.com ile example.com çoğu kullanıcı için aynı web sitesini temsil etse de HTTP ve DNS katmanında farklı hostlar olarak ele alınabilir. Sunucu iki hosta ayrı davranış tanımlayabilir, farklı sertifikalar veya CDN kuralları uygulanabilir ve arama motorları her iki URL varyasyonunu ayrı adresler olarak görebilir. Bu nedenle kurumsal domain tasarımında hangi hostname'in ana adres olacağı açık biçimde belirlenmelidir. Diğer hostname ise kullanıcıyı aynı path ve query değerini koruyarak kalıcı yönlendirmeyle tercih edilen hosta taşımalıdır.

WWW Domain Nedir?

WWW kullanılan yapıda web sitesi www.example.com gibi bir hostname üzerinden yayınlanır. Buradaki www teknik olarak domain adının önüne eklenen bir subdomain label'ıdır ve DNS üzerinde ayrı kayıtlarla yönetilebilir. Bu yapı özellikle CDN, trafik yönetimi veya çok sayıda subdomain barındıran kurumsal sistemlerde mimari esneklik sağlayabilir. Kullanıcı açısından www yazılması çoğu zaman işlevsel fark yaratmaz, çünkü tarayıcı nihayetinde tanımlanan hosta bağlanır. SEO açısından önemli olan www kullanmak değil, seçilen hostname'in redirect, canonical, sitemap ve internal link sinyallerinin tamamında tutarlı biçimde kullanılmasıdır.

Non-WWW / Apex Domain Nedir?

Non-www olarak adlandırılan yapı example.com gibi zone apex üzerinde çalışan web adresidir. Kullanıcı açısından daha kısa görünür ve marka iletişiminde sade bir URL sağlayabilir. DNS açısından apex kayıtlarının yönetimi geçmişte bazı CNAME kısıtları nedeniyle www subdomain'e göre daha az esnek olabiliyordu. Günümüzde birçok DNS ve CDN altyapısı flattening, alias veya benzer mekanizmalarla apex kullanımını kolaylaştırmaktadır. Bu nedenle yalnız geçmişteki DNS sınırlamalarına dayanarak bütün şirketlerin www kullanması gerektiğini söylemek doğru değildir.

WWW Teknik Olarak Bir Subdomain midir?

Evet, www teknik olarak ana domain altında bulunan bir hostname veya subdomain label'ıdır. www.example.com ile app.example.com DNS hiyerarşisinde benzer biçimde ana domainin altında yer alır. Bununla birlikte web kullanıcıları www adresini genellikle ana sitenin kendisi olarak algılar. Teknik ekip bu farkı cookie scope, DNS, TLS ve CDN rule tasarımında dikkate almalıdır. Özellikle includeSubDomains içeren HSTS veya Domain attribute kullanan cookie politikaları bütün subdomain yapısını etkileyebilir.

Hostname ile Domain Arasındaki Fark

Domain bir DNS isim alanını ifade ederken hostname belirli bir servisin erişildiği tam ad olabilir. example.com ana domain iken www.example.com, api.example.com ve auth.example.com farklı hostname'lerdir. Uygulama güvenliği ve routing açısından bu ayrım önemlidir, çünkü her hostname farklı origin kabul edilir. Browser cookie ve CORS davranışları da hostname yapısından etkilenebilir. Teknik SEO incelemesinde yalnız domain registrasyonuna bakmak değil, kullanıcıların ve crawler'ların erişebildiği bütün hostname varyasyonlarını analiz etmek gerekir.

Kullanıcı Açısından WWW ve Non-WWW Farkı

Çoğu ziyaretçi için www.example.com ile example.com arasında anlamlı bir kullanım farkı yoktur. Tarayıcı doğru redirect yapılandırılmışsa kullanıcı hangi varyasyonu yazarsa yazsın aynı canonical adrese ulaşır. Problem, iki varyasyonun farklı sayfalar göstermesi veya ikisinin de 200 döndürerek paralel şekilde açık kalmasıyla başlar. Bu durumda bookmark, paylaşım ve analytics kayıtları farklı URL biçimlerine dağılabilir. İyi domain tasarımı kullanıcıya bu teknik farkı hissettirmeden bütün yolları tek preferred host üzerinde birleştirir.

WWW ve Non-WWW SEO Açısından Farklı mıdır?

Arama motoru optimizasyonu açısından www veya non-www hostun kendisinin doğal bir sıralama üstünlüğü yoktur. Google canonicalization sırasında redirect, sitemap ve rel canonical gibi çeşitli sinyalleri birlikte değerlendirir ve kurumun tercih ettiği URL her durumda otomatik olarak seçilmek zorunda değildir. Bu nedenle asıl SEO konusu isim biçimi değil bütün teknik sinyallerin aynı hostu göstermesidir. Eğer iki hostname de 200 dönüyor, sitemap biriyle hazırlanıyor ve canonical diğerini gösteriyorsa sistem arama motoruna çelişkili bilgi verir. Kurumsal teknik SEO çalışmasında hedef, bir HTTPS hostname'i canonical standarda dönüştürmek ve bütün alternatifleri kalıcı redirect ile ona bağlamaktır.

Google WWW veya Non-WWW Tercih Eder mi?

Google'ın genel yaklaşımı belirli bir www veya non-www biçimini zorunlu tutmak değildir. Canonical seçiminde teknik sinyaller, HTTPS kullanımı, redirectler, sitemap ve canonical etiketleri gibi faktörler birlikte değerlendirilir. Bu nedenle “www kullanırsanız otomatik SEO avantajı elde edersiniz” veya tam tersini söylemek doğru olmaz. Kurumsal ekip kendi altyapı gereksinimlerine uygun preferred hostu seçebilir. Seçimden sonra diğer hostname kalıcı redirect, canonical ve internal link standardıyla aynı karara bağlanmalıdır.

SEO İçin Asıl Önemli Olan Nedir?

SEO açısından en önemli konu URL sinyallerinin tutarlı ve crawler açısından anlaşılır olmasıdır. Bir sayfanın canonical sürümü 200 dönmeli, alternatif hostname mümkünse doğrudan bu URL'ye kalıcı yönlendirme yapmalıdır. Sitemap yalnız canonical URL'leri içermeli ve dahili bağlantılar redirect üzerinden geçmemelidir. Hreflang, structured data ve sosyal paylaşım URL'leri de mümkün olduğunca aynı preferred host standardını kullanmalıdır. Bu yaklaşım hem crawl davranışını sadeleştirir hem analytics ve backlink konsolidasyonunu kolaylaştırır.

Preferred Host Kavramı

Preferred host şirketin ana web adresi olarak kabul ettiği hostname'dir. Bu www.example.com veya example.com olabilir ve karar teknik gereksinimlere göre verilebilir. Tercih edilen host yalnız kullanıcı arayüzünde kullanılmaz, aynı zamanda canonical, sitemap, hreflang ve internal link standardını da belirler. Secondary hostun görevi içerik sunmak değil canonical hosta yönlendirme sağlamaktır. Policy dokümanında preferred host açık biçimde yazılırsa farklı ekiplerin yıllar içinde çelişkili URL üretme ihtimali azalır.

Canonicalization

Canonicalization aynı veya çok benzer içerik için temsilci URL'nin belirlenmesi sürecidir. Google duplicate URL grupları içinde bir canonical seçer ve site sahipleri redirect, canonical annotation ve sitemap gibi sinyallerle tercihlerini bildirebilir. WWW ve non-www aynı içeriği sunuyorsa bu iki hostname canonicalization probleminin tipik örneklerinden biridir. En güçlü çözüm alternatif hostu 301 veya uygun kalıcı redirect ile preferred hosta taşımaktır. HTML canonical etiketi de final URL'nin kendisini göstermeli ve farklı sinyaller arasında çelişki bırakılmamalıdır.

Tutarlı URL Sinyalleri

Tutarlı URL sinyalleri redirect target, canonical, sitemap, internal link, hreflang ve structured data gibi bütün alanların aynı hostname'i göstermesidir. Bunun değeri yalnız arama motorları açısından değildir, çünkü analytics, cache, güvenlik ve kullanıcı paylaşımı da daha öngörülebilir hale gelir. Bir sistemde footer linkleri non-www, sitemap www ve canonical non-www ise teknik borç giderek büyür. Migration yapılırken bütün bu sinyaller aynı release planı içinde güncellenmelidir. CI/CD testleri yeni kodun eski hostname üretmesini otomatik olarak engelleyebilir.

Kurumsal Domainlerde Neden Tek Bir Preferred Host Seçilmelidir?

Tek preferred host seçmek URL mimarisinin merkezi standardını oluşturur. Böylece kullanıcı, crawler, analytics sistemi ve üçüncü taraf entegrasyonların aynı adres biçimi üzerinde çalışması kolaylaşır. İki hostname'i paralel 200 açık bırakmak duplicate URL kümeleri, backlink dağılması ve beklenmeyen cache davranışları oluşturabilir. Kurumsal ölçekte yüz binlerce sayfa varsa küçük bir host tutarsızlığı milyonlarca alternatif URL üretme potansiyeline sahiptir. Preferred host policy bu nedenle yalnız SEO ekiplerinin değil DevOps, security, backend ve marketing ekiplerinin ortak standardı olmalıdır.

URL Tutarlılığı

URL tutarlılığı kullanıcıya ve sistemlere tek bir referans adresi verir. Dokümanlarda, e-postalarda ve reklam kampanyalarında aynı hostname kullanıldığında paylaşım ve ölçüm daha kolay olur. Internal linkler doğrudan final URL'ye gittiği için gereksiz redirect request'i oluşmaz. Cache ve CDN key davranışı da daha öngörülebilir hale gelir. Büyük site migrationlarında envanter çıkarırken tek URL standardının bulunması operasyon maliyetini önemli ölçüde azaltır.

Search Engine Canonicalization

Arama motorları duplicate URL'ler gördüğünde kendi canonical değerlendirmelerini yapar. Site tarafında güçlü ve tutarlı sinyaller vermek bu süreci daha anlaşılır hale getirir. Redirect bir URL'nin kalıcı olarak yeni adrese taşındığını belirtirken canonical etiketi tercih edilen temsilci adresi bildirir. Google bu işaretleri farklı ağırlıklarda değerlendirebilir ve user declared canonical ile Google selected canonical farklı olabilir. Tek host standardı bu farklılaşma ihtimalini azaltan temel yapılandırmalardan biridir.

Analytics Tutarlılığı

Analytics sistemleri hostname'i raporlama boyutu olarak kullanabilir. WWW ve non-www paralel açık olduğunda aynı sayfa iki ayrı URL olarak raporlara düşebilir. Referral ve session attribution ayarları da hostname değişiminden etkilenebilir. Marketing ekipleri campaign destination URL'lerinde farklı hostlar kullandığında veri temizliği zorlaşır. Preferred host ve redirect standardı analytics verisini daha sade ve karşılaştırılabilir hale getirir.

Backlink Konsolidasyonu

Dış siteler yıllar içinde hem www hem non-www URL'lerine link verebilir. Kalıcı redirectler bu eski bağlantıları preferred hosta taşımak için önemlidir. Google site migration rehberinde eski URL'lerden yeni karşılıklarına doğru redirect mapping hazırlanmasını ve irrelevant toplu homepage yönlendirmelerinden kaçınılmasını önerir. Linkleri tek hostname üzerinde standardize etmek yeni backlinklerin de aynı URL biçimine yönelmesini teşvik eder. Üçüncü taraf profil ve kurumsal dizinler zamanla preferred hosta güncellenebilir.

Teknik Operasyon Kolaylığı

Tek hostname standardı redirect, certificate, WAF, CSP ve monitoring kural yönetimini sadeleştirir. Secondary host yalnız redirect service görevi gördüğünde application routing daha anlaşılır hale gelir. DevOps ekipleri tek canonical host için SLO tanımlayabilir. Log analizinde eski hostname hitleri migration borcunu gösteren metric olarak kullanılabilir. Domain policy açık olduğunda yeni servis ve sayfaların yanlış hostla yayına çıkması daha kolay önlenir.

Güvenlik Politikaları

Hostname tercihi cookie, HSTS, CSP, CORS ve OAuth configuration üzerinde etkili olabilir. Authentication cookie'nin hangi host veya subdomainlere gönderileceği açık biçimde belirlenmelidir. HSTS includeSubDomains kullanılıyorsa bütün ilgili subdomainlerin HTTPS hazır olması gerekir. OAuth provider callback ve allowed origin listeleri migration öncesinde güncellenmelidir. SEO amacıyla yapılan bir hostname değişikliği bu güvenlik bağımlılıkları dikkate alınmadan uygulanmamalıdır.

WWW mi Non-WWW mi Seçilmeli?

WWW ile non-www arasında evrensel bir kazanan yoktur. Seçim mevcut DNS, CDN, subdomain, cookie, marka kullanımı ve domain geçmişine göre yapılmalıdır. Yeni bir küçük site için kısa non-www URL daha sade olabilirken çok büyük ve dağıtık altyapıda www ayrı hostname olarak operasyon avantajı sağlayabilir. Mevcut sitenin yıllardır kullandığı host sorunsuz çalışıyorsa sırf görünüm nedeniyle migration yapmak çoğu zaman gereksiz risk oluşturur. Teknik kararın SEO kazancı varsayımına değil somut mimari ihtiyaca dayanması gerekir.

SEO Perspektifi

SEO perspektifinden her iki seçenek de doğru uygulanabilir. Asıl hedef alternatif hostun canonical URL'lerle rekabet etmemesi ve bütün sinyallerin aynı adrese gitmesidir. Google'ın canonical rehberi HTTPS, redirects, sitemap ve canonical annotations gibi işaretlerin birlikte değerlendirildiğini açıklar. Yeni sitelerde baştan bir standart seçmek kolaydır. Mevcut güçlü domaini sırf www biçimini değiştirmek için taşımak ise gereksiz migration dalgalanması oluşturabilir.

DNS Perspektifi

WWW ayrı subdomain olduğu için klasik DNS modelinde CNAME ile başka hostname'e bağlanması kolaydır. Apex domain üzerinde klasik CNAME kullanımı DNS zone davranışı nedeniyle tarihsel sınırlamalara sahiptir. Modern provider çözümleri alias veya flattening benzeri mekanizmalarla bu problemi büyük ölçüde azaltmıştır. Bu nedenle DNS kararında kullanılacak sağlayıcının gerçek özellikleri incelenmelidir. Domain architecture yalnız teorik DNS kuralına dayanarak değil failover, TTL ve provider migration ihtiyacıyla birlikte değerlendirilmelidir.

CDN Perspektifi

CDN entegrasyonlarında www subdomain klasik CNAME modeliyle kolay yapılandırılabilir. Fakat modern CDN ve DNS servisleri apex kullanımını da destekleyebildiği için www artık her durumda zorunlu değildir. CDN edge redirect işlemini origin'e gitmeden gerçekleştirebiliyorsa secondary host için düşük latency sağlanabilir. Buna karşılık provider değişiminde özel redirect syntax ve DNS özellikleri migration maliyeti oluşturabilir. CDN tercihi host kararını etkileyebilir, fakat tek başına belirlememelidir.

Cookie Perspektifi

Cookie güvenliği açısından mümkün olduğunca dar scope tercih edilmelidir. Host only cookie yalnız set edildiği hosta gönderilir ve gereksiz subdomain yayılımını önler. Domain attribute ile üst domain seviyesine yayılan cookie bütün subdomainlere gönderilebilir ve attack surface büyüyebilir. WWW veya non-www seçimi bu policy'nin nasıl uygulanacağını etkileyebilir. Authentication tasarımı domain migration öncesi test edilmeden host değişikliği production'a alınmamalıdır.

Subdomain Mimarisı

Kurumsal platformda app, api, auth, admin ve support gibi çok sayıda subdomain bulunabilir. Ana web sitesini www üzerinde tutmak bazı ekipler için site ile uygulama servislerini isimsel olarak daha açık ayırır. Non-www ana site de aynı şekilde güvenli ve yönetilebilir olabilir. Asıl konu DNS, cookie ve HSTS policy'nin bütün subdomain hiyerarşisini kapsamasıdır. Host kararı bütün subdomain inventory görüldükten sonra verilmelidir.

Marka ve URL Kullanılabilirliği

Non-www URL daha kısa olduğu için baskılı materyaller ve sözlü iletişimde sade görünebilir. Bazı markalar ise yıllardır www biçimini kullanır ve kullanıcı alışkanlığı oluşmuştur. Teknik migration yalnız estetik gerekçeyle yapılacaksa fayda genellikle sınırlıdır. Kullanıcı hangi biçimi yazarsa yazsın doğru redirect sayesinde final siteye ulaşabilmelidir. Marka standardı teknik policy ile uyumlu hale getirilerek bütün iletişim materyallerinde tek URL biçimi kullanılmalıdır.

Mevcut Domain Geçmişi

Yıllardır indexlenen ve backlink alan hostname güçlü bir operasyon geçmişine sahiptir. Sırf kısa görünüm için host migration yapmak redirect, Search Console, sitemap ve üçüncü taraf update çalışması gerektirir. Google site move rehberi URL değişikliklerinin dikkatli mapping, redirect ve monitoring ile yürütülmesini önerir. Teknik bir zorunluluk yoksa mevcut preferred hostu korumak çoğu zaman düşük riskli seçenektir. Migration yapılacaksa backlink, crawl ve analytics baseline önceden kaydedilmelidir.

WWW / Non-WWW Karar Matrisi

Karar matrisi host seçimini kişisel tercihten çıkarıp ölçülebilir kriterlere bağlar. DNS provider yeteneği, CDN modeli, subdomain sayısı, cookie stratejisi, mevcut backlink geçmişi ve migration maliyeti puanlanabilir. Yeni site ile yıllardır çalışan kurumsal domain aynı değerlendirme modeline sahip olmamalıdır. Özellikle büyük platformlarda security ve third party callback bağımlılıkları SEO kriterlerinden daha ağır basabilir. Son karar yazılı bir preferred host policy olarak kaydedilmeli ve gelecekteki projeler bu standardı kullanmalıdır.

Yeni Kurulan Küçük Site

Yeni küçük sitede legacy URL veya backlink borcu olmadığı için tercih daha esnektir. Non-www kısa URL avantajı sağlayabilir, www ise klasik DNS pattern'iyle rahat yönetilebilir. Seçimden daha önemli olan ilk günden secondary hostun kalıcı redirect ile kapatılmasıdır. Canonical ve sitemap aynı hostu kullanmalıdır. Daha sonra sırf estetik için host değiştirmek yerine başlangıçta bilinçli standard belirlemek daha sağlıklıdır.

Büyük Kurumsal Platform

Büyük platformlarda host kararı CDN, WAF, SSO, application routing ve çoklu ekip operasyonunu etkiler. WWW ayrı web frontend hostname'i olarak net boundary sunabilir. Non-www de modern altyapıda aynı ölçekte çalışabilir, ancak provider özellikleri doğrulanmalıdır. Migration sırasında yüz binlerce URL ve third party entegrasyon etkilenebileceği için mevcut host büyük değer taşır. Karar architecture board veya benzer teknik governance sürecinde alınmalıdır.

Çok Sayıda Subdomain

Çok subdomain kullanılan yapılarda cookie, HSTS ve certificate yönetimi daha önemli hale gelir. Ana site www üzerinde tutulduğunda app ve api gibi servislerden isimsel olarak ayrılabilir. Bunun SEO açısından doğrudan avantajı yoktur. Non-www ana site seçilecekse apex ve subdomain policy yine aynı düzeyde yönetilebilir. En önemli kriter shared authentication veya cookie scope gereksiniminin güvenli biçimde uygulanabilmesidir.

Global CDN Kullanımı

Global CDN kullanan şirketin DNS ve edge routing özellikleri host tercihinde önemli rol oynar. Provider apex aliasing destekliyorsa non-www kullanımının teknik engeli azalır. Edge redirect secondary host requestini origin'e ulaştırmadan çözebilir. Multi region certificate ve failover procedure test edilmelidir. Vendor değiştirme ihtimali varsa proprietary DNS özelliğine aşırı bağımlılık risk olarak değerlendirilmelidir.

SaaS Ürünü

SaaS ürünlerinde marketing site, app, API ve customer custom domain yapısı birbirinden ayrılabilir. www marketing site için kullanılıp app ayrı hostta çalıştırılabilir. Non-www de aynı modeli destekler. Cookie ve OAuth configuration bu ayrımın merkezindedir. Preferred host migration müşteri dokümantasyonu ve callback integration'ları etkileyebileceği için değişiklik maliyeti yüksektir.

E-Ticaret Platformu

E-ticaret sitelerinde canonical, product feed, payment callback ve campaign URL'leri hostname değişiminden etkilenebilir. Yoğun external link ve reklam trafiği nedeniyle redirect performansı önemlidir. Tek hop permanent redirect tercih edilmelidir. Checkout ve session cookie'leri migration öncesi kapsamlı QA gerektirir. Estetik host değişikliği ciddi ticari risk taşıdığı için yalnız somut teknik gerekçeyle yapılmalıdır.

Çok Uluslu Şirket

Çok uluslu şirketlerde country domain, subdomain veya subdirectory stratejileri host seçimiyle birlikte değerlendirilmelidir. Hreflang URL'lerinin tamamı canonical hostname standardına uymalıdır. Region bazlı CDN veya legal data requirement farklılaşabilir. Global policy merkezden tanımlanırken local domain istisnaları kayıt altında tutulmalıdır. Migration yapılırsa her ülke Search Console ve analytics verisi ayrı izlenmelidir.

Mevcut Domaini Yıllardır Kullanan Marka

Uzun süredir çalışan domain için değişiklik maliyeti yeni siteye göre çok daha yüksektir. Backlinkler, reklam destination URL'leri, bookmarklar ve üçüncü taraf entegrasyonlar mevcut hostname'e bağlı olabilir. Eğer ciddi DNS, CDN veya security problemi yoksa hostu değiştirmemek genellikle mantıklıdır. Değişiklik gerekiyorsa URL inventory ve one to one redirect mapping hazırlanmalıdır. Migration sonrası eski host hitleri aylar boyunca loglardan takip edilmelidir.

Mevcut Kurumsal Sitede WWW Yapısı Değiştirilmeli mi?

Mevcut sitede www yapısını değiştirmek normal bir configuration düzenlemesinden çok URL migration olarak değerlendirilmelidir. Arama motorları ve kullanıcılar için adres değiştiği için redirect, canonical, sitemap ve internal link güncellemesi gerekir. Google www ve non-www arasında aynı domain içinde yapılan değişikliklerde Search Console Change of Address aracının gerekli olmadığını belirtir, ancak redirect ve canonical kontrollerinin yine doğru yapılması gerekir. Değişikliğin nedeni yalnız URL'yi kısa göstermekse risk çoğu zaman faydadan büyüktür. Somut CDN, DNS veya architecture gereksinimi varsa planlı migration yapılabilir.

Sadece Estetik Amaçlı Değişiklik

URL'deki www ifadesini kaldırmak bazı ekipler için daha modern veya kısa görünebilir. Fakat bu değişiklik kullanıcı açısından çok küçük bir kazanım sağlarken bütün URL setini değiştirir. Search, analytics, social sharing ve backlink tarafında migration takibi gerekir. Teknik bir ihtiyaç yoksa mevcut güçlü hostname'i korumak daha düşük risklidir. Marka materyallerinde kısa domain yazılıp teknik olarak redirect kullanılması da alternatif olabilir.

Teknik Gerekçe

DNS sağlayıcı değişimi, platform standardizasyonu veya cookie architecture gibi nedenler host değişikliğini haklı çıkarabilir. Bu gerekçenin ölçülebilir olması gerekir. Migration öncesi mevcut ve hedef architecture karşılaştırılmalı, kazanım ve operasyon maliyeti yazılı hale getirilmelidir. Security ve backend ekipleri OAuth, CORS ve callback bağımlılıklarını kontrol etmelidir. SEO ekibi URL inventory ve redirect mapping hazırlamalıdır.

CDN/DNS Gereksinimi

Bazı altyapılar belirli hostname biçimiyle daha kolay entegre olabilir. Modern DNS özellikleri nedeniyle geçmişteki birçok apex sınırlaması artık farklı çözümlerle aşılabilmektedir. Bu nedenle provider dokümantasyonu ve gerçek failover ihtiyacı değerlendirilmelidir. Sırf eski teknik varsayımlara dayanarak www migration yapılmamalıdır. CDN değişimi ile host migration aynı release'te yapılacaksa rollback daha zor olacağı için risk ayrıca değerlendirilmelidir.

Subdomain Stratejisi

Yeni app, api ve auth subdomainleri ekleniyorsa ana web hostunun konumu yeniden değerlendirilebilir. WWW marketing site için ayrı boundary oluşturabilir. Bununla birlikte mevcut non-www siteyi değiştirmeden de yeni subdomain strategy kurulabilir. Cookie ve CSP policy host isimlendirmesinden daha önemli güvenlik kriterleridir. Domain standardı gelecekte eklenmesi muhtemel servisleri de kapsamalıdır.

Migration Riskleri

Migration sırasında redirect chain, broken URL, yanlış canonical ve certificate problemi oluşabilir. Üçüncü taraf OAuth veya payment callback'leri unutulursa kullanıcı login veya ödeme akışı bozulabilir. Search sonuçlarında geçici URL değişimleri görülebilir. Server log ve Search Console monitoring bu dönemde daha sık yapılmalıdır. Rollback planı migration başlamadan önce hazırlanmalıdır.

Fayda Risk Kararı

Karar tablosunda beklenen teknik fayda ve migration riski ayrı puanlanabilir. CDN flexibility yüksek fayda sunuyorsa değişiklik mantıklı olabilir. Sadece URL görünümünü değiştirmek genellikle düşük faydalıdır. Trafik, revenue ve third party dependency yüksekse risk puanı artırılmalıdır. Nihai karar SEO, platform, security ve business owner tarafından birlikte verilmelidir.

Dört Temel Domain Varyasyonu Nasıl Analiz Edilir?

Her domain auditinin başlangıç noktası dört temel URL varyasyonunu test etmektir. Bunlar HTTP non-www, HTTP www, HTTPS non-www ve HTTPS www adresleridir. İdeal yapıda yalnız seçilen HTTPS canonical host 200 döndürür. Diğer üç varyasyon aynı path ve query değerini koruyarak mümkün olduğunca tek redirect ile canonical URL'ye gider. Bu basit matris www ile non-www kaynaklı duplicate content indeksleme ve HTTPS sorunları için hızlı teşhis sağlar.

HTTP + Non-WWW

HTTP non-www request production web sitesinde final içerik sunmamalıdır. Preferred host www ise doğrudan HTTPS www karşılığına gitmelidir. Preferred host non-www ise aynı hostun HTTPS sürümüne yönlenebilir. Query string ve path korunmalıdır. Redirect sonucu 301 veya uygun kalıcı code kullanılarak standardize edilmelidir.

HTTP + WWW

HTTP www request de HTTPS canonical hosta taşınmalıdır. Eğer canonical host non-www ise mümkünse aynı response içinde hem protocol hem host normalizasyonu yapılmalıdır. Gereksiz önce HTTPS www ardından HTTPS non-www şeklinde chain oluşturulmamalıdır. HTTP request üzerinde HSTS header etkili değildir, çünkü HSTS güvenli HTTPS response üzerinden öğrenilir. İlk redirect davranışı bu nedenle hâlâ doğru yapılandırılmalıdır.

HTTPS + Non-WWW

Canonical host non-www ise bu varyasyon 200 döndürür. Canonical host www ise HTTPS requestin önce TLS handshake tamamlaması gerekir ve sonrasında redirect response alınır. Bu nedenle secondary hostname geçerli certificate kapsamına dahil olmalıdır. Certificate hatası redirect response gelmeden browser bağlantıyı kesebilir. Bu nokta host migrationlarında sık gözden kaçan operasyon detaylarından biridir.

HTTPS + WWW

Canonical host www ise HTTPS www final 200 URL'dir. Non-www tercih edilmişse HTTPS www kalıcı redirect vermelidir. Server veya CDN final hostu doğru algılamalıdır. Reverse proxy forwarded host configuration yanlışsa loop oluşabilir. Monitoring dört varyasyonu periyodik test ederek yanlış deploymentları erkenden yakalayabilir.

Hangisi 200 Döndürmeli?

İdeal yapıda yalnız preferred HTTPS hostname 200 response ile içerik sunmalıdır. Örneğin tercih https://www.example.com ise aynı path'in diğer protocol ve hostname varyasyonları redirect olmalıdır. Bu standard duplicate URL üretimini azaltır. Bazı teknik servis veya API hostları farklı olabilir, fakat web site canonicalization politikası net kalmalıdır. Health check veya special endpoint gibi istisnalar documentation içinde ayrıca belirtilmelidir.

Diğer Üçü Nasıl Davranmalı?

Diğer üç varyasyon kalıcı redirect ile aynı resource'un canonical karşılığına gitmelidir. Path ve query korunmalı, anlamsız biçimde ana sayfaya yönlendirilmemelidir. Google site migration rehberi alakasız çok sayıda URL'yi tek homepage'e taşımaktan kaçınılmasını önerir. Redirect chain minimum tutulmalı ve loop sıfır olmalıdır. Secondary HTTPS hostname certificate kontrolünden başarıyla geçebilmelidir.

Örnek Canonical Host Modeli: WWW Tercih Edilirse

WWW preferred host seçildiğinde bütün URL sinyalleri HTTPS www adresini göstermelidir. Canonical page 200 döndürür ve diğer host veya protocol varyasyonları aynı path üzerinde ona yönlenir. Sitemap, internal links ve canonical etiketleri doğrudan HTTPS www biçimini kullanmalıdır. Bu model kullanıcı hangi varyasyonu yazarsa yazsın tek final URL üretir. Migration sırasında eski non-www backlinkleri de kalıcı redirect sayesinde çalışmaya devam eder.

HTTPS WWW

HTTPS www bu modelin canonical hostudur. Site içeriği burada normal 200 response ile sunulur. HTML canonical etiketi aynı HTTPS www URL'yi gösterir. Sitemap ve hreflang kayıtları bu hostname'i kullanır. Application absolute URL üretirken de aynı standardı takip eder.

200 OK

Canonical URL'nin 200 OK dönmesi crawler ve kullanıcı için final resource olduğunu gösterir. Canonical page başka bir redirect target olmamalıdır. Response içinde doğru canonical, HSTS ve güvenlik headerları bulunabilir. Monitoring final URL'nin yanlışlıkla 3xx veya 5xx'e dönmesini alarm olarak yakalamalıdır. Cache layer da canonical hostname'i doğru key olarak kullanmalıdır.

HTTPS Non-WWW

HTTPS non-www secondary host görevi görür. Kullanıcı buraya geldiğinde TLS bağlantısı başarılı olmalı ve ardından permanent redirect alınmalıdır. Redirect target aynı path üzerindeki HTTPS www URL'dir. Non-www host content render etmemelidir. Loglar eski backlink veya bookmark kullanımını görmek için secondary host hitlerini ayrı ölçebilir.

301/308 → HTTPS WWW

301 ve 308 kalıcı redirect sınıfındadır. 308 request method ve body'nin korunmasını garanti ederken 301 eski user agent davranışlarında non GET methodlarda farklılık gösterebilir. Normal web sayfası GET trafiğinde 301 yaygın ve anlaşılır seçimdir. API veya method preservation önemliyse 308 teknik olarak daha belirgin davranış sağlar. Hangi code seçilirse seçilsin kurum standardı tutarlı uygulanmalıdır.

HTTP WWW

HTTP www request canonical HTTPS www adresine taşınmalıdır. İlk olarak aynı host HTTPS'e, sonra başka hosta gitmek gerekmiyorsa tek response yeterlidir. Location header final canonical URL'yi göstermelidir. User agent yeni HTTPS request yapar ve 200 içerik alır. Hop sayısı monitoring sisteminde ölçülebilir.

Tek Hop → HTTPS WWW

Tek hop yaklaşımında protocol ve host normalizasyonu aynı redirect rule içinde çözülür. http://www.example.com/a doğrudan https://www.example.com/a adresine gider. Bu model gereksiz round trip'i azaltır. Query string korunmalıdır. Redirect targetın tekrar redirect vermemesi quality gate ile test edilmelidir.

HTTP Non-WWW

HTTP non-www en uzak varyasyon gibi görünse de yine doğrudan final URL'ye yönlenebilir. Önce www sonra HTTPS yapmak şart değildir. Edge veya web server request host ve scheme değerini okuyarak canonical target oluşturabilir. Path normalization ayrı rule gerektiriyorsa chain riski dikkatle yönetilmelidir. En ideal sonuç tek permanent response ve ardından final 200'dür.

Tek Hop → HTTPS WWW

http://example.com/path doğrudan https://www.example.com/path adresine yönlendirilmelidir. Bu yapı hem protocol hem host değişimini tek request cycle içinde gerçekleştirir. Crawler ve kullanıcı fazladan ara URL ziyaret etmez. Redirect rule query parametrelerini kaybetmemelidir. Automated tests dört varyasyonu her release'te kontrol edebilir.

Örnek Canonical Host Modeli: Non-WWW Tercih Edilirse

Non-www preferred host modelinde aynı prensip ters yönde uygulanır. HTTPS apex URL 200 döndürür ve www ile HTTP varyasyonları doğrudan ona taşınır. Canonical, sitemap, internal links ve structured data non-www URL üretmelidir. CDN veya DNS sağlayıcısının apex desteği production gereksinimlerini karşılamalıdır. Mevcut www site migration yapıyorsa URL mapping ve certificate hazırlığı değişiklikten önce tamamlanmalıdır.

HTTPS Non-WWW

HTTPS non-www final canonical hosttur. Bu adres doğrudan 200 içerik sunar. Self canonical aynı URL'yi gösterir. Sitemap yalnız bu host üzerindeki URL'leri içerir. Third party campaign ve profile URL'leri zamanla bu biçime güncellenir.

200 OK

Canonical non-www URL başarılı HTTPS bağlantısından sonra 200 dönmelidir. Response başka hosta redirect vermemelidir. TLS certificate apex hostname'i kapsamalıdır. HSTS policy host ve subdomain tasarımına göre dikkatle yapılandırılmalıdır. Monitoring certificate expiry ve final status kodunu sürekli kontrol edebilir.

HTTPS WWW

HTTPS www secondary hostname olarak çalışır. Valid TLS certificate sonrası permanent redirect response verir. Redirect aynı resource'un non-www karşılığına gider. www üzerinde farklı content veya CMS page render edilmemelidir. Old backlink traffic loglardan takip edilerek migration performansı ölçülebilir.

301/308 → HTTPS Non-WWW

Kalıcı host değişikliğinde 301 veya 308 kullanılabilir. 308 method preservation davranışını açık biçimde garanti eder. Web sayfalarının standart GET requestlerinde 301 uzun süredir yaygın kullanılan çözümdür. API route veya POST davranışı varsa redirect semantics ayrıca test edilmelidir. Redirect code application ve edge katmanlarında çelişkili olmamalıdır.

HTTP Non-WWW

HTTP non-www yalnız protocol normalization gerektirir. Doğrudan aynı path'in HTTPS non-www karşılığına gitmelidir. Redirect target final 200 URL olmalıdır. HSTS daha sonraki browser ziyaretlerinde HTTP kullanımını önleyebilir. İlk ziyaret için HTTP listener ve redirect rule hâlâ gereklidir.

Tek Hop → HTTPS Non-WWW

Tek hop redirect kullanıcıyı ara hostname'e uğratmaz. Location header doğrudan secure canonical URL'yi gösterir. Path ve query korunur. Redirect latency ölçülerek edge veya origin performansı takip edilebilir. Quality gate ikinci 3xx response oluşursa deploymentı başarısız sayabilir.

HTTP WWW

HTTP www hem protocol hem host normalization gerektirir. Bu iki işlem aynı redirect response içinde yapılabilir. Önce HTTPS www sonra non-www şeklindeki zincir gereksizdir. Rule ordering doğru tasarlanmalıdır. CDN ve origin aynı request için iki farklı canonical karar üretmemelidir.

Tek Hop → HTTPS Non-WWW

http://www.example.com/x doğrudan https://example.com/x adresine gitmelidir. Redirect response kalıcı olmalıdır. Query string ve path kaybı olmamalıdır. Final URL self canonical sunmalıdır. Automated crawler bütün path örnekleri üzerinde bu davranışı test edebilir.

WWW ve Non-WWW Yönlendirmesinde 301 mi 308 mi?

301 ve 308 kalıcı yönlendirme statüleridir, ancak HTTP method davranışları arasında önemli fark vardır. MDN, 308'in request method ve body'yi koruduğunu, 301'in ise eski istemcilerde bazı non GET requestleri GET'e çevirebildiğini belirtir. Normal web sayfası canonicalization işleminde GET requestler baskın olduğu için 301 yaygın ve anlaşılır çözümdür. API veya method preservation gereken endpointlerde 308 daha güvenli semantic sunabilir. Kurumun redirect policy'si web ve API trafik türlerini ayırarak standard belirlemelidir.

301 Moved Permanently

301 kaynağın kalıcı olarak yeni URL'ye taşındığını ifade eder. Search crawlerları ve browserlar bu durumu uzun süredir destekler. Web page host normalization için yaygın tercihtir. Path ve query değerlerinin doğru Location URL'ye eklenmesi implementation sorumluluğudur. Migration sonrası eski host uzun süre 301 vermeye devam etmelidir.

308 Permanent Redirect

308 de kalıcı redirect ifade eder fakat request method ve body korunur. Bu özellik özellikle POST, PUT veya başka non GET requestlerde önemlidir. Modern altyapılarda hostname normalization için de kullanılabilir. CDN ve client compatibility kurumsal ortamda test edilmelidir. Web sayfası ve API policy'si aynı olmak zorunda değildir.

HTTP Method Preservation

Method preservation client'ın redirect sonrası aynı HTTP methodunu kullanması anlamına gelir. 307 temporary ve 308 permanent redirect bunu açık biçimde korur. 301 ve 302 eski istemcilerde farklı davranış gösterebilir. Form POST veya webhook trafiği hostname redirectine maruz kalıyorsa bu fark kritik hale gelir. Bu nedenle API ve callback URL'leri migration öncesinde özel test setine alınmalıdır.

Normal Web Sayfalarında Kullanım

Normal web navigation çoğunlukla GET request kullandığı için 301 pratik ve yaygın çözümdür. SEO ekipleri ve crawler araçları tarafından kolay anlaşılır. Redirect kalıcı host standardını açık biçimde belirtir. 308 de teknik olarak kullanılabilir, fakat bütün mevcut edge ve monitoring tool davranışları doğrulanmalıdır. Kurum standardında hangisinin tercih edildiği documentation içinde yazılmalıdır.

API Endpointlerinde Kullanım

API endpointlerinde method preservation daha kritik olabilir. POST request'in redirect sonrası GET'e dönüşmesi işlem semantiğini bozabilir. 308 bu belirsizliği ortadan kaldırır. Bununla birlikte API clientların redirect takip edip etmediği ayrıca test edilmelidir. En iyi yaklaşım client configuration'larını doğrudan final canonical API hostname'e güncelleyerek redirect bağımlılığını azaltmaktır.

302 ve 307 Neden Preferred Host İçin Genellikle Uygun Değildir?

302 ve 307 temporary redirect anlamı taşır. Preferred host seçimi ise normal şartlarda geçici değil kalıcı architecture kararıdır. Bu nedenle canonical hostname consolidation için kalıcı redirect semantic kullanmak daha doğru olur. Temporary status belirli migration testleri veya kısa süreli routing senaryolarında anlamlıdır. Kalıcı standardı geçici status ile ifade etmek crawler ve operasyon ekiplerine yanlış sinyal verir.

Temporary Redirect Kavramı

Temporary redirect kaynağın ana adresinin değişmediğini, kullanıcının geçici olarak başka location'a gitmesi gerektiğini belirtir. 302 ve 307 bu kategoriye girer. 307 methodu korurken 302 eski client davranışlarında farklı method handling gösterebilir. Host migration kalıcıysa temporary semantic kullanılmamalıdır. Monitoring tool redirect code değişikliğini configuration regression olarak yakalayabilir.

Kalıcı Host Tercihi

Preferred host uzun vadeli URL standardıdır. Kullanıcı ve crawler eski host yerine yeni canonical hostu kullanmaya yönlendirilir. Bu nedenle permanent redirect daha açık bir işaret sağlar. Sitemap ve internal linkler de final hosta güncellenir. Secondary host yalnız compatibility ve legacy traffic için redirect endpoint olarak kalır.

Geçici Migration Senaryoları

Yeni hostu kısa süre test etmek için temporary routing kullanılabilir. Ancak production search traffic üzerinde uzun süre 302 bırakmak migration hedefiyle çelişebilir. Test mümkünse staging veya controlled canary ortamında yapılmalıdır. Final cutover sırasında kalıcı redirect policy aktif edilir. Rollback gerekiyorsa configuration versioning ile eski durum geri getirilebilir.

A/B Test Gibi İstisnalar

A/B test routing farklı amaç taşır ve preferred host migration ile karıştırılmamalıdır. Kullanıcının deney varyantına geçici yönlendirilmesi temporary status veya application routing gerektirebilir. Canonical URL stratejisi experiment tasarımından ayrı ele alınmalıdır. Hostname değişimi A/B test aracı olarak kullanılacaksa analytics ve SEO sinyalleri dikkatle incelenmelidir. Kalıcı site hostname policy'si experiment sona erdiğinde değişmemelidir.

WWW / Non-WWW Redirect Chain Nedir?

Redirect chain bir URL'nin final sayfaya ulaşmadan önce birden fazla 3xx response üzerinden geçmesidir. Örneğin HTTP non-www önce HTTP www, sonra HTTPS www adresine gidiyorsa iki redirect hop oluşur. Bu yapı ek network round trip yaratır ve configuration karmaşasını artırır. MDN redirectlerin ek request gerektirdiğini ve bunun performans maliyeti olduğunu açıklar. Preferred host standardında mümkün olduğunca bütün alternatif varyasyonlar doğrudan final canonical URL'ye gitmelidir.

İdeal Yapı

İdeal yapı her secondary varyasyondan tek redirect ile final URL'ye ulaşır. Protocol ve host normalization aynı rule içinde yapılabilir. Path ve query korunur. Redirect target 200 döndürür. Automated audit hop count değerini birden büyük olduğunda uyarı olarak raporlayabilir.

HTTP Non-WWW → HTTPS WWW

Bu örnekte canonical host HTTPS www'dir. HTTP non-www request doğrudan https://www.example.com karşılığına gider. Ara HTTP www veya HTTPS non-www URL ziyaret edilmez. Bu yöntem latency ve crawl path'i sadeleştirir. Rule bütün site pathlerinde aynı davranışı göstermelidir.

Zincirli Yapı

Zincirli yapı genellikle farklı katmanlarda bağımsız redirect kuralları olduğunda oluşur. Bir server yalnız hostu değiştirirken başka katman yalnız protocolü değiştirebilir. Sonuçta kullanıcı iki veya daha fazla round trip yapar. Küçük sitelerde fark az görünse bile global traffic ve mobile latency altında maliyet büyür. Tek Source of Truth ilkesi bu tür chain'leri azaltır.

HTTP Non-WWW → HTTP WWW → HTTPS WWW

İlk redirect yalnız hostname'i düzeltir, ikinci redirect HTTPS'e geçirir. Teknik olarak çalışsa da aynı hedef tek response ile elde edilebilir. Redirect rule birleşik normalization yapmalıdır. Edge katmanda çözüm mümkünse origin'e ikinci request gitmesi de önlenir. CI testleri final host ve hop sayısını birlikte doğrulamalıdır.

Daha Uzun Chain

Legacy domain migrationları zamanla üç veya dört hop'a çıkabilir. Eski domain önce www standardına, sonra HTTPS'e, ardından yeni markanın domainine gidebilir. Her yeni migration eski chain'i olduğu gibi bıraktığında teknik borç büyür. Redirect mapping bütün eski kaynakları mümkün olduğunca doğrudan güncel final URL'ye bağlamalıdır. Özellikle yüksek backlink alan legacy URL'ler öncelikli temizlenmelidir.

HTTP → WWW → HTTPS → Yeni Domain

Bu pattern çok sayıda bağımsız migration kararının üst üste eklenmesiyle oluşur. Kullanıcı önce protocol veya host, sonra domain değişikliklerinden geçer. Mapping yeni domain migration sırasında yeniden yazılarak eski URL doğrudan final targeta gönderilebilir. Search crawler ve kullanıcı daha kısa path izler. Redirect source inventory bu teknik borcun bulunması için gereklidir.

Kullanıcı ve Crawler Etkisi

Her redirect ek request ve latency oluşturur. Çok uzun chain bazı crawler veya third party client davranışlarında sorun yaratabilir. Monitoring chain length ve redirect latency metric'lerini izlemelidir. Internal linklerin eski URL'ye gitmesi chain trafiğinin en kolay düzeltilebilecek kaynaklarından biridir. External backlinkleri değiştirmek zor olsa da internal sistemler doğrudan final URL kullanmalıdır.

WWW ve HTTPS Tek Hop’ta Nasıl Çözülür?

HTTP ve hostname normalization aynı request bilgisi kullanılarak tek redirect response içinde çözülebilir. Server gelen scheme ve Host header değerini kontrol eder ve canonical URL'yi doğrudan oluşturur. Bu yaklaşım hem www hem HTTPS migrationını ayrı ara adımlara bölme ihtiyacını ortadan kaldırır. Query string ve path aynen korunmalıdır. Final Location URL başka bir redirect üretmemelidir.

Protocol Normalization

Protocol normalization HTTP isteklerini HTTPS'e taşır. Güvenli site için port 80 listener yalnız redirect hizmeti verebilir. MDN HTTPS sitelerin HTTP isteklerini güvenli sürüme yönlendirmesini ve HSTS ile sonraki ziyaretlerde HTTPS kullanımını güçlendirmesini önerir. Protocol rule host normalization ile aynı response içinde birleştirilebilir. Reverse proxy arkasında gerçek client scheme doğru header üzerinden algılanmalıdır.

Host Normalization

Host normalization request hostname'ini preferred host ile karşılaştırır. Farklıysa Location final canonical hostname kullanır. Allowed host listesi uygulanması Host header injection riskini azaltabilir. Target URL user supplied hosttan körü körüne türetilmemelidir. Application veya edge config canonical hostname'i güvenilir configuration değeri olarak saklamalıdır.

Tek Redirect Response

Tek response hem scheme hem host değişikliğini gerçekleştirir. Client yalnız bir 3xx ve ardından final 200 görür. Bu yapı daha kolay loglanır ve test edilir. Redirect rule başka rewrite kurallarıyla çakışmamalıdır. Query ve path normalization ayrıca gerekiyorsa aynı response'a dikkatle dahil edilebilir.

Final Canonical URL

Final URL tercih edilen HTTPS host üzerinde olmalıdır. Sayfa self canonical sunmalıdır. Sitemap ve internal links aynı URL biçimini kullanmalıdır. Search Console inspection ile Google'ın selected canonical davranışı kontrol edilebilir. Redirect targetın 404 veya başka redirect vermemesi automated monitoring ile doğrulanmalıdır.

Query String ve Path Koruması

Host redirect kullanıcının ziyaret ettiği resource'u değiştirmemelidir. /products?id=10 adresi aynı path ve query ile final hosta gitmelidir. Query parametrelerinden bazıları bilinçli olarak kaldırılacaksa bu ayrı URL normalization policy'sidir. Redirect implementation encoding sorunlarına karşı test edilmelidir. Unicode path, trailing slash ve encoded query örnekleri QA datasetine eklenebilir.

Redirect Loop Nasıl Oluşur?

Redirect loop iki veya daha fazla katmanın aynı request için farklı canonical karar vermesiyle oluşabilir. CDN www'ye yönlendirirken origin non-www'ye gönderirse kullanıcı sonsuz döngüye girer. HTTP ve HTTPS scheme bilgisinin proxy arkasında yanlış algılanması da her requestin tekrar HTTPS'e yönlendirilmesine neden olabilir. CMS plugin ile web server configuration aynı anda farklı rule uyguladığında benzer problem çıkar. Loop production availability problemi olduğu için monitoring bunu kritik alarm olarak değerlendirmelidir.

CDN WWW’ye Gönderiyor

CDN edge rule canonical hostu www olarak belirlemiş olabilir. Origin configuration non-www standardını kullanıyorsa CDN'den geçen her request karşılıklı redirect görebilir. Architecture document hangi katmanın host normalization sahibi olduğunu açıkça belirtmelidir. Origin mümkünse edge tarafından normalize edilmiş requesti tekrar redirect etmemelidir. Config changes integration environment'da CDN ile birlikte test edilmelidir.

Origin Non-WWW’ye Gönderiyor

Origin server application ayarından dolayı bütün requestleri non-www'ye yönlendirebilir. CDN ise public standard olarak www kullanıyorsa conflict oluşur. Origin'e forwarded Host header yerine internal hostname ulaşıyorsa rule yanlış karar verebilir. Trusted proxy header configuration önemlidir. Redirect logic tek yerde tutulduğunda bu problem daha kolay önlenir.

HTTP/HTTPS Çakışması

Reverse proxy TLS'i sonlandırıp origin'e HTTP ile bağlanabilir. Origin requesti HTTP gördüğü için sürekli HTTPS redirect üretirse proxy tekrar aynı HTTP origin requestini yapabilir. X Forwarded Proto veya platformun eşdeğer trusted header'ı doğru kullanılmalıdır. Header yalnız güvenilir proxy'den geliyorsa kabul edilmelidir. Integration test external URL üzerinde loop olup olmadığını doğrulamalıdır.

CMS ve Server Kuralı Çakışması

CMS admin panelinde site URL non-www iken NGINX www redirect uygulayabilir. Uygulama requesti aldıktan sonra tekrar kendi configured URL'sine yönlendirir. Bu nedenle application base URL ve infrastructure preferred host aynı configuration source'tan türetilebilir. Plugin tabanlı redirectler inventory içinde görünür olmalıdır. Migration öncesi eski CMS redirect extensionları kapatılmalı veya standardla uyumlu hale getirilmelidir.

Reverse Proxy Header Hatası

Reverse proxy original host ve scheme bilgisini backend'e aktarırken yanlış veya eksik header gönderebilir. Backend kendi internal addressini public URL sanabilir. Absolute redirect veya canonical URL yanlış hostname üretebilir. Trusted proxy configuration framework seviyesinde doğru yapılmalıdır. Security test forged forwarded header ile external redirect manipülasyonu olup olmadığını da kontrol etmelidir.

Redirect Hangi Katmanda Yönetilmeli?

Redirect mümkün olduğunca kullanıcıya yakın ve application logic'ten bağımsız katmanda uygulanabilir. CDN veya edge yüksek trafikte origin yükünü azaltabilir. Web server veya reverse proxy ise vendor bağımlılığını azaltan merkezi configuration noktası olabilir. DNS HTTP status response üretmez ve bu nedenle gerçek redirect katmanı değildir. En önemli prensip aynı canonicalization kararının birden fazla yerde çelişkili biçimde tanımlanmamasıdır.

DNS

DNS hostname'i IP veya başka DNS kaynağına çözmek için kullanılır. Browsera 301 response döndürmez. DNS seviyesinde URL path bilgisi bulunmadığı için /products gibi resource mapping yapılamaz. Bazı providerlar “URL forwarding” adıyla ek HTTP hizmeti sunabilir, fakat bu DNS protokolünün kendisi değildir. Architecture document bu iki işlevi birbirinden ayırmalıdır.

CDN / Edge

CDN edge request origin'e ulaşmadan redirect verebilir. Bu düşük latency ve origin tasarrufu sağlar. Global trafik için etkili çözümdür. Rule precedence ve cache behavior dikkatle test edilmelidir. Vendor değişiminde rule portability ve infrastructure as code desteği değerlendirilmelidir.

Load Balancer

Load balancer host ve scheme bazlı redirect uygulayabilir. Application instance'a request ulaşmadan normalization yapılır. Merkezi configuration birden fazla backend service'i aynı standarda bağlayabilir. Health check route'ları için istisna gerekebilir. Configuration değişiklikleri version control ve automated test ile yönetilmelidir.

Reverse Proxy

Reverse proxy NGINX veya benzer gateway ile canonical host redirecti uygulayabilir. Public host ve TLS bilgisine yakın olduğu için uygun katmandır. Application framework değişse bile policy korunabilir. Proxy arkasında başka CDN varsa forwarded header standardı doğru kurulmalıdır. Redirect rule exact host allowlist kullanmalıdır.

Web Server

Apache, NGINX veya IIS seviyesinde redirect oldukça yaygın yaklaşımdır. Static ve dynamic bütün requestler application çalışmadan normalize edilebilir. Config değişiklikleri deploy pipeline'a alınmalıdır. Çok sayıda domain varsa generated configuration kullanılabilir. Manual server değişiklikleri configuration drift oluşturabileceği için kaçınılmalıdır.

Application

Application middleware host kontrolü yapabilir ve dynamic logic gerektiğinde yararlıdır. Fakat request application runtime'a kadar geldiği için gereksiz compute kullanabilir. Framework update veya routing bug redirect davranışını etkileyebilir. Domain canonicalization gibi basit kural için daha alt katman genellikle daha sade olur. Application yine absolute URL üretirken preferred host configuration'ını kullanmalıdır.

CMS

CMS plugin veya site URL configuration redirect uygulayabilir. Küçük sitelerde kolay yönetim sağlar. Kurumsal sistemde plugin bağımlılığı, update ve role permission risk oluşturabilir. Infrastructure katmanındaki rule ile conflict ihtimali yüksektir. CMS yalnız canonical URL üretimi için kullanılırken redirect edge veya server katmanına taşınabilir.

Tek Source of Truth İlkesi

Preferred host configuration tek otorite tarafından belirlenmelidir. CDN, origin ve application aynı canonical hostname değerini ortak config veya infrastructure code üzerinden alabilir. Rule farklı repositorylerde kopyalanırsa zamanla drift oluşabilir. Deployment pipeline dört URL varyasyonunu test ederek nihai davranışı doğrular. Ownership RACI dokümanında açık biçimde tanımlanmalıdır.

CDN Seviyesinde WWW / Non-WWW Redirect

CDN seviyesinde redirect kullanıcıya fiziksel olarak yakın edge noktasında uygulanabilir. Request origin servera ulaşmadan sonuçlandığı için latency ve backend yükü azalır. Büyük kurumsal sitelerde milyonlarca legacy host requesti varsa bu tasarruf anlamlı olabilir. Ancak edge rule'ların sırası, cache behavior ve origin fallback yapılandırması dikkatle test edilmelidir. Provider değişimi durumunda özel rule syntax migration maliyetine dahil edilmelidir.

Edge Redirect

Edge redirect Host header ve scheme değerini kontrol ederek Location response oluşturabilir. Rule static canonical host kullanmalıdır. Request path ve query güvenli biçimde korunmalıdır. Redirect response cache policy uygun ayarlanabilir. Edge logs migration traffic analizi için kullanılabilir.

Origin'e Gitmeden Yönlendirme

Secondary host requestinin origin'e gitmemesi backend resource tüketimini azaltır. Ayrıca application bug veya CMS configuration'ından bağımsız canonicalization sağlar. Edge certificate iki hostname'i de kapsamalıdır. DNS her hostu CDN ağına doğru çözmelidir. Origin yalnız final canonical host traffic alacak biçimde firewall veya host validation uygulayabilir.

Performans Avantajı

Edge redirect global kullanıcı için daha kısa network path sağlar. Origin round trip ve application processing ortadan kalkar. Average redirect latency monitoring dashboard'da edge location bazında ölçülebilir. Büyük traffic hacminde backend bandwidth de azalır. Bu avantaj provider lock-in ve configuration yönetimi maliyetiyle birlikte değerlendirilmelidir.

Rule Precedence

CDN üzerinde HTTPS redirect, host redirect, path rewrite ve security rule sırası önemlidir. Yanlış precedence chain veya loop oluşturabilir. Canonical host rule mümkün olduğunca tek final Location üretmelidir. Daha spesifik legacy path redirectleri gerektiğinde host normalization ile birleştirilebilir. Rule changes staging hostname veya dry run log ile test edilebilir.

CDN Vendor Değişimi Riski

Provider-specific expression ve edge function kullanımı migration maliyeti yaratır. Redirect matrix vendor bağımsız dokümanda saklanmalıdır. Infrastructure code yeni provider config üretmek için yeniden kullanılabilir. Critical tests dışarıdan HTTP request yaparak gerçek davranışı doğrulamalıdır. Böylece provider değişse bile business rule aynı kalır.

Web Server Seviyesinde Redirect

Web server redirecti klasik ve güvenilir çözümlerden biridir. Apache, NGINX ve IIS gelen Host ile scheme bilgisini kontrol ederek kalıcı Location response verebilir. Application çalışmadan request sonuçlandığı için performans açısından uygundur. Configuration repository içinde versionlanırsa değişiklik geçmişi ve rollback kolaylaşır. Birden fazla environment için template kullanmak manual drift'i azaltır.

Apache

Apache redirect mod_alias veya mod_rewrite gibi mekanizmalarla uygulanabilir. Basit hostname değişiminde mümkün olan en sade rule tercih edilmelidir. VirtualHost seviyesinde ayırmak .htaccess'e göre merkezi kontrol sağlayabilir. Query ve path behavior test edilmelidir. Apache arkasında reverse proxy veya CDN varsa gerçek scheme algısı ayrıca doğrulanmalıdır.

.htaccess

.htaccess shared hosting ortamlarında kolay configuration sağlar. Ancak her requestte directory configuration okunması ve kuralların dağıtık halde bulunması büyük kurumsal yapılarda yönetim zorluğu yaratabilir. Redirect rule başka rewrite pluginleriyle çakışabilir. Repository üzerinden deploy edilen merkezi config daha iyi kontrol sunabilir. .htaccess kullanılıyorsa automated tests gerçek server behavior'ını doğrulamalıdır.

VirtualHost

VirtualHost canonical ve secondary hostname'leri açık biçimde ayırabilir. Secondary host yalnız redirect response verecek minimal configuration kullanabilir. HTTPS VirtualHost için certificate yine gereklidir. Main host application veya proxy backend'e traffic geçirir. Bu ayrım architecture ve log analizi açısından anlaşılır model sağlar.

NGINX

NGINX server block yaklaşımı hostname normalization için sade yapı sunar. Secondary server block doğrudan return 301 veya 308 kullanabilir. Regex rewrite gerekmediğinde basit configuration hata riskini azaltır. TLS server name ve certificate mapping doğru olmalıdır. Config test command CI içinde syntax gate olarak çalıştırılabilir.

Server Block

Her hostname için ayrı server block tanımlanabilir. Canonical block application traffic'i işlerken secondary block redirect verir. HTTP listener bütün hostları final HTTPS hostname'e yönlendirebilir. Default server bilinmeyen Host headerlarını güvenli biçimde reddedebilir. Bu yöntem Host header manipulation riskini de azaltmaya yardımcı olur.

IIS

IIS URL Rewrite veya HTTP Redirect özellikleriyle canonicalization uygulayabilir. Windows tabanlı kurumsal altyapıda merkezi configuration yönetimi önemlidir. Rule sequence ve inherited settings gözden geçirilmelidir. Load balancer arkasında HTTPS termination varsa forwarded scheme configuration doğru olmalıdır. Deployment sonrası dört hostname variation automated testten geçirilmelidir.

Reverse Proxy

Reverse proxy farklı application stackleri önünde ortak domain standardı sağlar. NGINX, Envoy veya platform gateway gibi çözümler kullanılabilir. Canonical redirect application kodundan ayrıldığı için ekipler arası tutarlılık artar. Proxy allowed host listesi kullanmalıdır. Forwarded headers yalnız trusted upstream kaynaklardan kabul edilmelidir.

Konfigürasyon Yönetimi

Redirect configuration manuel production değişikliği olarak bırakılmamalıdır. Git repository, review ve automated test ile yönetilebilir. Environment specific hostname değerleri parameter olarak tutulabilir. Rollback previous known good configuration'a dönmeyi sağlar. Audit trail hangi değişikliğin redirect davranışını bozduğunu hızlı gösterir.

Application-Level Redirect Ne Zaman Kullanılmalı?

Application seviyesinde redirect dynamic business logic gerektiğinde anlamlıdır. Kullanıcının tenant, language veya authentication durumuna göre route değişecekse framework middleware karar verebilir. Buna karşılık www ve non-www canonicalization genellikle static infrastructure kuralıdır ve daha alt katmanda çözülmesi daha verimlidir. Application redirecti backend runtime, dependency ve deployment cycle'a bağlıdır. Kurumsal domain policy mümkün olduğunca uygulama frameworkünden bağımsız tutulmalıdır.

Framework Middleware

Middleware her incoming requestte Host veya scheme kontrol edebilir. Dynamic configuration veya multi-tenant custom domain sistemi için esneklik sağlar. Request application processine kadar ulaştığı için edge redirectten daha maliyetlidir. Proxy arkasında scheme ve host güvenilir headerlardan alınmalıdır. Redirect response unit ve integration testlerle doğrulanmalıdır.

Edge Runtime

Edge runtime application logic ile CDN arasındaki orta katman gibi çalışabilir. Dynamic redirect rule düşük latency ile uygulanabilir. Custom domain lookup veya geo routing gibi ihtiyaçlarda faydalıdır. Basit preferred host için static edge rule daha sade olabilir. Runtime code dependency ve cold start etkisi performans ölçümüne dahil edilmelidir.

Dynamic Redirect Gereksinimi

Bazı SaaS sistemleri tenant bazlı canonical host hesaplamak zorunda olabilir. Custom domains doğrulanmış config database'den okunabilir. Bu durumda static server rule yetersiz kalabilir. Security açısından tenantın başka domain üzerinde açık redirect üretmesine izin verilmemelidir. Dynamic redirect output allowlist ve ownership validation ile sınırlandırılmalıdır.

Dezavantajları

Application redirect daha fazla compute ve latency oluşturabilir. Uygulama down olduğunda secondary host redirect de çalışmayabilir. Framework değişikliği canonicalization behavior'ını etkileyebilir. Redirect logic farklı codebase'lere kopyalanırsa drift oluşur. Bu nedenle basit domain standardı için infrastructure layer daha dayanıklı olabilir.

Domain Canonicalization İçin Neden Genellikle Daha Alt Katman Tercih Edilir?

Canonical host kuralı request body veya business data gerektirmez. Edge, load balancer veya web server Host header üzerinden karar verebilir. Böylece application resource tüketilmez ve uygulama arızası redirect hizmetini etkilemez. Policy birden fazla application tarafından ortak kullanılabilir. Daha alt katman seçimi debug ve ownership modelini de sadeleştirir.

DNS ile HTTP Redirect Aynı Şey midir?

DNS ile HTTP redirect aynı işlem değildir. DNS hostname'in hangi IP veya hedef DNS adına çözüleceğini belirler. HTTP redirect ise web server veya benzer HTTP hizmetinin 3xx response ile clienta yeni URL bildirmesidir. DNS request path veya query bilgisine sahip değildir. Bu ayrım anlaşılmadığında “DNS'te www'yi non-www'ye yönlendirdik” gibi teknik olarak belirsiz ifadeler ortaya çıkar.

DNS Ne Yapar?

DNS alan adlarını IP adresi veya başka DNS recordlarına çözer. A, AAAA, CNAME ve diğer record türleri isim çözümleme için kullanılır. Browser DNS sonrasında servera HTTP veya HTTPS request gönderir. DNS web response status kodunu belirlemez. TTL ve caching DNS propagation davranışını etkiler.

HTTP Redirect Ne Yapar?

HTTP redirect serverın 3xx response ve Location header göndermesidir. Browser Location URL'ye yeni request yapar. Redirect path ve query bilgisiyle çalışabilir. 301, 302, 307 ve 308 farklı semantic taşır. Preferred host consolidation için permanent redirect kullanılır.

DNS Tek Başına 301 Döndürür mü?

Hayır, standart DNS protocolü HTTP 301 response üretmez. Bazı DNS provider panellerindeki URL forwarding özelliği arka planda ayrı HTTP service kullanır. Kullanıcı açısından kolay görünse de bunun DNS ile aynı katman olmadığı bilinmelidir. HTTPS forwarding için service'in certificate desteği gereklidir. Kurumsal architecture açık ownership ve observability istediği için gerçek redirect hizmeti belirlenmelidir.

Redirect Service Modelleri

Redirect CDN edge, dedicated web server, load balancer veya küçük serverless service ile sunulabilir. Legacy domain portföyü için merkezi redirect platformu kullanılabilir. Her domain certificate ve DNS configuration ile bu servise bağlanır. Mapping config repository içinde tutulabilir. High availability ve monitoring redirect service'in kendisi için de gereklidir.

DNS ve HTTP Katmanlarını Ayırmak

DNS hangi servise bağlanılacağını, HTTP ise bağlandıktan sonra requestin nasıl davranacağını belirler. Troubleshooting sırasında önce DNS resolution sonra TLS ve HTTP response kontrol edilmelidir. Bu katmanlar ayrı log ve monitoring sistemlerine sahiptir. DNS hatası varsa browser redirect servera hiç ulaşamaz. HTTP redirect yanlışsa DNS doğru olsa bile final URL hatalı olur.

Apex Domain ve CNAME Problemi

Zone apex üzerinde klasik CNAME kullanımının DNS standardı ve diğer zorunlu recordlarla ilişkili sınırlamaları vardır. Bu tarihsel durum www subdomain'in CDN entegrasyonlarında yaygın tercih edilmesinin nedenlerinden biridir. Modern DNS sağlayıcıları flattening veya alias benzeri mekanizmalarla uygulama seviyesinde kolaylık sunabilir. Bu çözümler standart CNAME ile aynı şey olmayabilir ve provider behavior'ı incelenmelidir. Kurumsal non-www seçimi yapılırken authoritative DNS özellikleri, failover ve portability birlikte değerlendirilmelidir.

Zone Apex Nedir?

Zone apex DNS zone'un kök adıdır, örneğin example.com. Bu noktada SOA ve NS gibi zone için temel recordlar bulunur. WWW ise apex altında ayrı hostname'dir. Apex üzerinde service routing yapmak provider özelliklerine bağlı olabilir. Architecture ekibi apex kullanımının DNS failover ve CDN entegrasyonuna etkisini test etmelidir.

Klasik CNAME Kısıtı

Klasik DNS modelinde aynı name üzerinde CNAME ile başka data recordlarının birlikte bulunması sorun oluşturur. Zone apex ise NS ve SOA gibi recordlara ihtiyaç duyar. Bu nedenle geleneksel CNAME doğrudan apex için uygun değildir. Modern provider abstractionları bu sorunu farklı yöntemlerle çözer. Configuration export edildiğinde bu özel davranışın başka sağlayıcıda birebir bulunacağı varsayılmamalıdır.

A / AAAA Record

A record hostname'i IPv4 adresine, AAAA ise IPv6 adresine bağlar. Apex için doğrudan IP mapping yapılabilir. CDN veya load balancer IP'leri sabit değilse management zorlaşabilir. Provider health check ve failover service destekleyebilir. IP değişim otomasyonu DNS as Code pipeline ile yönetilebilir.

CNAME Flattening

Flattening providerın CNAME benzeri targetı arka planda resolve edip apex için uygun response üretmesini sağlar. Kullanıcı configurationda hostname target belirleyebilir. Bu özellik provider-specific behavior gösterebilir. TTL ve refresh semantics incelenmelidir. DNS migration öncesi flattening dependency inventory çıkarılmalıdır.

ALIAS / ANAME Benzeri Çözümler

Bazı DNS platformları apex için ALIAS veya ANAME benzeri record abstractionları sunar. Bu kayıtlar standard DNS client açısından genellikle A veya AAAA response olarak görünür. Provider backend target hostname'i çözerek sonucu üretir. Failover ve health check behavior producta göre değişebilir. Kurumsal architecture bunları klasik CNAME olarak genellememelidir.

Modern DNS Sağlayıcılarında Apex Kullanımı

Günümüzde apex domain üzerinde CDN veya cloud service kullanmak çoğu altyapıda mümkündür. Bu nedenle “non-www teknik olarak çalışmaz” şeklindeki eski genelleme doğru değildir. Asıl soru providerın apex aliasing, DNSSEC, failover ve automation gereksinimlerini karşılayıp karşılamadığıdır. Proof of concept DNS failover ve certificate issuance senaryolarını içermelidir. Vendor lock-in riski configuration standardında belgelenmelidir.

WWW Kullanımı CDN İçin Zorunlu mudur?

WWW geçmişte CDN CNAME entegrasyonu için sık tercih edilmiştir, fakat modern altyapıda mutlak zorunluluk değildir. Apex aliasing ve flattening özellikleri non-www siteyi CDN'e bağlamayı mümkün hale getirebilir. Provider özellikleri ve DNS architecture bu kararı belirler. Sadece CDN kullanılıyor diye mevcut non-www domaini taşımak zorunlu değildir. Gerçek gereksinim vendor documentation ve failover testleriyle doğrulanmalıdır.

Geleneksel CNAME Modeli

WWW subdomain başka CDN hostname'ine CNAME ile kolay bağlanabilir. CDN target IP değişikliklerini kendi tarafında yönetir. Bu operational simplicity tarihsel olarak www kullanımını desteklemiştir. Apex tarafında aynı yaklaşım klasik DNS kısıtına takılır. Modern provider feature'ları bu farkı azaltmıştır.

Apex Aliasing

Apex aliasing providerın apex domaini başka dynamic service targetına bağlamasını sağlar. Kullanıcı non-www URL'yi koruyabilir. DNS response standard A veya AAAA şeklinde sunulabilir. Behavior ve SLA provider'a bağlıdır. Multi-provider DNS strategy varsa alias özelliğinin taşınabilirliği incelenmelidir.

CNAME Flattening

Flattening target hostname'i resolve ederek apex için uygun DNS cevabı üretir. Bu özellik CDN integrationını kolaylaştırabilir. Resolve frequency ve caching provider implementationına bağlı olabilir. Monitoring yalnız public DNS result değil target health durumunu da izlemelidir. Architecture dokümanı bu dependency'yi açıkça belirtmelidir.

Provider Yeteneğine Göre Karar

Host seçimi kullanılacak CDN ve DNS platformunun gerçek yetenekleriyle yapılmalıdır. Marketing ekibinin URL görünüm tercihi tek kriter olmamalıdır. Failover, multi region, certificate automation ve DNSSEC gereksinimleri aynı tabloda değerlendirilmelidir. Benchmark sadece latency değil operasyon kolaylığını da içermelidir. Mevcut domainin değiştirilmesi gerekiyorsa migration maliyeti ayrıca hesaplanmalıdır.

“WWW Her Zaman Daha İyidir” Yanılgısı

WWW bazı mimarilerde teknik avantaj sağlayabilir, fakat her sitenin kullanması gereken zorunlu SEO standardı değildir. Modern DNS çözümleri apex kullanımını çok daha uygulanabilir hale getirmiştir. Non-www da cookie ve subdomain policy doğru tasarlandığında büyük ölçekte çalışabilir. Karar mevcut teknoloji ve risk profilinden üretilmelidir. Eski genellemeler yerine güncel altyapı testi yapılmalıdır.

WWW / Non-WWW ve SSL Sertifikaları

HTTPS redirect çalışmadan önce TLS bağlantısının başarılı olması gerekir. Bu nedenle yalnız canonical host değil, HTTPS üzerinden request kabul edip redirect veren secondary host da geçerli certificate kapsamında olmalıdır. Kullanıcı https://example.com adresine girdiğinde certificate hatası oluşursa browser HTTP redirect response'a ulaşamaz. Certificate automation ve expiry monitoring her hostname'i kapsamalıdır. Migration sırasında DNS cutover öncesinde hedef sertifikaların hazır olması gerekir.

Canonical Host Sertifikası

Canonical host normal web içeriğini HTTPS üzerinden sunduğu için valid certificate gerektirir. Certificate hostname ile eşleşmelidir. Renewal otomatik hale getirilmelidir. CDN TLS termination kullanılıyorsa edge ve origin certificate modeli ayrı olabilir. Monitoring public endpoint certificate expiry ve chain doğruluğunu test etmelidir.

Redirect Veren Hostun Sertifikası

Secondary HTTPS host sadece 301 verse bile TLS handshake önce gerçekleşir. Bu nedenle valid certificate zorunludur. Redirect server application content sunmuyor diye sertifika ihtiyacı ortadan kalkmaz. Migrationlarda eski host certificate'i redirect ömrü boyunca korunmalıdır. Expiry incident eski backlinklerden gelen kullanıcıların siteye ulaşmasını engelleyebilir.

SAN Certificate

SAN certificate birden fazla hostname'i tek certificate içinde kapsayabilir. WWW ve apex aynı certificate'e eklenebilir. Ek subdomainler de ihtiyaç halinde SAN listesinde yer alabilir. Certificate issuance ve renewal automation liste değişikliklerini yönetmelidir. Çok fazla hostname tek certificate üzerinde toplandığında operational blast radius artabilir.

Wildcard Certificate

Wildcard certificate genellikle belirli subdomain seviyesini kapsar. Örneğin *.example.com www ve app gibi subdomainleri kapsayabilir, fakat apex example.com için ayrıca SAN gerekebilir. Bu davranış certificate tasarımında açık biçimde kontrol edilmelidir. Wildcard private key'in kapsamı geniş olduğu için security policy dikkatli olmalıdır. Managed certificate hizmetleri bazı riskleri azaltabilir.

Certificate Renewal

Certificate renewal tamamen otomatik hale getirilebilir. DNS veya HTTP challenge yönteminin migration sırasında çalışmaya devam ettiği doğrulanmalıdır. Secondary domain redirect server kaldırılmasa bile certificate renewal pipeline korunmalıdır. Renewal failure alarm üretmelidir. Certificate expiry tarihini yalnız takvim hatırlatıcısına bırakmak kurumsal sistem için yeterli değildir.

Certificate Monitoring

External monitoring gerçek kullanıcı gibi TLS handshake yapmalıdır. Expiry days, hostname match ve chain errors izlenebilir. Canonical ve secondary host ayrı test edilir. Certificate deployment sonrası eski edge node'larda stale certificate kalıp kalmadığı kontrol edilebilir. Alarm security ve platform ekibine yönlendirilmelidir.

Redirect Veren Secondary Host Neden SSL Sertifikasına İhtiyaç Duyar?

HTTPS bağlantısında browser önce TLS handshake gerçekleştirir ve ancak bağlantı güvenli biçimde kurulduktan sonra HTTP request gönderir. Serverın 301 veya 308 redirect vermesi bu handshake işleminden sonra gerçekleşir. Certificate invalid ise browser kullanıcıyı güvenlik hatasıyla durdurabilir ve Location response hiç görülmez. Bu nedenle “bu domain zaten sadece redirect oluyor” gerekçesi certificate'i kaldırmak için geçerli değildir. Özellikle eski hostu yıllarca redirect tutan kurumsal siteler certificate lifecycle'ını da aynı süre boyunca sürdürmelidir.

TLS Handshake

TLS handshake server identity ve encryption parametrelerini doğrular. Browser hostname ile certificate içindeki isimlerin uyuşmasını bekler. Doğrulama başarısızsa normal HTTP request aşamasına geçilmeyebilir. Bu işlem redirect logic'ten önce gerçekleşir. Monitoring synthetic browser veya TLS client ile doğrudan secondary hostname'i test etmelidir.

HTTPS Request

TLS bağlantı kurulduktan sonra client HTTP request gönderir. Host header secondary hostname'i içerir. Edge veya server bunu görüp redirect rule çalıştırır. Location final canonical URL'yi gösterir. Bu sıra certificate'in neden redirectten önce gerekli olduğunu açıklar.

Redirect Response

Server 301, 308 veya başka redirect statusuyla response döndürür. Location header hedef URL'yi belirtir. Browser ardından yeni URL'ye başka request yapar. Redirect host sadece birkaç byte response üretse bile bu noktaya ulaşmak için TLS tamamlanmış olmalıdır. Certificate availability redirect SLO'nun parçasıdır.

Certificate Hatası Olursa Kullanıcı Redirect’i Görebilir mi?

Normal browser davranışında certificate doğrulama problemi HTTP redirectten önce kullanıcıya gösterilir. Kullanıcı güvenlik warning ekranıyla karşılaşabilir. HSTS aktifse certificate hatasını bypass etme imkânı daha da sınırlı olabilir. Bu nedenle secondary certificate failure gerçek availability incidentıdır. Eski backlink traffic hâlâ bu hostname'i kullanıyorsa business etkisi oluşabilir.

HSTS Nedir?

HSTS browsera belirli host için yalnız HTTPS kullanması gerektiğini bildiren Strict Transport Security mekanizmasıdır. Server HTTPS response üzerinde Strict-Transport-Security header gönderir ve browser max-age süresi boyunca HTTP requestleri otomatik olarak HTTPS'e yükseltir. includeSubDomains ve preload gibi seçenekler kapsamı önemli ölçüde genişletebilir. Bu nedenle HSTS yalnız güvenlik headerı değil domain mimarisi kararıdır. Bütün subdomainler HTTPS hazır olmadan geniş kapsamlı policy etkinleştirilmemelidir.

Strict-Transport-Security

Strict Transport Security HTTPS response headerıdır. Browser domainin sadece güvenli bağlantıyla kullanılmasını öğrenir. HTTP URL girilse bile subsequent request browser tarafından HTTPS'e upgrade edilir. Header HTTP response üzerinden güvenilir biçimde öğrenilmez. İlk ziyaret riski preload gibi ek mekanizmalarla azaltılabilir.

HTTP → HTTPS Zorlaması

Normal redirect server tarafında HTTP request aldıktan sonra HTTPS Location döndürür. HSTS öğrenilmişse browser bu HTTP requesti networke göndermeden HTTPS'e yükseltebilir. Bu hem security hem latency açısından faydalıdır. Ancak ilk kez gelen veya HSTS kaydı expire olmuş client için HTTP redirect yine önemlidir. Bu nedenle port 80 behavior doğru kalmalıdır.

max-age

max-age browserın HSTS policy'yi kaç saniye hatırlayacağını belirtir. Çok uzun değer production rollback esnekliğini azaltabilir. İlk rollout kısa süreyle başlayıp doğrulama sonrası artırılabilir. Header yanlış hostta etkinleştirilirse kullanıcı erişim problemi uzun süre devam edebilir. Security ekibi value standardını merkezi policy ile yönetmelidir.

includeSubDomains

includeSubDomains parent host altında bulunan subdomainlere HSTS kapsamını genişletir. MDN bu directive'in ilgili host altındaki subdomain requestlerini de HTTPS'e yükselttiğini açıklar. Eski HTTP-only servis varsa bu seçenek onu erişilemez hale getirebilir. Subdomain inventory tamamlanmadan enable edilmemelidir. Third party delegated subdomainler de incelemeye dahil edilmelidir.

preload

HSTS preload browserların siteyi daha ilk bağlantıdan HTTPS olarak bilmesini amaçlar. Preload listesine girmek uzun süreli ve geniş kapsamlı commitment olarak değerlendirilmelidir. Bütün ilgili subdomain ve redirect davranışları önceden test edilmelidir. Yanlış configuration rollback'i normal header değişikliğinden daha yavaş olabilir. Security ve domain owner birlikte onay vermelidir.

HSTS ile WWW / Non-WWW Tasarımı

HSTS policy hostname hiyerarşisine göre davranır ve www ile apex kararından etkilenebilir. Apex üzerinde includeSubDomains etkinleştirmek www dahil bütün alt hostları kapsayabilir. WWW üzerinde aynı directive yalnız www altındaki daha derin hostları etkiler, sibling app veya api hostlarını kapsamaz. Bu nedenle HSTS tasarımı yalnız ana web sitesi üzerinden düşünülmemelidir. Domain inventory, certificate coverage ve legacy services birlikte incelenmelidir.

Apex Üzerindeki HSTS

Apex host HTTPS response üzerinde HSTS gönderebilir. includeSubDomains yoksa policy esas olarak apex hostu için geçerlidir. includeSubDomains eklendiğinde www ve diğer subdomainler de kapsam içine girer. Bu geniş etki production readiness gerektirir. HSTS header farklı edge locationlarda aynı olmalıdır.

WWW Üzerindeki HSTS

WWW host HSTS policy uygulayabilir. Bu policy apex sibling değildir ve example.com'u otomatik olarak aynı kapsamda ele almaz. Browser policy host hierarchy kurallarına göre çalışır. Secondary non-www hostun kendi HTTPS ve HSTS behavior'ı ayrıca test edilmelidir. Preferred host seçimi HSTS deployment planıyla birlikte yapılmalıdır.

includeSubDomains Etkisi

includeSubDomains güvenliği güçlendirebilir fakat blast radius'u genişletir. Legacy intranet veya third party subdomain HTTP kullanıyorsa erişim kesilebilir. DNS inventory bütün delegated zones dahil incelenmelidir. Certificate ve HTTPS readiness automated crawler ile test edilebilir. Ancak bütün sonuçlar başarılı olduktan sonra policy genişletilmelidir.

Bütün Subdomainlerin HTTPS Hazır Olması

App, API, auth, help ve diğer public hostname'ler geçerli TLS sertifikasına sahip olmalıdır. HTTP-only servis migrationdan önce düzeltilmelidir. Third party vendor custom domain destekliyorsa HTTPS davranışı doğrulanmalıdır. Staging veya forgotten hostname inventoryde görünmelidir. Security scan bütün active DNS records üzerinde çalıştırılabilir.

HSTS Preload Öncesi Kontrol

Preload kararı geri dönüşü zor bir domain policy olarak ele alınmalıdır. HTTPS bütün subdomainlerde test edilmelidir. Redirect chain ve certificate errors sıfır olmalıdır. DNS ownership ve future subdomain creation process hazırlanmalıdır. Change management ve emergency procedure documentation tamamlanmalıdır.

WWW / Non-WWW ve Cookie Yönetimi

Cookie scope hostname migrationında session ve authentication davranışını doğrudan etkileyebilir. Host only cookie yalnız set edildiği hosta gönderilirken Domain attribute daha geniş subdomain kapsamı oluşturabilir. Preferred host değiştiğinde eski hostta set edilmiş cookie yeni hostta görünmeyebilir. Bu bazen güvenlik açısından olumlu temizlik sağlar, bazen kullanıcıların logout olmasına yol açar. Migration QA gerçek browser sessionlarıyla yapılmalıdır.

Host-Only Cookie

Domain attribute belirtilmeden set edilen cookie host only davranır. Cookie yalnız set edildiği hostname'e gönderilir. Bu scope minimization güvenlik açısından faydalıdır. WWW'den non-www'ye geçişte eski www cookie yeni apex hostta otomatik görünmeyebilir. Session migration strategy kullanıcı deneyimine göre planlanmalıdır.

Domain Cookie

Domain attribute cookie'yi parent domain kapsamına genişletebilir. Böylece birden fazla subdomain aynı cookie'yi alabilir. Bu özellik shared authentication için kolaylık sağlasa da gereksiz servislerin credential taşımasına neden olabilir. Sensitive session cookie mümkün olduğunca dar scope kullanmalıdır. Domain migration eski cookie temizleme veya expiration planı gerektirebilir.

Subdomainlere Cookie Yayılımı

Cookie bütün subdomainlere yayıldığında app, help veya başka servisler de headerı alabilir. Bu hem request size hem security surface büyütür. Her subdomain aynı güven seviyesinde olmayabilir. Shared cookie gerçekten gerekiyor mu architecture review'da sorgulanmalıdır. Modern auth flow token veya redirect bazlı farklı yöntemler kullanabilir.

Authentication Cookie

Authentication cookie Secure, HttpOnly ve uygun SameSite ayarlarını kullanmalıdır. Preferred host migration session domainini değiştirebilir. Kullanıcıların yeniden login olması kabul edilebilir mi business kararıdır. SSO callback ve cookie domain birlikte test edilmelidir. Rollback durumunda eski ve yeni session coexistence etkisi değerlendirilmelidir.

Analytics Cookie

Analytics platformları cookie domainini otomatik veya manuel belirleyebilir. Host migration visitor identity continuity üzerinde etkili olabilir. Measurement plan migration öncesi baseline almalıdır. Cross subdomain tracking gerekiyorsa configuration tekrar doğrulanmalıdır. Privacy ve consent policy yeni hostname standardına göre güncellenmelidir.

Cookie Scope Minimizasyonu

Least privilege yalnız API permission için değil cookie scope için de uygulanabilir. Cookie sadece gerektiği host ve path'e gönderilmelidir. Shared parent domain cookie yerine host specific session tercih edilebilir. Bu karar XSS veya subdomain compromise etkisini azaltabilir. Domain architecture güvenlik ekibiyle birlikte değerlendirilmelidir.

__Host- Cookie Yaklaşımı

__Host prefix kullanılan cookie'ler daha dar güvenlik kurallarıyla ilişkilidir. Domain attribute kullanılmaması, Secure gereksinimi ve root path gibi şartlar cookie'nin belirli hosta bağlı olmasını sağlar. Bu yaklaşım session fixation veya sibling subdomain etkisini azaltmaya yardımcı olabilir. Preferred host migration sırasında yeni hostname yeni __Host cookie üretir. Çoklu subdomain authentication architecture'sında merkezi SSO ve host specific sessionlar birlikte değerlendirilebilir.

Host'a Bağlı Cookie

__Host cookie belirli host sınırında kalmayı amaçlar. Parent domain tarafından sibling hostlara yayılamaz. Bu özellik compromise olmuş daha az güvenilir subdomainin ana site session cookie'sini set etme riskini azaltabilir. Auth design host migration kararından önce incelenmelidir. Session continuity gerekiyorsa controlled reauthentication flow kullanılabilir.

Secure

__Host prefix Secure attribute gerektirir. Cookie yalnız HTTPS bağlantılarında gönderilir. Bu HSTS ve HTTPS-only site tasarımıyla uyumludur. Local development için farklı cookie policy gerekebilir. Production config environment bazlı automated testlerle doğrulanmalıdır.

Domain Attribute Kullanılmaması

Domain attribute olmaması cookie'yi host only yapar. Böylece sibling subdomainlere otomatik yayılmaz. Bu durum shared session ihtiyacını farklı architecture ile çözmeyi gerektirebilir. OAuth veya central auth redirect modeli kullanılabilir. Security kazancı convenience ile birlikte değerlendirilmelidir.

Session Security

Session cookie domain scope attack surface üzerinde doğrudan etkilidir. HttpOnly ve SameSite gibi diğer attribute'lar da birlikte düşünülmelidir. Host migration sırasında session invalidation güvenli default olabilir. Kullanıcı deneyimi için graceful login redirect sağlanabilir. Security monitoring eski hostta beklenmeyen session cookie üretimini alarm olarak yakalayabilir.

Çoklu Subdomain Sistemlerinde Kullanım

App ve admin gibi yüksek riskli hostlar ayrı session cookie kullanabilir. Central auth server kısa süreli authorization flow ile login sağlayabilir. Böylece parent domain cookie paylaşımı gerekmeyebilir. WWW veya non-www seçimi bu modelde daha az kritik hale gelir. Architecture identity boundary'lerini hostname isimlendirmesinden bağımsız açık biçimde tanımlamalıdır.

Kurumsal Subdomain Mimarisi

Büyük şirketlerde ana web sitesi domain ekosisteminin yalnız bir parçasıdır. App, API, auth, admin, static, support ve developer portal gibi farklı hostname'ler farklı security ve availability gereksinimlerine sahiptir. Preferred host kararı bu ekosistemin tamamıyla uyumlu olmalıdır. Cookie, HSTS, certificate ve CORS policy subdomain inventory üzerinden tasarlanmalıdır. Yeni hostname açma süreci DNS as Code ve central approval ile standardize edilebilir.

WWW

WWW ana marketing veya corporate website için kullanılabilir. Public content, SEO ve branding burada yönetilir. Diğer operational servislerden ayrı hostname olması monitoringi kolaylaştırır. Canonical site www ise apex secondary redirect verir. Certificate ve CDN policy bu role göre düzenlenir.

App

App authenticated product interface olabilir. SEO indexlenmesi genellikle gerekli değildir. Authentication cookie ve CSP ana marketing siteden farklı olabilir. Same origin varsayımları açıkça test edilmelidir. Preferred corporate host migration app hostname'i değiştirmek zorunda değildir.

API

API host machine clients tarafından kullanılır. Redirect takip davranışı browserdan farklı olabilir. POST veya PUT method preservation kritik olduğu için hostname migration daha risklidir. Client configuration doğrudan final API hostname'e güncellenmelidir. 308 gerekiyorsa compatibility test edilmelidir.

Auth

Auth hostname SSO ve OAuth callback flow'un merkezinde olabilir. Certificate ve availability çok kritiktir. Cookie scope mümkün olduğunca dar tutulmalıdır. Main www migration callback URL'leri etkileyebilir. Identity provider allowlist güncellemesi deployment öncesi yapılmalıdır.

Admin

Admin interface daha yüksek security standardı gerektirir. Public DNS veya network exposure sınırlı olabilir. Ana site cookie'leri admin hosta gereksiz gönderilmemelidir. Separate authentication ve MFA kullanılabilir. HSTS includeSubDomains admin hostu da etkileyebileceği için HTTPS readiness zorunludur.

CDN / Static

Static asset host cookie-free veya farklı cache policy ile çalışabilir. Domain cookie kullanımı gereksiz header taşımasına neden olabilir. CSP allowed source listesi bu hostname'i içerir. Main host migration absolute asset URL'leri etkileyebilir. Versioned asset domain changes long cache TTL nedeniyle dikkatli yönetilmelidir.

Help / Support

Help veya support sitesi third party platformda barındırılabilir. Custom domain certificate ve DNS provider tarafından yönetilebilir. HSTS includeSubDomains parent policy bu hostu da HTTPS'e zorlar. Search canonical behavior third party platformda ayrıca kontrol edilmelidir. Migration sırasında vendor custom domain settings güncellenmelidir.

Careers

Careers subdomain external recruitment platformuna işaret edebilir. SEO ve user tracking gereksinimi ana siteden farklı olabilir. Cookie yayılımı sınırlandırılmalıdır. Third party certificate ve callback behavior test edilmelidir. Structured data URL'leri preferred company host policy ile uyumlu tutulabilir.

Developer Portal

Developer portal docs, API key management veya SDK bilgisi sunabilir. Search traffic alabileceği için canonical ve sitemap standardına ihtiyaç duyar. API hostname ile karıştırılmamalıdır. Authentication gerekiyorsa session boundary belirlenmelidir. Main domain migration documentation internal linksini etkileyebilir.

Preferred Host Seçimi Subdomainleri Nasıl Etkiler?

Preferred host seçimi sibling subdomainleri doğrudan değiştirmek zorunda değildir, ancak shared policies üzerinden onları etkileyebilir. Cookie Domain attribute, HSTS includeSubDomains, CSP, CORS ve authentication settings bunların başında gelir. DNS zone ve certificate automation da ana host migrationından etkilenebilir. Bu nedenle hostname değişikliği yalnız SEO checklist ile yönetilmemelidir. Platform ve security ekipleri bütün domain tree üzerinde impact analysis yapmalıdır.

Cookie Scope

Parent domain cookie bütün sibling hostlara yayılabilir. Ana site www'den apex'e geçtiğinde cookie set behavior değişebilir. Host only cookie ise yeni hostname'de yeni session gerektirebilir. Migration plan cookie inventory içermelidir. Browser QA farklı login durumlarında yapılmalıdır.

DNS

Apex ve www farklı record türleri kullanabilir. CDN target değişimi DNS configurationa yansır. TTL migration öncesi kontrollü düşürülebilir. DNSSEC ve CAA gibi security records etkilenmemelidir. Rollback için old target configuration saklanmalıdır.

TLS

Yeni canonical host certificate kapsamında olmalıdır. Eski host redirect süresince certificate korur. Wildcard ve SAN coverage kontrol edilmelidir. Automated issuance DNS changesle uyumlu olmalıdır. Certificate monitoring bütün public hostları kapsamalıdır.

CORS

Browser origin scheme, hostname ve port kombinasyonuna bağlıdır. WWW ile non-www farklı origin kabul edilir. API allowed origin listesi migration öncesi yeni hostname'i içermelidir. Eski origin bir süre transitional allowlistte kalabilir. Security policy gereksiz legacy originleri daha sonra kaldırmalıdır.

CSP

CSP source listelerinde absolute host değerleri bulunabilir. Main site host migration script, image veya frame policy'sini etkileyebilir. report-uri veya report-to endpointleri de kontrol edilmelidir. Inline config ve third party dashboard settings inventory içine alınmalıdır. CSP violation monitoring migration QA sırasında faydalıdır.

Authentication

SSO provider redirect URI hostname'e bağlıdır. Callback exact match gereksinimi sık görülür. Yeni preferred host provider config'e eklenmeden login flow bozulabilir. Session cookie ve logout return URL de güncellenmelidir. Authentication migration end-to-end browser testi gerektirir.

Analytics

Analytics property ve hostname filters yeni preferred hostu tanımalıdır. Referral exclusion veya cross domain settings kontrol edilmelidir. Migration date annotation raporlara eklenebilir. Old host hitleri ayrı segmentte izlenebilir. Data continuity business reporting için önemlidir.

Canonical Tag WWW / Non-WWW Yapısında Nasıl Kullanılmalı?

Canonical tag sayfanın tercih edilen temsilci URL'sini belirtir. WWW veya non-www standardı seçildiyse bütün self canonical etiketleri preferred HTTPS hostu kullanmalıdır. Canonical başka bir redirect URL'ye değil doğrudan 200 final URL'ye gitmelidir. Google canonical annotation'ı önemli sinyallerden biri olarak değerlendirir, ancak nihai canonical seçimini kendisi yapabilir. Bu nedenle canonical tek başına secondary hostu açık bırakmanın yerine geçmemelidir.

Self-Referencing Canonical

Canonical page kendi URL'sini canonical olarak gösterebilir. Bu template consistency sağlar. Query parameter veya alternate host gibi varyasyonların hangi final URL'ye ait olduğunu açıklar. Dynamic pages canonical generation test edilmelidir. Host value request Host headerdan değil trusted site configurationdan alınmalıdır.

Absolute Canonical URL

Canonical URL absolute biçimde scheme ve hostname içermelidir. Böylece preferred HTTPS host açıkça belirtilir. Relative canonical interpretation riskini azaltır. Environment config staging hostun production canonicala yanlış çıkmasını önlemelidir. CI HTML sample'larında canonical hostname assertion yapabilir.

Preferred Host Kullanımı

Bütün canonical etiketler seçilmiş hostu kullanmalıdır. WWW migration sırasında eski host canonical'ları aynı release'te güncellenmelidir. Partial deployment çelişkili sinyal oluşturabilir. Sitemap ve internal links de aynı zamanda değişmelidir. Google selected canonical Search Console üzerinden izlenmelidir.

Canonical'ın Redirect URL'ye Gitmemesi

Canonical target ideal olarak doğrudan 200 response vermelidir. Eğer canonical URL 301 ile başka hosta gidiyorsa iki farklı tercih sinyali oluşur. Automated crawler canonical targets status kodlarını kontrol edebilir. Redirect target değiştiğinde canonical template hemen güncellenmelidir. Bu quality gate büyük sitelerde binlerce yanlış işareti önler.

Template Seviyesinde Canonical

Canonical generation merkezi template veya SEO component üzerinden yapılmalıdır. Farklı ekiplerin manual hostname yazması drift oluşturur. Preferred host configuration environment variable veya central config olabilir. Test suite page type bazında canonical outputu doğrular. CMS editorların hostname'i keyfi değiştirmesi sınırlandırılabilir.

Redirect mi Canonical mı?

Redirect ve canonical farklı görevler yapar. Redirect kullanıcı ve crawlerı başka URL'ye fiziksel olarak taşır. Canonical ise içerik varyasyonları arasında tercih edilen temsilci adresi bildirir. Kalıcı www veya non-www consolidation durumunda redirect daha doğrudan çözümdür. Canonical final sayfada bu kararı destekleyerek URL sinyallerini tutarlı hale getirir.

Kullanıcıya Açık Duplicate Host

İki host da 200 içerik sunuyorsa kullanıcı farklı URL'lerde aynı sayfayı görebilir. Bu analytics ve cache tarafında da duplication oluşturur. Canonical arama motoruna tercih bildirir, fakat kullanıcı hâlâ secondary hostta kalır. Permanent redirect bu problemi kökten çözer. Bu nedenle host consolidationda yalnız canonical yeterli yaklaşım değildir.

Kalıcı Host Konsolidasyonu

Kalıcı karar secondary hostun artık content origin olarak kullanılmamasıdır. 301 veya uygun permanent redirect bunu açık biçimde ifade eder. Internal links yeni URL'ye güncellenir. Sitemap eski hostu bırakır. Redirect uzun süre korunarak external traffic kaybı önlenir.

Redirect'in Rolü

Redirect clienta resource'un başka URL'de olduğunu söyler. Kullanıcı final URL'yi browserda görür. Crawler yeni adresi ziyaret eder. Permanent status migration sinyalini güçlendirir. Path mapping doğru değilse redirect faydadan çok hata üretebilir.

Canonical'ın Rolü

Canonical benzer veya duplicate content içinde representative URL tercihidir. Filter pages veya tracking parameters gibi redirect uygulanamayan varyasyonlarda kullanışlıdır. Host migrationda redirect ile birlikte final pages üzerinde self canonical kullanılabilir. Google canonical preference'ı hint olarak değerlendirir ve farklı seçim yapabilir. Bu nedenle diğer sinyallerin de aynı yönde olması önemlidir.

İkisini Tutarlı Kullanmak

Secondary host redirect final URL'ye gitmelidir. Final URL self canonical göstermelidir. Sitemap final URL'yi içermelidir. Internal links doğrudan final URL'ye gitmelidir. Bu dört sinyal aynı olduğunda canonicalization architecture daha anlaşılır hale gelir.

XML Sitemap Hangi Hostu Kullanmalı?

XML sitemap yalnız indexlenmesini istediğiniz canonical URL'leri listelemelidir. WWW preferred ise sitemap bütün URL'lerde HTTPS www kullanmalıdır. Non-www preferred ise aynı standard ters yönde uygulanır. Redirect URL'leri sitemap içinde tutmak crawlera gereksiz iş verir ve çelişkili signal oluşturur. Migration sonrası sitemap yeniden üretilip Search Console üzerinden takip edilmelidir.

Sadece Canonical URL'ler

Sitemap indexlenmesini istediğiniz final sayfaların envanteridir. 301 veren URL'ler buraya eklenmemelidir. Canonical olmayan query variantları da mümkün olduğunca çıkarılmalıdır. Page status düzenli crawler ile doğrulanabilir. Sitemap generation data source application routing standardıyla uyumlu olmalıdır.

WWW / Non-WWW Tutarlılığı

Sitemap hostname'i preferred host policy ile aynı olmalıdır. Mixed hostname büyük sitelerde migration sonrası sık görülür. Generator cache veya legacy database field buna neden olabilir. Automated validation bütün loc değerlerini regex veya URL parser ile kontrol edebilir. Yanlış host bulunursa deployment veya sitemap publish işlemi durdurulabilir.

HTTPS Tutarlılığı

Canonical site HTTPS ise sitemap HTTP URL içermemelidir. Protocol migration tamamlandıktan sonra bütün loc değerleri güncellenmelidir. Asset veya image sitemap ayrı kontrol edilmelidir. Redirect HTTP URL'yi düzeltse de sitemap doğrudan final secure URL kullanmalıdır. Bu yaklaşım crawler requestlerini azaltır.

Redirect URL'leri Sitemap'ten Çıkarmak

Redirect URL sitemapte bulunuyorsa crawler her seferinde gereksiz 3xx takip eder. Migration mapping tamamlandığında generator canonical source'dan veri almalıdır. Old sitemap bir süre erişilebilir kalabilir, ancak yeni content sitemap final URLs kullanmalıdır. Search Console sitemap report errors izlenmelidir. Redirecting loc oranı monitoring metric olabilir.

Sitemap Index

Büyük siteler birden fazla sitemapı index dosyasıyla gruplayabilir. Index ve child sitemap URL'leri preferred host üzerinde bulunmalıdır. Host migration bütün sitemap references'ı aynı anda güncellemelidir. Old host sitemap requests redirect verebilir. Ancak internal references mümkün olduğunca direct final URLs olmalıdır.

Internal Linkler Hangi Hostu Kullanmalı?

Internal linkler her zaman mümkün olduğunca doğrudan canonical URL'yi kullanmalıdır. Redirect üzerinden link vermek kullanıcıya görünmese bile gereksiz request ve crawl maliyeti oluşturur. Navigation, footer, breadcrumb ve CTA componentleri merkezi URL helper kullanmalıdır. Migration sırasında content database içindeki hardcoded eski hostname'ler ayrıca taranmalıdır. Internal link audit eski host kullanım oranını ölçerek cleanup progress gösterebilir.

Navigation

Main navigation bütün kullanıcıların tekrar tekrar tıkladığı yüksek hacimli link alanıdır. Burada eski hostname kalması milyonlarca redirect request oluşturabilir. Menu configuration preferred hosta güncellenmelidir. Relative links bazı durumlarda hostname migrationını kolaylaştırabilir. Absolute link gerekiyorsa central URL builder kullanılmalıdır.

Footer

Footer corporate, privacy ve contact linklerini içerir. CMS template değişmeden legacy host uzun süre kalabilir. Migration QA her template sectionı taramalıdır. Footer linkleri final canonical targeta doğrudan gitmelidir. Multi language site footerları ayrı kontrol edilmelidir.

Breadcrumb

Breadcrumb hem kullanıcı hem structured data içinde URL üretebilir. Visible link ve JSON LD aynı host standardını kullanmalıdır. Category path migration sırasında hardcoded hostname bırakmamalıdır. Breadcrumb component central routing config'e bağlanabilir. Search crawler rendered HTML üzerinde kontrol yapmalıdır.

Blog İç Linkleri

Yıllar içinde yazılmış blog content binlerce absolute old host linki içerebilir. Bulk metadata veya content update araçlarıyla bu URL'ler bulunup canonical targeta çevrilebilir. Bu tür toplu düzenleme mantığı için https://www.diyarbakiryazilim.com.tr/posts/e-tablo-formulleriyle-satir-bagimsiz-toplu-meta-veri-duzenleme adresindeki yaklaşım farklı veri temizleme senaryolarında fikir verebilir. Update öncesi backup ve sample review yapılmalıdır. Redirect devam etse bile dahili eski linkler zamanla tamamen temizlenmelidir.

CTA

CTA linkleri campaign ve conversion flow için kritiktir. Eski host redirecti attribution parametrelerini korumalıdır. Marketing componentleri preferred hosta güncellenmelidir. UTM query string kaybı test edilmelidir. Conversion tracking migration öncesi ve sonrası karşılaştırılmalıdır.

Structured Content

CMS block veya rich text fieldları absolute URL saklayabilir. Search and replace körü körüne uygulanmamalıdır, çünkü external URL veya code sample değişebilir. URL parser tabanlı migration script daha güvenlidir. Content revision history tutulmalıdır. QA sample farklı page types üzerinden yapılmalıdır.

Doğrudan Canonical URL

Internal link final 200 canonical URL'ye gitmelidir. Bu basit kural crawl architecture'ı sadeleştirir. Redirect log volume zamanla external traffic ağırlıklı hale gelir. Internal redirect ratio SLO olarak izlenebilir. Yeni development pull requestleri eski hostname string'i içerirse static check uyarı verebilir.

Preferred Host Tutarlılık Formülü

Preferred host standardını basit bir formülle düşünmek faydalıdır: redirect target, self canonical, sitemap URL, internal link, hreflang, structured data ve social URL aynı hostname'i göstermelidir. Bu alanlardan biri farklı olduğunda teknik sinyaller ayrışmaya başlar. Büyük kurumlarda farklı ekipler bu katmanları yönettiği için merkezi policy gerekir. Automated crawler her URL'de bu değerleri karşılaştırabilir. Kurumsal Domainlerde WWW ve Non-WWW Yönlendirme Analizi sırasında en güçlü kalite kontrolü bu tutarlılığı ölçmektir.

Redirect Target

Secondary host final canonical URL'ye gider. Intermediate redirect bulunmamalıdır. Path mapping korunur. Status permanent olmalıdır. Broken target monitoring ile yakalanır.

Self-Canonical

Final page canonical olarak kendisini gösterir. URL HTTPS ve preferred host kullanır. Canonical target 200 döner. Template bütün page types için aynı standardı üretir. Google selected canonical belirli samplelarda kontrol edilir.

Sitemap URL

Sitemap final canonical URL'yi listeler. Redirect veya alternate host içermez. Lastmod gerçekten değişiklik tarihini temsil ediyorsa kullanılır. Sitemap index aynı hostname üzerinde bulunur. Validation deployment pipeline'a bağlanabilir.

Internal Link

Internal link kullanıcıyı doğrudan final URL'ye götürür. Navigation ve content aynı standarda uyar. Hardcoded old hostname düzenli taranır. Relative ve absolute URL strategy documentation içinde tanımlanır. Redirect üzerinden çalışan internal link technical debt kabul edilir.

Hreflang

Hreflang alternate language URL'leri preferred host kullanmalıdır. Return links tutarlı olmalıdır. Canonical ve hreflang birbirini desteklemelidir. Migration sonrası eski hostname references temizlenir. x-default aynı standard içinde güncellenir.

Structured Data

Organization, WebSite, Article ve Breadcrumb URL değerleri canonical hostname'i kullanmalıdır. Schema generator merkezi config'ten URL üretmelidir. Migration sırasında rendered JSON LD taranmalıdır. Image URLs ayrı CDN domain kullanabilir, fakat entity page URLs preferred host standardına uyar. Validation tool sample pages üzerinde çalıştırılabilir.

Open Graph

og:url social paylaşım için canonical URL'yi gösterebilir. Migration sonrası eski hostname bırakılmamalıdır. Cache'lenen social previews zamanla güncellenebilir. Twitter card veya benzer metadata aynı URL standardını takip eder. Social campaign destination URLs ayrıca inventory içinde güncellenmelidir.

Hepsinin Aynı Hostu Kullanması

Tutarlılık arama motorlarının site architecture'ını anlamasını kolaylaştırır. Analytics ve user sharing de tek URL etrafında birleşir. Farklı ekiplerin kendi hostname tercihlerini uygulaması engellenir. Central config ve linting bu standardı otomatikleştirebilir. Migration tamamlandığında eski host yalnız external legacy traffic için redirect service olarak kalmalıdır.

Hreflang ve WWW / Non-WWW

Çok dilli veya çok bölgeli sitelerde hreflang URL'leri de hostname migrationından etkilenir. Hreflang alternate URLs canonical host standardını kullanmalıdır. Eski host referansı kalırsa crawler önce redirect takip etmek zorunda kalır ve signal seti dağılır. Migration planı bütün language ve region page mappinglerini kapsamalıdır. Google canonicalization rehberi localized variants için canonical ve hreflang kullanımının birlikte değerlendirilmesini açıklar.

Hreflang URL'lerinin Canonical Host Kullanması

Her hreflang href final 200 URL olmalıdır. Redirect target veya old hostname kullanılmamalıdır. Language template central URL builder kullanabilir. Alternate pages birbirine reciprocal link vermelidir. Automated crawler missing return link ve host mismatch raporlayabilir.

Çok Dilli Site

Türkçe, İngilizce ve diğer dil URL'leri aynı preferred host policy'ye bağlanabilir. Dil path veya subdomain architecture ayrıca değerlendirilir. Host migration bütün language versionsı birlikte kapsamalıdır. Bir dil eski hostta kalırsa canonical cluster davranışı karışabilir. Search Console performance language segmentleriyle takip edilebilir.

Çok Bölgeli Site

Region-specific content country path, subdomain veya ccTLD kullanabilir. Ana corporate hostname migration her property için aynı anlama gelmeyebilir. Region ownerlarla inventory çıkarılmalıdır. Canonical ve hreflang relation korunmalıdır. Staged rollout country traffic impactini izlemeyi kolaylaştırabilir.

x-default

x-default kullanıcı dili eşleşmediğinde fallback URL belirtmek için kullanılabilir. Bu URL de canonical host standardına uymalıdır. Migration sonrası eski hostname kalmamalıdır. Geo veya language selector page 200 final URL olmalıdır. Redirect chain hreflang debuggingini zorlaştırır.

Host Migration Sonrası Güncelleme

Hreflang generator yeni preferred hostu kullanmalıdır. Existing static XML veya database fields güncellenmelidir. Crawl sample old host references için taranabilir. Search Console international performance migration öncesi baseline ile karşılaştırılır. Redirect eski hreflang URL'leri korusa da source kodu final URL'ye güncellenmelidir.

Structured Data İçindeki Hostname

Structured data JSON LD veya diğer formatlarda absolute URL'ler içerir. Host migration yalnız visible links değil bu machine-readable referansları da güncellemeyi gerektirir. Organization ve WebSite entity URL'leri preferred hosta taşınmalıdır. Breadcrumb item URL'leri final canonical pages olmalıdır. Eski hostname references automated source scan ile bulunabilir.

Organization URL

Organization entity URL ana kurumsal siteyi göstermelidir. Preferred host değişirse bu alan güncellenir. sameAs external profile listesi host migrationdan etkilenmeyebilir. Logo URL ayrı asset domain kullanabilir. Structured data generator central site config'ten hostname almalıdır.

WebSite URL

WebSite entity URL canonical homepage'i göstermelidir. Secondary redirect host kullanılmamalıdır. SearchAction veya diğer nested URLs yeni hosta göre kontrol edilir. Home page canonical ile aynı standard tercih edilir. Validation deployment sonrası rendered output üzerinde yapılır.

Article URL

Article veya BlogPosting entity mainEntityOfPage gibi alanlarda canonical page URL kullanabilir. Migration sırasında old absolute hostname temizlenmelidir. CMS schema plugin eski site URL cache'i tutabilir. Cache purge ve template update birlikte yapılmalıdır. Sample article pages automated testten geçirilmelidir.

Breadcrumb

BreadcrumbList item URLs final path ve hostname'i göstermelidir. Visible breadcrumb linkleriyle tutarlı olmalıdır. Old host redirect üzerinden çalışsa bile schema doğrudan canonical kullanmalıdır. Category migration mapping doğru uygulanmalıdır. Search console enhancement reportları değişim sonrası izlenebilir.

ImageObject

ImageObject URL'leri asset host veya CDN domain kullanabilir. Preferred page hostname migration image CDN'i değiştirmek zorunda değildir. Ancak image page veya contentUrl yanlışlıkla old web hosta bağlıysa kontrol edilmelidir. HTTPS ve certificate consistency korunmalıdır. Asset migration ayrı project olarak değerlendirilmelidir.

Eski Host Referanslarını Temizlemek

Repository, database ve rendered HTML içinde old hostname araması yapılabilir. JSON LD stringleri özellikle gözden kaçabilir. Static scan build sırasında banned hostname listesi kullanabilir. Third party tag manager scriptleri ayrıca kontrol edilmelidir. Cleanup progress inventory tablosunda owner bazında takip edilebilir.

Open Graph ve Sosyal Paylaşım URL'leri

Sosyal paylaşım metadata'sı URL migrationından sonra güncellenmelidir. og:url canonical final URL'yi göstermesi için kullanılabilir. Eski hostname social crawler cachelerinde bir süre kalabilir. Bu SEO canonicalization kadar kritik olmasa da marka ve paylaşım tutarlılığı açısından önemlidir. Campaign tracking sistemleri preferred host standardını kullanmalıdır.

og

Open Graph metadata sosyal preview bilgilerini taşır. og:url canonical page adresi olarak preferred host kullanabilir. og:image asset hostta kalabilir. Migration sonrası CMS template cache temizlenmelidir. Social debug tool sample pages üzerinde kullanılabilir.

Twitter Cards

Twitter Card metadata page title, image ve description bilgilerini taşır. URL platform tarafından page request üzerinden de belirlenebilir. Absolute links old host içermemelidir. Share button direct final URL üretmelidir. Social traffic analytics host migration öncesi ve sonrası izlenebilir.

Social Sharing

Share component kullanıcıya canonical URL sunmalıdır. Secondary host browser address barında kalmıyorsa çoğu paylaşım zaten final URL olur. Ancak JavaScript hardcoded base URL kullanıyorsa eski hostname devam edebilir. Mobile app deep link generator ayrıca kontrol edilmelidir. URL shortener veya campaign platform integrationları inventory'e eklenmelidir.

Preferred Host Tutarlılığı

Social, SEO ve analytics URL'lerinin aynı hostname'i kullanması operasyonu sadeleştirir. Marka materyalleri tek address standardına kavuşur. User generated shares zamanla canonical host etrafında birikir. Redirect eski social posts için compatibility sağlar. Yeni campaign yaratma template'leri old hostname seçeneğini kaldırmalıdır.

Google Search Console’da WWW ve Non-WWW

Search Console domain ve URL prefix property modelleri üzerinden site performansı ve indexing davranışı izlenebilir. Domain Property bütün protocol ve subdomain varyasyonlarını daha geniş kapsamda değerlendirmek için yararlıdır. URL prefix property belirli scheme ve hostname'i ayrı incelemeye yardımcı olabilir. URL Inspection kullanıcı tarafından bildirilen canonical ile Google selected canonical farkını görmek için kullanılabilir. WWW ile non-www migration aynı domain içinde yapıldığında Google'ın Change of Address aracının gerekli olmadığını güncel site move rehberi belirtir.

Domain Property

Domain Property domainin farklı protocol ve subdomain varyasyonlarını kapsayabilir. Bu migration monitoring için geniş görünüm sağlar. DNS verification gerekir. Security ve SEO ekipleri property ownership processini merkezi yönetebilir. Legacy subdomain traffic de aynı kapsamda analiz edilebilir.

URL-Prefix Property

URL Prefix Property belirli URL başlangıcını kapsar. https://www.example.com ile https://example.com ayrı property olarak incelenebilir. Migration sırasında old ve new host performance karşılaştırması yapılabilir. Verification methodları environmenta göre değişebilir. Ownership kaybı incident investigationı zorlaştırmamalıdır.

HTTP / HTTPS Varyasyonları

HTTP ve HTTPS ayrı URL scheme'leridir. Domain Property broad görünüm sunsa da prefix property ile detay analiz yapılabilir. HTTP pages indexte kalıyorsa redirect veya canonical problemine işaret edebilir. Coverage ve inspection sampleları incelenmelidir. HSTS browser davranışı Google crawling signalının yerine geçmez, server redirect doğru kalmalıdır.

Canonical Kontrol

URL Inspection Google selected canonical bilgisini gösterebilir. User declared canonical farklıysa teknik sinyaller incelenmelidir. Redirect, sitemap, internal links ve content similarity kontrol edilir. Google'ın farklı seçim yapabileceği resmi dokümantasyonda açıkça belirtilir. Anomali tek sayfa değil page type bazında analiz edilmelidir.

URL Inspection

URL Inspection belirli URL'nin crawl ve index bilgilerini incelemeye yardımcı olur. Migration sonrası high value pages sample olarak kontrol edilebilir. Old host URL'nin redirect davranışı ve new canonical görünümü izlenir. Live test server response sorunlarını gösterebilir. Large scale kontrol crawler ve API tabanlı internal tooling ile desteklenebilir.

Migration Monitoring

Migration öncesi clicks, impressions ve indexed URL baseline kaydedilmelidir. Sonrasında old host visibility düşerken new host konsolide olmalıdır. Server log Googlebot hitlerinin hangi hosta geldiğini gösterir. Redirect errors ve canonical mismatch dashboarda eklenebilir. Geçici dalgalanma ile teknik incident birbirinden data üzerinden ayrılmalıdır.

Google Selected Canonical ile User Declared Canonical Farkı

User declared canonical site sahibinin canonical etiketiyle bildirdiği tercihtir. Google selected canonical ise Google'ın kendi sinyallerine göre seçtiği temsilci URL'dir. Bu iki değer farklıysa redirect, sitemap, internal link veya content signal arasında çelişki olabilir. Google canonical preference'ın bir hint olduğunu ve farklı URL seçebileceğini belirtir. Kurumsal audit bu farkı sayfa örnekleri ve pattern bazında incelemelidir.

Kurumun Bildirdiği Canonical

HTML rel canonical preferred host üzerindeki final URL'yi göstermelidir. CMS yanlış hostname üretiyorsa bütün site etkilenebilir. Canonical request Host headera göre dinamik değişmemelidir. Central config kullanmak daha güvenlidir. Test suite expected absolute canonical URL'yi doğrular.

Google'ın Seçtiği Canonical

Google duplicate cluster içinde kendi representative URL seçimini yapar. HTTPS, redirects, sitemap ve canonical annotation gibi sinyaller etkili olabilir. Selected canonical farklı olduğunda site sahibinin talimatı teknik olarak zorunlu uygulanmış sayılmaz. Search Console inspection investigation başlangıç noktasıdır. Content ve linking signals birlikte incelenmelidir.

Farklı Host Seçilmesinin Nedenleri

Secondary host 200 açık kalmış olabilir. Internal links yanlış hostname'e yoğun biçimde link veriyor olabilir. Sitemap ve canonical farklı hostları gösterebilir. Redirect chain veya server misconfiguration crawlerın final URL algısını bozabilir. Google troubleshooting rehberi incorrect canonical elements ve misconfigured server gibi nedenleri özellikle belirtir.

Redirect/Canonical/Sitemap Çakışmaları

Örneğin www URL 301 ile non-www'ye giderken non-www canonical tekrar www gösteriyorsa açık conflict oluşur. Sitemap www listelerse üçüncü signal da farklı davranır. Bu configuration automated audit ile kolay yakalanabilir. Final URL bütün source of truth alanlarında aynı olmalıdır. Deployment quality gate conflict varsa release'i durdurmalıdır.

Kurumsal Domainlerde WWW → Non-WWW Migration

WWW'den non-www'ye geçiş URL migrationıdır ve bütün page paths one to one mapping ile korunmalıdır. TLS, DNS ve CDN hedef apex host için production hazır hale getirilmelidir. Canonical, sitemap ve internal linkler new hostname'e güncellenmelidir. Old www host uzun süre permanent redirect vermeye devam etmelidir. Migration planı third party links ve callbacks dahil geniş inventory üzerinden yürütülmelidir.

Migration Gerekçesi

İlk adım değişikliğin neden gerekli olduğunu yazmaktır. Teknik neden yoksa migrationın yapılmaması seçenek olarak kalmalıdır. DNS ve architecture faydası ölçülebilir olmalıdır. Business owner risk ve beklenen kazanımı onaylamalıdır. Doküman gelecekte “neden değiştirdik?” sorusuna cevap verir.

URL Inventory

XML sitemap, analytics, crawl ve server loglar birleştirilerek aktif URL listesi çıkarılır. High backlink ve high traffic pages ayrıca işaretlenir. Query parameter ve legacy pathler dahil edilmelidir. Third party campaign destinations inventory'e eklenir. Mapping old www URL'den exact non-www counterparta hazırlanır.

Redirect Mapping

Her old URL mümkün olduğunca ilgili new URL'ye gider. Path aynıysa programmatic host replacement yeterli olabilir. Removed pages için relevant consolidated target belirlenir. Bütün eski URL'leri homepage'e göndermekten kaçınılmalıdır. Google site move rehberi irrelevant homepage redirects'in kullanıcıları şaşırtabileceğini ve soft 404 gibi değerlendirilebileceğini açıklar.

TLS Hazırlığı

Apex new canonical certificate migrationdan önce aktif olmalıdır. WWW redirect certificate de korunur. CDN SNI ve origin certificate configuration test edilir. HTTP ve HTTPS dört variant staging veya production dry run ile kontrol edilir. Certificate monitoring cutoverdan önce alarm üretmeye hazır olmalıdır.

Canonical Güncellemesi

New pages self canonical non-www üretir. Old host content render etmez, redirect verir. Hardcoded www canonical values database ve templates içinde temizlenir. Canonical targets 200 status verir. Search Console sample pages migration sonrası kontrol edilir.

Sitemap

Yeni sitemap yalnız non-www HTTPS URLs içerir. Sitemap index location new hosta taşınır. Old sitemap requesti redirect olabilir. Search Console new sitemapı işler. Redirect URL bulunma oranı automated validationla sıfıra yaklaştırılır.

Internal Links

Navigation ve content links direct non-www canonical URLs kullanır. Absolute www links repository ve database scan ile bulunur. Third party widgets ve tag manager config de kontrol edilir. Redirect hitlerinin önemli kısmı internal source ise cleanup devam etmelidir. Relative URLs architecturea uygunsa migration riskini azaltabilir.

Third-Party Links

Google Ads, social profiles, directory listings ve partner links zamanla new hostname'e güncellenebilir. Redirect compatibility nedeniyle hepsinin aynı gün değişmesi zorunlu değildir. High traffic sources önceliklendirilir. Payment ve OAuth gibi functional integrationlar ise cutover öncesi mutlaka update edilmelidir. Campaign tracking migration date ile annotate edilir.

Monitoring

Old www hit volume, redirect latency ve error rate takip edilir. New non-www 200 availability SLO izlenir. Search Console indexing ve canonical sampleları kontrol edilir. Analytics hostname split karşılaştırılır. Unexpected ranking veya conversion değişikliği root cause dataset ile incelenir.

Kurumsal Domainlerde Non-WWW → WWW Migration

Non-www'den www'ye geçişte aynı migration disiplinleri geçerlidir. DNS www hostu CDN veya origin'e doğru bağlamalıdır. New www certificate hazırlanmalıdır. Old apex HTTPS host valid certificate ile redirect vermeye devam etmelidir. Internal signal ve third party integrationlar final hostname'e güncellenmelidir.

Teknik Gerekçeler

CDN configuration, subdomain architecture veya operational standard www geçişini gerekçelendirebilir. Sırf marka görünümü tek başına güçlü neden olmayabilir. Migration cost ve benefit yazılı olarak değerlendirilmelidir. Legacy backlinks ve external integrations inventory çıkarılmalıdır. Business critical dönem dışında cutover planlanabilir.

DNS/CDN Hazırlığı

WWW record target CDN veya load balancer'a bağlanır. Apex secondary redirect service için doğru destinationa çözülür. TTL cutover planına göre ayarlanabilir. CDN custom domain verification önceden tamamlanmalıdır. Global DNS propagation external probes ile izlenmelidir.

SSL

WWW canonical certificate production hazır olmalıdır. Apex redirect certificate korunur. SAN veya ayrı certificates architecturea göre seçilir. Auto renewal her iki hostname için test edilir. TLS errors migration quality gate'te blocking kabul edilir.

1:1 Redirect

https://example.com/path doğrudan https://www.example.com/path adresine gider. Mapping path ve query korur. Removed content relevant new targeta yönlendirilir. Redirect targetın ikinci redirect vermediği test edilir. High traffic legacy URLs ayrı monitor edilir.

Canonical

New www pages self canonical kullanır. All page templates new hostu üretir. Old apex content response vermediği için canonical göstermesine gerek yoktur. Rendered HTML testleri bütün page typesı kapsar. Google selected canonical migration sonrası sample edilir.

Internal Links

Bütün internal absolute links www hosta taşınır. CMS content migration script kullanılabilir. Navigation ve footer componentleri central URL helper'a bağlanır. Old apex link ratio crawler ile ölçülür. Redirect üzerinden dahili trafik zamanla sıfırlanır.

Sitemap

Sitemap www HTTPS URLs kullanır. Redirect URLs çıkarılır. Search Console property monitoring new hostu kapsar. Lastmod data migration nedeniyle gereksiz güncellenmemelidir. Sitemap publish pipeline host validation yapmalıdır.

Search Console

Domain property broad monitoring sağlar. URL prefix properties old ve new host performance karşılaştırmasında yardımcı olabilir. Google www ile non-www aynı domain içindeki geçişlerde Change of Address istemediğini belirtir. URL Inspection selected canonical behaviorı kontrol etmek için kullanılabilir. Migration dashboards search data ve server logs birlikte kullanmalıdır.

WWW / Non-WWW Migration’da Redirect Chain Nasıl Önlenir?

Migration planında bütün eski varyasyonlar doğrudan final HTTPS hostname'e bağlanmalıdır. Önce eski canonical hosta, sonra yeni hosta gönderme yaklaşımı chain üretir. Redirect mapping rule mevcut scheme ve hostname ne olursa olsun tek final target hesaplayabilir. Legacy path redirectleri de mümkün olduğunca new host mapping ile birleştirilmelidir. Automated crawler launch öncesi geniş URL sample üzerinde hop count ölçmelidir.

Eski HTTP Non-WWW

Bu varyasyon hem scheme hem host değişikliği gerektirebilir. Rule final targetı doğrudan üretmelidir. Ara HTTPS non-www kullanılmamalıdır. Path ve query korunmalıdır. Response permanent olmalıdır.

Doğrudan Yeni HTTPS WWW

HTTP old request tek redirect ile HTTPS www new URL'ye gider. Final target 200 döndürür. Hop count bir olur. Server log source hostu migration metriği olarak saklar. CI bu exact flowu assertion olarak test edebilir.

Eski HTTP WWW

Eğer www yeni canonical ise yalnız scheme değişir. Fakat eski application path migration da varsa target final route olmalıdır. Intermediate legacy HTTPS page kullanılmamalıdır. Redirect mapping central service tarafından hesaplanabilir. Unknown paths güvenli 404 veya relevant mapping davranışı göstermelidir.

Doğrudan Yeni HTTPS WWW

Client tek permanent response alır. Location secure final URL'dir. Browser ikinci requestte content alır. Redirect latency düşük kalır. Internal links zaten final URL kullandığı için bu flow çoğunlukla external traffic içindir.

Eski HTTPS Non-WWW

TLS handshake old hostname certificate ile başarılı olur. Ardından permanent redirect new www hosta gönderilir. Certificate expiry bu legacy flowu bozabilir. Redirect mapping aynı path'i korur. Old host security headerları minimal redirect service standardına göre ayarlanabilir.

Doğrudan Yeni HTTPS WWW

Secondary secure host content sunmaz. Location direct final URL'yi gösterir. No intermediate www HTTP step vardır. Final target self canonicaldır. Synthetic monitor bu path'i düzenli test eder.

Intermediate Host Kullanmamak

Migration geçmişindeki ara hostname'ler yeni mappingde atlanmalıdır. Bir domain on yıl içinde iki kez değişmişse en eski URL doğrudan bugün kullanılan final page'e gidebilir. Bu işlem redirect configuration cleanup gerektirir. External backlink value ve user experience korunur. Mapping tests broken historical targetsı bulmalıdır.

Domain Migration ile WWW Migration Aynı Anda Yapılmalı mı?

Aynı anda domain, protocol, host ve path değiştirmek debug sürecini zorlaştırır. Bir problem çıktığında hangi değişkenin neden olduğunu anlamak daha fazla zaman alır. Buna karşılık business rebranding gibi durumlarda tek coordinated migration kaçınılmaz olabilir. Karar risk, ekip kapasitesi ve rollback seçeneklerine göre verilmelidir. Mümkünse değişken sayısını azaltmak ve bütün mappingi önceden test etmek güvenli yaklaşımdır.

Aynı Anda Çok Fazla Değişken Değiştirmenin Riski

DNS, TLS, host, path ve CMS aynı release'te değişirse failure surface genişler. Search traffic düşüşünün hangi katmandan geldiğini ayırmak zorlaşır. QA matrix büyür. Rollback bazı değişikliklerde diğerlerini de geri almak zorunda kalabilir. Risk yüksekse aşamalı migration tercih edilebilir.

Domain + Protocol + Host + URL Path

Bu dört boyutun her biri ayrı redirect ve canonical etkisi oluşturur. Combined migration mapping bütün old URL varyasyonlarını final new URL'ye doğrudan bağlamalıdır. Chain oluşmamalıdır. Search Console domain move gereksinimi domain değişimi için ayrıca değerlendirilir. Google yeni domain migrationlarında Change of Address kullanımına ilişkin güncel yönergeler sunar.

Tek Migration Senaryosu

Business tek launch tarihi istiyorsa bütün değişiklikler bir program altında yönetilebilir. URL mapping, DNS cutover ve application release aynı runbook içinde koordine edilir. Synthetic testing launch sırasında sürekli çalışır. Rollback threshold önceden belirlenir. Executive communication teknik ve business metricleri birlikte izler.

Aşamalı Migration

Önce HTTPS standardı, sonra host veya domain değişimi yapılabilir. Her aşama stabil hale geldikten sonra sonraki adım başlatılır. Bu approach root cause isolationı kolaylaştırır. Ancak toplam project süresi uzar. Search engines ve users birden fazla transition görebileceği için plan dikkatli yapılmalıdır.

Kurumsal Risk Değerlendirmesi

Traffic, revenue, brand launch deadline ve integration sayısı risk skorunu etkiler. High transaction e-commerce site ile bilgi amaçlı corporate site aynı migration riskine sahip değildir. RACI ve incident owner önceden belirlenmelidir. Maintenance window business takvime göre seçilmelidir. Go no go kriterleri objektif metriclere bağlanmalıdır.

M&A ve Rebranding Süreçlerinde WWW / Non-WWW

Satın alma ve yeniden markalama süreçlerinde birden fazla domain aynı anda yönetilir. Eski şirket domainleri backlink ve kullanıcı alışkanlığı taşır. Yeni marka altında tek preferred host standardı oluşturulması uzun vadede domain portföyünü sadeleştirir. Ancak her eski URL homepage'e yönlendirilmemelidir. Ürün ve hizmet karşılıkları mümkün olduğunca birebir map edilmelidir.

Satın Alınan Domain

Acquisition sonrası eski domain hemen kapatılmamalıdır. Traffic, backlink ve email dependency inventory çıkarılmalıdır. Website URLs new branddaki relevant content'e map edilir. Certificate ve DNS redirect service için korunur. Legal veya product pages ayrı mapping gerektirebilir.

Eski Kurumsal Domain

Old corporate domain kullanıcı bookmarkları ve external references nedeniyle yıllarca trafik alabilir. Permanent redirect uzun süre açık tutulmalıdır. Server logs legacy usageın azalma hızını gösterir. Renewal cost küçükse domain ownershipi korumak brand protection için mantıklı olabilir. Email veya identity dependency ayrıca değerlendirilmelidir.

Yeni Ana Marka

Yeni brand domainin preferred hostu migrationdan önce seçilmelidir. WWW veya non-www kararı tüm legacy domain mappinglerini etkiler. Yeni sitemap ve canonical standard doğrudan final hostname'i kullanır. Marketing campaignler launch gününde new URL yayınlar. Redirect service bütün old variantsı direct targeta bağlar.

Legacy Backlinks

High authority external links old domaini göstermeye devam edebilir. Permanent one to one redirects kullanıcı ve crawlerı relevant content'e taşır. En değerli partners zamanla new URLs ile güncellenebilir. Broken old pages backlink reportla bulunur. Redirect mapping removal ancak uzun vadeli değerlendirme sonrası yapılmalıdır.

Domain Consolidation

Birden fazla brand domain aynı siteye birleşiyorsa duplicate veya related content inventory hazırlanmalıdır. Aynı konudaki pages consolidated targeta gider. Unrelated pages zorla homepage'e taşınmamalıdır. Search ve analytics data domain bazında baseline alınır. Consolidation sonrası old domain hit volume izlenir.

Preferred Host Standardizasyonu

Yeni corporate standard bütün acquired brands için mümkün olduğunca ortak policy kullanabilir. HTTPS zorunlu, permanent redirects, maximum hop ve certificate standardı merkezi tanımlanır. İstisnalar architecture board tarafından kayıt edilir. Domain onboarding template yeni acquisitionlarda tekrar kullanılabilir. Bu yaklaşım M&A teknik entegrasyon süresini azaltır.

Kurumsal Domain Portföyü Nasıl Yönetilmeli?

Büyük şirketler ana marka dışında ülke domainleri, eski markalar, typo domains ve campaign domains yönetebilir. Her domainin ownership, expiration, DNS ve redirect amacı merkezi inventoryde bulunmalıdır. Unmanaged domain security ve brand riskidir. Redirect policy mümkün olduğunca standardize edilmelidir. Domain renewal ve certificate monitoring central platform tarafından yürütülebilir.

Ana Marka Domaini

Ana marka domain corporate canonical standardın merkezidir. Preferred hostname açıkça tanımlanır. DNS ve certificate highest availability standardına sahip olur. Search ve social entities bu URL'yi kullanır. Değişiklik yalnız formal change process ile yapılmalıdır.

Ülke Domainleri

Country code domains local content veya redirect amacıyla kullanılabilir. Her domainin SEO strategy aynı olmayabilir. Local site varsa canonical ve hreflang policy ayrı tasarlanır. Redirect domain ise relevant regional targeta gitmelidir. Country legal requirement ve ownership process inventoryde tutulur.

Eski Marka Domainleri

Legacy brands uzun süre external traffic alabilir. Expire edilmesi phishing veya brand abuse riskini artırabilir. Redirect mapping mümkün olduğunca ilgili new content'e gider. Certificate ve DNS cost yıllık portfolio budget içinde değerlendirilir. Usage çok azalsa bile security owner final retirement kararını onaylar.

Typo Domainleri

Typo domains defensive registration amacıyla tutulabilir. Kullanıcı yanlış yazdığında main siteye redirect edilebilir. Typosquatting riskine karşı monitoring yapılabilir. Bu domainlerin SEO content hostu olarak kullanılması gerekmez. Certificate gerekliyse automated redirect service kapsamalıdır.

Kampanya Domainleri

Campaign domains kısa süreli marketing için oluşturulabilir. Campaign bitince relevant permanent content'e redirect planı hazırlanmalıdır. Domain expire edilmeden önce old backlinks kontrol edilir. Analytics attribution policy belirlenir. Yeni campaign mümkünse ana domain altında path kullanarak portfolio karmaşasını azaltabilir.

Defensive Registrations

Brand koruma için alınan benzer domainler active web content taşımayabilir. Parking veya redirect security policy ile yönetilmelidir. Unknown third party hosting kullanılmamalıdır. DNSSEC ve registrar lock uygulanabilir. Renewal automation critical brand domains için zorunlu olabilir.

Hepsinin Redirect Politikası

Redirect domains central mapping service kullanabilir. Her source domain target, status code, certificate ve owner metadata taşır. Wildcard homepage redirect yerine specific path mapping mümkün olduğunda tercih edilir. Monitoring broken destinationları bulur. Portfolio dashboard expiry ve redirect availability metriclerini birleştirir.

Eski Kurumsal Domainler Ana Sayfaya mı Yönlendirilmeli?

Bütün eski URL'leri tek homepage'e yönlendirmek kolaydır, fakat kullanıcı niyeti ve content relation açısından çoğu zaman zayıf çözümdür. Google site move rehberi alakasız çok sayıda eski URL'nin tek homepage'e redirect edilmesinden kaçınılmasını açıkça önerir. Eski ürün sayfası yeni ürün karşılığına, hizmet sayfası ilgili yeni hizmete gitmelidir. İçerik gerçekten kaldırılmış ve eşdeğeri yoksa farklı status davranışı değerlendirilebilir. Mapping kullanıcı açısından mantıklı olmalıdır.

1:1 Relevant Mapping

Old URL ile new content arasında doğrudan relation varsa one to one mapping en iyi deneyimi sağlar. Page title ve content topic benzerliği kontrol edilebilir. Automated migration script mapping table kullanır. High traffic pages manual review alır. Redirect target final 200 URL olmalıdır.

Eski Ürün Sayfası

Ürün yeni brand altında devam ediyorsa corresponding product page'e yönlendirilir. Product discontinued ise successor veya consolidated category page düşünülebilir. Unrelated homepage kullanıcı aradığı bilgiye ulaştırmaz. Commerce tracking redirect query parametrelerini korumalıdır. External partner links zamanla update edilebilir.

Eski Hizmet Sayfası

Service name değişmiş olabilir fakat business offering devam ediyorsa semantic mapping yapılır. Content team old ve new page relationını doğrular. SEO team backlink ve ranking data ile priority belirler. Redirect chain olmamalıdır. New page self canonical kullanmalıdır.

Consolidated Content

Birden fazla eski page tek comprehensive new page'de birleşmiş olabilir. Bu durumda birkaç old URL aynı relevant consolidated targeta gidebilir. Google da content gerçekten consolidated ise bu yaklaşımın uygun olabileceğini belirtir. User intent mapping yine kontrol edilmelidir. Redirect table consolidation reason metadata taşıyabilir.

İlgisiz Homepage Redirect Riskleri

Kullanıcı spesifik bilgi ararken homepage'e gelirse hemen siteyi terk edebilir. Search engine de mappingi zayıf görebilir. Broken content envanteri gerçek replacement olup olmadığını belirlemelidir. Her URL için redirect zorunlu değildir. Relevant target yoksa doğru 404 veya 410 policy business ve SEO ekipleriyle değerlendirilebilir.

WWW / Non-WWW Redirect Analizi Nasıl Yapılır?

Redirect audit DNS, TLS, HTTP status, hop count, final URL, canonical, sitemap ve internal links katmanlarını birlikte kontrol eder. Sadece browserda “site açılıyor” görmek yeterli değildir. Her dört scheme hostname varyasyonu ayrı request ile test edilmelidir. Redirect chain raw response header seviyesinde kaydedilmelidir. Kurumsal domain www non-www yönlendirme ve teknik SEO optimizasyonu için bu audit düzenli olarak otomatik çalıştırılabilir.

DNS Kontrolü

WWW ve apex hostname public DNS üzerinden resolve edilmelidir. Expected provider veya IP doğrulanır. CNAME veya alias chain incelenir. DNSSEC ve TTL ayrıca raporlanabilir. NXDOMAIN veya stale record redirect testinin başlamasını bile engeller.

HTTP Status Kontrolü

Her URL varyasyonunun ilk response statusu kaydedilir. Canonical variant 200, others permanent redirect olması beklenebilir. Unexpected 302, 404 veya 500 error olarak raporlanır. HEAD ve GET behavior farklıysa ayrıca test yapılabilir. Some servers HEAD requestleri farklı işlediği için gerçek GET sampling önemlidir.

TLS Kontrolü

Her HTTPS hostname certificate handshake testinden geçer. Hostname match, expiry ve trust chain incelenir. Secondary redirect host da bu testi geçmelidir. TLS protocol security ayrı security audit konusudur. Certificate failure redirect availability severity olarak raporlanır.

Hop Sayısı

Redirect chain length her source URL için ölçülür. Preferred target mümkünse bir hop içinde bulunmalıdır. Legacy domain migration daha fazla hop üretiyorsa mapping optimize edilir. Maximum hop policy quality gate olarak tanımlanabilir. Internal links zero redirect hedefler.

Final URL

Final URL expected preferred HTTPS host üzerinde olmalıdır. Path ve query mapping doğrulanır. Final status 200 veya intended resource status olmalıdır. Unexpected language veya geo redirect ayrıca kaydedilir. URL normalization rules audit raporunda ayrı kategori olabilir.

Canonical

Final HTML canonical tag parse edilir. Expected preferred host ile karşılaştırılır. Canonical target statusu ve chain kontrol edilir. Missing veya cross host mismatch report edilir. Page types bazında pattern analizi yapılır.

Sitemap

Sitemap loc değerleri expected hostname ve scheme ile doğrulanır. Redirect URLs tespit edilir. Sitemap index references kontrol edilir. Sample URLs live request ile test edilir. Large sitemap streaming parser ile otomatik audit edilebilir.

Internal Links

Crawler internal anchorsı çıkarır. Old host veya HTTP links report edilir. Source page ve target bilgisi cleanup için verilir. Navigation wide issue template bug olarak ayrı sınıflandırılır. Redirecting internal link ratio zaman içinde düşürülür.

4× URL Host Test Matrisi

Dört URL matrisi kurumsal redirect auditinin en basit ve en etkili kontrolüdür. Aynı path HTTP www, HTTP non-www, HTTPS www ve HTTPS non-www biçimlerinde test edilir. Expected canonical host hangisiyse yalnız o HTTPS variation 200 verir. Diğerleri permanent redirect olur ve aynı final URL'ye ulaşır. Hop count ve TLS error gibi metricler birlikte kaydedilir.

HTTP WWW

İlk response permanent redirect beklenir. Final URL preferred HTTPS hostname olur. Path korunur. TLS second requestte valid olmalıdır. Hop count ideal olarak birdir.

HTTP Non-WWW

Bu variation da final HTTPS canonicala gitmelidir. Host ve scheme aynı response içinde normalize edilebilir. Query string kaybolmamalıdır. Final page self canonicaldır. Unexpected intermediate URL error olarak işaretlenir.

HTTPS WWW

Preferred host www ise 200 beklenir. Non-www preferred ise permanent redirect gerekir. TLS her iki durumda da valid olmalıdır. Certificate name match kontrol edilir. Final canonical consistency doğrulanır.

HTTPS Non-WWW

Preferred host non-www ise 200 response beklenir. WWW preferred ise redirect gerekir. Certificate secondary hostu kapsamalıdır. Redirect Location secure final URL olmalıdır. Loop olmamalıdır.

Beklenen Status Code

Canonical URL 200, alternate hostname permanent 3xx verir. HTTP variants secure final destinationa gider. Temporary 302 veya 307 standard migrationda unexpected kabul edilebilir. API exception policy ayrıca tanımlanabilir. Matrix automated assertion olarak kodlanabilir.

Beklenen Final URL

Dört source aynı logical resource için aynı final URL üretir. Example path değişmeden kalır. Final scheme HTTPS'tir. Host preferred standarddır. Query normalization intentional rule yoksa korunur.

Hop Count

Canonical source için zero redirect vardır. Alternate sources ideal olarak bir redirect içerir. Legacy domain scenarios exception olabilir. Maximum acceptable chain policy ile tanımlanır. Internal links her zaman zero hop target kullanır.

Redirect Testinde Hangi Sonuçlar Beklenmeli?

Başarılı redirect testinde bir HTTPS hostname content sunar, diğer varyasyonlar ona kalıcı yönlenir. Loop veya certificate error bulunmaz. Multi hop minimumdur ve canonical final URL self referencingdir. Sitemap ve internal linkler redirect source değil final target kullanır. Bu sonuçlar automated quality gate ile deployment sonrası sürekli doğrulanabilir.

Canonical URL = 200

Canonical page content response sağlar. Başka hostname'e yönlenmez. HTML canonical kendisini gösterir. Search engine ve user için final endpointtir. Availability monitoring bu URL üzerinden yapılır.

Secondary Host = Permanent Redirect

Secondary hostname content sunmaz. 301 veya policy tarafından seçilmiş permanent code döndürür. Location preferred hostu gösterir. TLS valid kalır. Redirect service availability ayrı SLO ile izlenebilir.

HTTP = HTTPS Canonical'a Redirect

HTTP request final secure URL'ye gider. Scheme upgrade ve host normalization tek response içinde birleştirilebilir. Browser HSTS öğrendikten sonra gelecekte HTTP requesti otomatik upgrade edebilir. Ancak server behavior yine doğru olmalıdır. Port 80 unexpected 200 content sunmamalıdır.

Redirect Loop = 0

Hiçbir test case aynı URL'ler arasında döngü oluşturmamalıdır. Crawler maximum hop aşmadan final URL'ye ulaşmalıdır. Loop critical availability failure sayılır. CDN ve origin configuration birlikte incelenir. Production alert hemen owner ekibe gider.

Multi-Hop = Minimum

Bir hop çoğu host normalization için yeterlidir. Legacy domain gibi special cases document edilir. Internal redirects sıfıra yakın tutulur. Chain cleanup scheduled technical debt olabilir. Average hop count dashboard metric olarak izlenebilir.

TLS Error = 0

Bütün HTTPS hostname variations valid handshake sağlamalıdır. Secondary host certificate expiration kabul edilemez. Global edge locations sample edilir. Certificate chain error ve hostname mismatch ayrı raporlanır. Automated renewal failure early alert üretir.

WWW / Non-WWW Redirect Analizinde Server Logları

Server logları redirect traffic'in gerçek kaynağını gösterir. Crawler audit yalnız configurationı test ederken logs kullanıcıların ve botların hangi hostname'i kullandığını açıklar. WWW ve non-www hit volume migration progress için faydalıdır. Googlebot requestleri old hosta devam ediyorsa external links veya crawl memory etkisi görülebilir. High traffic redirect sources internal cleanup veya partner update önceliğini belirler.

WWW Hit Sayısı

WWW secondary host ise hit sayısının zamanla düşmesi beklenir. Sudden increase internal deploy veya campaign error gösterebilir. Referrer data source tespitine yardımcı olur. Bot ve human traffic ayrı segmentlenebilir. Metric migration dashboarda eklenebilir.

Non-WWW Hit Sayısı

Non-www secondary ise aynı analiz ters yönde yapılır. Old backlinks sürekli baseline traffic üretebilir. Internal referer varsa cleanup gerekir. Automated scanner veya malicious traffic ayrı filtrelenebilir. Long term redirect capacity buna göre planlanır.

Googlebot Hit’leri

Googlebot old host requestleri migration sonrası bir süre devam edebilir. Response permanent redirect olmalıdır. Bot user agent tek doğrulama yöntemi değildir ve IP verification gerektiğinde uygulanmalıdır. Crawl patterns zaman içinde new hosta kayar. Search Console data ile logs birlikte yorumlanmalıdır.

Eski Host Kullanımı

Legacy hostname hangi page paths için hâlâ yoğun kullanılıyor analiz edilir. High volume old URL campaign veya application hardcode gösterebilir. Source system owner bulunur. Mapping direct final targeta optimize edilir. Usage sıfıra yaklaşmasa bile redirect service uzun süre korunabilir.

High-Traffic Redirect Sources

Referrer header veya campaign data en çok redirect üreten source'ları gösterir. Internal source öncelikle düzeltilir. External partner için outreach yapılabilir. Search engine traffic normal migration behavior olabilir. Dashboard top sourcesı haftalık raporlayabilir.

External Link Kaynakları

Backlink analysis old hostu linkleyen siteleri bulur. En değerli ve kontrol edilebilir kaynaklar update için iletişime alınabilir. Redirect yine compatibility katmanı olarak kalır. Social profile ve company directory gibi sahip olunan external properties hızlı güncellenmelidir. Outreach sonucu new direct links kazanılır.

Redirect Monitoring Dashboard

Dashboard redirect altyapısını SEO raporundan gerçek production service metriclerine taşır. Volume, latency, failure, loop, TLS ve certificate expiry aynı görünümde izlenebilir. Canonical mismatch crawler sonuçları da buna eklenebilir. Thresholdlar normal trafik baseline'ına göre belirlenmelidir. Domain migration sırasında alert sensitivity geçici olarak artırılabilir.

WWW Redirect Volume

WWW secondary ise total requests ve unique paths izlenir. Trend beklenmedik artışları gösterir. Referrer ve user agent segmentleri eklenebilir. High volume content cleanup priority oluşturur. Capacity planning redirect service QPS değerini kullanır.

Non-WWW Redirect Volume

Non-www secondary traffic aynı şekilde ölçülür. Migration tamamlandıkça internal source oranı düşmelidir. Old external traffic uzun süre devam edebilir. Volume tamamen sıfır olmak zorunda değildir. Business decision redirect retention süresini bu data ile destekleyebilir.

Average Redirect Latency

Redirect response kullanıcıya mümkün olduğunca hızlı ulaşmalıdır. Average yanında P95 ve P99 izlemek daha değerlidir. Edge ve origin locations ayrı karşılaştırılabilir. Sudden increase CDN rule veya DNS problemine işaret edebilir. SLO metric olarak tanımlanabilir.

Redirect Failure Rate

5xx, timeout ve malformed Location failures toplam requeste oranlanabilir. Broken target ayrı metric olmalıdır. Error budget SLO içinde tanımlanabilir. Secondary host düşük traffic alıyor diye availability önemsiz değildir. High backlink URL failure search ve user impact yaratabilir.

Loop Count

Synthetic checker loop tespitlerini sayabilir. Normal değer sıfırdır. Tek loop bile critical config regressiondır. Path-specific loops geniş matrix testinde bulunabilir. Alert deployment revision ile ilişkilendirilmelidir.

TLS Error

Certificate expiry, hostname mismatch ve handshake error ayrı sınıflandırılır. External monitor gerçek public DNS üzerinden test eder. Error canonical ve secondary hostları kapsar. HSTS nedeniyle browser bypass imkânı sınırlı olabilir. Security ve platform ekipleri ortak alert alabilir.

Certificate Expiry

Days to expiry metric erken uyarı sağlar. Automated renewal normalde expirationa yaklaşmadan çalışmalıdır. Warning threshold örneğin birkaç hafta önceden olabilir. Issuer veya certificate chain değişiklikleri ayrıca audit edilebilir. Legacy redirect domains central certificate inventoryye dahil edilmelidir.

Canonical Mismatch

Automated crawler page canonical hostunu expected policy ile karşılaştırır. Wrong host count release sonrası aniden artarsa template regression olabilir. Mismatch page type veya locale bazında gruplanabilir. Blocking threshold production criticality'e göre belirlenir. Search Console selected canonical sampleları ek doğrulama sağlar.

Kurumsal Domain SLO'ları

Domain redirect ve canonicalization production infrastructure olarak SLO ile yönetilebilir. Redirect availability, latency, broken target, certificate ve DNS health ölçülebilir. Bu yaklaşım teknik SEO problemlerini yalnız periyodik audit ile fark etmek yerine sürekli gözlemlemeyi sağlar. SLO hedefleri site traffic ve business kritikliğine göre belirlenmelidir. Error budget aşımı infrastructure backlogda öncelik kazanabilir.

Redirect Availability

Secondary host requestlerinin başarılı 3xx response üretme oranı izlenir. 5xx veya timeout failure kabul edilir. Global edge sampleları kullanılabilir. SLO yüksek traffic corporate domainlerde çok yüksek belirlenebilir. Maintenance değişiklikleri planlı exception olarak kayıt edilir.

Redirect Latency

Response time P95 ve P99 olarak ölçülür. DNS ve TLS süreleri ayrı veya total user journey içinde incelenebilir. Edge redirect düşük latency hedefleyebilir. Origin overload secondary redirecti etkilememelidir. Alert threshold baselinea göre belirlenir.

Broken Redirect Hedefi

Location target 404 veya 5xx döndürüyorsa redirect teknik olarak çalışsa bile user journey başarısızdır. Synthetic checker redirecti sonuna kadar takip etmelidir. Broken target rate sıfıra yakın hedeflenir. Content deletion workflow redirect table ile entegre olmalıdır. High traffic targets daha sık test edilir.

Chain Toleransı

Preferred host normalization için maximum one hop hedeflenebilir. Legacy domain exceptionları whitelist edilir. Unexpected chain quality warning üretir. Internal links zero hop hedefler. Migration project old chainsı kademeli optimize eder.

Certificate Availability

Canonical ve secondary HTTPS hosts valid certificate sunmalıdır. Expired certificate availability breach kabul edilir. Renewal automation SLO support processine bağlanır. Certificate issuer outage contingency planı gerekebilir. Monitoring public internetten yapılmalıdır.

DNS Availability

Authoritative DNS response website availability'nin ilk katmanıdır. Multiple resolver locations test edilebilir. SERVFAIL ve timeout metricleri izlenir. DNS provider SLA business criticality'e uygun olmalıdır. DNS changes audit trail ile yönetilmelidir.

WWW / Non-WWW Değişiklikleri CI/CD İçinde Test Edilebilir mi?

Evet, preferred host davranışı deployment pipeline içinde otomatik test edilebilir. Test runner dört URL varyasyonuna request gönderip status, Location, final host, HTTPS ve hop count kontrolü yapabilir. Canonical ve sitemap parsing de aynı suite'e eklenebilir. Böylece yanlış redirect rule productiona ulaşmadan durdurulur. Domain configuration infrastructure code ile birlikte versionlandığında reproducible test ortamı oluşturmak kolaylaşır.

Domain Configuration Test

Expected canonical hostname config dosyasından okunur. DNS veya local test routing staging environmenta yönlendirilebilir. Test bütün supported domains için matrix üretir. Unknown host handling ayrıca kontrol edilir. Production smoke tests deploy sonrasında gerçek endpoint üzerinde tekrar çalışır.

HTTP Status Assertion

Canonical URL'nin 200 veya expected status dönmesi assertion ile kontrol edilir. Secondary hosts permanent redirect vermelidir. Unexpected temporary response test failure olur. Error pages ayrı path datasetinde test edilebilir. Status change pull request reportunda görünür.

Final Host Assertion

Redirect takip edildikten sonra final hostname expected preferred hostla eşleşir. Case normalization ve IDN gibi özel durumlar parser tarafından doğru ele alınmalıdır. Unexpected third party host security issue olabilir. Final path mapping de kontrol edilir. Assertion central domain policy'den üretilir.

HTTPS Assertion

Final URL scheme HTTPS olmalıdır. HTTP content 200 response test failure sayılır. TLS certificate validation client tarafından yapılır. Redirect Location yanlışlıkla HTTP üretirse test yakalar. HSTS header ayrıca policy gereği assert edilebilir.

Hop Count Assertion

Redirect history uzunluğu sayılır. Alternate host için maximum one gibi policy tanımlanabilir. Legacy domain exceptions configte açıkça belirtilir. Unexpected second redirect test failure üretir. Bu gate zamanla redirect technical debt oluşmasını önler.

Canonical Assertion

Final HTML parse edilerek rel canonical bulunur. Absolute URL expected host ve path ile karşılaştırılır. Canonical target status ayrıca test edilebilir. Missing canonical bazı page types için policy exception olabilir. Result CI reporta eklenir.

Sitemap Assertion

Sitemap sample veya full stream parse edilir. Bütün loc values preferred host ve HTTPS kullanmalıdır. Redirecting loc varsa test failure olabilir. Sitemap index child references da kontrol edilir. Çok büyük filelarda incremental validation uygulanabilir.

Preferred Host Quality Gate

Quality gate domain standardının release kriterine dönüşmesini sağlar. Yalnız bir HTTPS hostun 200 dönmesi, diğer hostların permanent redirect olması ve final URL'nin self canonical sunması temel kurallardır. Sitemap final hostu kullanmalıdır. Test başarısızsa deployment otomatik durdurulabilir. Bu yaklaşım kurumsal domain yönetimini manual SEO checklistten engineering control sistemine taşır.

Sadece Bir HTTPS Host 200 Dönmeli

Canonical hostname content sunar. Secondary hostname 200 döndürürse duplicate host riski oluşur. Test aynı path'i iki host üzerinde kontrol eder. Exception endpoint varsa explicit whitelist gerekir. Unknown vhost fallback content sunmamalıdır.

Diğer Host Permanent Redirect Olmalı

Secondary host permanent status kullanır. Location exact final targeta gider. Temporary redirect config regression olarak görülür. API host behavior ayrı policyye sahip olabilir. Test web canonical host scopeunda çalışır.

Redirect Target Başka Redirect Olmamalı

Location URL doğrudan final resource olmalıdır. Test targetı takip edip second 3xx kontrol eder. Chain varsa failure veya warning üretir. Legacy path exceptions documented olur. Cleanup backlog owner atanır.

Final URL Self-Canonical Olmalı

Final page rel canonical kendi absolute URL'sini gösterir. Host, scheme ve normalized path eşleşir. Query canonicalization rules ayrıca uygulanabilir. Cross-host mismatch blocking olabilir. Rendered page test JavaScript generated head scenariosını da kapsayabilir.

Sitemap Final Hostu Kullanmalı

Sitemap old hostname içermez. CI generated sitemapı yayınlanmadan önce validate eder. Redirect URL count zero hedeflenir. Locale ve image sitemaps ayrı kontrol edilir. Host migration release bu gate geçmeden tamamlanmış sayılmaz.

Test Başarısızsa Deployment Durdurulmalı

Domain regression bütün siteyi etkileyebileceği için blocking gate mantıklıdır. Emergency override yalnız yetkili owner tarafından kullanılmalıdır. Override reason audit loga yazılır. Production smoke test yine çalıştırılır. Failure root cause düzeltildikten sonra normal pipeline geri açılır.

DNS as Code ve Redirect as Code

DNS ve redirect configuration version control altında tutulduğunda kurumsal domain değişiklikleri daha güvenli hale gelir. Manual panel değişiklikleri kimin neyi neden değiştirdiğini takip etmeyi zorlaştırır. Infrastructure as Code pull request, peer review ve automated validation sağlar. Production deployment kontrollü pipeline üzerinden gerçekleşir. Rollback previous known configurationa dönmeyi kolaylaştırır.

Version Control

DNS records ve redirect mappings repository içinde saklanabilir. Commit history değişiklik zamanını ve sahibini gösterir. Sensitive secrets repository dışında tutulur. Tag veya release domain configuration versionsı işaretleyebilir. Incident sırasında working revision hızlı bulunur.

Pull Request

Her preferred host değişikliği reviewable diff olarak sunulur. Redirect matrix ve DNS updates aynı pull requestte görülebilir. SEO ve platform reviewer atanabilir. Automated tests yorum olarak sonuç paylaşır. Approval olmadan production apply yapılmaz.

Peer Review

İkinci mühendis typo, reversed redirect veya missing certificate dependency yakalayabilir. SEO reviewer canonical ve sitemap etkisini inceler. Security reviewer HSTS veya cookie scope değişimini kontrol eder. Domain owner business impacti doğrular. Review checklist standardize edilir.

Automated Testing

Static config validation ve live endpoint testleri birlikte kullanılabilir. Duplicate DNS record veya invalid redirect target build aşamasında bulunur. Four URL matrix test staging deployment sonrası çalışır. Certificate check production smoke suite içinde olabilir. Test result audit evidence olarak saklanabilir.

Production Deployment

Deployment plan DNS TTL ve cache etkisini dikkate alır. CDN config propagate süresi izlenir. Synthetic monitor değişiklik sırasında sık aralıklarla çalışır. Error threshold aşılırsa rollout durur. Business owner migration status dashboardu görebilir.

Rollback

Previous config revision hızlı apply edilebilir. DNS propagation rollbacki anında olmayabilir, bu nedenle TTL planlaması önemlidir. Certificate ve application compatibility old state için korunmalıdır. Rollback trigger metricleri önceden belirlenir. Post incident review yeni test case üretir.

Audit Trail

Kim hangi record veya redirecti değiştirdi kayıt altındadır. Change ticket pull request ile ilişkilendirilebilir. Production apply actor ve timestamp kaydedilir. Compliance review domain changesı kolay takip eder. Manual emergency changes daha sonra repositoryye reconcile edilmelidir.

WWW / Non-WWW Yönlendirmesinde RACI

Domain migration farklı disiplinlerin birlikte çalışmasını gerektirir. SEO canonical ve crawl etkisini, DevOps DNS ve redirecti, security TLS ve cookie riskini, marketing campaign URL'lerini yönetir. Sorumluluk belirsiz olursa kritik callback veya sitemap değişiklikleri unutulabilir. RACI matrix her görevin Responsible, Accountable, Consulted ve Informed rollerini açıklar. Nihai preferred host owner organizasyon içinde belli olmalıdır.

SEO Ekibi

SEO URL inventory, canonical, sitemap ve Search Console monitoringden sorumlu olabilir. Redirect mapping relevance review yapar. Migration baseline ve post launch search metrics izler. Internal link audit yürütür. Technical implementationı DevOps ile birlikte doğrular.

DevOps / Platform

DNS, CDN, load balancer ve certificate deployment platform ekibinin alanıdır. Redirect config infrastructure code ile uygulanır. SLO ve monitoring kurulur. Rollback runbook hazırlanır. Security header ve proxy behavior test edilir.

Backend

Application absolute URL generation ve middleware config backend ekibini etkileyebilir. OAuth callback veya webhook endpoints update edilir. Host header validation kontrol edilir. API redirect behavior method preservation açısından test edilir. Database hardcoded URLs migration scriptle temizlenebilir.

Security

TLS, HSTS, cookie, CORS ve CSP impact security review kapsamındadır. Certificate coverage doğrulanır. includeSubDomains veya preload değişikliği onaylanır. Open redirect ve Host header injection tests yapılır. Incident response planına domain takeover riskleri eklenir.

Domain/DNS Yöneticisi

Registrar, DNS zone ve ownership access bu roldedir. Record changes review edilir. Domain lock ve renewal policy korunur. DNSSEC veya CAA etkisi incelenir. Legacy domains inventory güncel tutulur.

Marketing

Ads, social profiles ve campaign assets preferred hosta güncellenir. Brand communication URL standardını benimser. Analytics attribution migration döneminde izlenir. Partner outreach high value external links için yapılabilir. Launch date business calendar ile koordine edilir.

Nihai Onay Sahibi

Accountable owner migration riskini ve business impacti kabul eder. Go no go toplantısında quality gates gözden geçirilir. Emergency rollback karar yetkisi belirlenir. Teknik ekipler arası conflict bu rol tarafından çözülür. Policy değişikliği organizational standard olarak onaylanır.

Kurumsal Preferred Host Policy Nasıl Hazırlanır?

Preferred Host Policy domain mimarisinin yazılı standardıdır. Canonical hostname, HTTPS, redirect code, maximum hop, sitemap, internal link ve certificate gereksinimlerini açıklar. Yeni projeler bu policy'yi default kabul eder. İstisnalar owner ve süre bilgisiyle kayıt altına alınır. Böylece yıllar içinde farklı ekiplerin farklı host davranışları oluşturması önlenir.

Canonical Host

Policy net bir hostname belirtir. Örneğin public corporate web için https://www.example.com standardı yazılır. Environment ve country exceptions ayrı listelenir. Application configs merkezi value kullanır. Değişiklik formal architecture decision gerektirir.

HTTPS Zorunluluğu

Public web content yalnız HTTPS final URL üzerinden sunulur. HTTP permanent redirect verir. TLS certificate automation zorunludur. HSTS rollout security policyye göre uygulanır. Mixed content tests deployment pipelinea eklenir.

Allowed Redirect Codes

Web host canonicalization için 301 veya approved permanent code tanımlanır. API için 308 gibi method preserving policy ayrı olabilir. 302 ve 307 yalnız documented temporary exceptionsda kullanılır. Code changes review gerektirir. Monitoring unexpected statusları alarm olarak yakalar.

Maximum Hop

Preferred host variations için maximum one redirect tanımlanabilir. Internal links zero hop kullanır. Legacy domain exceptions explicit listede bulunur. New migration eski chainleri flatten etmeyi hedefler. Automated tests bu limite göre çalışır.

Canonical Standard

Final pages absolute self canonical kullanır. Canonical preferred HTTPS hostu gösterir. Redirect targets canonical olarak kullanılmaz. Template central URL builder üzerinden üretir. Search Console sample monitoring yapılır.

Sitemap Standard

Sitemap yalnız final canonical URLs içerir. Preferred host ve HTTPS zorunludur. Redirect ve noindex pages excluded olur. Validation publish pipelinea bağlanır. Sitemap index aynı hostta sunulur.

Internal Link Standard

Internal links final canonical URLs kullanır. Old host string repository ve contentte yasaklanabilir. Relative URL use case açıkça tanımlanır. Redirect üzerinden navigation kabul edilmez. Audit periyodik çalışır.

Certificate Standard

Canonical ve secondary redirect hosts valid certificate taşır. Renewal automateddır. Expiry monitoring belirli thresholdlarla alarm üretir. Wildcard veya SAN policy security tarafından tanımlanır. Private key management central standarda uyar.

Monitoring

Redirect availability, latency, TLS ve canonical mismatch dashboarda alınır. Synthetic tests dört URL matrixini düzenli çalıştırır. Search Console ve logs migration döneminde yakın izlenir. Alert ownership RACI ile eşleşir. Policy annual review ile güncellenebilir.

Third-Party Sistemlerde Preferred Host Güncellemesi

Domain migration yalnız web server configuration değişikliği değildir. Reklam platformları, CRM, OAuth providers, payment gateways ve webhook consumers hostname'i saklayabilir. Bu external configuration unutulursa site açılırken login veya ödeme gibi kritik işlevler bozulabilir. Inventory migrationın en önemli hazırlık adımlarından biridir. Her third party item owner ve test case ile takip edilmelidir.

Google Ads

Campaign final URLs new preferred hosta güncellenebilir. Redirect eski campaignsı çalıştırsa bile direct destination daha temiz measurement sağlar. Tracking templates query parametersı korumalıdır. Ad approval veya crawl behavior migration planında dikkate alınır. Conversion metrics launch öncesi baseline ile karşılaştırılır.

Meta Ads

Social campaign destination URLs new hosta taşınır. Pixel veya conversion API domain verification settings kontrol edilir. Redirect attribution parametersı kaybetmemelidir. Existing scheduled campaigns inventory çıkarılır. Marketing owner launch sırasında test click yapar.

LinkedIn

Company profile website URL ve campaign links güncellenir. Insight veya conversion tag settings hostname bağımlılığı açısından kontrol edilir. Existing posts redirect sayesinde çalışmaya devam eder. New content final URL kullanır. Referral analytics migration trendini gösterebilir.

E-posta Kampanyaları

Email templates absolute old host links içerebilir. Active automation flows yeni hostname ile güncellenmelidir. Eski gönderilmiş e-postalar redirecte bağımlı kalacağı için secondary host uzun süre çalışmalıdır. Tracking redirect service chain oluşturmamalıdır. Link test tool campaign öncesi final URL doğrulaması yapabilir.

CRM

CRM içinde website field, email templates ve automation webhooks old hostname kullanabilir. Search and update dikkatle yapılmalıdır. Historical records değiştirilmeyebilir, fakat active workflows güncellenmelidir. User permissions ve integration owner belirlenir. Migration checklist CRM admin tarafından sign off edilir.

Payment Providers

Success, failure ve webhook URLs exact hostname'e bağlı olabilir. Provider allowlist new hostu kabul etmelidir. Callback request method ve redirect behavior test edilmelidir. Payment flow gerçek sandbox transactionla QA yapılır. Eski URL transitional period boyunca allowlistte kalabilir.

OAuth Providers

OAuth redirect URI çoğu providerda exact match gerektirir. New hostname migrationdan önce registered olmalıdır. Allowed origin ve logout URLs ayrıca kontrol edilir. Login browser flow staging ve productionda test edilir. Old URI removal ancak traffic tamamen geçtiğinde yapılmalıdır.

Webhooks

Webhook senders redirect takip etmeyebilir veya POST method behaviorı farklı olabilir. Bu nedenle endpoint URL'leri provider configte doğrudan final hosta güncellenmelidir. 308 kullanılabilse bile client compatibility varsayılmamalıdır. Signature validation host değişiminden etkileniyor mu kontrol edilir. Delivery failures launch dashboardda izlenir.

OAuth ve SSO WWW / Non-WWW Değişiminden Nasıl Etkilenir?

OAuth ve SSO browser origin ile callback URLsine sıkı biçimde bağlıdır. Hostname değiştiğinde redirect URI, allowed origin, session cookie ve CORS configuration da değişebilir. Bu alanlardan biri unutulursa kullanıcı login sonrası error page görebilir. Migration yalnız public homepage test edilerek tamamlanmış sayılmamalıdır. Authentication end to end flow automated browser tests ile doğrulanmalıdır.

Redirect URI

Identity provider login sonrası kullanıcıyı registered URI'ye döndürür. WWW ile non-www farklı URI'dir. New hostname provider console veya API'de önceden eklenmelidir. Wildcard redirect security açısından çoğu sistemde önerilmez. Exact URI inventory environment bazında tutulmalıdır.

Allowed Origins

Browser based SDK allowed origin listesi kullanabilir. https://example.com ile https://www.example.com farklı origin sayılır. New host eklenmeden frontend token flow başarısız olabilir. Old origin transitional periodda korunabilir. Migration sonrası gereksiz origin kaldırılmalıdır.

Callback URL

OAuth dışında SAML veya custom SSO callback endpoints de hostname'e bağlı olabilir. Identity metadata file update gerekebilir. Corporate partners kendi allowlistlerini değiştirmek zorunda kalabilir. Lead time migration schedule'a eklenmelidir. Test accounts partner flowları doğrulamalıdır.

Session Cookie

Login sonrası session cookie old host scopeunda kalabilir. New hostta kullanıcı logout görünür. Shared Domain cookie kullanılıyorsa davranış farklı olabilir. Security review session migration yöntemini belirler. Controlled reauthentication çoğu zaman en temiz çözümdür.

CORS

API CORS allowlist new web origin'i içermelidir. Browser preflight requestleri migration QA sırasında test edilir. Old origin gerekli değilse daha sonra kaldırılır. Wildcard CORS ile problem gizlenmemelidir. Credentials kullanılıyorsa exact origin configuration özellikle önemlidir.

Migration Checklist

IdP redirect URIs, allowed origins, logout URLs ve cookie settings listelenmelidir. Production ve staging ayrı kontrol edilir. Browser login, logout ve token refresh flowları test edilir. Third party enterprise customers varsa notification planı hazırlanır. Sign off olmadan host cutover yapılmamalıdır.

Ödeme Sistemleri ve Callback URL’ler

Payment entegrasyonları domain migrationın en yüksek business riskli alanlarından biridir. Success ve failure URLs kullanıcı browserını yönlendirirken webhook server to server çağrı yapabilir. Provider redirect takip davranışı veya allowlist policy farklı olabilir. Hostname değişikliği sandbox ve gerçek düşük tutarlı transactionlarla test edilmelidir. Payment incident SEO probleminden çok daha ciddi ticari etki oluşturabilir.

Success URL

Ödeme sonrası kullanıcı preferred host üzerindeki success page'e dönmelidir. Provider config new URL kullanır. Old URL redirect backup olarak kalabilir. Query veya payment token params korunmalıdır. Analytics conversion event migration sonrası doğrulanır.

Failure URL

Failure veya cancel page de new hostname'e güncellenmelidir. Kullanıcının tekrar ödeme deneyebilmesi gerekir. Redirect chain session state kaybına neden olmamalıdır. Error tracking host mismatchi yakalar. Support ekibi migration günü bilgilendirilir.

Webhook

Webhook endpoint browser navigation değildir. Provider 301 takip etmeyebilir veya method semantics değişebilir. Final new endpoint doğrudan configured olmalıdır. Signature validation ve source IP policy korunmalıdır. Delivery retry dashboard launch sırasında izlenir.

Allowlist

Payment provider domain veya callback allowlist kullanabilir. New host advance olarak eklenir. Security firewall outbound veya inbound rules ayrıca kontrol edilir. Old host removal transition sonunda yapılır. Change ticket provider configuration screenshot veya API evidence içerebilir.

Host Migration Öncesi Güncelleme

Third party configuration DNS cutoverdan önce hazır olmalıdır. New host staging veya temporary validation method ile test edilebilir. Payment QA sign off launch blocker olmalıdır. Incident rollback old hostname supportunu korur. Customer support communication hazır tutulur.

Kurumsal Domainlerde En Sık Yapılan Hatalar

En yaygın hatalar iki hostname'i aynı anda 200 açık bırakmak, redirect yerine yalnız canonical kullanmak ve protocol ile host değişimini gereksiz chain'e dönüştürmektir. SSL certificate secondary hostta unutulabilir. Sitemap ve internal links eski hostu kullanmaya devam edebilir. OAuth ve webhook settings ise SEO crawler tarafından görülmediği için migrationın en kolay unutulan tarafıdır. Düzenli domain audit bu hataları production incidenta dönüşmeden bulur.

Hem WWW Hem Non-WWW'yi 200 Açık Bırakmak

İki host aynı contenti ayrı URL setlerinde sunar. Search engine canonicalization yükü artar. Analytics ve cache ayrışabilir. Permanent redirect ile bir host secondary hale getirilmelidir. Canonical tag bu düzeltmeyi destekler.

Sadece Canonical Kullanıp Redirect Yapmamak

Canonical userı final URL'ye taşımaz. Secondary host browser address barında kalır. External links ve analytics duplication devam eder. Host consolidation kalıcıysa redirect daha doğru çözümdür. Canonical final page üzerinde self reference olarak kalır.

HTTP → HTTPS → WWW Şeklinde Gereksiz Chain

Protocol ve host normalization tek stepte yapılabilir. İki redirect ek latency üretir. CDN ve origin ayrı rule uyguluyorsa chain oluşabilir. Central redirect rule final Location oluşturmalıdır. Hop count CI gate ile kontrol edilir.

Redirect Hostunda SSL Bulundurmamak

HTTPS secondary request TLS aşamasında certificate ister. Certificate yoksa kullanıcı redirect response'u göremez. Old host certificate migration boyunca korunmalıdır. Renewal monitoring yapılmalıdır. Bu hata external backlink trafficini doğrudan kesebilir.

Canonical'ı Eski Hosta Bırakmak

New host page redirect target olmasına rağmen canonical old hostu gösterirse conflict oluşur. CMS base URL cache sık nedendir. Template migrationla aynı release'te güncellenmelidir. Automated canonical assertion bunu yakalar. Search Console selected canonical sample ile doğrulanır.

Sitemap'i Güncellememek

Old host URLs sitemapte kalırsa crawler gereksiz redirects takip eder. Generator new preferred host kullanmalıdır. Old sitemap file redirect olabilir ama iç loc values update edilir. Search Console new sitemap submit edilir. Redirect URL ratio sıfıra indirilir.

Internal Linkleri Redirect Üzerinden Çalıştırmak

Site kendi içinde eski hostname'e link vermemelidir. Her click extra request oluşturur. Crawler yanlış signal görür. CMS ve templates new URLye güncellenir. Internal redirect reports düzenli temizlenir.

CDN ve Origin'de Çelişkili Kurallar Tanımlamak

İki katman farklı preferred host kullanırsa loop oluşabilir. Config ownership açık olmalıdır. Edge normalization varsa origin normalized requesti tekrar değiştirmemelidir. Integration test gerçek CDN pathini kullanır. Emergency bypass rule documentation içinde bulunur.

OAuth/Webhook URL'lerini Unutmak

Homepage düzgün açıldığı halde login veya integrations bozulabilir. Third party inventory migrationın parçasıdır. Callback exact URL settings cutover öncesi güncellenir. Webhook client redirect takip davranışına güvenilmez. Functional smoke tests launch blocker olur.

Migration Sonrası Monitoring Yapmamak

Launch tamamlandığında project bitmez. Search crawlerların new hostu benimsemesi ve old trafficin yönlenmesi zaman alır. Logs, Search Console, analytics ve TLS monitoring birlikte izlenir. Broken redirect ve canonical mismatch yeni release'lerle tekrar oluşabilir. Periyodik automated audit kalıcı kontrol sağlar.

“WWW Büyük Siteler İçin Her Zaman Daha İyidir” İddiası Doğru mu?

Bu ifade modern web altyapısı için fazla geneldir. WWW klasik DNS ve CDN modelinde bazı operasyon avantajları sağlamıştır. Ancak apex aliasing, flattening ve modern cookie güvenlik desenleri non-www yapının da büyük ölçeklerde kullanılmasını mümkün kılar. Gerçek karar provider özellikleri, migration history ve security architecture'a göre verilmelidir. SEO açısından her iki hostname doğru canonicalization ile başarılı olabilir.

Geleneksel Teknik Avantajlar

WWW subdomain CNAME ile başka service targetına kolay bağlanabilir. Cookie scope bazı mimarilerde daha açık ayrılabilir. DNS delegation ve traffic management basit olabilir. Bu nedenler geçmişte büyük sitelerde www kullanımını yaygınlaştırmıştır. Günümüzde aynı avantajların önemli bölümü başka teknik çözümlerle de sağlanabilir.

Modern DNS Sağlayıcıları

Modern providerlar apex için alias ve flattening mekanizmaları sunabilir. Managed CDN integration non-www hostla çalışabilir. DNSSEC ve automated certificates birlikte desteklenebilir. Bu feature set provider bazında doğrulanmalıdır. Architecture kararı eski internet kuralı gibi ele alınmamalıdır.

Apex Aliasing / Flattening

Bu çözümler apex domaini dynamic service targetına bağlama ihtiyacını karşılar. Kullanıcı kısa non-www URL kullanabilir. DNS provider backend target changesı yönetir. Portability ve failure semantics incelenmelidir. Multi provider planı feature compatibility test etmelidir.

Cookie Politikalarının Ayrı Yönetilebilmesi

Host only ve __Host cookie yaklaşımları ana site sessionını dar scope içinde tutabilir. WWW zorunlu olmadan güvenli cookie design mümkündür. Parent domain cookie kullanımı business requirement olmalıdır. Subdomain architecture identity boundariesi açıklar. Security decision hostname geleneğinden daha önemlidir.

Mimariye Göre Karar Vermek

En doğru karar mevcut system requirements üzerinden verilir. DNS, CDN, cookie, SSO, SEO ve migration cost matrise konur. New site farklı, legacy brand farklı sonuç üretebilir. Karar documentation ve review ile alınır. Seçildikten sonra tutarlılık host biçiminin kendisinden daha değerlidir.

En İyi Programlama Dili WWW / Non-WWW Yönlendirme İçin Hangisidir?

WWW ve non-www yönlendirme problemi programlama dili seçimi problemi değildir. Çoğu durumda en doğru çözüm CDN, reverse proxy veya web server configuration katmanındadır. Python, JavaScript, C# veya Java yalnız application-level redirect gerekiyorsa devreye girebilir. Infrastructure as Code ve HTTP bilgisi burada dil bilgisinden daha önemlidir. İyi mühendis problemi mümkün olan en düşük ve güvenilir katmanda çözmeye çalışır.

Problem Neden Programlama Dili Problemi Değildir?

Redirect için Host ve scheme bilgisi yeterlidir. Bu veriler application business logicine ihtiyaç duymaz. Web server tek line configurationla işi çözebilir. Application kodu ek dependency ve runtime cost getirir. Language choice yerine ownership, performance ve maintainability değerlendirilmelidir.

Web Server Configuration

Apache, NGINX ve IIS native redirect özellikleri sunar. Config code review ve test süreçlerine alınabilir. Application framework değişse bile behavior korunur. Syntax providera göre farklıdır. Central templates multi environment consistency sağlar.

Reverse Proxy

Reverse proxy bütün backendlerin önünde ortak standard uygular. Host validation ve TLS termination aynı yerde olabilir. Redirect application deploymentından bağımsız güncellenir. Forwarded header security doğru yapılandırılmalıdır. Infrastructure team ownershipi netleşir.

CDN

CDN edge redirect global latency avantajı sağlar. Origin cost azalır. Rule engine programlama dili gerektirmeden declarative çalışabilir. Edge function yalnız dynamic requirement olduğunda gerekir. Provider migration dependency documentation içinde tutulur.

Infrastructure as Code

DNS ve redirect rules Terraform veya benzer declarative araçlarla yönetilebilir. Asıl değer kullanılan syntax değil versioning ve reproducibility'dir. Pull request review ve plan çıktısı değişikliği görünür kılar. Secrets ayrı yönetilir. Rollback known configurationa dönmeyi kolaylaştırır.

Application Routing

Framework middleware dynamic host routing gerektiğinde kullanılabilir. Multi tenant custom domains buna örnektir. Preferred corporate host gibi static rule daha alt katmanda kalabilir. Application yine canonical URL generation için central config kullanmalıdır. Unit tests redirect edge casesı doğrulayabilir.

Doğru Katmanı Seçmek

En iyi çözüm minimum moving part içeren katmandır. DNS HTTP redirect yapamaz. CDN veya server static normalization için uygundur. Application yalnız dynamic context gerektiğinde seçilir. Architecture review latency, availability ve ownership kriterlerini birlikte değerlendirir.

Yazılımcı Olmak İçin HTTP ve DNS Bilgisi Neden Önemlidir?

Web geliştirme yalnız frontend component veya backend API yazmaktan ibaret değildir. HTTP request response modeli, DNS resolution ve TLS bağlantısı bütün web uygulamalarının temelidir. WWW ile non-www gibi görünen basit problem bu üç katmanın aynı anda anlaşılmasını gerektirir. Reverse proxy ve CDN bilgisi production debugging süresini ciddi biçimde azaltır. Technical SEO da bu altyapı bilgisinin kullanıcı ve crawler davranışına uygulanmış halidir.

Request Response Modeli

Client URL'yi çözümleyip servera request gönderir. Server status, headers ve body ile response verir. Redirect 3xx status ve Location header kullanır. Browser yeni URL'ye başka request yapar. Bu temel model chain ve loop analizinin başlangıcıdır.

HTTP Status Codes

200 content success, 3xx redirect, 4xx client resource ve 5xx server failure sınıflarını ifade eder. 301 ve 308 permanent, 302 ve 307 temporary redirect kategorisindedir. Method behavior farklılıkları API design için önemlidir. Developer status code semantiğini yalnız ezberlemek yerine network trace üzerinde görmelidir.

DNS Resolution

Browser HTTP requestten önce hostname'i resolve eder. DNS failure varsa applicationa request ulaşmaz. CNAME, A ve AAAA record davranışını anlamak deployment debugging için kritiktir. TTL cache nedeniyle changes anında her yerde görünmeyebilir. DNS logs ve public resolver tests birlikte kullanılabilir.

TLS

HTTPS requestten önce TLS handshake gerçekleşir. Certificate hostname doğrulaması redirectten önce gelir. HSTS browserı HTTPS kullanmaya zorlayabilir. TLS termination CDN veya load balancerda olabilir. Developer forwarded scheme ve secure cookie behaviorını anlamalıdır.

Reverse Proxy

Proxy client ile application arasında routing ve security katmanı sağlar. Original host ve scheme backend'e headers ile aktarılabilir. Trusted proxy configuration yanlışsa redirect loop oluşur. Load balancing ve TLS termination burada gerçekleşebilir. Logs distributed request debugging için correlation ID taşıyabilir.

CDN

CDN static content cache yanında edge redirect, WAF ve TLS hizmeti sunabilir. User request origin'e ulaşmayabilir. Cache ve rule precedence debugging için önemlidir. DNS CDN targetına doğru bağlanır. Developer production architecture diagramını okuyabilmelidir.

SEO-Friendly Routing

Search crawler HTTP davranışını normal client gibi izler. Clean permanent redirects ve canonical consistency crawl architectureı sadeleştirir. Broken links ve chains user experienceı da etkiler. Developer routing decisionın SEO etkisini anlayınca release quality artar. Technical SEO ekipler arası ortak sorumluluk haline gelir.

İyi Bir Web Geliştiricinin Domain Yönetimi Yetkinlikleri

Domain yönetimi yalnız DevOps uzmanlarının alanı değildir. Web developerın DNS, HTTP, TLS, cookie, CORS ve proxy temellerini bilmesi production sorunlarını daha hızlı çözmesini sağlar. SEO açısından URL canonicalization da bu bilginin doğal uzantısıdır. Log ve monitoring yetkinliği problemi kullanıcı şikayeti gelmeden fark etmeyi mümkün kılar. Bu beceriler özellikle dağıtık modern web sistemlerinde giderek daha önemli hale gelir.

DNS

A, AAAA, CNAME, TXT ve NS temel record türleri bilinmelidir. TTL ve propagation davranışı anlaşılmalıdır. Apex ve subdomain farkı deployment tasarımını etkiler. DNSSEC ve CAA gibi security özellikleri temel seviyede tanınmalıdır. Developer her değişikliği production panelinden manual yapmak zorunda değildir, fakat nasıl çalıştığını bilmelidir.

HTTP

Status codes, headers ve methods web protokolünün temelidir. Cache, redirects ve content negotiation uygulama davranışını etkiler. Browser developer tools request chain göstermeyi sağlar. curl gibi araçlarla raw response kontrol edilebilir. HTTP bilgisi SEO, API ve security debuggingin ortak dilidir.

TLS

Certificate chain ve hostname validation bilinmelidir. SNI birden fazla hostname deploymentında önemlidir. Expiry ve renewal automation production operasyonunun parçasıdır. HSTS irreversible etkiler taşıyabilir. Developer HTTPS hatasını application errorundan ayırabilmelidir.

Cookie

Secure, HttpOnly, SameSite, Domain ve Path attribute'ları bilinmelidir. Host migration session behaviorını etkiler. Parent domain cookie security surface büyütebilir. __Host prefix daha dar scope sağlar. Browser storage inspection debuggingte kullanılabilir.

CORS

WWW ve non-www farklı origin olduğundan CORS migrationda önemlidir. Allowed origins exact configuration gerektirebilir. Credentials kullanımında wildcard sınırlamaları vardır. Preflight behavior anlaşılmalıdır. API errorlarını SEO redirectleriyle karıştırmamak gerekir.

Reverse Proxy

Proxy routing ve forwarded headers anlaşılmalıdır. Host header validation security için önemlidir. TLS termination ve health check behavior developerı etkiler. Application logs client IP ve scheme'i doğru okuyabilmelidir. Local environment production proxy behaviorını yeterince temsil etmelidir.

Logging

Request host, path, status ve latency loglarda bulunmalıdır. Sensitive query data maskelenebilir. Redirect source ve target correlation migration analizi için değerlidir. Logs monitoring ve incident responseu besler. High volume sistemlerde sampling strategy dikkatle seçilir.

Technical SEO

Developer canonical, robots, sitemap ve redirect temelini bilmelidir. SEO ekibiyle ortak test kriterleri oluşturabilir. URL generation merkezi ve test edilebilir olmalıdır. Search crawler davranışı normal HTTP prensiplerine dayanır. Böylece teknik SEO son dakika kontrolü yerine development quality standardı olur.

Open Source ile WWW / Non-WWW Analizi

Domain audit için basit open source araçlar geliştirmek güçlü öğrenme ve kurumsal otomasyon projesidir. Redirect checker dört URL variationı test edebilir. HTTP crawler canonical ve internal links tarayabilir. TLS ve DNS checker ayrı modules olarak eklenebilir. Ortak CLI veya web interface sonuçları tek raporda birleştirebilir.

Redirect Checker

Tool URL alır ve redirect history kaydeder. Status, Location ve latency gösterir. Maximum hop ve loop detect eder. Expected preferred host config ile karşılaştırır. JSON output CI pipelinea entegre edilebilir.

HTTP Crawler

Crawler site içi links ve status codes toplar. Old hostname references bulunur. Canonical, hreflang ve structured URLs parse edilebilir. Crawl scope domain policy ile sınırlandırılır. Rate limit production siteyi aşırı yüklemeyecek şekilde ayarlanır.

Canonical Checker

Her 200 page canonical tag kontrol edilir. Missing, multiple veya cross host cases raporlanır. Target status live request ile doğrulanabilir. Preferred host mismatch severity verilir. Page template patternleri cluster edilir.

Sitemap Validator

Sitemap XML parse edilir. URLs scheme ve hostname policy ile karşılaştırılır. Redirect veya error targets bulunur. Child sitemap index references test edilir. Large files streaming mode ile işlenebilir.

TLS Checker

TLS module certificate expiry ve hostname match raporlar. WWW ve non-www ayrı test edilir. Protocol ve cipher security genişletilmiş audit olabilir. Secondary host certificate failure critical olarak işaretlenir. Output monitoring systeme gönderilebilir.

DNS Checker

DNS module A, AAAA, CNAME ve NS responses toplar. Multiple public resolvers karşılaştırılabilir. TTL ve CNAME chain raporlanır. Expected provider target assertion yapılabilir. DNSSEC validation ileri feature olarak eklenebilir.

Community Contributions

Open source tool issue ve pull request üzerinden geliştirilebilir. Developerlar yeni server patternleri veya tests ekleyebilir. Generic rules company secret içermeden paylaşılabilir. Documentation beginner contributors için önemlidir. Community feedback audit kapsamını genişletir.

Açık Kaynak Domain Auditor Nasıl Tasarlanır?

Domain Auditor kullanıcıdan tek domain alıp dört temel variationı otomatik üretebilir. Önce DNS resolve eder, ardından HTTP ve HTTPS requestleri gönderir. Redirect chain ve TLS results kaydedilir. Final page HTML parse edilerek canonical ve sitemap references kontrol edilir. Sonuç açık severity kategorileriyle raporlanır.

Domain Girdisi

User example.com gibi registrable domain verir. Input URL parser ile validate edilir. Scheme veya path verilirse normalize edilebilir. IDN domain support gerekiyorsa punycode handling yapılır. Untrusted input SSRF riskine karşı güvenli environmentda işlenmelidir.

Dört URL Varyasyonunu Üret

HTTP www, HTTP apex, HTTPS www ve HTTPS apex otomatik oluşturulur. Test path root veya user supplied path olabilir. Query sample optionaldır. Port defaults standard values kullanır. Results common matrix structure içinde saklanır.

DNS Resolve Et

Her hostname public DNS üzerinden çözülür. CNAME chain kaydedilir. Resolution failure HTTP testten ayrı hata olarak raporlanır. Resolver timeout controlleddır. Private IP targets SSRF güvenliği nedeniyle ayrı policyye tabi olabilir.

HTTP Request Gönder

Redirect automatic follow kapalı başlayarak her response manual kaydedilebilir. Status, headers ve timing alınır. Location URL parser ile resolve edilir. Maximum hop sınırı vardır. User agent açık tool kimliği kullanabilir.

Redirect Chain’i Kaydet

Her hop source, status ve target olarak listelenir. Repeated URL loop olarak işaretlenir. Chain length policy ile karşılaştırılır. Final target reachability test edilir. Report graphical arrow veya table biçiminde sunulabilir.

TLS Kontrol Et

HTTPS hosts handshake sırasında certificate metadata alır. Expiry ve subject alternative names kontrol edilir. Verification failure requestten ayrı kaydedilir. Secondary hostname certificate gereksinimi açık report edilir. Network environment system trust store kullanabilir.

Final URL'yi Bul

Redirect takip sonucu final response URL alınır. Expected preferred host config yoksa tool hangi variationın 200 verdiğini infer edebilir. Birden fazla host 200 ise duplicate warning oluşturur. Final scheme HTTPS değilse security issue raporlanır. Path preservation source ile karşılaştırılır.

Canonical ve Sitemap'i Kontrol Et

Final HTML head canonical tag parse edilir. robots.txt üzerinden sitemap locations bulunabilir. Sitemap URL hostname policy ile karşılaştırılır. Canonical target redirect veriyorsa warning oluşturulur. Results SEO ve infrastructure sections olarak ayrılabilir.

Diyarbakır Yazılım Topluluğu İçin Domain & Technical SEO Lab

HTTP, DNS, TLS ve teknik SEO konularını uygulamalı öğrenmek için domain audit projesi iyi bir çalışma alanıdır. Diyarbakır Yazılım Topluluğu içinde küçük ekipler redirect checker, canonical crawler veya certificate monitor geliştirebilir. Bu projeler web geliştiricilere yalnız SEO değil gerçek network ve production debugging pratiği kazandırır. Topluluğun proje yaklaşımına https://www.diyarbakiryazilim.com.tr/projects adresinden ulaşılabilir. Böyle bir laboratuvar yerel kurumsal siteler üzerinde izinli ve sorumlu teknik analiz örnekleri üreterek açık kaynak katkıya dönüşebilir.

HTTP/DNS Workshop

Workshop katılımcıları DNS resolutiondan başlayıp redirect responsea kadar request yolunu adım adım inceleyebilir. curl ve browser network tools kullanılabilir. Farklı 301, 302, 307 ve 308 davranışları gözlemlenir. DNS record ve TLS handshake ayrı katmanlar olarak işlenir. Final bölümde basit preferred host audit scripti yazılabilir.

Redirect Checker Projesi

CLI tool dört hostname variationı test edebilir. JSON ve terminal output üretir. Loop, chain ve wrong final host rules eklenir. Unit tests local HTTP servers üzerinde çalışır. GitHub issues yeni feature contribution için kullanılabilir.

Open Source SEO Crawler

Crawler canonical, sitemap ve internal redirectleri tarayabilir. Scope ve rate limit güvenli defaultlara sahip olmalıdır. Plugin architecture future hreflang veya structured data checks eklemeyi kolaylaştırır. Test fixtures farklı CMS outputs içerir. Community documentation Türkçe hazırlanabilir.

TLS ve Certificate Audit

Tool hostname listesi üzerinden certificate expiry ve coverage kontrol edebilir. WWW ile apex secondary hosts ayrı raporlanır. HSTS header ve redirect behavior optional checks olabilir. Certificate monitoring scheduler ile sürekli çalışabilir. Security eğitiminde handshake sırası uygulamalı gösterilir.

Canonical Audit

Canonical checker rendered veya raw HTML üzerinden tag çıkarır. Preferred host policy ile karşılaştırır. Google selected canonical doğrudan tool tarafından bilinemez, ancak Search Console manuel veya uygun authorized processle tamamlanabilir. Broken target ve redirect canonical warnings raporlanır. Dataset local test site üzerinde geliştirilebilir.

GitHub İşbirliği

Repository contribution guide ve issue templates içerir. Pull requestler automated tests çalıştırır. Beginner friendly tasks documentation veya new test case olabilir. Maintainer review network ve SEO correctness sağlar. Community projectleri portföy ve ortak öğrenme fırsatı sunar.

Yerel Kurumsal Sitelerde Teknik Analiz

Analiz yalnız izin verilen ve kamuya açık teknik endpointler üzerinde sorumlu biçimde yapılmalıdır. Private veya hassas sistemlere erişim denenmemelidir. Redirect, TLS ve public canonical bilgiler değerlendirilebilir. Sonuçlar site sahibine iyileştirme odaklı raporlanabilir. Diyarbakır Yazılım Topluluğu hakkında genel bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

30 Günlük WWW / Non-WWW Standardizasyon Planı

Otuz günlük plan büyük migrationı küçük ve kontrol edilebilir aşamalara böler. İlk hafta domain, subdomain, DNS ve certificate inventory çıkarılır. İkinci hafta preferred host ve redirect matrix tasarlanır. Üçüncü hafta implementation ve QA yapılır. Son hafta logs, Search Console, alerts ve documentation üzerinden production davranışı doğrulanır.

1 ile 7. Gün: Inventory

İlk hafta hiçbir production redirect değiştirmeden mevcut durum anlaşılır. Dört URL matrix, DNS records ve certificates taranır. Analytics ve server logs hangi hostun gerçekte kullanıldığını gösterir. Third party callbacks inventory başlatılır. Sonunda architecture diagram ve risk listesi oluşturulur.

Domainler

Ana domain, old brands ve campaign domains listelenir. Registrar ve expiration dates kaydedilir. Traffic ve backlink importance eklenir. Active website veya redirect role belirtilir. Owner bilgisi inventoryde zorunlu tutulur.

Subdomainler

WWW, app, API, auth ve other hosts public DNS üzerinden keşfedilir. Business purpose ve owner eklenir. HTTPS readiness kontrol edilir. Unknown subdomainler investigationa alınır. HSTS includeSubDomains planı bu inventoryye dayanır.

DNS

A, AAAA, CNAME, NS ve relevant records export edilir. CDN targets ve alias features belgelenir. TTL values cutover için değerlendirilir. DNSSEC ve CAA status kontrol edilir. Infrastructure as Code coverage belirlenir.

Sertifikalar

Canonical ve secondary host certificates inventory çıkarılır. Expiry ve issuer kaydedilir. Renewal automation ownerı belirlenir. Missing apex veya www coverage bulunur. Wildcard scope security review alır.

8 ile 14. Gün: Preferred Host Tasarımı

İkinci hafta teknik ve business kriterleriyle preferred host kararı verilir. Redirect matrix bütün dört variation ve legacy pathsı kapsar. Cookie ve TLS etkileri security ekibiyle değerlendirilir. Canonical, sitemap ve internal link standards dokümante edilir. Go live architecture review tamamlanır.

Canonical Host

WWW veya non-www final karar yazılır. HTTPS zorunlu tutulur. Application base URL configuration belirlenir. Search ve social metadata standarda bağlanır. Change reason architecture decision recorda eklenir.

Redirect Matrix

Dört URL variation expected status ve target ile tabloya yazılır. Legacy domains additional rows olur. Maximum hop bir gibi policy belirlenir. Query ve path preservation test cases oluşturulur. Redirect codes açık biçimde seçilir.

Cookie/TLS

Authentication cookie scope incelenir. OAuth callbacks listelenir. Certificates new topology için hazır edilir. HSTS policy etkisi değerlendirilir. Browser end to end test planı hazırlanır.

15 ile 21. Gün: Uygulama ve QA

Üçüncü hafta redirect configuration staging veya controlled environmentda uygulanır. Canonical ve sitemap output güncellenir. Internal link migration scripts çalıştırılır. Automated crawler ve functional tests yürütülür. Blocking issue kalmadan production change planı onaylanır.

Redirect

Edge veya server rules configuration code olarak hazırlanır. Syntax ve integration tests çalışır. Chain ve loop cases kontrol edilir. Secondary HTTPS certificate doğrulanır. Production smoke test scripti hazır tutulur.

Canonical

Templates new preferred host self canonical üretir. Page type sample set test edilir. Old hostname string source code scan ile aranır. Canonical target statusları doğrulanır. Search Console launch sonrası sample listesi hazırlanır.

Sitemap

Generator preferred host URLs üretir. Redirect URLs çıkarılır. Sitemap index update edilir. XML validation çalışır. Large URL set spot crawl ile kontrol edilir.

Internal Links

Navigation, footer ve breadcrumb güncellenir. CMS content old absolute links için taranır. High traffic pages manual QA alır. Redirecting internal link count baseline ile karşılaştırılır. Tracking parameters korunur.

22 ile 30. Gün: Monitoring

Son hafta production change sonrası gözlem dönemidir. Logs old host usage ve errorsı gösterir. Search Console indexing ve canonical behavior izlenir. Certificate, DNS ve redirect alerts aktif tutulur. Documentation actual production configurationa göre güncellenir. Beklenmeyen issue post launch backloga değil severityye göre doğrudan müdahale alır.

Logs

WWW ve non-www hit counts dashboarda eklenir. 5xx ve unexpected statuses alert olur. Referrer analysis old internal sourcesı bulur. Bot traffic ayrı segmentlenir. Retention troubleshooting için yeterli tutulur.

Search Console

High value URLs inspection ile kontrol edilir. Sitemap processing izlenir. Old host performance trendi takip edilir. New canonical indexing gradual adoption gösterir. Unexpected selected canonical cases investigationa alınır.

Alerts

TLS expiry, redirect failure ve loop alerts aktif olur. DNS availability external probes ile ölçülür. Canonical mismatch crawler daily veya weekly çalışabilir. Thresholdlar traffic kritikliğine göre belirlenir. On call routing RACI ile uyumludur.

Documentation

Preferred host policy final configurationı yansıtır. Redirect mappings repository ve runbook içinde bulunur. Third party updates completion state kaydedilir. Known exceptions owner ve expiry date taşır. Future developers için onboarding document hazırlanır.

WWW / Non-WWW Migration Kontrol Listesi

Migration kontrol listesi teknik ve operasyonel adımları tek yerde toplar. Her madde yalnız “yapıldı” değil evidence ile doğrulanmalıdır. Four URL matrix, TLS, canonical, sitemap, hreflang, OAuth ve payment callbacks aynı checklist içinde bulunmalıdır. Monitoring aktif olmadan launch tamamlanmış sayılmamalıdır. Kurumsal domain değişikliklerinde checklist release artifact olarak saklanabilir.

Preferred host kararı verildi mi?

WWW veya non-www kararı yazılı olmalıdır. Technical reason documentation bulunmalıdır. Owner ve approver bellidir. Application configs aynı değeri kullanır. Future change formal review gerektirir.

Dört URL varyasyonu test edildi mi?

HTTP www, HTTP non-www, HTTPS www ve HTTPS non-www ayrı test edilmelidir. Status ve final URL kaydedilir. Path sampleları birden fazla page içerir. Query preservation kontrol edilir. Test output release evidence olarak saklanır.

Tek canonical host 200 dönüyor mu?

Yalnız preferred HTTPS host content sunmalıdır. Secondary host 200 ise duplicate risk vardır. Unknown default vhost ayrıca test edilir. Final response cache ve CDN üzerinden doğrulanır. Monitoring bu davranışı periyodik kontrol eder.

Secondary host permanent redirect mi?

Secondary hostname 301 veya approved permanent status verir. Temporary code unexpected kabul edilir. Location direct final targettır. Content body önemli değildir. TLS önce başarıyla tamamlanır.

Redirect tek hop mu?

Alternate source final URL'ye tek response ile ulaşmalıdır. Chain history test edilir. Legacy exceptions documented olur. Internal links redirect kullanmaz. Hop count policy CI gate içindedir.

Her iki HTTPS hostname için TLS çalışıyor mu?

Canonical ve secondary certificates valid olmalıdır. Expiry yeterli sürede olmalıdır. Hostname match doğrulanır. Global edge certificate consistency test edilir. Renewal automation monitoring altındadır.

Canonical'lar güncellendi mi?

Rendered HTML new preferred hostu gösterir. Self canonical final URLs kullanılır. Old hostname source scan sıfır result hedefler. Redirect targets canonical değildir. Search Console selected canonical samplelanır.

Sitemap güncellendi mi?

Loc values preferred HTTPS host kullanır. Redirect URLs yoktur. Sitemap index new hostu referans eder. Search Console sitemap submit veya discovery kontrol edilir. Automated validation production file üzerinde çalışır.

Internal linkler güncellendi mi?

Navigation, content ve CTAs direct final URL kullanır. Old absolute host strings temizlenir. Internal redirect ratio ölçülür. Broken links migration sırasında düzeltilir. External links ayrı backlog olabilir.

Hreflang güncellendi mi?

Alternate language URLs new host kullanır. Reciprocal relationships korunur. x-default update edilir. Old hostname references yoktur. Locale templates automated test alır.

Structured data güncellendi mi?

Organization, WebSite, Article ve Breadcrumb URLs kontrol edilir. JSON LD old hostname içermemelidir. Asset URLs intentional exceptions olabilir. Schema validation sample pages üzerinde yapılır. CMS plugin cache temizlenir.

Open Graph güncellendi mi?

og:url final canonical hostu gösterir. Social share buttons new URL üretir. Twitter card metadata kontrol edilir. Scheduled campaigns new destination kullanır. Social preview cache gerektiğinde refresh edilir.

OAuth callback'leri güncellendi mi?

All identity providers new URI'yi register etmiştir. Allowed origins update edilmiştir. Login, logout ve refresh flow test edilmiştir. Old URI transitional period planı vardır. Enterprise partner IdP settings ayrıca doğrulanır.

Payment/webhook adresleri güncellendi mi?

Payment success ve failure URLs new hostu kullanır. Webhooks direct final endpointtir. Sandbox transaction başarıyla tamamlanmıştır. Provider allowlists update edilmiştir. Delivery monitoring launch sırasında aktiftir.

Analytics ve reklam URL'leri güncellendi mi?

Campaign destinations preferred host kullanır. Analytics hostname filters yeni URL'yi tanır. Conversion tracking test edilir. Old host traffic segmentlenir. Migration date reporting note olarak kaydedilir.

Monitoring aktif mi?

Redirect availability ve latency dashboarddadır. TLS expiry alert vardır. DNS health external test edilir. Canonical mismatch crawler scheduled çalışır. On call owner alert routeunu bilir.

Kurumsal Domain Yönlendirme Audit Checklist

Audit checklist mevcut bir siteyi migration yapılmadan önce veya sonra hızlı değerlendirmek için kullanılabilir. Her soru pass, warning veya fail olarak işaretlenebilir. Sonuçlar SEO, security ve platform ownerlarına dağıtılır. Critical errors önce availability ve data security açısından çözülmelidir. Kurumsal Domainlerde WWW ve Non-WWW Yönlendirme Analizi düzenli yapıldığında configuration drift erken fark edilir.

HTTP WWW sonucu nedir?

Expected permanent redirect olmalıdır. Final URL canonical HTTPS hosttur. Chain length kaydedilir. Query korunur. Unexpected 200 fail kabul edilir.

HTTP Non-WWW sonucu nedir?

Aynı policy bu variation için uygulanır. Host ve protocol normalization tek stepte yapılabilir. Final target expected page'tir. Broken redirect kontrol edilir. Response headers rapora eklenir.

HTTPS WWW sonucu nedir?

Preferred host www ise 200 beklenir. Değilse permanent redirect beklenir. TLS certificate valid olmalıdır. Final URL self canonicaldır. HSTS policy ayrıca kontrol edilir.

HTTPS Non-WWW sonucu nedir?

Preferred host non-www ise 200 beklenir. Aksi durumda redirect verir. Certificate coverage zorunludur. Loop bulunmamalıdır. Path mapping korunmalıdır.

Final URL doğru mu?

Scheme HTTPS, host preferred standard olmalıdır. Intended path korunur. Query normalization intentional olmalıdır. Final status expected content response verir. Geo veya language redirects varsa documentationla karşılaştırılır.

Redirect chain var mı?

History array incelenir. Host normalization için birden fazla hop warningdir. Legacy domain exceptions ayrılır. Internal source chains high priority cleanup alır. Target flattening uygulanabilir.

Loop var mı?

Repeated URL veya maximum redirects aşımı loop göstergesidir. CDN ve origin rules karşılaştırılır. Scheme headers kontrol edilir. Loop critical severitydir. Fix sonrası regression test eklenir.

TLS hatası var mı?

Canonical ve secondary hosts test edilir. Expiry, hostname mismatch ve chain error ayrılır. HSTS nedeniyle impact daha ciddi olabilir. Certificate renewal pipeline incelenir. Zero error hedeflenir.

Canonical preferred hostu gösteriyor mu?

Rendered rel canonical expected hostname ile eşleşir. Target final 200 URL'dir. Multiple canonical tags warningdir. Request Host manipulation canonicalı değiştirmemelidir. Sample page types birlikte test edilir.

Sitemap canonical host mu?

Sitemap loc values standard hostname'i kullanır. HTTP veya secondary URLs bulunmamalıdır. Redirect responses report edilir. Sitemap index references aynı standardı kullanır. Generator source config incelenir.

Internal links direct canonical URL mi?

Crawler anchor targetları analiz eder. Redirecting internal links source page listesiyle raporlanır. Navigation wide issues template ownera gider. Content hardcodes batch update alabilir. Cleanup sonrası recrawl yapılır.

HSTS politikası doğru mu?

Strict Transport Security header secure response üzerinde kontrol edilir. max-age ve includeSubDomains corporate policy ile karşılaştırılır. All subdomains HTTPS ready olmalıdır. Preload status bilinçli karar olmalıdır. Old test hostların etkisi değerlendirilir.

Cookie scope doğru mu?

Authentication cookie Domain attribute ve Secure settings kontrol edilir. Main site migration sonrası host only behavior doğrulanır. Unnecessary parent domain cookies security issue olabilir. SameSite application flowa uygun olmalıdır. Browser test login scenariosını kapsar.

CDN/origin kuralları uyumlu mu?

Her katmanın preferred host configurationı karşılaştırılır. Duplicate redirect ownership kaldırılır. Forwarded headers doğru aktarılır. Edge bypass request origin behaviorını test eder. Configuration docs actual deploymentla eşleşmelidir.

Sıkça Sorulan Sorular

WWW ve non-www konusunda en sık sorulan sorular genellikle SEO üstünlüğü, redirect kodu, SSL ve canonical ilişkisi etrafında toplanır. Temel prensip basittir: hangi hostname seçilirse seçilsin tek HTTPS canonical host belirlenmeli ve diğer varyasyonlar buna tutarlı biçimde bağlanmalıdır. Domain migrationı sırf görünüm için yapılmamalı, teknik gerekçe ve risk birlikte değerlendirilmelidir. Search, security ve application integrations aynı plan içinde ele alınmalıdır. Aşağıdaki yanıtlar hızlı karar için pratik referans sağlar.

WWW ile non-WWW arasındaki fark nedir?

WWW ana domain altında ayrı hostname veya subdomain labelıdır. Non-www ise apex domain olarak adlandırılır. Kullanıcı açısından iki adres aynı siteyi gösterebilir. DNS, cookie ve CDN açısından farklı davranışlar tanımlanabilir. SEO açısından önemli olan tek preferred host üzerinde tutarlılıktır.

SEO için www mi non-www mi daha iyidir?

İkisinin doğal sıralama avantajı yoktur. Search engine için doğru canonicalization ve permanent redirect daha önemlidir. Sitemap ve internal links aynı hostu kullanmalıdır. Existing strong host teknik gerekçe olmadan değiştirilmemelidir. New site architecture ihtiyacına göre birini seçebilir.

Google www domainleri tercih eder mi?

Google belirli www formatını genel sıralama tercihi olarak zorunlu tutmaz. Canonical seçiminde redirects, HTTPS, sitemap ve canonical annotations gibi sinyalleri birlikte değerlendirir. Site sahibi preferred URL sinyalleri verebilir. Google yine farklı canonical seçebilir. Tutarlılık bu nedenle önemlidir.

Hem www hem non-www kullanmak zararlı mı?

İki host aynı contenti 200 olarak sunuyorsa gereksiz duplicate URL oluşur. Arama motorları canonicalization yapabilir, ancak site sinyalleri dağılır. Analytics ve caching de etkilenebilir. Bir host 200 canonical, diğeri permanent redirect olmalıdır. Böylece kullanıcı hangi URL'yi yazarsa yazsın tek final address görür.

WWW'den non-WWW'ye 301 yapılmalı mı?

Non-www kalıcı preferred host seçildiyse www permanent redirect vermelidir. 301 normal web GET traffic için yaygın çözümdür. Path ve query korunmalıdır. HTTPS www certificate geçerli kalmalıdır. Internal links doğrudan non-www final URLs kullanmalıdır.

Non-WWW'den WWW'ye nasıl yönlendirilir?

CDN, reverse proxy veya web server Host headerı kontrol eder. Apex request doğrudan HTTPS www counterparta permanent redirect edilir. Protocol ve host aynı response içinde normalize edilebilir. Certificate apex hostname'i de kapsamalıdır. Redirect target başka redirect vermemelidir.

301 mi 308 mi kullanılmalıdır?

İkisi de permanent redirecttir. 308 request method ve body'yi korumayı garanti eder. 301 eski clientlarda bazı non GET methodlar için farklı davranabilir. Normal web page GET trafficinde 301 yaygındır, API flows için 308 değerlendirilebilir. Corporate policy use case bazında standard belirlemelidir.

HTTP ve WWW yönlendirmesi tek adımda yapılabilir mi?

Evet, scheme ve hostname aynı redirect response içinde değiştirilebilir. HTTP non-www doğrudan HTTPS www final URL'ye gidebilir. Ara HTTP www adımı gerekli değildir. Query ve path korunmalıdır. Hop count test ile doğrulanmalıdır.

Redirect chain SEO’yu etkiler mi?

Chain ek request ve latency oluşturur. Çok uzun chains crawl ve user experienceı gereksiz zorlaştırır. MDN her redirectin başka request gerektirdiğini gösterir. Preferred host normalization mümkün olduğunca tek hop olmalıdır. Internal links direct final URLs kullanmalıdır.

WWW ve non-WWW için ayrı SSL gerekir mi?

Ayrı certificate zorunlu değildir, tek SAN certificate iki hostname'i de kapsayabilir. Wildcard certificate www gibi subdomaini kapsasa da apex coverage ayrıca kontrol edilmelidir. İki hostname de HTTPS request alıyorsa valid TLS gerektirir. Deployment architecture certificate sayısını belirler. Renewal her durumda automated olmalıdır.

Redirect veren domainin SSL sertifikası olmak zorunda mı?

HTTPS request için evet, çünkü TLS handshake redirect response'tan önce gerçekleşir. Certificate invalid ise browser 301 response'u görmeden hata verebilir. Secondary hostname migration boyunca certificate korumalıdır. HSTS bu hatayı kullanıcı açısından daha katı hale getirebilir. Certificate expiry monitoring zorunlu olmalıdır.

HSTS www ve non-www yapısını nasıl etkiler?

HSTS hostname bazlı HTTPS enforcement sağlar. Apex üzerinde includeSubDomains kullanılırsa www ve diğer subdomainler de etkilenebilir. Bütün subdomainler HTTPS hazır olmalıdır. WWW üzerinde policy sibling apex için aynı etkiyi otomatik oluşturmaz. Preload öncesi kapsamlı inventory gerekir.

WWW kullanmak CDN için zorunlu mudur?

Hayır, modern DNS ve CDN platformları apex aliasing veya flattening destekleyebilir. WWW klasik CNAME modelinde kolaylık sağlar. Provider capability ve portability değerlendirilmelidir. Existing non-www site yalnız CDN nedeniyle otomatik taşınmamalıdır. Proof of concept gerçek failover behaviorını doğrulamalıdır.

Non-WWW domainlerde CNAME kullanılabilir mi?

Zone apex üzerinde klasik CNAME kullanımı DNS standardı nedeniyle sınırlıdır. Modern providerlar alias veya flattening benzeri çözümler sunabilir. Bu özellikler standard CNAME ile tamamen aynı değildir. DNS architecture provider dokümantasyonuna göre tasarlanmalıdır. A ve AAAA records da alternatif olabilir.

Canonical tag 301 redirect’in yerine geçer mi?

Hayır, canonical kullanıcıyı başka URL'ye taşımaz. Kalıcı host consolidation için redirect daha doğrudan araçtır. Canonical final page üzerinde preferred URL signalı sağlar. Google canonical annotationı hint olarak değerlendirir. Redirect ve canonical aynı kararı desteklemelidir.

Sitemap www mi non-www mi kullanmalıdır?

Sitemap preferred canonical hostu kullanmalıdır. WWW seçildiyse bütün URLs HTTPS www olmalıdır. Non-www seçildiyse aynı standard apex için uygulanır. Redirect URLs sitemapten çıkarılmalıdır. Search Console new sitemap processing takip edilmelidir.

Internal linklerin yönlendirme üzerinden gitmesi doğru mudur?

Teknik olarak çalışabilir, fakat iyi practice değildir. Site kendi içinde final canonical URL'ye doğrudan link vermelidir. Redirect request latency ve crawl overhead oluşturur. Internal old links migration cleanup ile düzeltilmelidir. External legacy links redirect üzerinden çalışmaya devam edebilir.

Kurumsal domain www'den non-www'ye taşınmalı mı?

Sadece estetik neden için genellikle gerekli değildir. Teknik DNS, CDN veya architecture faydası varsa migration değerlendirilebilir. Existing backlink ve integration cost hesaplanmalıdır. URL mapping ve monitoring hazırlanmalıdır. Karar fayda risk analiziyle verilmelidir.

WWW migration sırasında sıralama dalgalanması olabilir mi?

URL değişikliklerinde search visibility geçici olarak hareket edebilir. Correct one to one redirects, canonical ve sitemap updates migrationı daha anlaşılır hale getirir. Google site move rehberi redirect ve testing adımlarını özellikle önerir. Monitoring Search Console ve analytics üzerinden yapılmalıdır. Teknik error varsa hızlı müdahale edilmelidir.

Open source araçlarla www/non-www redirect testi yapılabilir mi?

Evet, basit HTTP client ve DNS libraries yeterlidir. Tool dört URL variationı üretip status, TLS ve final URL kontrol edebilir. Canonical ve sitemap parsing eklenebilir. CI pipeline içinde domain quality gate olarak çalıştırılabilir. Açık kaynak yaklaşım ekiplerin ortak test standardı geliştirmesini kolaylaştırır.

Sonuç

Kurumsal Domainlerde WWW ve Non-WWW Yönlendirme Analizi için en önemli sonuç, www veya non-www seçiminin tek başına bir SEO avantajı üretmediğidir. Başarılı yapı yalnız bir HTTPS hostun canonical content sunmasını, diğer scheme ve hostname varyasyonlarının kalıcı ve mümkün olduğunca tek adımlı redirect ile aynı final URL'ye gitmesini gerektirir. Canonical, sitemap, internal links, hreflang, structured data, Open Graph, OAuth callback ve payment URLs aynı host kararına göre güncellenmelidir. Google'ın güncel rehberleri de URL migrationlarında doğru mapping, permanent redirects, canonical güncellemeleri ve redirect testlerinin önemini vurgular. Kurumsal domain www non-www yönlendirme ve teknik SEO optimizasyonu veya domain yönlendirme ve teknik SEO danışmanlığı yakınımda gibi bir ihtiyacınız varsa Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilir, teknik çalışma ve proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects üzerinden inceleyebilirsiniz.

Ek Sık Sorulan Sorular

Kurumsal ekipler hostname standardı belirlerken çoğunlukla SEO, redirect, HTTPS ve teknik danışmanlık başlıklarında aynı sorularla karşılaşır. Kararın temelinde “hangi biçim daha popüler?” sorusu değil mevcut domain geçmişi ve altyapı gereksinimleri bulunmalıdır. Migration gerekiyorsa search signal ve functional integrationlar aynı plan içinde ele alınmalıdır. Dört URL matrixi, certificate ve canonical kontrolü launch öncesi minimum test setidir. Aşağıdaki sorular yönetici ve teknik ekiplerin ortak karar toplantısında kısa referans olarak kullanılabilir.

Kurumsal domainlerde WWW ve Non-WWW sürümleri arasında hangisi tercih edilmelidir?

SEO açısından iki seçeneğin doğrudan doğal üstünlüğü yoktur ve tercih mevcut DNS, CDN, cookie, subdomain ve domain geçmişine göre yapılmalıdır. Yeni bir site teknik gereksinimlerine göre www veya non-www ile başlayabilir. Yıllardır çalışan mevcut bir site yalnız görünüm amacıyla migration yapmamalıdır. Seçimden sonra tek HTTPS hostname canonical olarak 200 sunmalı ve secondary host permanent redirect vermelidir. Kurumsal policy sayesinde bütün ekipler sitemap, internal link ve third party integrations içinde aynı hostname'i kullanmalıdır.

WWW ve Non-WWW adreslerinin aynı anda erişilebilir olması SEO açısından sorun oluşturur mu?

İki hostname'in de aynı contenti 200 response ile sunması gereksiz duplicate URL kümeleri oluşturabilir ve canonical signal setini dağıtabilir. Google duplicate sayfalarda canonical seçimi yapabilir, ancak site tarafında redirect ve canonical ile açık tercih bildirmek daha düzenli architecture sağlar. Kullanıcı iki hostname'i yazabilmeli, fakat secondary hostname content sunmak yerine final canonical URL'ye taşımalıdır. Sitemap ve internal links yalnız final hostu kullanmalıdır. Böylece duplicate content, analytics fragmentation ve redirect technical debt önemli ölçüde azaltılır.

WWW’den Non-WWW’ye veya Non-WWW’den WWW’ye 301 yönlendirmesi nasıl doğru yapılandırılır?

Redirect mümkünse CDN, reverse proxy veya web server gibi merkezi katmanda uygulanmalıdır. Gelen requestin hostname'i preferred hosttan farklıysa Location aynı path ve query değerleri korunarak final HTTPS canonical URL olarak oluşturulur. HTTP ve hostname normalization tek response içinde yapılmalı, örneğin http://example.com/a doğrudan https://www.example.com/a adresine gidebilmelidir. Secondary HTTPS hostname geçerli certificate taşımaya devam etmelidir. Redirect targetın tekrar redirect vermediği automated four URL matrix testleriyle doğrulanmalıdır.

Canonical etiketleri, HTTPS ve WWW/Non-WWW yönlendirmeleri arasındaki tutarlılık nasıl kontrol edilmelidir?

Önce dört temel URL varyasyonu test edilerek yalnız canonical HTTPS hostname'in 200 dönüp dönmediği kontrol edilir. Secondary hostname ve HTTP varyasyonlarının permanent redirect ile aynı final URL'ye gitmesi beklenir. Final page rel canonical etiketi kendisini göstermeli, sitemap ve internal links aynı hostname'i kullanmalıdır. Search Console URL Inspection ile belirli örneklerde Google selected canonical ile user declared canonical karşılaştırılabilir. Bu kontroller CI/CD ve scheduled crawler ile otomatik hale getirildiğinde migration sonrası configuration drift daha hızlı yakalanır.

Kurumsal domainlerde WWW ve Non-WWW yönlendirme analizi için yakınımda teknik SEO danışmanlığı nerede bulabilirim?

Teknik SEO danışmanlığında yalnız 301 kuralına değil DNS, TLS, CDN, canonical, sitemap, internal links, OAuth ve monitoring katmanlarına birlikte bakılması gerekir. Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilirsiniz. Proje ve teknik çalışma alanlarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. İlk teknik analiz öncesinde domain ve subdomain envanteri, mevcut preferred host, Search Console erişimi ve CDN veya DNS sağlayıcı bilgilerini hazırlamak süreci hızlandırır. En sağlıklı başlangıç dört URL host test matrisi, certificate kontrolü, redirect chain analizi ve canonical sitemap tutarlılık raporunun birlikte çıkarılmasıdır.