Web Sitesi Yenilerken SEO Nasıl Korunur? Trafik Kaybetmeden Site Yenileme Rehberi

Site yenileme kararını çoğu işletme tasarım toplantısında verir; ancak trafik kaybı çoğu zaman o toplantıda kimsenin aklına gelmeyen bir ayrıntıdan doğar. 2012'den beri onlarca yenileme projesinde yer aldım ve aynı hikâyeyi defalarca dinledim: yeni site çok güzel oldu, fakat Google'dan gelen ziyaretçi yarıya indi. Bu rehberde site yenileme sürecini bir taşınma gibi ele alıyorum. Çünkü sorun tasarımda değil, adres defterini taşımayı unutmakta.
Site yenileme sürecinde SEO nasıl korunur?
Site yenileme sırasında SEO'yu korumak için beş fazlı bir yöntem uygularım: önce envanter çıkarıp ölçümü dondururum, ardından eski ve yeni URL'leri eşleştiren bir harita hazırlarım, staging ortamında teknik kontrolleri bitiririm, lansman gününü saatlik bir protokolle yönetirim ve son olarak 90 gün boyunca Search Console verisini izlerim.
Bu beş faz sırayla ilerler; yani tasarım aşaması, envanter tamamlanmadan başlamaz. Özellikle küçük ve orta ölçekli işletmelerde en sık gördüğüm hata, tasarımcının işi bitince SEO'nun hatırlanmasıdır. Öte yandan yöntemi baştan kurduğunuzda ek maliyet neredeyse sıfırdır. Bu nedenle web tasarım projelerimi her zaman SEO planıyla birlikte yürütürüm.
- Birinci faz envanter ve ölçüm dondurma; mevcut sayfaları, trafiği ve sıralamaları kayda alırsınız.
- İkinci fazda URL ve içerik haritası çıkar; her eski adresin yeni karşılığını belirlersiniz.
- Üçüncü faz staging'de teknik eşleştirme; başlıkları, linkleri ve hızı yeni şablonda kontrol edersiniz.
- Dördüncü faz lansman günü protokolü; DNS, yönlendirmeler ve sunucu sağlığını saat saat izlersiniz.
- Beşinci faz 90 günlük izleme; Search Console raporlarını düzenli okuyup sapmaları düzeltirsiniz.
Site yenileme neden organik trafik kaybına yol açar?
Trafik kaybının arkasında genellikle beş kök neden vardır ve bunların hiçbiri tasarımın kendisiyle ilgili değildir. İlk olarak URL'ler değişir, fakat kimse eski adreslerden yenilerine yönlendirme kurmaz. İkinci olarak "artık gereksiz" diye silinen sayfalar aslında en çok backlink alan sayfalardır. Üçüncü neden, menü sadeleşince derin sayfaların iç link kaybetmesidir.
Dördüncü neden hız gerilemesidir; çünkü yeni temalar çoğu zaman daha ağır JavaScript ve büyük görsellerle gelir. Beşinci neden ise staging ortamının canlıya taşınırken noindex etiketi veya yanlış robots.txt dosyasıyla açılmasıdır. Bu beş sorunun ortak noktası şudur: hepsi lansmandan haftalar önce, birkaç saatlik dikkatle önlenebilir.
Saha tecrübeme dayanan bir gözlemi paylaşayım; garanti değil, başlangıç aralığı olarak okuyun. Yönlendirme haritası olmadan URL değiştiren sitelerde organik tıklamalar ilk ay içinde belirgin düşer ve toparlanma aylar sürer. Buna karşılık haritayı doğru kuran sitelerde dalgalanma birkaç haftayla sınırlı kalır. Fark, tasarım kalitesinden değil, hazırlıktan gelir.
Yenilemeden önce hangi verileri kaydetmelisiniz?
"Ölçüm dondurma" dediğim adım, yenilemeden önce sitenin fotoğrafını çekmektir. Çünkü lansmandan sonra "trafik düştü mü" sorusuna ancak bir kıyas noktanız varsa cevap verebilirsiniz. Ayrıca bu kayıtlar, hangi sayfalara dokunmayacağınızı belirlerken elinizdeki tek nesnel veridir.
- Search Console Performans raporunu 16 aylık aralıkla, sorgu ve sayfa kırılımında dışa aktarın.
- GA4'ten açılış sayfası listesini oturum, dönüşüm ve gelir sütunlarıyla indirin.
- Backlink alan sayfaların listesini çıkarın; bu sayfaları sildiğinizde otoriteyi de silersiniz.
- Hedef anahtar kelimeleriniz için sıralama anlık görüntüsü alın.
- Tüm siteyi bir tarayıcı yazılımıyla tarayıp başlık, meta açıklama, H1 ve canonical değerlerini kaydedin.
- Eski sitemap.xml dosyasının kopyasını saklayın; yönlendirme haritasının omurgası bu dosyadır.
- Tam dosya ve veritabanı yedeği alın, ardından geri yükleme testini gerçekten yapın.
Bu yedi adım çoğu site yenileme projesinde yarım günden kısa sürer. Yine de atlanınca lansman sonrası her tartışma "bana öyle geliyor" seviyesinde kalır; veriyle konuşmak için önce veriyi dondurmanız gerekir.
Hangi sayfaları korumalı, hangilerini birleştirmeli, hangilerini silmelisiniz?
Her sayfa için üç soru sorarım: trafik getiriyor mu, backlink alıyor mu, dönüşüm üretiyor mu? Üçünden birine "evet" diyorsanız sayfa korunacaklar listesine girer. Üçüne de "hayır" diyorsanız silme adayıdır; ancak benzer bir sayfa varsa silmek yerine birleştirmek daha güvenlidir.
Örnek hesap: 400 sayfalık bir site düşünün. Search Console'a göre organik tıklamaların yüzde 80'i yalnızca 60 sayfadan geliyor. Bu 60 sayfa "dokunulmaz" listesidir; URL'leri, başlıkları ve içerikleri olduğu gibi taşınır. Kalan 340 sayfanın 120'si benzer konuları tekrar ediyorsa bunları 40 güçlü sayfada birleştirirsiniz. Böylece 120 satırlık bir yönlendirme haritası ortaya çıkar.
- Koru: trafik, backlink veya dönüşüm sinyali taşıyan sayfalar.
- Birleştir: aynı niyeti karşılayan zayıf sayfalar; her biri güçlü sayfaya 301 ile gider.
- Sil: hiçbir sinyal taşımayan, güncelliğini yitirmiş sayfalar; yine de en yakın kategoriye yönlendirin.
Kısacası "sil" kararı bile çoğu zaman bir yönlendirme kararıdır. Sayfayı 404'e bırakmak yalnız içerik silmez, o adrese gelen dış linklerin değerini de çöpe atar.
URL yapısını değiştirmek zorunlu mu?
Hayır, çoğu yenilemede URL yapısını değiştirmek zorunlu değildir ve değiştirmemek en güvenli seçenektir. Google'ın site taşıma belgesi bu konuda net bir ilke verir: tek seferde yalnız bir şeyi değiştirin. Yani tasarımı, CMS'i ve URL'leri aynı gün değiştirmek, üç riski üst üste yığmaktır.
Ancak bazı durumlarda değişiklik kaçınılmazdır. Örneğin eski sistem /index.php?id=42 gibi parametreli adresler üretiyorsa ya da site yeni bir dile açılıyorsa yeni bir yapı gerekir. Bu durumda yeni adresleri slug oluşturucu ile kısa, Türkçe karaktersiz ve okunaklı biçimde üretirsiniz. Üstelik yeni yapıyı önce kâğıt üzerinde tasarlayıp sonra CMS'e aktarmak, geri dönüşü zor hataları önler.
Peki URL'ler aynı kalırsa yönlendirme haritasına gerek kalır mı? Büyük ölçüde hayır; fakat kaldırılan ve birleştirilen sayfalar için yine küçük bir harita gerekir. Bu nedenle "URL değişmiyor" cümlesi, haritayı tamamen atlamanın gerekçesi olmamalı.
301 yönlendirme haritası nasıl hazırlanır?
Site yenileme projesinin kalbi olan yönlendirme haritası, her eski adresin karşısına yeni adresi yazdığınız bir e-tablodur. Ben beş sütun kullanırım: eski URL, yeni URL, durum kodu, öncelik ve test sonucu. Öncelik sütununu Search Console tıklama verisinden doldururum; böylece lansman sonrası bir hata çıkarsa hangi satırı önce düzelteceğimi bilirim.
Haritada iki yasağım var. Birincisi zincir yasağı: eski adres yeni adrese doğrudan gitmeli, araya ikinci bir yönlendirme girmemeli. Google tarayıcıları varsayılan olarak en fazla 10 atlama izler; fakat her atlama zaman ve sinyal kaybıdır. İkincisi döngü yasağı: A sayfası B'ye, B sayfası A'ya giderse tarayıcı sonsuz döngüde kalır.
Google, URL değişikliği içeren taşımalarda yönlendirmelerin mümkün olduğunca uzun, genellikle en az bir yıl tutulmasını önerir. Dolayısıyla haritayı geçici bir dosya değil, sitenin kalıcı parçası olarak düşünün. Hazırladığınız satırları canlıya almadan önce yönlendirme denetleyici ile tek tek test edin; özellikle öncelikli satırların hepsini kontrol edin.
301 mi 302 mi? Yönlendirme türü sıralamayı nasıl etkiler?
Google'ın yönlendirme belgesine göre kalıcı yönlendirmeler (301 ve 308) hedef sayfanın kanonik kabul edilmesi için güçlü bir sinyaldir; geçici yönlendirmeler (302, 303, 307) ise bu sinyali vermez. Bu yüzden site yenilemede varsayılan tercih her zaman 301'dir. Aşağıdaki tabloda yönlendirme ve gizleme yöntemlerinin site yenilemedeki anlamını özetledim.
| Yöntem | Google için anlamı | Kullanım yeri | Site yenilemede risk |
|---|---|---|---|
| 301 / 308 | Kalıcı taşınma, hedef kanonik olur. | Eski URL'den yeni URL'ye taşıma. | Düşük; doğru hedef seçildiyse güvenli. |
| 302 / 307 | Geçici taşınma, kanonik sinyali yok. | Kısa süreli kampanya veya bakım. | Yüksek; eski URL dizinde kalmaya devam eder. |
| Meta refresh (0 sn) | Kalıcı yönlendirme gibi davranır. | Sunucu ayarına erişim yoksa. | Orta; kullanıcı deneyimi zayıf. |
| Gecikmeli meta refresh | Geçici yönlendirme etkisi verir. | Neredeyse hiçbir zaman. | Yüksek; sinyal taşımaz. |
| JavaScript yönlendirme | Ancak render sonrası etki eder. | Sunucu tarafı mümkün değilse. | Orta; gecikmeli ve kırılgan. |
| noindex | Sayfayı dizinden çıkarır. | Staging ve gizli sayfalar. | Yüksek; canlıda unutulursa site kaybolur. |
| robots.txt Disallow | Taramayı engeller, dizini engellemez. | Bütçe yönetimi. | Yüksek; noindex'i gizler. |
| HTTP auth | Tarayıcı içeriği göremez. | Staging ortamı. | Düşük; en temiz gizleme yöntemi. |
Tablodan çıkan ders şu: Google'ın yönlendirme belgesi sunucu tarafı 301'i açıkça öne çıkarır. JavaScript yönlendirmesini yalnız başka seçeneğiniz yoksa kullanın; çünkü tarayıcı önce sayfayı render etmek zorunda kalır.
Domain değişiyorsa Adres Değişikliği aracı ne zaman gerekir?
Search Console'daki Adres Değişikliği aracı yalnız domain veya alt alan adı değiştiğinde gerekir. HTTPS'e geçişte ya da www ile www'suz sürüm arasında geçişte bu aracı kullanmazsınız. Yani "sitemi yeniledim, aracı çalıştırayım" refleksi çoğu projede gereksizdir; araç yalnız adres defterinin ilk satırı değiştiğinde devreye girer.
Aracı kullanmak için iki şart var: her iki mülkü de kendi hesabınızda doğrulamalısınız ve aynı Google hesabını kullanmalısınız. Araç sinyalleri 180 gün boyunca yeni siteye aktarır. Ayrıca Google, yönlendirmeleri en az 180 gün, aramadan hâlâ trafik geliyorsa daha uzun tutmanızı ister.
- Önce yeni domaini Search Console'a ekleyip doğrulayın.
- Sonra tüm 301 yönlendirmelerini canlıya alın ve örnekleme yapın.
- En son eski mülkte Adres Değişikliği aracını başlatın.
Sıralama önemlidir; çünkü araç yönlendirmeleri kontrol eder ve eksik bulursa uyarı verir. Domain değişimini tasarım değişimiyle aynı güne koymamanızı özellikle öneririm.
Staging ortamı Google'a nasıl gizlenir, canlıya alırken nasıl açılır?
Staging ortamını gizlemenin en temiz yolu HTTP kimlik doğrulamasıdır; tarayıcı içeriği hiç göremez, dolayısıyla dizine hiçbir şey girmez. İkinci seçenek noindex etiketidir. En kötü seçenek ise yalnız robots.txt ile engellemektir; çünkü engellenen adres, dış linkler sayesinde arama sonuçlarında yine de görünebilir.
Burada kritik bir tuzak var. Google'ın belgesine göre noindex kuralının çalışması için sayfanın robots.txt ile engellenmemiş olması gerekir. Robots.txt ile engellediğiniz sayfada tarayıcı noindex etiketini hiç göremez. Yani iki yöntemi "daha güvenli olsun" diye üst üste kullanmak, aslında ikisini de etkisiz hale getirir.
Canlıya alırken tersi sorun yaşarsınız: staging'deki koruma yeni siteyle birlikte canlıya gelir. Bu nedenle lansmandan önce şu üç kontrolü mutlaka yapın.
- Şablondaki noindex etiketini kaldırdınız mı? Kaynak kodda "noindex" araması yapın.
- robots.txt canlı sürüm mü? Dosyayı robots.txt oluşturucu ile sıfırdan üretmek, staging kalıntısını önler.
- Canonical etiketleri staging domainine mi işaret ediyor? Bu hata çok sık çıkar ve bütün siteyi yanlış adrese bağlar.
Ardından XML sitemap oluşturucu ile yeni URL'lerden temiz bir sitemap üretip Search Console'a gönderirsiniz.
Başlık, meta açıklama ve H1'ler yeni tasarımda nasıl taşınır?
Şablon geçişinde en sessiz kaybı başlık ve meta alanlarında yaşarsınız. Yeni tema kurulunca eski SEO eklentisinin alanları boş kalır ya da tema kendi otomatik başlığını üretir. Sonuç olarak yıllardır sıralama getiren "Ankara'da nakliyat fiyatları" başlığı bir gecede "Hizmetler" olur. Bunu fark etmek haftalar alabilir.
Bu yüzden Faz 1'de aldığınız tarama çıktısı burada devreye girer. Her URL için eski başlık, meta açıklama ve H1 değerini yeni siteyle karşılaştırırsınız. Farklılık varsa iki seçenek vardır: eski değeri olduğu gibi geri yazmak ya da bilinçli bir iyileştirme yapmak. Ancak "tema böyle üretti" diye bırakmak seçenek değildir.
Yeni değerleri yazarken meta tag oluşturucu ile karakter sınırlarını, Google SERP önizleme ile de sonuç sayfasındaki görünümü kontrol edin. Özellikle koruma listesindeki 60 sayfada başlık değişikliğini lansmandan sonraya bırakın; böylece bir değişkeni daha aynı güne yığmamış olursunuz.
İç link yapısı ve menü değişince ne olur?
Yeni tasarımın ilk kurbanı genellikle menüdür. Tasarımcı haklı olarak 40 maddelik menüyü 6 maddeye indirir; ancak o 34 sayfa artık hiçbir yerden link almaz. Google bu sayfaları hâlâ tarayabilir, fakat iç link sinyali kaybolduğu için önemleri düşer. Buna "yetim sayfa" sorunu diyorum.
Çözüm menüyü geri şişirmek değil, iç link haritası kurmaktır. Örneğin menüden çıkan hizmet sayfalarını ana hizmet sayfasından, ilgili blog yazılarından ve footer'dan bağlarsınız. Böylece her önemli sayfaya en fazla üç tıkla ulaşılabilir kalır. Ayrıca gövde içindeki linkleri eski URL'den yeniye elle güncelleyin; yönlendirmeye güvenmek her tıkta bir atlama ekler.
- Menüden çıkan her sayfa için en az iki alternatif iç link belirleyin.
- Footer'ı kategori düzeyinde sayfalarla doldurun, tekil ürünleri oraya yığmayın.
- Blog yazılarındaki eski iç linkleri toplu bul-değiştir ile yeni adreslere çevirin.
Yeni tema Core Web Vitals'ı geriletir mi?
Geriletebilir; hatta çoğu zaman geriletir. Google'ın Core Web Vitals eşikleri nettir: LCP ilk 2,5 saniye içinde, INP 200 milisaniyenin altında, CLS 0,1'in altında olmalı. Google bu metriklerin temel sıralama sistemlerinin ödüllendirmek istediği şeyle örtüştüğünü belirtir. Yani hız, tasarımın yan etkisi değil, sıralamanın parçasıdır.
INP metriği 12 Mart 2024'te FID'in yerini aldı ve sayfa ömrü boyunca tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözler. Bu nedenle kaydırma animasyonları, ağır slider'lar ve her tıkta çalışan JavaScript kütüphaneleri yeni temanın en riskli parçalarıdır. Eski site sade olduğu için iyi ölçülüyorsa yeni sitenin "daha güzel" olması bu avantajı silebilir.
Ölçüm için iki katman kullanırım. Staging'de Lighthouse ile laboratuvar verisini alır, en kötü beş sayfayı düzeltirim. Lansmandan sonra ise CrUX alan verisini izlerim; çünkü gerçek kullanıcı ölçümü laboratuvar sonuçlarından farklı çıkabilir. Karşılaştırmayı her zaman eski sitenin aynı sayfalarıyla yapın, mutlak puanla değil.
JavaScript tabanlı tasarım SEO için risk mi?
React, Vue veya headless mimari tek başına risk değildir; risk, render stratejisini düşünmeden seçmektir. Google JavaScript'i üç aşamada işler: tarama, render kuyruğu ve dizinleme. Render kuyruğunda bekleme birkaç saniye olabilir, ama daha uzun da sürebilir. Dolayısıyla içerik yalnız tarayıcıda oluşuyorsa Google'ın onu görmesi gecikir.
Google sunucu tarafı render veya ön-render'ı hâlâ harika bir fikir olarak tanımlar. Benim tavsiyem de aynı: yeni site tek sayfa uygulaması olacaksa SSR veya statik üretim şart. Ayrıca anlamlı HTTP durum kodları kullanın; olmayan bir ürün için 200 dönen sayfa "soft 404" olur ve dizin kalitesini düşürür.
- Staging'de URL Denetimi aracıyla render edilmiş HTML'i kontrol edin; içerik orada görünmüyorsa Google da görmez.
- JavaScript kapalıyken ana içerik ve iç linkler okunabiliyor mu diye test edin.
- Olmayan sayfalar için gerçek 404, yetkisiz alanlar için 401 döndürün.
Site yenileme için en doğru zamanlama nedir?
Site yenileme için en doğru zaman, işletmenizin en düşük trafikli dönemidir. Google'ın kendi taşıma belgesi bile taşımayı düşük trafikli döneme denk getirmenizi önerir. Çünkü orta ölçekli bir sitede Google'ın eski URL'ler yerine yenilerini göstermeye başlaması birkaç hafta veya daha fazla sürebilir. Bu dalgalanmayı sezon ortasında yaşamak istemezsiniz.
Tek değişken kuralı burada da geçerlidir. Örneğin e-ticaret sitesini Kasım kampanyası öncesinde, hem tasarım hem CMS değiştirerek yenilemek, en kötü senaryoyu davet eder. Bunun yerine tasarımı yazın, URL düzenlemesini ayrı bir tarihte, domain değişimini ise hiç gerekmiyorsa asla yapın.
Ayrıca reklam takvimine bakın. Google Ads yönetimi yaptığım müşterilerde lansmanı kampanya bütçesinin yüksek olduğu haftalardan uzak tutarım; çünkü yönlendirme hatası yalnız organik trafiği değil, tıklama başına ödediğiniz reklam trafiğini de 404 sayfasına gönderir. Reklam final URL'lerini de haritanın bir sütunu gibi düşünün.
Lansman günü kontrol listesi nasıl olmalı?
Lansman gününü saatlik bir protokolle yönetirim; çünkü bu günde yapılan bir hata haftalarca iz bırakır. Özellikle sunucu hataları kritik: Google'a göre 5xx hataları taramayı geçici olarak yavaşlatır ve sunucu yeniden 2xx dönünce tarama hızı kademeli artar. Yani lansman günündeki kısa bir çökme bile tarama bütçesini doğrudan etkiler.
- DNS TTL değerini bir gün önceden düşürün; böylece geçiş dakikalar içinde tamamlanır.
- Bakım moduna 503 kodu ile girin, asla 200 dönen "yakında" sayfası kullanmayın.
- Yönlendirme haritasını sunucuya yükleyin ve öncelikli satırları anında örnekleyin.
- Sunucu log'unu 5xx ve 404 için canlı izleyin.
- noindex, robots.txt ve canonical kontrolünü canlı domainde tekrarlayın.
- Yeni sitemap'i Search Console'a gönderin, eskisini kaldırmayın.
- Analytics ve dönüşüm etiketlerinin yeni şablonda çalıştığını test edin.
- Ana sayfa, en çok trafik alan 20 sayfa ve iletişim formunu elle deneyin.
- URL Denetimi ile üç önemli sayfada canlı test yapın.
- Günün sonunda tüm haritayı yönlendirme denetleyicisinden tekrar geçirin.
Site yenileme günü bu on madde bitmeden ekibe "bitti" demem. Üstelik listeyi yazdırıp masaya koymak, o günkü stresle bir adımı atlamayı önler.
Lansmandan sonra Search Console'da neyi izlemelisiniz?
İlk iki hafta günlük, sonraki on hafta haftalık bakarım. Günlük izlemede üç rapor var: Sayfa dizine ekleme raporu, tarama istatistikleri ve Performans raporu. Sayfa dizine ekleme raporunda "Bulunamadı (404)" ve "Yönlendirme içeren sayfa" satırlarındaki ani artış, haritadaki eksik satırların en hızlı sinyalidir.
URL Denetimi aracı burada en yakın dostunuzdur. Bir adresin dizin durumunu, son tarama tarihini ve hangi Googlebot'un taradığını gösterir; canlı URL testiyle yönlendirmelerin çalışıp çalışmadığını tek tek doğrularsınız. Örneğin en değerli 20 sayfayı lansmanın ertesi günü bu araçla kontrol etmek, haftalar sürecek belirsizliği bir saate indirir.
Beklentiyi doğru kurun: Google'ın yeni URL'leri eski adreslerin yerine göstermesi birkaç hafta veya daha fazla sürebilir. Bu dönemde tıklamalarda dalgalanma normaldir. Ancak üçüncü haftada hâlâ düşüş sürüyorsa teknik bir sorun vardır. Böyle durumlarda SEO danışmanlığı kapsamında yaptığım ilk iş, raporları tek tek bu sırayla okumaktır.
Trafik düştüyse ilk 72 saatte ne yaparsınız?
Site yenileme sonrası düşüşte panik yerine beş adımlık bir teşhis sırası uygularım. Sıra önemlidir; çünkü en sık görülen hatalar en başta yer alır ve çoğu zaman ilk iki adımda sorun ortaya çıkar.
- Search Console 404 raporunu açın ve hangi eski adreslerin hata verdiğini listeleyin.
- Yönlendirme testini yapın; 404 dönen adresler haritada var mı, varsa doğru hedefe mi gidiyor?
- noindex ve robots.txt kontrolünü tekrarlayın; staging kalıntısı hâlâ en yaygın suçludur.
- Canonical etiketlerini örnekleyin; yanlış domain veya yanlış sayfaya işaret eden etiketleri düzeltin.
- Hız verisini karşılaştırın; LCP ve INP eski siteye göre gerilediyse en ağır bileşenleri kaldırın.
Örnek hesap: lansmandan sonra 200 URL'nin 15'i 404 dönüyor. Eğer bu 15 sayfa eski toplam tıklamanın yüzde 22'sini taşıyorsa, öncelik sırasını tıklama payına göre kurarsınız. Yani en çok tıklanan üç sayfa önce düzelir, geri kalanları aynı gün içinde bitirirsiniz. Bu yaklaşım, toparlanma süresini belirgin biçimde kısaltır; garanti değil, ama sahada tekrar tekrar gördüğüm bir örüntü.
Çok dilli siteler yenilenirken hreflang nasıl korunur?
Kendi sitem üç dilde yayında; bu nedenle çok dilli yenilemenin tuzaklarını bizzat yaşadım. En kritik kural şudur: hreflang etiketleri karşılıklı olmalı. Türkçe sayfa İngilizce sürümü gösteriyorsa İngilizce sayfa da Türkçe sürümü göstermeli. Yenilemede bir dilin URL'leri değişip diğerininki değişmezse bu karşılıklılık bozulur.
Bu yüzden yönlendirme haritasını dil başına ayrı sekmede tutarım. Ayrıca her dilin yeni URL'sini hreflang setine aynı anda yazarım; aksi halde Google bir süre eski ve yeni adresleri karışık görür. Yeni etiketleri hreflang oluşturucu ile üretmek, dil ve bölge kodu hatalarını baştan önler.
- Üç dilin lansmanını aynı güne koyun; aksi halde eşleşme haftalarca bozuk kalır.
- Her dilin sitemap'ini ayrı gönderin, fakat hreflang bilgisini ortak tutun.
- x-default değerini yeni ana sayfaya işaret edecek şekilde güncelleyin.
E-ticaret sitesinde ürün ve kategori URL'leri nasıl korunur?
E-ticaret yenilemesi, sıradan siteye göre üç kat daha fazla URL barındırır; çünkü ürün, kategori ve filtre sayfaları birlikte gelir. Öncelik kategori sayfalarıdır: genellikle en çok organik trafiği bunlar taşır. Ürün URL'lerinde ise SKU veya benzersiz bir kimlik kullanmak, gelecekteki yenilemelerde haritayı otomatik üretmenizi sağlar.
Filtre ve parametre URL'leri site yenileme planında ayrı bir başlıktır. Eski sistemde ?renk=mavi&beden=m gibi binlerce adres dizine girmiş olabilir. Yeni sistemde bunları canonical ile ana kategoriye bağlayın; hepsine tek tek yönlendirme yazmaya gerek yok. Ancak trafik alan birkaç filtre sayfası varsa onları koruyun.
Stokta olmayan ürünler için de kural belirleyin. Geri gelecek ürün 200 kodla açık kalır ve "stokta yok" der; kalıcı olarak kalkan ürün en yakın kategoriye 301 ile gider. E-ticaret danışmanlığı projelerimde bu iki kuralı yenilemeden önce yazılı hale getiririm; böylece yazılım ekibi her ürünü ayrı ayrı sormak zorunda kalmaz.
Site yenileme işini ajansa mı verirsiniz, kendiniz mi yaparsınız?
Dürüst cevap: ikisi de olur, ama sorumluluk sınırını baştan yazmanız şartıyla. Site yenileme işini ajansa verdiğinizde çoğu teklif "tasarım ve kodlama" kapsar; yönlendirme haritası, ölçüm dondurma ve 90 günlük izleme ise sözleşmede yoktur. Sonuç olarak trafik düşünce herkes birbirine bakar.
Kendiniz yapacaksanız beş fazlı yöntemi olduğu gibi uygulayabilirsiniz; araçların çoğu ücretsizdir ve teknik bilgi gerektiren tek adım sunucu tarafı yönlendirmelerdir. Öte yandan sitede 500'den fazla sayfa, çok dil veya e-ticaret varsa dışarıdan destek almak zaman kazandırır. Ben aracısız çalıştığım için müşteriyle doğrudan bu listeyi paylaşır, her fazın sorumlusunu birlikte belirlerim.
- Teklifte "301 yönlendirme haritası" satırı yoksa ekletin.
- Lansman sonrası en az 30 gün izleme desteği isteyin.
- Eski sitenin yedeğinin kimde kalacağını yazılı belirleyin.
Bütçe planlaması için web sitesi yaptırma fiyatları sayfamda güncel aralıkları bulabilirsiniz.
Yeni site ne zaman başarılı sayılır?
Doksanıncı günde üç metriği eski siteyle kıyaslarım: sıralama getiren sorgu sayısı, organik tıklama ve dönüşüm. Sorgu sayısı aynı kalmış, tıklama eski seviyeye dönmüş ve dönüşüm oranı artmışsa site yenileme başarılıdır. Tasarım ödülleri, beğeni sayısı veya "çok güzel olmuş" yorumları bu listeye girmez.
Beklenti aralığını da dürüstçe paylaşayım; bunlar saha tecrübesine dayalı başlangıç aralıklarıdır, garanti değildir. Haritası eksiksiz olan sitelerde ilk dört haftada dalgalanma görür, sekizinci haftada eski seviyeyi yakalar, doksanıncı günde ise güçlendirdiğiniz sayfalar sayesinde küçük bir artış beklerim. Haritası eksik sitelerde bu takvim aylara uzar.
Kısacası site yenileme bir tasarım işi değil, taşınma işidir. Adres defterini taşımadan eve taşınmayın. Yenileme planlıyorsanız ve trafik kaybı endişeniz varsa iletişim sayfasından bana ulaşın; mevcut sitenizin envanterine birlikte bakıp beş fazı takvime oturtalım.




