Web Sitesi Yenilerken SEO Kaybetmemek: URL Haritasından 301 Yönlendirmelerine Kurumsal Migrasyon Rehberi

SEO migrasyonu, bir web sitesinin teknoloji, URL, alan adı, içerik veya bilgi mimarisi değişirken organik erişilebilirliğini ve kullanıcı yollarını korumaya yönelik planlı geçiş sürecidir. Başarı, her metriğin hiç dalgalanmaması değildir. Arama sistemlerinin değişiklikleri yeniden taraması ve işlemesi zaman alabilir. Başarı; değişikliğin amacına uygun olması, kaybın kontrol edilebilir kalması, hataların hızla görülmesi ve yeni yapının uzun vadeli gelişime açık olmasıdır.

URL değişikliği doğrudan keşif ve kimlik katmanını etkiler. Eski URL’ye gelen kullanıcı, bot ve backlink doğru yeni kaynağa ulaşmalıdır. İçerik silinmesi ise yalnız kelime kaybı değildir; sorgu eşleşmeleri, iç bağlantı hedefleri ve dönüşüm yolları da kaybolabilir. Her kaldırma kararı, sayfanın trafik almamasından daha geniş veriyle değerlendirilmelidir.

Internal link değişimi, önemli sayfaların tıklama derinliğini ve bağlamsal ilişkilerini dönüştürür. JavaScript render stratejisinin değişmesi, ilk HTML’de görünen metni ve link keşfini azaltabilir. Canonical veya hreflang hataları doğru sayfanın yerine başka locale, eski domain ya da parametreli varyasyonu işaret edebilir. Robots.txt veya yanlış taşınmış `noindex`, siteyi yayınlanmış görünmesine rağmen aramaya kapatabilir.

Altyapı riski de SEO riskidir. Yetersiz sunucu kapasitesi, bot trafiği ve gerçek kullanıcılar aynı anda arttığında 5xx üretir. Cache anahtarları yanlışsa dil veya canonical karışabilir. Analytics kopması, görünürlük kaybı olmasa bile ekibi kör bırakır; dönüşüm düşüşünün trafik, form, event veya consent kaynaklı olup olmadığı anlaşılamaz.

• Kritik kombinasyon: URL değişikliği + içerik azaltma + yeni JavaScript render modeli aynı anda uygulanıyorsa geri alma eşiği önceden yazılmalıdır.
• Sessiz hata: Sayfa 200 dönerken ana metnin boş olması, yalnız status code kontrolü yapan QA’den geçebilir.
• Ölçüm körlüğü: GA4 görünürken form event’lerinin veya consent sinyallerinin kaybolması, dönüşüm raporunu yanlış güvenli gösterebilir.

Tek bir crawl, bütün mevcut URL’leri vermez. Menü ve HTML linklerinden keşfedilen sayfalar ile sitemap, Search Console, analytics ve backlink araçlarında görünen adresleri birleştirin. İndekslenmiş fakat iç link almayan eski kampanya sayfaları, PDF’ler, görseller veya parametreli landing page’ler yalnız bu kesişimde ortaya çıkabilir. Her kaynak sütun olarak tutulmalı; URL’nin nereden bulunduğu kaybolmamalıdır.

Search Console’dan tıklama, gösterim, sorgu ve ülke verisini URL düzeyinde; analytics’ten landing session, dönüşüm ve gelir gibi iş metriklerini alın. Backlink alan sayfaları ve yönlendirme zincirlerini çıkarın. Canonical hedeflerini, hreflang kümelerini, indexability durumunu, status code’u, title ve H1’i kaydedin. Tarih aralığı mevsimselliği temsil etmeli; yalnız son yedi gün düşük hacimli sayfalar için yeterli olmayabilir.

Envanter bir arşiv değil, karar tablosunun girdisidir. Her URL için “koru”, “yenile”, “birleştir”, “kaldır” veya “incele” kararı verin. Organik dönüşüm sağlayan, güçlü backlink alan veya kurumsal olarak kritik sayfaları yüksek öncelik işaretleyin. İndekslenmiş olması tek başına korunma zorunluluğu değildir; fakat kaldırmanın nedenini ve beklenen cevabı belgelemek zorunludur.

Yönlendirme haritası, her eski URL’nin yeni sistemdeki sonucunu açıklar. Bire bir eşleştirmede eski ürün veya hizmet sayfası aynı niyeti ve ana içeriği taşıyan yeni sayfaya gider. Birden çok eski sayfa gerçekten tek kapsam altında birleştirildiyse çoktan bire eşleme yapılabilir. Fakat yalnız yönetimi kolaylaştırmak için bütün adresleri kategoriye veya ana sayfaya toplamak kullanıcı beklentisini bozar ve soft 404 gibi değerlendirilebilir.

Benzerlik kontrolü yalnız URL kelimelerine dayanmaz. Eski sayfanın ana konusu, sorguları, içerik kapsamı, hedef kitlesi ve dönüşüm amacı yeni hedefle karşılaştırılır. “Web tasarım performansı” yazısı, performans ve teknik SEO’yu kapsamlı biçimde ele alan yeni bir rehbere taşınabilir; UI/UX prensipleri yazısını aynı hedefe göndermek doğru değildir. Eşdeğer içerik yoksa gerçek 404 veya bilinçli kaldırmada 410, ilgisiz redirectten daha dürüst sonuçtur.

301 ve 308 kalıcı HTTP yönlendirmeleridir. Google bunları hedef URL’nin canonical olması yönünde güçlü sinyal olarak kullanır. 301 tarihsel olarak yaygın çözümdür; 308, isteğin yöntem ve gövdesinin korunmasını daha açık biçimde tanımlar. Standart GET sayfa geçişlerinde ikisi de kalıcı taşıma amacıyla kullanılabilir. Form veya API benzeri yöntem duyarlı isteklerde davranış farkını altyapı ekibiyle değerlendirin.

Yönlendirmeyi mümkün olduğunca server, reverse proxy veya framework routing katmanında üretin. JavaScript `location` yönlendirmesi kullanıcı tarafında kod çalışmasına bağlıdır ve son tercih olmalıdır. Meta refresh de server-side cevaptan daha zayıf bir uygulama katmanıdır. Eski URL doğrudan nihai yeni URL’ye gitmeli; A→B→C zinciri tarama maliyeti, gecikme ve bakım riski üretir. A→B ve B→A döngüsü ise sayfayı tamamen erişilemez kılar.

302 veya 307 geçici durumlar, kaynağın geri geleceği bakım ve kısa kampanya senaryoları içindir. Kalıcı migrasyonda geçici kod kullanmak kaynak URL’yi canonical tutma niyetiyle çelişebilir. Redirect kuralları query parametrelerini bilinçli yönetmeli; ölçüm parametresi korunurken eski filtre parametresinin yeni sayfada sınırsız kopya üretmediği doğrulanmalıdır.

const redirects = [
  {
    source: "/tr/blog/eski-yazi",
    destination: "/tr/blog/yeni-rehber",
    permanent: true,
  },
];

Yeni canonical URL kendi kendini işaret etmelidir. Eski URL, 301 ile yeni URL’ye gider; eski sayfada yalnız canonical değiştirip 200 bırakmak gerçek bir taşıma değildir. Redirect yeni hedefi gösterirken canonical eski domain’i gösteriyorsa sinyaller çatışır. Sitemap, internal link ve hreflang da yeni canonical URL’leri kullanmalıdır.

HTTP/HTTPS, www/non-www, trailing slash ve büyük-küçük harf varyasyonlarını tek politikada normalleştirin. Parametreli URL’lerde gerçekten aynı içeriği temsil eden varyasyonlar canonical ile konsolide edilebilir; farklı kullanıcı ihtiyacını karşılayan sayfayı ilgisiz ana sayfaya canonical etmek çözüm değildir. Canonical mutlak URL olmalı ve ilk HTML’de bulunmalıdır. JavaScript ile sonradan değiştirmek, özellikle render sorunu varsa gereksiz belirsizlik üretir.

Migrasyon QA’sinde yalnız canonical değerini değil, hedefinin status code’unu ve indexability durumunu da kontrol edin. 404’e, redirect zincirine veya `noindex` sayfaya canonical veren URL’ler teknik olarak etiket taşısa da doğru konsolidasyon sağlamaz. Staging canonical’ının production’a taşınması ve production canonical’ının test domain’ine kalması sık görülen yayın hatalarıdır.

Sadece gövde metnini kopyalamak, sayfayı taşımak değildir. Title, meta description, H1-H3 yapısı, görsel alt metinleri, dosya adları, video ve PDF bağlantıları, structured data ve iç bağlantılar envantere dâhildir. Yeni tasarım bazı alanları desteklemiyorsa içerik kaybı “tasarım kararı” adı altında görünmezleşebilir. İçerik modeli geliştirme başlamadan örnek sayfalarla test edilmelidir.

Güncellenen sayfalarda hangi bölümün neden değiştiğini belirtin. Birleştirilen içeriklerde her eski sayfanın değerli ve benzersiz kısımlarını yeni yapıya taşıyın; yalnız en popüler sayfanın metnini bırakıp diğerlerini yönlendirmeyin. Silinen içerik için eşdeğer yoksa iç linkleri kaldırın, sitemap’ten çıkarın ve kullanıcıya dürüst status code döndürün.

Structured data yeni görünür içeriğe göre yeniden üretilmelidir. Eski FAQ görünmüyorsa FAQPage verisi kalmamalı; ürün olmayan hizmete Product işaretlemesi taşınmamalı. Görsel URL’leri değişiyorsa kritik backlink veya image search değeri olan varlıklar için yönlendirme değerlendirin. İç link anchor metinleri yeni sayfanın kapsamını doğru anlatmalıdır.

Locale URL yapısını önce seçin: alt dizin, alt domain veya ayrı domain. Bir migrasyon sırasında dil segmentlerini değiştirmek her locale için bağımsız URL eşlemesi gerektirir. Türkçe sayfayı İngilizce ana sayfaya veya eksik çeviriyi otomatik olarak başka dildeki içeriğe yönlendirmek kullanıcı niyetini karşılamaz. Profesyonel karşılık yoksa yanlış hreflang üretmemek daha güvenlidir.

Her indekslenebilir locale sayfası self-referencing canonical taşır. Hreflang, dil veya dil-ülke koduyla gerçek karşılıkları bağlar ve bağlantılar karşılıklı olmalıdır. `tr` sayfası `en` sayfasına işaret ederken İngilizce sayfa geri dönmüyorsa küme eksiktir. `x-default`, dil seçici veya genel varsayılan için kullanılabilir; her projede zorunlu değildir.

Canonical ile hreflang farklı işleri yapar. Türkçe sayfayı İngilizce sayfaya canonical edip aynı zamanda birbirlerini alternatif göstermek çelişkidir. Hreflang URL’lerinin 200, indekslenebilir ve nihai canonical olması gerekir. Eksik karşılıkları kümeden çıkarın; staging, redirect veya 404 URL’lerini listelemeyin.

Production’a en yakın staging ortamında eski URL listesinin tamamını hedef davranışa karşı test edin. 200 olması gereken sayfalar içerik ve metadata ile 200; taşınanlar tek sıçramalı 301/308; kaldırılanlar karara göre 404/410; hiçbir kritik rota 5xx dönmemelidir. Test crawler’ı yönlendirmeleri takip etmeli ve nihai URL’yi raporlamalıdır.

Robots.txt, meta robots, X-Robots-Tag, canonical, sitemap ve hreflang birlikte kontrol edilir. Formlar gerçek teslimat veya güvenli test endpoint’iyle denenir. GA4, GTM, consent mode ve kritik conversion event’leri debug ortamında doğrulanır. Mobil görünüm, SSL zinciri, DNS TTL, CDN cache davranışı, image optimization ve Core Web Vitals laboratuvar ölçümü kabul raporuna eklenir.

• Status kodları: 200, 301/308, 404/410 ve 5xx örnekleri karar tablosuyla eşleşiyor.
• Index kontrolü: robots, noindex, canonical, sitemap ve hreflang tutarlı.
• Çıktı kontrolü: title, description, tek H1, ana metin, linkler ve structured data ilk HTML’de.
• İşlev kontrolü: formlar, e-posta, ödeme/lead akışları ve consent davranışı gerçek hata durumlarıyla test edildi.
• Altyapı kontrolü: SSL, DNS, CDN, cache, server kapasitesi ve rollback paketi hazır.

Yayın günü planı rol, zaman, kanıt ve geri alma eşiği içermelidir. “Sabah deploy ederiz, sonra bakarız” operasyon değildir. Aşağıdaki örnek, projenin ölçeğine göre daraltılabilir; amaç her adımın sahibini ve beklenen çıktısını görünür kılmaktır.

İlk saatlerde uygulama ve edge loglarını izleyin. 404’leri istek hacmi, referrer ve eski URL envanteriyle eşleştirin. 5xx oranı, server load, response time ve cache hit davranışını takip edin. Redirectlerin yalnız varlığını değil, hedefini ve zincir uzunluğunu kontrol edin. Formlar ve analytics event’leri farklı cihaz ve consent durumlarında yeniden denenmelidir.

Search Console anlık izleme aracı değildir; yine de sitemap erişimi, URL Inspection örnekleri ve kritik sayfaların indexability kontrolü için kullanılır. Sitemap yalnız yeni canonical URL’leri içermeli; eski sitemap geçici izleme amacıyla tutulacaksa planı ve kaldırma tarihi açık olmalıdır. Eski URL’nin yeniye yönlendiğini ve yeni URL’nin doğru canonical verdiğini birlikte doğrulayın.

Sorunları tek listede önceliklendirin: gelir/lead akışını bozanlar, site geneline yayılan indexability hataları, yüksek değerli URL redirectleri, içerik ve görsel kayıpları, düşük hacimli kozmetik sorunlar. Her düzeltme yeniden crawl ve regression testiyle kapanmalıdır.

Eski ve yeni URL’leri eşleme tablosu üzerinden karşılaştırın. Toplam trafik tek başına yeterli değildir; tıklama, gösterim, sorgu, ortalama konum ve landing page dönüşümünü URL kümeleri bazında izleyin. Taşınan yüksek değerli sayfanın performansı düşerken toplam site trafiği yeni bir kampanyayla artabilir. Bu nedenle migrasyon etkisini segmentlemek gerekir.

Backlink hedeflerinin doğru yönlendiğini ve önemli yayınların mümkünse yeni URL’yi güncellediğini kontrol edin. Crawl istatistikleri, index coverage/indexing raporları, sitemap keşfi ve Core Web Vitals alan verisi zaman içinde okunur. Yeni performans ölçümleri için yeterli gerçek kullanıcı verisi oluşması beklenmelidir; yalnız tek Lighthouse koşusuyla karar verilmez.

Dalgalanmayı otomatik olarak başarısızlık saymayın; fakat “Google’ın işlemesini bekliyoruz” cümlesini de sonsuz erteleme aracı yapmayın. Hatalı redirect, noindex veya kayıp içerik gibi açıklanabilir neden varsa düzeltin. Teknik sinyaller doğru, yeni sayfa eşdeğer ve taranmışsa trendi belirlenen izleme penceresinde değerlendirin. İlk 30 gün sonunda kalan riskler için 60 ve 90 günlük aksiyon planı çıkarın.

Migrasyon raporu, yalnız toplam organik oturum grafiği olmamalıdır. Yönetim ekibi riskin iş etkisini, teknik ekip kök nedeni, SEO ekibi URL ve sorgu değişimini görebilmelidir. Bu nedenle aynı veri kaynağından üç görünüm üretin: yönetici özeti, operasyon hata panosu ve URL karşılaştırma tablosu. Yönetici özetinde kritik kayıp, dönüşüm etkisi, açık risk ve sonraki karar bulunur. Operasyon panosunda status code, redirect, indexability, form ve altyapı alarmları sahipleriyle listelenir.

Karşılaştırmayı eşit dönem mantığıyla yapın. Haftanın günleri, kampanyalar, tatiller ve mevsimsellik sonucu etkileyebilir. Eski URL ile yeni URL aynı satırda; tıklama, gösterim, sorgu sayısı, landing dönüşümü ve backlink bilgisiyle görünmelidir. URL birleşmişse eski sayfaların toplam tabanı yeni hedefle karşılaştırılır. Yeni bilgi mimarisinde bölünmüşse tek eski URL’nin değeri yeni hedef kümesine dağıtılır. Aksi hâlde bire bir grafik gerçeği yanlış temsil eder.

Her anomali aksiyon gerektirmez. Önce veri kalitesini doğrulayın: GA4 etiketi aynı mı, consent oranı değişti mi, Search Console property doğru mu, URL normalizasyonu raporu böldü mü? Ardından teknik kanıt arayın: eski URL hangi kodu veriyor, hedefin canonical’ı ne, içerik ilk HTML’de mi, internal link var mı, loglarda bot hedefe ulaşmış mı? Varsayıma dayalı içerik değişikliği yapmadan önce bu zinciri tamamlayın.

Karar günlüğü tutmak özellikle çok ekipli projelerde değerlidir. Her önemli değişiklik için tarih, sorumlu, gerekçe, etkilenen URL grubu, beklenen sonuç, rollback koşulu ve doğrulama bağlantısı kaydedilir. Redirect kuralı, canonical düzeltmesi veya içerik geri yüklemesi sonrasında metriklerin hangi tarihten itibaren yeniden değerlendirileceği yazılır. Böylece ekip aynı sorunu tekrar tartışmaz ve sonuçları yanlış deploy ile ilişkilendirmez.

Yayın sonrası iletişim de raporun parçasıdır. Satış ve müşteri hizmetleri eski bookmark, bozuk form veya içerik eksikliği geri bildirimlerini tek kanala iletebilmelidir. Dış paydaşlara yalnız etkiledikleri bağlantılar için güncelleme isteği gönderin. “Migrasyon tamamlandı” kararı deploy bittiğinde değil; yüksek öncelikli URL’ler, dönüşüm yolları ve indeksleme sinyalleri kabul kriterini karşıladığında verilmelidir.

Raporun sahipliği de açık olmalıdır. SEO ekibi veriyi yorumlar, geliştirme ekibi teknik düzeltmenin uygulanabilirliğini doğrular, analitik ekibi ölçüm sürekliliğini denetler ve ürün sahibi iş önceliğini belirler. Tek bir kişinin bütün katmanları varsayımla kapatması yerine kanıt bağlantıları ortak kayıtta tutulur. Kritik bir metrik düşerken teknik kontroller temiz görünüyorsa içerik kapsamı, arama niyeti ve yeni kullanıcı yolculuğu birlikte incelenir; sorun otomatik olarak algoritma değişikliğine bağlanmaz.

• Bütün eski URL’leri ana sayfaya yönlendirmek: Kullanıcı niyetini karşılamaz ve eşdeğerlik sinyali üretmez.
• Redirect listesini yayın sonrasına bırakmak: Yeni bilgi mimarisini ve geliştirme kabulünü yönlendirme kararından koparır.
• Staging noindex’ini production’a taşımak: Site 200 çalışsa bile indekslenmeyi engeller.
• Robots ile JavaScript/CSS dosyalarını engellemek: Arama sisteminin sayfayı kullanıcı gibi render etmesini zorlaştırır.
• Eski sitemap’i süresiz göndermek: Yayın niyetini eski URL’lerle karıştırır.
• Canonical’ı eski domain’e bırakmak: Redirect ve sitemap sinyalleriyle çatışır.
• Hreflang kümelerini bozmak: Yanlış locale’i veya 404/redirect hedefleri alternatif olarak sunar.
• Analytics kodunu veya event’leri unutmak: Ekip gerçek kullanıcı etkisini göremez.
• Formları yalnız görsel test etmek: Başarı mesajı görünürken e-posta veya CRM teslimatı başarısız olabilir.
• Domain, CMS ve içeriği kontrolsüz aynı anda değiştirmek: Sorunun hangi katmandan geldiğini ayırmayı zorlaştırır.
• Sunucu kapasitesini hesaba katmamak: Yeniden tarama ve kullanıcı yükünde 5xx artabilir.
• Yönlendirmeleri çok erken kaldırmak: Eski backlink, bookmark ve seyrek taranan URL’lerin yolunu keser.
• Yalnız masaüstünü test etmek: Mobile-first indeksleme bağlamında eksik içerik ve etkileşim hataları gözden kaçar.
• Her 404’ü redirect etmek: Gerçekten eşdeğeri olmayan içeriği ilgisiz hedefe taşır ve hata envanterini gizler.

SEO migrasyonu bir eklenti işi değil, web sitesi yenileme projesinin başlangıcından itibaren planlanması gereken bir risk yönetimi disiplinidir. URL haritası tasarım ve bilgi mimarisiyle; redirect geliştirme ve altyapıyla; canonical, hreflang ve schema içerik modeliyle; ölçüm ise iş hedefleriyle birlikte ele alınmalıdır.

İyi migrasyon görünmez çalışır: kullanıcı eski bağlantıdan doğru yeni kaynağa ulaşır, arama sistemi tutarlı sinyaller görür, ekip yayın günü neyi kontrol edeceğini bilir ve kayıp olduğunda sebebi araştırabilecek veriye sahiptir. Bu sonucu üreten şey tek bir araç değil; envanter, karar tablosu, teknik QA, kontrollü yayın ve disiplinli izlemenin birleşimidir. Kabul kriterlerini yazılı tutmak, sonraki yenilemelerde de tekrar kullanılabilecek kurumsal bir öğrenme kaydı oluşturur.