Arama sıralamalarınızı düşürmeden alan adı nasıl taşınır

Alan adı değiştirmek, teknik olarak küçük bir hatanın çok hızlı biçimde görünür sonuçlar doğurabildiği az sayıdaki SEO projesinden biridir. Eksik bir yönlendirme, engellenmiş bir tarama yolu veya unutulmuş bir canonical etiketi, basit bir yeniden markalaşma sürecini haftalar süren sıralama dalgalanmasına dönüştürebilir.

Bir miktar hareket normaldir. Arama motorlarının eski URL’leri taramak, yönlendirmeleri keşfetmek, sinyalleri işlemek ve yeni alan adını dizine yerleştirmek için zamana ihtiyacı vardır. Amaç her düşüşü önlemek değildir. Amaç taşıma sürecini sıkıcı hale getirmektir: bir eski URL, eşdeğer bir yeni URL’ye işaret eder; sunucu açık yanıt verir ve önemli hiçbir şey kaybolmaz.

Bir yönlendirme kuralıyla değil, envanterle başlayın

En yaygın taşıma hatası, bunu bir sunucu yapılandırma işi olarak görmektir. Öyle değildir. Bu, sonunda sunucu yapılandırmasına bağlanan bir bilgi mimarisi işidir.

DNS’e dokunmadan önce önemli URL’lerin bir listesini oluşturun:

• Organik trafik alan URL’ler
• Harici backlink’lere sahip URL’ler
• Dönüşüm sağlayan, potansiyel müşteri üreten veya kampanyaları destekleyen URL’ler
• XML sitemap’inizde şu anda bulunan canonical URL’ler
• Harici olarak bağlantı verilmiş PDF’ler, görseller ve indirilebilir dosyalar
• Mevcut gezinmede görünmeyebilecek yüksek değerli eski URL’ler

Her eski URL için yeni alan adında bir hedef belirleyin. Çoğu durumda bu hedef, aynı niyete sahip aynı sayfa olmalıdır. /pricing sayfası https://newdomain.com/pricing haline geliyorsa bu basittir. Üç eski ürün sayfası tek bir yeni rehberde birleştiriliyorsa, bu kararı bilinçli biçimde belgelendirin.

Tembel kalıptan kaçının: her şeyi yeni ana sayfaya yönlendirmek. Kullanışlıdır, ama alaka düzeyini boşa harcar. Hem arama motorları hem de kullanıcılar, hedef sayfanın özgün URL ile aynı ihtiyaca yanıt vermesini bekler.

Mümkün olduğunda URL yapısını koruyun

Yollar sabit kaldığında alan adı taşıma daha kolaydır. oldsite.com/blog/example adresinden newsite.com/blog/example adresine geçmek; alan adını, CMS’i, slug’ları, klasör yapısını ve içeriği aynı anda değiştirmekten çok daha temizdir.

Bazen bir yeniden tasarım veya CMS geçişi URL değişikliklerini kaçınılmaz kılar. Öyleyse kararları ayırın:

1. Alan adı değiştiği için ne değişiyor?
2. Site yapısı değiştiği için ne değişiyor?
3. Ne siliniyor, birleştiriliyor veya yeniden yazılıyor?

Ne kadar çok değişken eklerseniz, daha sonra sorunları teşhis etmek o kadar zorlaşır. Taşıma önemliyse ve mevcut site iyi performans gösteriyorsa, önce alan adını taşımayı, yeniden tasarımı ise daha sonra yapmayı düşünün.

Kalıcı, tek atlamalı yönlendirmeler kullanın

Gerçek bir alan adı taşıma için eski URL’lerden yeni eşdeğerlerine sunucu taraflı 301 veya 308 yönlendirmeleri kullanın. Geçici yönlendirmeler geçici durumlar içindir. JavaScript yönlendirmeleri, meta refresh’ler ve soft redirect’ler daha zayıf sinyallerdir ve daha kolay bozulur.

Yönlendirme hedefleriniz basittir:

• Her önemli eski URL kalıcı bir yönlendirme döndürür.
• Her yönlendirme doğrudan nihai hedefe gider.
• HTTP, HTTPS’e temiz biçimde yönlenir.
• www ve www olmayan varyantlar tutarlı biçimde ele alınır.
• Gerekmedikçe yönlendirmeler kırılgan query-string davranışına bağlı olmaz.

Kötü bir zincir şöyle görünür:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Bu sonunda doğru sayfaya ulaşabilir, ancak yavaştır, taranması daha zordur ve hataları gizleme olasılığı daha yüksektir. Her eski varyanttan nihai yeni URL’ye tek atlama hedefleyin.

Davranışı doğrularken tarayıcının gösterdiğine güvenmek yerine gerçek HTTP yanıtlarını inceleyin. Üretimde yönlendirmeleri ve HTTP header’larını hata ayıklama rehberimiz burada yararlıdır; çünkü tarayıcılar fazla naziktir: zinciri takip eder ve dağınık kısımları gizler.

DNS ve sertifikaları yayından önce hazırlayın

DNS sıralamaları doğrudan aktarmaz, ancak kötü DNS bir taşımayı bozuk gösterebilir. Değişikliklerin daha öngörülebilir biçimde yayılması için yayın penceresinden önce TTL değerlerini düşürün. Yeni alan adının web trafiği, e-posta ve gerekli tüm alt alan adları için doğru kayıtlara sahip olduğunu doğrulayın.

Her iki alan adı için de geçerli TLS sertifikalarına ihtiyacınız vardır. Bunu gözden kaçırmak kolaydır. Eski alan adının taşıma sonrasında da HTTPS yönlendirmeleri sunması gerekir. Sertifikası sona ererse, kullanıcılar ve tarayıcılar yeni siteye ulaşmadan önce tarayıcı uyarılarıyla karşılaşabilir.

Taşıma e-postayı etkiliyorsa, bunu sonradan düşünülecek bir konu gibi ele almayın. Alan adı değişiklikleri sıklıkla SPF, DKIM, DMARC, MX kayıtlarını, takip bağlantılarını ve işlem e-postalarını bozar. Önemli kayıtlar hakkında tazeleme için geliştirici dostu MX, SPF, DKIM ve DMARC rehberimize bakın.

Canonical etiketlerini, dahili bağlantıları ve sitemap’leri kontrol edin

Yayından sonra yeni alan adı, sanki içeriğin her zaman canonical eviymiş gibi davranmalıdır.

Bu şu anlama gelir:

• Canonical etiketleri eski alan adına değil, yeni URL’lere işaret eder.
• Dahili bağlantılar yeni alan adını veya köke göreli yolları kullanır.
• XML sitemap’leri yalnızca nihai, dizine eklenebilir yeni URL’leri içerir.
• hreflang anotasyonları kullanılıyorsa yeni URL’leri referans alır.
• Open Graph, structured data ve alternate bağlantılar güncellenir.
• Robots.txt önemli bölümleri engellemez.

Eski URL’lerle dolu bir sitemap yayınlayıp yönlendirmelerin bunu temizlemesini beklemeyin. Sitemap, dizine eklenmesini istediğiniz URL’lerin listesi olmalıdır. Taşıma sonrasında bu, yeni alan adındaki nihai URL’ler anlamına gelir.

Canonical çelişkilerine de dikkat edin. Eski adresten yenisine yönlenen, ancak canonical etiketi eski alan adına geri işaret eden bir sayfa karışık sinyaller gönderir. Arama motorları genellikle bir miktar tutarsızlığın üstesinden gelebilir, ancak bunu onlardan istememelisiniz.

Yayın gününde her şeyi değiştirmeyin

Bir taşıma zaten yeterince büyük bir olaydır. Mümkünse bunu büyük içerik budama çalışmaları, şablon yeniden yazımları, gezinme değişiklikleri, JavaScript rendering değişiklikleri veya yeni bir performans profiliyle birleştirmekten kaçının.

Bu batıl inanç değildir. Hata ayıklama disiplinidir. Yayından sonra sıralamalar düşerse, nedenin yönlendirme eşlemesi mi, tarama erişimi mi, değişen içerik mi, daha yavaş rendering mi, eksik structured data mı yoksa başka bir şey mi olduğunu bilmeniz gerekir.

İlk yayını, pratik olduğu ölçüde eski siteye yakın tutun. Yeni alan adı stabil hale geldiğinde, daha büyük editoryal ve tasarım değişikliklerini daha küçük partiler halinde yapın.

Arama motorlarına neyin değiştiğini söyleyin

Google Search Console’da hem eski hem de yeni alan adlarını doğrulayın. Ardından taşıma alan adı düzeyinde bir değişiklikse ve içerik yeni bir alan adına taşınıyorsa Change of Address aracını kullanın. Yayından sonra yeni sitemap’i gönderin.

Bu, yönlendirmelerin yerine geçmez. Onları destekler. Arama motorlarının URL düzeyindeki eşlemeyi anlamak için hâlâ taranabilir, kalıcı yönlendirmelere ihtiyacı vardır.

Bing ve diğer arama motorları için, mevcut olduğu yerlerde webmaster araçlarını kullanın. Ayrıca kontrol ettiğiniz yerleri güncelleyin: sosyal profiller, işletme kayıtları, reklam hedefleri, e-posta imzaları, dokümantasyon, iş ortağı bağlantıları ve sendikasyon içeriklerdeki canonical referansları.

Harici bağlantıların tamamı güncellenmeyecektir; bu sorun değildir. Ancak en önemlileri güncellenmelidir. Büyük bir iş ortağı, uygulama pazarı, dokümantasyon portalı veya basın sayfası eski alan adına bağlantı veriyorsa güncelleme isteyin.

Yayından sonra doğru şeyleri izleyin

Taşıma sonrası ilk birkaç gün kutlama değil, aktif izleme dönemi olmalıdır.

Şunları kontrol edin:

• Eski ve yeni alan adlarında tarama etkinliği için sunucu logları
• 404’ler ve beklenmeyen 5xx hataları
• Yönlendirme zincirleri ve döngüleri
• Search Console’da dizine ekleme durumu
• Sitemap keşfi ve işlenmesi
• Organik açılış sayfaları ve sorgu kalıpları
• Eski URL’lere bağlı dönüşüm yolları
• Analytics filtreleri ve referral exclusions

Raporlama gürültüsü bekleyin. Bazı analytics araçları, doğru yapılandırılmadıkça yeni alan adını yeni bir mülk olarak ele alır. Bazı panolar eski alan adı trafiğini yeni alan adı trafiğiyle karşılaştırır ve taşımayı olduğundan daha kötü gösterir.

Arama görünürlüğü birkaç hafta dalgalanabilir. İstemediğiniz şey, yüksek değerli eski URL’lerin tekrar tekrar taranmasına rağmen düzgün yönlendirilmemesi veya yeni sayfaların keşfedilip eski alan adının kopyaları olarak işaretlenmesidir.

Performans da göz ardı edilmemelidir. Yeni alan adı daha ağır şablonlarla, bozuk caching ile veya optimize edilmemiş varlıklarla yayına girerse, kullanıcılar taşımayı bir yavaşlama olarak hissedebilir. Kontrollerinizin parçası olarak Lighthouse kullanıyorsanız, öncelikleri akılda tutarak okuyun; paniklemeden Lighthouse raporu nasıl okunur yazımız anlamlı sorunları gürültüden ayırmayı açıklar.

Eski alan adını uzun süre tutun

Taşıma “çalıştıktan” sonra eski alan adının süresinin dolmasına izin vermeyin. Kayıtlı tutun, sertifikaları geçerli tutun ve yönlendirmeleri mümkün olduğunca uzun süre çalışır durumda bırakın. Pratikte bu çoğu zaman yıllar anlamına gelir.

Eski bağlantılar blog yazılarında, yer imlerinde, dokümantasyonda, PDF’lerde, e-postalarda ve sosyal paylaşımlarda var olmaya devam eder. Yönlendirmeler, bu tarihsel iz ile yeni alan adı arasındaki köprüdür. Bunları çok erken kapatmak kullanıcıların yollarını kırar ve birikmiş sinyalleri boşa harcar.

Yönlendirme haritanızın ve yayın notlarınızın bir kopyasını da saklayın. Altı ay sonra biri eski bir URL’nin neden belirli şekilde davrandığını sorduğunda, bunu belgelendirmiş olduğunuz için memnun olacaksınız.

<!-- tool-cta:start -->

💡 Bunu deneyin: Geçişten sonra eski URL'lerinizi Redirect Checker üzerinden izleyerek her birinin doğru yeni sayfaya tek bir 301 atlamasıyla çözümlendiğini doğrulayın.

<!-- tool-cta:end -->

Mantıklı bir taşıma kontrol listesi

Yayından önce:

• Her iki alan adını Search Console’da doğrulayın.
• Mevcut siteyi tarayın ve önemli URL’leri dışa aktarın.
• Bire bir yönlendirme haritası oluşturun.
• DNS TTL’lerini düşürün.
• Eski ve yeni alan adları için TLS sertifikalarını hazırlayın.
• Canonical etiketlerini, dahili bağlantıları, hreflang’i, structured data’yı ve sitemap’leri güncelleyin.
• Yönlendirmeleri staging ortamında veya kontrollü bir ortamda test edin.

Yayın gününde:

• Yönlendirmeleri devreye alın.
• HTTP’den HTTPS’e davranışı doğrulayın.
• Her şablon türünden önemli URL örneklerini test edin.
• Yeni sitemap’i gönderin.
• Uygun olduğu yerde Change of Address aracını kullanın.
• Sunucu hatalarını, yönlendirme döngülerini ve engellenmiş kaynakları izleyin.

Yayından sonra:

• Tarama hatalarını ve dizine ekleme raporlarını izleyin.
• Yapabildiğiniz yerlerde önemli harici bağlantıları güncelleyin.
• Trafiği yalnızca alan adı toplamlarına göre değil, açılış sayfası niyetine göre karşılaştırın.
• Yönlendirmeleri süresiz olarak canlı tutun.
• Taşıma stabil hale gelene kadar ilgisiz yeniden tasarım veya içerik deneylerini erteleyin.

Alan adı taşımaları risksiz değildir, ancak yönetilebilir. Sıralamalar genellikle taşıma belirsiz sinyaller gönderdiğinde zarar görür: eksik yönlendirmeler, değişmiş içerik, çelişkili canonical etiketleri, engellenmiş tarayıcılar veya unutulmuş bir eski alan adı. Arama motorlarına ve kullanıcılara temiz bir harita verin; taşıma çok daha az dramatik hale gelir.