Blog details
Site taşıma projeleri çoğu zaman tasarım ya da altyapı işi gibi görünür. Oysa organik trafik kaybı, genelde son dakika unutulan teknik ayrıntılardan çıkar.
Eğer domain değişiyor, URL yapısı yenileniyor, CMS taşınıyor ya da birkaç site birleşiyorsa, site migration SEO sürecini proje planının merkezine koymanız gerekir. Aksi halde iyi bir yeniden tasarım bile görünürlük kaybına dönebilir.
Bu yüzden taşıma işini “yayına alırız, sonra bakarız” yaklaşımıyla değil, ölçülebilir bir kontrol listesiyle yürütmek gerekir.
Önce taşımanın tipini ve risk seviyesini netleştirin
Her site taşıma aynı riskte değildir. Sadece tema değişikliği yapıyorsanız risk başka, domain ve bilgi mimarisi aynı anda değişiyorsa risk çok daha yüksektir. İlk iş, taşınan şeyin ne olduğunu netleştirmektir.
Kapsam net değilse ekipler farklı varsayımlarla ilerler. SEO ekibi URL’lerin korunacağını düşünür, geliştirici rota yapısını değiştirir, proje yöneticisi de testi yayına bir gün kala planlar. Sorun tam burada başlar.
Aşağıdaki tablo, taşıma türünü hızlıca sınıflandırmak için işe yarar:
| Taşıma tipi | Risk seviyesi | İlk bakılacak alan |
|---|---|---|
| Sadece tasarım yenilemesi | Orta | Şablon, iç linkler, hız, structured data |
| CMS değişimi | Yüksek | URL yapısı, render, canonical, yönlendirmeler |
| Domain değişimi | Çok yüksek | 301 planı, Search Console, backlinkli sayfalar |
| HTTP -> HTTPS / subdomain değişimi | Yüksek | Canonical, sitemap, mixed content, yönlendirme |
| Site birleşmesi | Çok yüksek | İçerik eşleme, yetkili sayfalar, hreflang, redirect mapping |
Bu aşamada tek bir sahiplik matrisi çıkarın. Hangi iş SEO ekibinde, hangisi geliştiricide, hangisi içerik ekibinde belli olsun. Ayrıca bir “yayın engeli” listesi tanımlayın. Örneğin 301 testleri bitmeden, noindex kaldırılmadan veya dönüşüm etiketleri doğrulanmadan canlıya çıkılmasın.
Başarı ölçütlerini de taşıma öncesinde sabitleyin. Organik oturumlar, tıklamalar, indeksli URL sayısı, en çok trafik alan sayfalar, dönüşümler, 404 ve 5xx oranları bu listenin başında olmalı. Daha geniş bir faz planı görmek isterseniz, Search Engine Land’deki başarılı site taşıma planı ekipler arası görev dağılımını iyi çerçeveliyor.
Taşıma öncesi teknik SEO kontrol listesi
Teknik kontroller, taşıma günü panik yaşamamanız için vardır. Yayına çıkmadan önce eski sitenin envanterini toplamazsanız, yeni sitede neyin eksik kaldığını anlamak zorlaşır.
İlk çıkarılacak veri seti eski URL listesidir. Buna sitemap dosyaları, crawl çıktıları, en çok trafik alan açılış sayfaları, en çok backlink alan URL’ler ve dönüşüm getiren sayfalar dahil olmalı. SEO tarafında öncelik, tüm URL’leri değil, iş sonucu üreten URL’leri korumaktır.
URL envanteri ve redirect mapping
Redirect mapping, taşımanın omurgasıdır. Eski her değerli URL için yeni tarafta açık bir hedef URL tanımlanmalıdır. Bu mümkünse bire bir olmalı, değilse en yakın içerik niyetine yönlenmelidir.
Ana sayfaya toplu yönlendirme yapmak, kısa vadede kolay görünür ama kötü bir çözümdür. Google, konu alakasını kaybeder; kullanıcı da beklediği içeriği bulamaz. Özellikle blog, kategori, ürün, rehber ve kampanya sayfalarında bu hata pahalıya mal olur.
En yüksek riskli hata, eski URL’leri toplu olarak ana sayfaya göndermektir.
Redirect listesinde şu kontroller yer almalı:
- Eski URL -> yeni URL eşleşmesi tam dosya halinde hazır olsun.
- Kalıcı taşımada 301 kullanın, geçici test senaryosunda 302 bırakmayın.
- Redirect chain ve loop oluşmadığını tarama ile doğrulayın.
- Parametreli URL’ler, PDF dosyaları, görsel dosyaları ve eski kampanya sayfaları unutulmasın.
- Backlink alan ve organik trafik getiren URL’lere ayrı öncelik verin.
- 404 verilecek sayfalar için bilinçli karar alın, tesadüfi kayıp bırakmayın.
Birçok ekip sadece HTML sayfaları eşler. Oysa eski sitede sık indirilen PDF dosyaları veya güçlü backlink alan medya URL’leri de değer taşır. Özellikle domain taşımasında bunları atlamak otorite kaybını hızlandırır. Bire bir yönlendirme mantığı için URL eşleme ve taşıma rehberi pratik bir referans sunuyor.
Canonical, noindex, robots.txt ve XML sitemap
Yeni sitede canonical etiketleri, yeni URL’leri göstermelidir. Eski domaini ya da eski yol yapısını işaret eden canonical’lar çok sık gözden kaçar. Sonuçta Google yönlendirme ile bir yere, canonical ile başka yere çağrılır. Bu çakışma indekslemeyi yavaşlatır.
Staging ortamında noindex kullanmak mantıklıdır. Ancak canlı ortamda noindex etiketi ya da X-Robots-Tag açık kalırsa, taşımanın en ağır darbelerinden biri gelir. Bu yüzden canlı öncesi son kontrolde sayfa düzeyi ve şablon düzeyi noindex taraması şarttır.
Staging’de noindex koruyucudur, prod ortamında açık kalırsa trafik keser.
robots.txt dosyası da aynı dikkatle ele alınmalı. Geliştirme sırasında kullanılan Disallow: / kuralı bazen olduğu gibi canlıya taşınır. Ayrıca CSS, JS veya görsellerin taramaya kapatılması render sorunları yaratabilir. robots.txt, güvenlik katmanı değildir; staging için daha doğru çözüm erişim kısıtı ve parola korumasıdır.
XML sitemap tarafında ise sadece kanonik, 200 dönen, indekslenebilir URL’ler yer almalı. 301, 404, noindex veya parametreli sayfalar sitemap’te olmamalı. Büyük sitelerde ürün, kategori, içerik ve dil bazlı ayrı sitemap kümeleri yönetimi kolaylaştırır. Canlıdan hemen sonra yeni sitemap’i Search Console’a göndermek de işleri hızlandırır.
İçerik yapısı, iç linkler ve uluslararası kurgu
Site taşımasında sayfayı taşımak yetmez, bağlamı da taşımak gerekir. Bir kategori yapısı değiştiğinde sadece URL değil, o URL’ye giden iç linkler, breadcrumb yapısı ve bağlantı dağılımı da değişir.
İç linkler ve kırık bağlantılar
İç linklerde iki hata çok görülür. İlki, eski URL’lere link vermeye devam etmektir. İkincisi, tüm eski linkleri 301’e bırakarak işi çözülmüş sanmaktır. Oysa site içindeki linkler doğrudan yeni URL’leri göstermelidir. Böylece gereksiz yönlendirme yükü azalır, crawl bütçesi daha verimli kullanılır.
Menü, footer, breadcrumb, içerik içi linkler, related content modülleri ve filtre sayfaları birlikte kontrol edilmelidir. Özellikle JavaScript ile üretilen link alanları, manuel kontrolde gözden kaçar. Tarama raporunda iç linklerin kaçının 3xx ya da 4xx verdiğini görün ve canlı öncesi sıfıra indirmeye çalışın.
Aynı mantık canonical ve structured data içinde geçen URL’ler için de geçerlidir. JSON-LD içinde eski logo URL’si, eski breadcrumb yolu veya eski Organization profili kaldığında arama motoruna karışık sinyal gider.
Hreflang ve structured data
Çok dilli yapılarda hata payı daha yüksektir. Çünkü her dil veya ülke sayfası hem kendi yeni URL’sini göstermeli, hem de diğer varyantlara doğru dönmelidir. Karşılıklı hreflang ilişkisi kırılırsa ülke bazlı görünürlük düşebilir.
Uluslararası yapılarda site taşıma sonrası hreflang sorunları beklenenden sık çıkar. Özellikle klasör yapısı değiştiğinde, eski ülke sayfalarına giden etiketler yayında kalabiliyor. x-default etiketi kullanıyorsanız onun da yeni yapıyla uyumlu olduğundan emin olun.
Structured data tarafında da aynı disiplin gerekli. Product, Article, BreadcrumbList, FAQ, Organization ya da WebSite işaretlemeleri yeni URL’ler, yeni görseller ve doğru kanoniklerle güncellenmeli. Markup geçerli olsa bile yanlış sayfayı işaret ediyorsa fayda sağlamaz.
Ölçüm altyapısı hazır değilse sorun geç fark edilir
Taşıma sonrası “trafik düştü” demek geç kalmış bir cümledir. Daha doğru yaklaşım, taşıma öncesi temel verileri kaydetmek ve ilk saatten itibaren farkları izlemektir.
Analytics ve dönüşüm takibi
GA4, tag manager, reklam pikselleri ve temel dönüşüm olayları yayına çıkmadan test edilmelidir. Form gönderimi, telefon tıklaması, satın alma, lead adımı, üyelik, teşekkür sayfası gibi iş hedefi taşıyan olaylar ayrı ayrı doğrulanmalıdır.
Domain değişiyorsa referral exclusion, cross-domain tracking ve ödeme adımı yönlendirmeleri de kontrol edilmelidir. Aksi halde trafik verisi bölünür, dönüşüm atribüsyonu bozulur. Performans pazarlama ekibi bu aşamada sadece reklam etiketlerini değil, organik kaynakların temiz aktığını da test etmelidir.
Büyük hacimli projelerde taşıma öncesi ve sonrası anotasyon tutmak işe yarar. Yayın saati, DNS değişimi, sitemap gönderimi, noindex kaldırma anı ve büyük düzeltmeler analitik zaman çizelgesinde not düşülmelidir. Ekip içinde teknik kaynak sınırlıysa, profesyonel SEO danışmanlığı desteği bu kontrol katmanını hızlandırabilir.
Search Console, log kontrolü ve crawl bütçesi
Search Console tarafında yeni mülkler önceden doğrulanmalı. Domain taşımasında “Change of Address” özelliği kullanılmalı, yeni sitemap yüklenmeli ve kapsama raporları günlük takip edilmelidir.
Log kontrolü burada fark yaratır. Çünkü tarama araçları size teorik resmi gösterir, loglar ise Googlebot’un gerçekte ne yaptığını söyler. Eski URL’lere yoğun bot isteği devam ediyor mu, 301 zincirleri botu yavaşlatıyor mu, 404 oranı artıyor mu, bunları logtan görürsünüz.
Crawl bütçesi özellikle büyük sitelerde önemlidir. Googlebot’un zamanı filtre sayfalarına, parametre çöplüğüne ya da gereksiz yönlendirmelere gidiyorsa, yeni önemli URL’ler daha geç keşfedilir. Bu yüzden düşük değerli URL’leri sınırlamak, iç linkleri temizlemek ve sitemap’i rafine tutmak indeksleme hızını artırır.
Bir de hız tarafı var. Taşıma sonrası artan JavaScript, büyük görseller, yanlış cache ayarı veya yavaş sunucu yanıtı hem kullanıcıyı hem taramayı etkiler. Canlıya almadan önce en azından ana şablonlarda TTFB, LCP ve mobil sayfa ağırlığını kontrol edin.
Canlıya alma günü için net aksiyon listesi
Canlıya alma günü, yaratıcı kararların değil, disiplinli yürütmenin günüdür. O gün yeni fikir eklemeyin, daha önce onaylanan listeyi uygulayın.
Aşağıdaki sıra, çoğu projede güvenli bir akış sağlar:
- Son yedekleri alın ve geri dönüş planını ekipte görünür hale getirin.
- DNS, sunucu ve CDN değişikliklerinin planlandığı gibi uygulandığını doğrulayın.
- Canlı sitede noindex, yanlış canonical ve robots bloklarını kontrol edin.
- Redirect mapping dosyasını çalıştırın ve örnek URL setiyle anında test yapın.
- Ana şablonların 200 döndüğünü, eski değerli URL’lerin 301 ile doğru hedefe gittiğini teyit edin.
- Menü, breadcrumb, footer ve kritik içerik içi linklerin yeni URL’lere geçtiğini kontrol edin.
- XML sitemap’i üretin, Search Console’a gönderin ve domain değiştiyse adres değişikliğini işleyin.
- GA4, Tag Manager ve ana dönüşüm olaylarını canlı ortamda test edin.
- Structured data, hreflang ve canonical örneklemelerini en önemli sayfalarda doğrulayın.
- Sunucu logları, 5xx hataları ve anlık performans düşüşleri için ilk izlemeyi başlatın.
Bu listede ilk dört madde P0 önceliğindedir. Buralarda sorun varsa yayın durdurulmalı ya da sınırlı yayına geçilmelidir. Örneğin yanlış robots.txt, eksik 301’ler veya tüm şablona basılmış noindex etiketi “sonradan düzeltiriz” kategorisinde değildir.
Canlı gününde ayrıca kısa bir savaş odası mantığı kurun. SEO, developer, analytics ve proje yöneticisi aynı kanalda olsun. Kim hangi hatayı çözecek, hangi durumda rollback düşünülecek, baştan belli olsun. Faz bazlı canlı kontrol mantığı için Semrush’ın SEO dostu migration kontrol listesi iyi bir çapraz kontrol kaynağıdır.
İlk 7-14 gün için izleme planı
Canlıya çıkmak, işin yarısıdır. Arama motorlarının yeni yapıyı anlaması ve sinyalleri taşıması zaman alır. Bu yüzden ilk iki hafta reaktif değil, planlı izleme yapılmalıdır.
İlk 48 saatte kapsama, tarama ve yönlendirme raporlarına bakın. 404 ve soft 404 sayıları yükseliyor mu, 5xx artıyor mu, en çok trafik alan eski URL’ler doğru yönleniyor mu, bunları günlük kontrol edin. Search Console performans raporunda tıklama düşüşü tek başına alarm değildir; fakat önemli açılış sayfalarında görünüm ve sorgu kaybı birlikte artıyorsa kök neden bulunmalıdır. 3. günden sonra loglar daha anlamlı hale gelir. Googlebot yeni sitemap URL’lerini ne hızla ziyaret ediyor, eski URL’lerde ne kadar oyalanıyor, tarama en çok hangi klasörlerde yoğunlaşıyor, buna bakın. Crawl bütçesi boşa gidiyorsa iç linkleri, filtre yapısını ve gereksiz parametreleri yeniden gözden geçirin.
İlk 7-14 gün için pratik kontrol listesi şöyle olabilir:
- Her gün en kritik 50-100 URL’nin durum kodu, canonical ve indekslenebilirlik durumu kontrol edilsin.
- Organik trafik, tıklama ve dönüşüm verileri, eski dönemle aynı gün bazında karşılaştırılsın.
- Yeni 404’ler redirect mapping listesine eklenerek hızlıca kapatılsın.
- Hreflang, structured data ve sitemap hataları Search Console üzerinden izlenip önceliklendirilsin.
- Sunucu loglarında Googlebot, Bingbot ve yoğun 5xx örüntüleri takip edilsin.
- LCP, mobil hız ve sunucu yanıt süreleri ilk hafta boyunca günlük bakılsın.
Bu dönemde sıralama dalgalanması görebilirsiniz. Ancak iyi taşımalarda en kritik şey, yüksek değerli sayfaların erişilebilir ve tutarlı sinyal veriyor olmasıdır. Trafik biraz oynasa bile doğru sinyaller yerindeyse toparlanma daha hızlı olur.
Sonuç
Site taşıma projelerinde kayıp çoğu zaman büyük bir teknik arızadan değil, küçük ama birikimli ihmallerden çıkar. Eksik redirect mapping, yanlış canonical, açık unutulmuş noindex ya da kopmuş iç linkler, tek başına küçük görünür; birlikte ciddi görünürlük kaybı yaratır.
Bu yüzden en sağlam yaklaşım, taşıma işini tasarım teslimi gibi değil, kontrollü bir yayın operasyonu gibi yönetmektir. Kapsamı başta netleştirip canlı gününü disiplinli yürütürseniz, ilk 7-14 günlük izleme de kurtarma süreci değil, doğrulama süreci olur.
İyi bir site migration SEO planı, sürprizleri tamamen bitirmez. Ama hangi riskin nerede olduğunu görünür hale getirir ve organik performansı şansa bırakmaz.
This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.