Site Taşıma SEO Rehberi: Domain veya Altyapı Değiştirirken Sıralama Kaybı Nasıl Önlenir?

Bir web sitesi yeni domaine, farklı CMS altyapısına veya tamamen yenilenmiş URL yapısına taşındığında bütün sayfalar açılıyor olabilir. Buna rağmen eski URL’ler yanlış hedefe yönleniyor, canonical etiketleri eski domaini gösteriyor veya önemli içerikler yeni sistemde unutuluyorsa organik görünürlük hızla kaybolabilir. Site taşıma SEO’su, yayından sonra birkaç yönlendirme eklemek değil; eski arama sinyallerinin yeni ve doğru URL’lerle eşleştirilmesini sağlayan kontrollü bir geçiş operasyonudur.

Taşımalar farklıdır. Yalnız hosting değişiyor ve kullanıcıların gördüğü URL’ler aynı kalıyorsa süreç domain veya path değişiminden daha basittir. Domain, protokol, klasör veya slug değişiyorsa Google’ın ve kullanıcıların eski adreslerden yeni karşılıklara yönlendirilmesi gerekir. CMS ve tasarım da aynı anda değişiyorsa içerik, link yapısı ve render davranışı ayrıca doğrulanmalıdır.

Bu rehber genel web sitesi yenileme sürecini tekrar etmez. Odak; URL mapping, yönlendirmeler, canonical sinyalleri, sitemap, Search Console, yayın sonrası monitoring ve gerektiğinde kontrollü rollback planıdır.

Site taşıma SEO’su nedir?

Site taşıma SEO’su, bir sitenin domaini, protokolü, URL yapısı, CMS’i veya hosting altyapısı değişirken mevcut organik arama sinyallerini mümkün olduğunca korumak için yapılan teknik ve operasyonel çalışmadır. Google’ın resmî site taşıma rehberi; HTTP’den HTTPS’e geçişi, domain değişimini ve URL path değişikliklerini görünür URL değişikliği içeren taşıma örnekleri arasında sayar Google Site Taşıma Rehberi.

Taşımanın temel amacı eski sayfanın en uygun yeni karşılığını göstermektir. Redirect, iç link, canonical, sitemap ve Search Console aynı yeni URL envanterini desteklemelidir.

Hangi değişiklikler site migration sayılır?

Google, yalnız hosting altyapısı değişiyor ve görünür URL’ler aynı kalıyorsa ayrı hosting taşıma rehberinin kullanılmasını önerir Google Hosting Değiştirme Rehberi. URL değişiyorsa daha kapsamlı site move süreci gerekir.

Taşıma öncesinde neden mevcut durum kaydı alınmalıdır?

Yayın sonrasında neyin kaybolduğunu anlayabilmek için önce mevcut sitenin ölçülebilir bir fotoğrafı çıkarılmalıdır. Yalnız toplam organik trafik değil; önemli landing page’ler, sorgular, indeks durumu, backlink alan URL’ler, status code dağılımı, canonical seçimleri ve sitemap envanteri kaydedilmelidir.

• Eski sitenin tam crawl çıktısı.
• XML sitemap ve canonical URL listesi.
• Search Console’daki yüksek gösterim ve tıklama alan sayfalar.
• Analitik sistemindeki organik landing page’ler ve dönüşümler.
• Backlink alan eski URL’ler.
• İndekslenebilirlik, canonical, robots ve hreflang verileri.
• Page title, H1, içerik uzunluğu ve structured data karşılaştırma alanları.
• Sunucu yanıt süreleri ve 4xx/5xx dağılımı.

Bu baseline, migration sonrası trafik düşüşünün sezon, algoritma güncellemesi veya teknik taşıma hatasından kaynaklanıp kaynaklanmadığını ayırmaya yardımcı olur. Google da trafik düşüşlerini URL, sorgu, ülke, cihaz ve arama görünümü boyutlarında Search Console üzerinden karşılaştırmayı önerir Google Search Trafiği Düşüşlerini İnceleme.

URL mapping nedir?

URL mapping, her eski indekslenebilir URL’nin yeni sitedeki en uygun karşılığıyla eşleştirilmesidir. Dosya genellikle “old URL”, “new URL”, “karar”, “HTTP sonucu”, “not” ve “kontrol durumu” sütunlarını taşır. Mapping yalnız mevcut sitemap’e göre hazırlanırsa sitemap dışında kalan fakat trafik veya backlink alan sayfalar unutulabilir.

Envanter; crawl, Search Console, analitik, backlink, CMS ve sunucu logu kaynaklarından birleştirilmelidir. Ardından her eski URL şu kararlardan birini almalıdır:

1. Aynı içeriğin yeni URL’sine birebir 301.
2. İçerik birleştirildiyse en yakın ve gerçekten karşılayan sayfaya 301.
3. Yeni sitede URL değişmeden korunuyorsa 200.
4. Kalıcı olarak kaldırıldı ve karşılığı yoksa 404 veya 410.
5. Geçici olarak kapalıysa migration dışında ayrı geçici politika.

Bütün eski URL’leri ana sayfaya yönlendirmek doğru mudur?

Hayır. Ürün, kategori, hizmet ve blog sayfalarının tamamını ana sayfaya yönlendirmek kullanıcı niyetini karşılamaz. Eski “kurumsal-web-tasarim” URL’si doğrudan ilgili yeni hizmet sayfasına gitmelidir; alakasız ana sayfa yönlendirmesi sayfa düzeyindeki bağlamı kaybettirir.

Eski sayfanın gerçek karşılığı yoksa 404 veya 410 çoğu zaman daha doğrudur. Yönlendirme yalnız yeni hedef eski içeriğin amacını anlamlı biçimde karşılıyorsa kullanılmalıdır.

301 yönlendirmeleri nasıl uygulanmalıdır?

Kalıcı site taşımasında sunucu taraflı 301 veya desteklenen kalıcı redirect yöntemi kullanılmalıdır. Google, redirect’i bir URL’nin yeni konumunu kullanıcılara ve Google Search’e bildiren mekanizma olarak açıklar Google Redirect Rehberi.

• Eski URL’yi doğrudan nihai yeni URL’ye yönlendirin.
• Redirect zinciri ve döngüsü oluşturmayın.
• HTTP, HTTPS, www ve non-www varyasyonlarını tek canonical hosta taşıyın.
• Query parametrelerinin gerçekten korunması gerekenlerini belirleyin.
• Regex kurallarını sayfa bazlı mapping örnekleriyle test edin.
• Redirect hedefinin 200 döndüğünü ve indekslenebilir olduğunu doğrulayın.
• Eski domaini ve redirect altyapısını uzun süre aktif tutun.

Google Search Console Change of Address yardım sayfası, domain taşımasında yönlendirmelerin en az 180 gün korunmasını; eski domainin başkası tarafından kötüye kullanılmasını önlemek amacıyla en az bir yıl elde tutulmasını önerir Search Console Change of Address.

Redirect chain neden migration riskidir?

Eski URL önce başka bir eski URL’ye, sonra HTTP’den HTTPS’e ve ardından yeni domaine gidiyorsa her aşama ek istek ve hata noktası oluşturur. Mapping doğrudan nihai hedefi göstermelidir. Önceki yıllardan kalan redirect kuralları yeni taşıma sırasında zincir üretmemelidir.

Yayın öncesi ve sonrasında bütün eski URL listesi otomatik olarak test edilmeli; redirect sayısı, nihai durum kodu, hedef URL ve içerik uyumu raporlanmalıdır.

Canonical etiketleri nasıl güncellenmelidir?

Yeni sayfalar kendi yeni URL’lerine self-canonical vermelidir. Eski domaini, staging hostunu veya önceki slug’ı gösteren canonical etiketleri migration sinyalleriyle çelişir. Google canonical rehberinde redirect ve rel="canonical" güçlü; sitemap dahilini daha zayıf canonical sinyalleri olarak açıklar Google Canonical Rehberi.

Canonical yalnız HTML kaynağında değil render edilmiş sayfada da doğrulanmalıdır. JavaScript’in canonical değerini değiştirmediği, sayfalama ve dil varyantlarının doğru hedefi gösterdiği kontrol edilmelidir.

İç linkler neden eski URL’lerden yeni URL’lere çevrilmelidir?

Redirect çalışıyor olsa bile menü, breadcrumb, footer, kategori ve içerik linklerinin eski URL’ye gitmeye devam etmesi gereksiz yönlendirme üretir. Site kendi içinde doğrudan yeni canonical URL’lere bağlanmalıdır. Google da site içi linklerde canonical URL’nin kullanılmasını önerir Google Canonical Rehberi.

XML sitemap migration sırasında nasıl yönetilmelidir?

Yeni sitemap yalnız yeni canonical, 200 dönen ve indekslenebilir URL’leri içermelidir. Google sitemap oluşturma rehberi, sitemap’e arama sonuçlarında görünmesini istediğiniz canonical URL’lerin eklenmesini önerir Google Sitemap Rehberi.

Domain veya URL değişiminde eski URL sitemap’i kısa süre Search Console’da tutulabilir; bu Google’ın eski adresleri yeniden tarayıp redirect’leri görmesine yardımcı olur. Yeni sitemap ayrıca yeni property’ye gönderilir. Sitemap içinde redirect, 404, noindex veya başka sayfaya canonical veren URL bulunmamalıdır.

Search Console hazırlığı nasıl yapılmalıdır?

Eski ve yeni domain veya host Search Console’da doğrulanmalıdır. Domain değişiminde Change of Address aracı yalnız taşıma tamamlanıp yönlendirmeler devreye girdikten sonra kullanılır. Google bu aracın domain veya subdomain değişimleri için olduğunu; HTTP–HTTPS geçişi ve aynı domain içindeki path değişikliklerinde kullanılmaması gerektiğini açıklar Search Console Change of Address.

• Eski ve yeni property sahipliğini yayın öncesinde doğrulayın.
• Doğrulama dosyası veya DNS kaydının migration sırasında kaybolmadığını kontrol edin.
• Yeni sitemap’i yeni property’ye gönderin.
• Domain değişiminde redirect testinden sonra Change of Address çalıştırın.
• Eski property verilerini izlemeye devam edin.
• Page Indexing, Crawl Stats ve URL Inspection örneklerini takip edin.

Taşıma ile tasarım ve içerik değişimi aynı anda yapılmalı mı?

Mümkünse domain, URL mimarisi, tasarım, içerik ve teknoloji değişiklikleri tek anda birleştirilmemelidir. Google, yeni konumda aynı site mimarisinin korunmasının sinyallerin daha doğrudan aktarılmasına yardımcı olduğunu; taşımanın kapsamlı redesign ve URL değişikliğiyle birleştirilmesinin sayfaların yeniden değerlendirilmesine ve trafik kaybına yol açabileceğini belirtir Search Console Change of Address.

İş gereği bütün değişiklikler aynı release’te yapılacaksa baseline ve URL mapping daha da önem kazanır. Hangi kaybın redirect, içerik, render veya bilgi mimarisi değişiminden kaynaklandığını ayıracak testler hazırlanmalıdır. Profesyonel bir web sitesi yenileme projesinde SEO kabul kriterleri tasarım kabul kriterleriyle aynı release planında yer almalıdır.

Staging ortamı nasıl test edilmelidir?

Yeni sistem yayınlanmadan önce staging veya geçici hostname üzerinde tam işlev testi yapılmalıdır. Google’ın hosting taşıma rehberi; sayfa, görsel, form ve dosyaların test edilmesini, geçici ortamın yanlışlıkla indekslenmemesi için noindex kullanılmasını ve Googlebot erişiminin Search Console ile kontrol edilmesini önerir Google Hosting Değiştirme Rehberi.

• Staging ortamını şifre veya IP kısıtıyla koruyun; gerekiyorsa noindex ekleyin.
• Production’a geçerken staging noindex kuralının taşınmadığını doğrulayın.
• Eski ve yeni crawl sonuçlarını URL bazında karşılaştırın.
• Title, H1, canonical, robots, structured data ve içerik kayıplarını raporlayın.
• Mobil render, JavaScript, formlar, arama ve filtreleri test edin.
• 404 template’inin gerçek 404 döndürdüğünü kontrol edin.
• Redirect mapping’i production benzeri kurallarla prova edin.

Hosting değişiminde DNS ve erişim nasıl planlanmalıdır?

URL değişmeden yalnız hosting taşınıyorsa redirect gerekmez. Yeni altyapı önceden hazırlanmalı, DNS geçişi izlenmeli ve eski sunucu trafik tamamen yeni sisteme geçene kadar kapatılmamalıdır. Google, DNS kayıtlarının TTL değerini taşıma öncesinde düşürmenin yeni ayarların daha hızlı yayılmasına yardımcı olabileceğini belirtir Google Hosting Değiştirme Rehberi.

Firewall, CDN veya bot koruma kurallarının Googlebot’u engellemediği doğrulanmalıdır. Yeni hosting daha güçlü olsa bile yanlış WAF kuralı veya origin yapılandırması tarama sorununa neden olabilir.

Migration yayın günü kontrol sırası nasıl olmalıdır?

1. İçerik ve veritabanı son senkronizasyonunu tamamlayın.
2. Yeni sistemi erişime açın ve temel sayfa kontrollerini çalıştırın.
3. Robots.txt ve meta robots kurallarını doğrulayın.
4. Redirect mapping’i devreye alın.
5. Eski URL örneklerini ve yüksek trafik sayfalarını test edin.
6. Canonical, hreflang, sitemap ve iç linkleri kontrol edin.
7. Yeni sitemap’i Search Console’a gönderin.
8. Domain değişiminde şartlar sağlandıktan sonra Change of Address kullanın.
9. Analitik, dönüşüm ve hata izleme sistemlerinin veri aldığını doğrulayın.
10. Rollback kararı için ilk teknik metrikleri izlemeye başlayın.

Yayın sonrası hangi metrikler izlenmelidir?

Search Console ve analitik verisinin birlikte izlenmesi, arama sonucundaki görünürlük ile site içindeki kullanıcı davranışını ayırmaya yardımcı olur Google Search Console ve Analytics Rehberi. Bu takip teknik SEO danışmanlığı sürecinde URL grubu ve sayfa şablonu seviyesine indirilmelidir.

Trafik düşüşünde önce ne kontrol edilmelidir?

Migration sonrasında kısa süreli dalgalanma olabilir; fakat ciddi kaybı yalnız “Google’ın alışması gerekiyor” diyerek beklemek doğru değildir. Önce teknik kırılma aranmalıdır.

• Önemli eski URL’ler doğru hedefe yönleniyor mu?
• Yeni sayfalarda yanlış noindex veya robots engeli var mı?
• Canonical eski domaini veya staging adresini gösteriyor mu?
• Yeni içerik eski sayfaya göre eksilmiş mi?
• Internal link yapısı önemli sayfaları yetim bırakmış mı?
• Googlebot 5xx, timeout veya WAF engeli alıyor mu?
• Hreflang ve structured data taşıma sırasında bozulmuş mu?
• Analytics kodu çalışmadığı için yalnız ölçüm kaybı mı var?

Bu kontrolün URL bazlı görevler halinde yürütülmesi, SEO denetimi ve aksiyon planı içinde “bekle” yaklaşımının yerine kanıta dayalı müdahale sağlar.

Rollback planı nasıl hazırlanmalıdır?

Rollback, organik trafik bir gün düştüğünde panikle eski siteyi geri açmak değildir. Önceden tanımlı teknik eşik ve karar sahiplerine bağlı bir geri dönüş planıdır. Veritabanı şeması, içerik senkronizasyonu, DNS, redirect ve yeni URL’lerde oluşan kullanıcı verileri dikkate alınmalıdır.

1. Eski uygulama ve veritabanı yedeğinin ne kadar süre sıcak tutulacağını belirleyin.
2. DNS veya load balancer geri dönüş adımlarını belgeleyin.
3. Hangi 5xx, checkout veya kritik fonksiyon hatasının acil rollback gerektirdiğini yazın.
4. Yalnız SEO dalgalanmasıyla teknik sistem arızasını ayırın.
5. Yeni sistemde oluşan sipariş, form ve kullanıcı verisinin geri dönüşte kaybolmamasını planlayın.
6. Rollback halinde redirect ve canonical davranışının ne olacağını test edin.
7. Karar yetkisini ve iletişim kanalını yayın öncesinde belirleyin.

Domain değişiminde Search Console Change of Address işlemini geri çevirmek ayrıca yönlendirme kurallarının tersine alınmasını ve araçta taşımanın iptal edilmesini gerektirir. Bu nedenle rollback yalnız SEO ekibinin tek başına vereceği bir karar değildir.

En sık yapılan site taşıma SEO hataları

1. URL mapping hazırlamadan yalnız genel redirect kuralı yazmak.
2. Bütün eski URL’leri ana sayfaya yönlendirmek.
3. Redirect zinciri ve döngülerini test etmemek.
4. Yeni sayfalarda eski domain canonical’ını bırakmak.
5. Staging noindex kuralını production’a taşımak.
6. İç link, hreflang ve structured data URL’lerini güncellememek.
7. Sitemap’e redirect veya noindex URL’leri eklemek.
8. Domain, CMS, tasarım ve içerik değişimini ölçüm planı olmadan birleştirmek.
9. Search Console yeni property ve Change of Address hazırlığını unutmak.
10. Yayın sonrası yalnız toplam trafiği izleyip URL gruplarını incelememek.

Site taşıma SEO kontrol listesi

1. Eski sitenin tam URL ve performans envanteri çıkarıldı mı?
2. Her eski URL için yeni hedef veya kaldırma kararı var mı?
3. Yönlendirmeler tek adımda ve sunucu tarafında çalışıyor mu?
4. Yeni sayfalar 200, indexable ve self-canonical mı?
5. İç linkler doğrudan yeni canonical URL’lere gidiyor mu?
6. Robots, hreflang, structured data ve sitemap güncellendi mi?
7. Eski ve yeni Search Console property’leri doğrulandı mı?
8. Domain değişiminde Change of Address şartları karşılandı mı?
9. Yayın sonrası URL, trafik, crawl, dönüşüm ve hata dashboard’u hazır mı?
10. Teknik rollback adımları ve karar eşikleri belgelendi mi?

Sonuç: Başarılı migration birebir sinyal aktarımıdır

Site taşıma SEO’sunda en kritik iş, eski URL’lerin yeni sitedeki gerçek karşılıklarını bulmak ve bütün teknik sinyalleri bu eşleşmeyle uyumlu hale getirmektir. Redirect, canonical, iç link, sitemap ve Search Console farklı hedefleri gösteriyorsa Google’ın geçişi anlaması zorlaşır.

Taşıma öncesi envanter ve staging testi, yayın sırasında otomatik URL kontrolleri, sonrasında ise Search Console, analitik ve sunucu sağlığı izleme birlikte yürütülmelidir. Domain veya altyapı değişimi tek gecelik işlem gibi değil, tamamlanması haftalar sürebilen kontrollü bir geçiş dönemi olarak yönetilmelidir.