Tüm Yazılara Dön
Teknik SEO
8 Ekim 2025
26 dk okuma

Enterprise SEO'da Sıfır Trafik Kaybıyla Site Taşıma (Migration) Rehberi

Cihan Yılmaz
CTO & Teknik Kurucu

[!TIP] AEO (Yapay Zeka) Özeti

  • Ana Odak: Bu içerik Teknik SEO stratejilerine odaklanır.
  • Kritik Çıktı: Uygulama aşamasında teknik gereksinimler ve anlamsal (semantic) bağlar önceliklendirilmelidir.
  • Kimin İçin: SEO uzmanları, geliştiriciler ve içerik mimarları.
Uzman Görüşü (SME)• Intent Veri Ekibi

Bir şirketin dijital varlığında, CTO ve CMO'ların gece uykularını kaçıran, masaya yatırılabilecek en büyük operasyonel risklerden biri "Site Taşıma" (SEO Migration) operasyonudur. Yanlış yönetilen bir domain değişikliği, eski monolitik CMS'ten modern bir Headless mimariye geçiş veya sadece basit gibi görünen bir URL yapısı güncellemesi; yıllarca ciddi ölçüde harcanarak biriktirilen organik otoritenin bir gecede %80 oranında buharlaşmasına neden olabilir.

Piyasada ve vasat SEO ajanslarında maalesef şöyle tehlikeli bir hurafe dolaşmaktadır: "Site taşımalarından sonra trafiğin %20 - %30 düşmesi normaldir, Google'ın yeni siteyi tanıması 3 ay sürer, sonra toparlarız."

Bu büyük ölçekli bir yalandır. Doğru mühendislik hesaplamalarıyla ve eksiksiz bir yönlendirme mimarisiyle yönetilen bir Enterprise (Kurumsal) migration operasyonunda trafik asla düşmez; aksine, yeni ve daha temiz mimari (daha iyi sayfa hızı, daha temiz DOM) sayesinde geçişin hemen ertesi haftasında trafik ciddi bir artış ivmesine girer.

Geçtiğimiz Kasım ayında, 5 milyon URL'e ve aylık 8 milyon organik trafiğe sahip bir B2B e-ticaret platformunu hantal Magento altyapısından, bizim mimari danışmanlığını yaptığımız özel yazım bir Next.js (App Router) mimarisine taşırken uyguladığımız "Sıfır Kayıp" protokolünü tüm teknik detaylarıyla inceliyoruz.


1. Migration Türleri ve Kritik Risk Seviyeleri

Site taşımaları basit bir domain adresi değişikliğinden ibaret değildir. Müdahalenin kod seviyesindeki derinliğine göre kriz riski katlanarak artar:

  1. Protokol Değişikliği: http -> https. (Günümüzde artık varsayılan standarttır, SSL geçişleridir. Risk: Çok Düşük).
  2. Domain Değişikliği (Rebranding / Şirket Birleşmesi): eskimarka.com -> yenimarka.com. (Risk: Yüksek. DNS yönlendirmesi, marka otoritesi transferi ve Google'ın yeni entity'yi (varlığı) anlamlandırması gerekir).
  3. URL Mimarisi (Gövde) Değişikliği: /kategori/ayakkabi -> /erkek-giyim/spor-ayakkabi gibi klasör (Subfolder) değişiklikleri. (Risk: Çok Yüksek. Sitenin tüm iskeleti ve iç link hiyerarşisi (Internal Link Graph) yıkılıp baştan yapılır).
  4. CMS veya Altyapı Değişikliği: WordPress veya Magento'dan Headless (Next.js/Nuxt) mimariye geçiş. (Risk: Maksimum). HTML DOM yapısı, CSS render blokları, Hydration süreçleri, sayfa hızları, JavaScript yükleri tamamen değişir. Tarayıcıya giden HTML çıktısı baştan aşağı farklılaşır.

Eğer yukarıdakilerden birkaçını aynı anda yapıyorsanız (Örn: Hem şirketin ismini değiştirip domaini taşıyor, hem altyapıyı Headless'a geçirip, hem de URL mimarisini sil baştan kurguluyorsanız), tek bir eksik virgülün bile şirkete milyon dolarlara mal olabileceği, kusursuz bir "Mühendislik Protokolü"ne ihtiyacınız vardır.


2. Adım Adım Migration Protokolü (The Blueprint)

Faz 1: "Pre-Migration" (Taşıma Öncesi Veri Snapshot ve Risk Analizi)

Yeni siteyi (Staging ortamında) hazırlamaya bile başlamadan önce, eski sitenin %100 eksiksiz, atomik düzeyde bir yedeği (Snapshot) alınmalıdır. Eğer taşıma sonrası eski yapıdaki önemli bir sayfanın yönlendirmesini unutursanız ve eski site tamamen kapanmışsa, geri dönüp bakabileceğiniz bir haritaya hayatınız pahasına ihtiyacınız olacaktır.

  1. Sunucu Log Dosyası Analizi: Googlebot'un son 6 ayda taradığı tüm URL'lerin Nginx/Apache loglarından çekilmesi. Botun en çok hangi sayfalara önem verdiğini (Crawl Demand) anlamanın tek yolu budur.
  2. Tam Site Crawl (Spidering): Screaming Frog veya Sitebulb gibi Enterprise tarayıcılarla sitenin mevcut halini (HTML haritası, Meta etiketleri, H1 hiyerarşisi, canonical yapısı ve iç link sayıları) eksiksiz olarak bilgisayarınıza indirin.
  3. Trafik ve Backlink Haritası: Search Console API kullanarak son 12 ayda Google'dan en az 1 tık (Click) almış tüm URL'leri çekin. Ardından Ahrefs veya Majestic üzerinden dışarıdan en az 1 adet backlink (DoFollow) almış URL'leri çekin.

Bu üç farklı veri setini birleştirip (Python Pandas veya BigQuery kullanarak) "Altın URL Listesi"ni (The Golden URL Map) oluşturun. Kural şudur: Bu listedeki hiçbir sayfa taşıma sonrası 404 (Not Found) hatasına düşemez.

Faz 2: Kusursuz 1:1 Redirect (Yönlendirme) Haritası

Migration operasyonunun kalbi ve tek kurtarıcısı 301 Yönlendirme (Permanent Redirect) haritasıdır. Eski URL'ler, yeni sitede içerik ve kullanıcı niyeti (Search Intent) olarak en eşdeğer, birebir karşılık gelen yeni URL'ye yönlendirilmelidir.

DİKKAT: Tembel Yönlendirme Hatası (Lazy Redirecting): Milyonluk Hata! En sık yapılan faciadır. Yazılım veya SEO ekibi, binlerce sayfası olan eski bir blog kategorisini siler. O kategorideki tüm alt yazıları teker teker eşlemek yerine kolayına kaçıp tüm URL'leri doğrudan sitenin "Ana Sayfasına" topluca (Regex ile) yönlendirir. Buna Soft 404 denir. Google aptal değildir; aradığı makalenin ana sayfada olmadığını anlar, bu yönlendirmeyi "geçersiz" sayar ve o makalelerin yıllarca biriktirdiği PageRank gücünü anında sıfırlar. Yönlendirme her zaman 1:1 veya anlamlı bir "Kategori" sayfasına yapılmalıdır.

Uzman Görüşü (SME)• Intent Veri Ekibi

Regex ve Edge Yönlendirmeleri (Performance is Key) Eğer 5 milyon URL'yi WordPress eklentileriyle veya basit bir .htaccess dosyasına satır satır yazarak yönlendirmeye çalışırsanız, sunucunuz ilk saniyede CPU krizine girer ve çöker. Büyük ölçekli sitelerde yönlendirmeler uygulama (Application) katmanında yapılmaz; Sunucu (Nginx/Apache) veya daha iyisi Edge/CDN (Cloudflare Page Rules, AWS CloudFront Functions) seviyesinde, Regex (Düzenli İfade) kullanılarak dinamik (Wildcard) olarak yapılır.

# Nginx Sunucusunda Regex ile Yüksek Performanslı Dinamik Yönlendirme Örneği
# Milyonlarca ürünü tek satır kodla 301 yapıyoruz.

# Eski yapı: /urun/detay/12345-kirmizi-kadin-ayakkabi
# Yeni yapı: /p/kadin/kirmizi-ayakkabi-12345

# (\d+) ile ID'yi, (.*) ile slug'ı yakalayıp yer değiştiriyoruz.
rewrite ^/urun/detay/(\d+)-(.*)$ /p/$2-$1 permanent;

# Eski .html uzantılı statik sayfaları yeni uzantısız modern yapıya taşıma
rewrite ^/(.*)\.html$ /$1 permanent;

Faz 3: Staging (Test Ortamı) Validasyonu ve Crawl Testi

Yazılım ekibi yeni siteyi kodlamayı bitirdiğinde, asla doğrudan canlıya (Production) alınmaz. Site kapalı bir "Staging" (Test) ortamına alınır (Örn: staging.sirketiniz.com). Bu ortama Googlebot'un veya rakiplerin girmesini engellemek için robots.txt ile Disallow yapmak asla yetmez (Google bazen bunu dinlemeyip indekse alabilir, kopya içerik faciası yaşarsınız). Staging ortamına mutlaka sunucu seviyesinde HTTP Basic Authentication (Kullanıcı Adı/Şifre) koyun.

Staging ortamı hazırken, Screaming Frog'un "List Mode" özelliğini kullanarak Faz 1'de oluşturduğumuz "Altın URL Listesi"ni araca yükleyin ve taratın. Araç, eski URL'lere istek atıp yeni Staging ortamındaki karşılıklarını bulacaktır.

Beklediğimiz Kesin Sonuç: Tüm eski URL'lerin 301 Moved Permanently ile yeni URL'lere gitmesi ve hedeflenen yeni URL'lerin kusursuz bir şekilde 200 OK yanıtı vermesi. Eğer 1 tane bile 404 Not Found veya 302 Found (Geçici yönlendirme - PageRank geçirmez!) veya zincir yönlendirme (301 -> 301 -> 200) varsa canlıya çıkış (Go-live) o hata çözülene kadar ertelenir.


3. Canlıya Çıkış (Go-Live) Günü Operasyonu: İlk 24 Saat

Her şey kusursuzsa, taşıma işlemini trafik hacminin ve sunucu yükünün en düşük olduğu saatte (B2B firmalar için genellikle Cuma gece 03:00 veya Cumartesi sabaha karşı) başlatın.

  1. DNS ve Yönlendirmelerin Açılması: Domain DNS kayıtları yeni sunucuya (Next.js vb.) çevrilir. Nginx/Edge üzerindeki 301 kuralları aktif edilir.
  2. Sitemap Değişimi (Kritik Strateji): En çok bilinen SEO hatalarından biri eski sitemap'i silip sadece yenisini koymaktır. Eski sitenin sitemap'ini silmeyin! Search Console'da hem eski URL'leri barındıran sitemap kalsın, hem de yeni URL'leri barındıran yeni sitemap'i ekleyin. Neden mi? Googlebot'u eski sitemap'e gönderip, o eski linklere tıklamasını sağlarsanız, bot anında 301 yönlendirmesini görüp yeni siteyi "Hızla Keşfeder" (Rapid Discovery). Bu işlem, Google'ın yeni yapıya adapte olma hızını (Indexation Rate) %500 artırır. 1-2 ay sonra eski sitemap'i kaldırabilirsiniz.
  3. Search Console'da "Adres Değişikliği" Aracı: Eğer sadece altyapı değil, doğrudan Alan Adı (Domain) değişiyorsa (eskimarka.com -> yenimarka.com), Google Search Console üzerinden resmi "Adres Değişikliği Bildirimi" (Change of Address Tool) yapılmalıdır. Bu, Google'ın çekirdek algoritmalarına "Bu şirket markasını değiştirdi, otoriteyi yeni yere taşı" sinyalini verir.

4. Post-Migration (Taşıma Sonrası) İzleme ve Kriz Yönetimi

Go-Live sonrası ilk 48 saat teknik SEO ekibi uyumaz. Log kayıtlarını (Sunucu Erişim Kayıtları) Kibana veya Grafana üzerinden saniye saniye canlı olarak izleriz.

  • Googlebot yeni URL'leri 200 OK olarak tarayabiliyor mu? Yoksa bir JavaScript hatasından (Hydration Error) dolayı 500 Server Error mu alıyor?
  • Eski URL'lere geldiğinde 301 ile dönüyor mu? Yoksa bir kural atlaması sonucu soft 404 mü oluşuyor?
  • Yeni sitede oluşan "Yönlendirme Zincirleri" (Redirect Chains) var mı? (Örn: A sayfası B'ye yönlendi, ama B de C'ye yönlendi -> A -> B -> C). Googlebot maksimum 5 yönlendirme zincirini takip eder, sonrasında pes eder (Redirect Error). Zincirler tespit edilip (A -> C) şeklinde doğrudan hedefe kısaltılmalıdır.
sequenceDiagram
    participant U as Kullanıcı / Googlebot
    participant E as Eski URL (A)
    participant N as Yeni URL (B)
    
    U->>E: GET /eski-kategori/ayakkabi
    E-->>U: HTTP 301 Moved Permanently (Location: /yeni/ayakkabi)
    Note over E,U: PageRank %100 Transfer Edilir
    
    U->>N: GET /yeni/ayakkabi
    N-->>U: HTTP 200 OK (Temiz Next.js Çıktısı)
    Note over N,U: Hızlı render, yüksek Core Web Vitals

Sonuç: Geçiş Bir Kriz Değil, Eşsiz Bir SEO Fırsatıdır

Eğer şirketin içinde veya danışmanınız olarak süreçleri matematiğe ve veriye döken doğru bir mühendislik ekibiyle çalışıyorsanız, Migration bir sistem darboğazı değil; aksine eski, hantal ve hatalı mimariden (gereksiz kodlar yığını, zombi sayfalar, kötü URL hiyerarşisi) sonsuza dek kurtulmak için optimize edilmiş bir fırsattır.

Temiz bir "Tuğla ve Harç" ile, modern teknolojilerle (Next.js, Edge Network) inşa edilmiş yeni bir altyapı, taşımanın 2. veya en geç 3. ayından itibaren (Google yeni yapıyı tamamen güvenli bulduktan sonra) size daha önce hiç görmediğiniz, katlanarak artan bir organik otorite getirecektir. Korkmayın, sadece ölçün ve doğru yönlendirin.


🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Teknik SEO topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

🧠 Semantic Entities (Terimler & Senaryolar)

Semantic Yönerge: Bu sayfa Enterprise SEO'da Sıfır Trafik Kaybıyla Site Taşıma (Migration) Rehberi konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.