Site Taşıma SEO: Organik Görünürlüğü Kontrollü Biçimde Yeni Yapıya Aktarın

Web sitesi taşıması yalnız dosyaları yeni sunucuya veya ürünleri yeni e-ticaret altyapısına aktarmak değildir.

Domain, URL yapısı, CMS, kategori mimarisi veya tasarım değiştiğinde arama motorlarının tanıdığı URL’ler, dahili bağlantılar, canonical sinyalleri, sitemap yapısı ve kullanıcı yolları da değişebilir.

DigitalPlus Site Taşıma SEO hizmetinde geçişi yalnız 301 yönlendirme listesi olarak yönetmiyoruz.

Taşınmadan önce mevcut SEO değerini envantere alıyor, eski ve yeni URL’leri eşleştiriyor, staging ortamını test ediyor, launch gününü kontrol ediyor ve geçiş sonrasında indeks, trafik ve ticari performansın yeni yapıya nasıl aktarıldığını izliyoruz.

Amaç sıralama garantisi vermek değil. Migration sırasında önlenebilir SEO kayıplarını azaltmak ve değerli URL’lerin yeni yapıya doğru biçimde aktarılmasını sağlamak.

Site Taşıma Projenizi İnceleyelim

Site Taşıma SEO Nedir?

Site Taşıma SEO, web sitesindeki büyük teknik veya yapısal değişikliklerin organik arama görünürlüğü üzerindeki risklerini yönetme sürecidir.

Migration kapsamına örneğin:

• Domain değişikliği
• HTTP → HTTPS geçişi
• CMS değişikliği
• E-ticaret altyapısı değişikliği
• URL yapısının değişmesi
• Kategori mimarisinin yeniden kurulması
• İki veya daha fazla domainin birleştirilmesi
• Subdomain değişimi
• Yeniden tasarım
• Büyük içerik konsolidasyonu

girebilir.

Her migration aynı değildir.

Hosting değişiyor ancak kullanıcıya görünen URL yapısı aynı kalıyorsa ihtiyaç farklıdır. Domain ve bütün URL mimarisi değişiyorsa çok daha kapsamlı bir SEO migration planı gerekir.

Bu nedenle işe yalnız “kaç URL var?” sorusuyla değil, “hangi teknik ve organik sinyaller değişiyor?” sorusuyla başlıyoruz.

Site Taşıması Neden SEO Riski Oluşturur?

Mevcut URL’ler zaman içinde indekslenmiş, sorgularda görünürlük kazanmış, backlink almış, internal linklerle desteklenmiş veya dönüşüm üreten landing page’lere dönüşmüş olabilir.

Yeni yapı yayına girdiğinde eski ve yeni URL’ler arasındaki ilişkinin yeniden işlenmesi gerekir.

Migration sırasında örneğin:

• Eski URL’nin yeni sistemde gerçek karşılığının bulunmaması
• Yanlış hedefe redirect verilmesi
• Redirect chain oluşması
• Staging noindex kuralının canlıda kalması
• robots.txt bloklarının unutulması
• Canonical’ların eski URL’leri göstermesi
• Internal linklerin eski adreslerde kalması
• XML sitemap’in güncellenmemesi
• Ölçüm kodlarının taşınmaması
• Önemli içeriğin yeni template’te kaybolması

organik görünürlük veya ölçüm tarafında sorun yaratabilir.

Bu yüzden SEO migration yayın gecesi yapılan son kontrol değil, geliştirme ve geçiş planının bir parçası olmalıdır.

Site Taşımasına Ne Zaman SEO Ekibi Dahil Olmalı?

Yeni site yayına alınmadan önce.

İdeal durumda SEO migration çalışması yeni site mimarisi ve URL kararları kesinleşmeden başlar.

SEO ekibi ancak site yayına çıktıktan sonra sürece dahil olursa bazı önemli kararlar çoktan kod, tasarım veya içerik mimarisine gömülmüş olabilir.

Erken dahil olduğumuzda:

• Hangi URL’lerin korunacağını
• Hangi içeriklerin birleştirileceğini
• Hangi URL’lerin değişeceğini
• Hangi kategorilerin yeni mimariye taşınacağını
• Redirect kurallarının nasıl oluşturulacağını
• Staging ortamında hangi davranışların test edileceğini

yayından önce belirleyebiliriz.

En ucuz migration problemi, canlıya çıkmadan bulunan problemdir.

Migration Öncesinde Mevcut Değeri Haritalıyoruz

Taşımaya başlamadan önce mevcut sitenin SEO açısından referans görüntüsünü çıkarıyoruz.

Yalnız crawler verisine güvenmiyoruz.

Projeye göre şu kaynakları birleştirebiliriz:

• Mevcut site crawl’u
• XML sitemap
• Google Search Console landing page verileri
• Analitik landing page verileri
• Backlink alan URL’ler
• CMS URL listesi
• Gerekli projelerde sunucu logları
• İndekslenen URL örnekleri

Amaç mümkün olduğunca uzun bir URL listesi oluşturmak değildir. Amaç taşıma sırasında gözden kaçırılmaması gereken URL’leri bulmaktır.

URL’leri Değerine Göre Sınıflandırıyoruz

Her URL aynı önemde değildir.

Değerlendirmede projeye göre:

• Organik trafik
• Gösterim
• Sorgu görünürlüğü
• Backlink
• Dönüşüm
• Gelir
• Sayfanın site mimarisindeki görevi
• Ticari intent
• İçerik değeri

kullanılabilir.

Böylece yalnız yüksek trafik alan URL’leri değil, yeni yapıda ticari veya mimari görev taşıması gereken sayfaları da koruma planına dahil ediyoruz.

Her Eski URL İçin Aynı Kararı Vermiyoruz

Migration planındaki kritik işlerden biri her eski URL’nin yeni sistemde ne olacağına karar vermektir.

Koru

URL ve içerik görevini değiştirmek için gerçek bir sebep yoksa mevcut URL korunabilir.

Gereksiz URL değişikliği gereksiz redirect ve yeniden işleme ihtiyacı yaratır.

301 ile Taşı

Eski içeriğin yeni sistemde aynı veya çok yakın kullanıcı ihtiyacını karşılayan açık bir karşılığı bulunuyorsa kalıcı yönlendirme kullanılabilir.

Birleştir

Birden fazla eski sayfa yeni sistemde gerçekten aynı arama niyetini karşılayan tek bir güçlü sayfada birleşiyorsa ilgili eski URL’ler bu yeni hedefe taşınabilir.

404 veya 410

Eski içeriğin yeni sistemde gerçek bir karşılığı yoksa her URL’yi zorla başka bir sayfaya yönlendirmiyoruz.

Gerçek alternatifi bulunmayan kaldırılmış içerik için uygun 404 veya 410 davranışı değerlendirilebilir.

Her 404 SEO hatası değildir.

Bu karar yapısını ve uygulama dosyasının nasıl hazırlanması gerektiğini 301 yönlendirme haritası nasıl hazırlanır? rehberinde ayrıntılı olarak ele alıyoruz.

Bütün Eski URL’leri Ana Sayfaya Yönlendirmiyoruz

Eski URL ile yeni hedef arasında gerçek bir kullanıcı ve içerik ilişkisi bulunmalıdır.

Örneğin:

/erkek-kosu-ayakkabilari

sayfasındaki ürün grubu yeni yapıda:

/erkek/spor-ayakkabi/kosu

altına taşındıysa doğrudan ilgili kategoriye yönlendirme anlamlıdır.

Ancak artık bulunmayan yüzlerce kategori veya ürünün tamamını ana sayfaya göndermek doğru eşleştirme değildir.

Redirect haritasının amacı bütün eski URL’lerin teknik olarak 301 dönmesini sağlamak değil, eski URL ile yeni hedef arasında doğru ilişkiyi kurmaktır.

Redirect Haritasını Nasıl Hazırlıyoruz?

Eski ve yeni URL envanterlerini karşılaştırıyoruz.

Her satırda ihtiyaca göre şu alanlar bulunabilir:

• Eski URL
• Yeni URL
• Eski HTTP durumu
• Yeni hedefin durumu
• Sayfa tipi
• Organik trafik
• Backlink
• Intent
• Migration kararı
• Redirect tipi
• Öncelik
• Test durumu
• Not

Kural Bazlı Redirect

URL yapısında tutarlı dönüşüm varsa geliştirici seviyesinde pattern kullanılabilir.

Örneğin:

/urunler/kategori/slug

yapısının:

/kategori/slug

modeline dönüşmesi gibi.

URL Bazlı Redirect

Eski ve yeni mimari birebir eşleşmiyorsa manuel karar gerekir.

Özellikle yüksek değerli kategori, hizmet, ürün ve içerik URL’lerini yalnız otomatik string eşleştirmeye bırakmıyoruz.

Redirect Chain Oluşturmamaya Çalışıyoruz

Eski URL’nin mümkün olduğunca doğrudan nihai hedefe gitmesini istiyoruz.

Şunun yerine:

Eski URL → Ara URL → Eski kategori → Yeni kategori

şunu hedefliyoruz:

Eski URL → Nihai yeni URL

Migration öncesinde redirect haritasını oluşturmanın avantajlarından biri de eski redirect kurallarını yeni kuralların üzerine körlemesine yığmak yerine zincirleri önceden temizleyebilmektir.

Yeni Siteyi Staging Ortamında SEO Açısından Test Ediyoruz

Yeni sitenin tasarım olarak düzgün görünmesi migration için yeterli değildir.

Staging aşamasında projeye göre şu alanları kontrol ediyoruz:

• URL yapısı
• HTTP durumları
• Canonical
• Robots direktifleri
• robots.txt
• Metadata
• Heading yapısı
• Internal linking
• Breadcrumb
• Pagination
• Hreflang
• Structured data
• XML sitemap mantığı
• JavaScript rendering
• Mobil davranış
• Analytics ve conversion tracking

Ayrıca eski site crawl’u ile staging crawl’unu karşılaştırarak migration sırasında beklenmeden kaybolan sayfa veya şablon öğelerini tespit etmeye çalışıyoruz.

Staging Noindex Kuralı Canlıya Taşınmamalı

Staging ortamının arama sonuçlarına girmesini engellemek için erişim kısıtları veya noindex kullanılabilir.

Problem, geliştirme ortamı için kullanılan bu kuralların launch sırasında canlı sisteme taşınmasıdır.

Bu nedenle geçiş checklist’inde özellikle:

• robots.txt
• Meta robots
• X-Robots-Tag
• Canonical
• Erişim kontrolleri

yeniden doğrulanır.

“Site açılıyor” kontrolü tek başına yeterli değildir. Önemli URL’lerin crawler tarafından da erişilebilir ve doğru şekilde işlenebilir olması gerekir.

Internal Linkler Yeni URL’lere Güncellenmeli

301 redirect kurmak eski URL’leri site içindeki bütün bağlantılarda bırakmak için gerekçe değildir.

Yeni site içindeki:

• Menü
• Breadcrumb
• Kategori linkleri
• Footer
• İçerik linkleri
• Related content alanları
• Ürün bağlantıları

mümkün olduğunca doğrudan yeni canonical URL’lere gitmelidir.

Aynı kontrol canonical, hreflang ve XML sitemap için de yapılır.

Yeni sistem kendi içinde eski URL’leri referans göstermeye devam etmemelidir.

Site Taşıma Günü Nasıl Yönetiliyor?

Migration günü yalnız geliştiricinin deployment yaptığı saat değildir.

SEO ve ticari sistem açısından kritik doğrulamaların hızlı biçimde yapılması gerekir.

Erişim

• Ana sayfa açılıyor mu?
• Kritik kategori, hizmet ve ürün sayfaları 200 dönüyor mu?
• 5xx veya başka sunucu hataları var mı?

Yönlendirmeler

• Eski kritik URL’ler doğru hedefe gidiyor mu?
• Redirect loop var mı?
• Redirect chain oluşmuş mu?
• Kaldırılması gereken URL’ler doğru davranıyor mu?

Indexation

• Yanlışlıkla noindex kaldı mı?
• robots.txt doğru mu?
• Canonical yeni URL’leri gösteriyor mu?

Site Mimarisi

• Internal linkler yeni URL’lere gidiyor mu?
• Navigasyon çalışıyor mu?
• Kritik orphan page oluşmuş mu?

Sitemap

• Yeni XML sitemap doğru canonical URL’leri içeriyor mu?
• Eski URL’ler yanlışlıkla yeni sitemap’te kalmış mı?

Ölçüm

• GA4 çalışıyor mu?
• GTM yükleniyor mu?
• Form dönüşümleri geliyor mu?
• Telefon ve WhatsApp event’leri çalışıyor mu?
• E-ticaret event’leri korunmuş mu?

SEO migration yalnız Search Console projesi değildir.

Web sitesi teknik olarak çalışıyor ancak ölçüm sistemi bozulduysa migration’ın gerçek iş etkisini doğru değerlendiremeyiz.

Domain Değişikliğinde Ek Kontroller Yapıyoruz

Domain değişikliği, aynı domain altında gerçekleştirilen URL veya CMS değişikliğinden farklıdır.

Eski ve yeni domain:

• Search Console
• Yönlendirmeler
• Canonical
• Sitemap
• Backlink kaynakları
• Profil ve marka bağlantıları

açısından ayrıca yönetilir.

Uygun domain migration projelerinde Search Console Change of Address işlemi de geçiş planına dahil edilir.

Ancak Change of Address, 301 veya 308 gibi permanent redirectlerin yerine geçmez. Önce teknik migration yapısının doğru kurulması gerekir.

Eski Domaini Migration Sonrası Hemen Kapatmıyoruz

Redirect sisteminin çalışabilmesi için eski domainin ve yönlendirme altyapısının kullanılabilir kalması gerekir.

Permanent migration redirectlerini birkaç hafta sonra kaldırmıyoruz.

Ayrıca yüksek değerli dış bağlantıların mümkün olduğu durumlarda doğrudan yeni URL’lere güncellenmesini değerlendirebiliriz.

Redirect kullanıcıyı ve crawler’ı yeni hedefe taşır; ancak kendi internal linklerimizin ve kontrol edebildiğimiz önemli dış bağlantıların doğrudan yeni URL’ye gitmesi daha temiz bir yapı oluşturur.

Site Taşıma Yayına Çıkınca Bitmez

Migration sürecindeki en tehlikeli cümlelerden biri “Site açıldı, iş tamam.” olabilir.

Bazı problemler launch anında görünmez. Eski ve yeni URL’lerin yeniden taranması, indeks durumlarının değişmesi ve performans verilerinin yeni yapıya taşınması zaman içinde gerçekleşir.

Bu nedenle geçiş sonrası:

• Eski URL’lerin yönlendirme davranışı
• Yeni URL indexation
• 404 ve 5xx artışı
• Canonical seçimi
• Sitemap durumu
• Önemli sorgular
• Landing page tıklamaları
• Organik dönüşümler
• E-ticarette sipariş ve gelir

izlenir.

Yayın sonrasındaki kontrol sırasını site taşıma sonrası ilk 30 gün kontrol listesinde daha ayrıntılı ele alıyoruz.

İlk Günlerde Neyi Önceliklendiriyoruz?

Migration sonrasında bütün metriklere aynı ağırlığı vermiyoruz.

İlk aşamada teknik doğrulamalar daha acildir:

• Kritik URL açılıyor mu?
• Redirect doğru mu?
• Noindex problemi var mı?
• Canonical doğru mu?
• Search Console erişimi çalışıyor mu?
• Ölçüm sistemi veri topluyor mu?

Bunlar doğrulandıktan sonra performans değişimleri daha anlamlı şekilde değerlendirilebilir.

Tek günlük sıralama hareketine bakıp redirect ve URL mimarisini tekrar değiştirmiyoruz.

Migration Sonrası Performansı URL Gruplarıyla İnceliyoruz

Yalnız site geneline bakmak problemi gizleyebilir.

Örneğin toplam organik trafik sınırlı değişmiş olsa bile kategori, ürün veya hizmet sayfalarında çok daha büyük kayıplar bulunabilir.

Bu nedenle URL’leri:

• Kategori
• Ürün
• Hizmet
• İçerik
• Lokasyon

gibi anlamlı gruplara ayırarak değerlendiriyoruz.

Böylece problemin bütün sitede mi yoksa belirli template veya site bölümlerinde mi oluştuğunu daha hızlı görebiliriz.

Site Taşıma Sonrası Trafik Düşerse Nasıl Teşhis Ediyoruz?

Önce düşüşün gerçekten migration kaynaklı olup olmadığını belirlemeye çalışıyoruz.

1. Ölçüm

GA4, GTM veya conversion tracking bozuldu mu?

2. Sunucu

5xx, gecikme veya erişim problemi var mı?

3. Redirect

Eski URL’ler doğru hedefe gidiyor mu?

4. Indexability

robots.txt, noindex veya canonical problemi var mı?

5. İçerik

Taşıma sırasında sayfa içeriği, metadata veya önemli öğeler kayboldu mu?

6. Internal Linking

Yeni yapı kritik URL’leri yeterince destekliyor mu?

7. Arama Talebi

Talep veya mevsimsellik aynı dönemde değişti mi?

8. URL Grupları

Kayıp bütün sitede mi, yoksa yalnız belirli sayfa tiplerinde mi?

Böylece “migration oldu, biraz düşüş normal” diyerek gerçek teknik problemi haftalarca bekletmiyoruz.

Migration Süresi Neden Her Site İçin Aynı Değildir?

Site taşıması arama motoru tarafında tek bir anda tamamlanan işlem değildir.

Geçişin işlenme süresini:

• URL sayısı
• Site büyüklüğü
• Sunucu kapasitesi
• Crawl sıklığı
• Redirect yapısı
• Internal linking
• Değişikliğin kapsamı

gibi faktörler etkileyebilir.

Bu yüzden bütün projeler için “30 günde biter” veya “6 haftada eski performansa döner” gibi süre garantileri vermiyoruz.

İlk 30 günü yoğun monitoring penceresi olarak kullanabiliriz ancak büyük veya karmaşık migration projelerinde takip daha uzun devam edebilir.

Domain, CMS ve Tasarımı Aynı Anda Değiştirmek Mantıklı mı?

Mümkün olabilir ancak aynı anda değişen değişken sayısını artırır.

Örneğin aynı deployment içinde:

• Domain
• URL yapısı
• CMS
• Tasarım
• İçerik
• Kategori mimarisi

değişirse performans problemi ortaya çıktığında kök nedeni izole etmek zorlaşabilir.

Teknik ve operasyonel olarak mümkünse büyük değişikliklerin kontrollü aşamalara bölünmesini değerlendiriyoruz.

Her proje buna izin vermediği için migration planını yazılım ve ticari takvimle birlikte oluşturuyoruz.

E-Ticaret Site Taşıması Neden Daha Karmaşıktır?

E-ticaret migration projelerinde yalnız içerik URL’leri bulunmaz.

Aynı anda:

• Kategoriler
• Alt kategoriler
• Ürünler
• Markalar
• Filtreler
• Pagination
• Ürün varyantları
• Stokta olmayan ürünler
• Ürün feed’leri
• Structured data
• Tracking
• Checkout yolları

değişebilir.

Bu nedenle e-ticaret platformu migration’ında SEO ve ticari QA birlikte yürütülmelidir.

Ürün sayfası açılıyor ancak sepete ekleme event’i çalışmıyorsa geçiş ticari açıdan tamamlanmış değildir. Kategori URL’si 200 dönüyor ancak canonical eski altyapıyı gösteriyorsa SEO açısından da tamamlanmış değildir.

E-ticaret yapısında kategori, ürün ve facet mimarisi de yeniden kuruluyorsa e-ticaret SEO kapsamını migration planıyla birlikte değerlendirmek gerekir.

Site Taşıma SEO Sürecimiz

1. Migration Scope

Neyin değiştiğini belirliyoruz:

• Domain mi?
• CMS mi?
• URL yapısı mı?
• Tasarım mı?
• Site mimarisi mi?
• İçerik mi?

2. Baseline

Taşıma öncesi teknik ve organik referans verilerini kaydediyoruz.

3. URL Inventory

Mevcut URL’leri crawl, sitemap, Search Console, analitik, backlink ve diğer uygun veri kaynaklarından birleştiriyoruz.

4. URL Decision Matrix

Her önemli URL için koru / 301 / birleştir / 404 / 410 kararını veriyoruz.

5. Redirect Mapping

Eski ve yeni URL ilişkisini geliştirici ekibin uygulayabileceği haritaya dönüştürüyoruz.

6. Staging QA

Yeni sistemi canlıya alınmadan önce SEO açısından test ediyoruz.

7. Launch Plan

Geçiş günü görevlerini, sorumluları ve kritik kontrol listesini önceden belirliyoruz.

8. Live QA

Yeni siteyi ve redirect davranışını canlı ortamda tekrar test ediyoruz.

9. Monitoring

Eski ve yeni URL’lerin crawling, indexation, trafik, sorgu ve dönüşüm davranışını izliyoruz.

10. Stabilizasyon

Tespit edilen kritik problemleri geliştirici görevlerine çeviriyor ve geçiş verileri yeterince anlaşılır hale gelene kadar kontrolü sürdürüyoruz.

Migration Sırasında Kim Ne Yapar?

Site taşıması yalnız SEO ekibinin yürüttüğü bir proje değildir.

DigitalPlus

Projeye göre:

• SEO envanteri
• URL değerleme
• Redirect mapping
• Staging QA
• Launch checklist
• Developer brief
• Canlı QA
• Search Console kontrolleri
• Monitoring
• Problem teşhisi

yürütür.

Yazılım Ekibi

Redirect implementasyonu, template değişiklikleri, robots ve canonical uygulamaları, altyapı düzenlemeleri ve deployment gibi kod seviyesindeki işleri uygular.

Tasarım veya Web Ajansı

Yeni sayfa yapılarının ve template’lerin migration gereksinimleriyle uyumlu geliştirilmesini sağlar.

Müşteri Ekibi

Ticari öncelikler, ürün veya hizmet değişiklikleri, kaldırılacak içerikler, gerekli erişimler ve launch takvimi hakkında bilgi sağlar.

Migration’ın sağlıklı ilerlemesi için sorumlulukları yayından önce netleştiriyoruz.

Site Taşıma SEO Hizmetinde Ne Teslim Alırsınız?

Projenin kapsamına göre:

• Mevcut URL envanteri
• SEO baseline
• URL değerleme tablosu
• Eski-yeni URL mapping
• Koru / 301 / merge / 404 / 410 karar tablosu
• Redirect implementasyon dosyası
• Staging SEO QA raporu
• Launch checklist
• Developer task listesi
• Yeni XML sitemap kontrolü
• Internal link kontrolü
• Search Console migration planı
• Live crawl karşılaştırması
• İlk dönem monitoring raporu
• P0/P1 hata listesi
• Migration sonrası performans analizi

teslim edilebilir.

Amacımız PDF sayısını artırmak değildir. Migration ekibinin hangi URL’nin ne olacağını ve geliştiricinin ne uygulaması gerektiğini açık biçimde görebilmesidir.

Site Taşıma SEO Hangi Projelerde Gereklidir?

Özellikle:

• Domain değiştiren markalar
• Marka birleşmesi yapan şirketler
• Yeni CMS’e geçen siteler
• Shopify, WooCommerce veya özel altyapı değişikliği yapan mağazalar
• URL mimarisini değiştiren siteler
• Web sitesini tamamen yenileyen şirketler
• Kategori mimarisini değiştiren e-ticaret siteleri
• Birden fazla domaini birleştiren şirketler
• Daha önce migration sonrası organik trafik kaybeden siteler

için değerlendirilmelidir.

Yalnız sunucunun değiştiği ve kullanıcıya görünen URL yapısının aynı kaldığı projelerde ihtiyaç daha farklı ve daha dar kapsamlı olabilir.

Site Taşıma SEO Fiyatını Ne Belirler?

Migration kapsamını özellikle:

• Toplam URL hacmi
• Organik trafik alan URL sayısı
• Site türü
• Kategori ve ürün miktarı
• Domain değişimi
• URL mimarisi değişimi
• CMS değişimi
• Backlink profili
• Hreflang yapısı
• Redirect karmaşıklığı
• Staging erişimi
• Geliştirici koordinasyonu
• Launch takvimi
• Monitoring ihtiyacı

etkiler.

Daha düşük URL sayısına sahip ancak yoğun manuel eşleştirme gerektiren bir migration, URL hacmi yüksek fakat tamamen kural bazlı dönüşebilen bir projeden daha fazla operasyon gerektirebilir.

Bu nedenle kapsamı yalnız URL adedine bakarak belirlemiyoruz.

Sıkça Sorulan Sorular

Site taşımasında trafik kaybı normal mi?

Geçici sıralama ve görünürlük dalgalanmaları görülebilir.

Ancak bu, büyük kayıpların otomatik olarak “normal migration etkisi” kabul edilmesi gerektiği anlamına gelmez.

Özellikle yanlış redirect, noindex, robots blokları, canonical problemleri, eksik içerik, sunucu hataları ve tracking sorunları önce kontrol edilmelidir.

Bütün URL’leri 301 yapmak gerekir mi?

Hayır.

Yeni sitede gerçek karşılığı bulunan URL’ler uygun yeni hedeflere yönlendirilir. Artık gerçek karşılığı bulunmayan içeriklerin 404 veya 410 dönmesi daha doğru olabilir.

301 yönlendirmeleri ne kadar süre kalmalı?

Permanent migration redirectleri kısa süre sonra kaldırılmamalıdır.

Google genel olarak yönlendirmelerin en az bir yıl korunmasını önerir. Kullanıcılar ve dış siteler eski URL’leri daha uzun süre kullanabileceği için teknik olarak mümkün olduğunda daha uzun süre tutulmaları değerlendirilebilir.

Domain değiştirirken Change of Address kullanılmalı mı?

Uygun domain migration projelerinde evet.

Ancak Change of Address; redirect mapping, canonical, sitemap veya diğer migration gereksinimlerinin yerine geçmez.

HTTP’den HTTPS’ye geçişte ise Change of Address kullanılmaz.

Site taşımasından sonra her URL için index request göndermek gerekir mi?

Hayır.

Büyük migration projelerinde her URL’yi manuel olarak göndermek ölçeklenebilir bir yöntem değildir.

Doğru redirect, internal linking, XML sitemap ve erişilebilir site mimarisi önceliklidir. URL Inspection kritik örnekleri kontrol etmek için kullanılabilir.

Tasarım veya yazılım ajansımız ayrıysa birlikte çalışabilir misiniz?

Evet.

Site migration çoğu zaman çok ekipli bir projedir.

DigitalPlus SEO gereksinimlerini, redirect planını ve acceptance criteria’yı oluşturabilir; mevcut yazılım veya tasarım ekibiniz uygulamayı gerçekleştirebilir. Canlıya alınan değişiklikleri sonrasında SEO açısından tekrar doğrularız.

Taşınma sonrası geldik, çok geç mi?

İdeal zaman migration öncesidir ancak geçiş zaten gerçekleştirildiyse recovery çalışması yapılabilir.

Bu durumda eski URL’ler, redirectler, indexation, Search Console verileri, içerik kayıpları ve trafik değişimi üzerinden hangi sinyalin veya sayfa grubunun kayıp yaşadığını araştırıyoruz.

Problem migration sonrasında farklı teknik alanlara yayılmışsa daha geniş bir SEO Audit veya uygulama odaklı Teknik SEO çalışması gerekebilir.

Migration Planını Yayından Önce Kilitleyelim

Site taşımasındaki kritik SEO işi yayın gecesi yüzlerce 301 eklemek değildir.

Asıl iş daha önce başlar:

• Neyi koruyoruz?
• Neyi değiştiriyoruz?
• Hangi eski URL hangi yeni URL’ye ait?
• Hangi içerik kaldırılıyor?
• Yeni sistem staging’de doğru çalışıyor mu?
• Geçiş sonrası başarıyı hangi veriyle doğrulayacağız?

DigitalPlus Site Taşıma SEO hizmeti ile mevcut organik yapınızı envantere alıp eski ve yeni site arasındaki geçişi URL seviyesinde planlıyor; uygulamayı test ediyor ve yayından sonra sonuçları takip ediyoruz.

Site Taşıma Projenizi İnceleyelim