Site Taşıma Sonrası Trafik Düştü: SEO Kaybının Nedeni ve Çözümü

Site taşıma sonrası trafik düştü diye panik yapan yüzlerce site sahibiyle konuştum ve neredeyse hepsinde aynı tablo vardı: taşıma günü her şey yolunda görünüyor, site açılıyor, sayfalar geliyor, sepet çalışıyor. Sonra on gün geçiyor ve Search Console'daki tıklama grafiği bir uçurumdan aşağı iniyor. Asıl sinir bozucu olan da bu gecikme: sorun taşıma anında oluşuyor ama etkisi ancak Google siteyi yeniden taradığında görünür hâle geliyor. O yüzden çoğu kişi düşüşü taşımayla ilişkilendirmiyor, "Google güncelleme yaptı herhalde" deyip haftalarca bekliyor.

Bu yazıda hosting değişikliği SEO etkisini genel geçer cümlelerle geçiştirmeyeceğim. Taşıma sonrası sıralama kaybının gerçek teknik nedenlerini — test ortamından sürüklenen noindex etiketi, robots.txt içindeki tek satırlık Disallow, kırılan 301 zincirleri, yavaşlayan TTFB ve yeni IP'nin geçmişi — tek tek ele alıp bunları hangi sırayla kontrol etmeniz gerektiğini anlatacağım. Sıra önemli: yanlış sırayla başlarsanız günlerce sunucu ayarlarıyla uğraşıp asıl sebebi (çoğu zaman iki satırlık bir dosya) atlarsınız. Aşağıdaki tanı sırasını yukarıdan aşağı uygularsanız, vakaların büyük çoğunluğu ilk üç adımda çözülüyor.

Trafik Gerçekten Düştü mü: Önce Ölçümü Doğrulayın#

Teknik tanıya başlamadan önce düşüşün gerçek olduğunu ve taşımayla ilgili olduğunu kanıtlamanız gerekir. Aksi hâlde var olmayan bir sorunu kovalarsınız.

Analytics kodunun taşıma sırasında kaybolmuş olması, en sık karşılaştığım "sahte düşüş" nedenidir. Tema dosyalarını elle kopyaladıysanız veya taşıma sırasında temayı yeniden kurduysanız, header.php içindeki ölçüm kodu gitmiş olabilir. Bu durumda organik trafik değil, ölçüm ölmüştür.

Ayrımı şöyle yaparsınız:

1. Search Console → Performans raporunu açın. Analytics değil, Search Console. Çünkü Search Console verisi sitenizdeki koda bağlı değildir, doğrudan Google'ın kendi kayıtlarından gelir.
2. Tarih aralığını taşımadan 28 gün öncesi ile sonrası olacak şekilde karşılaştırın.
3. Tıklama ve Gösterim çizgilerini ayrı ayrı bakın.

Buradaki ayrım tanıyı yarı yarıya daraltır:

Son satırı gördüyseniz nefes alın ve tema dosyalarına geri dönün. Diğer üçü için okumaya devam edin.

Tanı Sırası: Bu Sekiz Kontrolü Bu Sırayla Yapın#

Taşıma sonrası SEO kaybının nedenini bulmanın en hızlı yolu, kontrolleri "ucuz ve yıkıcı" olandan "pahalı ve ihtimali düşük" olana doğru sıralamaktır.

İlk iki maddeyi atlayıp doğrudan hız optimizasyonuna girişen çok kişi gördüm. Sonuç: iki hafta boyunca önbellek eklentisi ayarlanırken sitenin tamamı noindex ile dizinden düştü.

robots.txt: Tek Satır Bütün Siteyi Kapatır#

Taşıma sonrası trafik kaybının en yaygın tek nedeni, test ortamından canlıya sürüklenen bir robots.txt dosyasıdır.

Tarayıcınızda doğrudan https://alanadiniz.com/robots.txt adresini açın ve şu satırı arayın:

User-agent: *
Disallow: /

Bu iki satır, "sitemin hiçbir sayfasını tarama" demektir. Test ortamında tamamen doğru bir ayardır; canlıda felakettir. Taşıma yaparken geliştirici genellikle bir staging alan adı üzerinde çalışır, orada arama motorlarını kapatır, sonra bütün dosyaları olduğu gibi kopyalar — ve o dosya da kopyalananların içindedir.

Komut satırından kontrol etmek isterseniz:

curl -s https://alanadiniz.com/robots.txt

WordPress kullanıyorsanız ikinci bir tuzak daha var: Ayarlar → Okuma → "Arama motorlarının siteyi dizine eklemesini engelle" kutusu. Bu kutu işaretliyken WordPress fiziksel bir robots.txt dosyası olmasa bile sanal bir tane üretir ve içine Disallow: / yazar. Taşımadan sonra bu kutuyu mutlaka kontrol edin; test kurulumlarında varsayılan olarak işaretli gelir.

WP-CLI ile tek komutta bakabilirsiniz:

wp option get blog_public

Dönen değer 1 olmalıdır. 0 dönüyorsa engel açıktır:

wp option update blog_public 1

Search Console'da bu sorunun izi Sayfalar → "robots.txt tarafından engellendi" raporunda görünür. Sayfa sayısı taşıma tarihinden sonra fırlamışsa nedeni bulmuşsunuz demektir. Bu hatanın ayrıntılı çözümü için robots.txt tarafından engellendi hatası yazısına bakabilirsiniz.

noindex Etiketi: robots.txt'den Daha Sinsi Olan#

noindex etiketi robots.txt'ten daha tehlikelidir çünkü sayfa normal görünür, açılır, çalışır — sadece Google onu dizinden çıkarır.

İki yerden gelebilir. Birincisi HTML içindeki meta etiket:

<meta name="robots" content="noindex, nofollow" />

İkincisi ve gözden kaçanı, sunucunun gönderdiği HTTP başlığı:

X-Robots-Tag: noindex

İkincisi HTML kaynağında görünmez. Sayfanın kaynağına bakıp "temiz" dediğiniz hâlde sayfa dizinden düşüyorsa neredeyse kesin budur. Kontrol etmek için:

curl -sI https://alanadiniz.com/ | grep -i "x-robots-tag"

Hiçbir çıktı gelmemesi iyi haberdir. X-Robots-Tag: noindex görüyorsanız kaynağını aramanız gerekir; genellikle .htaccess içinde şuna benzer bir blok bulunur:

Header set X-Robots-Tag "noindex, nofollow"

Nginx tarafında da aynı şey sunucu bloğu içinde add_header X-Robots-Tag "noindex"; şeklinde yer alabilir. Taşıma sırasında eski sunucudaki staging yapılandırması yeni sunucuya kopyalandıysa bu satır da gelmiş olur.

Meta etiket tarafında ise SEO eklentileri suçludur. Yoast veya Rank Math kullanıyorsanız arama görünürlüğü ayarlarını taşımadan sonra tek tek kontrol edin — veritabanı içe aktarılırken staging'in ayarları da gelir. Site genelinde tarama yapmak için sekiz on önemli sayfanızı şu komutla test edin:

for u in / /hakkimizda /urunler /iletisim; do
  echo "== $u"
  curl -s "https://alanadiniz.com$u" | grep -io '<meta name="robots"[^>]*>'
done

Kırık 301 Zincirleri ve Yönlendirme Döngüleri#

Yönlendirme hataları taşıma sonrası sıralama kaybının ikinci büyük nedenidir ve en çok URL yapısı değişen taşımalarda görülür.

Üç ayrı sorun var, üçü de farklı belirti verir:

Zincir yönlendirme. http://alanadi.com/sayfa → https://alanadi.com/sayfa → https://www.alanadi.com/sayfa → https://www.alanadi.com/yeni-sayfa. Her adım biraz zaman ve biraz sinyal kaybettirir. İki adımı geçen her zincir düzeltilmelidir; hedefe tek atlamada gidilmelidir.

Döngü. Yönlendirme kendine döner ve tarayıcı ERR_TOO_MANY_REDIRECTS verir. Genellikle hem .htaccess içinde hem de WordPress ayarlarında HTTPS zorlaması yapıldığında oluşur.

Toplu ana sayfa yönlendirmesi. Taşıma sırasında "eski URL'leri ana sayfaya yönlendirelim" kararı verilir. Bu, Google için soft 404 anlamına gelir ve o sayfaların bütün sıralama geçmişi silinir. İçerik hedefi ile eski URL birebir eşleşmeli, ana sayfa son çare olmalıdır.

Zinciri komut satırından görmenin en temiz yolu:

curl -sIL https://alanadiniz.com/eski-sayfa | grep -Ei "^(HTTP|location)"

Çıktı şuna benzer:

HTTP/2 301
location: https://www.alanadiniz.com/eski-sayfa
HTTP/2 301
location: https://www.alanadiniz.com/yeni-sayfa
HTTP/2 200

Burada iki adım var; tek adıma indirilmelidir. Hangi yönlendirme kodunu ne zaman kullanmanız gerektiği konusunda kararsızsanız 301 mi 302 mi yönlendirme yazısı ayrımı net şekilde anlatıyor. URL yapısı da değiştiyse site taşıma sonrası URL değiştirme yazısındaki eşleme tablosu yöntemini kullanın.

Bir de kanonik etiketi unutmayın. Veritabanı içe aktarıldıktan sonra kanonik hâlâ eski alan adını gösteriyorsa Google sayfayı sizin sitenize ait saymaz:

curl -s https://alanadiniz.com/ | grep -i 'rel="canonical"'

Çıkan adres, sayfanın kendi güncel adresi olmalı. Eski alan adını gösteren bir kanonik etiket, Google'a "asıl sürüm başka yerde" der ve sayfanız kendi adresiyle sıralanmaz.

Yeni Sunucunun TTFB'si: Yavaşlama Sıralamayı Aşağı Çeker#

Yeni sunucu eskisinden yavaşsa sıralama kaybı yavaş ama kalıcı olur; bu, ani düşüşten farklı olarak birkaç hafta içinde birikerek gelir.

Taşımadan sonra hız ölçümünü mutlaka yapın, çünkü "yeni sunucu daha güçlü" ifadesi çoğu zaman kâğıt üstündedir. Paylaşımlı bir pakete taşındıysanız, PHP sürümü düşürüldüyse, OPcache kapalıysa veya veritabanı sunucusu ayrı bir makineye alındıysa yanıt süresi kötüleşebilir.

Ölçüm için:

curl -o /dev/null -s -w "dns:%{time_namelookup}s connect:%{time_connect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" https://alanadiniz.com/

Bu komutu farklı sayfalarda ve günün farklı saatlerinde beş altı kez çalıştırın. Tek ölçüm yanıltıcıdır. Değerlendirme için kaba bir çerçeve:

Taşımadan sonra TTFB iki katına çıktıysa neden aramanız gereken yerler sırasıyla: PHP sürümü ve OPcache durumu, veritabanı bağlantısının localhost yerine uzak bir sunucuya gitmesi, önbellek eklentisinin taşıma sırasında devre dışı kalması ve DNS çözümlemesinin yavaşlığı. Ayrıntılı yöntem için TTFB nedir nasıl düşürülür yazısındaki katman katman ayrıştırma yaklaşımı işinizi görür.

Özellikle şu ikisi taşımadan sonra çok sık bozulur: wp-config.php içindeki DB_HOST değerinin yanlış kalması ve nesne önbelleği (Redis/Memcached) sunucunun yeni ortamında bulunmadığı hâlde eklentinin hâlâ ona bağlanmaya çalışması. İkincisi her sayfa yüklemesine sessizce birkaç yüz milisaniye ekler.

Yeni IP Adresinin Geçmişi ve Engel Listeleri#

Taşındığınız IP adresinin geçmişi kötüyse bu doğrudan bir sıralama cezası yaratmaz, ama e-posta teslimatını ve bazı güvenlik filtrelerini etkileyerek dolaylı zarar verir.

Paylaşımlı bir sunucuya taşındıysanız IP'yi onlarca siteyle paylaşıyorsunuz demektir. O IP'den geçmişte spam gönderilmişse veya komşu sitelerden biri hacklenmişse, IP çeşitli engel listelerine girmiş olabilir. Bunun SEO'ya doğrudan etkisi abartılır; Google sıralama için IP itibarını temel bir sinyal olarak kullanmaz. Ancak şu üç somut etki gerçektir:

1. Siteden çıkan bildirim ve sipariş e-postaları spam klasörüne düşer, müşteri kaybedersiniz.
2. Bazı kurumsal güvenlik duvarları IP'yi engeller, o ağlardan gelen ziyaretçiler siteye ulaşamaz.
3. Sunucudaki komşu siteler yoğun bot trafiği çekiyorsa paylaşılan kaynaklar tükenir ve sizin siteniz yavaşlar.

Kontrol için IP'nizi öğrenip engel listelerinde sorgulayın:

dig +short alanadiniz.com

Dönen IP'yi engel listesi sorgulama servislerinde aratın. Çıkan sonuç kirliyse hosting sağlayıcınızdan IP değişikliği talep edebilirsiniz; ciddi sağlayıcılar bunu yapar. E-posta tarafında ayrıca SPF, DKIM ve DMARC kayıtlarınızın yeni sunucuya göre güncellendiğinden emin olun — taşımadan sonra bu üç kaydın eski sunucuyu göstermeye devam etmesi çok yaygındır.

Kayıp Sayfalar, 404'ler ve Eksik İçerik#

Taşıma sırasında dosya kaybı yaşandıysa sıralama kaybı sayfa bazlı olur ve toplam trafiğin belirli bir yüzdesini götürür.

Bunu tespit etmenin en güvenilir yolu, taşımadan önceki dizin listesiyle sonrakini karşılaştırmaktır. Elinizde eski sitenin yedeği varsa:

# Eski ve yeni URL listelerini karşılaştırma
sort eski-urls.txt > /tmp/a.txt
sort yeni-urls.txt > /tmp/b.txt
comm -23 /tmp/a.txt /tmp/b.txt

Elinizde liste yoksa Search Console'un Sayfalar raporundaki "Bulunamadı (404)" bölümü aynı işi görür. Taşıma tarihinden sonra bu bölüme düşen URL'ler, taşınamamış ya da adresi değişmiş sayfalardır.

Sık kaybolan şeyler şunlardır: wp-content/uploads içindeki eski yıl klasörleri (özellikle FTP aktarımı yarıda kesildiyse), .htaccess içindeki elle yazılmış özel yönlendirmeler, site haritası dosyaları ve doğrulama dosyaları (google*.html gibi). Son maddesi Search Console erişiminizi kaybettirir, veri akışı durur ve düşüşü göremezsiniz bile.

Ayrıca sayfa görsel olarak bozuksa Google onu da düşük kaliteli sayar. Sitenin tasarımı taşımadan sonra dağıldıysa taşıma sonrası site bozuk görünüyor yazısındaki adımlarla önce görünümü toparlayın; SEO'yu ondan sonra kovalayın.

Search Console'da Ne Kontrol Edilir ve Toparlanma Ne Kadar Sürer#

Düzeltmeleri yaptıktan sonra Google'a haber vermeniz ve sonra sabretmeniz gerekir; toparlanma anlık değildir.

Yapılacaklar sırayla:

1. URL Denetimi aracında ana sayfanızı ve iki üç önemli iç sayfanızı test edin. "Dizine eklenebilir" yazması gerekir.
2. Aynı ekranda Dizine eklenmesini iste düğmesine basın. Bunu her sayfa için tek tek yapmak zorunda değilsiniz, birkaç kilit sayfa yeter.
3. Site haritaları bölümünde sitemap URL'nizi yeniden gönderin. Sunucu taşındıysa Google'ın son okuma tarihi eskimiştir.
4. Sayfalar raporunu haftalık takip edin; "robots.txt tarafından engellendi" ve "noindex etiketiyle hariç tutuldu" sayıları düşüşe geçmeli.
5. Ayarlar → Tarama istatistikleri bölümünde ortalama yanıt süresini izleyin. Taşımadan sonra fırladıysa hız sorunu hâlâ duruyor demektir.

Süre beklentisi konusunda gerçekçi olun. Küçük bir siteyi (birkaç yüz sayfa) Google birkaç gün içinde yeniden tarar. Binlerce sayfalı bir sitede tam yeniden tarama üç haftaya kadar sürebilir. Sayfaların yeniden dizine alınması ile sıralamaların geri gelmesi de ayrı iki aşamadır; ikincisi genellikle bir iki hafta daha ister. Sayfalarınız "Tarandı, şu anda dizine eklenmedi" durumunda takılı kalıyorsa bu, engelin kalktığını ama Google'ın henüz sıraya almadığını gösterir; bu durumda beklemek doğru yaklaşımdır.

Bu süreçte yapılmaması gerekenler de en az yapılacaklar kadar önemlidir: alan adını değiştirmeyin, URL yapısını yeniden elden geçirmeyin, "hızlansın" diye toplu içerik silmeyin ve panik hâlinde her gün yeni bir eklenti kurmayın. Taşıma sonrası dönem, sitede değişkeni azaltmanız gereken dönemdir; her yeni değişken tanıyı zorlaştırır.

Sıkça Sorulan Sorular#

Hosting değiştirmek SEO'yu gerçekten etkiler mi#

Hosting değişikliğinin kendisi sıralama kaybı yaratmaz, ama değişiklik sırasında yapılan teknik hatalar yaratır. Google, sitenizin hangi firmada barındığını bir sıralama sinyali olarak kullanmaz. Buna karşılık taşıma sırasında oluşan noindex etiketi, engelleyen robots.txt, kırık yönlendirmeler ve yavaşlayan yanıt süresi doğrudan sıralamayı etkiler. Yani sorun taşımanın kendisi değil, taşımanın nasıl yapıldığıdır.

Taşımadan sonra trafik ne kadar sürede geri gelir#

Sorun bulunup düzeltildikten sonra küçük sitelerde bir ila iki hafta, büyük sitelerde üç ila altı hafta içinde toparlanma görülür. Süre, Google'ın sitenizi ne sıklıkta taradığına bağlıdır. Düzeltmeden sonra site haritasını yeniden göndermek ve kilit sayfalar için dizine ekleme talebi oluşturmak süreci hızlandırır. Altı haftadan sonra hâlâ toparlanma yoksa, düzelttiğinizi sandığınız sorun aslında hâlâ duruyordur; kontrol listesini baştan uygulayın.

Taşımadan önce Google'a haber vermem gerekir mi#

Alan adı aynı kalıyorsa Google'a önceden haber vermeniz gerekmez, adres değişikliği bildirimi sadece alan adı değiştiğinde kullanılır. Sunucu değişikliği Google için görünmez bir olaydır; o sadece aynı adresten aynı içeriğin gelmeye devam ettiğini görür. Yapmanız gereken tek hazırlık, taşımadan önce Search Console'daki mevcut durumu (dizindeki sayfa sayısı, ortalama konum, tıklama) not almaktır; sonrasında karşılaştırma yapabilmek için buna ihtiyacınız olacak.

DNS geçişi sırasında ziyaretçi kaybeder miyim#

DNS geçişi doğru yapılırsa ziyaretçi kaybı yaşanmaz, çünkü eski sunucu bir süre daha yayında bırakılır. Taşıma öncesinde alan adının TTL değerini düşürüp yayılmayı hızlandırmak, taşıma sonrasında da eski sunucuyu en az yetmiş iki saat kapatmamak standart uygulamadır. Bu sürede bazı ziyaretçiler eski, bazıları yeni sunucuya gider; iki tarafta da site çalıştığı sürece kimse kesinti görmez. Asıl kayıp, eski sunucu erken kapatıldığında oluşur.

Sıralamam düştü ama teknik bir sorun bulamıyorum, ne yapmalıyım#

Teknik kontrollerin tamamı temiz çıkıyorsa düşüşün taşımayla ilgisi olmayabilir. Düşüşün tarihini Google'ın bilinen algoritma güncelleme tarihleriyle karşılaştırın; taşıma ile aynı haftaya denk gelen bir güncelleme varsa nedeni o olabilir. Ayrıca rakiplerinizin aynı anahtar kelimelerde yükselip yükselmediğine bakın. Sadece belirli sayfalarınız düştüyse sorun site geneli değil içerik bazlıdır ve taşımadan bağımsızdır.

Taşıma sırasında site kapalı kalırsa Google ceza verir mi#

Birkaç saatlik kesinti kalıcı bir sıralama kaybına yol açmaz, Google geçici erişilemezliği tolere eder. Bu durumda sunucunun 500 hatası yerine 503 durum kodu döndürmesi en doğrusudur; 503, "geçici olarak hizmet dışı, sonra tekrar gel" anlamına gelir ve Google sayfayı dizinden çıkarmaz. Kesinti günlerce sürerse Google sayfaları dizinden düşürmeye başlar. Planlı taşımalarda kesintiyi birkaç saatin altında tutmak ve bakım sayfasını 503 ile sunmak yeterlidir.

Yeni sunucudaki IP değişikliği Google'ı olumsuz etkiler mi#

IP adresinin değişmesi tek başına olumsuz bir sinyal değildir, Google IP değişikliğini normal bir olay olarak görür. Etkisi olan durum, yeni IP'nin spam gönderimi nedeniyle engel listelerinde olmasıdır ve bunun da asıl zararı e-posta teslimatındadır. Sıralama tarafında ölçülebilir bir kayıp beklemeyin. Yine de yeni IP'nizi engel listelerinde sorgulamak on dakikalık bir iştir ve e-posta sorunlarını baştan önler.

Taşımadan sonra sitemap'i yeniden göndermek şart mı#

Zorunlu değildir ama toparlanmayı belirgin şekilde hızlandırır, o yüzden yapmanız önerilir. Google site haritasını zaten periyodik olarak yeniden okur; ancak taşımadan hemen sonra elle göndermek, "bu sitede bir şey değişti, bakmaya gel" sinyali verir. Site haritasının içindeki adreslerin de yeni yapıya uygun olduğundan emin olun; eski URL'leri listeleyen bir site haritası göndermek toparlanmayı yavaşlatır.

Kapanış#

Taşıma sonrası trafik düşüşü, doğru sırayla bakıldığında neredeyse her zaman çözülebilir bir problemdir. Önce ölçümün doğru olduğunu kanıtlayın, sonra robots.txt ve noindex gibi site genelini kapatan iki maddeyi bir dakikada eleyin, ardından kanonik ve yönlendirme zincirlerine geçin. Bunlar temizse hız ve IP itibarına bakın. Yıllardır gördüğüm vakaların büyük kısmı ilk üç adımda bitiyor; geri kalanı da düzeltildikten sonra birkaç hafta içinde eski seviyesine dönüyor. Kritik olan, düzeltmeleri yaptıktan sonra sitede sürekli yeni değişiklik yapmayı bırakıp Google'ın yeniden taramasına izin vermektir.

Taşıma işini kendi başınıza yönetmek istemiyorsanız ya da canlı bir sitede risk almak istemiyorsanız, site taşıma hizmetimiz aktarımı yönlendirmeler ve DNS geçişi dahil üstlenir. Yeni sunucunun yavaş kalması sorununu yaşıyorsanız kaynakları size ayrılmış bir VDS sunucuya geçmek TTFB tarafında en kalıcı çözümdür. Taşıma sonrası teknik iyileştirmeleri planlı biçimde yürütmek isterseniz SEO hizmetimiz bu kontrol listesini sizin adınıza uygular ve toparlanma sürecini takip eder.