Site Taşıma Sonrası SEO Çöküşü Nasıl Önlenir? Net Kontrol Planı

Site taşıma (hosting, sunucu, alan adı veya platform değişimi) SEO performansını en çok etkileyen işlemlerden biridir. Sorun genellikle yeni sunucunun “yavaş” olmasından değil; yönlendirme zincirleri, yanlış canonical etiketi, eksik sitemap, robots.txt hatası ve indeks gecikmesinden çıkar. Bu rehberde, site taşıma sonrası SEO çöküşünü önlemek için uygulanabilir, kontrol edilebilir adımları bir zaman çizelgesiyle anlatıyorum. Böylece hangi noktada hata yaptığınızı tespit edip hızlıca düzeltirsiniz.

1) Taşımaya başlamadan önce: SEO envanteri çıkarın

Site taşımada yapılacak en kritik iş, “taşınacak şeyi” sayısal olarak belgelemektir. Hataların büyük kısmı sonradan değil, planlama aşamasında azaltılır.

Hangi verileri toplayın?

Aşağıdaki listeyi taşınma öncesinde çıkarın: - İndeksli URL sayısı (Google Search Console, GSC): “Kapsam/Pages” raporundan bakın. - Önemli trafik URL’leri: Son 90 günün Google Organic trafiğiyle gelen sayfalarını listeleyin. - Backlink alanları ve hedef URL’ler: En çok link alan sayfaları belirleyin. - Mevcut yönlendirme yapısı: Mevcut site .htaccess/nginx rewrite (varsa) ve mevcut 3xx kuralları. - Canonical mantığı: Her sayfada canonical hangi URL’yi gösteriyor? - robots.txt ve sitemap.xml: Dosyaların tam içeriği ve güncel olarak hangi URL’leri içerdiği.

Bu veriler taşımadan sonra “neden düştü?” sorusuna tek tek cevap verir. Örneğin trafik düşüşü canonical kaynaklıysa, aynı canonical stratejisini yeni ortamda birebir kurmanız gerekir.

Dökümante edilen URL eşleşmeleri (mapping)

Site taşıma sırasında en az şu eşleşme tablosunu oluşturun: - Eski URL -> Yeni URL - Eski -> Yeni aynı ise (ör. /urun-adi) - Eski URL karşılığı yoksa: 301 ile en yakın eşdeğere yönlendirme

Özellikle e-ticaret sitelerinde (ürün/ kategori URL’leri) “benzer sayfa” yanlışlığını önlemek için yakın eşleşme (en iyi benzer başlık) kuralını netleştirin.

2) Sunucu ve uygulama farkı SEO’yu nasıl bozar?

SEO çöküşü bazen doğrudan SEO ayarlarından değil, sayfa teslim (response) davranışlarından kaynaklanır. Google, siteyi tarar; tarayıcı davranışını da sunucu etkiler.

En sık görülen teknik tetikleyiciler

HTTP durum kodu hataları: 200 beklenen sayfada 404/500 gelmesi veya 302’nin kalıcı sanılması.
Yönlendirme zinciri: Örn. http -> https -> www -> yeni alan adı -> tekrar eskiye dönüş gibi zincirler.
Ters proxy/CDN yapılandırma farkları: Host header yanlış gelmesi, yanlış script base URL.
Geç yüklenen varlıklar: CSS/JS’in farklı domain’den geç gelmesi, TTFB ve render gecikmesi.
WAF / rate limit: Bazı tarayıcı IP’lerini gereksiz engelleme.

Hız testi: hedef metrikler

Taşıma sonrası kontrol etmek için ölçülebilir hedefler koyun: - Ttek sayfa için TTFB (Time to First Byte) düşüşü: Yeni sunucuda TTFB belirgin artıyorsa SEO taramasını da etkilersiniz. - TTFB ve LCP dalgalanması: Özellikle ilk isteklerde artıyorsa cache ön ısıtma eksiktir.

Pratik yaklaşım: Taşımadan önce aynı URL setiyle ölçüm alın, taşıma sonrası aynı URL’leri tekrar ölçün. Farkı, hız kaynağıyla birlikte raporlayın.

3) 301 yönlendirmelerini “zincirsiz” kurun ve doğrulayın

Site taşıma sonrası SEO kaybının en yaygın nedeni, yanlış yönlendirmedir. Doğru yöntem tek atlayışlı 301 yaklaşımıdır.

301 kuralı: tek adım, doğru hedef

Her eski URL, doğrudan doğru yeni URL’ye 301 ile gitsin.
302 değil 301 kullanın (kalıcı).
Zincir oluşturmayın: A URL -> B URL -> C URL (Google üçüncü adımı geç tarar, canonical sinyali karışır).

Kontrol listesi: yönlendirme testleri

Aşağıdaki testleri bir eylem listesi gibi uygulayın: - 10-20 kritik URL’yi tarayıcıda açın: - Adres çubuğunda beklenen yeni URL görünüyor mu? - Sayfa başlığı (title) ve canonical doğru mu? - CURL/HEAD ile durum kodunu kontrol edin: - Eski URL -> 301 - Yeni URL -> 200 - Redirect loop var mı kontrol edin: - Aynı URL’ler arasında dönüyorsa (loop), Google sayfayı “sonsuz yönlendirme” olarak algılayabilir.

Domain değişimi varsa ekstra kural

http ve https kombinasyonlarını tek bir hedefe bağlayın.
www/non-www farkını da tek noktaya sabitleyin.

4) Canonical, robots.txt ve sitemap.xml: indeks sinyallerini kilitleyin

Yönlendirme çalışsa bile, canonical ve indeks dosyaları yanlışsa Google doğru sayfayı seçmeyebilir.

Canonical’i birebir eşleştirin

Eski sitedeki canonical mantığınız neyse, yeni sitede birebir uygulayın.
Canonical etiketi “yeni URL”yi göstermelidir. Eğer canonical hâlâ eski URL’yi işaret ediyorsa, yeni sayfaya indeksleme transferi zayıflar.

robots.txt: taşıma sırasında en sık yapılan hata

Taşıma sonrası geçici olarak /robots.txt ile taramayı kapatmak istenir. Ancak yanlış kalıcı kural SEO düşüşü üretir. - Taşıma sonrası robots.txt içinde önemli dizinleri kalıcı kapatmayın. - Özellikle staging/preview dizinini kapatırken prod URL’leri kapatmayın.

sitemap.xml: doğru yerde doğru protokol

Yeni alan adında sitemap.xml aktif olmalı.
Sitemap içinde yer alan URL’ler 200 döndürmeli.
Üst düzey sitemap ile alt sitemap uyumlu olmalı.

Sitemap sürümü ve iletim

Yeni sitemap’ı GSC’ye ekleyin.
GSC “Sitemap ve indeks” raporları üzerinden yeni URL’lerin ne zaman tarandığını takip edin.

5) Geçiş stratejisi: staging, kademeli kesim ve izleme

SEO çöküşü yaşanmadan önce, riski kademeli azaltmak mümkündür. Burada amaç “bir günde her şeyi değiştirmek” yerine, sorun yakalanınca hızlı geri dönüş sağlamaktır.

Staging ortamı: arama motorlarından izole edin

Staging kullanıyorsanız iki şeyi netleştirin: - Staging domain/alt dizininde tarama engeli olmalı. - Analytics ve GSC sinyalleri karışmamalı.

Kademeli taşıma (pratik yöntem)

Önce statik sayfalar/az trafik URL’lerini taşıyın.
Ardından kategori/ürün gibi URL sayısı fazla alanları sırayla geçin.
En son kırılgan ve dönüşüm odaklı sayfaları taşıyın.

Geri dönüş planı (rollback) şarttır

Şu koşullarda geri dönüş yapmalısınız: - 24-48 saatte kritik URL’lerde 404/500 artışı - Redirect loop tespiti - GSC’de “Seçilen canonical farklı” veya kapsama düşme oranında ciddi artış

6) Google Search Console ile 72 saatlik “kriz yönetimi”

Taşıma sonrası ilk hafta “beklemek” yerine ölçmek gerekir. Aşağıda, 72 saatlik somut bir izleme planı var.

0-24 saat: durum kodu ve indeks sinyali kontrolü

Eski URL’ler için redirect çalışıyor mu (301)?
Yeni URL’ler 200 döndürür mü?
GSC’de tarama hatası raporu var mı?
sitemap içindeki URL’ler gerçekten ulaşılabilir mi?

24-48 saat: indeksleme hızına bakın

Yeni domain/URL’ler GSC’de görünmeye başladı mı?
“Kapsam dışı” durumları artıyor mu?
Canonical seçiminde hatalar var mı?

48-72 saat: performans ve tarama davranışı

GSC’de tarama istatistikleri normal mi?
Sunucu hata oranı (5xx) yükseldi mi?
Cloud/WAF gibi güvenlik katmanları bot trafiğini engelliyor mu?

7) Sunucu ölçekleme ve cache: SEO için “gerektiğinde” kullanın

Cache ve hız optimizasyonu SEO’yu destekler; ancak yanlış yapı SEO’yu baltalayabilir. Özellikle taşımada “cache purge” unutulduğunda eski içerik dönmeye başlar.

Cache purge kuralı

Taşıma kesimi sırasında CDN/Reverse proxy cache temizlenmeli (purge).
Uygulama cache (varsa) yeni URL’lerle uyumlu olmalı.

Object cache ne zaman devreye girmeli?

Eğer site dinamik içerik üretip veritabanı sorguları ağırsa object cache (APCu/Redis) fayda sağlar. Ancak tek başına SEO çöküşünü çözmez; önce yönlendirme/canonical/sitemap hatalarını düzeltmek gerekir.

8) Sık görülen SEO çöküş senaryoları ve net düzeltmeler

Bu bölüm, taşımadan sonra karşılaşılan gerçek sorunları ve hızlı düzeltmeyi özetler.

Senaryo A: Trafik düşüyor, ama yönlendirme çalışıyor

Olası neden: Canonical eski URL’yi işaret ediyor veya yeni sayfa farklı title/meta ile geliyor. Düzeltme: Yeni ortamda canonical’i yeni URL’ye taşıyın; GSC’de “canonical seçimi” raporunu izleyin.

Senaryo B: 404 artışı var

Olası neden: mapping eksik veya rewrite kuralı eksik. Düzeltme: En çok trafik alan 50 URL’yi tek tek eski->yeni eşlemesiyle düzeltin; sonra redirect kurallarını tekrar test edin.

Senaryo C: Redirect zinciri oluşuyor

Olası neden: http/https/www/non-www kuralları birbiriyle çakışıyor. Düzeltme: Tek hedef belirleyin ve diğer kombinasyonları o hedefe 301 ile bağlayın. Zincir var mı curl ile doğrulayın.

Senaryo D: Sitemap var ama indekslenmiyor

Olası neden: Sitemap URL’leri 301 ile başka yere gidiyor ya da 200 döndürmüyor. Düzeltme: Sitemap’taki URL’leri açıp durum kodlarını doğrulayın. GSC’de sitemap raporunu kontrol edin.

Sonuç: Aksiyona çevrilmiş taşıma planı

Site taşıma sonrası SEO çöküşünü önlemek için tek bir “sihirli ayar” yoktur; yönlendirme (301), canonical, robots.txt/sitemap ve sunucu davranışı birlikte doğru kurulmalıdır. En hızlı ilerleme için bugün şu sırayı uygulayın: (1) URL mapping çıkarın, (2) kritik URL’lerde redirect + canonical + 200 kontrolü yapın, (3) robots/sitemap’i yeni ortamda kilitleyin, (4) taşımadan sonraki 72 saatte GSC ve durum kodlarını izleyin. Taşıma kesimini planlı yapıp ölçüm koyduğunuzda, SEO düşüşünü oluşmadan engellemek veya oluşursa gün içinde geri almak mümkündür.