SEO Migration (Site Taşıma) Süreci Nasıl Yönetilir?

SEO migration, URL, alan adı, CMS veya sunum mimarisi değişirken arama ve kullanıcı erişimini korumaya yönelik kontrollü geçiştir. Sıfır kayıp, belirli büyüme yüzdesi veya sabit toparlanma süresi garanti değildir. Bu rehber karar, eşleme ve yayın kabulüne odaklanır; rendering değişimi için JavaScript SEO rehberini kullanın.

Önce neyin değiştiğini ayırın

Değişiklik	Öncelikli kontrol
URL aynı, hosting/CMS farklı	Aynı URL’de içerik, durum kodu, meta ve kaynak erişimi
Alan adı veya URL yolu değişiyor	Eski-yeni eşleme, kalıcı yönlendirme, canonical ve site haritası
Tasarım/render mimarisi değişiyor	HTML/DOM içeriği, bağlantılar, formlar ve performans
İçerik kaldırılıyor veya birleşiyor	Gerçek karşılık ve kaldırma gerekçesi

Bütün değişiklikleri aynı yayına yığmak hatanın kaynağını bulmayı zorlaştırır. Projenin izin verdiği ölçüde aşamalı geçiş ve geri alma noktaları planlayın. URL değişikliği varsa Google’ın site taşıma rehberini, kullanıcıya görünen URL aynı kalıp yalnız hosting/CDN değişiyorsa hosting değiştirme rehberini izleyin. İki senaryonun DNS, eşleme ve yönlendirme adımları aynı değildir.

Envanter ve eşleme tablosu

CMS rotalarını, site haritasını, iç bağlantıları ve erişilebilen analitik/log verilerini birleştirin. Görsel, PDF ve diğer trafik alan dosyaları unutmayın. Hangi kaynağın eksik olduğunu kaydedin; envanteri site haritası dışındaki kaynaklarla da tamamlayın.

Eşleme kaydı eski URL, karar, yeni URL, gerekçe, beklenen HTTP, uygulama sahibi ve test sonucu alanlarını içersin. Gerçek karşılık varsa kalıcı yönlendirme; karşılık yoksa gerekçeli 404/410 değerlendirmesi yapın. Sırf hata sayısını azaltmak için tüm eski sayfaları ana sayfaya gönderme kullanıcının işini çözmez ve soft 404 yorumuna yol açabilir. Sabit PageRank korunma/kayıp yüzdesi hesaplamayın.

Hayali örnek	Karar	Kabul
/eski-urun/ → /urun/yeni-ad/	Aynı ürün, kalıcı taşıma	Tek adım 301/308; hedef 200 ve doğru içerik
/eski-rehber/ → /rehber/	İçerik aynı niyetle birleşti	Gerekçe ve hedef içerik kontrolü
/kaldirilan/ → karşılık yok	Gerçek kaldırma	404/410; ana sayfa HTML’iyle 200 dönmemeli

Redirect map aracı sabit Cloudflare Pages kural taslağı üretir; query parametreli kaynakları veya bütün sunucu türlerini desteklediğini varsaymayın. Taslak üretimi canlı HTTP kabulü değildir. Canonical ile içerik taşımasını ayırmak için canonical veya 301 rehberini inceleyin.

Yayın öncesi kapılar

Staging’i erişim kontrolüyle koruyun; noindex gizlilik mekanizması değildir. Yayına taşınacak URL politikasını tek tek belirleyin: üretimde bilerek noindex olan form sayfasını topluca dizine açmayın.

1. Önemli URL ve şablonlarda içerik, title, canonical, robots ve gerçek href’leri karşılaştırın.
2. Tüm eşleme satırlarında döngü/zincir, eksik hedef ve yanlış origin kontrolü yapın.
3. Hedefler ve iç bağlantılar yeni canonical politikasını izlesin; site haritasına yalnız uygun URL’ler girsin.
4. DNS/TLS, statik dosyalar, form başarısı ve analitik ölçümünü ayrıca test edin.
5. Eski sürüm, yönlendirme ayarı ve geri alma koşulunu yayın öncesi kaydedin.

Üç ek taşıma kapısı

Google’ın site taşıma belgesi, URL eşlemesi yanında dil anotasyonlarını ve Google Search Console doğrulama yöntemlerini kontrol etmeyi önerir. Ek tarama talebi ve sunucu kapasitesi proje loglarıyla ayrıca izlenmelidir.

Kapı	Yapılacak iş	Kaydedilecek kanıt
Çok dilli URL ilişkileri	Eski-yeni eşlemeye her dil karşılığını ekle. Hreflang hedeflerini yeni URL’lere taşı; hedef HTTP, dil içeriği ve karşılıklı dönüş bağlantısını incele.	URL çifti, HTML anotasyonu, HTTP sonucu; veri yoksa bilinmiyor
Mülk doğrulaması	Kullanılan Search Console doğrulama yöntemini belirle. HTML dosyası veya meta etiketi gerekiyorsa yeni yayında korunduğunu kontrol et; kaynak varlığını mülk erişimi kabulü sayma.	Dosya/etiket erişimi ve ayrıca yetkili mülk doğrulama sonucu
Tarama yükü	Eski ve yeni URL’lerin aynı dönemde istek alabileceğini hesaba kat. Hosting kapasitesi, hata oranı ve yanıt süresi için önceki kaydı ve geçiş sonrası logları karşılaştır.	Zaman aralığı, istek/hata sayıları ve sunucu yanıt ölçümü; log yoksa bilinmiyor

Bu üç kapıyı eşleme tablonuza ve yayın kontrol listenize ekleyin:

• Test ortamı sonucunu, canlı HTTP yanıtını, Search Console mülk erişimini ve organik trafik sonucunu ayrı sütunlarda tutun.
• Eksik sunucu kaydını veya hesap erişimini açıkça not edin.
• Dil sürümleri arasındaki karşılıklı bağlantı eksikse, mülk doğrulaması kaybolduysa veya yaygın sunucu hatası varsa ilgili kapıyı tamamlanmadı olarak işaretleyin.

Yayın sonrası kabul

Yayından hemen sonra küçük ama temsil edici bir URL örneklemini ve eşleme listesinin tamamını kontrol edin; örneklem, tüm kuralların kabulü yerine geçmez:

1. Eski URL’lerin beklenen 301/308 ile tek adımda doğru, erişilebilir son hedefe gittiğini; taşınan içerik, görsel ve dosya URL’lerinin de doğru davrandığını doğrulayın. Hedefin 200 dönmesinin yanında içeriğin eski sayfayla eşdeğer olduğunu da kontrol edin.
2. Yeni sayfalarda canonical, robots, dil alternates ve iç bağlantıların hedef politikasını; güncellenen site haritasında yalnız yeni canonical URL’lerin bulunduğunu denetleyin. Kaldırılan ve eşdeğer karşılığı olmayan URL’lerin gerçek 404/410 yanıtını kontrol edin.
3. Yeni host veya alan adı kullanılıyorsa HTTPS, DNS’in farklı çözümleyicilerde yayılımı, robots.txt erişimi, statik dosyalar, formlar ve temel kullanıcı akışlarını sınayın. Hosting değişiminde eski ortamı, yeni ortam doğru içerik sunup erişim ve log kontrolleri tamamlanana kadar kapatmayın.
4. Search Console erişimi varsa eski ve yeni doğrulanmış mülklerde site haritası ve indeksleme raporlarını; sunucu loglarında Googlebot isteklerini, beklenmeyen 4xx/5xx yanıtlarını ve yanıt sürelerini izleyin. Analytics ve iş dönüşümlerini ayrı kaynaklarda takip edin. Erişim veya log yoksa sonucu unknown bırakın.
5. Önceden yazılmış geri alma koşulunu uygulayın: örneğin yaygın yanlış yönlendirme, önemli sayfalarda noindex/robots engeli, formun çalışmaması veya geniş sunucu hatası. Eşik ve sorumlu kişiyi geçişten önce belirleyin; tek günlük sıralama değişimini otomatik geri alma kuralı yapmayın.

Toplam 404 sayısına bakmak yerine hataları eski-yeni URL eşlemesi, şablon ve kullanıcı etkisiyle inceleyin.

GSC erişimi varsa eski/yeni mülkleri ve uygun taşıma için Adres Değişikliği aracının şartlarını değerlendirin. Bu araç her CMS, yol veya HTTP→HTTPS değişikliği için çalıştırılmaz. Yönlendirme ve site haritası kurulumunun yerine geçmez.

Teknik yayın kabulü ile organik sonuç kabulünü ayırın. 14/28/56 günlük karşılaştırmada ülke, cihaz, marka sorguları ve mevsimselliği koruyun; bu aralıkları toparlanma tarihi olarak değil, karşılaştırma noktası olarak kullanın. Google kalıcı yönlendirmeleri genel olarak en az bir yıl tutmayı önerir; kullanıcılar için daha uzun süre gerekli olabilir. Sabit %10-15 dalgalanmayı normal ilan etmeyin; değişimin nedenini araştırın.

Sık sorulan sorular

CMS değişirken bütün slug’ları yenilemeli miyim?

Hayır. Çalışan URL’yi korumak ek eşleme ve keşif yükünü azaltır; değişiklik kullanıcı veya mimari gerekçesiyle yapılır.

Trafik ne zaman eski seviyeye gelir?

Sabit bir süre söylenemez. Yeniden keşif/işleme, içerik değişimi ve teknik hataları ayrı değerlendirin.

Hangi durumda geri almalıyım?

Önceden tanımlanan kritik kabul hatasında: geniş noindex, erişim kesintisi, bozuk yönlendirme veya temel kullanıcı akışı arızası. Yalnız günlük sıra dalgalanmasına göre plansız geri dönüş yapmayın.

Kapsam için teknik SEO kontrol listesine ve SEO danışmanlığına geçebilirsiniz.