Site Taşıma Sonrası Trafik Kaybı ve Hata Düzeltme Rehberi

Site taşıma işlemi bittikten birkaç gün, bazen birkaç saat sonra panik başlar: Google Search Console’daki tıklama grafiği aniden düşer, Analytics’te oturum sayıları yarıya iner, bazı sayfalar 404 vermeye başlar ya da site hiç açılmaz. Bu yazı, “taşıma nasıl yapılır” sorusuna değil, “taşıma zaten yapıldı ve şimdi bir sorun var” durumuna odaklanıyor. Yani elinizde zaten taşınmış bir site var, bir yerlerde bir şeyler ters gitmiş ve şimdi bunu düzeltmeniz gerekiyor.

Taşımayı henüz planlama aşamasındaysanız ve önceden doğru bir checklist ile ilerlemek istiyorsanız, bu yazı yerine site taşıma rehberi yazımıza bakmanızı öneririz; orada adım adım planlama, test ortamı kurulumu ve taşıma öncesi hazırlık süreci ayrıntılı anlatılıyor. Burada ise doğrudan sorun giderme moduna geçiyoruz: teşhis, en sık nedenler, düzeltme adımları ve toparlanma süresi beklentileri.

Bu rehber; alan adı değiştirenler, HTTP’den HTTPS’e geçenler, hosting sağlayıcısı değiştirenler, WordPress’ten başka bir CMS’e (veya tam tersi) geçenler ve site yapısını (URL şeması, klasörleme, dil yapısı) değiştirenler için geçerli. Sorunun kaynağı farklı olsa da teşhis mantığı büyük ölçüde aynı işliyor.

Önce Panik Yapmayın: Normal mi, Anormal mi?

Site taşımalarının büyük çoğunluğunda kısa süreli, öngörülebilir bir dalgalanma yaşanır. Google, yeni URL’leri yeniden taramak, eski URL’lerle ilişkilendirdiği sinyalleri (backlink, tıklama geçmişi, indeks kaydı) yeni adreslere aktarmak için zaman ister. Bu süreçte trafikte %10-25 arası geçici bir dalgalanma “normal” kabul edilebilir.

Aşağıdaki tabloda normal dalgalanma ile gerçek bir sorunun belirtilerini ayırt etmenize yardımcı olacak kriterler var.

Eğer tablonun sol sütunundaysanız, aşağıdaki teşhis adımlarını yine de uygulayın ama acele etmeyin — çoğu şey kendiliğinden düzelir. Sağ sütundaysanız, bir sonraki bölüme doğrudan geçin.

Adım Adım Teşhis Süreci

Site taşıma sonrası sorunları rastgele kontrol etmek yerine sistematik bir sırayla ilerlemek, hem zaman kazandırır hem de kök nedeni gözden kaçırma riskini azaltır. Aşağıdaki sıra, en kritik ve en hızlı tespit edilebilir sorunlardan başlayıp daha ince detaylara doğru ilerler.

1. Site Gerçekten Açılıyor mu?

İlk kontrol her zaman en temel olanı olmalı: site tarayıcıda düzgün açılıyor mu? Farklı cihazlardan, farklı ağlardan (mobil veri, farklı bir Wi-Fi), gizli sekmeden (önbellek etkisini elemek için) test edin. “WordPress taşıma sonrası site açılmıyor” şikâyetinin arkasında genellikle şu nedenlerden biri yatar:

• DNS henüz tam yayılmamış: Domain’i yeni bir hosting’e taşıdıysanız DNS değişikliklerinin dünya genelinde yayılması 24-48 saat, bazen 72 saate kadar sürebilir. dnschecker.org gibi bir araçla farklı bölgelerden çözümlemeyi kontrol edin.
• Yanlış nameserver veya A kaydı: Yeni hosting panelinde verilen IP adresi veya nameserver bilgileri domain sağlayıcısında doğru girilmemiş olabilir.
• wp-config.php içinde eski URL bilgisi: WordPress taşımalarında WP_HOME ve WP_SITEURL sabitleri (veya veritabanındaki siteurl/home seçenekleri) eski adresi gösteriyorsa, site sonsuz yönlendirme döngüsüne girer veya hiç açılmaz.
• .htaccess dosyası taşınmamış veya bozulmuş: Apache sunucularda .htaccess dosyası genellikle gizli dosya olduğu için FTP taşımalarında unutulur. Eksikse site 500 hatası verebilir.
• SSL sertifikası yeni sunucuda kurulmamış: HTTPS geçişinde sertifika henüz aktifleşmemişse tarayıcı “bağlantınız güvenli değil” uyarısı gösterir.
• PHP sürümü uyumsuzluğu: Eski hosting’de çalışan bir tema veya eklenti, yeni sunucudaki farklı PHP sürümüyle (örneğin 8.x) uyumsuz olabilir ve beyaz ekran (WSOD) hatasına yol açabilir.

Bu adımda site tamamen kapalıysa, aşağıdaki bölümlerdeki SEO odaklı adımlara geçmeden önce mutlaka bu erişilebilirlik sorununu çözün — site kapalıyken yapılacak hiçbir SEO müdahalesinin bir anlamı olmaz.

2. Search Console’da “Kapsam” ve “Sayfa İndeksleme” Raporlarını İnceleyin

Google Search Console, taşıma sonrası teşhisin en önemli kaynağıdır. Önce mülkünüzün doğru şekilde ayarlandığından emin olun — hem eski hem yeni domain (veya hem HTTP hem HTTPS sürüm) Search Console’da ayrı mülkler olarak tanımlı olmalı.

Kontrol edilmesi gerekenler:

• Sayfa İndeksleme raporu: “Taranmadı”, “Alternatif sayfa doğru kurallı etiketle” veya “Yönlendirme içeriyor” gibi durumlar hızla artıyorsa, bu URL yapısında bir sorun olduğunun işaretidir.
• 404 (Bulunamadı) sayısı: Taşıma sonrası kısa süreli bir artış normaldir (Google eski URL’leri hâlâ deniyor) ama sayı hızla azalmıyorsa, muhtemelen eksik yönlendirmeleriniz var.
• Sunucu hatası (5xx): Bu kategori artıyorsa hosting/sunucu tarafında bir kapasite veya konfigürasyon sorunu var demektir.
• Kurallı URL Google tarafından seçildi: HTTPS geçişinde Google’ın hâlâ HTTP sürümünü kurallı (canonical) olarak seçtiğini görüyorsanız, yönlendirme veya canonical etiket ayarlarınızda tutarsızlık var demektir.

3. Kapsamlı Bir 404 Taraması Yapın

Search Console verisi örneklemle sınırlıdır ve gecikmelidir; bu yüzden site genelinde bağımsız bir tarama yapmak gerekir. Screaming Frog, Sitebulb veya benzeri bir araçla (ya da elinizde profesyonel bir 404 link düzeltme hizmeti varsa onların raporlama aracıyla) tüm eski URL listesini (taşımadan önce alınmış bir site haritası veya arşiv yedeği üzerinden) yeni site üzerinde tek tek test edin.

Pratik bir kontrol listesi:

1. Taşıma öncesi tüm URL listesini çıkarın (Search Console’un eski performans verisi, Google Analytics’in eski sayfa raporu veya Wayback Machine üzerinden).
2. Bu listeyi toplu olarak tarayıp hangi URL’lerin 404, hangilerinin 301 ile doğru hedefe, hangilerinin ise yanlış bir sayfaya (örneğin ana sayfaya) yönlendirildiğini belirleyin.
3. ”Yumuşak 404” (soft 404) durumlarını da kontrol edin — sayfa 200 durum kodu dönse de içerik olarak boş veya hata mesajı gösteriyorsa Google bunu düşük kaliteli sinyal olarak değerlendirir.
4. Yüksek trafik/backlink alan sayfaları önceliklendirin; tüm site aynı anda düzeltilemeyebilir ama en değerli sayfalar ilk sırada olmalı.
5. Dış bağlantı veren sitelerden gelen trafiği de kontrol edin (Analytics’te “Yönlendirme” kaynakları) — bu bağlantılar hâlâ eski URL’lere gidiyor olabilir.

4. Yönlendirme (Redirect) Zincirlerini ve Döngülerini Kontrol Edin

Taşıma sırasında birden fazla yönlendirme katmanı (örneğin hem .htaccess hem CMS eklentisi hem CDN seviyesinde kural) üst üste binerse, “yönlendirme zinciri” oluşur: A sayfası B’ye, B sayfası C’ye yönlendirir. Google üç-dört zincirden sonra takip etmeyi bırakabilir, kullanıcı deneyimi de yavaşlar. Daha kötüsü, A’nın B’ye, B’nin de tekrar A’ya yönlendirdiği bir “döngü” oluşursa sayfa hiç açılmaz.

Bu sorunu tespit etmek için tarayıcı geliştirici araçlarındaki Ağ (Network) sekmesinde veya curl -IL komutuyla bir URL’nin kaç adımda nihai hedefe ulaştığını görebilirsiniz. İdeal olan her yönlendirmenin tek adımda (301, doğrudan hedef) tamamlanmasıdır.

5. Dahili Bağlantı Yapısını Yeniden Tarayın

Taşıma sırasında en sık gözden kaçan konulardan biri, sitenin kendi içindeki bağlantıların (menü, footer, içerik içi linkler, ilgili yazılar bölümü) hâlâ eski URL yapısını mı yoksa yeni yapıyı mı kullandığıdır. Dahili linkler eski URL’lere gidiyorsa, her tıklamada gereksiz bir yönlendirme zinciri oluşur; bu hem kullanıcı deneyimini hem de Google’ın tarama bütçesini olumsuz etkiler. Site genelinde bir tarama yaparak tüm dahili linklerin doğrudan yeni (nihai) URL’lere işaret ettiğinden emin olun.

6. XML Site Haritasını ve robots.txt Dosyasını Doğrulayın

Taşıma sonrası sıkça yaşanan iki basit ama etkili hata:

• Site haritası güncellenmemiş: Hâlâ eski URL’leri listeliyor veya yeni sayfaları içermiyor. Search Console’da güncel site haritasını yeniden gönderin.
• robots.txt yanlışlıkla tüm siteyi engelliyor: Özellikle test/staging ortamından canlıya geçişte, geliştiricilerin test aşamasında kullandığı Disallow: / satırı unutulup canlı siteye taşınabilir. Bu, tek başına tüm organik trafiği sıfırlayabilecek kritik bir hatadır — mutlaka ilk kontrol edilmesi gerekenler arasına alın.

Site Taşıma Sonrası Trafik Düşüşünün En Sık 9 Nedeni

Teşhis sürecinde topladığınız verileri aşağıdaki listeyle eşleştirerek kök nedeni hızla belirleyebilirsiniz.

1. Eksik veya hatalı 301 yönlendirmeleri. Eski URL’lerin bir kısmı ya da tamamı yeni URL’lere yönlendirilmemiş. Google bu sayfaları 404 olarak görür, biriktirdiği sinyalleri (backlink değeri, tıklama geçmişi) aktaramaz.
2. Yönlendirmelerin yanlış hedefe gitmesi. Tüm eski URL’ler tek tek eşleştirilmek yerine toplu olarak ana sayfaya yönlendirilmiş (bu, “her şeyi ana sayfaya at” yaklaşımı olarak bilinir ve Google tarafından zayıf bir sinyal olarak değerlendirilir).
3. robots.txt’nin siteyi engellemesi. Yukarıda değindiğimiz gibi, tek satırlık bir hata tüm taramayı durdurabilir.
4. noindex etiketinin unutulması. Test ortamından canlıya geçerken <meta name="robots" content="noindex"> etiketi bazı veya tüm sayfalarda kalmış olabilir.
5. Canonical etiket tutarsızlığı. Sayfalar kendi URL’lerini değil, eski (veya yanlış) bir URL’yi kurallı olarak işaret ediyor; bu da Google’ın yeni sayfayı indekslemesini engelliyor.
6. HTTPS/HTTP karışıklığı. Bazı sayfalar hâlâ HTTP üzerinden erişilebilir durumda, karma içerik (mixed content) uyarıları veya çift indeksleme yaşanıyor.
7. Sunucu performansı düşüşü. Yeni hosting eskisinden daha yavaşsa veya sık sık zaman aşımına (timeout) giriyorsa, hem kullanıcı deneyimi hem Core Web Vitals metrikleri kötüleşir, bu da sıralamayı etkiler.
8. Yapısal veri (schema) kaybı. Taşıma sırasında ürün, makale veya yerel işletme şeması gibi yapısal veriler yeni şablona aktarılmamış olabilir; bu da zengin sonuçların (rich results) kaybolmasına yol açar.
9. İçerik veya URL yapısının önemli ölçüde değişmesi. Sadece domain değil, aynı zamanda URL şeması, kategori yapısı veya sayfa içerikleri de değiştiyse, Google bu sayfaları “yeni” olarak değerlendirebilir ve eski sinyalleri tam aktaramayabilir.

”Domain değişikliği sonrası sıralama kaybı” yaşayanların büyük bir kısmında kök neden yukarıdaki 1, 2 ve 5. maddelerin bir kombinasyonudur. Domain değişikliğinde yönlendirme haritasının (eski URL → yeni URL eşleştirmesi) nasıl kurulması gerektiğine dair kurulum detaylarına burada girmiyoruz; bu konuyu adım adım ele aldığımız domain değişikliği ve toplu 301 yönlendirme stratejisi yazımıza bakabilirsiniz.

Düzeltme Süreci: Öncelik Sırasına Göre Adımlar

Sorunları tespit ettikten sonra hepsini aynı anda düzeltmeye çalışmak yerine, etki büyüklüğüne göre bir sıralama izlemek daha verimlidir.

Öncelik 1: Site Erişilebilirliğini Garanti Altına Alın

Site kapalıysa veya kısmen açılmıyorsa her şeyden önce bunu çözün. DNS, sunucu ve SSL sorunlarını giderin. Bu adım tamamlanmadan diğer hiçbir SEO müdahalesi anlamlı sonuç vermez.

Öncelik 2: robots.txt ve noindex Kontrolü

Bu, en hızlı düzeltilebilecek ama en yıkıcı etkiye sahip hatadır. robots.txt dosyasını tarayıcıdan doğrudan açıp (siteadi.com/robots.txt) içeriğini kontrol edin. Sayfa kaynak kodlarında toplu bir noindex taraması yaparak (Screaming Frog’un “Directives” raporu buna uygundur) hangi sayfaların yanlışlıkla engellendiğini bulun.

Öncelik 3: 301 Yönlendirme Haritasını Tamamlayın

Teşhis aşamasında bulduğunuz 404 listesini alıp her biri için doğru, bire bir eşleşen bir 301 yönlendirmesi oluşturun. “Bire bir eşleşme” burada kritik: eski bir blog yazısı, yeni sitede en yakın konudaki karşılığına yönlendirilmeli, mümkünse ana sayfaya değil. İçerik kategorileri değiştiyse en azından kategori/etiket sayfası düzeyinde bir eşleşme kurun.

Öncelik 4: Site Haritasını ve Search Console’u Güncelleyin

Güncel XML site haritasını oluşturup Search Console’a gönderin, “Değişiklik İste” (URL denetleme aracı üzerinden yeniden tarama talebi) özelliğini en kritik sayfalar için kullanın. Toplu talep göndermek yerine önceliklendirilmiş, en değerli 10-20 sayfa ile başlayın; Google’ın günlük tarama talebi kotası sınırlıdır.

Öncelik 5: Dahili Bağlantıları ve Yapısal Veriyi Düzeltin

Menü, footer ve içerik içi bağlantıları yeni URL yapısına göre güncelleyin. Yapısal veri şablonlarının yeni sitede doğru çalıştığını Google’ın Zengin Sonuç Testi aracıyla doğrulayın.

Öncelik 6: Performans ve Core Web Vitals Kontrolü

Yeni sunucu/hosting ortamının eskisi kadar (ya da ondan daha) hızlı çalıştığından emin olun. PageSpeed Insights ve Search Console’daki “Önemli Web Verileri” raporunu karşılaştırmalı olarak izleyin.

Bu düzeltme sürecinin tamamını kendi başınıza yürütmek yerine kapsamlı bir denetim istiyorsanız, bir site taşıma sonrası teknik SEO denetimi; yukarıdaki tüm adımları sistematik bir raporla ele alıp öncelik sırasına göre bir aksiyon planı çıkarır.

HTTP’den HTTPS’e Geçişte Özel Kontrol Noktaları

HTTP HTTPS geçiş hizmeti kapsamında sıkça karşılaşılan sorunlar, domain değişikliğinden biraz farklı bir teşhis çizgisi izler çünkü URL yapısı (yol, dosya adları) aynı kalır, sadece protokol değişir. Buna rağmen ciddi trafik kayıplarına yol açabilecek noktalar şunlardır:

• Karma içerik (mixed content) uyarıları: Sayfa HTTPS üzerinden yüklenirken içindeki görseller, script’ler veya CSS dosyaları hâlâ HTTP adresinden çağrılıyorsa, tarayıcılar “tam güvenli değil” uyarısı gösterir ve bazı kaynaklar hiç yüklenmeyebilir.
• HTTP → HTTPS yönlendirmesinin eksik olması: Her HTTP URL’sinin kendi HTTPS karşılığına 301 ile yönlendirildiğinden emin olun; toplu bir yönlendirme yerine bire bir protokol değişimi olmalı.
• Search Console’da yeni mülk (HTTPS) tanımlanmamış olması: HTTP ve HTTPS, Google için farklı mülklerdir. HTTPS mülkünü ayrıca doğrulamadıysanız performans verisini takip edemezsiniz.
• Canonical etiketlerin hâlâ HTTP gösterdiği durumlar: Şablon veya eklenti ayarlarında unutulmuş statik canonical URL’ler, Google’ın hangi sürümü kurallı kabul edeceği konusunda kafa karışıklığı yaratır.
• HSTS ayarının erken aktifleştirilmesi: Sertifika henüz stabil değilken HSTS (HTTP Strict Transport Security) ayarı açılırsa, herhangi bir sertifika sorununda site tamamen erişilemez hale gelebilir; bu ayarı sertifikanın en az birkaç hafta sorunsuz çalıştığını gördükten sonra etkinleştirmek daha güvenlidir.

”Google’da Görünmüyorum” Sorusuna Site-Taşıma Bağlamında Yaklaşım

”Site yenileme sonrası Google’da görünmüyorum” şikâyeti genellikle iki farklı durumu kapsar: sayfalar hâlâ indekste ama sıralamalar düşmüş, ya da sayfalar indeksten tamamen çıkmış. Bunu ayırt etmek için site:siteadiniz.com sorgusuyla Google’da kaç sayfanızın göründüğünü kontrol edin ve bu sayıyı taşımadan önceki döneme (Search Console’un geçmiş verisi veya arşivlenmiş ekran görüntüleri varsa) kıyaslayın.

Bu yazı kapsamında yalnızca site taşımasıyla doğrudan bağlantılı indeksleme nedenlerine odaklanıyoruz: yukarıda saydığımız robots.txt, noindex, yönlendirme ve canonical sorunları. Bunların dışında, taşımayla ilgisi olmayan (örneğin manuel işlem, düşük içerik kalitesi, teknik altyapı dışı nedenler gibi) daha genel indeksleme sorunlarını kapsamlı biçimde ele almak isterseniz web sitem neden Google’da çıkmıyor yazımıza bakmanızı öneririz; orada indekslemeyi etkileyen tüm olası nedenler tek tek inceleniyor.

Ne Kadar Sürede Toparlanma Beklenmeli?

Bu, taşıma sonrası en sık sorulan sorulardan biri ve net bir cevabı yok çünkü toparlanma hızı birçok değişkene bağlı. Yine de genel eğilimleri gösteren bir tablo hazırladık.

Bu süreler kesin garanti değildir; Google’ın tarama sıklığı, sitenin mevcut otoritesi, sektörün rekabet yoğunluğu ve düzeltmelerin ne kadar hızlı ve doğru uygulandığı toparlanma hızını doğrudan etkiler. Genel kural şudur: hata ne kadar erken tespit edilip düzeltilirse, toparlanma da o kadar hızlı olur. Haftalarca fark edilmeyen bir robots.txt engeli, birkaç günde fark edilip düzeltilen aynı hataya kıyasla çok daha uzun bir toparlanma süreci gerektirir.

Vaka Kurgusu: Orta Ölçekli Bir E-Ticaret Sitesinin Domain Değişikliği Krizi

Elektronik aksesuar satan orta ölçekli bir e-ticaret sitesi, marka yenileme kapsamında domain adını değiştirdi ve aynı hafta içinde sitenin URL yapısını da (kategori isimlendirmesi dahil) güncelledi. Taşıma bir cuma akşamı tamamlandı, ekip pazartesi güne “her şey yolunda” diyerek başladı.

Salı günü Search Console’daki tıklama grafiğinde belirgin bir düşüş fark edildi. Perşembe gününe gelindiğinde organik trafik taşıma öncesine göre yaklaşık %55 gerilemişti ve bazı ürün kategori sayfaları aramada hiç görünmüyordu.

Teşhis sürecinde şu bulgular ortaya çıktı:

• Yeni domain’e geçişte kullanılan yönlendirme kuralları yalnızca ana sayfa ve birkaç popüler ürün sayfası için tanımlanmıştı; kategori sayfalarının büyük kısmı 404 veriyordu.
• URL yapısındaki kategori isimlendirmesi değişikliği (örneğin /kulaklik-modelleri/ yerine /kulakliklar/) yönlendirme haritasına hiç dahil edilmemişti — sanki yalnızca domain değişmiş gibi bir eşleştirme yapılmıştı, oysa yol yapısı da değişmişti.
• Eski sitenin XML site haritası yeni sunucuya taşınmamış, yeni bir site haritası da henüz oluşturulmamıştı.
• Test ortamından canlıya geçerken kullanılan Disallow: /wp-admin/ satırının üstüne yanlışlıkla eklenmiş genel bir Disallow: / satırı, sitenin büyük kısmının Google tarafından taranmasını engelliyordu.

Düzeltme süreci şöyle ilerledi: İlk gün robots.txt hatası tespit edilip anında kaldırıldı, aynı gün içinde güncel site haritası oluşturulup Search Console’a gönderildi. Takip eden üç gün boyunca eski site haritası arşivinden ve Analytics geçmiş verisinden çıkarılan 340 eski URL, yeni URL yapısıyla bire bir eşleştirilerek eksiksiz bir 301 yönlendirme haritası oluşturuldu. En yüksek trafikli 25 sayfa için Search Console’dan manuel yeniden tarama talebinde bulunuldu.

Sonuç penceresi: robots.txt düzeltmesinin etkisi üç-dört gün içinde tarama verilerinde görülmeye başladı. Yönlendirme haritası tamamlandıktan sonraki iki hafta içinde 404 sayısı belirgin biçimde azaldı. Organik trafik, altıncı haftanın sonunda taşıma öncesi seviyenin yaklaşık %90’ına ulaştı; tam eski seviyeye dönüş ise onuncu haftada gerçekleşti. En büyük gecikme nedeni, kategori isimlendirme değişikliğinin ilk yönlendirme haritasında gözden kaçırılmış olmasıydı. (Vaka temsilidir.)

Sık Yapılan Hatalar

1. Yönlendirmeleri “sonra hallederiz” diye ertelemek. Taşıma tamamlandıktan sonra yönlendirme haritasını oluşturmayı bir sonraki haftaya bırakmak, bu süre zarfında hem kullanıcı hem de Google’ın 404 sayfalarla karşılaşmasına neden olur; her geçen gün kayıp sinyal miktarını artırır.
2. Tüm eski URL’leri ana sayfaya yönlendirmek. Teknik olarak “çalışıyor” görünse de Google bunu alakasız bir eşleştirme olarak değerlendirir ve sayfa değerini tam aktarmaz; kullanıcı deneyimi açısından da can sıkıcıdır.
3. Test ortamı ayarlarını canlıya taşımayı unutmak. robots.txt engeli veya noindex etiketleri, geliştirme sürecinde kullanılan ama canlıya geçerken kaldırılması gereken en tehlikeli kalıntılardır.
4. Sadece bir tarayıcıdan “site açılıyor” diye kontrolü yeterli görmek. DNS yayılımı bölgeye göre farklı hızlarda ilerler; tek bir cihaz/ağdan yapılan kontrol yanıltıcı olabilir.
5. Search Console’da yeni mülkü tanımlamayı atlamak. Performans verisini takip edemeyen bir ekip, sorunun büyüklüğünü haftalar sonra fark edebilir.
6. Yönlendirme zincirlerini fark etmemek. Birden fazla sistemin (eklenti, sunucu düzeyi kural, CDN) aynı anda yönlendirme yapması, hem yavaşlığa hem de Google’ın takibi bırakmasına yol açabilir.
7. Dahili linkleri güncellememek. Yeni site canlıya alınsa da menü ve içerik içi bağlantılar hâlâ eski URL yapısını kullanıyorsa, her tıklama gereksiz bir yönlendirme adımına dönüşür.
8. Sabırsızlanıp aynı sayfa için tekrar tekrar yeniden tarama talebinde bulunmak. Bu, Google’ın günlük kotanızı tüketir ve süreci hızlandırmaz; aksine öncelik sırasını bozabilir.
9. Backlink profilini gözden kaçırmak. Yüksek değerli dış bağlantıların hangi eski URL’lere gittiğini kontrol etmeden yönlendirme haritası kurmak, en değerli sinyallerin kaybolmasına neden olabilir.
10. Yapay zeka destekli arama sonuçlarını (AI Overviews) hesaba katmamak. 2026 itibarıyla Google’ın üretken arama deneyimleri, sayfa geçmişini ve yapısal veri tutarlılığını değerlendirme biçiminde daha hassas hale geldi; taşıma sonrası yapısal veri kaybı, klasik organik sıralamanın yanında AI destekli sonuçlardaki görünürlüğü de etkileyebiliyor. Bu nedenle şema doğrulamasını atlamamak eskisinden daha önemli.

Yapay Zeka Çağında Site Taşıma Sonrası İzleme

2026 itibarıyla arama deneyiminin önemli bir kısmı yapay zeka destekli özetler ve sohbet tabanlı arama arayüzleri üzerinden gerçekleşiyor. Bu, site taşıma sonrası izleme sürecine yeni bir boyut ekliyor: klasik “10 mavi bağlantı” sıralamasının yanında, sitenizin yapay zeka modelleri tarafından ne kadar güvenilir ve tutarlı bir kaynak olarak algılandığı da önem kazanıyor.

Pratik açıdan bunun anlamı şu: taşıma sonrası yapısal veri (schema markup) kaybı veya tutarsız canonical sinyalleri, yalnızca geleneksel sıralamaları değil, yapay zeka özetlerinde atıf alma olasılığınızı da etkileyebilir. Ayrıca yapay zeka destekli tarayıcı botları (örneğin büyük dil modellerinin veri toplama ajanları), robots.txt kurallarına klasik Googlebot’tan farklı şekilde yaklaşabiliyor; taşıma sonrası robots.txt denetimi yaparken yalnızca arama motoru botlarını değil, bu botları da göz önünde bulundurmakta fayda var.

Bir diğer pratik öneri: taşıma sonrası izleme sürecinde yalnızca Search Console ve Analytics’e bakmak yerine, markanızın adını doğrudan popüler yapay zeka sohbet arayüzlerinde arayarak sitenizin hâlâ doğru URL’lerle referans gösterilip gösterilmediğini periyodik olarak kontrol etmek, taşıma sonrası tutarlılığı erken tespit etmenize yardımcı olabilir.

Kime Danışmalı: İç Ekip mi, Ajans mı, Freelance mı?

Taşıma sonrası sorunları çözerken kimin sorumlu olacağı sorusu da pratikte sıkça karışıklık yaratır. Genellikle üç taraf devrede olur: hosting/sunucu tarafını yöneten geliştirici veya ajans, içerik ve SEO tarafını yöneten kişi ve varsa taşımayı gerçekleştiren dış tedarikçi. Sorumluluk sınırlarının net olmaması, “bu bizim işimiz değil” şeklinde bir gecikmeye yol açabilir; bu yüzden taşıma öncesinde kimin hangi hatadan sorumlu olacağını netleştirmek faydalı olur.

Küçük ölçekli, birkaç düzine sayfalık sitelerde teşhis ve düzeltme süreci genellikle site sahibinin veya tek bir geliştiricinin birkaç saat içinde halledebileceği bir iştir. Orta ve büyük ölçekli sitelerde ise durum farklıdır: yüzlerce URL’nin doğru eşleştirilmesi, sunucu günlüklerinin analiz edilmesi ve birden fazla teknik katmanın (DNS, sunucu, CMS, CDN) eş zamanlı kontrol edilmesi gerektiğinden, bu noktada deneyimli bir teknik SEO uzmanına veya ajansa danışmak, hem hata riskini azaltır hem de toparlanma süresini kısaltır. Özellikle e-ticaret siteleri gibi her günün doğrudan gelir kaybına dönüştüğü projelerde, dışarıdan profesyonel destek almanın maliyeti genellikle kaybedilen trafiğin maliyetinden çok daha düşüktür.

Taşıma Sonrası İlk 30 Gün İçin İzleme Takvimi

Sorunları düzelttikten sonra sürecin bitmediğini unutmayın; toparlanmayı doğru izlemek, yeni sorunları erken yakalamak açısından kritik. Aşağıdaki takvim, taşıma sonrası ilk ay boyunca hangi metriklere ne sıklıkla bakmanız gerektiğine dair pratik bir çerçeve sunuyor.

Bu takvimi uygularken tek bir güne veya tek bir veri noktasına aşırı anlam yüklememek önemli; Google Search Console verisi doğası gereği 2-3 günlük bir gecikmeyle gelir ve günlük dalgalanmalar gösterebilir. Asıl bakılması gereken, kısa vadeli gürültü değil, haftalık ve iki haftalık trend çizgisidir.

İzleme sürecinde faydalı olacak somut bir alışkanlık: taşımadan hemen önce ve taşımadan sonraki her hafta, aynı gün ve aynı saatte ekran görüntüsü alarak Search Console performans grafiğini, indekslenen sayfa sayısını ve en çok trafik alan 20 sayfanın sıralamalarını kayıt altına almak. Bu basit alışkanlık, ileride “ne zaman, hangi değişiklikten sonra iyileşme başladı” sorusunu net biçimde cevaplamanızı sağlar ve hangi düzeltmenin işe yaradığını ayırt etmenize yardımcı olur.

Ayrıca sunucu taraflı günlükleri (server log) incelemek de değerli bir teşhis aracıdır. Log dosyalarında Googlebot’un hangi URL’leri hangi sıklıkla ziyaret ettiğini görmek, tarama davranışındaki değişimi Search Console’dan çok daha erken ve ham veriyle fark etmenizi sağlar. Örneğin Googlebot hâlâ eski URL yapısını yoğun biçimde ziyaret ediyorsa, bu durum yönlendirme haritanızın eksik olduğunun erken bir işareti olabilir; yeni URL’lere geçişin beklenenden yavaş ilerlediğini gösterebilir.

SSS

Taşıma sonrası yaşadığınız trafik kaybını kendi başınıza teşhis etmek zaman alıyorsa veya sorunun kök nedenini bulamıyorsanız, teknik SEO hizmetimiz kapsamında sitenizin taşıma sonrası durumunu uçtan uca denetleyip önceliklendirilmiş bir aksiyon planı çıkarabiliriz.