Kısa cevap: Site taşıma; mevcut bir sitenin URL’lerini, alan adını, altyapısını, sunucusunu veya yapısını değiştiren her işlemdir — ve organik trafiğe yapabileceğiniz en riskli müdahaledir. Doğru yapıldığında sıralamalarınızın %90–100’ünü korur, geçici düşüşü dört ile sekiz hafta içinde toparlarsınız. Yanlış yapıldığında bir gecede trafiğinizin yarısını kaybeder, geri kazanmak için altı ay harcarsınız. Aradaki farkı belirleyen şey neredeyse hiçbir zaman yeni sitenin kendisi değildir; eksiksiz bir URL haritası çıkarıp çıkarmadığınız, her eski URL’yi tek bir 301 ile gerçek karşılığına yönlendirip yönlendirmediğiniz, sayfa içi sinyalleri koruyup korumadığınız ve yayına aldıktan sonraki ilk saatlerde her şeyi doğrulayıp doğrulamadığınızdır. Bu rehber, öncesi — sırası — sonrasıyla eksiksiz kontrol listesidir; her adım için kullanabileceğiniz ücretsiz araçlarla birlikte.

Neye “taşıma” denir?

“Site taşıma” denince çoğu kişinin aklına yeni bir alan adına geçmek gelir. Bu türlerden yalnızca biri. Kavram çok daha geniş bir değişiklik kümesini kapsıyor ve en riskli olanlarının bir kısmı, işi yürüten ekiplere hiç taşıma gibi gelmiyor. Yol haritanızda aşağıdakilerden biri varsa, siz bir taşıma yapıyorsunuz demektir ve bu kontrol listesine ihtiyacınız var:

  • Alan adı değişikliğieskimarka.com yerine yenimarka.com. En yüksek riskli kategori; çünkü istisnasız her URL değişir ve yıllarca biriktirdiğiniz otoritenin tamamı yönlendirmeler üzerinden aktarılmak zorundadır.
  • Protokol veya alt alan adı değişikliği — HTTP’den HTTPS’e ya da www’den www’siz sürüme geçiş. Teknik olarak küçük görünür ama sitedeki her URL’yi değiştirir. Ayrıntısı HTTPS geçiş rehberinde var.
  • Altyapı değişikliği — WordPress’ten hazır bir e-ticaret paketine, özel yazılımdan headless bir CMS’e, bir e-ticaret motorundan diğerine geçmek. İçerik birebir aynı kalsa bile URL kalıpları, şablonlar, sayfanın nasıl render edildiği ve meta etiketlerin nasıl üretildiği aynı anda değişir.
  • URL yapısı değişikliği/blog/2019/03/yazi-adi/ yapısını /blog/yazi-adi/ hâline getirmek, kategori klasörü eklemek ya da kaldırmak, ürün URL kalıbını değiştirmek. Hedeflemeniz gereken yapı için URL yapısı kuralları iyi bir başlangıç.
  • Tasarım yenileme — URL’ler hiç değişmeyebilir; ama şablonlar, iç bağlantılar, başlıklar, metin hacmi ve sayfa hızı değişir. İnsanların en sık “bu taşıma sayılmaz” deyip geçtiği tür budur ve sayfa içi sinyaller inceldiği için sessizce trafik kaybettirir.
  • Birleştirme veya ayırma — birkaç siteyi tek çatı altında toplamak, blogu blog.ornek.com adresinden ornek.com/blog/ adresine almak ya da bir bölümü ayrı alan adına çıkarmak.
  • Sunucu, hosting veya CDN değişikliği — hiçbir URL değişmez; ama IP, yanıt süreleri, HTTP başlıkları ve önbellek davranışı değişir. Risk daha düşüktür, yine de yeni yığın yavaşsa veya yanlış yapılandırılmışsa trafik düşürebilir.

Google da aynı ayrımı yapıyor ve URL değişikliği olan taşımalar ile URL değişikliği olmayan taşımalar için ayrı dokümanlar yayımlıyor. Pratik kural şu: URL’lerinizin ne kadar büyük kısmı değişiyorsa süreç o kadar uzar ve o kadar dikkatli planlanmalıdır. Ama “URL’ler aynı kalıyor” denen bir tasarım yenilemesi bile öncesi-sonrası karşılaştırması hak eder; çünkü içerik ve şablon değişiklikleri de sıralamaları en az bozuk yönlendirmeler kadar etkili biçimde oynatır.

Taşımalar trafiği neden kaybettirir?

Bir taşıma kötü gittiğinde, sonradan yapılan incelemede karşımıza hemen her zaman sınırlı sayıda sebepten biri çıkar. Bunları önceden bilmek, savunmanın büyük bölümüdür:

  • Eksik yönlendirmeler. Eski URL, yeni karşılığına gitmek yerine 404 döner. O URL’ye bağlı her bağlantı, her sıralama ve biriken tüm otorite buharlaşır. Farkla birinci sıradaki sebep budur.
  • Tembel yönlendirmeler. Bütün eski URL’ler gerçek karşılıklarına değil, toplu hâlde ana sayfaya yönlendirilir. Google, alakasız bir sayfaya yapılan toplu yönlendirmeyi yumuşak 404 (soft 404) olarak değerlendirir ve sıralama aktarımı hiç gerçekleşmez. Sunucu yapılandırmasında derli toplu görünür, sonuç olarak yönlendirme yapmamaktan pek farkı yoktur.
  • Yanlış yönlendirme tipi. 301 (kalıcı) gereken yerde 302 (geçici) kullanmak, arama motorlarına eski URL’nin geri geleceğini söyler; sinyaller birleşmeyebilir. Farkı 301 ve 302 yönlendirmeleri yazısında ayrıntılı anlattık.
  • Yönlendirme zincirleri ve döngüler. Eski URL → ara adres → başka bir ara adres → son adres. Her sıçrama biraz verim kaybettirir, taramayı yavaşlatır ve zincirin bir yerinde kopma ihtimalini katlar.
  • Sayfa içi sinyallerin incelmesi. Yeni tasarımda metin kısalmış, başlıklar azalmış, title’lar değişmiş, alt metinler ya da şema işaretlemesi kaybolmuştur. Sıralamalar taşıma yüzünden değil, sayfalar nesnel olarak zayıfladığı için düşer.
  • İç bağlantıların güncellenmemesi. Menü, gövde bağlantıları ve site haritası hâlâ eski URL’leri gösterir; her iç tıklama bir yönlendirmeden geçer ve iç bağlantı grafiği seyrelir.
  • Kazara engelleme. Test ortamının noindex etiketi veya robots.txt içindeki Disallow: / satırı canlıya çıkar. Yıkıcıdır, sık görülür ve erken yakalarsanız beş dakikada düzelir.
  • Performans gerilemesi. Yeni altyapı daha yavaştır, yeni hosting yetersiz kaynakla açılmıştır ya da ağır betikler Core Web Vitals değerlerini kırmızıya iter.

Bu listedeki her madde planlamayla önlenebilir ve yayından sonraki bir saat içinde tespit edilebilir. Rehberin geri kalanı altı aşamaya bölünmüş durumda — ölçüm, haritalama, geliştirme, yayın, doğrulama ve izleme — çünkü işin yapılması gereken sıra tam olarak budur.

1. Aşama — Hiçbir şeye dokunmadan önce eksiksiz ölçüm alın

Bir taşımanın başarılı olduğunu kanıtlamanız ya da neyin bozulduğunu teşhis etmeniz, öncesinde neyin var olduğuna dair bir fotoğraf olmadan mümkün değildir. Bu iş, eski site hâlâ yayındayken yapılmak zorunda; site kapandıktan sonra bu veriler geri getirilemez. Buna bir gün ayırın.

1. Eski sitenin tamamını tarayın

Tam bir tarama çalıştırın ve 200 dönen her URL’yi; başlığı, meta açıklaması, H1’i, kelime sayısı, canonical’ı, durum kodu ve aldığı iç bağlantı sayısıyla birlikte dışa aktarın. Bu döküm, URL haritanızın ham maddesidir; dolayısıyla eksiksiz olmalı — yalnızca menüde görünen sayfalar yetmez. Taranabilir kümeyi Teknik Site Denetimi (Tarayıcı) ile çıkarın; sonra bunu Sitemap Bulucu & Doğrulayıcı ile bulduğunuz XML site haritasıyla ve elinizde varsa sunucu loglarıyla karşılaştırın. Çünkü hiçbir iç bağlantının işaret etmediği öksüz sayfalar saf taramada görünmez ama hâlâ sıralanıyor ve trafik getiriyor olabilir.

2. Search Console ve analitik verisini dışa aktarın

Search Console’dan en az 16 aylık performans verisini sayfa kırılımında çekin: tıklama, gösterim, ortalama pozisyon ve her URL’nin sıralandığı sorgular. Aynısını analitik tarafında yapın: son 12 ay için açılış sayfası bazında oturum ve dönüşüm. Bu ikisi birlikte, hangi URL’lerin gerçekten önemli olduğunu söyler. Tipik bir sitede sayfaların %10–20’si organik trafiğin %80’ini üretir; bu sayfalar yayından sonra toplu kurallara emanet edilmez, tek tek doğrulanır. Raporları çekme ve okuma tarafı için Search Console ile ölçümleme rehberine bakın.

3. Sıralama fotoğrafını çekin

Yayından önce öncelikli anahtar kelimelerinizin güncel pozisyonlarını Anahtar Kelime Sıralama Kontrolü ile kaydedin. Taşıma sonrası paniği genelde verilerden değil hislerden beslenir; tarihli bir sıralama kaydı, hangi kelimenin ne kadar oynadığını ve eğilimin toparlanma mı yoksa düşüş mü olduğunu net söylemenizi sağlar. Veriyle birlikte tarihi de saklayın.

4. Backlink envanterini çıkarın

Yönlendiren alan adlarını ve tam olarak hangi sayfaya bağlandıklarını Backlink Kontrol / Doğrulayıcı ve Zararlı Backlink Denetimi ile dışa aktarın. İki sebepten: birincisi, dış bağlantı almış her URL çalışan bir yönlendirme almak zorundadır, çünkü otorite sitenize oradan giriyor; ikincisi, taşımadan sonra en değerli kaynak sitelerden bağlantılarını doğrudan yeni URL’ye güncellemelerini isteyeceksiniz — bu, sonsuza kadar yönlendirmeye güvenmekten kesinlikle daha iyidir.

5. Teknik referans değerlerini kaydedin

Şunları ölçün ve saklayın: ana şablonların sayfa hızı ve Core Web Vitals değerleri (Sayfa Hızı & Boyut Testi ile), her şablonda bulunan yapısal veri (Yapısal Veri (Schema) Kontrolü ile), mevcut robots.txt (Robots.txt Test Aracı ile), Search Console’daki dizine eklenmiş sayfa sayısı ve sunucunuzun gönderdiği yanıt başlıkları (HTTP Başlık Kontrolü ile). Yayından sonra tahmin yürütmek yerine bu sayılarla karşılaştırma yaparsınız.

Tüm bunları tarih damgalı tek bir klasörde toplayın. Üçüncü hafta biri “bu sayfa eskiden sıralanıyor muydu?” diye sorduğunda tartışma değil, cevap üretmek istersiniz.

2. Aşama — URL haritası: her şeyi belirleyen tek belge

Bir taşımanın başarısını tek bir çıktı belirliyorsa, o da budur. URL haritası, her eski URL için bir satır içeren ve en azından üç sütunu olan bir tablodur: eski URL, dönüşeceği yeni URL ve yönlendirme tipi. Taşımadaki diğer her şey uygulama ayrıntısıdır; taşımanın kendisi bu belgedir.

Mümkün olan her yerde bire bir eşleyin

Her eski URL, aynı kitleye aynı niyeti karşılayan yeni URL’ye gitmelidir. Eski ürün sayfası, o ürünün yeni sayfasına. Eski blog yazısı, yeni adresindeki aynı yazıya. Kategori, karşılık gelen kategoriye. Eşleşme ne kadar birebirse sıralamalar ve link değeri o kadar eksiksiz aktarılır; çünkü Google’a “bu içerik buraya taşındı” demiş olursunuz, “bu içerik gitti, mağazaya bakın” değil.

Karşılığı olmayan içerik için bilinçli karar verin

Bazı eski URL’lerin yeni sitede doğrudan karşılığı olmayacak. Refleks olarak ana sayfaya yönlendirmeyin. Şu sırayla ilerleyin:

  • En yakın alakalı sayfa. Üretimi biten bir ürün, yerine geçen modele; o da yoksa kategori sayfasına gider. Kaldırılan bir hizmet, en yakın güncel hizmete. Yönlendirmeyi anlamlı kılan şey alakadır.
  • Üst kategori — tek bir sayfa iyi bir karşılık değilse ama bölüm hâlâ duruyorsa.
  • 410 Gone — gerçekten ölmüş, karşılığı ve gelen bağlantısı olmayan içerik için: biten etkinlikler, kimsenin bağlantı vermediği kapanmış ürün grupları. Bilinçli bir 410, alakasız bir yönlendirmeden temizdir ve Google’a URL’yi hızlıca düşürmesini söyler.
  • Ana sayfa — yalnızca son çare ve yalnızca trafiği, bağlantısı ve yakın akrabası olmayan URL’ler için. Toplu ana sayfa yönlendirmeleri yumuşak 404 sayılır ve hiçbir şey aktarmaz.

Birleştirmeyi dürüstçe planlayın

Taşıma, ince ve birbiriyle örtüşen sayfaları birleştirmek için doğal bir fırsattır; birbirinin neredeyse aynısı olan beş hizmet sayfasının tek bir güçlü sayfaya dönüşmesi gibi. Bu genelde hem anahtar kelime yamyamlığı açısından hem de kullanıcı açısından iyidir. Yalnızca aynı anda iki iş yaptığınızın farkında olun: içerik birleştiriyor ve URL değiştiriyorsunuz. Eski varyantların hepsini birleşmiş sayfaya yönlendirin, birleşmiş sayfanın her birinin kapsadığı konuyu gerçekten kapsadığından emin olun ve yeni (çoğunlukla daha yüksek) pozisyonuna oturmasının birkaç hafta süreceğini hesaba katın. Neyin yaşamayı hak ettiğine karar vermek için eski kümeye Zayıf İçerik Kontrolü çalıştırın.

Herkesin unuttuğu URL’leri de kapsayın

Eksik harita en sık görülen hata biçimidir ve boşluklar tahmin edilebilir. Şunları açıkça ekleyin: sayfalanmış URL’ler (sayfalama SEO’su yazısına bakın), sıralanan parametre ve filtre URL’leri, etiket ve yazar arşivleri, arama trafiği çeken görsel dosyaları ve PDF’ler, eski XML site haritası yolları, robots.txt, favicon ve dış servislerin istediği diğer kök dosyalar, besleme adresleri (/feed/, /rss), kampanyalardan kalan eski açılış sayfaları ve bugün hiç trafik almasa bile dış bağlantısı olan her URL.

Önce kalıp kuralları, sonra istisnalar

Büyük bir sitede 40.000 satırlık yönlendirme listesini elle bakımda tutamazsınız. Dönüşüm sistematikse kalıp kuralı yazın (/blog/2019/03/(.*)/blog/…) ve birebir listeyi yalnızca istisnalar ile en değerli URL’leriniz için tutun. Sonra kalıpları yayına almadan önce gerçek eski URL örnekleriyle test edin — kâğıt üzerinde çalışan ama sondaki eğik çizgide ya da büyük harflerde tökezleyen bir düzenli ifade, bir sitenin koca bir bölümünü kaybetmenin klasik yoludur.

Zincir kurmayın

Daha önce taşıma yaptıysanız yönlendirme dosyanızda önceki taşımadan kalan kurallar duruyor olabilir. Eski URL A, B’ye yönleniyor; şimdi B de C’ye yönlenecek. Bunu düzleştirin: A doğrudan C’ye gitmeli, B de öyle. Zincirler taramayı yavaşlatır, tarama bütçesini israf eder ve ara kurallardan biri sonradan silinirse tamamen kopar. Yazdığınız her kuraldan örnek URL’ler alıp sıçrama sayısını Yönlendirme & HTTP Durum Kontrolü ile doğrulayın.

3. Aşama — Geliştirme ve test ortamı kontrolleri

Bu aşamanın tamamı yayın gününden önce, test ortamında yaşanır. Burada doğru yapmak, canlıda trafik düşerken düzeltmeye çalışmaktan çok daha ucuzdur.

Test ortamını dizinden gerçekten uzak tutun

Test siteleri iç karartıcı bir düzenlilikle dizine giriyor ve dizine giren bir kopya, canlı sitenizle rekabet ediyor. Test ortamını yalnızca robots.txt ile değil, HTTP kimlik doğrulaması veya IP kısıtıyla koruyun: Disallow satırı taramayı durdurur ama URL’nin sonuçlarda görünmesini güvenilir biçimde engellemez ve bağlantıyı bulan kimseyi durdurmaz. Şifre koruması tek sağlam cevaptır — ayrıca canlıya kazara “engelleme kuralı” olarak taşınamama gibi bir yan faydası da vardır. Test ortamında ayrıca noindex kullanıyorsanız, onu kaldırmayı yayın kontrol listenizin en başına yazın. Bu, noindex, nofollow ve disallow arasındaki farktır ve taşıma sırasında bunları karıştırmak pahalıya patlar.

Sayfa içi sinyalleri sayfa sayfa koruyun

Tasarım yenilemesi genelde şablonları baştan yazar; şablonlar da sayfa içi SEO’nuzu taşır. Önemli her sayfa için eskiyi ve yeniyi şu başlıklarda karşılaştırın:

  • Title ve meta açıklamalar — yeni CMS’ler kendi başlıklarını üretmeye bayılır. Örnek sayfaları Meta Etiket Analizcisi ile kontrol edin; bilinçli olarak yeniden yazacaksanız başlık etiketi optimizasyonuna bakın.
  • Başlık etiketleri — sayfa başına tek H1, mantıklı bir H1–H6 hiyerarşisi ve aynı anahtar ifadelerin korunması. Başlık Yapısı Analizcisi ile doğrulayın.
  • Gövde metni — kelime sayısı ve içerik derinliği. “Daha sade” tasarımlar, sıralamayı sağlayan metnin %40’ını rutin olarak kırpar. Sıralanan bir sayfayı kısaltırsanız daha kötü sıralanmasını bekleyin.
  • Görseller ve alt metinler — yeni galeri bileşenleri alt niteliklerini sıklıkla tamamen düşürür. Görsel ALT Metni Kontrolü çalıştırın; dosya adları veya yolları da değişiyorsa görsel SEO yazısını tekrar okuyun.
  • Yapısal veri — ürün, makale, SSS, breadcrumb ve kurum işaretlemesi şablon değişikliğinden sağ çıkmalı. Yapısal Veri (Schema) Kontrolü ile doğrulayın, ayrıntı için yapısal veri yazısına bakın.
  • İç bağlantılar — metin içi bağlantılar tasarım yenilemesinin ilk kurbanıdır. Birkaç şablonu Link Analizcisi ile kontrol edip iç bağlantı stratejinizle karşılaştırın.
  • Canonical etiketleri — kendine referans veren ve test ortamının değil, yeni sitenin mutlak URL’lerini gösteren biçimde. Test ortamı canonical’larının canlıya sızması klasik bir yayın günü hatasıdır. Ayrıntı: canonical etiketleri.
  • Hreflang — birden fazla dil yayınlıyorsanız her anotasyon yeni URL’lere göre yeniden yazılmalı ve karşılıklı kalmalıdır. Detaylar uluslararası SEO ve hreflang yazısında.

Performansı gerçekçi koşullarda test edin

Yeni şablonları test ortamında ölçün ve aldığınız referans değerlerle karşılaştırın. Hızınızı yarıya düşüren bir taşıma, yönlendirmeleriniz kusursuz olsa bile size sıralama kaybettirir. Özellikle sunucu yanıt süresine dikkat edin: yeni hosting çoğunlukla test sitesinin aldığı trafiğe göre boyutlandırılır, canlı sitenin yayına geçtikten dakikalar sonra göndereceği trafiğe göre değil. Sayılar eski siteden kötüyse sayfa hızı optimizasyonu yazısına bakın.

Operasyonel hazırlıkları tamamlayın

Yayın gününden önce şunlar hazır olsun: yeni XML site haritası üretilmiş ve doğrulanmış (XML site haritaları yazısına bakın), canlı robots.txt yazılmış ve gözden geçirilmiş, analitik ve etiket yöneticisi kapsayıcıları test ortamında kurulup denenmiş, yeni alan adı veya protokol için Search Console mülkü oluşturulup doğrulanmış, hizmet vereceğiniz her alan adı için SSL sertifikaları alınmış ve test edilmiş, geri dönüş gerekirse hızlı yayılsın diye DNS TTL değeri 24–48 saat öncesinden birkaç dakikaya çekilmiş olmalı.

4. Aşama — Yayın günü işletim planı

Takvim güzel göründüğü için değil, ilgi ayırabildiğiniz için yayına alın. Bu şu demek: trafiğin düşük olduğu bir gün, tipik olarak haftanın başı ve siteyi geliştiren ekip birkaç saat boyunca ulaşılabilir durumda — cuma akşamı değil, tatil arifesi veya en yoğun satış döneminizin bir gün öncesi hiç değil. Sezonun zirvesinde taşımak, yönetilebilir bir düşüşü ciro olayına çevirir.

Günün işlem sırası:

  • 1. Yayına alın ve engellemeleri kaldırın. Yeni siteyi yayınlayın, hemen ardından tüm noindex etiketlerini ve test ortamı robots.txt kurallarını kaldırın. Robots.txt Test Aracı ile ve canlı bir sayfanın ham HTML’ine bakarak doğrulayın.
  • 2. Yönlendirmeleri devreye alın. Yönlendirmeler yeni siteyle aynı sürümde canlıya çıkmalı, “bu hafta içinde” değil. Eski URL’lerin 404 döndüğü her aralık, Google’ın yeniden tarayıp onları dizinden düşürdüğü bir aralıktır.
  • 3. Trafiğe göre ilk 50 URL’yi tek tek kontrol edin. Her eski URL’yi çağırın ve doğru yeni sayfaya tek bir 301 ile gittiğini doğrulayın. Yönlendirme & HTTP Durum Kontrolü tüm sıçrama zincirini ve son durum kodunu gösterir.
  • 4. HTTPS ve sertifikaları doğrulayın — her alan adı için SSL Sertifika Kontrolü ile; www ve www’siz varyantlar ile tüm alt alan adları dâhil.
  • 5. Yeni site haritasını gönderin — Search Console üzerinden. Eski site haritasını da bir süre erişilebilir bırakın; Google’ın eski URL’leri yeniden tarayıp yönlendirmeleri görmesi için hızlı bir yol sunar.
  • 6. Adres değişikliğini bildirin — alan adı değiştiyseniz. Google’ın Adres Değişikliği aracı Search Console’a taşımanın kasıtlı olduğunu söyler ve aktarımı hızlandırır. Her iki mülkün doğrulanmış ve yönlendirmelerin çalışıyor olmasını ister.
  • 7. Analitiğin veri aldığını doğrulayın. Gerçek zamanlı raporlarda yeni URL’lerdeki trafiği izleyin. Yayından on dakika sonra sıfır oturum, bozuk bir siteyi değil bozuk bir etiketi işaret eder — ama hangisi olduğunu bilmeniz gerekir.
  • 8. Yeni sitenin tam taramasını başlatın. Teknik Site Denetimi (Tarayıcı) taramasını hemen çalıştırın ki 404’leri, yönlendirme zincirlerini, eksik başlıkları ve kırık iç bağlantıları ilk ayda değil ilk saatte bulun.

Hiçbir şeyin eski sisteme bağlı kalmadığından emin olana kadar eski sitenin hostingini ve DNS kayıtlarını açık tutun. Yönlendirmeleri sonuçta bir sunucunun yanıtlaması gerekir.

5. Aşama — İlk 48 saat

Düzeltilebilir bir hatanın hâlâ düzeltilebilir kaldığı pencere burasıdır. Bu listeyi iki kez uygulayın: yayından birkaç saat sonra ve ertesi sabah tekrar.

  • Eski URL listesinin tamamını tarayın. 1. Aşamadaki dökümü alın ve her URL’yi çağırın. Hepsi, canlı ve 200 dönen bir sayfaya tek bir 301 ile gitmeli. 404, 500, zincir ya da ana sayfaya yönlendirme dönen ne varsa hemen düzeltme listesine girer.
  • Site içi 404’leri kontrol edin. Yeni sitede Kırık Link Kontrolü çalıştırın. Şablonların otomatik düzeltmediği bağlantılar, içerik içindekilerdir.
  • Dizine eklenebilirliği doğrulayın. Search Console’daki URL İnceleme aracını birkaç kritik sayfada kullanın: sayfa dizine eklenebilir görünmeli, canonical doğru olmalı ve noindex bulunmamalı. Sayfalar hariç tutuldu olarak dönüyorsa, olağan sebepleri tarandı – şu anda dizine eklenmedi yazısı anlatıyor.
  • Canlı sayfalarda meta ve başlıkları doğrulayınMeta Etiket Analizcisi ve Sayfa İçi SEO Kontrolü (Anahtar Kelime) ile. Şablonlar canlıda, test ortamındakinden farklı davranmayı herkesin beklediğinden daha sık becerir.
  • Hızı canlıda yeniden ölçün — test koşullarında değil, gerçek trafik altında Sayfa Hızı & Boyut Testi ile.
  • Search Console kapsam ve tarama istatistiklerini günlük izleyin. 404’lerdeki sıçrama hangi yönlendirme kurallarının ıskaladığını, sunucu hatalarındaki sıçrama ise yeni hostingin zorlandığını söyler.
  • Sunucu loglarını okuyun. Taşımadan sonra Googlebot’un gerçekte neyi istediğini — hangi eski URL’lere hâlâ uğradığını ve karşılığında ne aldığını — görmenin en hızlı yolu log dosyası analizidir.

Öncelik sırasıyla düzeltin: önce en çok organik trafik alan sayfalar, sonra en çok backlink alanlar, sonra geri kalan her şey. Ayda üç ziyaret getiren bir sayfadaki 404 bir hafta bekleyebilir; en çok dönüşüm getiren sayfanızdaki 404 bir saat bile bekleyemez.

6. Aşama — Birinci haftadan on ikinci haftaya

Bir düşüş bekleyin. Ders kitabına uygun bir taşımada bile organik trafik, Google yeniden tarayıp yönlendirmeleri işlerken ve sinyalleri yeni URL’lere devrederken iki ila dört hafta boyunca genelde %5 ile %20 arasında geriler. Bu normaldir ve başarısızlık kanıtı değildir. Önemli olan eğrinin şeklidir: birkaç hafta içinde yataylaşıp yukarı dönen bir düşüş sağlıklı bir taşımadır; dördüncü haftadan sonra derinleşmeye devam eden bir düşüş ise gerçekten bozuk bir şey olduğunu gösterir.

İlk ayın haftalık rutini:

  • Sıralamaları kayıtla karşılaştırın. Aynı kelime kümesinde Anahtar Kelime Sıralama Kontrolü kontrolünü haftalık tekrarlayın. Düşüp yerinde kalan kelimelere odaklanın — bunlar genelde site geneli bir soruna değil, yönlendirmesi ya da içeriği yanlış olan belirli bir URL’ye işaret eder.
  • Dizine eklenmeyi takip edin. Yeni sitedeki dizine eklenmiş sayfa sayısı yükselirken eskininki düşmelidir. Yeni sayfalar dizine girmiyorsa önce canonical’lara, robots.txt dosyasına ve iç bağlantılara bakın.
  • İç bağlantıları güncelleyin, yönlendirmeye yaslanmayı bırakın. Menü, alt bilgi, gövde bağlantıları, canonical’lar, site haritaları ve hreflang etiketlerinin hepsi nihai yeni URL’leri göstermeli. Yönlendirmeler dış dünya için bir güvenlik ağıdır; doğru iç bağlantıların yerine geçmez. Yeni yapıda bağlantı grafiğini yeniden kurmak için İç Bağlantı Fırsatı Bulucu işinizi kolaylaştırır.
  • En iyi backlinklerinizin peşine düşün. En değerli eski URL’lerinize bağlantı veren sitelerle iletişime geçip güncellemelerini isteyin. Doğrudan bağlantı her zaman yönlendirilmiş bağlantıdan güçlüdür ve bir gün yönlendirme kaybolursa sizi korur.
  • Yönlendirmeleri en az bir yıl açık tutun. Google, taşımadan sonra en az bir yıl korumayı öneriyor; değerli backlink almış URL’ler için kalıcı tutun. Sunmanın hiçbir maliyeti yok.
  • Dördüncü haftada yeniden denetleyin. Tam bir Sayfa İçi SEO Denetimi çalıştırıp aldığınız referans değerlerle karşılaştırın. O aşamada yeni sitenin gerçek teknik profili oturmuş olur ve kalan boşluklar görünür hâle gelir.

Ayrıca planlanması gereken özel durumlar

Alan adı değişikliği

En yüksek riskli taşıma türü; çünkü her URL ve her dış bağlantı etkilenir. Standart listeye ek olarak: yayından önce hem eski hem yeni mülkü Search Console’da doğrulayın, Adres Değişikliği bildirimini gönderin, eski alan adını kayıtlı ve yönlendirmelerini çalışır hâlde süresiz tutun (bir alan adının süresini dolduruma bırakmak, backlink profilinizi onu satın alan kişiye hediye etmektir) ve kontrolünüzdeki her dış profili güncelleyin — sosyal medya hesapları, işletme kayıtları, e-posta imzaları, rehberler. Bir Google İşletme Profiliniz veya yerel dizin kayıtlarınız varsa oradaki web sitesi alanını da güncelleyin; yoksa NAP tutarlılığınız tam da sıralamalarınızın en kırılgan olduğu anda bozulur.

URL değişikliğiyle birlikte altyapı geçişi

Buradaki tuzak, platformların kendi URL kurallarını dayatmasıdır: zorunlu /urun/ önekleri, farklı eğik çizgi davranışı, otomatik etiket arşivleri. Yeni platformun ne üreteceğini URL haritasını çıkarmadan önce öğrenin, sonra değil. Ayrıca platformun neyi elinizden aldığına bakın: birçok hazır e-ticaret sistemi robots.txt, canonical ya da şema kontrolünü sınırlar; bu kısıtı, hâlâ etrafından dolaşacak tasarım yapabilecekken bilmelisiniz.

URL’ler değişmeden yapılan tasarım yenilemesi

Yönlendirme gerekmediği için kontrol listesi bütünüyle atlanır — ve sıralamalar yine de düşer; çünkü yeni şablonlar metni kırpmış, başlıkları kaybetmiş, şemayı düşürmüş ya da siteyi yavaşlatmıştır. URL’lere hiç dokunulmasa bile 1. Aşama ölçümünü ve 3. Aşama sayfa içi karşılaştırmasını yapın. Öncesi ve sonrası için Hepsi Bir Arada SEO Denetimi çalıştırmak, URL başına karşılaştırılabilir tek bir puan verir.

Alt alan adından alt klasöre geçiş

blog.ornek.com adresini ornek.com/blog/ adresine almak gerçek bir taşımadır ve gerçek bir kazanç sunar: içerik, ana alan adının otoritesinin yanında durmak yerine onun parçası hâline gelir. İlgili bölüm için tam anlamıyla bir alan adı değişikliği gibi davranın — eksiksiz URL haritası, her yazı için 301, güncellenmiş iç bağlantılar ve her iki taraf için Search Console mülkü.

Birden fazla siteyi birleştirme

İki ya da üç siteyi tek çatı altında toplamak her riski katlar: artık birbiriyle yarışan örtüşen içerikler, iki ayrı backlink kümesi, iki ayrı tarama geçmişi. Her kaynak siteyi ayrı haritalayın, mükerrer konuları yayından sonra değil önce tek bir asıl sayfada birleştirin ve mümkünse taşımaları teker teker yapın; böylece hangi değişikliğin hangi sonucu doğurduğunu her zaman bilirsiniz.

E-ticaret taşımaları

Online mağazalar, başka hiçbir site tipinde olmayan bir sorun kümesi taşır ve bunlar plana ayrı satır olarak yazılmayı hak eder. Ürünler taşıma sürerken stoktan düşer ya da üretimden kalkar; on binlerce ürünü olan bir mağazada, haritayı yazarken karşılığı henüz var olmayan eski ürün URL’leri her zaman çıkar. Bu yüzden kuralı önceden belirleyin (önce yerine geçen ürün, sonra üst kategori, sonra 410) — ürün başına doğaçlama yapmayın. Varyant URL’leri sorunu katlar: renk ve beden seçenekleri kendi adreslerini üretiyorsa hepsinin ya haritalanması ya da birleştirilmesi gerekir; bu karar da doğrudan filtreli navigasyon ve kategori sayfalarınızın üzerine binen filtre parametreleriyle iç içedir.

URL’lerin ötesinde, altyapı değişiminde rutin olarak üç şey bozulur ve hiçbiri yönlendirme testinde görünmez. Birincisi ürün şeması: fiyat, stok durumu, para birimi, SKU ve değerlendirme işaretlemesi zengin sonuçları besleyen unsurlardır ve yeni temalar sıklıkla eksik ya da geçersiz işaretlemeyle gelir — her ürün şablonunu yayından sonra değil önce Yapısal Veri (Schema) Kontrolü ile doğrulayın. İkincisi ürün akışları: Merchant Center ile pazaryeri ve iş ortağı akışlarınız eski URL’leri gösterir; siteyle birlikte güncellemezseniz alışveriş kayıtlarınız yayından günler sonra reddedilmeye başlar. Üçüncüsü değerlendirme içeriği — puanlar ve yorumlar çoğu zaman eski platformun veritabanında kalır ve sessizce geride bırakılır; giderken hem sayfa içeriğini hem de arama sonuçlarındaki yıldızları beraberinde götürür. Geçişten önce dışa aktarın ve yeni ürün sayfalarında göründüklerini doğrulayın.

Taşıma felaketlerinin ardındaki hatalar

  • Her şeyi ana sayfaya yönlendirmek. Uygulaması hızlı, yumuşak 404 sayılıyor, neredeyse hiçbir şey aktarmıyor. Bu rehberden tek bir şey alacaksanız bunu alın.
  • URL haritası olmadan yayına çıkmak. “404 veren ne varsa sonra yönlendirme ekleriz” demek, kayıplarınızı iki hafta sonra trafik grafiğinden öğrenmek demektir — Google o URL’leri çoktan düşürmüşken.
  • Test ortamının noindex ya da Disallow satırını canlıya taşımak. Beş dakikalık bir düzeltmenin, hayatta kaldığı her gün için servete mal olması. Yayından sonraki ilk on dakikada kontrol edin, ertesi gün bir daha edin.
  • HTML dışı dosyaları unutmak. PDF’ler, görseller ve beslemeler zamanla bağlantı ve trafik biriktirir. Onların da haritalanması gerekir.
  • Eski alan adının süresini doldurmaya bırakmak. Yönlendirmeleriniz durur, backlink değeriniz yok olur ve alan adını bir rakip ya da spam yayıncısı satın alabilir. Süresiz yenileyin.
  • Sezonun zirvesinde taşımak. İyi bir taşıma bile düşüş yaşatır. Bu düşüşü en yüksek cirolu haftalarınızın üstüne planlamayın.
  • İkinci hafta panik yapmak. Google tam yeniden işleme yaparken yönlendirmeleri söküp içeriği baştan yazmak, birinci taşımanın üstüne ikinci bir taşıma bindirir. Önce veriyle teşhis edin, sonra müdahale edin.
  • Her şeyi aynı anda değiştirmek. Yeni alan adı, yeni platform, yeni URL yapısı, yeni tasarım ve yeni içeriği tek sürüme sığdırmak, bir düşüşü herhangi bir sebebe bağlamayı imkânsız kılar. Yapabiliyorsanız değişiklikleri farklı sürümlere bölün.

Toparlanma ne kadar sürer?

Birkaç yüz URL’lik küçük bir sitede, temiz bir haritayla Google yönlendirmelerin çoğunu genelde bir ila üç hafta içinde işler ve trafik iki ila dört haftada eski seviyesine döner. On binlerce URL’si olan büyük bir sitede tam yeniden işleme altı ila on iki hafta, kimi zaman daha uzun sürer; çünkü Google, yönlendirmeyi görmek için her eski URL’yi yeniden taramak zorundadır ve bunu sitenizin normal tarama hızında yapar — taşıma sırasında tarama bütçesinin ve sağlıklı bir iç bağlantı yapısının önemi tam olarak buradan gelir.

İki noktada beklentiyi doğru kurmakta fayda var. Birincisi, taşımanın kendisi bir siteyi daha iyi sıralatmaz; sonrasında trafik eski seviyenin üzerine çıkıyorsa bunun sebebi yeni sitenin daha hızlı, daha iyi yapılandırılmış veya daha iyi yazılmış olmasıdır, taşımanın ödüllendirilmesi değil. İkincisi, taşıma dönemi SEO performansını genel olarak yargılamak için kötü bir andır — algoritma güncellemeleri, mevsimsellik ve rakip hareketleri kendi seyrinde devam eder. Dönemleri benzeriyle karşılaştırın ve tablonun netleşmesinin, normal SEO zaman çizelgeleriyle uyumlu şekilde birkaç ay alacağını hesaba katın.

Geri dönüş planınız olsun

Yayından önce, sizi geri dönmeye ne ikna edeceğine karar verin ve geri dönmenin gerçekten mümkün olduğundan emin olun. Pratikte bu şu demek: eski sitenin dosya ve veritabanının tam yedeği, açık ve ödemesi yapılmış eski hosting, geçişten önce düşürülmüş DNS TTL değeri ve düğmeye basacak yetkiye ve erişime sahip, adı belli bir kişi.

Geri dönüşü yalnızca hızlıca düzeltilemeyen felaket durumları için kullanın — site tamamen kapalıysa, ödeme adımı çalışmıyorsa, alan adı genelinde 500 dönüyorsa. İlk haftadaki normal bir trafik düşüşü ya da birkaç eksik yönlendirme için geri dönmeyin: geri dönmek başlı başına yeni bir taşımadır ve iki hafta içinde iki taşıma yapmak, hatalı yönlendirmeleri düzeltmekten çok daha fazla zarar verir.

Eksiksiz taşıma kontrol listesi

Öncesinde:

  • Eski sitenin tam taraması dışa aktarıldı; loglardan ve site haritasından öksüz sayfalar da eklendi.
  • 16 aylık Search Console sayfa ve sorgu verisi ile 12 aylık analitik açılış sayfası verisi indirildi.
  • Sıralama fotoğrafı tarihiyle birlikte kaydedildi.
  • Backlinkler, her biri için hedef URL bilgisiyle dışa aktarıldı.
  • Hız, şema, başlıklar ve dizine eklenmiş sayfa sayısı referansları saklandı.
  • URL haritası tamamlandı: her eski URL’nin bir hedefi ve bir yönlendirme tipi var.
  • HTML dışı dosyalar, beslemeler, sayfalanmış ve parametreli URL’ler haritaya dâhil edildi.
  • Önceki taşımalardan kalan yönlendirme zincirleri düzleştirildi.
  • Test ortamı şifreyle korundu; yayın listesinin ilk maddesi noindex’i kaldırmak.
  • Önemli her şablonda sayfa içi sinyaller eski-yeni karşılaştırıldı.
  • Yeni site haritası, robots.txt, analitik, Search Console mülkü ve SSL hazır.
  • DNS TTL düşürüldü; yedekler alındı; geri dönüş planı üzerinde uzlaşıldı.

Yayın günü:

  • Düşük trafikli bir gün, geliştiriciler ulaşılabilir, tatil veya sezon zirvesi öncesi değil.
  • noindex etiketleri ve test ortamı robots.txt kuralları kaldırıldı; ham HTML üzerinden doğrulandı.
  • Yönlendirmeler yeni siteyle aynı sürümde canlıda.
  • Trafiğe göre ilk 50 URL elle doğrulandı: tek 301, doğru hedef, sonda 200.
  • Her alan adında HTTPS geçerli.
  • Yeni site haritası gönderildi; eski site haritası erişilebilir bırakıldı.
  • Alan adı değiştiyse Adres Değişikliği bildirimi yapıldı.
  • Analitik veri alıyor; yeni sitenin tam taraması başlatıldı.

Sonrasında:

  • 48 saat içinde eski URL listesinin tamamı tarandı ve her yanıt kontrol edildi.
  • Site içi 404’ler ve kırık bağlantılar düzeltildi.
  • Kritik sayfaların dizine eklenebilirliği URL İnceleme ile doğrulandı.
  • İlk iki hafta kapsam, tarama istatistikleri ve sunucu logları günlük izlendi.
  • İç bağlantılar, canonical’lar, site haritaları ve hreflang nihai URL’lere güncellendi.
  • En değerli bağlantı veren sitelere güncelleme talebi gönderildi.
  • Sıralamalar haftalık olarak kayıtla karşılaştırıldı; dördüncü haftada tam denetim tekrarlandı.
  • Yönlendirmeler ve eski alan adı en az bir yıl açık tutuldu.

Taşımaların felaket namı, hasarın büyük bölümünün kimsenin göremediği bir anda — yayından haftalar önce, planlama aşamasında — oluşmasından geliyor. Süreçten temiz çıkan siteler nadiren en iyi geliştiricilere sahip olanlardır; ölçüm alan, eksiksiz bir URL haritası çıkaran ve yayından sonraki 48 saat içinde her varsayımını kontrol eden sitelerdir. Bu üçünü yaparsanız taşıma, olması gerektiği şeye dönüşür: kısa bir düşüş, hızlı bir toparlanma ve diğer tarafta daha iyi bir site. Kontrolleri düzenli teknik SEO denetim rutininize ekleyin ki yeni site, yayına girdiği günkü kadar sağlıklı kalsın.

Sık sorulan sorular

Site taşırken ne kadar trafik kaybederim?

İyi yürütülmüş bir taşımada trafik iki ila dört hafta boyunca genelde %5–20 geriler, sonra eski seviyesine ya da üzerine döner. Kötü yürütülmüş bir taşımada — eksik yönlendirmeler, ana sayfaya toplu yönlendirme, engellenmiş dizinleme — kayıp %40–70’e çıkabilir ve toparlanma altı ayı veya daha fazlasını bulur. Düşüşün büyüklüğünü neredeyse tamamen URL haritanızın eksiksizliği ve yönlendirmelerinizin isabeti belirler.

Yönlendirmeleri taşımadan sonra ne kadar süre tutmalıyım?

En az bir yıl; bu Google’ın kendi tavsiyesi. Pratikte kalıcı tutun: sunmanın maliyeti yok ve hâlâ dış bağlantı alan her eski URL, o yönlendirme üzerinden değer aktarmaya devam ediyor. Bir yönlendirmeyi yalnızca eski URL’ye kimsenin bağlantı vermediğinden ve kimsenin onu istemediğinden eminseniz kaldırın.

Taşımada 301 mi 302 mi kullanmalıyım?

Taşımadaki her yönlendirme için 301 (kalıcı). 302, eski URL’nin geri döneceği sinyalini verir; arama motorları eski adresi dizinde tutmayı sürdürebilir ve sinyalleri yeni adreste birleştirmeyi geciktirebilir. 302’yi yalnızca kısa bakım pencereleri ya da A/B testleri gibi gerçekten geçici durumlarda kullanın.

Eski URL’leri ana sayfaya yönlendirebilir miyim?

Yalnızca trafiği, backlinki ve alakalı karşılığı olmayan URL’ler için — o durumda bile çoğu zaman 410 daha doğrudur. Google, alakasız bir sayfaya yapılan toplu yönlendirmeleri yumuşak 404 sayar; sıralama ve bağlantı değeri aktarılmaz. Bunun yerine her zaman en yakın alakalı sayfaya yönlendirin.

Taşımadan sonra yeni bir Search Console mülkü gerekir mi?

Alan adı, protokol veya alt alan adı değiştiyse evet. Search Console http://, https://, www ve www’siz sürümleri ayrı mülkler olarak görür (Domain tipi mülk, bir alan adının protokol ve alt alan adı varyantlarını birlikte kapsar). Yeni mülkü yayından önce doğrulayın, eski URL taramasını izlemek için eskisini de tutun ve alan adı değiştiyse Adres Değişikliği bildirimini gönderin.

URL’leri değiştirmeyen bir tasarım yenilemesi de taşıma sayılır mı?

Evet ve en sık yanlış yönetilen tür budur. Yönlendirme gerekmez; ama yeni şablonlar rutin olarak gövde metnini kırpar, başlıkları ve title’ları değiştirir, alt metinleri ve yapısal veriyi düşürür ve siteyi yavaşlatır — bunların hepsi sıralamayı oynatır. Aynı ölçümü alın ve yayından önce sayfa içi sinyalleri eski-yeni karşılaştırın.

Hem alan adını hem altyapıyı değiştireceksem en güvenli sıra nedir?

İkisini ayırın. Önce mevcut alan adı üzerinde yeni altyapıya geçin, toparlanmayı doğrulayın; sonra URL yapısını sabit tutarak alan adını değiştirin. İkisini aynı anda yaparsanız trafik düştüğünde sebebin yönlendirmeler mi, şablonlar mı, yoksa yeni URL kalıpları mı olduğunu ayırt edemezsiniz — ve işin büyük kısmı teşhistir.