300'den Fazla URL İçeren Çok Dilli SEO Taşıması Kontrol Kaybetmeden Nasıl Planlanır?

Web sitesi taşımaları çoğu zaman ekibin yönlendirme diye bir şey olduğunu unutması nedeniyle başarısız olmaz. Asıl sorun, değişen her şeyin eksiksiz bir modelinin hiç oluşturulmamasıdır.

Olgun bir çok dilli sitede güncel URL'ler, tarihî URL'ler, alt alan adları, eski alan adları, parametreli varyasyonlar, PDF'ler, görseller, çevrilmiş sayfalar, yetim sayfalar ve kimsenin hatırlamadığı hâlde trafik almaya devam eden bağlantılar bulunabilir. Tasarım, yazılım altyapısı, alan adı ve dil yapısı aynı anda değişiyorsa “eski sayfa → yeni sayfa” biçimindeki basit bir tablo yeterli değildir.

Bu yazı, bir B2B üretici için yürütülen anonimleştirilmiş lansman öncesi planlama vakasını anlatıyor. Canlı ve tarihî kaynaklar birleştirildiğinde aday URL envanterinin 300'ü aşması bekleniyordu. Projede uzun geçmişe sahip ülke uzantılı bir site, planlanan global alan adı, ayrı dil varlıkları ve eksik analitik erişimi bulunuyordu.

Açıklama: Bu bir planlama vaka çalışmasıdır; önce/sonra performans hikâyesi değildir. Yazının hazırlandığı tarihte taşıma henüz canlıya alınmamıştı. Sıralama, trafik veya gelir sonucu iddia edilmez. Burada gösterilen değer; risk kontrolü, kanıt kalitesi ve yayın planıdır.

Başlangıç durumu

Şirket, parçalı uluslararası varlığını daha anlaşılır bir global mimaride birleştirmek istiyordu. Eski yapı şu riskleri taşıyordu:

• arama geçmişi ve mevcut değeri olan yerel alan adı;
• birden fazla açık alan adı veya dil varlığı;
• güncel navigasyonda görünmeyen tarihî URL'ler;
• farklı hostlar üzerine dağılmış diller;
• ana varlık dışındaki Search Console erişimlerinin sınırlı olması;
• güvenilir GA4 başlangıç verisinin bulunmaması;
• ürün, kategori, sektör ve teknik içerik niyetlerinin çakışması;
• yönetimin görünürlüğü kaybetmeden siteyi sadeleştirme beklentisi.

Görünen web sitesi, taşıma yüzeyinin yalnızca bir parçasıydı. Gerçek proje; arama motorlarının, kullanıcıların ve dış bağlantıların hâlâ isteyebileceği her şeyin birleşimiydi.

Neden “mevcut siteyi tara ve yönlendir” yaklaşımı yeterli değildi?

Güncel tarama şu soruyu yanıtlar: Bir tarayıcı bugün hangi sayfalara ulaşabiliyor? Ancak şu soruları tam olarak cevaplamaz:

• Hangi eski URL'ler hâlâ bağlantı veya gösterim alıyor?
• Hangi sayfalar yetim kaldı?
• Navigasyondan kaldırıldığı hâlde dizinde bulunan URL'ler hangileri?
• Hangi PDF ve görseller arama keşfi sağlıyor?
• Bir dil sayfasının gerçek karşılığı hangisi?
• Hangi kopyalar birleşmeli, hangi arama niyeti yeni sayfayı hak ediyor?
• Hangi sayfaların en başta bağımsız URL olmaması gerekiyordu?

Bu nedenle taşıma planlaması yeni menüyle değil, kanıt kaynaklarıyla başladı.

Aşama 1: Adli nitelikte URL envanteri oluşturmak

Tek bir ana matris tanımlandı. Her satır yalnızca bir menü öğesini değil, mevcut, tarihî veya önerilen bir URL'yi temsil etti.

Kanıt kaynakları

• erişilebilen her host için tam tarama;
• XML site haritaları ve site haritası dizinleri;
• erişilebilen varlıkların Search Console sayfa ve performans dışa aktarımları;
• güvenilir erişimin bulunduğu analitik verileri;
• backlink ve yönlendiren sayfa raporları;
• mümkün olduğunda sunucu/CDN logları;
• tarihî web arşivleri;
• CMS veya veritabanı dışa aktarımları;
• ürün modelleri, sektörler ve dilleri listeleyen şirket içi belgeler;
• navigasyon, footer, site içi arama ve filtreli rotalardan elde edilen manuel bulgular.

Temel alanlar

Matris bir rapor süsü değil, kontrol sistemiydi. Karar verilmemiş her URL açık risk olarak kaldı.

Aşama 2: Yönlendirmelerden önce hedef mimariye karar vermek

Yönlendirmeler, karışık hedef mimariyi telafi edemez. Önce birbirine karışan dört kavram ayrıldı:

1. Ürün/kategori: Şirket ne sunuyor?
2. Model/özellik: Üründeki ayrım bağımsız landing page gerektiriyor mu?
3. Sektör/kullanım: Çözüm nerede ve neden kullanılıyor?
4. Dil/pazar: İçerik kime ve hangi yerel bağlamda sunuluyor?

Hedef model, global alan adı altında kararlı dil alt dizinlerini tercih etti. Her dil kendi URL'lerine sahipti. Bu yapı, aynı içeriği ilgisiz hostlara dağıtmaya kıyasla yönetim, analitik, iç bağlantı ve dil ilişkilerini daha kolay kontrol etmeyi sağladı.

Bu, alt dizinin her proje için doğru olduğu anlamına gelmez. Karar; marka, tüzel yapı, operasyon, pazar bağımsızlığı ve mevcut arama değerine bağlıdır. Önemli olan tercihlerin gerekçesini belgelemek ve tutarlı uygulamaktır.

Aşama 3: Sayfa düzeyinde niyet kuralları oluşturmak

Yalnızca başlığa bakarak eşleme yapmak sessiz hatalara neden olur. İki URL benzer görünebilir, fakat farklı arama niyetine hizmet edebilir.

Her kaynak URL şu sınıflardan birine alındı:

• Koru: Niyet ve içerik geçerliliğini korur.
• Geliştir: URL kalır, içerik veya yapı güçlendirilir.
• Birleştir: Aynı niyete hizmet eden birden fazla sayfa tek güçlü hedefte birleşir.
• Yönlendir: Eski konum gerçek eşdeğerine taşınır.
• 404/410 ile kaldır: İlgili karşılık yoktur ve yönlendirmek kullanıcıyı yanıltır.
• Araştır: Kanıt eksiktir veya paydaşlar aynı fikirde değildir.

Kaldırılan tüm sayfaları ana sayfaya yönlendirme kısa yolu reddedildi. Yönlendirme en yakın ve yararlı eşdeğere gitmelidir. Eşdeğer yoksa doğru 404 veya 410, yanıltıcı soft 404'ten daha iyidir.

Aşama 4: Yönlendirme matrisini kurmak

Taşınan her URL için şu alanlar zorunluydu:

• tam kaynak URL;
• tam hedef URL;
• tek adımlı kalıcı yönlendirme;
• eşlemenin gerekçesi;
• içerik eşdeğerliği kontrolü;
• sorumlu;
• uygulama durumu;
• lansman öncesi test;
• lansman sonrası test.

Yönlendirme kalite kuralları

• zincir yok;
• döngü yok;
• toplu ana sayfa yönlendirmesi yok;
• anlamlı derin hedefleri koru;
• protokol, hostname ve slash davranışını standartlaştır;
• site içi bağlantıları güncelle, içeride yönlendirmeye güvenme;
• eski bağlantılar istenmeye devam ettiği sürece yönlendirmeleri koru;
• parametre davranışını ayrıca test et.

Google, kalıcı URL değişikliklerinde sunucu taraflı kalıcı yönlendirmeleri öneriyor ve taşıma sırasında URL'ler yeniden taranıp dizine eklenirken geçici sıralama dalgalanmaları yaşanabileceğini belirtiyor.

Aşama 5: Canonical ve hreflang'ı birlikte tasarlamak

Çok dilli taşımalarda canonical ve hreflang'ın çelişkili sinyaller vermesi sık görülür.

Kurallar netti:

• her İngilizce sayfa İngilizce URL'sine canonical verir;
• her Türkçe sayfa Türkçe URL'sine canonical verir;
• her çift karşılıklı hreflang ile birbirini gösterir;
• x-default belirlenen global/varsayılan sürüme gider;
• hreflang yalnızca yönlendirme veya hata vermeyen nihai 200 canonical URL'lere işaret eder;
• gerçek karşılığı olmayan sayfalara yapay eşleşme eklenmez;
• site haritası ve iç bağlantılar aynı canonical hedefleri kullanır.

Canonical, kopyalar arasındaki tercih edilen URL'yi belirtir. Hreflang, doğru yerel sürümün seçilmesine yardımcı olur. Farklı problemleri çözerler ve birbirleriyle uyumlu olmalıdırlar.

Aşama 6: Taşıma zorunluluklarını içerik hedeflerinden ayırmak

Bir taşımanın en riskli kararlarından biri her şeyi aynı anda değiştirmektir.

Proje üç katmana ayrıldı:

• zorunlu taşıma eşdeğerliği: Eski sitenin güvenli biçimde yerini alması için gereken temel içerik ve işlevler;
• lansman düzeltmeleri: Bilinen teknik veya içerik hatalarını taşımamak için gereken iyileştirmeler;
• lansman sonrası büyüme: Yeni landing page'ler, geniş içerik programları ve deneysel özellikler.

Bu ayrım değişken sayısını azalttı. Alan adı, tasarım, CMS, taksonomi, metin ve dil yapısını aynı anda değiştirmek mümkündür; fakat kayıp yaşandığında nedeni teşhis etmek çok daha zor olur.

Aşama 7: Yayın kapılarını tanımlamak

“Ana sayfa tamamlandı” taşımayı canlıya almak için yeterli değildi. Ölçülebilir kapılar gerekiyordu.

Lansman öncesi tarama kapısı

• hedeflenen tüm açık URL'ler beklenen durumu döndürür;
• hiçbir canlı sayfa yanlışlıkla noindex içermez;
• canonical üretim alan adını kullanır;
• hreflang karşılıklıdır;
• title, description ve H1 yerelleştirilmiştir;
• site haritasında yalnızca canonical ve dizine açık URL'ler bulunur;
• robots, site haritasını gösterir ve gerekli içeriği engellemez;
• yapılandırılmış veri geçerli ve gerçektir;
• iç bağlantılar doğrudan nihai URL'lere gider;
• eski-yeni yönlendirmelerin otomatik testleri geçer;
• mobil ve performans kontrolleri kabul edilen eşiği karşılar.

Lansman kapısı

• DNS/CDN/SSL ve origin sağlığı doğrulanır;
• yönlendirmeler geri alma planıyla dağıtılır;
• formlar ve kritik dönüşümler test edilir;
• izleme ve hata kaydı aktiftir;
• gerekli Search Console sahiplikleri hazırdır;
• yayın notu ve sorumlular kaydedilir.

Lansman sonrası kapı

• eski ve yeni URL setleri taranır;
• temsilî sayfalar URL Denetleme ile kontrol edilir;
• site haritası gönderilir;
• 404, 5xx, dizin, canonical seçimi ve hreflang izlenir;
• markasız gösterimler ve landing page'ler karşılaştırılır;
• yalnızca oturum değil, dönüşümler doğrulanır;
• dış bağlantıların doğru hedeflere ulaşmaya devam ettiği kontrol edilir.

Özellikle iddia etmediğimiz şeyler

Bu çalışmalar çoğu zaman yeterli süre geçmeden, hatta taşıma yapılmadan trafik grafiğiyle pazarlanır. Şunları iddia etmedik:

• hiç sıralama dalgalanması olmayacağını;
• her pozisyonun kesin korunacağını;
• bütün sinyallerin anında aktarılacağını;
• erişilemeyen analitik verilerinden sonuç çıkarılabileceğini;
• lansman öncesinde uluslararası büyümenin başarıldığını;
• tek başına bir tablonun taşımayı koruyacağını.

İyi planlama önlenebilir riski azaltır. Arama sisteminin her tepkisini kontrol edemez.

300 URL'den küçük veya büyük her siteye uyan dersler

Envanter, sayfa sayısından önemlidir

Üç eski alan adı ve zayıf kanıtı olan 50 URL'lik site, temiz 5.000 URL'lik platformdan daha riskli olabilir.

Dil eşdeğerliği içerik kararıdır

Hreflang, birbiriyle zayıf ilişkili iki sayfanın çeviri olduğuna karar veremez. Editör ve konu uzmanları gerçek eşdeğerliği doğrulamalıdır.

Matrisin sorumluları olmalıdır

Sorumlusu olmayan yönlendirme, çeviri veya doğrulama bir plan değil, nottur.

“Veri yok” bir risk durumudur

Analitik veya Search Console erişimi eksikse sınırı açıkça yazın ve alternatif kaynakları birleştirin. Eksik kanıtı özgüvenle doldurmayın.

Doğrulama aynı URL setini kullanmalıdır

Lansman öncesi envanter, lansman sonrası test paketine dönüşür. Araştırmayı kontrole çeviren süreklilik budur.

Sık sorulan sorular

Çok dilli site alt dizin, alt alan adı veya ülke alan adı mı kullanmalı?

Evrensel cevap yoktur. Alt dizinler ortak otorite ve yönetimi çoğunlukla kolaylaştırır. Alt alan adları operasyonel ayrışmayı destekleyebilir. Ülke alan adları güçlü coğrafi sinyal verir ancak bağımsız yönetim ister. Mevcut arama değeri, pazar bağımsızlığı, tüzel yapı ve kaynaklar kararı belirlemelidir.

Yönlendirmeler ne kadar süre açık kalmalı?

Kullanıcılar, arama motorları veya dış bağlantılar eski URL'leri isteyebildiği sürece kalıcı yönlendirmeleri koruyun. Kısa sürede kaldırmak yerine uzun vadeli tutmak daha güvenlidir.

Her eski URL bir yere yönlenmeli mi?

Hayır. Yalnızca ilgili karşılık varsa yönlendirin. Karşılığı olmayan kaldırılmış içerik doğru 404 veya 410 döndürmeli ve yararlı navigasyon sunmalıdır.

Analitik olmadan taşıma yapılabilir mi?

Yapılabilir; fakat ölçüm riski yüksektir. Mümkünse lansman öncesinde Search Console, dönüşüm takibi ve güvenilir başlangıç verisi kurun. Erişim eksikse performans sürekliliği iddia etmek yerine sınırlamayı belgeleyin.

Hreflang kopya içerik sorununu engeller mi?

Hreflang doğru yerel sürümün seçilmesine yardımcı olur. Doğru canonical, gerçek yerelleştirme, taranabilir bağlantılar ve tutarlı mimarinin yerini tutmaz.

Taşıma güveni izlenebilirlikten doğar

Güçlü taşıma planında incelemeyi yapan kişi herhangi bir eski URL'den başlayıp şunları cevaplayabilir: Bu sayfa neydi? Değeri kanıtlandı mı? Hangi karar verildi? Nereye gidecek? Değişikliğin sahibi kim? Nasıl test edilecek? Lansmandan sonra ne oldu?

Taşımanız birden fazla dil, alan adı, yazılım çatısı veya yüzlerce tarihî URL içeriyorsa yeni mimari kesinleşmeden önce site taşıma risk analizi isteyin. En ucuz düzeltme, dağıtımdan önce yakalanan yanlış yönlendirmedir.

Kaynaklar

• Google Search: URL değişiklikli site taşımaları
• Google Search: Yönlendirmeler ve Arama
• Google Search: Çok dilli ve çok bölgeli siteler
• Google Search: Yerelleştirilmiş sürümler ve hreflang
• Google Search: Canonicalization
• Google Search: Trafik düşüşlerini inceleme