Site taşıma sonrası organik düşüşte yapılacak SEO kontrolleri

Site taşıma sonrası organik düşüşte ilk 24 saatte ne kontrol edilir?

İlk 24 saatte amaç, düşüşün normal dalgalanma mı yoksa kritik bir geçiş hatası mı olduğunu ayırmaktır. Bunun için tüm siteyi aynı ağırlıkta izlemek yerine son 30-90 günde en fazla organik tıklama, dönüşüm veya gelir getiren 10-20 landing page çiftini seçin. Kategori, ürün, hizmet ve blog gibi farklı şablonlardan örnekler alın. Böylece problem tek bir URL’de değil, şablon seviyesinde mi yayılıyor sorusuna çok daha hızlı cevap verirsiniz.

Google Search Central’ın 27 Mart 2026 tarihli Site Moves and Migrations dokümanında belirtildiği gibi, taşıma sonrası geçici sıralama dalgalanması beklenebilir; ancak eski URL’lerin 404 vermesi, 302’ye düşmesi, zincir yönlendirmeye girmesi veya yeni sayfaların noindex kalması normal kabul edilmez. İlk saatlerde toplam trafik grafiğine kilitlenmek yerine, kritik URL setinin doğru hedefe tek adımda 301 ile ulaşıp ulaşmadığını kontrol etmek daha doğru bir başlangıçtır.

• HTTP durum kodu: Eski URL 301 dönmeli, yeni URL 200 açılmalıdır.
• Redirect chain ve loop: Eski URL birden fazla sıçrama yapmamalı, kendi üstüne dönmemelidir.
• Kırık iç bağlantılar: Menü, breadcrumb, filtre ve footer linkleri eski yapıyı çağırmamalıdır.
• Örnek URL denetimi: Search Console URL Inspection ile eski-yeni eşleşme mantığı doğrulanmalıdır.

Bu aşamada üç veri kaynağını yan yana koyun: canlı HTTP testi, Search Console URL Inspection ve aynı URL’nin site içi linklerde nereden çağrıldığı. Özellikle yüksek backlink alan eski landing page’ler, yanlış eşleşme olduğunda en görünür kaybı üretir. İlk günün hedefi bütün siteyi raporlamak değil, en büyük hasarı üreten hata kümelerini ayırmaktır. Bu yüzden “kaç sayfa etkilendi” sorusundan önce “hangi sayfa tipi etkilendi” sorusunu cevaplamak daha değerlidir.

301 yönlendirme, canonical ve iç link sinyalleri nasıl doğrulanır?

Taşıma sonrası görünürlük kaybının en yaygın nedeni, eski URL seti ile yeni URL seti arasında gerçek bir 1:1 redirect map kurulmamasıdır. En riskli durumlar, birçok eski URL’nin tek bir ana sayfaya yönlendirilmesi, parametreli sayfaların yanlış şablona düşmesi ve kategori-alt kategori ilişkilerinin bozulmasıdır. Redirect map yalnızca teknik dosya değil, bilgi mimarisinin korunup korunmadığını gösteren bir kalite belgesidir.

Google’ın 14 Nisan 2026 tarihli Redirects and Google Search dokümanına göre kalıcı yönlendirmeler yeni hedef URL’nin arama sonuçlarında gösterilmesine yardımcı olur; geçici yönlendirmeler ise kaynak URL sinyalini koruyabilir. Bu yüzden kalıcı bir site taşımasında 302, gecikmeli meta refresh veya JavaScript tabanlı geçici akışlar gereksiz belirsizlik üretir. Server-side 301 ya da 308 öncelikli tercih olmalıdır.

Hangi sinyaller birlikte kontrol edilmeli?

• Canonical: Yeni sayfa kendisini veya doğru yeni varyantı canonical göstermelidir.
• Hreflang: Dil ve ülke etiketleri eski URL’leri değil yeni hedefleri referanslamalıdır.
• Sitemap: XML sitemap yalnızca yeni, indekslenebilir ve 200 dönen URL’leri içermelidir.
• İç linkler: Menü, breadcrumb, related content ve CTA linkleri yeni yolu işaret etmelidir.

Canonical tarafında ikinci kritik nokta sinyal önceliğidir. Google’ın 27 Mart 2026 güncellemeli canonical yönergelerine göre yönlendirmeler ve rel=”canonical” güçlü sinyallerdir, sitemap ise daha zayıf bir sinyal taşır. Pratik karşılığı şudur: sitemap doğru olsa bile canonical eski URL’yi gösteriyorsa veya iç linkler eski yapıyı çağırıyorsa, Google’ın yeni sayfayı benimsemesi gecikebilir. Bu yüzden redirect, canonical, sitemap ve iç linkler aynı hedefi göstermelidir; biri doğruyken diğerinin yanlış olması yeterli değildir.

GSC, Crawl Stats ve server log ile düşüşün nedeni nasıl teşhis edilir?

Taşıma sonrası teşhiste en kullanışlı ekranlardan biri Page Indexing raporudur. Google Search Console yardım belgesindeki Page indexing report açıklamasına göre “Why pages aren’t indexed” tablosu, belirli URL desenlerinin neden dışarıda kaldığını gösterir. Burada tek tek URL bakmak yerine desen bakın: örneğin yalnızca /blog/ klasörü mü düşmüş, yalnızca filtreli URL’ler mi dışarıda, yoksa tüm yeni şablonda canonical karışıklığı mı var?

GSC’de birlikte okunması gereken raporlar

• Page Indexing: Hariç kalan URL nedenlerini desen bazında ayırır.
• URL Inspection: Seçilen örnek URL’de Google’ın gördüğü canonical ve crawl durumunu gösterir.
• Sitemaps: Yeni URL setinin gerçekten submit edilip edilmediğini doğrular.
• Performance: Aynı landing page grubunda tıklama ve gösterim kırılımını izler.

Crawl tarafında ise Search Console’un Crawl Stats report bölümü toplam crawl isteği, ortalama yanıt süresi, host status ve yanıt kodları gibi sinyalleri gösterir. Bu rapor tek başına kusursuz değildir; Google aynı yardım belgesinde rapor ile gerçek server log’ları arasında küçük farklar olabileceğini açıkça belirtir. Yine de 5xx artışı, response time sıçraması veya bot hit’lerinde keskin düşüş varsa, teknik kaynağı ayırmak için en hızlı üst seviye görünümü sağlar.

Server log analizi burada son doğrulama katmanıdır. En çok trafik alan eski landing page’lerin Googlebot tarafından hangi eski URL’den istenip hangi yeni URL’ye yönlendirildiğini, son hedefte 200 alıp almadığını ve tarama sıklığının düşüp düşmediğini log üzerinden doğrulayın. GSC “sinyal”, log ise “olay kaydı” verir. İkisini birlikte okuyunca, sorun gerçekten indeksleme tarafında mı, yönlendirme katmanında mı, yoksa sunucu erişiminde mi çok daha net ayrılır. İlgili video kaynak olarak Google Search Central kanalındaki site move içerikleri de ekip içi eğitimde faydalı olabilir.

Platform, domain, HTTPS ve hosting değişimlerinde en sık görülen SEO kayıpları

Her taşıma aynı değildir; risk profili değişikliğin tipine göre değişir. Domain değişiminde eski alan adındaki otorite yeni alana doğru yönlendirilmelidir. Platform değişiminde ise çoğu zaman asıl problem URL değil, içerik parity, şablon farkı, JS render davranışı, yanlış noindex etiketi veya beklenmedik robots.txt kısıtları olur. HTTPS ve hosting geçişlerinde ise crawl bütçesi genellikle 5xx, timeout, mixed content ve CDN cache kaynaklı erişim sorunları yüzünden darbe alır.

Search Console’daki Change of Address tool yalnızca domain veya subdomain değişimlerinde kullanılmalıdır. Aynı dokümana göre HTTP’den HTTPS’e geçişte, site içi path değişiminde veya görünür URL değişmeden yapılan hosting/CDN taşımasında bu araç kullanılmaz; bu senaryolarda doğru redirect, sitemap ve property doğrulaması yeterlidir. Ayrıca eski ve yeni property’lerin ayrı ayrı doğrulanması, özellikle www ve non-www varyantlarında hata ayıklamayı çok hızlandırır.

2026 güncelliğinde dikkat edilmesi gereken ayrı bir nokta da meta robots ve X-Robots-Tag katmanıdır. Google’ın 24 Mart 2026 güncellemeli robots meta dokümanında nosnippet kuralının AI Overviews ve AI Mode görünürlüğünü de etkilediği açıkça yer alıyor. Bu, platform geçişinde yanlış şablon meta etiketlerinin sadece klasik arama sonucunu değil, yapay zekâ yüzeylerindeki görünürlüğü de daraltabileceği anlamına gelir. Daha kritik hata ise noindex veya crawl engeli bırakmaktır; bunlar varsa toparlanma beklemek yerine doğrudan düzeltme gerekir.

Toparlanma süresini de gerçekçi yorumlamak gerekir. Google Search Central’ın site move dokümanı, orta ölçekli sitelerde çoğu sayfanın taşınmasının birkaç hafta sürebileceğini söylüyor. Buna rağmen aynı kritik landing page setinde hem bot hit’i düşüyor, hem yeni URL indekslenmiyor, hem de redirect zinciri devam ediyorsa bu artık “normal dalgalanma” değil, düzeltme ya da gerekirse kısmi rollback değerlendirmesi isteyen bir durumdur. Özellikle aynı anda tasarım, içerik yapısı ve URL mimarisi değiştiyse kaynağı ayırmak için değişken sayısını azaltmak önemlidir.

Kurtarma günlüğü yaklaşımıyla ilk 72 saat ve ilk 2 hafta aksiyon planı

Pratikte en hızlı netlik veren yöntem, aynı 15-20 kritik landing page için bir kurtarma günlüğü tutmaktır. Bu günlükte her URL için dört sütun bulunur: GSC tıklama-gösterim eğilimi, URL Inspection sonucu, son 24 saat Googlebot hit’i ve teknik karar notu. Böyle bir kayıt tutulduğunda ekip, genel hislerle değil, hangi hata tipinin hangi URL grubunu etkilediğiyle konuşur. Bu yaklaşım özellikle ilk 72 saatte gereksiz toplantıyı azaltır ve düzeltme önceliğini netleştirir.

• İlk 72 saat: 301 hataları, 404’ler, yanlış canonical, robots/noindex, 5xx ve timeout sorunları kapatılır.
• İlk 2 hafta: Yeni URL indekslenmesi, bot hit artışı, gösterim geri dönüşü ve sorgu stabilitesi izlenir.
• Rollback sinyali: Aynı sayfa setinde hem erişim hem indeks hem performans birlikte bozuluyorsa değerlendirilir.

Bu izleme akışında tek tek araç değiştirmek yerine aynı operasyonu merkezileştirmek iş yükünü azaltır. Örneğin site sağlığı taraması ile redirect chain, 404, canonical ve robots sapmaları hızlıca bulunabilir. Kritik sorguların geri dönüşünü günlük izlemek için sıralama takibi paneli işe yarar. Eski URL’lere gelen değerli bağlantıların doğru yeni hedefe oturup oturmadığını görmek için backlink analizi görünümü, yapay zekâ yüzeylerindeki görünürlük etkisini takip etmek için de AI görünürlük takibi bu günlük yapısına doğal biçimde eklenebilir.

Ahrefs ve SEMrush gibi global araçları kullanan ekipler için paralel kontrol akışı kurulabilir; burada mesele bir aracı dışlamak değil, operasyonu yerel ihtiyaçlara uygun hızda yönetmektir. Ahrefs karşılaştırması ve SEMrush karşılaştırması tarafında görülen temel fark, SEOYEN’in aynı denetim akışını Türkçe arayüz, TL bazlı fiyatlandırma ve yerel destekle tek platformda toplayabilmesidir. Planlama tarafında sabit rakam paylaşmak yerine güncel yapı için paket seçenekleri üzerinden ilerlemek daha sağlıklıdır.

Kritik nokta şu: taşıma sonrası kurtarma işi tek seferlik tarama değil, zaman bazlı karar disiplinidir. İlk gün en ağır hatayı ayırır, ilk 72 saatte erişim ve indeks engellerini kapatır, ilk 2 haftada ise geri dönüş sinyallerini izlersiniz. Bu sırayı korumayan ekipler çoğu zaman semptomları düzeltir ama kök nedeni kaçırır. Kurtarma günlüğü yaklaşımı, bu yüzden standart checklist’ten daha güvenilir sonuç verir.

Adım Adım Site taşıma sonrası organik düşüşü teşhis etme ve toparlama

Aşağıdaki akış, taşıma sonrası görünürlük kaybını sistematik biçimde daraltmak için kullanılabilir. Mantık basittir: önce en büyük gelir ve trafik etkisini taşıyan URL’leri sabitleyin, sonra sinyalleri doğrulayın, en son toparlanma hızını izleyin. Adımların sırası önemlidir; log analiziyle başlamadan önce redirect ve indeksleme katmanını netleştirmek daha verimlidir.

1. Kritik landing page listesini çıkar: Son 30-90 günde en fazla organik tıklama, dönüşüm veya backlink alan eski URL’leri seçin ve yeni URL karşılıklarını aynı tabloda eşleştirin. Her sayfayı tek tek değil, kategori, ürün, blog ve hizmet gibi şablon kümeleri halinde işaretleyin. Böylece düşüşün hangi sayfa tipinde yoğunlaştığı daha ilk saatte anlaşılır.
2. Yönlendirme haritasını doğrula: Seçtiğiniz eski URL listesini toplu testten geçirerek 301, 302, 404, chain ve loop durumlarını ayırın. Özellikle filtre sayfaları, etiketler, eski kampanya URL’leri ve yüksek backlink alan sayfalar yanlış hedeflenmeye daha yatkındır. Map’in amacı yalnızca eski adresi yeniye taşımak değil, aynı arama niyetini koruyan doğru hedefe götürmektir.
3. İndeksleme sinyallerini kontrol et: Yeni URL’de canonical, hreflang, robots, noindex, X-Robots-Tag ve sitemap tutarlılığını doğrulayın. Sitemap’e eklenmiş ama canonical’ı eskiye bakan sayfalar veya robots ile taramaya kapatılmış yeni şablonlar, taşıma sonrası en sinsi kayıpları üretir. İç linklerin de yeni yapıya dönmüş olması gerekir; aksi halde Google eski yolu yeniden keşfetmeye devam eder.
4. GSC raporlarını birlikte okuyun: Page Indexing raporunda dışarıda kalan URL nedenlerini desen bazında inceleyin, ardından aynı gruptan birkaç URL’yi URL Inspection ile açın. Eski ve yeni property’leri ayrı okuyun; özellikle domain değişiminde bu fark hayati olur. GSC verisini tek bir ekran gibi değil, birbirini doğrulayan katmanlar gibi kullanın.
5. Crawl ve log verisini eşleştirin: Crawl Stats’ta istek sayısı, host status ve response time değişimini izleyin; sonra log üzerinde aynı URL grubunda Googlebot hit’lerini doğrulayın. GSC trendi düşüyor ama log’da bot eski URL’ye yoğun gidiyorsa redirect tarafı, log’da 5xx artıyorsa altyapı tarafı ağır basıyor olabilir. Bu eşleştirme, semptomu değil kök nedeni kapatmaya yardım eder.
6. İlk 72 saat düzeltmelerini uygula: Trafik ve tarama kaybı en yüksek kümeleri öne alın. Eski URL’nin yanlış hedefe gitmesi, yeni URL’nin noindex kalması, canonical çakışması, 5xx ve timeout gibi hatalar ilk pencerenin önceliğidir. Bu safhada amaç mükemmel rapor değil, Google’ın yeni URL’leri doğru şekilde tarayıp değerlendirmesini engelleyen bariyerleri kaldırmaktır.
7. İki haftalık toparlanmayı izle: Aynı landing page seti için gösterim, tıklama, indekslenme ve bot hit eğilimini her gün aynı tabloda izleyin. Orta ölçekli sitelerde toparlanmanın birkaç haftaya yayılması normal olabilir; buna rağmen aynı URL grubunda hiçbir iyileşme yoksa redirect map, canonical ve sunucu katmanı yeniden gözden geçirilmelidir. Gerekirse değişken sayısını azaltmak için kısmi rollback düşünülür.

Sıkça Sorulan Sorular