Alt Alan Adı mı Alt Klasör mü? SEO ve Teknik Farklar

blog.example.com mu, example.com/blog/ mu? Kısa cevap şu: arama motorları ikisini de tarar, dizine ekler ve sıralar; Google temsilcileri yıllardır "kurulumunuza uyan yapıyı seçin" diyor. Kesin olan ve size iş çıkaracak ya da iş kazandıracak farklar tekniktir: alt alan adı (subdomain) ayrı bir DNS adı, tarayıcı için ayrı bir origin ve tarayıcı botları için ayrı bir host'tur; alt klasör (alt dizin) ise zaten var olan bir host'un üzerindeki bir yoldan ibarettir. Bu yazıda bu mekanikleri anlatıyor, sonunda bir karar tablosu veriyoruz. "Şu yapı daha iyi sıralanır" türünden bir iddiada bulunmuyoruz, çünkü arama motorlarının dışında kimse böyle bir iddiayı kaynak göstererek kanıtlayamaz.

Alt alan adı ve alt klasör nedir?

Alt alan adı, alan adınızın altındaki bir addır: blog.example.com, magaza.example.com, status.example.com. Var olmasının nedeni, o ad için bir DNS kaydının bulunmasıdır. İstediğiniz yeri gösterebilir: ana siteyle aynı sunucuyu, başka bir veri merkezini ya da dünyanın öbür ucundaki bir SaaS platformunu.

Alt klasör bir yoldur: example.com/blog/. DNS'in bundan haberi yoktur. Tarayıcı example.com adını çözer, cevap veren sunucuya bağlanır ve ondan /blog/ yolunu ister. O yolun arkasındaki her şeyi example.com adına cevap veren host, ya da onun isteği ilettiği bir sistem sunmak zorundadır.

$ dig +short blog.example.com
blog-example.hosted-platform.example.
203.0.113.20

$ curl -sI https://example.com/blog/ | head -n 1
HTTP/2 200

İlk komut, bir CNAME ile dış bir platforma devredilmiş alt alan adını gösteriyor. İkincisi, ana sitenin kendi sunucusunun cevapladığı bir yolu.

DNS ve barındırma tarafı

Alt alan adı. Tek kayıt yeter, içerik dilediğiniz yerde durur. Hazır bir blog, mağaza ya da doküman platformuna CNAME vermek bir dakikalık iştir; kaydın kendi TTL değeri olur ve ileride ana siteye dokunmadan başka yere taşınabilir. Kök alan adına CNAME konamaz ama alt alan adına konabilir; SaaS ürünlerinin sizden neredeyse her zaman bir subdomain istemesinin nedeni budur.

Bedeli envanterdir. Her alt alan adı, birinin hatırlaması gereken bir DNS kaydıdır. Platform aboneliği iptal edilip CNAME yerinde kalırsa ortada sahipsiz bir kayıt olur; bu da subdomain takeover saldırısının başlangıç noktasıdır. Wildcard kayıtlar tabloyu ayrıca değiştirir: bkz. wildcard DNS kayıtları.

Alt klasör. Yolu aynı uygulama sunuyorsa DNS tarafında yapılacak hiçbir şey yoktur. Blog ana siteden farklı bir platformda çalışıyorsa /blog/* isteklerini öbür arka uca yönlendiren bir reverse proxy ya da CDN kuralı gerekir. Bu çalışır, ama operasyonel bir bağımlılıktır: proxy doğru Host başlığını iletmeli, yönlendirmeleri ve mutlak URL'leri yeniden yazmalı, kuralları farklı iki uygulamanın önbelleğini yönetmelidir; üstelik ikisi için de tek hata noktası hâline gelir. Birçok hazır platform bir yolun altından sunulmayı hiç desteklemez.

SSL/TLS sertifikası

Sertifika, içinde yazan host adları için geçerlidir. Alt klasör yeni bir şey gerektirmez: example.com/blog/, example.com sertifikasının kapsamındadır.

Alt alan adı ise bir sertifikada yer almalıdır: ya adıyla (Subject Alternative Name olarak) ya da *.example.com wildcard'ı üzerinden. Wildcard yalnızca tek etiketi kapsar: blog.example.com ile eşleşir, eu.blog.example.com ile eşleşmez. Hazır platformlar CNAME yerine oturunca subdomain'iniz için sertifikayı genellikle kendileri alır; CAA kaydıyla sertifika otoritelerini kısıtladıysanız platformun kullandığı otoriteye izin vermeniz gerekir.

Tarayıcı tarafı: origin, çerezler, HSTS

İki seçeneğin en çok ayrıştığı ve güvenlik argümanının bulunduğu yer burasıdır.

Same-origin politikası. Origin; şema + host + porttur. https://example.com ile https://blog.example.com farklı origin'lerdir. localStorage, IndexedDB ve service worker'ları paylaşmazlar; sunucu CORS başlıkları göndermedikçe birindeki JavaScript öbüründen gelen cevapları okuyamaz. https://example.com/blog/ ile https://example.com/app/ ise aynı origin'dir: bir yolun altındaki betik, öbür yolun sakladığı her şeye tam erişime sahiptir.

Çerezler. Domain özniteliği olmadan konan çerez yalnızca onu koyan host'a gönderilir. Domain=example.com ile konan çerez ise example.com adına ve bütün alt alan adlarına gider. Yani site ile subdomain arasında oturum paylaşmak mümkündür, ama bilinçli bir tercihtir ve unutulmuş olanlar dahil her alt alan adının o çerezi alması anlamına gelir. Tek bir host içinde bütün yollar çerezleri paylaşır; Path özniteliği bir güvenlik sınırı değildir.

Yalıtım. Sonuç: tam denetiminizde olmayan içerik, oturumlarınızı tutan origin'de yaşamamalıdır. example.com/… altında çalışan kullanıcı içerikleri, üçüncü taraf bir destek masası ya da pazarlama aracı, uygulamanızla aynı origin yetkilerine sahip olur. Alt alan adında olmaz (oturum çerezleriniz host'a özel kaldığı sürece). Müşteri içeriği barındıran platformlar bir adım daha ileri gider: ayrı bir kayıtlı alan adı kullanır ve bunu çoğu zaman Public Suffix List'e yazdırır; böylece müşterilerin siteleri birbirine çerez koyamaz.

HSTS. Strict-Transport-Security başlığı, onu gönderen host için geçerlidir. Alt alan adları ancak kök alan adı includeSubDomains gönderirse kapsanır; aksi hâlde her subdomain kendi başlığını göndermelidir. Tersi de önemlidir: includeSubDomains açıldığında, şirket içi ya da eski sistemler dahil bütün alt alan adlarında HTTPS zorunlu olur. Ayrıntılar HSTS sözlük maddesinde.

SEO tarafında kesin olanlar: robots.txt, site haritası, Search Console

Sıralamaya dair hiçbir şey söylemeden, host düzeyindeki şu gerçekler geçerlidir:

• robots.txt host başınadır. Subdomain'i https://blog.example.com/robots.txt yönetir; example.com üzerindeki dosya ona uygulanmaz. Alt klasör ise ana sitenin tek dosyasına tabidir.
• Site haritaları pratikte host başınadır: subdomain'in URL'lerini, o subdomain'den sunulan ya da onun robots.txt dosyasında belirtilen bir site haritasında listeleyin.
• Search Console mülkleri. URL ön eki mülkü tek bir host'u kapsar. Alan adı mülkü (DNS TXT kaydıyla doğrulanır) kök alan adını ve tüm alt alan adlarını birlikte kapsar. Alt klasör her zaman ana sitenin mülkünün içindedir.
• Tarama host adı bazında yönetilir. Yavaşlayan ya da hata veren bir subdomain platformu ana sitenin sunucusundan ayrı bir konudur; aynı host altındaki yavaş bir yol ise öyle değildir.
• Analitik. Alt alan adları arasında analitik çerezinin üst alan adına kapsandığını ve yönlendiren hariç tutma ayarlarının yapıldığını kontrol edin; yoksa ziyaretçi host değiştirdiğinde oturum ikiye bölünür.

$ curl -s https://blog.example.com/robots.txt
User-agent: *
Disallow: /taslaklar/
Sitemap: https://blog.example.com/sitemap.xml

Klasik kaza: test ortamının Disallow: / içeren robots.txt dosyası yeni subdomain'de yayına girer ve kimse fark etmez, çünkü herkes ana sitenin dosyasına bakar.

Karar tablosu

Kullanım	Genellikle uygun olan	Neden
Site ile aynı CMS'teki blog	Alt klasör	Ek DNS, sertifika ya da origin yok; tek robots.txt, tek mülk
Hazır platformdaki blog	Alt alan adı	Tek CNAME; yol için işletip izlemeniz gereken bir reverse proxy gerekir
SaaS üzerindeki mağaza	Alt alan adı	Platformlar özel host adı bekler; ödeme betikleri ana origin'in dışında kalır
Dokümantasyon	İkisi de	Aynı yayın hattı: yol. Ayrı doküman platformu: subdomain
Web uygulaması (app.)	Alt alan adı	Ayrı origin, oturumları tanıtım sayfalarından ve onların üçüncü taraf betiklerinden yalıtır
Ülke ya da dil sürümleri	İkisi de (ya da ülke uzantıları)	Yollar daha kolay işletilir; subdomain bölgeye göre ayrı barındırmaya izin verir. İkisinde de hreflang kullanın
Kullanıcıların oluşturduğu siteler, yüklemeler	Ayrı alan adı	Origin ve çerez yalıtımı
Durum (status) sayfası	Ayrı altyapıda alt alan adı	Ana site, CDN'i ya da DNS sağlayıcısı çöktüğünde ayakta kalmalıdır; DNS'i de ayırmayı düşünün

Birinden öbürüne taşıma

blog.example.com ile example.com/blog/ arasındaki geçiş, içerik birebir aynı olsa bile bir site taşımasıdır:

1. Her eski URL'yi yeni karşılığıyla eşleyin. Her birini 301 ile bire bir yönlendirin; hepsini yeni ana sayfaya göndermeyin.
2. Canonical etiketlerini, hreflang açıklamalarını, site içi bağlantıları ve site haritalarını yeni URL'lere göre güncelleyin.
3. Bir subdomain'den ayrılıyorsanız DNS kaydını ve sertifikasını yaşatın; yönlendirmeler o host'tan sunulur.
4. Yeni konumu Search Console'da doğrulayın, yeni site haritasını gönderin.
5. Eski ve yeni URL'lerin arama sonuçlarında bir arada göründüğü, trafiğin dalgalandığı bir geçiş dönemi bekleyin.
6. Yönlendirmeleri uzun vadede koruyun. Başka sitelerdeki bağlantılar yıllarca eski URL'leri göstermeye devam eder.

Ana sitenin host adına da henüz karar vermediyseniz önce www'lu mu www'suz mu yazısını okuyun: o seçim, çerez kapsamını ve geri kalan her şey için CNAME seçeneklerini belirler.

Sık yapılan hatalar

• Yapıyı bir sıralama söylentisine göre seçip ekipte kimsenin bakımını yapamadığı bir reverse proxy'nin bedelini ödemek.
• Oturum çerezlerini "garanti olsun" diye Domain=example.com ile koymak; böylece çerezler, üçüncü tarafların işlettikleri dahil her alt alan adına teslim edilir.
• Üçüncü taraf bir aracı uygulamanın origin'indeki bir yolun altına yerleştirmek.
• Subdomain'in kendi robots.txt dosyasını, site haritasını ve Search Console kapsamını unutmak.
• Hâlâ düz HTTP konuşan alt alan adlarının dökümünü çıkarmadan includeSubDomains açmak.
• Taşımadan hemen sonra eski subdomain kaydını silmek; yönlendirmeler de onunla birlikte ölür.
• Hazır platformu iptal edip CNAME kaydını zone'da bırakmak.

OrbitProbe ile kontrol edin

OrbitProbe DNS sorgulama aracı bir alt alan adının gerçekte nereyi gösterdiğini canlı sorguyla ortaya koyar: CNAME zinciri, arkasındaki A ve AAAA kayıtları ve TTL değerleri. İşlettiğiniz her host adı için çalıştırıp hangilerinin dış platformlara gittiğini görün; taşımadan sonra da eski adın hâlâ çözümlendiğini, yani yönlendirmelerin çalışmaya devam ettiğini doğrulayın. /blog/ gibi bir yolun kendine ait DNS'i yoktur; onun için önemli olan kayıt, önündeki host'un kaydıdır.