Subdomain mi Alt Dizin mi: SEO Açısından Doğru Yapı

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllardır “subdomain mi kullansak, alt dizin mi?” sorusunu tartışan ekiplerle çalıştım. Her seferinde aynı tablo: geliştiriciler subdomain’i seviyor çünkü izole ortam kurmak kolay, SEO ekibi alt dizin istiyor çünkü “domain authority birikiyor” diyor, proje yöneticisi ikisi arasında sıkışıp kalıyor. Bu yazıda bu kararı teknik altyapı tarafından ele alacağım; yani sadece “hangisi daha iyi” değil, seçtiğiniz yapıyı sunucu tarafında nasıl doğru konfigure edeceğinizi de göstereceğim.

Temel Fark Nedir, Google Ne Düşünüyor?

Google’ın resmi tutumu yıllardır şu: her ikisini de anlıyoruz, her ikisini de crawl edebiliyoruz. Ama bu cevap biraz yanıltıcı. “Anlıyoruz” demek “eşit muamele ediyoruz” anlamına gelmiyor.

Subdomain yapısında blog.sirketim.com ile sirketim.com Google gözünde farklı siteler olabilir. “Olabilir” diyorum çünkü bu kesin değil; Google context’e bakıyor. Ama şunu pratikte gördüm: yeni bir subdomain açtığınızda, o subdomain’in kendi başına otorite kazanması zaman alıyor. Ana domaininizin kazandığı backlink gücü otomatik olarak subdomain’e akmıyor.

Alt dizin yapısında sirketim.com/blog ise ana sitenin domain authority’sinden doğrudan beslendiği için indexleme hızı genellikle daha hızlı, yeni içerik daha çabuk sıralamaya giriyor.

Ama bu kesin bir kural değil. Şimdi gerçek senaryolara bakalım.

Ne Zaman Subdomain Kullanmalısınız?

Subdomain’in mantıklı olduğu durumlar var, bunları görmezden gelmek hata olur:

  • Farklı platformlar: Ana site WordPress, blog Gatsby, forum Discourse üzerinde çalışıyorsa, bunları alt dizinde birleştirmek mimari kabus olur.
  • Farklı diller veya bölgeler: tr.sirketim.com, de.sirketim.com gibi yapılar hreflang yönetimini kolaylaştırır.
  • Staging ve test ortamları: staging.sirketim.com gibi ortamlar her zaman subdomain olmalı, bunları ana siteye dahil etmenin hiçbir mantığı yok.
  • Tamamen farklı ürünler: SaaS bir şirketin ana pazarlama sitesi ile gerçek uygulama paneli farklı hedef kitlelere hitap ediyor. app.sirketim.com ayrı bir ürün gibi davranabilir.

Ne Zaman Alt Dizin Kullanmalısınız?

Eğer şu durumlardan birindeyseniz, alt dizin tercih edin:

  • Ana sitenizle aynı teknolojiyi kullanıyorsunuz.
  • Blog, dokümantasyon veya yardım merkezi gibi içerik üretiyorsunuz ve bu içeriklerin ana sitenizin SEO’sunu güçlendirmesini istiyorsunuz.
  • Tek dil, tek hedef kitle, tek platform.
  • Domain authority’nizi bir yerde toplamak istiyorsunuz.

Nginx ile Alt Dizin Yapılandırması

Alt dizin tercih ettiyseniz ve farklı bir backend servis çalıştırıyorsanız, Nginx reverse proxy ile bunu kolayca yönetebilirsiniz. Örneğin ana site Node.js üzerinde, blog ise Ghost üzerinde çalışıyor olsun:

# /etc/nginx/sites-available/sirketim.com

server {
    listen 80;
    server_name sirketim.com www.sirketim.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name sirketim.com www.sirketim.com;

    ssl_certificate /etc/letsencrypt/live/sirketim.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sirketim.com/privkey.pem;

    # Ana site - Node.js backend
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    # Blog - Ghost backend, ayrı port
    location /blog {
        proxy_pass http://127.0.0.1:2368;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ghost’u bu konfigürasyonla kullanırken dikkat etmeniz gereken nokta: Ghost’un kendi config dosyasında da /blog path’ini belirtmeniz gerekiyor.

# Ghost config dosyasını düzenle
nano /var/www/ghost/config.production.json
# config.production.json içeriği
{
  "url": "https://sirketim.com/blog",
  "server": {
    "port": 2368,
    "host": "127.0.0.1"
  },
  "database": {
    "client": "mysql",
    "connection": {
      "host": "localhost",
      "user": "ghost_user",
      "password": "guclu_sifre",
      "database": "ghost_db"
    }
  },
  "mail": {
    "transport": "Direct"
  },
  "logging": {
    "transports": ["file", "stdout"]
  },
  "process": "systemd",
  "paths": {
    "contentPath": "/var/www/ghost/content"
  }
}

Subdomain Yapılandırması: Apache ile Örnek

Eğer subdomain yolunu seçtiyseniz ve Apache kullanıyorsanız, blog.sirketim.com için ayrı bir virtual host tanımlamanız gerekiyor:

# /etc/apache2/sites-available/blog.sirketim.com.conf

<VirtualHost *:443>
    ServerName blog.sirketim.com
    DocumentRoot /var/www/blog

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/blog.sirketim.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/blog.sirketim.com/privkey.pem

    # Ghost veya WordPress için proxy
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:2368/
    ProxyPassReverse / http://127.0.0.1:2368/

    ErrorLog ${APACHE_LOG_DIR}/blog-error.log
    CustomLog ${APACHE_LOG_DIR}/blog-access.log combined
</VirtualHost>

<VirtualHost *:80>
    ServerName blog.sirketim.com
    Redirect permanent / https://blog.sirketim.com/
</VirtualHost>

Subdomain için Let’s Encrypt sertifikası alırken wildcard veya subdomain özelinde sertifika almanız gerekiyor:

# Wildcard sertifika - DNS challenge gerektirir
certbot certonly --manual --preferred-challenges dns 
  -d sirketim.com 
  -d *.sirketim.com

# Sadece blog subdomain için
certbot --apache -d blog.sirketim.com

Mevcut Subdomain’i Alt Dizine Taşımak

Bu, en kritik senaryolardan biri. blog.sirketim.com üzerinde yıllardır içerik ürettiniz, artık sirketim.com/blog‘a taşımak istiyorsunuz. Yanlış yaparsanız mevcut SEO değerinizi mahvedebilirsiniz.

Doğru yaklaşım 301 redirect. Ama burada ince bir nokta var: redirect’i mümkün olan en uzun süre ayakta tutun. Google’ın redirect zincirini tamamen işlemesi haftalar hatta aylar alabilir.

# Nginx ile subdomain'den alt dizine 301 redirect
# /etc/nginx/sites-available/blog.sirketim.com

server {
    listen 443 ssl http2;
    server_name blog.sirketim.com;

    ssl_certificate /etc/letsencrypt/live/blog.sirketim.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.sirketim.com/privkey.pem;

    # Tum URL'leri alt dizine yonlendir
    # blog.sirketim.com/makale-adi -> sirketim.com/blog/makale-adi
    location / {
        return 301 https://sirketim.com/blog$request_uri;
    }
}

server {
    listen 80;
    server_name blog.sirketim.com;
    return 301 https://sirketim.com/blog$request_uri;
}

Bu konfigürasyonla blog.sirketim.com/nginx-rehberi isteği otomatik olarak sirketim.com/blog/nginx-rehberi adresine yönlenecek. $request_uri değişkeni path ve query string’i olduğu gibi taşıyor.

Canonical Tag ile Çift İçerik Sorununu Çözmek

Bazen her iki yapıyı da aynı anda çalıştırmak zorunda kalırsınız; geçiş sürecinde ya da teknik kısıtlar nedeniyle. Bu durumda canonical tag hayat kurtarıyor. Örneğin WordPress kullandığınızda wp-config.php veya .htaccess ile bunu kontrol edebilirsiniz, ama en güvenilir yol sunucu tarafında header eklemek:

# Nginx ile canonical header ekleme
# Subdomain uzerindeki tum sayfalara canonical header ekle

server {
    listen 443 ssl http2;
    server_name blog.sirketim.com;

    location ~* .php$ {
        # PHP handler ayarlari
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;

        # Her PHP response'a canonical header ekle
        # Not: Bu yaklasim tum sayfalar icin ayni canonical verir
        # Sayfa bazli canonical icin uygulama katmaninda yapilmali
        add_header Link '<https://sirketim.com/blog>; rel="canonical"';
    }
}

Gerçek dünyada canonical tag’i uygulama katmanında yönetmek daha doğru; sunucu tarafında her sayfa için farklı canonical vermek çok karmaşık hale geliyor. Ama sitemap ve robots.txt tarafında sunucu konfigürasyonunun önemi büyük.

robots.txt ve Sitemap Yönetimi

Alt dizin yapısında her şey tek robots.txt ve tek sitemap altında toplanabilir. Subdomain yapısında her subdomain kendi robots.txt ve sitemap dosyasına ihtiyaç duyuyor.

# Ana site robots.txt - /var/www/html/robots.txt
# Alt dizin yapisi icin

User-agent: *
Allow: /

# Blog alt dizinine izin ver
Allow: /blog/

# Admin panellerini engelle
Disallow: /wp-admin/
Disallow: /blog/wp-admin/
Disallow: /admin/

# Sitemap konumu
Sitemap: https://sirketim.com/sitemap.xml
Sitemap: https://sirketim.com/blog/sitemap.xml
# Subdomain yapisinda blog.sirketim.com/robots.txt
# /var/www/blog/robots.txt

User-agent: *
Allow: /

Disallow: /wp-admin/
Disallow: /ghost/

# Subdomain icin ayri sitemap
Sitemap: https://blog.sirketim.com/sitemap.xml

Performans: Alt Dizin vs Subdomain

SEO dışında bir faktör daha var: CDN konfigürasyonu. Cloudflare veya benzeri bir CDN kullanıyorsanız, subdomain’ler için ayrı cache kuralları yazabilirsiniz, bu bazen avantaj. Alt dizin yapısında ise URL pattern bazlı cache kuralları yazmak gerekiyor.

Cloudflare Page Rules veya Cache Rules ile alt dizin optimizasyonu:

# Cloudflare API ile cache kuralı ekleme ornegi
# Bu bash script Cloudflare API'yi kullanir

ZONE_ID="your_zone_id"
API_TOKEN="your_api_token"

curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/pagerules" 
     -H "Authorization: Bearer ${API_TOKEN}" 
     -H "Content-Type: application/json" 
     --data '{
       "targets": [
         {
           "target": "url",
           "constraint": {
             "operator": "matches",
             "value": "sirketim.com/blog/*"
           }
         }
       ],
       "actions": [
         {
           "id": "cache_level",
           "value": "cache_everything"
         },
         {
           "id": "edge_cache_ttl",
           "value": 86400
         }
       ],
       "status": "active",
       "priority": 1
     }'

Google Search Console’da Doğrulama

Hangi yapıyı seçerseniz seçin, Google Search Console’da doğru konfigürasyon şart. Alt dizin yapısında ana domain’i doğrulayınca /blog otomatik dahil oluyor. Subdomain’de ise ayrıca doğrulama gerekiyor.

DNS TXT kaydı ile domain doğrulama hem ana domain hem subdomain için çalışır:

# DNS TXT kaydı kontrol
dig TXT sirketim.com
dig TXT blog.sirketim.com

# Beklenen cikti
# sirketim.com. 3600 IN TXT "google-site-verification=xxxxx"
# blog.sirketim.com. 3600 IN TXT "google-site-verification=yyyyy"

Search Console’da subdomain kullanıyorsanız iki ayrı property oluşturmanız ve her birini izlemeniz gerekiyor. Bu zamanla karmaşıklaşabilir; özellikle birden fazla subdomain varsa.

Gerçek Dünya Senaryosu: Hangi Yapının Kazandığını Gördüm

Bir e-ticaret müşterisinde yardım merkezi içerikleri yardim.sirketim.com üzerinde yıllarca tutulmuştu. Organik trafik durağandı, rakipler ise benzer içerikleri ana domain’in alt dizininde yayınlayıp bizden daha üst sıralarda yer alıyordu.

Taşıma kararı aldık. yardim.sirketim.com üzerindeki yaklaşık 400 sayfa sirketim.com/yardim/ altına taşındı. 301 redirect’ler yerleşti, eski subdomain 6 ay daha redirect sunucusu olarak ayakta kaldı. Search Console’da dönüşüm izlendi.

Sonuç: Taşımadan 3 ay sonra yardım içeriklerinin organik trafiği yüzde 40 arttı. Bunun tamamı taşımanın etkisi mi? Kesin söylemek zor, çünkü aynı dönemde içerik güncellemesi de yapıldı. Ama subdomain döneminde hiç görülmemiş anahtar kelimelerde sıralamaya girildi.

Bu tür gözlemler, alt dizin avantajının gerçek olduğunu gösteriyor. Ama her durum farklı.

Karar Verme Sürecini Basitleştirmek

Ekibinizle tartışırken şu soruları sorun:

  • Aynı sunucuda mı çalışacak? Evet ise alt dizin teknik olarak daha kolay.
  • Farklı ekipler mi yönetecek? Subdomain izolasyon sağlar, deployment bağımsızlığı verir.
  • İçerik ana ürünü destekliyor mu? Blog, rehber, yardım merkezi gibi içerikler için alt dizin tercih edin.
  • Tamamen farklı bir ürün mü? App, panel, API dokümantasyonu için subdomain makul.
  • Uluslararası hedefleme var mı? Ülke subdomainleri veya ccTLD’ler daha mantıklı olabilir.

Sonuç

Bu tartışmanın “doğru cevabı” yok ama pratikte gördüğüm şu: teknik karar, SEO kararından önce gelmemeli. Önce içeriğin amacını ve hedef kitlesini belirleyin, sonra teknik altyapıyı buna göre şekillendirin.

Eğer içerik ana ürününüzün parçasıysa ve aynı platformda yönetiliyorsa, alt dizin hem teknik hem SEO açısından daha temiz bir çözüm. Eğer farklı bir platform, farklı bir ekip veya farklı bir ürün söz konusuysa, subdomain’in izolasyon avantajları SEO maliyetini telafi edebilir.

En kötü senaryo ikisi arasında gidip gelmek: bugün subdomain kurup, altı ay sonra taşıyıp, bir yıl sonra tekrar subdomain’e dönmek. Her taşıma hem teknik iş yükü hem potansiyel SEO riski demek. Kararı bir kez verin, doğru konfigüre edin, uzun vadede tutarlı kalın.

Sunucu tarafında doğru konfigürasyon kadar önemli olan şey şu: seçtiğiniz yapıyı tüm bileşenleriyle tutarlı şekilde uygulamak. Nginx config’inizde, sitemap’inizde, robots.txt’inizde, Search Console’unuzda ve internal link yapınızda hepsi birbiriyle uyumlu olmalı. Yarım kalmış bir konfigürasyon, yanlış seçilmiş bir yapıdan daha fazla zarar verir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir