Site taşımasında SEO riskini azaltmanın ilk adımı, hangi şeyin değiştiğini açıkça belirlemektir. Hosting değişirken adresler aynı kalabilir; alan adı veya sayfa yolu değiştiğinde ise URL haritası gerekir. Her geçişe topluca 301 eklemek doğru bir plan değildir ve hiçbir yöntem trafik kaybının olmayacağını garanti etmez.
Taşıma envanterini URL ve içerik kimliğiyle oluşturun
Eski sitemap, içerik sistemi, sunucu kayıtları ve erişiminiz varsa Search Console sayfa verilerini birleştirin. Yalnız ana menüdeki sayfaları saymak arşiv, araç, görsel ve eski kampanya adreslerini kaçırabilir. Her adresin mevcut yanıtını ve yeni karşılığını kaydedin.
Haritada eski URL, beklenen yeni URL, içerik durumu ve kabul sonucu bulunmalıdır. Adres korunuyorsa doğrudan çalışmasını test edin. Adres değişiyorsa aynı ihtiyaca cevap veren hedef seçin. Karşılığı olmayan değerli sayfayı alakasız ana sayfaya göndermek içerik eşdeğerliği sağlamaz.
Kaynak listeler birbirinin yerine geçmez
Sitemap yalnız oraya eklenmiş adresleri gösterir; geçmişte bağlantı almış eski kampanya sayfasını kaçırabilir. İçerik sistemi taslak veya yardımcı kayıtlar içerebilir. Sunucu günlükleri ise dönem ve saklama kapsamıyla sınırlıdır. Kaynakların hangilerini kullandığınızı ve hangi alanlarda veri eksik kaldığını yazın. Erişmediğiniz Search Console hesabı veya geçmiş trafik verisi incelenmiş gibi raporlanmamalıdır.
Envanterde sayfa türü, mevcut durum kodu, canonical, içerik kimliği ve medya ilişkisi bulunabilir. Aynı başlıklı iki sayfanın gerçekten aynı içerik olduğunu varsaymayın. Bloglarda özgün yayın tarihi ve eski slug ayrı korunmalıdır. Tarihi yalnız yeni sisteme aktarıldığı için bugüne çekmek içerik geçmişini yanlış gösterebilir; gerçek revizyon tarihi ayrıca kaydedilir.
URL korunması ile URL değişimini ayrı planlayın
Google’ın URL değişmeden hosting taşıma rehberi, altyapı geçişini ayrı ele alır. 9 Ekim 2026 kaynak kontrolünde bu ayrım geçerlidir. Bir projede altyapı, URL ve bütün içeriklerin aynı anda değişmesi sorun kaynağını bulmayı zorlaştırabilir.
WordPress’ten Next.js’e geçerken kaynak metin, yayın tarihi ve medya kopyalarını saklayın. Büyük editoryal revizyonu geri alınabilir ayrı bir yayın paketinde tutun. Yerel testin geçmesi, yeni hostingin doğru SSL, proxy veya environment ile çalıştığını kanıtlamaz.
Diğer sütunları görmek için yatay kaydırın.
| Durum | Beklenen davranış | Kabul kanıtı |
|---|---|---|
| Adres ve içerik korunuyor | Aynı URL doğrudan çalışır | HTTP ve içerik eşleşmesi |
| Kalıcı eşdeğer yeni adres | Doğru kalıcı yönlendirme | Durum kodu, hedef ve içerik |
| Karşılığı bulunmuyor | Açık içerik kararı gerekir | Değer ve eşdeğerlik değerlendirmesi |
| Yalnız hosting değişiyor | URL haritası korunur | Yeni sunucuda aynı adresler |
Aynı geçişte yapılan değişiklikleri geri alınabilir tutun
Tasarım, içerik ve altyapı aynı anda değiştiğinde bir sorunun kaynağını ayırmak zorlaşır. Gereken değişiklikler ayrı paket ve kabul kaydıyla yönetilebilir. Bu, her projede tek değişkenle yayın yapılabileceği anlamına gelmez; birlikte değişen kapsamın görünür tutulması gerekir. Kaynak metin ve medya kopyaları, yalnız Git geçmişine güvenmeden uygun yedekleme planında korunmalıdır.
Yönlendirme zinciri, canonical ve iç bağlantıyı birlikte test edin
Gerçekten kalıcı taşınan adres için kalıcı sunucu yönlendirmesi planlayın. Beklenen durum kodunu, Location hedefini ve hedefin içerik yanıtını kontrol edin. Zincir, döngü ve http/https geçişinin üst üste binmesi ayrıca test edilmelidir.
İç bağlantılar yeni doğru hedefi doğrudan göstermelidir. Sitemap ve canonical aynı tercih edilen adresi kullanmalıdır. Medya URL’leri değişiyorsa bunları da envantere alın; sayfanın açılması bütün görsel ve dosyaların korunduğu anlamına gelmez.
Eski URL'nin yeni sayfaya yönlenmesi yeterli değildir. Hedefin HTTP 200 vermesi, beklenen içerik ve tercih edilen canonical'ı taşıması kontrol edilir. http/https, www ve slash normalleştirmeleri üst üste bindiğinde gereksiz zincir oluşabilir. Döngü veya yanlış alan adı yönlendirmesi test edilmeden canlı geçiş yapılmamalıdır. Geçici önizleme adresi üretim canonical'ı yerine sızmamalıdır.
Medya ve dosya URL'leri de taşıma kapsamındadır
Ürün görselleri, PDF kılavuzlar ve eski paylaşımlardaki kapaklar ayrı envanter gerektirebilir. Sayfa içindeki görselin çalışması, dışarıdan kullanılan eski medya adresinin korunduğunu göstermez. Özgün dosya yoksa yerine alakasız görsel koymak içerik eşdeğerliği sağlamaz. Eksik varlığın durumu ve kullanıcıya etkisi açık raporlanmalıdır.
Yeni iç bağlantılar doğru son hedefi doğrudan göstermelidir. Sitemap, canonical ve navigasyon farklı adresleri tercih ediyorsa geçiş sinyalleri tutarsızlaşır. Şablon değişikliği birden fazla sayfayı etkilediğinde yalnız ana sayfayı test etmek yeterli değildir. Blog, arşiv, araç ve hizmet sayfasından gerçek örnekler seçin.
Yedekleme ve geri dönüşü veri akışıyla birlikte prova edin
Veritabanı, yüklemeler, kaynak kod ve sunucu ayarlarının yedeğini alın; yalnız dosyanın oluşmasını değil geri yüklenmesini doğrulayın. Yeni sunucuyu canlı DNS’i değiştirmeden test etme yöntemini hosting ekibiyle belirleyin. E-posta kayıtları ve üçüncü taraf callback adresleri web trafiğinden ayrı değerlendirilmelidir.
Rollback kararını hangi hatanın tetikleyeceğini yazın: yaygın değerli URL kaybı, ödeme veya form arızası, erişim engeli gibi. Sorumlu kişi ve eski sunucunun ne kadar süre korunacağı belli olsun. Yayın sırasında oluşan yeni sipariş ve başvuruların eski sisteme nasıl taşınacağını planlamadan geri dönüş tam değildir.
Yedek dosyasının varlığı geri yükleme başarısı değildir
Veritabanı, yüklemeler, kod ve gerekli yapılandırma dosyaları uygun güvenlikle saklanır. Geri yükleme ayrılmış ortamda denenmeli; kritik sayfa ve işlem örnekleri açılmalıdır. Gizli anahtarların rapora veya açık dosyaya dökülmemesi gerekir. Yedek tarihi, kapsamı ve erişim sorumlusu kaydedilir. Tam yedek alınmış gibi görünürken yükleme klasörünün dışarıda kalması sık rastlanabilecek bir kapsam hatasıdır.
Temsili geri dönüş sorunu: Yeni site açıldıktan sonra teklif başvuruları gelir, sonra eski siteye dönülür. Yeni kayıtların nerede tutulduğu ve eski sistemde nasıl izleneceği bilinmiyorsa teknik geri dönüş müşteri kaybını önlemeyebilir. Form, sipariş veya stok yazan sistemler için veri aktarımı ve çift yazım riski ayrıca planlanmalıdır. Salt içerik sitesi ile işlem alan mağazanın rollback planı aynı değildir.
DNS, SSL, proxy, e-posta kayıtları ve üçüncü taraf callback adresleri ilgili sorumlularla kontrol edilir. Bu rehber canlı DNS değişikliği yaptığını iddia etmez. Eski sunucunun korunma süresi ve geri dönüş kararı işletmenin koşullarına göre belirlenir; bütün projeler için sabit süre önerilmez. Yayına engel durumlar somut örnek ve sorumluyla yazılmalıdır.
Yayın sonrası teknik kabul ve Search Console izlemesi
Form ve ödeme sağlayıcısı dönüş adresleri alan adı değişiminden etkilenebilir. Yetkili ekip ilgili callback ve izin verilen alan adı listelerini gerçek sağlayıcı panelinde kontrol etmelidir. Yerel uygulamada çalışan bir form, yeni hostingte e-posta servisine erişemeyebilir. Environment değişkenleri raporda yalnız tanımlı/eksik olarak incelenir; gizli değerler test çıktısına dökülmez.
Yayından önce örnek hata senaryosu üzerinde sorumluluk provası yapın: değerli bir URL yanlış hedefe gidiyor, form kayıtları oluşmuyor veya sertifika hatası görülüyor. Kimin karar vereceği ve hangi kanıtın geri dönüşü tetikleyeceği yazılı olmalıdır. Her hata bütün geçişi geri almayı gerektirmeyebilir; etkilenen kapsam ve düzeltme güvenilirliği birlikte değerlendirilir. Bu kararlar canlı değişiklik izni yerine geçmez.
Önemli URL örneklerini, sunucu hatalarını, form teslimini, tarama erişimini ve sitemap durumunu kontrol edin. Search Console mülk doğrulamasının korunduğunu sınayın. İlk günkü sıralama hareketini tek başına bütün geçişin başarısı veya başarısızlığı saymayın.
SEO geçiş denetimi için URL haritası ve kanıt dosyasıyla başlayın. Sorunlu sayfalarda Search Console teşhis rehberi yardımcı olur. Bu projede hazırlanan yerel yayın planı, production deploy veya DNS değişikliğinin gerçekleştiği anlamına gelmez.
İlk kontrolde değerli adresler, yönlendirmeler, robots, sitemap ve formlar gerçek sunucuda sınanır. Sertifika zinciri ve alan adı davranışı yerel build testinden farklıdır. Gerçek form teslimi veya ödeme sonucu test edilmediyse mock kabulü canlı başarı diye sunulmaz. İzleme kayıtları hata oranı ve etkilenen URL kapsamını içermelidir.
Search Console mülk doğrulaması ve sitemap gönderimi yetkili hesap üzerinden yapılır. Tarama ve indeks verisinin zamanla güncellenmesi izlenir; tek günlük sıralama hareketinden kesin geçiş başarısı çıkarılmaz. Kapanış dosyası URL haritası, kaynak yedekleri, gerçek test kanıtları ve henüz doğrulanmamış alanları birlikte taşır. Güvenilir geçiş, kayıpsız trafik garantisi değil risklerin görünür ve geri alınabilir biçimde yönetilmesidir.
