Site taşıma SEO çalışması hangi değişiklikleri kapsar?

Site taşıma, yalnızca dosyaları yeni bir sunucuya kopyalamak değildir. HTTP adreslerini HTTPS'e geçirmek, alan adını değiştirmek, alt alan adlarını birleştirmek, kategori yapısını yenilemek veya eski parametreli adresleri okunabilir URL'lere dönüştürmek arama motorları açısından bir URL değişikliğidir. Her eski adresin yeni karşılığının keşfedilmesi, taranması ve yeniden değerlendirilmesi gerekir. Yalnızca barındırma altyapısı değişiyor ve URL'ler aynı kalıyorsa süreç farklıdır; buna rağmen durum kodları, DNS, performans, erişilebilirlik ve sunucu yanıtları yine denetlenmelidir.

Taşınma öncesinde kapsamı tek cümleyle tanımlayın: hangi alan adları, protokoller, dizinler, diller, dosyalar ve kampanya sayfaları değişecek? Google Search Central, alan adı değişikliği, HTTP'den HTTPS'e geçiş ve URL yolu değişikliklerini aynı site taşıma çerçevesinde ele alır. Ayrıca mümkünse alan adı, içerik yönetim sistemi ve tasarım değişikliklerinin aynı anda yapılmamasını önerir. Değişkenleri ayırmak, görünürlükteki bir dalgalanmanın nedenini bulmayı ve gerektiğinde geri dönüş planını çalıştırmayı kolaylaştırır.

Taşınmadan önce ölçülebilir bir URL envanteri çıkarın

İyi bir taşıma planının merkezi eski URL envanteridir. XML site haritası, içerik yönetim sistemi, analitik raporları, sunucu günlükleri, Search Console bağlantı verileri ve ücretli kampanyalarda kullanılan açılış sayfaları birlikte incelenmelidir. Yalnızca organik trafik alan HTML sayfalarını değil; görselleri, PDF dosyalarını, video adreslerini, dil sürümlerini ve dış bağlantı alan eski içerikleri de listeye ekleyin. Her satırda eski URL, planlanan yeni URL, içerik türü, mevcut durum kodu, organik önem ve uygulama notu bulunsun.

Envanter tamamlandığında yeni sitedeki her önemli sayfanın 200 durumuyla açıldığını ve taşıdığı içeriğin eski sayfanın arama niyetini karşıladığını kontrol edin. Aynı konu altında birleşen birkaç eski sayfa gerçekten daha kapsamlı tek bir kaynağa taşınabilir; ancak ilgisiz yüzlerce adresi ana sayfaya yönlendirmek doğru değildir. Google, alakasız toplu yönlendirmelerin kullanıcıyı şaşırtabileceğini ve soft 404 olarak değerlendirilebileceğini belirtir. Yeni karşılığı olmayan içerik 404 veya 410 vermeli; silinmiş bir URL sırf hata görünmesin diye ilgisiz sayfaya gönderilmemelidir.

Eski ve yeni URL'ler arasında bire bir yönlendirme haritası kurun

Her eski URL'yi en yakın yeni karşılığıyla eşleştirin ve bu tabloyu geliştirme ekibinin kullanacağı tek kaynak hâline getirin. Kalıcı taşınmalarda sunucu tarafında 301 veya 308 yönlendirmesi tercih edilir. Yönlendirme doğrudan son adrese gitmelidir; eski URL'den geçici bir ara adrese, oradan başka bir adrese uzanan zincirler kullanıcı gecikmesini ve hata ihtimalini artırır. Aynı şekilde A adresinin B'ye, B'nin yeniden A'ya dönmesi gibi döngüler hem ziyaretçiyi hem tarayıcıyı çıkmaza sokar.

Yönlendirmeleri yalnızca birkaç örnek üzerinde değil, envanterin tamamında test edin. Eski adresin beklenen kalıcı durum kodunu verdiğini, Location başlığının doğru HTTPS URL'ye gittiğini, nihai sayfanın 200 döndürdüğünü ve zincir oluşmadığını kaydedin. Büyük sitelerde kurallar desen tabanlı yazılabilir; yine de özel karakterler, büyük-küçük harf, son eğik çizgi, sorgu parametresi ve dil klasörleri ayrı örneklerle doğrulanmalıdır. İstemci tarafı JavaScript yönlendirmesi, sunucu yönlendirmesi teknik olarak mümkün değilse son seçenek olmalıdır.

Canonical, hreflang ve dahili bağlantıları yeni adreslere çevirin

Yönlendirme tek başına yeterli değildir. Yeni sayfaların canonical etiketi kendi yeni ve nihai URL'sini göstermelidir. Eski alan adına işaret eden canonical, yönlendirmeyle çelişir ve arama motoruna hangi adresin temsilci olduğu konusunda karışık sinyal verir. Çok dilli sitelerde hreflang kümelerindeki tüm karşılıklar yeni URL'lerle güncellenmeli; her dil sayfası karşılıklı ve erişilebilir olmalıdır. OpenGraph adresleri, yapılandırılmış verideki URL ve görsel alanları, pagination bağlantıları ve varsa RSS ya da JSON yayın akışları da aynı envantere göre değiştirilmelidir.

Menü, breadcrumb, içerik içi bağlantı, logo, footer ve ilişkili içerik kartları doğrudan yeni URL'lere gitmelidir. Kendi sitenizde eski adrese bağlantı verip kullanıcıyı yönlendirmeden geçirmek gereksiz sunucu yükü ve gecikme oluşturur. Önce en çok ziyaret edilen şablonları, sonra bütün içerik gövdesini tarayın. Reklamlar, e-posta şablonları, sosyal profil bağlantıları, QR kodlar ve yüksek trafik getiren dış bağlantılar için de güncelleme listesi hazırlayın. Dış sitelerdeki her bağlantı değiştirilemese bile önemli yayıncılardan yeni adresi kullanmalarını istemek kullanıcı yolculuğunu kısaltır.

Robots, noindex ve sitemap sinyallerini yayından önce doğrulayın

Geliştirme ortamını arama motorlarından uzak tutmak için kullanılan robots.txt engeli veya noindex etiketi canlıya taşınırsa yeni site keşfedilemeyebilir. Yayın kontrolünde ana sayfa, kategori, içerik, ürün veya hizmet ve dil şablonlarından temsilî URL'ler seçin. Bu adreslerin 200 döndürdüğünü, robots.txt tarafından engellenmediğini, index/follow davranışı taşıdığını ve HTML kaynağında doğru canonical bulunduğunu doğrulayın. CSS, JavaScript ve kritik görsel kaynaklarının yanlışlıkla engellenmesi de render ve değerlendirme sorunlarına yol açabilir.

Yeni XML site haritası yalnızca canonical, indekslenebilir ve nihai yeni URL'leri içermelidir. Google, yeni site haritasının gönderilmesinin URL'lerin keşfini hızlandırmaya yardımcı olabileceğini açıklar; ancak site haritası yönlendirmenin veya doğru dahili bağlantıların yerine geçmez. Robots.txt içinde yeni sitemap adresini belirtin, Search Console'da gönderin ve işlenme durumunu izleyin. Taşıma sırasında eski URL'leri ayrı bir sitemap dosyasında geçici olarak izlemek, eski adreslerin taranıp yeni hedeflere aktarılıp aktarılmadığını karşılaştırmayı kolaylaştırabilir.

Yayın anını teknik kabul testiyle yönetin

Canlıya geçişten önce düşük trafik dönemini seçmek, DNS ve sertifika hazırlığını tamamlamak ve sorumlu kişileri belirlemek riski azaltır. Önce yeni ortamın TLS sertifikasını, alan adı varyantlarını, www ve apex davranışını, mobil görünümü, formları, analitik etiketlerini ve hata sayfalarını kontrol edin. Ardından yönlendirmeleri etkinleştirin ve örnek değil tam URL listesi üzerinden otomatik durum kodu testi çalıştırın. Kritik sayfaların sunucudan okunabilir HTML sunduğunu; başlık, açıklama, H1, canonical, ana metin ve bağlantıların ilk yanıtta yer aldığını doğrulayın.

Yeni alan adı kullanılıyorsa eski ve yeni mülklerin Search Console doğrulamalarını koruyun. Google'ın Adres Değişikliği aracı, alan adı taşıma senaryolarında uygun mülkler için kullanılabilir; yalnızca HTTP'den HTTPS'e geçişte bu araç gerekmez. Yeni site haritasını gönderin ve URL Denetleme ile kritik sayfalardan örnekler kontrol edin. Yayın kontrol listesi tek kişinin hafızasına bağlı kalmamalı; SEO, geliştirme, içerik, analitik ve reklam ekiplerinin imzaladığı ortak bir kabul kaydı olmalıdır.

Taşıma sonrasında hangi sinyaller izlenmelidir?

İlk saatlerde 5xx hataları, TLS sorunları, yönlendirme döngüleri, yanlış host davranışı ve form hataları izlenmelidir. Sonraki günlerde sunucu günlüklerinde arama motoru taraması, eski URL istekleri, beklenmeyen 404'ler ve yeni adreslerin yanıt süreleri takip edilir. Search Console'da sayfa indeksleme, site haritası, tarama istatistikleri, performans sorguları ve seçilen canonical sinyalleri karşılaştırılır. Analitikte organik oturum, önemli açılış sayfaları ve dönüşüm olayları eski ve yeni URL eşlemesi üzerinden değerlendirilir.

Geçici görünürlük dalgalanması her zaman teknik hata anlamına gelmez; arama sistemlerinin eski ve yeni adresleri yeniden taraması zaman alabilir. Buna karşılık önemli bir sayfanın günlerce 404 vermesi, canonical'ın eski alan adında kalması veya yönlendirmelerin ana sayfaya yığılması beklenmemelidir. Google, kalıcı yönlendirmelerin genel olarak en az bir yıl korunmasını; kullanıcı açısından mümkünse daha uzun süre açık tutulmasını önerir. İzleme eşiği önceden tanımlanırsa ekip normal geçiş süreciyle acil müdahale gerektiren hatayı ayırabilir.

Başarılı site taşımanın özeti: tutarlı sinyaller ve sabırlı izleme

Site taşıma SEO'su tek bir ayar değil, eski ve yeni adresler arasındaki bütün sinyallerin tutarlı hâle getirilmesidir. Bire bir URL haritası, doğrudan kalıcı yönlendirme, kendine referans veren canonical, güncel dahili bağlantılar, indekslenebilir sunucu HTML'i ve yeni sitemap aynı hedefi göstermelidir. İçerik eşdeğerliği, kullanıcı deneyimi ve sunucu kapasitesi teknik işaretler kadar önemlidir. Taşınma sırasında kesin sıralama veya süre garantisi verilemez; amaç keşfi kolaylaştırmak, hataları hızla görmek ve gereksiz görünürlük kaybı riskini azaltmaktır.

Fırat Averbek’in ileri düzey SEO yaklaşımı, taşıma kararını yayından sonra yapılan bir kontrol değil, ürün ve yayın planının parçası olarak ele alır. Her URL için sahip, hedef, test sonucu ve izleme durumu kaydedildiğinde ekipler sorunları tahminle değil kanıtla yönetebilir. Fırat Averbek imzasıyla hazırlanan bu rehberin temel ilkesi açıktır: önce envanteri çıkarın, sonra sinyalleri aynı yeni adreste birleştirin ve geçiş tamamlanana kadar eski ile yeni sistemi birlikte ölçün.

İlgili Fırat Averbek kaynakları

Fırat Averbek ileri düzey SEO hizmeti: URL envanteri, teknik taşıma planı ve yayın sonrası indeksleme kontrollerini birlikte yönetin.

JavaScript SEO ve indeksleme rehberi: Yeni altyapının sunucu HTML'i ve render sinyallerini nasıl doğrulayacağınızı inceleyin.

Çok dilli SEO ve hreflang rehberi: Dil URL'leri taşınırken canonical ve hreflang kümelerini tutarlı kurun.

Resmî kaynaklar

Bu rehber hazırlanırken aşağıdaki resmî ve birincil kaynaklar makalenin yayın veya son güncelleme tarihinde kontrol edilmiştir.

Sık sorulan sorular

Bu rehber hangi standarda göre hazırlanmıştır?

Metin; doğrulanabilir kaynak, açık yöntem, insan editoryal incelemesi ve yanıltıcı sonuç garantilerinden kaçınma ilkeleriyle hazırlanmıştır.

Bilgiler uygulama kararı için tek başına yeterli mi?

Hayır. Teknik, hukuki veya ticari kararlar güncel koşullar ve yetkili uzman görüşüyle doğrulanmalıdır.