Site taşıma veya yeniden tasarımda SEO kaybı nasıl önlenir? Kontrol listesi

Site taşıma veya yeniden tasarımda SEO kaybını önlemek için taşımadan önce siteyi tarayıp tüm URL'leri ve performans verisini kaydetmeniz, eski ve yeni adresler arasında bire bir 301 eşlemesi kurmanız, canonical, sitemap ve robots ayarlarını doğrulamanız, lansmandan sonra da birkaç hafta boyunca Search Console'da izlemeniz gerekir.

Yeniden tasarım ve taşıma projeleri çoğu zaman görsel ve işlevsel hedeflerle başlar; SEO ise son haftada akla gelir. Oysa trafiğin düşmesinin en sık nedenleri tasarımla ilgili değil, teknik ayrıntılardır: eksik yönlendirme, yanlışlıkla açık kalan noindex, değişen URL'ler, kaybolan içerik ve bozulan iç linkler. Dürüst bir uyarı: Doğru yapılsa bile geçici dalgalanma görülebilir ve hiçbir kontrol listesi trafiğin aynı kalacağını garanti etmez. Amaç kaybı en aza indirmek ve neyin neden olduğunu hızla anlayabilmektir.

Taşıma ve yeniden tasarım türleri nelerdir ve her birinin riski nedir?

Dört temel taşıma türü vardır: alan adı değişikliği, CMS veya altyapı değişikliği, URL yapısı değişikliği ve http'den https'e geçiş. Bunlar bir arada da yapılabilir. Ne kadar çok şey aynı anda değişirse risk ve sorun kaynağı o kadar artar; mümkünse aşamalara bölmek tanı ve düzeltmeyi kolaylaştırır.

• —Alan adı değişikliği: tüm sayfaların yeni alan adına taşınması; en yüksek risk, tüm sinyallerin yeni alan adına aktarılması gerekir.
• —CMS veya altyapı değişikliği: aynı alan adı ve URL, farklı sistem; risk, şablonun meta etiketleri, yapılandırılmış veriyi veya içeriği farklı üretmesi ve hız farklarıdır.
• —URL yapısı değişikliği: sayfa adreslerinin değişmesi; risk eksik veya yanlış yönlendirmedir.
• —https geçişi: http'den https'e; risk karışık içerik, yönlendirme zincirleri ve canonical uyuşmazlığıdır.
• —Tasarım yenilemesi (aynı URL'ler): görünümün değişmesi; risk içerik, başlık ve iç linklerin kaybolması veya hızın düşmesidir.
• —Birleşme ve ayrışma: iki sitenin birleştirilmesi veya birinin bölünmesi; içerik eşlemesi en karmaşık türdür.

Hangi türü yaptığınızı baştan bilmek, kontrol listesinin hangi maddelerinin sizin için kritik olduğunu belirler. Örneğin yalnızca tasarım yenileyip URL'leri aynı bırakıyorsanız, yönlendirme yükünüz düşük ama içerik ve başlık yapısının korunması önceliklidir. Alan adı değiştiriyorsanız, yönlendirme ve Search Console adım adım izlenmelidir.

Taşımadan önce siteyi taramak ve URL envanteri çıkarmak neden gereklidir?

Taşımadan önce siteyi taramak, mevcut tüm sayfaların, başlıklarının, yönlendirmelerinin ve iç linklerinin kayıtlı bir envanterini verir. Bu envanter olmadan hangi sayfanın kaybolduğunu veya hangi eski adresin yönlendirilmesi gerektiğini bilemezsiniz. Envanter, taşımanın tüm sonraki adımlarının temelidir.

• —Tam tarama: bir tarama aracıyla siteyi gezin ve tüm URL'leri, durum kodlarını, başlık, açıklama, h1, canonical ve noindex bilgilerini dışa aktarın.
• —Sitemap ve Search Console: sitemap'te olan ve Google'ın bildiği ama taramada görünmeyen adresleri de ekleyin.
• —Yetim sayfalar: iç link almayan ama trafik veya bağlantı alan sayfaları belirleyin.
• —Dış bağlantı alan sayfalar: değerli sayfaları işaretleyin; bunların URL'si korunmalı veya doğru yönlendirilmelidir.
• —Medya ve dosyalar: PDF, görsel ve indirilebilir dosyaların adreslerini de kaydedin.
• —Yönlendirmeler: mevcut 301/302 kayıtlarını çıkarın; yeni sistemde de korunmaları gerekir.
• —Tarama kaydını saklayın: lansmandan sonra karşılaştırma için tarih etiketli olarak yedekleyin.

Taşımadan önce performans baz çizgisi nasıl çıkarılır?

Performans baz çizgisi, taşımadan önceki trafiğin, sıralamanın, dönüşümün ve hız metriklerinin kaydıdır. Taşıma sonrası bir düşüş olursa karşılaştıracağınız tek referans budur. Search Console ve analitik verisini tarih etiketiyle dışa aktarmak, taşımadan önce yapılacak en değerli ve en çok unutulan işlerden biridir.

• —Search Console: son 12-16 ayın sayfa ve sorgu bazlı gösterim, tıklama, CTR ve konum verisini dışa aktarın.
• —Analitik: organik oturumlar, en çok trafik alan sayfalar, hedef ve dönüşüm verileri; mümkünse geçen yılın aynı dönemiyle birlikte.
• —Önemli sorgu listesi: kazandıran 20-50 anahtar kelimenin güncel konumları.
• —Hız ve Core Web Vitals: ana şablonlar için mevcut ölçümler; yeni site daha yavaşsa fark edilsin.
• —Dizin durumu: Search Console'daki indekslenen sayfa sayısı ve hata raporları.
• —Dönüşüm yolları: form, telefon ve WhatsApp tıklamalarının çalıştığını gösteren test kaydı.
• —Mevsimsellik notu: taşımayı yoğun satış döneminin ortasına koymayın; baz çizgisini mevsimle birlikte okuyun.

URL eşleme tablosu nasıl hazırlanır ve 301 yönlendirmeleri nasıl kurulur?

URL eşleme tablosu, her eski adresin yeni karşılığını gösteren ve yönlendirmelerin temelini oluşturan bir listedir. Her eski URL, en yakın içerik karşılığı olan yeni URL'ye tek adımda 301 ile yönlendirilmelidir. Hepsini ana sayfaya yönlendirmek, Google tarafından çoğu zaman “yumuşak 404” gibi işlenebilir ve değeri kaybettirir.

• —Tablo sütunları: eski URL, yeni URL, durum (aynı kalıyor, değişiyor, birleşiyor, kaldırılıyor), yönlendirme türü, not.
• —Bire bir eşleme: en yakın içeriğe; benzer içerik yoksa ilgili kategori sayfasına, son çare olarak ana sayfaya.
• —Tek adım: A'dan B'ye, B'den C'ye zincir kurmayın; eski adresi doğrudan son adrese yönlendirin.
• —301 kalıcı yönlendirmedir; geçici durum olmadıkça 302 kullanmayın.
• —Sorgu parametreli ve eğik çizgi varyasyonlu eski adresleri de unutmayın.
• —Kaldırılan sayfalar: gerçekten içeriği olmayan ve karşılığı bulunmayanlar 404 veya 410 dönebilir; ama trafiği/bağlantısı olan hiçbir sayfa sessizce silinmemelidir.
• —Yönlendirme testi: lansmandan önce staging ortamında örneklem değil, tüm listeyi araçla test edin.

Yönlendirmeleri en az bir yıl tutmanız önerilir; kalıcı olarak korumak daha da güvenlidir. Eski adresler dışarıdan hâlâ bağlantı alabilir ve kullanıcıların yer imlerinde durabilir. Yönlendirmeyi kısa sürede kaldırmak, taşıma sırasında kazandığınız tüm sinyalleri riske atar.

Canonical, hreflang, sitemap ve robots.txt nasıl doğrulanır?

Yeni sitede canonical etiketleri kendi sayfasına işaret etmeli, hreflang karşılıklı ve doğru olmalı, sitemap yalnızca indekslenmesini istediğiniz 200 dönen adresleri içermeli ve robots.txt önemli bölümleri engellememelidir. Bu dört ayar, taşıma sonrası en sık bozulan teknik unsurlardır ve lansmandan önce tek tek test edilmelidir.

• —Canonical: her sayfa kendi yeni adresine işaret etsin; eski alan adına veya staging adresine işaret eden kalıntı olmasın.
• —Hreflang: çok dilli sitede karşılıklı doğrulama; dil klasörleri ve alternatifler yeni adreslerle güncellenmiş olsun.
• —Sitemap: yalnızca yeni, kanonik, 200 dönen adresleri içersin; eski sitemap'i kaldırın, yenisini Search Console'a gönderin.
• —robots.txt: staging'den kalma kısıtlamalar canlıda olmasın; önemli klasörler engellenmemiş olsun; sitemap konumu yazılı olsun.
• —Meta robots: şablon düzeyinde noindex veya nofollow kalıntısı bırakmayın.
• —Yapılandırılmış veri: şablonların işaretlemesi yeni adreslerle ve doğru bilgilerle çalışsın; Zengin Sonuçlar Testi ile örnek sayfaları doğrulayın.
• —Sayfalama ve filtre sayfaları: yeni sistemde canonical ve indeks politikasını gözden geçirin.

Staging ortamındaki noindex'i kaldırmayı unutmak neden bu kadar yaygın bir felakettir?

Staging, yani test ortamı, arama motorlarından gizlenmek için noindex veya robots.txt engeliyle korunur. Site canlıya alınırken bu ayarların kaldırılması unutulursa yeni site indekslenmez ve sıralamalar hızla kaybolabilir. Bu, en sık görülen ve en kolay önlenebilir taşıma hatalarından biridir; kontrol listesinde ayrı bir madde olmalıdır.

Önlemek için lansman günü şu üç noktayı elle doğrulayın: sayfa kaynağında meta robots etiketinin noindex içermemesi, robots.txt dosyasında Disallow: / satırının olmaması ve HTTP başlığında X-Robots-Tag: noindex bulunmaması. Search Console'daki URL Denetimi aracıyla önemli birkaç sayfa için “indekslenmeye uygun” durumunu görmek de iyi bir doğrulamadır. Tersini de unutmayın: eski sitede canlı kalan kopya (eski alan adı) ile yeni site yinelenen içerik oluşturmamalı; yönlendirme kurulmalıdır.

• —Lansman sabahı: ana sayfa, bir hizmet sayfası ve bir blog yazısında kaynak kodu ve HTTP başlığını kontrol edin.
• —robots.txt dosyasını tarayıcıda açıp okuyun.
• —Search Console URL Denetimi ile canlı URL testini çalıştırın.
• —Staging ortamına şifre koruması ekleyin; böylece yanlışlıkla indekslenmez.
• —Lansmandan sonra staging ortamının arama sonuçlarında çıkmadığını kontrol edin.

Alan adı değişikliğinde Search Console Adres Değişikliği aracı nasıl kullanılır?

Alan adı değişikliğinde 301 yönlendirmeleri kurulduktan sonra Search Console'daki Adres Değişikliği aracı, eski mülkten yeni mülke taşındığınızı Google'a bildirir. Bu araç yalnızca alan adı değişikliği için geçerlidir; yalnızca URL yolu değişen taşımalarda kullanılmaz. Önce her iki alan adının mülk olarak doğrulanmış olması gerekir.

• —Eski ve yeni alan adı Search Console'da doğrulanmış mülk olarak eklensin.
• —Eski alan adından yeni alan adına tüm sayfalar için 301 yönlendirmesi çalışır durumda olsun.
• —Yeni alan adının sitemap'ini gönderin.
• —Eski mülkün ayarlarından Adres Değişikliği aracını açıp yeni mülkü seçin.
• —Eski alan adını ve yönlendirmeleri uzun süre ayakta tutun; alan adı süresini yenilemeyi unutmayın.
• —Eski alan adından gelen dış bağlantıları, mümkünse sahiplerinden güncellemelerini isteyerek yeni adrese yönlendirin.

Araç, yönlendirmenin yerine geçmez; yönlendirme kurulmadan kullanılması anlamsızdır. Ayrıca bu tür bir taşıma sırasında trafik ve sıralama geçici olarak dalgalanabilir; Google'ın yeni alan adını tam olarak işlemesi zaman alır. Taşıma sırasında eski ve yeni mülkü birlikte izlemeniz gerekir.

Analitik, etiketler ve dönüşüm izleme taşıma sırasında nasıl korunur?

Taşımadan sonra analitik, etiket yöneticisi, reklam dönüşümleri ve form izleme kodlarının yeni sitede doğru çalıştığını lansman günü test etmek gerekir. Bu kodlar şablonla birlikte kaybolabilir; fark edilmezse haftalarca veri kaybı yaşanır ve taşımanın etkisini ölçmek imkânsız hâle gelir.

• —Analitik kodu: yeni sitede çalıştığını gerçek zamanlı raporlarla doğrulayın.
• —Etiket yöneticisi ve reklam etiketleri: dönüşüm etiketlerinin tetiklendiğini test edin.
• —Telefon, WhatsApp ve form: tıklama ve gönderim izlemesinin çalıştığını bir test gönderimiyle doğrulayın.
• —Search Console mülkü: yeni alan adı veya https için mülkün doğrulanmış olduğundan emin olun.
• —Çerez ve gizlilik: onay mekanizması yeni sitede aynı davranışla çalışsın.
• —Hedefler ve filtreler: analitikte iç trafik filtreleri ve hedef tanımları yeni URL'lerle uyumlu olsun.
• —Notlar: analitikte lansman tarihini ek açıklama olarak işaretleyin.

Lansman sonrası izleme takvimi nasıl olmalı?

Lansman sonrası izleme, ilk gün saatlik kontrol, ilk hafta günlük kontrol ve sonraki haftalarda haftalık kontrol şeklinde ilerler. Amaç, sorunları geçici dalgalanmadan ayırmak ve gerçek hataları hızla düzeltmektir. Takvim, kimin neye bakacağını önceden belirleyerek paniğe dayalı kararları önler.

• —Lansman günü: staging noindex kontrolü, yönlendirme örnekleri, sitemap gönderimi, analitik ve dönüşüm testi, 404 ve hata sayfası kontrolü.
• —İlk hafta (günlük): Search Console kapsam ve tarama hataları, sunucu günlüklerinde 404/5xx, yönlendirme zincirleri, indekslenen sayfa sayısı.
• —2.-4. hafta (haftalık): organik trafik ve baz çizgi karşılaştırması, hedef sorguların konumları, kopyalama ve canonical sorunları, Core Web Vitals alan verisi.
• —2.-3. ay (iki haftada bir): sıralama toparlanması, kaybolan sayfalar, düşen sorgu grupları, iç link ve içerik eksikleri.
• —6. ay: yıl bazlı karşılaştırma, kalıcı yönlendirmelerin gözden geçirilmesi, kalan sorunların kapatılması.

Taşıma sonrası geçici dalgalanma ne kadar sürer ve ne zaman endişelenmeli?

Doğru yapılan bir taşıma sonrasında bile organik trafikte ve sıralamada geçici dalgalanma görülebilir; Google'ın yeni adresleri yeniden taramaları, işlemesi ve sinyalleri aktarması zaman alır. Süre sitenin büyüklüğüne ve taşıma türüne göre değişir. Kesin bir gün sayısı vermek doğru olmaz, ancak birkaç hafta içinde toparlanma beklenmesi yaygındır.

Endişelenmek için şu işaretlere bakın: Dalgalanma değil, sürekli bir düşüş mü var? Belirli bir sayfa grubu mu kayboldu? Search Console'da kapsam hataları, “dizine eklenmedi” sayfaları veya 404 sayısı artıyor mu? Yeni sitenizde noindex, yönlendirme eksiği veya canonical hatası var mı? Bunlardan biri varsa beklemek yerine hemen müdahale edin. Sorun görünmüyor ve trafik dalgalanıp toparlanıyorsa, panikle yapılan toplu değişiklikler genellikle durumu kötüleştirir.

• —Normal olabilir: ilk haftalarda gösterimlerde dalgalanma, bazı sorgularda geçici konum değişimi.
• —İnceleme gerektirir: önemli sayfaların indeksten düşmesi, 404 artışı, yönlendirme zinciri, canonical uyuşmazlığı.
• —Acil: tüm sitenin indeksten çıkması, noindex veya robots engeli, sunucu hataları (5xx).
• —Bekle ve izle: hata bulunmuyor, dalgalanma görünüyor; haftalık eğilimi değerlendir.
• —Müdahale ederken: tek tek değişiklik yapın ve her birini kaydedin.

Taşıma ve yeniden tasarımlarda tipik felaketler nelerdir?

En sık görülen felaketler: yönlendirme kurulmamış eski URL'ler, canlıda kalmış noindex, kaybolan veya kısaltılan içerik, bozulan iç linkler, ana sayfaya toplu yönlendirme, yanlış canonical ve izleme kodlarının unutulması. Hepsi kontrol listesiyle önlenebilir; ortak nedenleri tasarım odaklı çalışmanın SEO'yu son aşamaya bırakmasıdır.

• —Yönlendirme yok: eski adreslerin 404 vermesiyle bağlantı ve sıralama değerinin kaybı.
• —Noindex kalıntısı: staging ayarının canlıya taşınması.
• —İçerik kısaltma: “daha sade” tasarım adına hizmet ve rehber metinlerinin silinmesi.
• —Başlık ve meta kaybı: yeni şablonun tüm sayfalara aynı başlığı veya boş açıklama vermesi.
• —İç link kaybı: menü ve içerik içi linklerin yeni yapıda eksik kalması.
• —Toplu ana sayfa yönlendirmesi: tüm eski sayfaların ana sayfaya gönderilmesi.
• —JavaScript ile içerik: önemli içeriğin yalnızca istemci tarafında üretilip taranamaması.
• —Hız kaybı: görsel ağırlıklı yeni tasarımın Core Web Vitals değerlerini bozması.
• —İzleme kaybı: analitik ve dönüşüm kodlarının şablonla birlikte silinmesi.
• —Mobil farkı: masaüstü ile mobil sürüm içeriğinin farklı olması.

Her felaketin önleyici bir kontrol maddesi vardır. Bu yüzden listeyi proje başında hazırlamak, tasarım ekibiyle ve geliştiriciyle paylaşmak ve lansman öncesi bir “SEO onay” toplantısı yapmak, taşıma maliyetinin en düşük sigortasıdır.

Taşıma ve yeniden tasarım için özet kontrol listesi nedir?

Özet kontrol listesi üç evredir: öncesinde tarama, URL envanteri ve baz çizgi; lansmanda eşleme tablosu, 301, canonical, sitemap, robots ve noindex kontrolü; sonrasında analitik doğrulama, Search Console izleme ve haftalık karşılaştırma. Her evrenin sonunda sorumlu ve onay olmalıdır.

• —Öncesi: tam tarama ve URL envanteri; Search Console ve analitik baz çizgisi dışa aktarıldı; en değerli sayfalar belirlendi.
• —Öncesi: URL eşleme tablosu hazır; içerik, başlık ve iç linkler yeni tasarımda korunacak şekilde planlandı.
• —Öncesi: staging noindex/şifre korumalı; canlıya geçiş günü ve sorumlular belirlendi.
• —Lansman: tüm 301 yönlendirmeleri test edildi, zincir ve döngü yok.
• —Lansman: canonical, hreflang, sitemap ve robots.txt doğrulandı; noindex kalıntısı yok.
• —Lansman: analitik, etiket ve dönüşüm izleme çalışıyor; telefon, WhatsApp ve formlar test edildi.
• —Lansman: yeni sitemap gönderildi; alan adı değişikliğiyse Adres Değişikliği aracı kullanıldı.
• —Sonrası: ilk hafta günlük, sonraki aylarda haftalık Search Console ve trafik izleme.
• —Sonrası: 404, tarama hataları ve indeks kapsamı düzenli kontrol; sorunlar tek tek düzeltilip kaydedildi.
• —Sonrası: yönlendirmeler en az bir yıl, tercihen kalıcı olarak korundu.