Web sitesi taşıma ve yenilemelerinde SEO kaybı nasıl önlenir?

Taşıma türü ve aynı anda değişecek unsurlar açıkça sınırlandırılmalıdır

Hosting değişimi, HTTP’den HTTPS’ye geçiş, domain değişimi, URL yapısının yenilenmesi, CMS geçişi, çok dilli mimari, yeniden tasarım ve içerik konsolidasyonu farklı riskler taşır. Bir projede domain, URL, tasarım, içerik, teknoloji ve marka aynı anda değiştirilirse sorun çıktığında kök nedeni ayırmak zorlaşır. Google da büyük değişikliklerin mümkün olduğunca aşamalı yapılmasını önerir.

Taşıma öncesi envanter, yalnız sitemap dosyasından çıkarılamaz

Gerçek URL kümesi; sitemap, analitik, Search Console, sunucu logu, backlink raporu, CMS dışa aktarımı, dahili arama, medya dosyaları ve kapsamlı crawl kaynaklarının birleşiminden oluşur. Her URL için durum kodu, canonical, indexability, trafik, sorgu, backlink, içerik türü, sahip, son güncelleme ve yeni hedef kaydedilmelidir.

• Organik trafik ve dönüşüm üreten sayfaları işaretleyin.
• Dış bağlantı alan URL’leri koruma önceliğine alın.
• PDF, görsel, feed ve API gibi HTML dışı varlıkları unutmayın.
• Noindex ve robots kararlarının bilinçli olup olmadığını doğrulayın.
• Yetim sayfa ve eski kampanya URL’lerini ayrı sınıflandırın.
• Mevcut 404 ve yönlendirme borcunu yeni projeye taşımayın.

Her eski URL, aynı niyeti karşılayan en yakın yeni URL’ye eşlenmelidir

Yönlendirme tablosu otomatik string değiştirme kuralından ibaret değildir. Eski sayfanın konusu, kullanıcı amacı, ana sorgusu ve içerik kapsamı yeni hedefle karşılaştırılmalıdır. Eşdeğer hedef yoksa yeni sayfa üretme, sayfayı koruma, içerikleri birleştirme veya gerçek 404/410 verme kararı alınır. Bütün eski URL’leri ana sayfaya yönlendirmek soft 404 sinyali ve kötü kullanıcı deneyimi yaratabilir.

Yeni site arama motorlarından gizli test edilir, ancak yayın anında erişilebilir olmalıdır

Staging ortamı kimlik doğrulama veya ağ kısıtıyla korunabilir. Yalnız robots.txt engeli, URL’nin başka yerlerden keşfedilmesini veya test ortamının sızmasını tamamen önlemez. Yayın öncesi canonical, noindex, robots, sitemap, structured data, hreflang, HTTP durumları, cache, CDN, güvenlik başlıkları ve performans ayarları kontrol edilir. Yayın sırasında staging’e ait noindex veya canonical kalıntısı kritik risktir.

1. Yeni altyapıyı üretim kapasitesine yakın yükle test edin.
2. Eski ve yeni sayfaların HTML, metin ve metadata farkını otomatik karşılaştırın.
3. Yönlendirme kurallarını staging hostundan bağımsız test edin.
4. Redirect loop, chain ve query parameter davranışını kontrol edin.
5. Canonical, hreflang ve yapılandırılmış veride yeni URL’leri kullanın.
6. Robots ve noindex kilitlerinin yayın planında kaldırılmasını çift onaya bağlayın.

Görsel yenileme sırasında içerik ve arama niyeti sessizce kaybolmamalıdır

Yeni tasarım çoğu zaman metni kısaltır, başlıkları değiştirir, sekme veya akordeon içine taşır, tabloları görsele çevirir ya da mobilde bazı blokları kaldırır. Bu değişiklikler kullanıcıya ve arama sistemlerine sunulan bilgiyi azaltabilir. Her kritik sayfa için eski ve yeni sürümde ana başlık, kısa cevap, karar içeriği, kaynak, iç link ve CTA eşdeğerliği kontrol edilmelidir.

Yayın, geri dönüş planı olan kontrollü bir değişiklik penceresidir

DNS TTL, yedek, bakım sorumlusu, iletişim kanalı, karar yetkisi, rollback koşulu ve yayın sonrası smoke test önceden yazılmalıdır. Google, URL değişikliklerinde eski ve yeni siteyi Search Console’da doğrulamayı, yeni sitemap göndermeyi ve domain değişiminde Change of Address aracını kullanmayı önerir. Yönlendirmeler uzun süre, mümkünse en az bir yıl korunmalıdır.

• Düşük trafik dönemini seçin ancak izleme ekibini hazır tutun.
• DNS, sertifika, redirect ve uygulama dağıtım sırasını yazın.
• En kritik 20–100 URL için gerçek tarayıcı smoke testi yapın.
• Eski host ve log erişimini hemen kapatmayın.
• Sitemap, robots ve ana navigasyonu yayın anında doğrulayın.
• Rollback’in yönlendirme ve veri değişikliklerini nasıl geri alacağını test edin.

İlk saat, ilk gün, ilk hafta ve ilk ay için farklı izleme gerekir

İlk saatlerde 5xx, DNS, sertifika, loop ve kritik sayfalar; ilk günlerde 404, yönlendirme ve crawl; ilk haftalarda indeks, sorgu ve trafik; sonraki haftalarda dönüşüm ve uzun kuyruk görünürlüğü incelenir. Google, site taşımasında geçici sıralama dalgalanmalarının normal olabileceğini ve orta ölçekli sitelerde yeniden taramanın haftalar sürebileceğini belirtir.

Kayıp varsa sorunu toplu trafik yerine URL ve sorgu kümeleriyle ayırın

Tüm site düşüşü ile belirli klasör, dil, şablon veya içerik türü düşüşü farklı nedenlere işaret eder. Eski ve yeni URL seviyesinde gösterim, tıklama, indeks durumu, canonical seçimi, yönlendirme hedefi, içerik farkı ve log davranışı karşılaştırılır. Sorun düzeltilmeden her URL için yeniden indeksleme istemek kök nedeni çözmez.

• Eski URL hâlâ 200 mü, 301 mi, 404 mü?
• Redirect doğrudan ve konu açısından eşdeğer hedefe mi gidiyor?
• Yeni sayfa indekslenebilir ve self-canonical mı?
• Google farklı canonical mı seçmiş?
• İçerik veya başlık önemli ölçüde zayıflamış mı?
• Botlar 429, 403 veya 5xx ile engelleniyor mu?
• Mobil render masaüstünden farklı mı?

Taşıma kararı ürün, içerik, SEO, geliştirme, altyapı ve hukuk arasında paylaşılmalıdır

Teknik ekip yönlendirmeyi kurabilir; fakat hangi içeriğin korunacağına tek başına karar vermemelidir. İçerik sahibi eşdeğerliği, SEO ekibi URL ve sinyal aktarımını, geliştirme render ve işlevi, altyapı kapasite ve logu, güvenlik erişim ve başlıkları, hukuk ise zorunlu kayıt ve açıklamaları kontrol eder. Tek bir accountable yayın sahibi son kararı verir.

1. Taşıma kapsamı ve değişmeyecek unsurları kilitleyin.
2. URL eşleme tablosuna iş ve teknik sahip atayın.
3. Yayın öncesi kırmızı bayrakları “go/no-go” kriteri yapın.
4. Rollback yetkisini ve karar süresini belirleyin.
5. 30–90 günlük izleme kapanış kriteri tanımlayın.
6. Sonuç ve öğrenimleri sonraki sürüm sözleşmesine işleyin.