Web Sitesi Yenilenirken Google Trafiği Nasıl Korunur? SEO Migration Kontrol Listesi

Kısa cevap

Web sitesi yenilenirken organik trafiği korumanın en güvenli yolu, Google’ın zaten bildiği URL’leri gereksiz yere değiştirmemek ve değişmesi gereken her eski URL’yi yeni sitedeki en yakın karşılığına kalıcı olarak yönlendirmektir. Yeni tasarım, yeni altyapı veya yeni CMS tek başına SEO kaybı anlamına gelmez. Risk; aynı anda URL yapısı, domain, içerik, internal linking, canonical, robots/noindex ve rendering davranışlarının kontrolsüz değiştirilmesiyle büyür. Google da domain, CMS ve tasarım gibi büyük değişikliklerin mümkün olduğunda tek tek yapılmasını; URL değişiyorsa eski→yeni URL eşlemesinin hazırlanmasını, kalıcı yönlendirmelerin uygulanmasını ve taşınma sonrasında trafiğin izlenmesini öneriyor. (Google for Developers) Temel prensip: Yeni siteyi sıfırdan bir SEO projesi gibi değil, mevcut organik değerin kontrollü biçimde taşındığı bir migration projesi gibi ele alın.

Web sitesi yenilemek neden Google trafiğini etkileyebilir?

Çünkü Google eski sitenizi yalnızca:

“bir tasarım” olarak görmez. Zaman içinde: URL'ler + İçerikler + Internal link'ler + Canonical sinyalleri + Backlink'ler + Site yapısı hakkında bilgi toplamıştır. Yeni site yayına çıktığında bunların bir kısmı aniden değişirse Google yeni yapıyı yeniden:

• crawl etmek,
• anlamak,
• canonicalize etmek,

indexlemek zorunda kalabilir. Google önemli site taşımalarında sıralama dalgalanmalarının normal olduğunu ve orta ölçekli sitelerde URL’lerin büyük bölümünün yeni yapıya taşınmasının birkaç hafta sürebileceğini; büyük sitelerde sürenin daha uzun olabileceğini belirtiyor. (Google for Developers)

Web sitesi yenileme ile SEO migration aynı şey mi?

Her zaman değil. Dört farklı senaryoyu ayırmak gerekir.

Google da URL değişmeyen hosting taşımaları ile URL değişen site taşımalarını ayrı süreçler olarak ele alıyor. (Google for Developers) En güvenli senaryo: Tasarım değişsin, URL’ler mümkün olduğunca aynı kalsın Mevcut sitenizde: /hizmetler/ozel-yazilim Google’da trafik alıyorsa yeni sitede sırf daha modern görünsün diye: /cozumler/custom-software-development haline getirmek zorunda değilsiniz. URL değiştirmenin business veya bilgi mimarisi açısından gerçek bir gerekçesi yoksa mevcut başarılı URL’yi korumak genellikle daha düşük risklidir.

“Yeni site yapıyoruz, URL’leri de temizleyelim” neden riskli?

Tek başına kötü fikir değildir. Ancak örneğin: Eski domain + Yeni domain + Yeni CMS + Yeni tasarım + Yeni URL yapısı + Yeni içerik aynı gün değiştirilirse trafik düşüşü olduğunda sebebi ayırmak zorlaşır. Google’ın mevcut site-move rehberi açıkça mümkün olduğunda değişikliklerin birer birer yapılmasını öneriyor; örneğin önce domain taşınması, daha sonra layout değişimi. (Google for Developers) SEO migration'ın en önemli belgesi: URL Mapping Yeni site kodlanmadan önce şu tablo oluşturulmalıdır: Eski URL Yeni URL İşlem /hizmetler/web-tasarim /hizmetler/web-platformlari 301 /blog/eski-yazi /blog/yeni-yazi 301 /referanslar /projeler 301 /eski-kampanya — 404/410 /iletisim /iletisim Aynı kalır Google da URL değişikliği yapılan migration’larda mevcut URL’lerden yeni karşılıklarına mapping hazırlanmasını sürecin temel adımlarından biri olarak tanımlıyor. (Google for Developers)

Hangi URL'ler önce envantere alınmalı?

Özellikle:

• organik trafik alan sayfalar,
• impression alan sayfalar,
• backlink alan URL’ler,
• dönüşüm sağlayan landing page’ler,
• önemli ürün/hizmet sayfaları,
• blog içerikleri,

PDF ve diğer indexlenebilir dokümanlar. Ama ideal durumda yalnızca “SEO açısından önemli görünen” URL’leri değil: indexlenebilir mevcut URL setinin tamamını mapping’e alın.

Google Search Console burada nasıl kullanılır?

Migration öncesinde mevcut site için en azından:

• Performance,
• Pages,
• Indexing,
• Sitemaps,

Core Web Vitals verileri export edilmelidir. Böylece migration sonrası: Önce vs Sonra karşılaştırılabilir. Google site taşımalarında Search Console’un eski ve yeni property’leri izlemek için kullanılmasını özellikle öneriyor. (Google for Developers) En büyük hata: Bütün eski URL'leri ana sayfaya yönlendirmek Örneğin eski sitede: /blog/seo-rehberi /hizmetler/mobil-uygulama /hizmetler/saas /referanslar var. Yeni sitede bunların hepsi: 301 → / yapılıyor. Bu doğru migration değildir. Google, çok sayıda alakasız eski URL’nin tek bir hedefe — örneğin ana sayfaya — yönlendirilmesinin kullanıcıları şaşırtabileceğini ve soft 404 olarak değerlendirilebileceğini açıkça belirtiyor. (Google for Developers)

Doğru 301 mantığı nedir?

Her eski URL:

yeni sitedeki en yakın ve anlamlı karşılığına gitmelidir. Örneğin: /eski/crm-yazilimi ↓ 301 /cozumler/crm Mantıklı. Ama: /eski/crm-yazilimi ↓ 301 / yalnızca ana sayfanın en uygun karşılık olduğu gerçek bir durum varsa anlamlıdır.

301 mi 302 mi?

Kalıcı URL değişikliğinde:

301 veya 308 gibi permanent redirect kullanılmalıdır. Google permanent redirect’leri hedef URL’nin canonical olması gerektiğine dair güçlü bir sinyal olarak değerlendiriyor. Temporary redirect’lerde ise source URL’nin Search’te tutulması daha olasıdır. (Google for Developers) Basit örnek: HTTP/1.1 301 Moved Permanently

Location:

301 kullanmak PageRank kaybettirir mi?

Google’ın güncel site-move rehberindeki açıklamasına göre 301 ve diğer permanent redirect’ler PageRank kaybına neden olmaz. (Google for Developers) Ancak bundan: “301 yaptıysak ranking kesinlikle hiç değişmez.” sonucu çıkarılmamalıdır. Google aynı rehberde önemli migration’larda recrawl ve reindex sürecinde geçici sıralama dalgalanmaları oluşabileceğini de belirtiyor. (Google for Developers) Redirect chain oluşturmayın Şu yapı: /eski ↓ /eski-v2 ↓ /yeni ↓ /yeni-v2 yerine: /eski ↓ /yeni-v2 daha doğrudur. Googlebot redirect chain’leri takip edebilse de Google doğrudan final destination’a yönlendirmeyi öneriyor. Uzun chain’ler kullanıcı latency’sini de artırıyor. (Google for Developers)

Eski sayfanın yeni karşılığı yoksa ne yapmalısınız?

Her URL’ye zorla redirect vermek gerekmiyor. İçerik gerçekten kaldırılmış ve yeni sitede: anlamlı bir karşılığı yoksa gerçek: 404 Not Found veya: 410 Gone dönmek doğru olabilir. Google, kaldırılmış ve eşdeğer içeriği bulunmayan sayfalar için 404 veya 410 kullanılmasını öneriyor. (Google for Developers)

Soft 404 nedir?

Örneğin kullanıcı:

/eski-sayfa açıyor. Ekranda: Sayfa bulunamadı. yazıyor. Ama server: 200 OK döndürüyor. Google buna soft 404 diyebilir.

Error sayfasının gerçek HTTP status code’u da doğru olmalıdır. (Google for Developers)

Canonical migration sırasında neden kritik?

Yeni URL örneğin:

ama HTML içindeki canonical hâlâ:

gösteriyorsa birbirine çelişen sinyaller üretirsiniz. Google migration sonrasında yeni sayfaların canonical annotation’larının yeni URL’leri göstermesini öneriyor. (Google for Developers) Self-referencing canonical kullanın Yeni canonical sayfa:

<link
rel="canonical"
href="

/> şeklinde kendisini canonical olarak gösterebilir. Google canonicalizasyon için:

• redirect,
• rel="canonical",

sitemap gibi birden fazla sinyali değerlendiriyor; redirect ve rel="canonical" güçlü sinyaller, sitemap ise daha zayıf bir canonical sinyali olarak tanımlanıyor. (Google for Developers)

Canonical bir emir mi?

Hayır. Google canonical declaration’larını sinyal olarak değerlendirir ve bazı durumlarda sizin belirttiğiniz URL’den farklı bir URL’yi canonical seçebilir. (Google for Developers) Bu nedenle migration’da: 301 + Canonical + Internal links + Sitemap aynı URL setini işaret etmelidir. Internal link'leri redirect'e bırakmayın Yeni site içindeki link:

<a href="/eski-url">

şeklinde kalıp sonra 301 üzerinden yeni sayfaya gitmemeli. Doğrudan:

<a href="/yeni-url">

olmalıdır.

Google site move sırasında internal link’lerin yeni URL’lere güncellenmesini özellikle öneriyor. (Google for Developers)

Neden?

Çünkü aksi halde:

Internal Link ↓ 301 ↓ New URL gereksiz bir redirect hop yaratır. Ayrıca site içinde eski URL’leri kullanmaya devam etmek canonical sinyallerinizi de bulanıklaştırabilir. Çok dilli sitelerde hreflang unutulmamalı Örneğin: /tr/hizmet /en/service /de/dienstleistung sayfalarınız varsa ve URL yapısını değiştiriyorsanız:

• hreflang,
• alternate URL’ler,
• canonical,

internal link referansları birlikte güncellenmelidir. Google da site move rehberinde multilingual/multinational sitelerde hreflang annotation’larının yeni URL’lere taşınmasını açıkça istiyor. (Google for Developers) Çok dilli migration'da en sık yapılan hata Eski: /tr/limanlar/izmir /en/ports/izmir Yeni: /tr/ports/izmir /en/ports/izmir oluyor. Ama hreflang hâlâ eski Türkçe URL’yi gösteriyor. Sonuç: Redirect başka yeri Canonical başka yeri Hreflang başka yeri işaret edebilir. Migration sonunda bütün SEO annotation’ları aynı yeni URL modeline göre kontrol edilmelidir.

Sitemap nasıl güncellenmeli?

Yeni XML sitemap:

Google’da görünmesini istediğiniz canonical yeni URL’leri içermelidir. Google sitemap’lerde tam ve absolute URL kullanılmasını ve tercih edilen canonical URL’lerin listelenmesini öneriyor. (Google for Developers) Örneğin:

<url>
<loc>
</url>

Yeni sitemap ne zaman Search Console'a gönderilmeli?

Migration yayına alındıktan ve yeni URL’ler ulaşılabilir hale geldikten sonra yeni sitemap Search Console’a gönderilmelidir.

Google bunun yeni URL’leri keşfetmeye yardımcı olabileceğini belirtiyor. (Google for Developers)

Staging sitesi Google'a açılmalı mı?

Genellikle istemezsiniz. Örneğin: staging.example.com production içeriğinin birebir kopyasıysa yanlışlıkla indexlenmesi duplicate URL setleri oluşturabilir. Development sırasında staging üzerinde noindex kullanılabilir. Ancak kritik nokta: Launch sırasında staging için kullandığınız noindex production’a taşınmamalı. Google site taşıma rehberi bunu migration sırasında en sık görülen hatalardan biri olarak özellikle belirtiyor. (Google for Developers)

noindex ve robots.txt birlikte nasıl çalışır?

Burada sık yapılan teknik hata:

robots.txt Disallow: / ve:

<meta name="robots" content="noindex">

birlikte kullanmaktır. Google, noindex kuralını görebilmek için sayfayı crawl edebilmelidir. Sayfa robots.txt ile engellenirse Googlebot noindex direktifini göremeyebilir. (Google for Developers) Bu nedenle staging erişim politikasını bilinçli planlayın. Launch günündeki en tehlikeli satır Şudur:

<meta name="robots" content="noindex,nofollow">

Production template içinde unutulursa bütün migration teknik olarak çalışırken Search görünürlüğü zarar görebilir. Launch checklist’in ilk maddelerinden biri: Indexability kontrolü olmalıdır. robots.txt de kontrol edilmeli Staging sırasında kullanılan: User-agent: * Disallow: / production’a taşınmamalıdır.

Google yeni site launch edildiğinde temporary crawling bloklarının kaldırılmasını istiyor. (Google for Developers)

Tasarım değişirken içerik de tamamen değiştirilmeli mi?

Teknik olarak yapılabilir. Ama migration riskini artırır. Örneğin eski sayfa: 2.000 kelime + FAQ + ürün detayları ile organik trafik alıyor. Yeni tasarımda yalnızca: 1 hero + 3 kart + iletişim butonu kalıyor. URL aynı olsa bile Google açısından içerik artık aynı değildir. Bu nedenle redesign sırasında: trafik alan sayfaların search intent ve bilgi değerini koruyun. Görsel sadeleşme uğruna değerli içeriği silmek SEO migration’dan bağımsız olarak ranking etkisi yaratabilir. Meta title ve description'ları sıfırlamayın Yeni CMS’e geçerken bazen bütün sayfalara: Company Name şeklinde aynı title atanır. Migration öncesinde:

• title,
• meta description,
• H1,

önemli heading’ler

export edilip yeni sistemle karşılaştırılmalıdır.

Buradaki amaç eski metni sonsuza kadar korumak değildir. Ama: hangi SEO varlığını değiştirdiğinizi bilmeden sıfırlamamak önemlidir. Bu InoviqLab migration önerisidir. Structured data'yı unutmayın Eski sitenizde:

• BreadcrumbList,
• Organization,
• Article,
• Product,

LocalBusiness gibi structured data bulunuyorsa yeni frontend’de bunların kaybolup kaybolmadığı kontrol edilmelidir. Migration: HTML'i yeniden yaptık seviyesinde görülürse schema katmanı kolayca unutulabilir. Bu InoviqLab teknik kontrol önerisidir.

Yeni frontend içeriği Google gerçekten görebiliyor mu?

Özellikle framework/CMS değişiminde test edilmelidir. Tarayıcıda kullanıcı içeriği görüyor olabilir ama Googlebot:

• JavaScript hatası,
• blocked resource,
• server rendering problemi,

API error nedeniyle aynı içeriği göremeyebilir. Search Console URL Inspection kullanılarak kritik sayfaların Google açısından render edilen durumu kontrol edilebilir; Google da migration troubleshooting sırasında kayıp sayfalar için URL Inspection kullanılmasını öneriyor. (Google for Developers)

Core Web Vitals yenileme sırasında ölçülmeli mi?

Evet. Yeni site: daha güzel ama: çok daha yavaş olabilir. Google’ın güncel Core Web Vitals hedefleri: Metrik İyi deneyim hedefi LCP ≤ 2,5 saniye INP < 200 ms CLS < 0,1 Google site sahiplerinin Search başarısı ve kullanıcı deneyimi açısından iyi Core Web Vitals elde etmelerini tavsiye ediyor. (Google for Developers) Ancak “Lighthouse 100 olmazsa trafik düşer” demeyin Google tek bir page-experience skorunun ranking’i belirlemediğini; genel page experience’ın çeşitli unsurlarla birlikte değerlendirildiğini açıkça belirtiyor. (Google for Developers) Ama redesign sonrası: LCP 1.8 s → 5.4 s gibi ciddi regresyonlar yine de düzeltilmelidir.

Domain de değişiyorsa süreç farklı mı?

Evet. Örneğin: oldcompany.com ↓ newcompany.com taşınması gerçek bir domain migrationdır. Bu durumda:

• yeni domain Search Console’da doğrulanır,
• URL mapping hazırlanır,
• permanent redirects uygulanır,
• canonical/internal links/sitemap güncellenir,

Search Console Change of Address aracı kullanılabilir.

Google Change of Address aracını domain veya subdomain değişiklikleri için sunuyor. (Google Destek)

Change of Address hangi durumlarda kullanılmaz?

Google’a göre araç şu işlemlerde kullanılmamalıdır:

• HTTP → HTTPS,
• site içindeki yalnızca path değişiklikleri,
• www → non-www aynı domain,

URL değişmeden hosting/CDN taşıması. (Google Destek) Örneğin: example.com/blog/a ↓ example.com/icerik/a için Change of Address gerekmez. Doğru redirect ve sitemap güncellemesi yeterlidir.

Domain değiştirirken eski domain ne kadar tutulmalı?

Google current site-move guidance’a göre permanent redirect’ler mümkün olduğunca uzun, genel olarak en az 1 yıl korunmalıdır. (Google for Developers) Change of Address aracı migration sinyallerini 180 günlük süre boyunca işler; Google ayrıca eski domain’in kötü niyetle başka kişilerce alınmasını önlemek amacıyla en az bir yıl daha tutulmasını öneriyor. (Google Destek) Pratikte değerli eski domain’in uzun süre şirket kontrolünde kalması daha güvenlidir.

Hosting değişiyor ama URL değişmiyorsa?

Bu durumda:

example.com aynı kalır. Sadece altyapı değişir. Google’ın hosting migration rehberi bu durumda:

• yeni hosting’i hazırlayın,
• test edin,
• DNS’i değiştirin,
• eski ve yeni altyapıdaki trafiği izleyin,

Googlebot dahil herkes yeni altyapıya geçtiğinde eski ortamı kapatın yaklaşımını öneriyor. (Google for Developers) DNS değişiminde Search Console doğrulamasını kaybetmeyin Örneğin Search Console verification:

• HTML file,
• meta tag,

DNS üzerinden yapılmış olabilir. Hosting veya CMS değişirken verification dosyası/tag’i kaybolabilir. Google hosting migration dokümanında Search Console verification’ın yeni altyapıda devam ettiğinin kontrol edilmesini özellikle öneriyor. (Google for Developers) Analytics ölçümü de migration'ın parçasıdır Yeni site yayına çıktı. Trafik bir anda: %80 düştü görünüyor. Ama sebep SEO değil: GA4 tag’i yeni template’e eklenmemiş. olabilir. Bu yüzden launch öncesi:

• GA4,
• GTM,
• conversion events,
• consent setup,

ad conversion tags kontrol edilmelidir. Google site move dokümantasyonu da eski ve yeni sitenin kullanım/trafiğinin web analytics ile takip edilmesini öneriyor. (Google for Developers) SEO Migration'ı 3 aşamaya bölün Aşama 1 — Yayın Öncesi En kritik aşama. Inventory ↓ Mapping ↓ Technical QA ↓ SEO parity ↓ Performance test Aşama 2 — Launch Deploy ↓ Redirects ↓ Indexability ↓ Sitemap ↓ Search Console ↓ Analytics Aşama 3 — Launch Sonrası Crawl ↓ Index ↓ Traffic ↓ Errors ↓ Ranking ↓

Conversion

YAYIN ÖNCESİ SEO MIGRATION KONTROL LİSTESİ

URL Envanteri

Mevcut URL’ler çıkarıldı. Sitemap URL’leri alındı. Search Console trafik alan sayfalar export edildi. Analytics landing page’leri export edildi. Backlink alan önemli URL’ler belirlendi. PDF ve indexlenebilir dosyalar dahil edildi. URL Mapping Her eski URL için karar var. Aynı URL korunabiliyorsa korunuyor. Değişen URL’nin doğru yeni karşılığı var. Karşılığı olmayan sayfalar işaretlendi. Toplu homepage redirect planlanmadı. Redirect chain oluşturulmadı. Google doğrudan final URL’ye server-side permanent redirect verilmesini öneriyor. (Google for Developers) İçerik Organik trafik alan içerikler yeni sitede mevcut. Kritik başlık/H1 bilgileri korundu veya bilinçli değiştirildi. Search intent değişmedi. Değerli FAQ/table/veri bölümleri yanlışlıkla silinmedi. Görsel ve PDF varlıkları kontrol edildi. Teknik SEO Canonical doğru. Self-canonical yeni URL’leri gösteriyor. Internal links yeni URL’lere gidiyor. Hreflang güncellendi. Sitemap yeni canonical URL’leri içeriyor. Structured data mevcut. Gerçek 404 response çalışıyor. Redirect response’ları test edildi. Indexability Production’da noindex yok. robots.txt production için doğru. CSS/JS kritik dosyaları gereksiz engellenmiyor. Googlebot sayfayı render edebiliyor. Staging indexlenmiyor. Ölçüm GA4 çalışıyor. GTM çalışıyor. Conversion event’leri test edildi. Search Console verification korunuyor. Eski trafik benchmark’ı kaydedildi. Performance Mobil test yapıldı. LCP kontrol edildi. INP riskleri kontrol edildi. CLS kontrol edildi. Büyük image/font/script regresyonları incelendi.

LAUNCH GÜNÜ SEO KONTROL LİSTESİ

Production deploy tamamlandı. Ana sayfa 200 dönüyor. Kritik landing page’ler 200 dönüyor. Eski URL’ler doğru 301/308 dönüyor. 301 hedefleri 200 dönüyor. Redirect chain yok. noindex kaldırıldı. robots.txt kontrol edildi. Canonical production domain’i gösteriyor. hreflang production URL’lerini gösteriyor. Sitemap production URL’lerini içeriyor. Yeni sitemap Search Console’a gönderildi. Analytics gerçek zamanlı veri alıyor. Conversion test edildi. 404 sayfası gerçek 404 döndürüyor. Domain değiştiyse Change of Address değerlendirildi.

LAUNCH SONRASI KONTROL LİSTESİ

İlk 24–72 saat

Server error’ları kontrol et. Unexpected 404’leri bul. Redirect hatalarını kontrol et.

Analytics data geliyor mu?

Conversion çalışıyor mu?

Search Console URL Inspection ile kritik URL’leri test et. İlk 1–2 hafta Page indexing değişimini izle. Old URLs / New URLs davranışını kontrol et. Search impressions trendini izle. Kritik query/page performansını karşılaştır. Google-selected canonical’ları kontrol et. Yeni 404/soft 404 raporlarını incele. Core Web Vitals regresyonlarını izle. İlk 1–3 ay Organik landing-page trendlerini kıyasla. Conversion trendini kıyasla. Eski URL’lere gelen backlink/trafik için redirect çalışıyor mu kontrol et. Önemli dış linkleri yeni URL’ye güncellettir. Sosyal profil ve reklam landing page URL’lerini güncelle. Redirect’leri kaldırma. Google ayrıca site taşındıktan sonra yüksek değerli external link’lerin yeni URL’lere güncellenmesini ve sosyal profil/reklam URL’lerinin değiştirilmesini öneriyor. (Google for Developers)

Migration sonrası trafik düştüğünde önce nereye bakmalısınız?

Panikle:

“Google yeni siteyi sevmedi.” demeden önce teknik nedenleri ayırın.

1. Analytics problemi mi?

Tag kayıp olabilir.

2. Indexability problemi mi?

noindex / robots.

3. Redirect problemi mi?

Eski URL → yanlış URL.

4. Content problemi mi?

Değerli içerik kaldırıldı.

5. Canonical problemi mi?

Yeni sayfalar eski veya yanlış domaine canonical veriyor.

6. Rendering problemi mi?

Google önemli içeriği göremiyor.

7. Internal linking problemi mi?

Yeni site önemli sayfalara yeterli bağlantı vermiyor.

8. Performance problemi mi?

Yeni frontend ciddi biçimde yavaşladı.

Trafik ne kadar düşerse paniklemeliyiz?

Bunun evrensel bir yüzde cevabı yoktur. Google significant site move sırasında geçici sıralama dalgalanmalarının normal olduğunu belirtiyor. (Google for Developers) Asıl önemli olan: Temporary fluctuation ile: Technical migration failure arasındaki farkı bulmaktır. Örnek: Sağlıklı dalgalanma Hafta 1 -12% Hafta 2 -6% Hafta 3 -2% Hafta 4 normalleşme gibi olabilir. Bu yalnızca örnektir. Daha ciddi sinyal Örneğin: Organik trafik -60% + Indexed pages -70% + Binlerce 404 varsa teknik migration problemi araştırılmalıdır.

Ranking aynı ama trafik düştüyse?

SEO migration dışında:

• search demand,
• seasonality,
• SERP değişiklikleri,
• AI Overviews,
• CTR,

tracking gibi başka nedenler olabilir. Bu nedenle yalnızca: toplam trafik bakmak yerine: Queries + Pages + Impressions + Clicks + Position + Conversion birlikte incelenmelidir.

Yeni sitenin tasarımı SEO'yu otomatik iyileştirir mi?

Hayır. Daha modern UI: daha yüksek ranking garantisi değildir. Ama:

• mobil kullanılabilirlik,
• navigation,
• performance,
• içerik erişilebilirliği,

iyi page experience iyileşebilir. Google da iyi page experience’ın Search sistemlerinin ödüllendirmeyi hedeflediği özelliklerle uyumlu olduğunu, ancak tek bir page-experience metriğinin ranking garantisi olmadığını belirtiyor. (Google for Developers) SEO Migration'da En Sık Yapılan 12 Hata URL’leri gerekmeden değiştirmek Redirect mapping hazırlamamak Her şeyi ana sayfaya yönlendirmek 302 kullanıp kalıcı taşımayı belirtmemek Redirect chain oluşturmak Staging noindex ayarını production’da unutmak robots.txt ile bütün siteyi engellemek Canonical’ları eski domaine bırakmak Internal link’leri eski URL’lere bırakmak Hreflang’i güncellememek Analytics/conversion tracking’i kaybetmek Domain + CMS + URL + içerik değişimini aynı anda yapmak Bu hataların büyük bölümü launch’tan önce yapılacak teknik crawl ile bulunabilir.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın SEO migration yaklaşımıdır. Bir web sitesi yenilemesinde bizim için en kritik prensip: Önce mevcut organik varlıkları envantere al, sonra yeni siteyi tasarla. Tersi değil. Birinci prensip: Tasarım URL mimarisini gereksiz yere yönetmemeli Örneğin tasarımcı: “Bu menü yapısına göre URL’leri de değiştirelim.” diyebilir. Navigation değişebilir. Ama mevcut başarılı URL’nin değişmesi gerekmeyebilir. URL değişikliğinin business/SEO/mimari gerekçesi ayrıca değerlendirilmelidir. İkinci prensip: SEO migration development bittikten sonra eklenen checklist değildir Yanlış sıra: Siteyi kodla ↓ Canlıya al ↓ SEO'cu baksın Daha iyi: SEO Inventory ↓ Architecture ↓ Design ↓ Development ↓ SEO QA ↓ Launch Çünkü redirect mapping, URL yapısı ve rendering gibi kararlar uygulama geliştirilirken verilmelidir. Üçüncü prensip: En iyi redirect gerekmeyen redirect'tir Mevcut URL: /hizmetler/ozel-yazilim doğruysa yeni site de aynı URL’yi kullanabilir. Bu durumda:

• redirect yok,
• backlink transfer problemi yok,

kullanıcı bookmark problemi yok.

Bu nedenle migration tasarımında ilk soru:

Bu URL gerçekten değişmek zorunda mı?

olmalıdır. Dördüncü prensip: Aynı anda çok fazla değişken değiştirmeyin Google’ın kendi guidance’ı da domain, CMS ve layout gibi değişikliklerin mümkün olduğunda ardışık yapılmasını öneriyor. (Google for Developers) Bunun yalnızca Google için değil debugging açısından da değeri vardır. Eğer: Domain + CMS + URLs + Content + Rendering aynı gün değişirse sorunun kaynağını belirlemek çok daha zordur. Beşinci prensip: SEO trafiğini değil SEO değerini taşıyın Migration’ın amacı: eski ziyaretçi sayısını kopyalamak değildir. Taşınması gereken: Search Intent + Useful Content + URL Signals + Backlinks + Internal Authority + Technical Accessibility toplamıdır. Bu nedenle yalnızca 301 listesi hazırlamak tam SEO migration değildir. Altıncı prensip: Launch günü projenin sonu değildir SEO migration: Go Live ile bitmez. Asıl kritik faz: Go Live ↓ Observe ↓ Fix ↓ Stabilize dönemidir. Google da migration sırasında eski ve yeni URL trafiğinin izlenmesini ve sürecin per-URL ilerlediğinin dikkate alınmasını öneriyor. (Google for Developers) SEO Migration Master Checklist Önce Inventory → URL Mapping → Content → Technical SEO → Tracking → Performance Launch 301 → Indexability → Canonical → Sitemap → Search Console → Analytics Sonra 404 → Indexing → Pages → Queries → Traffic → Conversion → CWV Bu üç aşama doğru yönetildiğinde web sitesi yenilemesi: SEO’yu sıfırlayan bir proje olmak yerine: mevcut organik değerin daha iyi bir platforma taşındığı kontrollü bir modernizasyon haline gelir.

Sonuç

Web sitesini yenilemek Google trafiğini kaybetmek anlamına gelmez. Ancak yeni siteyi: “Eski siteyi kapatıp yeni dosyaları yüklemek” olarak görmek ciddi risktir. Google’ın güncel migration guidance’ı başarılı geçiş için:

• URL mapping,
• kalıcı server-side redirects,
• canonical güncellemeleri,
• internal link güncellemeleri,
• sitemap,
• Search Console,

trafik izleme adımlarını temel olarak öne çıkarıyor. (Google for Developers) Özellikle domain veya URL değişikliğinde geçici ranking dalgalanmaları normal olabilir; Google yeni URL’leri yeniden crawl ve index ederken geçiş zaman alabilir. (Google for Developers) Şirketler açısından doğru soru bu nedenle: “Yeni site ne zaman yayına çıkacak?” kadar: “Eski sitenin Google’da yıllardır biriktirdiği değeri yeni platforma nasıl taşıyacağız?” olmalıdır. İyi bir redesign yalnızca daha modern görünmemeli. Eski organik değeri korurken performans, kullanıcı deneyimi ve teknik altyapıyı da ileri taşımalıdır.