Blog, Mağaza ve Landing Page İçin Subdomain mi Klasör mü? SEO, Hosting ve CDN Karar Rehberi

Neyi Nereye Koyduğunuz Neden Bu Kadar Önemli?

Blogunuzu, mağazanızı veya kampanya landing page’lerinizi nereye konumlandıracağınız çoğu zaman tasarım toplantılarında son dakikaya kalan bir karar oluyor: blog.site.com mu, yoksa site.com/blog/ mü? Mağaza için shop.site.com mu, site.com/magaza/ mı? Pazarlama ekibi çoğunlukla marka tutarlılığına, ajans teknik ekibi URL düzenine, SEO tarafı ise otoriteye odaklanıyor. Altyapı tarafında biz ise DCHost ekibi olarak bunun sadece bir URL kozmetiği değil, DNS, SSL, CDN, cache, güvenlik ve izleme boyutları olan bir mimari kararı olduğunu görüyoruz.

Bu yazıda; blog, mağaza ve landing page özelinde subdomain (alt alan adı) ile klasör (alt dizin) tercihini; SEO etkileri, hosting yönetimi, CDN ve performans mimarisi üzerinden detaylı şekilde ele alacağız. Zaten yayında bir siteniz varsa, yanlış kararla SEO kaybı yaşamamak için yönlendirme ve geçiş stratejilerine de değineceğiz. Daha önce ele aldığımız subdomain vs alt dizin karşılaştırması yazımızı genişleten, daha mimari odaklı bir rehber olarak düşünebilirsiniz.

Hedefimiz; “herkes subdomain kullanıyor” ya da “SEO için her şeyi klasöre alın” gibi ezbere cümleler yerine, farklı senaryolara göre uygulanabilir karar modelleri vermek. Böylece ister paylaşımlı hosting, ister VPS, dedicated sunucu veya colocation kullansın, DCHost üzerinde barındırdığınız projelerde tutarlı ve ölçeklenebilir bir yapı kurabilirsiniz.

Subdomain ve Klasörün Teknik Farkları

Önce kavramları netleştirelim. Örnek bir alan adımız olsun: site.com.

• Klasör (alt dizin): site.com/blog/, site.com/magaza/, site.com/kampanya/indirim/
• Subdomain (alt alan adı): blog.site.com, shop.site.com, kampanya.site.com

Gözünüze benzer görünebilir ama altyapıda ciddi farklar yaratırlar.

DNS, SSL ve Barındırma Ayrımı

Klasörler, domain ile aynı DNS kaydını ve genellikle aynı web sunucusunu paylaşır. Yani site.com ve site.com/blog/ aynı IP’ye gider. Bu, paylaşımlı hosting veya basit bir VPS üzerinde yönetimi kolaylaştırır.

Subdomain’de ise her alt alan için ayrı DNS kaydı tanımlarsınız:

• A site.com → 203.0.113.10
• A blog.site.com → 203.0.113.10 (aynı sunucu) ya da
• A shop.site.com → 203.0.113.20 (farklı sunucu)

Bu esneklik sayesinde blog, mağaza ve ana sitenizi tamamen farklı sunucularda barındırabilirsiniz. DCHost üzerinde bir projeyi paylaşımlı hosting’te, diğerini ayrı bir VPS’te veya dedicated sunucuda koşturmak istediğinizde subdomain mimarisi çok işe yarar.

SSL tarafında da durum benzer. Wildcard SSL (örneğin *.site.com) ile çok sayıda subdomain’i tek sertifikayla kapsayabilirsiniz. Bir yandan da Let’s Encrypt otomatik SSL süreçleri devreye girer. Klasör yapısında ise tek bir sertifika tüm dizinleri kapsar; yönetim daha basittir ama altyapısal ayrıştırma yapmanız zorlaşır.

Çerezler, Oturumlar ve Login Paylaşımı

Tarayıcı çerezleri (cookies), hangi alan adında set edildiğinize göre çalışır. Örneğin:

• Domain=site.com çerezi → site.com ve tüm alt alanlarda (blog.site.com, shop.site.com…) geçerli olabilir.
• Domain=blog.site.com çerezi → sadece blog subdomain’inde geçerlidir.

Bu neye etki eder?

• Tek oturum ile hem ana site hem mağazada login kalmak istiyorsanız; çerez domain’ini ve mimariyi buna göre tasarlamalısınız.
• Güvenlik gereği, admin paneli için ayrı subdomain kullanıp çerezleri sadece orada geçerli kılabilirsiniz.

Tek uygulamalı klasör yapısında (örneğin tek WordPress veya Laravel kurulumunda /blog, /magaza gibi) oturum paylaşımı doğası gereği daha basittir. Mikroservis veya farklı teknoloji stack’leri kullanıyorsanız, subdomain tarafı yönetilebilirliği artırır.

Loglama, Güvenlik ve İzleme

Subdomain tercih ettiğinizde:

• Her alt alan adını ayrı sanal host olarak konumlandırabilir, ayrı access/error log tutabilirsiniz.
• WAF kuralları, rate limiting, IP kısıtlaması gibi güvenlik politikalarını alt alan bazında ayırabilirsiniz.
• Uptime izleme, performans ölçümü ve alarm kurallarını her subdomain için ayrı ayrı yapılandırabilirsiniz.

Klasör yapısında da benzer granülerlik mümkün; ancak genelde tek uygulama ve tek log akışı olduğu için sorun tespiti biraz daha emek ister. Yüksek trafikli yapılarda, merkezi loglama ve izleme senaryolarında subdomain segmentasyonu hayli işe yarar.

SEO Perspektifinden Subdomain mi Klasör mü?

Teknik tarafı bir kenara koyup SEO açısından bakalım. Klasik özet şöyle anlatılır: “Google subdomain’i ayrı site gibi görür, klasör ise ana domainin parçasıdır.” Bu ifade hem doğru hem eksik.

Otorite, Backlink ve Domain Gücü

SEO’da kritik metriklerden biri, domain’in genel otoritesidir (farklı araçlarda farklı isimlerle ölçülür). Genel kabul gören yaklaşım şudur:

• Klasör: site.com/blog/ üzerinde ürettiğiniz içerik, backlink’ler ve trafik; site.com’un genel otoritesine daha doğal ve hızlı katkı sağlar.
• Subdomain: blog.site.com daha bağımsız bir site gibi yorumlanır; otoritesini ayrı ayrı inşa etmeniz gerekir, ancak yine de ana domainle bağ güçlü ise tamamen kopuk değildir.

Eğer hedefiniz; markanızı tek domain altında güçlendirmek ve blog/icerik pazarlaması ile ana domaini beslemekse, çoğu senaryoda blog için klasör (örneğin site.com/blog/) daha avantajlıdır.

Blog İçin: Kural Değil Ama Güçlü Bir Tavsiye

Pratikte gördüğümüz şu: Blog, dokümantasyon, yardım merkezi gibi içerik zenginliği sağlayan kanalları alt dizinde (klasör) konumlandıran siteler, uzun vadede ana domain otorisini beslemede daha net bir avantaj yakalıyor. Yine de bazı durumlarda subdomain daha mantıklı olabilir:

• Blog tamamen farklı bir teknoloji stack’i ile çalışıyor (örneğin Ghost veya statik site), ana site bambaşka bir framework üzerinde.
• Blog ekibi ayrı bir altyapı, deploy süreci ve güvenlik politikası kullanmak istiyor.
• Farklı diller için blog’u coğrafi subdomain’lere bölmek istiyorsunuz (ör. blog-en.site.com).

Eğer bu tip mimari ihtiyaçlar yoksa, “blogu klasörde tutmak” genellikle daha sade ve SEO açısından daha verimli bir yoldur. Bu noktada; URL yapısı değişikliği yapacaksanız, SEO kaybı olmadan 301 yönlendirme yapma rehberimize mutlaka göz atmanızı öneririz.

Mağaza (E‑ticaret) İçin Mimari Tercihler

Mağaza tarafı biraz daha kritik, çünkü:

• Performans baskısı daha yüksektir (ürün listeleme, filtre, sepet, ödeme).
• Güvenlik, PCI-DSS uyumu, ödeme sayfaları gibi ek gereksinimler vardır.
• Özel bir altyapı ve ölçeklenebilirlik ihtiyacı doğar.

Senaryolar:

1. Küçük/orta ölçekli mağaza + kurumsal site: Ana domain WordPress kurumsal site, mağaza WooCommerce veya basit bir e-ticaret eklentisi ise site.com/magaza/ veya site.com/shop/ klasör yapısı genellikle idealdir. SEO açısından tüm otorite tek domain üzerinde toplanır.
2. Büyük katalog, yüksek trafik: Mağaza motoru (Magento, özel yazılım vb.) için ayrı bir altyapı, veritabanı replikasyonu, cache katmanı kurgulamak istiyorsanız shop.site.com gibi ayrı bir subdomain’e taşımak operasyonel olarak işleri kolaylaştırabilir. Burada SEO kaybı yaşamamak için 301 ve içerik stratejisi hayati önem taşır.

Özetle: “Mağaza kesinlikle subdomain olmalı” ya da “mutlaka klasör olmalı” diye evrensel bir kural yok. Tercih; büyüklük, teknoloji seti ve güvenlik/regülasyon ihtiyaçlarına göre değişmelidir.

Landing Page ve Kampanya Sayfaları

Landing page’ler (özellikle reklam ve kısa süreli kampanyalar için) çoğu zaman hızlı kurulup hızlı kapanan yapılardır. Burada iki ana seçenek çıkar:

• Klasör: site.com/kampanya/yeni-urun/
• Subdomain: yeni-urun.site.com

SEO ağırlıklı, uzun vadeli bir sayfa ise genelde klasör kullanmak daha mantıklıdır. Ama pazarlama ekibi farklı bir tasarım sistemi, farklı bir Javascript framework’ü ve A/B test altyapısı kurmak istiyorsa, landing page’leri ayrı bir subdomain altında toparlamak (örn. campaign.site.com) daha yönetilebilir hale gelebilir.

Uluslararası SEO, Dil Sürümleri ve Hreflang

Farklı diller ve ülkeler için çok sayıda blog, mağaza ve landing page yönetiyorsanız, konu daha da karmaşıklaşır. ccTLD (ülke uzantısı), subdomain ve alt dizin kombinasyonlarını doğru kurgulamak için hreflang’i doğru kurma rehberimize mutlaka göz atın. Orada; ccTLD, alt dizin ve alt alan seçeneklerinin uluslararası SEO’ya etkilerini detaylandırdık.

Hosting Mimarisi ve Yönetim Açısından Etkiler

SEO tarafını bir kenara bırakıp, işin operasyonel boyutuna bakalım. DCHost tarafında günlük olarak gördüğümüz en yaygın karar noktası şu: “Tüm siteyi tek hosting hesabında mı toplayalım, yoksa blog, mağaza ve kampanyaları farklı sunuculara mı dağıtalım?”

Paylaşımlı Hosting: Basit Projeler İçin Klasör Avantajı

Küçük işletmeler, kişisel bloglar ve basit katalog siteleri için paylaşımlı hosting halen oldukça mantıklı. Bu senaryoda:

• Tek bir cPanel/DirectAdmin hesabınız vardır.
• Root SSH erişimi genelde yoktur.
• Tek uygulama (örneğin WordPress) ile hem kurumsal siteyi, hem blogu, hem mağazayı yürütmek istersiniz.

Bu durumda ayrı ayrı subdomain + ayrı uygulama kurmak, yönetim yükünü artırır. Klasör yapısı (örn. /blog, /magaza) hem maliyet hem operasyon açısından daha hafif olur. Paylaşımlı hosting’te kaynakları doğru kullanmak için cPanel kaynak limitleri ve Resource Limit Reached hatasını önleme yazılarımızı da inceleyebilirsiniz.

VPS ve Dedicated Sunucular: Ayrı Uygulamalar, Ayrı Subdomain’ler

Projeler büyüdükçe; blog, mağaza ve uygulama panellerini farklı servisler haline getirmek çoğu zaman zorunlu hale gelir. Örneğin:

• Blog: WordPress (PHP, MySQL)
• Mağaza: Laravel + Vue.js tabanlı özel uygulama
• Landing page: statik HTML + Tailwind + küçük bir Node.js API

Bu yapıyı tek domain altında tek sunucuda zorlamak yerine, her bileşeni ayrı bir VPS veya dedicated sunucuya dağıtıp subdomain ile yönlendirmek çok daha sağlıklıdır. Böylece:

• CPU/RAM disk kotalarını her servis için ayrı ayrı planlarsınız.
• Bakım ve deploy süreçlerinde (örneğin blog güncellemesi) mağazayı etkilemezsiniz.
• Güvenlik açığı veya DDoS saldırısı bir servisi hedef aldığında diğerleri etkilenmez.

Büyük ajans veya çok siteli yapılarda bu konuyu daha geniş ele aldığımız ajanslar için hosting mimarisi rehberinde de, subdomain + çoklu sunucu yaklaşımının pratik avantajlarını bulabilirsiniz.

Colocation ve Karmaşık Altyapılar

Kendi fiziksel sunucularını veri merkezinde barındıran (colocation) veya karmaşık cluster mimarileri kullanan yapılarda subdomain, servis sınırlarını tanımlamak için adeta bir harita işlevi görür:

• api.site.com → API kümesi
• shop.site.com → e-ticaret front-end
• cdn.site.com → statik dosya/medya sunucuları
• panel.site.com → yönetim paneli

Bu sayede; ağ topolojisi, firewall kuralları, load balancer konfigürasyonları ve log/izleme sistemleri de bu alt alan adları üzerinden net bir şekilde tanımlanır. DCHost’ta colocation veya yüksek erişilebilirlik senaryoları kurgularken, subdomain hiyerarşisini bu gözle tasarlamayı öneriyoruz.

CDN, Medya ve Performans Boyutu

Blog, mağaza ve landing page’lerin performansını konuşurken; CDN (Content Delivery Network), statik dosyalar ve görsel optimizasyonu göz ardı etmek mümkün değil. Özellikle Core Web Vitals metriklerini iyileştirmek istiyorsanız, alt alan adları burada stratejik bir rol oynuyor.

Statik Dosyalar İçin Ayrı Subdomain Kullanmak

Geleneksel yaklaşım, statik içerikleri (görseller, CSS, JS) cdn.site.com gibi ayrı bir subdomain üzerinden servis etmektir. Bunun bazı avantajları:

• Tarayıcıya “bu alan sadece statik içerik” sinyali verilir; çerez yükü azalır.
• CDN’ler genelde alt alan üzerinden konumlandırıldığı için konfigürasyon basitleşir.
• Statik dosyaları farklı bir sunucu veya object storage üzerinde tutup ana sunucunun yükünü azaltabilirsiniz.

Özellikle görsel ağırlıklı sitelerde bu konuyu görsel SEO ve CDN alt alan adları yazımızda detaylandırdık. Burada; WebP/AVIF dönüşümü, görsel site haritaları ve alt alan stratejisinin arama motoru trafiğine doğrudan etkilerini bulabilirsiniz.

CDN, Coğrafi Yayılım ve Çok Bölgeli Mimari

Kullanıcılarınız farklı ülkelerden geliyorsa, sadece tek sunucu üzerinde durmak yerine CDN + çok bölgeli DNS stratejilerini düşünmek gerekir. Statik içerikleri subdomain üzerinden CDN’e vermek; hem yapılandırmayı sadeleştirir, hem de ileride çok bölgeli mimariye geçmek istediğinizde işinizi kolaylaştırır.

Bu konuda iki yazımız doğrudan işinize yarayacaktır:

• CDN nedir, ne zaman gerekir? – CDN’e gerçekten ihtiyacınız olup olmadığını anlamak için karar rehberi.
• GeoDNS ve çok bölgeli hosting mimarisi – Farklı bölgelerdeki kullanıcıları en yakın sunucuya yönlendirme stratejileri.

Blog, mağaza ve landing page’lerinizi farklı subdomain’lere dağıtıyor olmanız, CDN kurgusunu da esnekleştirir. Örneğin sadece cdn.site.com ve img.site.com için CDN açıp, dinamik uygulamaları doğrudan origin sunucudan servis edebilirsiniz.

Core Web Vitals ve URL Mimarisi

Google’ın Core Web Vitals metrikleri (TTFB, LCP, CLS vb.) artık sıralama faktörleri arasında. URL mimariniz, bu metrikleri doğrudan etkilemez; ama altyapı tasarımınızı etkilediği için dolaylı yoldan büyük rol oynar. Örneğin:

• Blogu alt dizinde tutup tek güçlü VPS’te koşturmak, TTFB’yi düşürmenize yardımcı olabilir.
• Mağazayı ayrı subdomain’de ayrı bir optimizasyon seti ile çalıştırmak, checkout performansını iyileştirebilir.
• Görselleri CDN alt alanına taşıyarak LCP’yi anlamlı ölçüde düşürebilirsiniz.

Bu konuları daha teknik seviyede ele aldığımız Core Web Vitals ve hosting altyapısı rehberini de okumanızı öneririm.

Farklı Senaryolar İçin Karar Modelleri

Teoriyi bir kenara bırakıp, pratik senaryolar üzerinden ilerleyelim. Aşağıdaki örnekler; DCHost’ta sık karşılaştığımız durumların sadeleştirilmiş özetleri.

1) Küçük İşletme: Kurumsal Site + Blog

Durum: Tek dilde web sitesi, referanslar, hizmetler ve düzenli içerik üreten bir blog. Trafik orta düzey, tek ekibiniz var.

• Öneri: Kurumsal site ve blogu tek WordPress kurulumu altında site.com/blog/ olarak kullanın.
• Hosting: Güçlü bir paylaşımlı hosting planı veya küçük/orta kaynaklı bir VPS yeterli olur.
• SEO: Tüm içerik otoriteyi site.com üzerinde toplar.

Burada subdomain açmak genellikle gereksiz karmaşıklık yaratır. Sadece staging veya test ortamı için staging.site.com gibi subdomain’ler kullanmak mantıklıdır.

2) Büyüyen E‑Ticaret: Kurumsal Site + Büyük Mağaza

Durum: Markanız güçlenmiş, ürün gamı büyümüş, mağaza yazılımı ayrı bir ekip tarafından geliştiriliyor. Yüksek sayıda ürün, filtreleme, kampanya ve yoğun kampanya dönemleri var.

• Öneri (başlangıç): Mağazayı site.com/magaza/ altında başlatmak; SEO otoritesi için avantajlıdır.
• Öneri (ölçeklenme aşaması): Trafik ve kaynak ihtiyacı ciddi şekilde artmaya başladığında, mağazayı shop.site.com gibi ayrı bir subdomain’e taşıyıp; kendi VPS veya dedicated sunucusuna almak mantıklı hale gelir.
• Dikkat: Geçişte 301 yönlendirme, canonical etiketleri ve site haritalarını titizlikle güncellemek gerekir.

Burada; PCI-DSS gibi regülasyon, log saklama politikaları ve performans hedeflerine göre PCI-DSS uyumlu e-ticaret hosting rehberinde anlattığımız ilkeleri de devreye almak gerekir.

3) SaaS Ürünü: Uygulama + Marketing Site + Blog + Landing Page

Durum: Ana ürününüz SaaS; React/SPA + API altyapısı üzerinde çalışıyor. Bunun yanında pazarlama sitesi, blog ve çok sayıda kampanya landing page’iniz var.

Bu tarz yapılarda, sık gördüğümüz başarılı mimari şöyle:

• site.com → Marketing site (WordPress veya statik site)
• app.site.com → Uygulama
• blog.site.com veya site.com/blog/ → Blog (kararı SEO stratejinize göre verin)
• go.site.com veya campaign.site.com → Landing page ve izleme/redirect altyapısı

Burada kritik nokta, oturum ve güvenlik sınırlarını net çizmektir. Uygulama tarafında authentication çerezlerini sadece app.site.com alanında geçerli tutmak, marketing ve kampanya tarafını tamamen izole etmek genellikle en iyi uygulamadır.

4) Çok Dilli Kurumsal Site + Blog + Bölgesel Landing Page’ler

Durum: Birden fazla dilde içerik, bölgesel kampanyalar ve her ülke için ayrı landing page’leriniz var.

• Dil sürümlerini alt dizinlerle yönetmek: site.com/tr/, site.com/en/, site.com/de/
• Blogları dil dizinleri altında konumlandırmak: site.com/en/blog/, site.com/de/blog/
• Bölgesel landing page’leri ilgili dil dizini içinde tutmak: site.com/tr/kampanyalar/

Bu yaklaşım; hreflang, canonical ve site haritası yönetimini sadeleştirir. Eğer her ülke için ayrı ekip, ayrı altyapı veya yerel regülasyon gereksinimleri varsa; o zaman ülke bazlı subdomain veya ccTLD stratejisine geçmek değerlendirilebilir.

Uygulanabilir Kontrol Listesi ve Özet

Kararı verirken elinizde net bir checklist olsun istiyorsanız, aşağıdaki soruları tek tek yanıtlayın. Çoğuna “evet” diyorsanız, o madde sizi subdomain veya klasör yönüne iter.

Klasör (Alt Dizin) Tercihini Güçlendiren Sorular

• Blog/mağaza/landing page’lerinizin hepsi aynı ekip tarafından mı yönetiliyor?
• Hepsi aynı teknoloji üzerinde mi (örneğin tek WordPress, tek Laravel monolit)?
• SEO açısından tüm otoriteyi tek domain üzerinde toplamak kritik mi?
• Paylaşımlı hosting gibi basit ve ekonomik bir mimari kullanmak istiyor musunuz?
• Uygulamalar arasında kompleks oturum paylaşımları veya mikroservis mimarisi yok mu?

Bu soruların çoğuna “evet” diyorsanız; blog, mağaza ve landing page’leri alt dizin olarak konumlandırmak (örneğin site.com/blog/, site.com/magaza/, site.com/kampanya/) genellikle daha sağlıklı olacaktır.

Subdomain Tercihini Güçlendiren Sorular

• Blog, mağaza ve uygulamalarınız farklı teknolojiler veya framework’ler mi kullanıyor?
• Her birini farklı VPS, dedicated veya colocation altyapısında ayrı ayrı ölçeklendirmek istiyor musunuz?
• Her alt alan için farklı güvenlik politikaları (WAF kuralları, IP kısıtlaması, mTLS, vs.) mı gerekli?
• Görsellere, statik içeriklere veya API’lere özel CDN ve cache politikaları tanımlamak istiyor musunuz?
• Takımlarınız ve deploy süreçleriniz birbirinden bağımsız mı (örneğin ürün ekibi, marketing ekibi, altyapı ekibi ayrı)?

Bu soruların çoğuna “evet” diyorsanız; blog, mağaza ve landing page’ler için subdomain tabanlı bir hiyerarşi (örneğin blog.site.com, shop.site.com, campaign.site.com) mimari olarak daha sürdürülebilir olacaktır.

Son Söz ve DCHost Tarafında Nasıl İlerleyebilirsiniz?

Subdomain mi klasör mü sorusunun tek bir doğru cevabı yok; doğru olan, iş hedefleriniz, ekip yapınız ve teknik altyapınızla uyumlu karar. Küçük bir blog için alt dizin yeterli olurken, büyüyen bir SaaS için subdomain’lerle ayrılmış çok katmanlı bir mimari şart hale gelebilir.

DCHost olarak; basit kurumsal sitelerden, yüksek trafikli e‑ticaret ve SaaS projelerine kadar geniş bir yelpazede paylaşımlı hosting, VPS, dedicated ve colocation altyapıları sunuyoruz. Yeni bir proje planlıyor ya da mevcut yapınızı subdomain/klasör ekseninde yeniden tasarlamayı düşünüyorsanız, mimari tasarım aşamasında birkaç saatlik doğru planlamanın size aylarca sürecek sorunları önleyebileceğini rahatlıkla söyleyebilirim.

İsterseniz mevcut URL yapınızı, SEO risklerini, hosting ve CDN konfigürasyonunuzu birlikte gözden geçirip; blog, mağaza ve landing page’leriniz için en dengeli mimariyi netleştirebiliriz. Böylece hem arama motoru görünürlüğünüzü, hem de altyapı esnekliğinizi uzun vadeli bir plana oturtmuş olursunuz.