Domain taşıma kararı genellikle teknik bir işlem gibi görünür; eski sunucudan yeni sunucuya geçiş, bir DNS kaydı değişikliği ve birkaç dakikalık bekleme. Ama URL mimarisini, iç linkleri ve sitemap yapısını doğrudan tehdit eden bu değişiklik, haftalarca uğraşılarak oluşturulan hiyerarşiyi sessizce dağıtabilir.

Zararın büyük kısmı taşıma sırasında değil, taşıma sonrasında ortaya çıkar. Yeni domain indekslenmeye başladıkça eski URL'ler ölü uçlara dönüşür, iç linkler bozuk kalır ve sitemap gerçekle çelişmeye başlar. Arama motorları bu tutarsızlıkla karşılaştığında sayfaları doğru konumlara atamakta zorlanır.

İyi hazırlanmış bir domain taşıması mimari bütünlüğü korur; sadece redirect kuralları eklemekle değil, URL yapısını, iç link grafını ve sitemap doğruluğunu sistematik biçimde aktararak. Aşağıdaki bölümler bu aktarımın kırılma noktalarını sırayla izler.

Domain taşıma neden mimari hasara yol açar?

URL'ler, bir sitenin yapısını kodlar. /blog/seo/ altındaki bir sayfa ile /seo-blog/ altındaki aynı sayfa, arama motorları açısından farklı konumdaki farklı belgelerdir. Domain değiştiğinde bu yapı otomatik olarak aktarılmaz; her URL yeni domaine elle ya da kurala dayalı biçimde eşlenmezse eski adresler boş yere 404 döndürür.

İç linkler ikinci hasar noktasıdır. Eski sitede https://eskidomain.com/hizmetler/ adresini işaret eden onlarca iç link, taşıma sonrasında aynı kalmaya devam eder. Yeni domaine 301 yönlendirme konulsa bile bu linkler mimari açıdan pasif hale gelir; bot ve kullanıcı ek bir hop atarak ilerler, hiyerarşik sinyal zayıflar. Üstelik bu hop'ların birikmesi, özellikle derin hiyerarşi seviyelerindeki sayfalarda crawl bütçesinin verimsiz harcanmasına da zemin hazırlar. Tıklama derinliği açısından da sorun aynıdır; üç hop gerektiren bir sayfa, hiyerarşide üçüncü seviyedeymiş gibi değil, daha derindeymiş gibi davranmaya başlar.

Sitemap bütünlüğü üçüncü kırılma noktasıdır. Eski sitemapı yayında bırakan, yeni sitemapi güncel tutmayan veya her ikisini Search Console'a gönderen siteler karma bir indeks oluşturur. Hangi URL'nin kanonik olduğu belirsizleşir; gereksiz yinelenen içerik riski artar.

Redirect haritası: taşımanın teknik omurgası

Redirect haritası, eski URL'lerden yeni URL'lere bire bir ya da kurala dayalı eşleme tablosudur. Kurallara dayalı eşleme - örneğin tüm eskidomain.com/* adreslerini yenidomain.com/* biçiminde yönlendirmek - URL yapısı aynı kalıyorsa yeterlidir. Yapı değişiyorsa bu yol hatalı hedefler üretir ve hasar kontrol altına alınamaz.

Haritayı hazırlamadan önce eski sitenin tam URL envanteri çıkarılmalıdır. Sitemap, sunucu log dosyaları ve Search Console raporu, bu üç kaynağın birleşimi en kapsamlı listeyi verir. Yalnızca sitemaptaki URL'lere güvenmek, sitemap dışında kalan ama trafik almaya devam eden sayfaları atlatır. Log dosyaları özellikle değerlidir; gerçek bot ve kullanıcı trafiğinin hangi URL'leri ziyaret ettiğini gösterdiğinden hem sitemap hem de mevcut linklerin kapsamadığı adresleri gün yüzüne çıkarır. Envantere eklenmesi gereken bir diğer kaynak ise dışarıdan gelen geri linklerdir; yüksek otorite taşıyan sayfalar redirect haritasında öncelikli sıraya alınırsa sinyal geçişi en kritik noktalarda kesintisiz kalır.

Harita tamamlandıktan sonra her satır elle değil, test aracıyla doğrulanmalıdır. 301 dışında dönen yanıtlar, zincirleme yönlendirmeler ve döngüler bu aşamada tespit edilmezse prodüksiyona açıldıktan sonra manuel müdahale gerekir. Test aşamasında bir sayfanın farklı giriş yollarını - doğrudan URL, yönlendirilmiş URL, kanonik üzerinden erişim - ayrı ayrı kontrol etmek, prodüksiyona geçtikten sonra beklenmedik hata kodlarını engeller. İki adımdan uzun redirect zincirleri mümkünse doğrudan bağlantıya dönüştürülmelidir; her ek hop geçiş sinyalini zayıflatır.

URL yapısını korumak ya da bilinçli değiştirmek

Domain taşımasını fırsata dönüştürüp URL yapısını da aynı anda iyileştirmek cazip görünür. Ama iki değişikliği eş zamanlı yapmak, sorun çıktığında nedenin tespitini güçleştirir. Yapı değişikliği varsa ya taşımadan önce tamamlanmış olmalı ya da taşıma oturduğundan sonra ayrı bir adımda ele alınmalıdır.

Küçük-büyük harf tutarlılığı gözden kaçan bir detaydır. Eski sitede /Hizmetler/ olan URL yeni sitede /hizmetler/ biçiminde açılıyorsa sunucu düzeyinde her ikisinin de doğru hedefe yönlendirildiğinden emin olunmalıdır. Sondaki eğik çizgi tutarlılığı da aynı şekilde kontrol edilmelidir; her iki biçim de kullanılabiliyorsa kanonik tercih netleştirilip tutarsızlık giderilmelidir.

Parametreli URL'ler, sayfalandırma ve filtre kombinasyonları özellikle sorunludur. Eski sitede ?sayfa=2 biçimindeki URL'ler arama motorları tarafından indekslenmişse bunlar için de redirect kuralları oluşturulmalıdır. Yoksa bu adresler 404 döner; sitenin başka yerlerinden hâlâ bu sayfalara link veriliyorsa ölü uçlar hızla çoğalır.

İç linkler taşındıktan sonra da eski domain adreslerini gösteriyorsa sitenin kendi içinde gereksiz hop'lar oluşur. Arama motorları bu durumu büyük ihtimalle 301 zinciri üzerinden çözer; ama bu çözüm, hiyerarşik sinyalin temiz aktarımı yerine bir yama işlevi görür. İç linklerin yeni domain adreslerine güncellenmesi temiz bir link grafı için zorunludur.

Toplu güncelleme yaparken özellikle iki URL biçimine dikkat edin: mutlak URL'ler (https://eskidomain.com/sayfa/) ve protokol-göreli URL'ler (//eskidomain.com/sayfa/). Kök göreli URL'ler (/sayfa/) domain değişikliğinden etkilenmez; bunları değiştirmek gerekmez. Mutlak ve protokol-göreli biçimler ise tüm içerik, şablon ve CMS veritabanı alanlarında sistematik biçimde taranmalıdır.

Navigasyon menüsü, footer linkleri ve site genelindeki şablon bileşenleri çoğu zaman CMS'de tek bir noktadan kontrol edilir. Ama breadcrumb bileşenleri, kategori widget'ları ve ilgili yazı blokları ayrı şablonlarda yer alabilir; bunların hepsi ayrıca kontrol edilmelidir. Derin hiyerarşi konumlarındaki sayfalar - üçüncü seviye kategoriler veya ürün detay sayfaları gibi - iç link sayısı zaten az olduğundan, eski domain adreslerine kalan tek bir link bile tıklama derinliğini orantısız biçimde artırabilir. İç link grafının tamamlanması, tıklama derinliği ve hiyerarşi düzeyinin taşıma sonrasında da tutarlı kalmasını sağlar.

Sitemap ve robots.txt yönetimi

Yeni sitenin sitemapı yalnızca yeni domain URL'lerini içermelidir. Eski ve yeni domain adreslerinin karışık bulunduğu bir sitemap, tarama botları için anlamsız bir liste üretir; hangi URL'nin öncelikli olduğu belirsizleşir. Karma sitemap aynı zamanda tarama sırasını da karıştırır; bot eski ve yeni adreslere dönüşümlü olarak uğrarsa crawl bütçesi her iki domain arasında bölünür ve yeni sitenin önemli sayfaları gerektiğinden geç keşfedilir.

Sitemap dosyası oluşturulduktan sonra Search Console'a yeni property için ayrıca gönderilmelidir. Eski domain property'si de aktif tutulmalı; oradaki hatalar ve kapsam raporları, taşımanın sağlıklı ilerlediğini izlemenin en doğrudan yoludur. Eski property kapanmadan önce indeks kapsamı bölümünde eski URL'lerin zamanla "yönlendirilen URL" olarak işaretlenip işaretlenmediğine bakılmalıdır.

robots.txt dosyası da ayrı incelenmesi gereken bir noktadır. Eski sitede belirli klasörleri veya parametreleri taramadan hariç tutan kurallar varsa bu kuralların yeni sitede de gerekli olup olmadığı değerlendirilmelidir. Eski siteye ait engelleme kurallarını yeni siteye olduğu gibi kopyalamak, ihtiyaç duyulmayan kısıtlamaları da beraberinde getirir.

Kanonik etiket tutarlılığı

Kanonik etiketler yanlış yapılandırıldığında mimari hasar sessizce büyür. Taşıma sırasında en sık görülen hata, yeni domain sayfalarının hâlâ eski domain URL'lerini kanonik olarak göstermesidir. Bu durumda yeni domain indekslense de kanonik sinyal eski adrese işaret ettiğinden arama motoru hangi sürümü öne çıkaracağı konusunda kararsız kalır.

Her sayfanın kanonik etiketi kendi URL'sini göstermelidir. Sayfa baskısı veya parametre varyasyonu için kullanılan kanonikler yeni domain adreslerine güncellenmelidir. Siteyi oluşturan şablon motoru kanonik URL'yi dinamik olarak üretiyorsa bu üretim mantığının yeni domain adresini baz aldığı doğrulanmalıdır.

Kanonik - sitemap - hreflang üçlüsünün tutarlı olması gerekir. Uluslararası site yapısı varsa hreflang etiketlerindeki domain referansları da güncellenmeden taşıma tamamlanmış sayılmamalıdır; tutarsız hreflang, dil ve bölge hedeflemesini bozar. Aynı sayfanın hem sitemap hem kanonik hem hreflang üzerinden tutarlı biçimde tanımlanması, arama motorunun doğru URL'yi güvenle seçmesinin önünü açar. Özellikle aynı içeriğin birden fazla dil sürümü yayınlanıyorsa tek bir yanlış domain referansı tüm hreflang kümesini etkisiz hale getirebilir; arama motoru bu durumda hangi sayfayı hangi kullanıcıya sunacağını belirleyemez.

Taşıma sonrası doğrulama kontrol listesi

Redirect haritası çalışıyor mu? Eski domain URL'lerinin tamamı, özellikle en çok trafik alan sayfalar, 301 ile doğru hedefe yönlendirilmelidir. Bir tarama botu çalıştırarak eski URL listesi üzerinden toplu yanıt kodu kontrolü yapılabilir.

  • Eski domain URL'leri 301 ile doğru hedefe yönleniyor mu?
  • Redirect zinciri iki adımı geçiyor mu? Varsa doğrudan bağlantıya dönüştürülmeli.
  • İç linkler eski domain adreslerine işaret ediyor mu? Varsa güncellenmelidir.
  • Sitemap yalnızca yeni domain URL'lerini içeriyor mu?
  • Kanonik etiketler yeni domain URL'lerini gösteriyor mu?
  • robots.txt dosyası gerekli sayfaları engelliyor mu, gereksiz kısıtlama var mı?
  • Search Console'da yeni property oluşturuldu ve sitemap gönderildi mi?
  • Hreflang etiketleri varsa yeni domain adreslerine güncellendi mi?
  • 404 sayfası düzgün çalışıyor mu, redirect haritası dışındaki eski URL'ler için gerçek 404 dönüyor mu?

Kontrol listesinin her maddesi bir kez onaylandıktan sonra izleme periyodu başlar. Yeni domain için arama görünürlüğünün önceki seviyeye dönmesi zaman alır; bu süre, sitenin büyüklüğüne ve taşımanın temizliğine göre değişir. Ama mimari tutarlılık sağlandıysa bu süreç öngörülebilir bir yolda ilerler.

Domain taşıması, iç link grafının ve URL hiyerarşisinin sıfırdan gözden geçirildiği nadir fırsatlardan biridir. Yönlendirmeler doğru kurulmuş, iç linkler güncellenmiş ve sitemap tutarlı hale getirilmişse taşıma kalıcı bir mimari kayba değil, temiz bir geçişe dönüşür. Bunlardan herhangi biri atlanmışsa sorun görünür hale gelmeden önce hata kaynağını bulmak giderek güçleşir. Taşıma geçici bir süreçtir; ama yanlış kurulmuş bir redirect zinciri veya güncellenmemiş iç linkler, taşıma çok önce tamamlanmış olsa bile mimari üzerindeki etkisini sürdürür.