SEO Migration Nedir? Site Taşırken Sıralama Kaybını Önleme Kontrol Listesi

Bir siteyi yeni bir adrese, yeni bir platforma ya da yeni bir sunucuya taşımak, SEO açısından en riskli işlerden biridir. Bu yazıda SEO migration kavramını taşıma türlerine göre ayırıyor ve her tür için ayrı bir kontrol listesi veriyorum. 2012'den beri sahada gördüğüm hataları da dürüstçe paylaşıyorum.

SEO migration nedir?

SEO migration, bir web sitesinin alan adını, protokolünü, platformunu, URL yapısını veya sunucusunu değiştirirken arama motorlarındaki görünürlüğü korumak için yapılan planlı taşıma sürecidir. Amaç, eski adreslerin biriktirdiği sinyalleri yeni adreslere eksiksiz aktarmak ve geçiş döneminde trafik kaybını en aza indirmektir.

Kısacası mesele yalnızca dosyaları bir yerden başka bir yere kopyalamak değil. Google, eski URL'lerinizi yıllardır tanıyor; bağlantılar, tıklamalar ve dizin kayıtları bu adreslere bağlı. Taşıma sırasında bu hafızayı yeni adreslere nasıl devredeceğinizi siz belirlersiniz. Planı iyi kurarsanız dalgalanma kısa sürer, plansız giderseniz aylarca süren bir kayıp yaşayabilirsiniz.

Google'ın kendi dokümantasyonu da bu riski açıkça kabul ediyor: URL değişikliği içeren site taşıma rehberinde büyük bir değişiklikten sonra Google siteyi yeniden tarayıp dizine eklerken sıralama dalgalanmaları yaşayabileceğinizi belirtiyor. Yani hedef sıfır dalgalanma değil; hedef, dalgalanmayı kısa ve kontrollü tutmak.

Bu yazıyı bir kontrol listesi olarak kullanmanızı öneririm. Önce hangi taşıma türüyle karşı karşıya olduğunuzu belirleyin, ardından ortak hazırlık adımlarını ve kendi türünüze özel bölümü uygulayın. Birden fazla tür aynı projede birleşiyorsa, ilgili bölümlerin hepsini tek bir takvimde toplayın.

SEO migration ile tasarım yenileme arasındaki fark nedir?

Tasarım yenilemede genellikle aynı alan adında kalırsınız; değişen şey görünüm, şablon ve bazen içerik düzenidir. Bu konuyu web sitesi yenilerken SEO nasıl korunur yazısında ayrıntılı anlattım. SEO migration ise daha geniş bir şemsiye: adresin kendisi, altyapı ya da sunucu değişiyor.

Pratikte ikisi sık sık iç içe geçer. Örneğin bir e-ticaret sitesi hem tasarımı yeniler hem de platform değiştirir; bu durumda iki kontrol listesini birlikte uygulamanız gerekir. Ayrım önemli, çünkü risk kaynakları farklı:

• Tasarım yenilemede risk çoğunlukla içerik kaybı, başlık yapısının bozulması ve iç linklerin kopmasıdır.
• Taşımada risk ise yönlendirme eksikliği, yanlış kanonik etiketler, robots.txt engeli ve kayıp sinyallerdir.
• Birleşik projelerde her iki risk grubu aynı anda devreye girer, bu yüzden takvimi ayrı aşamalara bölmek daha güvenlidir.

Benim tavsiyem şu: mümkünse tasarım değişikliği ile adres değişikliğini aynı gün canlıya almayın. İki değişikliği ayırırsanız, bir düşüş gördüğünüzde nedenini çok daha hızlı teşhis edersiniz.

Hangi taşıma türleri var ve risk düzeyleri nasıl değişir?

Her SEO migration aynı ağırlıkta değildir. Aşağıdaki tablo, sahada en sık karşılaştığım altı taşıma türünü ve her birinin göreli risk düzeyini özetliyor. Risk sütunu saha tecrübesine dayalı bir başlangıç değerlendirmesidir, garanti değil; sitenizin büyüklüğü ve teknik borcu bu tabloyu değiştirebilir.

Tablodaki sıralama size bir öncelik fikri verir. Ancak birden fazla türü aynı anda yapıyorsanız, riskler üst üste biner. Örneğin alan adı değişikliğiyle birlikte platform değiştirmek, iki yüksek riskli işi tek güne sıkıştırmak demektir.

Taşımaya başlamadan önce hangi verileri yedeklemelisiniz?

Taşıma sonrası bir sorun çıktığında elinizde karşılaştırma yapacak bir "önce" fotoğrafı yoksa, neyin bozulduğunu kanıtlayamazsınız. Bu nedenle ilk işim her zaman kapsamlı bir anlık görüntü almak olur.

• Search Console'dan son 16 ayın performans verisi: sayfa, sorgu ve ülke kırılımıyla dışa aktarın.
• Tam site taraması: tüm URL'ler, durum kodları, başlıklar, meta açıklamalar, kanonik etiketler ve H1'ler.
• Analytics verisi: organik giriş sayfaları ve dönüşüm getiren sayfaların listesi.
• Dış bağlantı alan en değerli sayfaların listesi; bu sayfalar yönlendirmede önceliklidir.
• Mevcut robots.txt, XML site haritası ve varsa hreflang yapısının kopyası.
• Şema işaretlemesi örnekleri: ürün, makale, SSS ve işletme işaretlemeleri.

Ayrıca kendi takibim için en çok trafik getiren sayfaların anahtar kelime sıralamalarını da kaydederim. Böylece taşıma sonrası hangi sayfanın, hangi sorguda yer kaybettiğini net görürsünüz. Bu hazırlık birkaç saat sürer ama sonradan günlerce süren tahmin yürütme işinden sizi kurtarır.

Bu dosyaları taşıma projesinin ortak klasöründe saklayın ve tarih ekleyin. Aylar sonra biri "eskiden bu sayfa ne kadar trafik alıyordu?" diye sorduğunda cevabı saniyeler içinde verebilirsiniz. Özellikle Search Console verisi sınırlı bir geçmiş tuttuğu için bu yedek, uzun vadeli karşılaştırmanın tek kaynağı olabilir.

URL eşleme tablosunu nasıl hazırlarsınız?

URL eşleme tablosu, her eski adresin hangi yeni adrese gideceğini gösteren basit bir listedir. Her SEO migration projesinde en çok emek isteyen ama en çok da geri dönen adım budur. Google da taşıma rehberinde eski ve yeni URL'ler arasında bir eşleme hazırlamayı ilk adımlardan biri olarak sayıyor.

Tabloyu hazırlarken şu sırayı izliyorum:

1. Tarama, site haritası, Search Console ve analitik verilerinden tüm eski URL'leri tek listede birleştirin.
2. Her eski URL için içerik olarak en yakın yeni sayfayı bulun; bire bir eşleşme her zaman ilk tercihtir.
3. Karşılığı olmayan sayfalar için karar verin: benzer bir sayfaya mı yönlendireceksiniz, yoksa 404 veya 410 mu dönecek?
4. Parametreli, sayfalamalı ve büyük küçük harf farkı olan varyasyonları ayrıca listeleyin.
5. Tabloyu test ortamında toplu olarak doğrulayın ve her satırın tek adımda hedefe ulaştığını kontrol edin.

En sık gördüğüm kestirme, tüm eski adresleri ana sayfaya yönlendirmektir. Google bu tür alakasız toplu yönlendirmeleri kullanıcı için yararlı bulmaz ve ilgili sayfaların sinyallerini kaybedebilirsiniz. Yeni adreslerde kısa ve okunabilir bağlantılar kurmak için slug oluşturucu aracından da faydalanabilirsiniz.

301, 302 ve 308 yönlendirmeleri arasında ne fark var?

Kalıcı taşımalarda kalıcı yönlendirme kullanırsınız. Google'ın yönlendirmeler ve Google Arama dokümanına göre 301 ve 308 kalıcı yönlendirmedir; Google bunları hedef sayfanın kanonik olması gerektiğine dair güçlü bir sinyal olarak okur. Buna karşılık 302, 303 ve 307 geçici yönlendirme grubundadır ve kaynak sayfa arama sonuçlarında kalmaya devam edebilir.

Dokümanda dikkat çeken birkaç ayrıntı daha var:

• Sunucu tarafı yönlendirme, Google'ın doğru yorumlaması için en sağlam yöntemdir.
• Google sıfır saniyelik meta refresh'i kalıcı, gecikmeli olanı ise geçici sayar.
• JavaScript yönlendirmesi ancak sunucu tarafı veya meta refresh mümkün değilse son çare olmalıdır; oluşturma adımı başarısız olursa yönlendirme hiç görülmeyebilir.

Site taşıma rehberi ayrıca yönlendirme zincirlerine dikkat çekiyor: Googlebot on adıma kadar takip edebilse de rehber zinciri üç adımın altında tutmayı öneriyor, çünkü her ek adım kullanıcıyı yavaşlatıyor. Yönlendirmelerinizi yayına almadan önce yönlendirme denetleyici ile örnek URL'lerin tek adımda ve doğru kodla hedefe ulaştığını kontrol edin.

Alan adı değişikliğinde nelere dikkat etmelisiniz?

Alan adı değişikliği, marka birleşmesi, yeniden markalaşma ya da ülke uzantısından genel uzantıya geçiş gibi sebeplerle gündeme gelir. En yüksek riskli SEO migration türüdür, çünkü tüm sinyallerin başka bir alan adına devredilmesi gerekir. Kontrol listem şöyle:

1. Yeni alan adının geçmişini kontrol edin; spam geçmişi olan bir alan adı sorun taşıyabilir.
2. Eski ve yeni alan adını Search Console'da aynı Google hesabıyla, sahip yetkisiyle doğrulayın.
3. Eski sitedeki her URL'yi karşılığı olan yeni URL'ye sayfa bazında 301 ile yönlendirin.
4. Yeni sitede kanonik etiketlerin, hreflang'ın ve site haritasının yeni alan adını gösterdiğinden emin olun.
5. Yönlendirmeler çalıştıktan sonra Search Console'daki Adres Değişikliği aracını başlatın.

Adres Değişikliği aracının yardım sayfasına göre araç yalnızca alan adı veya alt alan adı düzeyindeki mülklerde çalışır, eski ana sayfadan yeni ana sayfaya 301 bekler ve etkisi 180 gün sürer. Bu süre boyunca Google yeni siteyi taramaya öncelik verir ve sinyalleri yeni siteye aktarır. Dolayısıyla eski alan adını bu 180 günün içinde asla bırakmayın; hatta Google'ın önerisine uyarak yönlendirmeleri en az bir yıl, mümkünse süresiz tutun.

HTTP'den HTTPS'e geçerken neyi kontrol etmelisiniz?

HTTPS geçişi teknik olarak bir URL değişikliğidir, çünkü protokol adresin parçasıdır. Ancak aynı alan adında kaldığınız için Adres Değişikliği aracına gerek yoktur; Google'ın taşıma rehberi de bu aracın HTTP'den HTTPS'e geçişlerde kullanılmadığını belirtiyor. Kontrol listem:

• Sertifikanın tüm alan adı varyasyonlarını (www ve www'suz) kapsadığını doğrulayın.
• Tüm HTTP adreslerini, aynı yolu koruyarak HTTPS karşılığına tek adımda 301 ile yönlendirin.
• Şablonlardaki resim, script ve stil dosyası çağrılarını HTTPS'e çevirerek karışık içerik uyarılarını temizleyin.
• Kanonik etiketleri, iç linkleri ve site haritasını HTTPS adreslerle güncelleyin.
• Search Console'da HTTPS mülkünü ekleyin veya alan adı mülkü kullanıyorsanız kapsamı kontrol edin.

Sahada en sık gördüğüm hata, www ile HTTPS yönlendirmesinin iki ayrı kural olarak yazılmasıdır. Sonuçta http://site.com önce https://site.com adresine, oradan da https://www.site.com adresine gider. Bu iki adımlı zincir büyük bir felaket değildir ama gereksizdir; tek kuralla doğrudan son hedefe gönderin.

CMS veya platform değişiminde neler bozulabilir?

WordPress'ten özel bir altyapıya, bir e-ticaret paketinden başka bir pakete ya da statik siteden CMS'e geçerken sorunların çoğu gözden kaçan yerlerden çıkar. Yeni platform sayfaları aynı gösterir ama arka planda farklı çalışır. Özellikle şu alanları tek tek karşılaştırırım:

• Başlık etiketleri ve meta açıklamalar: toplu aktarımda boş kalabilir veya şablon varsayılanına dönebilir.
• Kanonik etiketler: bazı platformlar filtre ve sıralama sayfalarında kendi kanonik mantığını dayatır.
• Şema işaretlemesi: ürün fiyatı, stok ve değerlendirme işaretlemesi yeni temada eksik olabilir.
• Sayfalama ve filtreler: parametre yapısı değişirse binlerce yeni URL ortaya çıkabilir.
• Görsel adresleri ve alt metinleri: görsel aramadan gelen trafiği etkiler.
• Sayfa hızı: yeni tema ağırsa Core Web Vitals değerleriniz geriler.

E-ticaret tarafında kategori ve ürün URL'leri platforma göre çok farklı kalıplar kullanır. Bu nedenle platform seçimini yapmadan önce URL yapısını ne kadar kontrol edebileceğinizi sorun. Büyük kataloglarda kategori mimarisini baştan düşünmek için büyük web sitelerinde kategori yapısı yazısına göz atabilirsiniz; platform geçişi süreçlerinde ise e-ticaret danışmanlığı kapsamında destek veriyorum.

URL yapısını değiştirirken hangi hatalardan kaçınmalısınız?

Bazen alan adı ve platform aynı kalır, yalnızca adresler değişir: tarihli blog adreslerinden sade adreslere geçmek, kategori klasörlerini kaldırmak ya da uzantıları temizlemek gibi. Bu tür bir SEO migration küçük gibi durur ama etkisi site geneline yayılır. Kaçınmanız gereken hatalar:

1. Değişikliği "daha güzel görünsün" diye yapmak. Net bir kazanç yoksa URL değiştirmek riski boşuna almak demektir.
2. İç linkleri güncellememek. Yönlendirme çalışsa bile site içinde eski adreslere link vermek tarama bütçesini ve hızı gereksiz yere harcar.
3. Sonda eğik çizgi, büyük küçük harf ve uzantı varyasyonlarını unutmak.
4. Eski URL'yi kısa süre sonra yeniden başka bir içerik için kullanmak.
5. Site haritasında hem eski hem yeni adresleri bırakmak.

Benim kuralım basit: yeni yapı en az birkaç yıl değişmeyecek kadar sade ve mantıklı olmalı. İki yılda bir URL değiştiren siteler, her seferinde biriken sinyalleri yeniden taşımak zorunda kalır. Yayına almadan önce yeni site haritasını XML sitemap oluşturucu ile hazırlayabilir, yalnızca 200 dönen kanonik adresleri eklediğinizden emin olabilirsiniz.

Sunucu veya hosting taşıması sıralamayı etkiler mi?

URL'ler değişmiyorsa sunucu taşıması en düşük riskli türdür, ama sıfır riskli değildir. Google'ın URL değişikliği olmadan site taşıma rehberi taşıma sonrası Googlebot'un tarama hızında geçici bir düşüş, ardından birkaç gün içinde istikrarlı bir artış görebileceğinizi söylüyor. Yani kısa süreli bir tarama dalgalanması normaldir.

Aynı rehberden çıkardığım ve kendi pratiğime eklediğim kontrol listesi:

• DNS kayıtlarının TTL değerini taşımadan en az bir hafta önce düşürün; böylece yeni adres daha çabuk geçerlilik kazanır.
• Yeni sunucuda robots.txt ve noindex engeli kalmadığından emin olun.
• HTML dosyasıyla doğrulama yapıyorsanız doğrulama dosyasını yeni sunucuya da taşıyın.
• URL Denetimi aracıyla Googlebot'un yeni sunucuya erişebildiğini test edin.
• Eski sunucuya gelen trafik sıfırlanana kadar eski hostingi kapatmayın.

DNS kayıtlarının yeni adrese dönüp dönmediğini DNS sorgulama aracıyla hızlıca kontrol edebilirsiniz. Ayrıca yeni sunucunun yanıt süresini de izleyin; yavaş bir sunucu, tarama hızını düşürerek dolaylı yoldan görünürlüğü etkiler.

İki siteyi birleştirirken hangi sayfaları tutmalısınız?

Birleştirme, iki markanın tek çatı altına girmesi ya da bir kampanya sitesinin ana siteye katılması gibi durumlarda karşınıza çıkar. Bu, en çok karar gerektiren taşıma türüdür, çünkü her sayfayı birebir taşımak çoğu zaman mantıklı değildir. Burada her içeriği üç gruptan birine ayırıyorum:

• Tut ve taşı: trafik, bağlantı veya dönüşüm getiren, konusu ana siteyle örtüşmeyen sayfalar.
• Birleştir: ana sitede zaten benzer bir sayfa varsa, iki içeriğin güçlü yanlarını tek sayfada toplayıp eskisini buraya yönlendirin.
• Kaldır: ince, güncelliğini yitirmiş ve hiçbir sinyali olmayan sayfalar için 410 veya 404 dönün.

Birleştirmede bir tuzak daha var: iki sitenin aynı sorgular için yarıştığı durumlarda, birleşme sonrası sıralamalar kendiliğinden birleşmez. Google yeni sayfayı değerlendirirken zaman geçer ve bu süreçte dalgalanma olağandır. Taşıma rehberi de daha büyük sitelerin daha uzun sürede toparlandığını belirtiyor. Bu nedenle birleştirme projelerinde beklentiyi baştan gerçekçi kurmak, sonradan yaşanabilecek hayal kırıklığını önler.

Çok dilli sitelerde hreflang yapısını nasıl korursunuz?

Birden fazla dilde yayın yapan sitelerde taşıma, hreflang ağını da yeniden kurmak demektir. Her dil sürümü, diğer tüm sürümleri yeni adresleriyle göstermelidir. Bir dil sürümünde eski adres unutulursa karşılıklı bağlantı kopar ve Google bu işaretlemeyi yok sayabilir.

Taşımada kontrol ettiğim noktalar:

• Hreflang etiketleri yönlendirilen değil, 200 dönen son adresi göstermeli.
• Her sürüm kendisini de listelemeli ve x-default doğru sayfayı işaret etmeli.
• Dil klasörleri değişiyorsa her dil için ayrı eşleme tablosu hazırlayın.

Konunun temellerini hreflang etiketi nedir yazısında anlattım. Yeni adreslerle etiketleri hızlıca üretmek için hreflang oluşturucu aracını kullanabilirsiniz. Böylece elle yazarken yapılan yazım hatalarını da en baştan önlersiniz.

Dil sürümlerini farklı alan adlarından tek alan adı altındaki klasörlere taşıyorsanız, her ülke uzantısı için ayrı bir Search Console mülkü ve ayrı bir yönlendirme planı gerekir. Örneğin Almanca sürüm .de alan adından /de/ klasörüne geçiyorsa, o alan adındaki her sayfayı /de/ altındaki karşılığına tek tek 301 ile yönlendirmeniz ve eski alan adını Search Console'da ayrıca izlemeniz gerekir.

Canlıya almadan önce test ortamında neleri denemelisiniz?

Test ortamı, SEO migration sürecinin sigortasıdır. Yeni siteyi şifreyle veya IP kısıtlamasıyla koruyun; test ortamının Google dizinine girmesini istemezsiniz. Ancak bu korumayı canlıya geçişte kaldırmayı da takvime ayrı bir madde olarak yazın.

Test aşamasında şu kontrolleri yaparım:

• Eşleme tablosundaki tüm satırları bir tarama aracıyla toplu test edin; her eski adres tek adımda 200 dönen bir hedefe ulaşmalı.
• Önemli şablonların (ana sayfa, kategori, ürün, blog yazısı) başlık, meta açıklama, H1 ve kanonik değerlerini eski siteyle yan yana karşılaştırın.
• Mobil görünümü ve sayfa hızını kontrol edin; yeni tema ağırsa canlıya almadan önce düzeltin.
• Formları, sepet ve ödeme akışını ve teşekkür sayfalarını baştan sona deneyin.

Bu listeyi ekiple paylaşın ve her maddeye bir sorumlu atayın. Böylece canlıya alma günü sürpriz yerine yalnızca doğrulama yaparsınız. Meta etiketleri toplu olarak gözden geçirirken Google SERP önizleme aracı, başlıkların arama sonuçlarında nasıl duracağını görmenize yardımcı olur.

Taşıma günü sırasıyla neler yapmalısınız?

Taşıma gününü düşük trafikli bir güne ve saate denk getirin; perakendede kampanya haftası, B2B'de çeyrek sonu gibi dönemlerden kaçının. Benim canlıya alma günü listem şu sırayı izler:

1. Test ortamındaki noindex etiketlerini ve robots.txt engelini kaldırın. Bu adımı unutmak, sahada gördüğüm en pahalı hatalardan biridir.
2. Yönlendirme kurallarını yayına alın ve eşleme tablosundan rastgele seçtiğiniz örnekleri hemen test edin.
3. Yeni XML site haritasını Search Console'a gönderin.
4. Alan adı değişikliğiyse Adres Değişikliği aracını başlatın.
5. En değerli sayfaları URL Denetimi aracıyla kontrol edin ve dizine eklenme isteği gönderin.
6. Analytics ve dönüşüm etiketlerinin yeni sayfalarda tetiklendiğini doğrulayın.

Google'ın rehberine göre yeni URL'leri içeren site haritası başlangıçta dizinde hiç sayfa göstermeyebilir; bu normaldir. Robots.txt dosyanızı yeni yapıya göre düzenlemeniz gerekiyorsa robots.txt oluşturucu ile temiz bir dosya hazırlayabilirsiniz. Son olarak ekip içinde kimin hangi sorundan sorumlu olduğunu önceden belirleyin; sorun çıktığında kimi arayacağınızı bilmek dakikalar kazandırır.

Taşıma sonrası ilk 30 gün neyi izlemelisiniz?

Canlıya almak işin yarısıdır. Asıl sorunlar genellikle ilk günlerde değil, Google eski URL'leri tekrar taramaya başladıkça ortaya çıkar. İlk 30 günde her gün veya iki günde bir şunlara bakarım:

• Search Console tarama istatistikleri: 404, 5xx ve yönlendirme hatalarındaki artışlar.
• Sayfa dizine ekleme raporu: yeni adreslerin dizine girme hızı ve "yönlendirmeli sayfa" sayısı.
• Performans raporu: eski ve yeni URL'lerin gösterim ve tıklamalarının kesişme noktası.
• Sunucu kayıtları: Googlebot'un hangi eski adreslere hâlâ geldiği.
• Dönüşümler: trafik korunsa bile form veya satış akışı çalışmıyor olabilir.

Önce hazırladığınız anlık görüntüyle karşılaştırma yaparsanız, düşüşün site geneli mi yoksa belirli bir şablona mı özgü olduğunu hızla görürsünüz. Örneğin yalnızca ürün sayfaları düşüyorsa sorun büyük ihtimalle ürün şablonundadır. Üçüncü haftadan sonra kontrol sıklığını azaltabilirsiniz, ancak aylık karşılaştırmayı en az altı ay sürdürün. Teknik tarafın genel çerçevesini yapay zekâ sonrası teknik SEO yazısında da ele aldım.

SEO migration sonrası trafik ne kadar sürede eski seviyesine döner?

Tek bir doğru süre yok. Google'ın site taşıma rehberi, orta büyüklükteki bir sitede Google'ın eski URL'ler yerine yenilerini göstermeye başlamasının birkaç hafta veya daha uzun sürebileceğini, büyük sitelerde ise sürecin daha da uzayabileceğini söylüyor. Bu, SEO migration planlarken beklentiyi yönetmek için elinizdeki en sağlam resmi referanstır.

Kendi deneyimime dayanan kaba bir çerçeve de paylaşayım, ama bunu garanti olarak değil, saha tecrübesine dayalı bir başlangıç aralığı olarak okuyun:

• Sunucu taşıması ve temiz bir HTTPS geçişi: çoğu zaman birkaç gün ile birkaç hafta arasında dengeye gelir.
• URL yapısı ve platform değişimi: birkaç hafta ile birkaç ay arası dalgalanma görebilirsiniz.
• Alan adı değişikliği ve birleştirme: birkaç ay sürebilir; bazı projelerde eski seviyeye hiç dönemezsiniz.

Toparlanma süresini en çok uzatan şey, taşıma sonrası fark edilen hataların geç düzeltilmesidir. Dolayısıyla ilk 30 günlük izleme, toparlanma hızını doğrudan belirler.

Bir de şunu ekleyeyim: taşımadan hemen önce ve sonra büyük içerik değişiklikleri yapmayın. Eski sayfaları silmek, başlıkları topluca yeniden yazmak veya yeni kategoriler açmak, dalgalanmanın nedenini belirsizleştirir. Önce taşımanın oturmasını bekleyin, sonra iyileştirmelere geçin.

En sık gördüğüm SEO migration hataları nelerdir?

Yıllar içinde farklı ölçekte sitelerde taşıma sürecine dahil oldum veya taşıma sonrası kurtarma için çağrıldım. Hataların büyük kısmı teknik bilgi eksikliğinden değil, planlama ve iletişim eksikliğinden çıkıyor. En sık karşılaştıklarım:

1. Test ortamının noindex etiketinin canlıya taşınması.
2. Tüm eski sayfaların ana sayfaya yönlendirilmesi.
3. Kalıcı yerine geçici yönlendirme kullanılması, çünkü yazılım varsayılanı 302'dir.
4. Eski alan adının birkaç ay sonra yenilenmeyip boşa düşmesi.
5. Yeni sitede kanonik etiketlerin hâlâ eski alan adını göstermesi.
6. Reklam, e-posta ve sosyal medya profillerindeki linklerin güncellenmemesi.

Son madde doğrudan SEO sorunu gibi görünmese de önemlidir. Google Ads nihai URL'leri güncellenmezse reklam trafiği her tıklamada yönlendirmeden geçer ve ölçüm karışabilir. Kampanya tarafını birlikte ele almak isterseniz Google Ads yönetimi sayfama göz atabilirsiniz.

Bu hataların hemen hepsinin ortak noktası, taşımanın yalnızca geliştirici ekibin işi olarak görülmesidir. Oysa pazarlama, reklam ve içerik ekiplerinin de takvimden haberdar olması gerekir. Kısa bir toplantı ve paylaşılan bir kontrol listesi, bu hataların çoğunu önler.

Taşımayı kendiniz mi yapmalısınız, destek mi almalısınız?

Küçük bir kurumsal sitede sunucu taşıması veya HTTPS geçişi için bu yazıdaki kontrol listeleri çoğu zaman yeterlidir. Ancak binlerce URL'lik bir e-ticaret sitesinde alan adı ya da platform değiştiriyorsanız, hata maliyeti destek maliyetini kolayca aşar. Karar verirken kendinize şu soruları sorun:

• Organik trafik gelirinizin ne kadarını oluşturuyor?
• Ekibinizde yönlendirme kurallarını yazıp test edebilecek biri var mı?
• Taşıma sonrası 30 günü günlük izleyecek zamanınız var mı?

Bu sorulardan birine bile "hayır" diyorsanız, dışarıdan bir göz almak mantıklıdır. SEO danışmanlığı kapsamında taşıma öncesi denetim, eşleme tablosu kontrolü ve sonrası izlemeyi üstleniyorum. Projenizi konuşmak isterseniz iletişim sayfasından bana doğrudan ulaşabilirsiniz; aracı olmadan, planı birlikte netleştiririz.

Hangi yolu seçerseniz seçin, bu yazıdaki listeleri kendi projenize göre uyarlayın ve her adımın tamamlandığını işaretleyin. Taşımada başarıyı belirleyen şey tek bir büyük hamle değil; unutulmayan onlarca küçük ayrıntıdır.