Web Sitesi Yenileme (Redesign): Ne Zaman, Nasıl? 2026

Web sitesi yenileme (redesign), mevcut sitenizi sıfırdan kurmadan görünümünü, kullanıcı deneyimini, performansını ve teknik altyapısını güncel standartlara taşıma sürecidir. Pratikte üç seviyesi vardır: yüzeysel "tazeleme" (renk, tipografi, görsel düzeni yenileme), UX/yapısal yenileme (bilgi mimarisi, akış, dönüşüm hunisi) ve yapısal "yeniden inşa" (altyapı/CMS, kod tabanı, çoğu zaman URL yapısı değişimi). Sitenizi ne zaman yenilemeniz gerektiğinin en net cevabı şudur: site artık iş hedefinizi karşılamıyorsa — mobilde bozuksa, yavaşsa (Core Web Vitals'ı geçemiyorsa), dönüşüm üretmiyorsa, markanızı temsil etmiyorsa veya güvenlik/yasal açıdan riskliyse. Yenileme bir "moda kararı" değil, ölçülebilir sinyallere dayanan bir iş kararıdır; estetik beğeni tek başına yeterli gerekçe değildir. Bu bölümde redesign'ın ne olduğunu, hangi somut sinyallerin yenileme zamanı geldiğini gösterdiğini, "yenileme mi yoksa küçük iyileştirme mi" kararını nasıl vereceğinizi ve doğru kapsamı seçmenin bütçe ile SEO üzerindeki etkisini danışman gözüyle açıklıyoruz.

Web sitesi yenileme (redesign) nedir?

Web sitesi yenileme, en geniş anlamıyla mevcut bir sitenin tasarımını, içerik düzenini, teknik altyapısını ya da bunların hepsini güncelleme işidir. Ama bütün redesign'lar aynı kapsamda değildir ve karıştırmak hem bütçenizi hem de SEO'nuzu yanlış yönlendirir. Müşterilerimizde gördüğümüz en sık hata, aslında küçük bir UI tazelemesi yeterliyken sitenin tamamen sıfırdan yapılması — ya da tam tersi, altyapı çürümüşken sadece "boya badana" yapılıp sorunun bir yıl içinde geri gelmesidir.

Redesign'ı "sürekli iyileştirme"den ayırmak da önemlidir. Sağlıklı bir site zaten her ay küçük dokunuşlarla (yeni içerik, A/B testleri, hız iyileştirmeleri) evrilir; buna "iterative redesign" denir ve risk düşüktür çünkü değişiklikler kademeli ölçülür. "Big bang" yenileme ise her şeyin tek seferde değiştiği, yayın gününde geri dönüşü zor olan yaklaşımdır. Müşterilerimize çoğu zaman, mümkün olan yerde kademeli yenilemeyi öneririz; çünkü tek seferlik dev bir lansman, hem SEO hem dönüşüm açısından tüm yumurtaları aynı sepete koymak demektir.

Tazeleme, yapısal yenileme ve yeniden inşa farkı nedir?

Doğru kapsamı seçmek redesign'ın en kritik kararıdır; bu yüzden üç seviyeyi ayrı tanımlıyoruz:

• Yüzeysel tazeleme (visual refresh): İçerik ve URL yapısı korunur; renk paleti, tipografi, buton stilleri, görsel hiyerarşi ve birkaç bileşen güncellenir. Marka kimliği tazelenir ama "iskelet" aynı kalır. En düşük risk, en kısa süre; SEO'ya neredeyse dokunmadığı için en güvenli seviyedir.
• UX/yapısal yenileme: Bilgi mimarisi (menü, sayfa hiyerarşisi, kullanıcı akışları) yeniden kurgulanır; dönüşüm hunisi sadeleştirilir, formlar ve CTA'lar elden geçirilir. Görünüm kadar "nasıl çalıştığı" değişir. Bu seviyede UI ile UX'i ayrı düşünmek kritik; iyi bir görsel katman kötü bir akışı kurtaramaz. Bilgi mimarisi değiştiği için bazı URL'ler de değişebilir, dolayısıyla 301 disiplini devreye girer. Bu ayrımın detayını UI/UX tasarım nedir, nasıl yapılır yazımızda açıklıyoruz.
• Yeniden inşa (rebuild / replatform): Altyapı/CMS değişir (örneğin eski, eklenti şişmesinden yorulmuş bir WordPress'ten yönetilen hosting'e ya da Next.js gibi modern bir özel yazılıma geçiş), kod tabanı yenilenir, çoğu zaman URL yapısı da değişir. En yüksek değer potansiyeli ama en yüksek risk; burada 301 yönlendirme disiplini olmadan ciddi SEO kaybı yaşanır.

Bu üç seviyeyi tek bir tabloda yan yana koyduğumuzda, hangi durumda neyi beklemeniz gerektiği netleşir:

Doğru kapsamı seçmek için önce "sorun nerede?" sorusuna dürüst cevap vermek gerekir. Site güzel görünüyor ama yavaşsa, çözüm renk değişimi değil performans/altyapı müdahalesidir. Site hızlı ama eski ve markayı temsil etmiyorsa, tam rebuild yerine tazeleme yeterli olabilir. Bu yüzden her yenileme bir denetimle başlamalı — neyin çalıştığını, neyin çalışmadığını ölçmeden tasarıma geçmek, sıfırdan bir site kurmanın temel adımlarını atlamak demektir; o adımları web sitesi nasıl yapılır 2026 rehberi yazımızda sıralıyoruz. Yenileme maliyetinin neye göre değiştiğini merak ediyorsanız web tasarım fiyatları 2026 ve özel yazılım maliyeti neye göre belirlenir yazılarımız kapsam-bütçe ilişkisini somutlaştırır.

Web sitenizi ne zaman yenilemelisiniz? Yenileme sinyalleri

Yenileme kararı duyguyla değil, gözlemlenebilir sinyallerle verilmelidir. Aşağıdaki sinyallerden biri tek başına bile güçlü bir gerekçe olabilir; ikisi veya daha fazlası bir araya geldiğinde yenilemeyi ertelemek genelde para kaybettirir. Müşterilerimizde en çok karşılaştığımız tetikleyiciler şunlardır:

• Mobilde bozuk veya zayıf deneyim: Mobil cihazlar 2026 itibarıyla küresel web trafiğinin yaklaşık %60'ını oluşturuyor (Türkiye gibi pazarlarda bu oran %80'e kadar çıkabiliyor — yaklaşık değerler, kaynağa ve döneme göre değişir). Üstelik Google artık varsayılan olarak sitenin mobil sürümünü indeksleyip sıralıyor (mobile-first indexing). Siteniz masaüstünde iyi ama mobilde taşıyor, dokunma hedefleri küçük (WCAG 2.2 SC 2.5.8 asgari 24x24 CSS piksel ister; pratikte 44-48px öneririz) ya da metin okunmuyorsa, bu hem deneyim hem de doğrudan SEO kaybıdır. Mobil-öncelikli yaklaşımı mobil uyumlu responsive web tasarım rehberi yazımızda ele alıyoruz.
• Yavaşlık ve başarısız Core Web Vitals: Google'ın "iyi" eşikleri net (75. yüzdelik saha verisi): LCP (en büyük içeriğin görünme süresi) 2,5 saniye veya altı, INP (etkileşime yanıt hızı) 200 ms veya altı, CLS (beklenmedik kayma) 0,1 veya altı. Not: INP, 12 Mart 2024'te FID'in yerini alarak resmî bir Core Web Vital oldu ve etkileşim performansını çok daha kapsamlı ölçüyor. Siteniz bu eşikleri saha verisinde geçemiyorsa — özellikle ağır eklentiler, optimize edilmemiş hero görselleri (LCP'yi bozar) veya şişmiş JavaScript (INP'yi bozar) yüzünden — bu güçlü bir yenileme sinyalidir. Hızın SEO ile ilişkisini site hızı ve SEO Core Web Vitals rehberi yazımızda detaylandırıyoruz; sitenizin mevcut durumunu PageSpeed Insights ile nasıl iyileştirirsiniz yazısından ölçmeye başlayabilirsiniz.
• Düşük dönüşüm, yüksek hemen çıkma: Ziyaretçi geliyor ama lead/satış/iletişim üretilmiyorsa, sorun çoğu zaman trafikte değil tasarımdadır. Belirsiz değer önerisi, zayıf ya da çok sayıda rakip CTA (Hick Yasası: seçenek arttıkça karar süresi uzar), sürtünmeli formlar, güven öğelerinin eksikliği dönüşümü öldürür. İyi tasarımın dönüşümle ilişkisini iyi web tasarımı nasıl olmalı yazımızda anlatıyoruz; dönüşüm odaklı düzen için dönüşüm odaklı landing page rehberi ve e-ticaret tarafında dönüşüm oranını artırma (CRO) rehberi iyi başlangıçlardır.
• Eski, demode görünüm ve marka kopukluğu: Tasarım dili 4-5 yıl öncesinin kalıplarında takılıysa, logo/renk/ton güncel marka kimliğinizle uyuşmuyorsa, ziyaretçi daha ilk saniyelerde "bu firma güncel mi?" sorusunu sorar. 2026'nın yönü gösterişten çok hız, sadelik ve net hiyerarşi; demode efektler değil, içeriğe odaklı "sakin" arayüzler ve açık/koyu tema desteği öne çıkıyor. Burada dikkat: kalıcı ilke (hız, erişilebilirlik, mobil-öncelik, net hiyerarşi) ile geçici moda (belirli animasyon/glassmorphism akımları) ayrımını koruyun; trend ilkenin yerini almaz.
• İçeriğin yönetilemez hale gelmesi: Basit bir metin ya da görsel güncellemesi için her seferinde geliştiriciye ihtiyaç duyuyorsanız, altyapınız ekibinizi yavaşlatıyor demektir. Bu, doğru bir CMS'e geçişi gerektiren klasik bir yenileme nedenidir. Hangi altyapının size uyduğunu CMS nedir, hangi CMS seçilmeli yazımızda karşılaştırıyoruz; WordPress hâlâ tüm web'in yaklaşık %41,9'unu çalıştırsa da, eklenti şişmesi yönetilemez hale geldiyse modern bir altyapı daha sürdürülebilir olabilir.
• Güvenlik ve yasal uyumsuzluk: Güncellenmemiş CMS çekirdeği, terk edilmiş üçüncü taraf eklentiler (OWASP Top 10:2025'te tedarik zinciri artık A03 olarak ayrı bir başlık), HTTPS eksikliği ya da KVKK/çerez metinlerinin yetersizliği hem teknik hem hukuki risktir. KVKK m.12 veri güvenliği tedbirlerini yasal zorunluluk kılar; ayrıca aydınlatma metni ile açık rıza/ticari ileti izninin ayrı düzenlenmesi gerektiği güncel Kurul kararıyla (KVKK'nın güncel İlke Kararı) pekiştirildi. Bunlardan biri eksikse yenileme artık ertelenebilir değildir. Güvenlik tarafının çerçevesini web sitesi güvenliği nedir, nasıl sağlanır yazımızda bulabilirsiniz.
• Erişilebilirlik ve EAA uyumsuzluğu: Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025'te yürürlüğe girdi; EN 301 549 ve dolayısıyla WCAG 2.1 AA uyumu zorunlu. AB'ye ürün/hizmet satan Türkiye firmaları da (e-ticaret, e-kitap, bankacılık, ulaşım vb.) kapsama girebilir; piyasada olan eski hizmetler için geçiş 28 Haziran 2030'a kadar. Düşük kontrast, alt metni olmayan görseller, etiketsiz form alanları gibi en sık hatalar hem yasal hem dönüşüm riskidir. Bu konuyu web erişilebilirliği (accessibility) nedir, nasıl sağlanır yazımızda detaylandırıyoruz.

Altyapı ve domain/hosting tarafı yenilemeyi nasıl tetikler?

Yenileme sinyalleri her zaman görünür değildir; bazıları "kaputun altında" birikir. Eski bir paylaşımlı hosting'in artan yanıt süreleri (TTFB), süresi geçmiş ya da yanlış yapılandırılmış SSL sertifikaları, terk edilmiş eklenti bağımlılıkları ve yedeği alınmayan bir altyapı, görünürde iyi çalışan bir sitenin altında biriken risklerdir. Bu tür durumlarda yenileme çoğu zaman görsel değil teknik bir karardır: modern bir edge/CDN katmanına, yönetilen hosting'e ya da statik/JAMstack barındırmaya geçiş hem hızı hem güvenliği baştan kazandırır. Domain, hosting ve SSL'in birbirinden bağımsız yönetilmesi (taşınabilirlik için) yenileme sırasında değerlendirmeniz gereken bir konudur; bu temel kararları domain, hosting, SSL altyapı rehberi yazımızda ele alıyoruz. Mevcut altyapınızı hızlıca tespit etmek için e-ticaret altyapı tespit ve domain sorgulama araçlarımızdan yararlanabilirsiniz.

Yenileme mi, küçük iyileştirme mi? Karar kriteri

Her sinyal tam yenilemeyi gerektirmez. Asıl beceri, tam rebuild ile hedefli iyileştirme arasında doğru çizgiyi çekmektir. Aşağıdaki tablo, müşterilerimize önerdiğimiz karar mantığını özetler:

Pratik kural şudur: Sorun tek bir sayfada ya da tek bir bileşendeyse, önce o noktayı iyileştirin — tüm siteyi yenilemek hem pahalı hem risklidir (URL değişirse SEO'yu tehlikeye atarsınız). Ama sorun yapısal ve birden çok katmana yayılmışsa (görünüm + hız + dönüşüm + altyapı), parça parça müdahale yerine bütünsel bir yenileme uzun vadede daha ekonomiktir. Burada kritik bir uyarı: Yenileme "iyi çalışan şeyleri silmek" değildir. İyi performans gösteren sayfaları, dönüşüm getiren metinleri ve sıralamada olan içeriği korumak, redesign'ın en önemli disiplinlerinden biridir — bu yüzden her yenileme bir analiz/denetim adımıyla başlamalıdır.

Redesign'ın görünmez maliyeti: SEO kaybı riski

Yenileme kararının en çok hafife alınan tarafı SEO maliyetidir. Çok sayıda firma, "daha güzel" bir site için yola çıkıp, yanlış yönetilen bir yenilemeden sonra organik trafiğinin önemli bir kısmını kaybeder. Çünkü görünüm değişirken URL yapısı, başlık etiketleri, iç linkleme ve mevcut backlink değeri farkında olmadan bozulur. Bu riski sıfırlamanın yolu basit ama disiplin ister: URL yapısı değişiyorsa eski adreslerden yenilerine kalıcı 301 yönlendirme şarttır; iyi performans gösteren içerik haritalanıp korunmalı; yayın sonrası sitemap Search Console'a yeniden gönderilmeli ve 404'ler izlenmelidir. Bu disiplinin teknik tarafını teknik SEO denetimi nasıl yapılır ve genel çerçeveyi SEO nedir, nasıl yapılır 2026 rehberi yazılarımızda ele alıyoruz. Kısacası: bir redesign'ı sadece "görsel proje" olarak görmek, en pahalı yenileme hatasıdır.

Kararsız kaldığınızda: önce ölçün, sonra karar verin

Kararsız kaldığınız noktada en sağlıklı yol, "tahmin" yerine ölçüme dayanmaktır: Mevcut sitenizin hız, mobil uyum, dönüşüm ve teknik sağlık durumunu objektif bir denetimden geçirin. Üç soruyu netleştirin — sorun görünümde mi, akışta mı, yoksa altyapıda mı? Sorun kaç katmana yayılmış? Mevcut URL ve sıralamaların ne kadarı korunmalı? Bu üç sorunun cevabı, hem kapsamı (tazeleme mi, yapısal mı, rebuild mi) hem de bütçeyi belirler. Sitenizin yenilemeye gerçekten ihtiyacı olup olmadığını ve hangi kapsamda olması gerektiğini netleştirmek için ücretsiz site analizi üzerinden başlayabilir; kapsam belirlendikten sonra UI/UX ve geliştirme tarafını web ve mobil UI/UX tasarımı hizmetimizle, altyapı/replatform gerekiyorsa özel yazılım ve web sitesi hizmetimizle hayata geçirebilirsiniz. Doğru teşhis, doğru yenilemenin yarısıdır; gereğinden fazlasını yapmak da, gereken müdahaleyi ertelemek de maliyetlidir.

SEO Kaybetmeden Yenileme: URL Yapısı, 301 Yönlendirme ve İçerik Nasıl Korunur?

Site yenilemenin en büyük gizli riski tasarım değil, SEO kaybıdır: yanlış yürütülen bir redesign, yıllarca biriktirdiğiniz organik trafiği ve geri bağlantı (backlink) değerini bir gecede sıfırlayabilir. Kısa cevap şudur: mevcut URL'lerinizi mümkün olduğunca koruyun; değiştirmek zorundaysanız her eski adresi yeni adresine kalıcı 301 yönlendirmeyle bağlayın; iyi performans gösteren içeriği silmeyin, taşıyın. Müşterilerimizde gördüğümüz trafik düşüşlerinin neredeyse tamamı yeni tasarımın "çirkin" olmasından değil, bu üç kuralın atlanmasından kaynaklanır. Bu bölümde yenilemeyi sıralamanızı zedelemeden nasıl yürüteceğinizi adım adım, somut kontrol listeleriyle anlatıyoruz.

Önce zihinsel çerçeveyi netleştirelim. Google bir sayfayı URL'siyle tanır; sıralama gücünü (otorite, geri bağlantılar, içerik alaka sinyalleri) o URL'de biriktirir. Yenileme sırasında URL değişir ve eski adresten yeni adrese düzgün bir köprü kurulmazsa, Google eski URL'yi "kayıp" (404) olarak görür, yeni URL'yi ise sıfırdan değerlendirmeye başlar. Yani teknik olarak yepyeni bir sayfa yayınlamış olursunuz. İşte 301 yönlendirme tam burada devreye girer: "bu içerik kalıcı olarak şu yeni adrese taşındı" der ve biriken değerin büyük kısmını yeni URL'ye aktarır. Bu yüzden bir yenileme projesini "görsel tazeleme" değil, "değer taşıma operasyonu" olarak görmek gerekir; tasarımcı ne kadar yetenekli olursa olsun, taşıma planı kötüyse sonuç organik trafikte düşüştür.

Bir önemli ayrımı baştan koyalım: yenileme (redesign) ile platform/altyapı taşıma (replatform) çoğu zaman aynı projede iç içe geçer ama riskleri farklıdır. Yalnızca görünüm değişiyorsa risk düşüktür; CMS veya altyapı da değişiyorsa (örneğin WordPress'ten özel yazılıma geçiş) URL kalıpları, sayfa şablonları ve sunucu davranışı topluca değişir, dolayısıyla SEO riski katlanır. Hangi senaryoda olduğunuzu net görmek, ne kadar titizlik gerektiğini de belirler.

URL Yapısını Korumak mı, Değiştirmek mi Daha İyi?

En güvenli yol URL yapısını hiç değiştirmemektir. Tasarımı, şablonu, CMS'i baştan kurabilir; ama bir sayfanın adresi olan alanadi.com/hizmetler/web-tasarim aynı kaldığı sürece o sayfanın SEO geçmişi de yerinde kalır. Bu nedenle ilk kararınız şu olmalı: "URL'leri gerçekten değiştirmem gerekiyor mu?" Çoğu yenilemede cevap hayırdır. Yalnızca görünüm, hız ve içerik kalitesi yenileniyorsa URL'lere dokunmamak en akıllıcasıdır. Bir URL'yi "daha güzel görünsün" diye değiştirmenin SEO maliyeti, çoğu zaman estetik kazancından çok daha büyüktür.

Ancak bazı durumlarda URL değişikliği kaçınılmazdır. Bunların başlıcaları şunlardır:

• CMS/altyapı değişimi: WordPress'ten özel yazılıma (Next.js gibi) veya tam tersi bir geçişte URL kalıpları sıklıkla değişir; örneğin tarih içeren blog adresleri (/2023/05/baslik) sade adreslere (/blog/baslik) taşınır.
• Bilgi mimarisi (IA) yeniden kurgusu: Kategori ağacı sadeleşir, sayfalar birleştirilir veya bölünür; bu da yolu (path) değiştirir. UI/UX tasarımının temelindeki bilgi mimarisi prensipleri burada da geçerlidir: kullanıcı için daha iyi bir yapı kurarken SEO köprülerini ihmal etmeyin.
• Dil/protokol/alan adı değişimi: HTTP'den HTTPS'e geçiş, www'lı ve www'suz sürüm birleştirme, ya da alan adı değişikliği; hepsi yönlendirme planı gerektirir.
• Türkçeleştirme/sadeleştirme: Eski sitelerde sık görülen kodlu, parametreli veya İngilizce slug'ların okunabilir Türkçe slug'lara çevrilmesi.
• Parametreli/oturum kirli URL temizliği: ?id=1234&ref=eski gibi izleme veya oturum parametreleri taşıyan adreslerin kanonik, temiz adreslere indirgenmesi; bu hem tarama bütçesini hem kullanıcı algısını iyileştirir.

URL'yi değiştiriyorsanız, fırsatı iyi kullanın: yeni URL'ler kısa, açıklayıcı, küçük harfli, kelimeler arası tireli ve mümkünse hedef anahtar kelimeyi içeren yapıda olsun. Türkçe karakter yerine sadeleştirilmiş (ç→c, ş→s, ı→i gibi) ASCII slug tercih edin; UTF-8 kodlama site genelinde standart olsa da slug düzeyinde Türkçe karakter taşımak yönlendirme, paylaşım ve kopyalamada bozuk (yüzde-kodlu) adreslere yol açabilir. Ayrıca dizin derinliğini abartmayın: /hizmetler/web-tasarim gibi iki seviyeli, anlamlı bir yapı, beş altı seviye derine gömülmüş adreslerden hem kullanıcı hem tarayıcı için daha iyidir. Bu URL hijyeni kararlarını sayfa içi (on-page) SEO çalışmasının bir parçası olarak ele almak, yenileme sonrası uzun vadeli kazanç sağlar.

Önemli bir uyarı: URL değişikliğini ileride yapacağınız küçük rötuşlara bölmeyin. Aynı sayfanın adresini önce bir, birkaç ay sonra tekrar değiştirmek, Google'ı her seferinde yeniden değerlendirmeye zorlar ve birikmiş değeri zayıflatır. URL kararlarını yenileme anında bir kerede, kalıcı olacak şekilde verin.

301 Yönlendirme: En Kritik Kural Neden Bu?

Yenilemede SEO'yu koruyan tek en önemli teknik adım, URL yapısı değişiyorsa eski adresten yeni adrese kalıcı (301) yönlendirme kurmaktır. Bu, Google'ın resmî olarak da vurguladığı bir kuraldır: kalıcı taşınmalarda 301 kullanılmalı, böylece hem kullanıcı doğru sayfaya ulaşır hem de eski URL'nin sıralama ve geri bağlantı değeri yeni URL'ye aktarılır. 301'i atlamak, yani eski URL'leri 404'e düşürmek, yenilemede yapılabilecek en pahalı hatadır.

Yönlendirme türlerini ve doğru kullanımlarını netleştirelim:

Buradaki en yaygın ve en zararlı hatayı özellikle vurgulamak isteriz: tüm eski URL'leri toplu hâlde ana sayfaya yönlendirmeyin. "Nasılsa hepsi siteye geliyor" mantığı yanlıştır. Google bu tür toplu ana sayfa yönlendirmelerini çoğu zaman yumuşak 404 (soft 404) gibi yorumlar ve değer aktarmaz. Her eski URL, içerik olarak en yakın yeni karşılığına bire bir (one-to-one) yönlendirilmelidir. Karşılığı gerçekten yoksa, en alakalı kategori veya üst sayfaya yönlendirin; hiçbir alakalı sayfa yoksa o zaman bilinçli olarak 404/410 bırakın.

302 ile 301 ayrımını da küçümsemeyin. Birçok eklenti, panel ve geliştirici varsayılan olarak 302 (geçici) yönlendirme üretir; çünkü test için pratiktir. Yenileme canlıya çıkarken bu varsayılanların 301'e (kalıcı) çevrildiğini bizzat doğrulayın. Bir tarayıcı eklentisi veya komut satırı aracıyla yanıt başlığındaki durum kodunu ("301 Moved Permanently") gözle teyit etmek, sonradan aylarca süren değer kaybını önler.

Yönlendirmeleri uygularken birkaç teknik incelik önemlidir:

• Zincir ve döngü oluşturmayın. A→B→C şeklinde zincirleme yönlendirmeler hem hızı düşürür hem değer kaybına yol açar. Mümkünse doğrudan A→C kurun. A→B, B→A gibi döngüler ise sayfayı tamamen erişilemez kılar.
• Sunucu düzeyinde uygulayın. Yönlendirmeyi mümkünse sunucu/altyapı seviyesinde (örneğin Next.js'te redirects yapılandırması, Apache'de .htaccess, Nginx'te rewrite, ya da CDN/edge kural setinde) tanımlayın; JavaScript ile yapılan istemci tarafı yönlendirmeler botlar için daha az güvenilirdir ve değer aktarımı garanti edilmez.
• HTTPS ve www tutarlılığı. Yenileme, HTTP→HTTPS geçişini ve www/non-www birleştirmesini netleştirmek için iyi bir fırsattır. SSL/TLS zaten artık zorunludur ve bir Google sıralama sinyalidir; tek bir kanonik (canonical) sürüm belirleyip diğer varyantları ona yönlendirin. Domain, hosting ve SSL altyapısı kararlarını yenilemeyle birlikte gözden geçirmek, bu birleştirmeyi tek seferde temiz yapmanızı sağlar.
• Sondaki eğik çizgi (trailing slash) tutarlılığı. /sayfa ve /sayfa/ ayrı URL'ler gibi davranabilir; tek bir biçim seçip diğerini yönlendirin.
• Büyük/küçük harf ve dil duyarlılığı. Sunucular URL'lerde büyük/küçük harfi farklı yorumlayabilir; tüm slug'ları küçük harfe normalize edip eski büyük harfli varyantları 301'le yönlendirin.
• Yönlendirmeleri yayından sonra kaldırmayın. 301 kuralları, geri bağlantılar yeni adrese işaret edene kadar (pratikte uzun süre) yerinde kalmalıdır. Geçiş "tamamlandı" diye yönlendirme dosyasını temizlemek, dış bağlantılardan gelen değeri ve kullanıcıları yeniden 404'e düşürür.

İçeriği Koruma: Yenileme "Silme" Değildir

Redesign kelimesi sizi yanıltmasın: yenileme, görünümü ve deneyimi tazelemektir; iyi çalışan içeriği çöpe atmak değildir. Müşterilerimizde en sık gördüğümüz trafik düşüşü, yeni siteye geçerken eski sitedeki değerli sayfaların ve metinlerin sessizce kaybolmasından kaynaklanır. Çünkü o eski, "çirkin" görünen sayfalar çoğu zaman tam da Google'da sıralanan, trafik ve müşteri getiren sayfalardır. Tasarımcının gözünde değersiz görünen uzun bir blog yazısı, gerçekte sitenin organik trafiğinin önemli bir bölümünü taşıyor olabilir.

Bu yüzden tasarıma başlamadan önce mevcut sitenizin bir içerik ve performans envanterini çıkarın. Pratik adımlar:

• Tüm URL'leri listeleyin. Mevcut sitemap.xml, sunucu logları ve bir tarayıcı (crawler) ile sitenin tam URL envanterini çıkarın. Hiçbir sayfa gözden kaçmamalı; menüde görünmeyen ama dışarıdan link almış eski sayfalar genelde en kıymetlileridir.
• Performansa göre etiketleyin. Google Analytics ve Search Console verisiyle her URL için organik trafik, geldiği anahtar kelimeler, dönüşüm ve geri bağlantı sayısını işaretleyin. "En çok trafik getiren ilk 20-50 sayfa" listesi yenilemenin dokunulmazlarıdır.
• Anahtar kelime ve niyet haritası çıkarın. Hangi sayfa hangi aramada çıkıyor? Yeni yapıda bu niyetin karşılığı hangi sayfa olacak? Bu eşleme, hem 301 haritanızın hem de içerik kararlarınızın temelidir.
• Koru / birleştir / güncelle / kaldır kararı verin. İyi performans gösteren içeriği koruyun (gerekirse yeni şablona taşıyın), zayıf ve örtüşen sayfaları daha güçlü bir sayfada birleştirin, eskimiş bilgiyi güncelleyin, gerçekten değersiz/yinelenen içeriği bilinçli kaldırın.

Bu dört kararı somutlaştırmak için basit bir karar tablosu kullanmak işi netleştirir:

İçerik korunurken sayfa içi SEO öğelerinin de taşındığından emin olun: başlık etiketleri (title), meta açıklamalar, H1/H2 yapısı, görsel alt metinleri ve iç bağlantılar. Yeni tasarımda metni "sadeleştirelim" derken Google'ın sıralama için kullandığı anahtar kelimeleri ve bağlamı yok etmek, en sinsi trafik kaybı sebeplerinden biridir. Aynı şekilde, eski sayfalarda kullanılan yapısal veri (Schema.org / JSON-LD) işaretlemelerinin (örneğin SSS, ürün, makale şemaları) yeni şablonda da bulunduğundan emin olun; bunlar arama sonuçlarındaki zengin görünümleri besler ve sessizce kaybolduklarında tıklama oranı düşer. Bu detayları doğru yönetmek için yenilemeyi bir teknik SEO denetimi disipliniyle ele almak gerekir; meta etiketlerini hızlıca üretip standardize etmek içinse meta başlık ve açıklama oluşturucu aracımızdan yararlanabilirsiniz.

Hız ve Deneyim: Yenileme Aynı Zamanda Bir Performans Fırsatıdır

Bir yenilemeyi SEO açısından nötr geçirmek hedeftir; ama doğru yapılırsa yenileme net bir kazanç da getirebilir. Çünkü Core Web Vitals bir Google sıralama sinyalidir ve eski siteler bu metrikleri çoğu zaman geçemez. Yenilemeyi, hız ve deneyimi sıfırdan doğru kurmak için bir fırsat olarak değerlendirin. Hedefiniz, Google'ın "iyi" eşiklerini saha verisinde (75. yüzdelik) geçmektir: LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1.

Tasarımcı ve geliştiricinin yenileme sırasında doğrudan etkileyebileceği başlıca noktalar:

• LCP (en büyük içeriğin görünme süresi): Hero görselini/yazı tipini önceden yükleyin (preload), kritik CSS'i satır içi verin, fontu display: swap ile sunun. Yeni sitenin ilk ekranını ağır görsellerle boğmayın.
• CLS (beklenmedik kayma): En yaygın kök neden, görsele yer ayrılmamasıdır. Her görsel, video ve iframe alanına açık genişlik/yükseklik veya aspect-ratio verin; dinamik banner/reklam alanlarına yer rezerve edin. Yeni şablonu kurarken bu disiplini baştan koymak, sonradan düzeltmekten çok daha ucuzdur.
• INP (etkileşime yanıt hızı): Ağır JavaScript ana iş parçacığını bloke eder ve butona/menüye tıklamada gecikme yaratır. Az script, kod bölme (code splitting) ve uzun görevleri parçalama ile INP'yi koruyun. Yenilemede "şık" diye eklenen ağır animasyon kütüphaneleri çoğu zaman INP'yi bozan asıl sebeptir.

Eski sitenin Core Web Vitals değerlerini yenileme öncesi mutlaka ölçüp kaydedin; böylece yeni sitenin gerçekten ilerleme kaydedip kaydetmediğini kıyaslayabilirsiniz. Bu konuyu derinleştirmek için site hızı ve Core Web Vitals rehberimize bakabilir, sayfa düzeyinde teşhis için PageSpeed Insights kullanımını inceleyebilirsiniz.

Sitemap ve Dahili Bağlantıları Güncelleme

Yeni site canlıya çıkınca Google'a "harita değişti" demeniz gerekir. Bunun iki ayağı vardır: site haritası (sitemap.xml) ve dahili bağlantı (internal linking) yapısı.

Sitemap tarafında yapılması gerekenler:

• Yeni sitemap.xml'i oluşturun ve içinde yalnızca yeni, geçerli (200 dönen, indekslenebilir) URL'ler bulunsun. Eski URL'leri sitemap'e koymayın; onların görevi 301 ile zaten yeni adrese işaret etmek.
• Google Search Console'a yeni sitemap'i tekrar gönderin. Yenileme sonrası bu adım atlanırsa, yeni sayfaların indekslenmesi gereksiz yere gecikir. Müşterilerimizde "yeni site açıldı ama Google'da görünmüyor" şikayetlerinin sık bir kök nedeni budur.
• robots.txt'i kontrol edin. Staging (test) ortamında siteyi botlara kapatmak için kullanılan Disallow kuralının canlı sürüme yanlışlıkla taşınmadığından emin olun; bu hata tüm siteyi indeksten düşürebilir.
• noindex etiketlerini ve şifre korumasını temizleyin. Test ortamında sayfa düzeyinde eklenen <meta name="robots" content="noindex"> etiketleri ya da HTTP kimlik doğrulaması, canlıya yanlışlıkla taşınırsa site indekslenemez. Yayın öncesi bunu sayfa sayfa doğrulayın.

Dahili bağlantı tarafında ise eski sürümdeki menü, içerik içi linkler ve alt bilgi (footer) bağlantılarının tamamı yeni URL'lere doğrudan işaret etmelidir. Dahili linkleri eski URL'de bırakıp 301'e güvenmek teknik olarak çalışır ama her tıklamada gereksiz bir yönlendirme adımı ekler, hızı düşürür ve zamanla zincir hatalarına yol açar. Yeni içerik kümeleri arasında güçlü bir iç bağlantı ağı kurmak, hem kullanıcı gezinmesini hem de yeni sayfaların hızlı değer kazanmasını destekler. Bu, aynı zamanda bilgi mimarisi açısından da kazançtır: yenilemeyi, sayfaların birbirine mantıklı şekilde bağlandığı bir konu kümesi (topic cluster) yapısı kurmak için kullanın.

Yenileme Geçiş Kontrol Listesi (Aşama Aşama)

Yenilemeyi SEO güvenli kılmanın yolu, işi rastgele değil belirli bir sırayla yürütmektir. Aşağıdaki kontrol listesi, müşterilerimizde uyguladığımız geçiş akışını özetler.

1. Denetim (yayından önce):

• Tam URL envanteri + analytics/Search Console performans verisi çıkarıldı.
• En değerli sayfalar (trafik, dönüşüm, geri bağlantı) "dokunulmaz" olarak işaretlendi.
• Anahtar kelime → sayfa haritası hazırlandı.
• Mevcut Core Web Vitals (LCP, INP, CLS) ölçümleri kaydedildi; yeni sitenin bunları geçmesi hedef olarak belirlendi.
• Mevcut geri bağlantı profili çıkarıldı; en çok link alan eski URL'ler ayrıca işaretlendi (bunlar 301'de önceliklidir).

2. Planlama ve tasarım:

• Yeni bilgi mimarisi ve URL yapısı belirlendi; değişen her URL için yeni karşılığı yazıldı.
• Eski URL → yeni URL 301 yönlendirme haritası (redirect map) eksiksiz hazırlandı; her satır bire bir, en yakın içerik karşılığına eşlendi.
• Koru/birleştir/güncelle/kaldır kararları tüm sayfalar için verildi.
• Yasal metinlerin (KVKK aydınlatma, çerez politikası, varsa mesafeli satış) yeni şablonda yer alacağı planlandı.

3. Staging'de (test ortamında) doğrulama:

• Yeni site botlara kapalı bir staging ortamında kuruldu.
• 301 haritası uygulandı ve örnek eski URL'ler tek tek test edildi (zincir/döngü yok, doğru hedefe ve doğru durum koduyla — 301 — gidiyor).
• Tüm sayfalarda title, meta açıklama, H1, alt metin ve yapısal veri (varsa) korundu/doğrulandı.
• Hız (Core Web Vitals: LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1), mobil uyum, erişilebilirlik ve form testleri yapıldı.
• Yasal metinler (KVKK aydınlatma, çerez politikası) yeni sitede mevcut ve güncel.

4. Yayın (go-live):

• Staging'in indekslemeyi engelleyen robots.txt/noindex ayarları ve test kimlik doğrulaması kaldırıldı.
• 301 yönlendirmeleri canlıda etkinleştirildi; HTTPS ve tek kanonik sürüm (www/non-www) zorunlu kılındı.
• Yeni sitemap.xml yayınlandı; dahili bağlantılar doğrudan yeni URL'lere işaret edecek şekilde güncellendi.

5. Yayın sonrası izleme:

• Yeni sitemap Google Search Console'a tekrar gönderildi.
• Search Console'da Kapsam (Coverage) ve 404 raporları düzenli izlendi; kaçan eski URL'lere yönlendirme eklendi.
• İndeksleme durumu ve Core Web Vitals takip edildi; sunucu logları taranarak hangi eski URL'lerin hâlâ 404 döndürdüğü tespit edildi.
• İlk haftalarda sıralama ve trafikte dalgalanma normal kabul edildi; panik kararlarıyla hemen geri dönüş yapılmadı, veri 4-8 hafta gözlemlendi.

Bu son nokta önemlidir: iyi planlanmış bir yenilemede bile Google'ın yeni yapıyı tam değerlendirmesi haftalar alabilir; ilk günlerdeki küçük dalgalanmalar genelde geçicidir. Kontrol listesini disiplinle uyguladıysanız trafik kısa sürede toparlanır, hatta hız ve deneyim iyileştikçe daha iyi bir noktaya çıkar. Tersine, ilk hafta yaşanan bir düşüşü görüp paniğe kapılarak yeni siteyi geri almak çoğu zaman durumu daha da bozar; çünkü Google bu kez de geri dönüşü yeniden değerlendirmek zorunda kalır.

Yenilemede En Sık Yapılan SEO Hataları

Onlarca geçiş projesinden damıttığımız, en sık tekrar eden ve en pahalıya patlayan hatalar şunlardır. Yeni sitenizi yayınlamadan önce bu listeyi bir "yapma" kontrol listesi gibi okuyun:

• 301 haritasını hiç çıkarmamak ve değişen URL'leri sessizce 404'e düşürmek. Tek başına en büyük trafik kaybı sebebidir.
• Her şeyi ana sayfaya yönlendirmek; bu soft 404 olarak değerlendirilir ve değer aktarmaz.
• 301 yerine 302 kullanmak; geçici yönlendirme kalıcı taşımada değeri taşımaz.
• Staging'in noindex/robots Disallow ayarını canlıya taşımak; tüm site indeksten düşer.
• İyi performans gösteren içeriği "eski göründüğü için" silmek; sıralanan metin yok olunca o anahtar kelimeler de gider.
• Yeni sitemap'i Search Console'a göndermeyi unutmak; indeksleme gereksiz yere gecikir.
• Yapısal veriyi (Schema/JSON-LD) ve meta etiketlerini taşımamak; zengin sonuçlar ve tıklama oranı düşer.
• Görsel URL'lerini topluca değiştirip yönlendirmemek; görsel aramasından gelen trafik ve görsellerin biriktirdiği değer kaybolur.
• Yenileme öncesi temel ölçümleri (trafik, sıralama, CWV) kaydetmemek; sonradan neyin bozulduğunu anlamak imkânsızlaşır.

Yenilemenin SEO tarafı titizlik ve deneyim ister; tek bir atlanan 301 satırı bile aylarca trafik kaybına mal olabilir. Bu süreci kendiniz yürütmek yerine uçtan uca güvenli bir geçişle yönetmek isterseniz, web ve özel yazılım geliştirme hizmetimiz kapsamında yenileme projelerini 301 haritası ve SEO koruması dahil planlıyoruz; mevcut sitenizin durumunu görmek için ücretsiz analiz talebinde bulunabilirsiniz.

Yenileme süreci nasıl işler: denetim, tasarım, yayın

Web sitesi yenileme süreci yedi aşamadan oluşur: denetim/analiz, strateji, tasarım, geliştirme, test, yayın ve yayın sonrası izleme. Bu süreç doğru kurgulandığında mevcut SEO değerini, trafiği ve dönüşümleri korurken arayüzü, hızı ve altyapıyı 2026 standartlarına taşır. Yanlış kurgulandığında ise -özellikle URL haritası ve yönlendirmeler atlandığında- yıllarca biriken organik sıralama tek bir yayın günü ile kaybedilebilir. Bu yüzden yenileme, yeni site yapmaktan farklı bir disiplindir: sıfırdan başlamazsınız, var olan değeri taşıyarak yeniden inşa edersiniz. Sürecin nasıl planlandığına dair temeli web sitesi yapma adımları rehberinde bulabilirsiniz; burada özellikle "mevcut bir siteyi yenileme" bağlamına odaklanıyoruz.

Sıfırdan site kurarken çoğunlukla on adımlık bir sıra (hedef, alan adı, hosting, SSL, tasarım, geliştirme, içerik, test, yayın, bakım) izlenir. Yenilemede ise zaten bir alan adınız, içerik birikiminiz ve -en önemlisi- arama motorlarında biriktirdiğiniz bir otorite vardır. Dolayısıyla yenilemenin ilk adımı yeni bir şey üretmek değil, var olanı envantere almaktır. Aşağıdaki tabloda iki sürecin nerede ayrıştığını özetliyoruz; bu fark, neden tasarımdan değil denetimden başlamanız gerektiğini de açıklar.

Müşterilerimizde gördüğümüz en yaygın hata, projeye "tasarım" aşamasından başlamaktır. Oysa denetim atlandığında, iyi performans gösteren sayfalar farkında olmadan silinir, çalışan URL'ler kırılır ve yenilenen site eskisinden daha az iş yapar. Görsel olarak çok daha modern bir site, organik trafiğinin yarısını kaybettiği için ticari olarak başarısız olabilir; çünkü estetik tek başına ne arama görünürlüğünü ne de dönüşümü garanti eder. Aşağıda her aşamayı sırayla, somut adımlarla açıyoruz.

Yenilemeye gerçekten ihtiyacınız var mı? Önce sinyalleri okuyun

Süreci başlatmadan önce sorulması gereken soru şudur: bu bir yenileme projesi mi, yoksa hedefli birkaç düzeltme mi? Tam yenilemeyi haklı çıkaran belirli sinyaller vardır ve bunları doğru okumak, hem bütçeyi hem de SEO riskini doğru yönetmenizi sağlar. Pratikte gördüğümüz başlıca yenileme gerekçeleri şunlardır:

• Mobil uyumsuzluk veya eskimiş görünüm: Site küçük ekranda bozuluyor, eski bir şablon hissi veriyor. Mobil küresel web trafiğinin yaklaşık %60'ını oluşturduğundan (2026; kaynağa göre değişir), bu doğrudan iş kaybıdır.
• Yavaşlık: Core Web Vitals eşikleri tutmuyor (LCP > 2,5 sn, INP > 200 ms, CLS > 0,1). Genellikle yıllar içinde biriken eklenti şişmesi, optimize edilmemiş görseller veya ağır JavaScript bunun kaynağıdır.
• Düşük dönüşüm, yüksek hemen çıkma: Trafik var ama lead/satış yok; bilgi mimarisi veya dönüşüm akışı kırık.
• Marka değişimi: Logo, renk, isim veya konumlandırma değişti; site marka ile uyumsuz kaldı.
• Eski veya güvensiz altyapı: Güncellenmeyen CMS/eklentiler, biten destek, yönetilemeyen içerik yapısı. OWASP Top 10:2025'te tedarik zinciri açıkları (A03) ayrı bir madde haline geldi; güncellenmemiş bileşenler en sık sömürülen yüzeydir.
• Erişilebilirlik/yasal uyumsuzluk: WCAG 2.2 AA hedefini karşılamayan, KVKK/çerez metinleri eksik bir site.

Tek bir sinyal (örneğin yalnızca yavaşlık) varsa, çoğu zaman tam yenileme yerine performans odaklı bir iyileştirme yeterli olabilir. Birkaç sinyal bir araya geldiğinde -özellikle altyapı eskimişse- tam yenileme daha mantıklıdır. Bu kararı netleştirmek için mevcut sitenizin durumunu ölçmenizi öneririz; e-ticaret altyapı tespit aracımız ile hangi platform üzerinde çalıştığınızı hızla görebilir, kapsamlı bir tablo için teknik SEO denetimi rehberimize başvurabilirsiniz.

1. Denetim ve analiz: neyi koruyacağınızı önce ölçün

Denetim, yenilemenin en kritik ama en çok atlanan aşamasıdır. Amaç tek cümleyle şudur: elinizdeki sitenin neyi iyi yaptığını sayısal olarak bilmeden hiçbir şeyi silmemek. Bu aşama üç koldan yürür: analitik denetimi, SEO denetimi ve UX/teknik denetim. Her biri yenileme kararlarınızın gerekçesini oluşturan farklı bir veri katmanı üretir.

Analitik denetimi. Google Analytics 4 ve Search Console verisiyle son 12 ayın trafiğini sayfa bazında çıkarın. Hangi sayfalar en çok organik trafik alıyor, hangileri dönüşüm üretiyor, hangileri ölü? En çok trafik ve dönüşüm getiren sayfaların URL'lerini, başlıklarını ve sıralandıkları anahtar kelimeleri bir tabloya işleyin. Bu tablo, yenilemenin "dokunulmazlar listesi" olur. İyi performans gösteren sayfaları korumak gerekir; redesign görünümü yenilemek demektir, çalışan içeriği sıfırlamak değil. Pratik bir ipucu: sayfaları getirdiği değere göre üç gruba ayırın - koru (yüksek trafik veya dönüşüm), birleştir/yenile (zayıf ama konu olarak değerli), kaldır (ölü, tekrar eden veya artık geçerli olmayan). Bu sınıflandırma sonraki tüm aşamaların iskeletidir.

SEO denetimi. Mevcut URL yapısını, meta başlık/açıklamaları, dahili link ağını, sitemap'i ve dış bağlantı (backlink) profilini envantere alın. Hangi sayfalar dışarıdan link almış? Bu sayfalar otorite biriktirmiştir; URL'leri değişecekse mutlaka yönlendirilmeleri gerekir. Teknik tarafta indeksleme durumunu ve mevcut Core Web Vitals skorlarını da kaydedin; yenileme sonrası "daha mı iyi oldu?" sorusunu ancak başlangıç ölçümünüz varsa cevaplayabilirsiniz. Buradaki en kritik çıktı, ileride kuracağınız URL eşleme tablosunun ham maddesi olan eksiksiz eski URL envanteridir. Bu işin yöntemini teknik SEO denetimi rehberinde adım adım ele alıyoruz; mevcut altyapınızı hızlıca görmek için e-ticaret altyapı tespit aracımızı da kullanabilirsiniz.

UX ve teknik denetim. Sitenin neden yenilenmesi gerektiğini somutlaştırın: mobil uyumsuzluk mu, yavaşlık mı (LCP > 2,5 sn, INP > 200 ms, CLS > 0,1), yüksek hemen çıkma mı, eski/güvensiz altyapı mı, erişilebilirlik uyumsuzluğu mu? Bu sinyaller, tasarım kararlarınızın gerekçesi olur. Örneğin mevcut INP'niz kötüyse, yeni tasarımda ağır JavaScript ve gereksiz animasyondan kaçınmanız gerektiğini baştan bilirsiniz. Erişilebilirlik tarafında WebAIM'in yıllık taramalarında en sık çıkan hatalar -düşük metin kontrastı, alt-metni olmayan görseller, boş bağlantılar, etiketsiz form alanları, boş butonlar, eksik dil tanımı- mevcut sitenizde var mı, denetimde işaretleyin; bunlar yeni tasarımda tekrar etmemesi gereken kalıplardır.

Bu aşamanın somut çıktısı tek bir belgedir: her önemli URL'nin trafiği, dönüşümü, aldığı dış linkler ve "koru/birleştir/kaldır" kararıyla listelendiği bir denetim tablosu. Bu belge olmadan ilerleyen yenileme projeleri, kör uçuş yapar.

2. Strateji ve bilgi mimarisi: çıktıyı tasarımdan önce tanımlayın

Denetim "ne durumdayız" sorusunu cevaplar; strateji "nereye gidiyoruz" sorusunu. Bu aşamada yenilemenin ölçülebilir hedefini netleştirin: dönüşüm oranını artırmak mı, mobil deneyimi düzeltmek mi, marka kimliğini yenilemek mi, yasal/erişilebilirlik uyumu mu? Hedef belirsizse sonuç "güzel ama işe yaramaz" bir site olur. Mümkünse hedefi sayısallaştırın: "form gönderimlerini artırmak" yerine "iletişim formu dönüşümünü ölçülebilir biçimde yükseltmek ve mobil LCP'yi 2,5 sn altına çekmek" gibi.

Stratejinin kalbi bilgi mimarisidir (IA): içeriğin mantıklı gruplanması, gezinme yapısı ve etiketleme. Kullanıcı her an "nerede olduğunu ve nereye gideceğini" bilmeli. Yenilemede IA çalışmasının en önemli çıktısı URL eşleme tablosudur (URL mapping): eski her önemli URL'nin yeni karşılığını gösteren liste. Bu tablo, ileride 301 yönlendirme haritasının temeli olacak; bu yüzden strateji aşamasında hazırlanmalı, yayın gününe bırakılmamalıdır. Tablonun pratik formatı sade olmalıdır:

Bu aşamada içerik haritalandırması da yapılır: denetimde "dokunulmaz" işaretlenen sayfalar korunur, zayıf içerikler birleştirilir veya yenilenir, eksik konular planlanır. Birden fazla zayıf sayfayı tek güçlü sayfada birleştirirken (içerik konsolidasyonu), kaldırılan URL'lerin birleştirildikleri sayfaya 301 ile yönlendirilmesi şarttır; aksi halde o sayfaların biriktirdiği değer yok olur. Hick Yasası gereği menü ve seçenekleri sadeleştirmek karar yükünü azaltır; yenileme, gereksiz şişmiş gezinme yapısını temizlemek için iyi bir fırsattır. Aynı şekilde Jakob Yasası kullanıcıların diğer sitelerden öğrendikleri kalıpları beklediğini söyler; IA'yı sadeleştirirken tanıdık gezinme mantığını koruyun. Bilgi mimarisi ve kullanıcı odaklı tasarım ilkelerinin derinine UI/UX tasarım rehberimizde giriyoruz.

3. Tasarım: önce mobil, sonra büyük ekran

Tasarım aşamasında, stratejide tanımlanan IA üzerine görsel katman kurulur. 2026'da doğru yaklaşım mobil-öncelikli tasarımdır: önce küçük ekran tasarlanır, sonra büyük ekrana genişletilir (progressive enhancement). Tersi -masaüstünden küçültme- genelde kötü mobil deneyim üretir. Google'ın varsayılan mobil öncelikli indekslemesi de bunu zorunlu kılar: Google sitenin mobil sürümünü indeksler ve sıralar, dolayısıyla mobilde eksik içerik doğrudan SEO kaybıdır. Pratikte bu, masaüstünde gösterip mobilde gizlediğiniz içeriğin Google için "yok" sayılabileceği anlamına gelir; yenilemede tüm temel içeriği mobil düzende eksiksiz tutun.

Yenilemede tasarım kararlarını şu ilkelere bağlayın:

• Görsel hiyerarşi: Boyut, renk, kontrast ve boşlukla önem sırası kurun; göz önce başlık ve ana CTA'ya gitmeli. Yenilenen anasayfada net değer önerisini üst-katlamaya (above the fold) yerleştirin. Fitts Yasası gereği önemli ve sık kullanılan butonları büyük ve erişilebilir tutun.
• Kontrast ve erişilebilirlik: WCAG AA gereği gövde metni kontrastı en az 4,5:1, büyük metin 3:1 olmalı. Renk tek başına bilgi taşımamalı (renk körlüğü için). Erişilebilirliği yenilemenin sonuna bırakmayın; 2026'da erişilebilirlik bir "özellik" değil altyapıdır ve hem SEO hem de -Avrupa Erişilebilirlik Yasası kapsamına giren işler için- yasal bir gerekliliktir.
• Dokunma hedefleri: WCAG 2.2 SC 2.5.8 (AA) minimum 24x24 CSS piksel ister; pratikte mobil butonlar için 44-48px hedefleyin (Apple HIG 44x44 pt, Material 48x48 dp, WCAG AAA 44x44 px).
• Tutarlılık: Aynı eylem her yerde aynı görünmeli (butonlar, renkler, terimler). Jakob Yasası gereği kullanıcı, diğer sitelerden öğrendiği kalıpları bekler; redesign'da "farklı olsun" diye tanıdık kalıpları bozmayın.
• Tipografi: Gövde metni için ~16px taban boyut, ~50-75 karakter satır uzunluğu ve 1,4-1,6 satır aralığı okunabilirliği belirler; en çok 2-3 yazı tipiyle sınırlı kalın.
• İşlevsel mikro etkileşim: Hover, buton geri bildirimi ve onay işaretleri "sistem dinliyor" hissi verir; işlevsel mikro etkileşimin etkileşimi belirgin biçimde artırdığı gözlemleniyor, ancak dekoratif değil yol gösterici olmalı.

Dönüşüm odaklı bir yenilemede tek net birincil CTA, az alanlı formlar ve güven öğeleri (referans logoları, sertifikalar, gerçek ekip, açık adres/telefon) belirleyicidir. 2026'nın tasarım ekseni de bu yöndedir: gösterişli efektten çok hız, sadelik ve performans-öncelikli, dikkat dağıtmayan "sakin" arayüzler öne çıkıyor. Koyu mod desteği artık beklenen bir özellik haline geldi. Ancak geçici moda ile kalıcı ilkeyi ayırın: hız, erişilebilirlik, mobil-öncelik, net hiyerarşi ve kullanıcı odaklılık her zaman geçerlidir; belirli animasyon veya yazı tipi akımları ise markaya uyuyorsa kullanılmalı, körü körüne takip edilmemelidir. Mobil-öncelikli tasarımın detaylarını responsive web tasarım rehberinde, dönüşümü artıran arayüz kalıplarını ise dönüşüm odaklı landing page rehberinde bulabilirsiniz.

4. Geliştirme: hız ve altyapı kararlarının verildiği yer

Geliştirme aşamasında tasarım koda dönüşür ve yenilemenin altyapı kararları kesinleşir. Eski siteyi neden yenilediğinize göre platform da değişebilir: ağır eklentilerle yavaşlamış bir WordPress sitesini, performans-kritik bir kurumsal siteyi modern statik/edge altyapıya (Next.js/Astro, Vercel/Netlify/Cloudflare Pages) taşımak yaygın bir yenileme gerekçesidir. WordPress hâlâ tüm web'in yaklaşık %41,9'unu çalıştıran baskın CMS'tir ve geniş eklenti ekosistemi büyük bir güç; ancak aynı ekosistem, kontrolsüz büyüdüğünde performans ve güvenlik yükü yaratır. Platform kararını yenileme gerekçenize göre verin:

Bu kararda sahiplik ve taşınabilirlik de önemlidir: hazır kurucularda içerik ve tasarım platforma kilitlidir (vendor lock-in), çıkış zordur; açık kaynak CMS veya özel yazılımda kod ve veri sizindir. Hazır kurucu, CMS veya özel yazılım arasındaki karar mantığını hangi CMS seçilmeli rehberinde ve hazır site mi özel yazılım mı yazımızda ayrıntılandırıyoruz.

Geliştirmede Core Web Vitals'ı baştan gözetin; bunlar yayından sonra "düzeltilecek" işler değildir. Her metrik için somut müdahaleler şunlardır:

• LCP için (≤ 2,5 sn): En büyük içerik genelde hero görseli/videosudur. Bu görseli preload edin, kritik CSS'i satır içi verin, fontu preload edip display: swap kullanın ve sunucu yanıt süresini düşük tutun (edge/CDN).
• CLS için (≤ 0,1): En yaygın kök neden, görsele yer ayrılmamasıdır. Her img/video/iframe/reklam alanına açık width ve height (veya aspect-ratio) verin; dinamik banner ve reklamlara yer rezerve edin. Font kaynaklı kaymayı @font-face üzerindeki size-adjust descriptor'ı ile bastırın - bu, kaymayı örneğin 0,15'ten 0,02'ye düşürebilir.
• INP için (≤ 200 ms): Ağır JavaScript ana iş parçacığını bloke eder ve etkileşim yanıtını geciktirir. Kod bölme (code splitting), az script ve uzun görevleri parçalama uygulayın. INP, FID'in 12 Mart 2024'te yerini aldığından beri tek bir ilk etkileşimi değil tüm etkileşim yaşam döngüsünü ölçer; bu yüzden gereksiz her satır JavaScript'in maliyeti vardır.

Bu aşamada güvenlik temelleri de baştan kurulmalıdır; yenileme, eski güvenlik borçlarını kapatmak için en doğru zamandır. SSL/TLS zorunludur (Let's Encrypt ile ücretsiz, çoğu hostingte otomatik) ve HTTPS hem bir Google sıralama sinyali hem de tarayıcının "güvenli değil" uyarısını önleyen temeldir. Güvenli form ve giriş için sunucu tarafı doğrulama, CSRF token, rate-limit (kaba kuvvet önleme), güçlü parola + 2FA ve girdi temizleme (injection/XSS önleme) uygulayın. OWASP Top 10:2025'te yetki kontrolü (A01) ve güvenlik yapılandırma hataları (#2'ye yükseldi) ilk sıralarda olduğundan, yeni sitede yetkilendirme ve yapılandırmayı titizlikle gözden geçirin. KVKK m.12 gereği kişisel veri işleyen sitelerde HTTPS, şifreleme, erişim kontrolü ve log tutma yasal bir zorunluluktur. CWV'nin SEO'ya etkisini site hızı ve Core Web Vitals rehberinde, güvenlik tarafını ise GEO denetim aracımızla birlikte değerlendirebilirsiniz.

5. Test: yayından önce her şeyi staging'de doğrulayın

Yenilemede test, canlıya almadan önce bir hazırlık (staging) ortamında yapılır. Bu, yenileme ile sıfırdan site arasındaki en kritik farklardan biridir: test edilecek ekstra ve hayati bir kalem vardır, o da yönlendirme haritasıdır. Sıfırdan bir sitede yönlendirilecek eski URL yoktur; yenilemede ise bu adım, projenin tüm SEO değerinin korunduğu ya da kaybedildiği yerdir. Yayın öncesi kontrol listesi:

• 301 yönlendirme haritası: URL eşleme tablosundaki her eski URL'nin yeni URL'ye kalıcı (301) yönlendirildiğini tek tek doğrulayın. URL yapısı değişiyorsa bu adım pazarlık konusu değildir; aksi halde sıralama ve backlink değeri kaybolur. Yönlendirmelerin zincirleme (A→B→C) çalışmadığından, doğrudan hedefe (A→C) gittiğinden ve geçici (302) değil kalıcı (301) olduğundan emin olun.
• Mobil ve responsive test: Gerçek cihaz boyutlarında (~360-480px telefon, ~768px tablet, ~1024px+ masaüstü) düzenin bozulmadığını kontrol edin. Mobil-öncelikli indeksleme nedeniyle mobil düzendeki içerik eksiksiz olmalı.
• Hız/CWV: Staging'de LCP, INP ve CLS'yi ölçün; başlangıç denetimindeki değerlerle karşılaştırın. Yenilemenin "daha hızlı oldu" iddiasını ancak bu karşılaştırma kanıtlar.
• Erişilebilirlik denetimi: Kontrast (AA için 4,5:1 / 3:1), alt metinleri, klavyeyle tam gezinme, görünür odak halkası, form etiketleri ve dil tanımını (lang="tr") kontrol edin. En sık hatalar düşük kontrast, alt-metni olmayan görseller, etiketsiz form alanları ve boş butonlardır; bunları yayından önce sıfırlayın.
• SEO unsurları: Meta başlık/açıklama, sitemap, dahili linkler ve canonical etiketlerini doğrulayın. Yeni meta etiketleri için meta başlık ve açıklama oluşturucu aracımızdan yararlanabilirsiniz.
• 404 ve form testleri: Kırık linkleri tarayın, tüm formların çalıştığını ve doğru yere düştüğünü test edin. Özellikle mobil form akışını (otomatik doldurma, doğru klavye tipleri) ayrıca deneyin.
• Yasal metinler: KVKK aydınlatma metni ve çerez politikası yerinde mi? Çerez bandı, zorunlu olmayan (analitik/pazarlama) çerezler için açık rıza alıyor mu? Aydınlatma metni ile açık rıza/ticari ileti izni AYRI düzenlenmeli; tek kutuda "kabul ediyorum" hukuken sakıncalıdır. E-ticaret varsa mesafeli satış sözleşmesi, ön bilgilendirme formu ve iade/cayma koşulları da yerinde olmalı.
• Yedekleme: Yayından hemen önce eski sitenin tam, site dışı (off-site) yedeğini alın; bir sorun çıkarsa geri dönüş yolunuz olsun. Geri yüklemeyi de en az bir kez test edin.

Türkçe karakter testini de atlamayın: site UTF-8 olmalı ve seçilen font ç, ğ, ı, İ, ö, ş, ü ile özellikle noktalı/noktasız I ayrımını doğru göstermeli; bazı popüler fontlarda "İ/ı" sorunları çıkar. lang="tr" tanımı hem erişilebilirlik hem de doğru büyük/küçük harf dönüşümü için gereklidir. Erişilebilirlik denetiminin tüm adımlarını web erişilebilirliği rehberinde bulabilirsiniz.

6. Yayın: kontrollü geçiş

Yayın, staging'de doğrulanan sitenin canlıya alındığı andır. Geçişi mümkünse düşük trafikli bir zaman diliminde yapın; böylece olası bir aksaklık daha az kullanıcıyı etkiler ve müdahale için zamanınız olur. Yayın anında üç şeyden mutlak emin olun: 301 yönlendirmeler aktif mi, SSL sertifikası yeni sitede çalışıyor mu, eski yedek dosyalar geri dönüş için hazır bekliyor mu? Yayın hemen sonrası ilk yapılacak iş, yeni sitemap'i Google Search Console'a tekrar göndermektir; böylece Google yeni URL yapısını hızla keşfeder ve eski URL'lerden yenilere geçişi daha çabuk işler.

Bu noktada eski URL'lere gelen trafiğin gerçekten yeni sayfalara düştüğünü canlı ortamda da örnekleyerek doğrulayın; en çok dış link almış birkaç eski URL'yi tarayıcıda açıp yeni hedefe 301 ile gittiklerini tek tek görün. Bir kurumsal yenilemede güven öğelerinin (açık adres, telefon, gerçek ekip, referanslar, müşteri logoları) yerli yerinde ve doğru olması özellikle önemlidir; B2B bağlamında site tek başına "satın al" değil, uzun ve çok karar vericili satış döngüsünde "eğitim ve güven" rolü oynar. Bu güven mimarisinin derinine kurumsal web sitesi rehberinde ve B2B web sitesi tasarımı yazımızda giriyoruz.

7. Yayın sonrası izleme: ilk haftalar belirleyicidir

Yenileme yayınla bitmez; asıl değerlendirme yayın sonrası izleme ile yapılır. İlk haftalarda sıralamalarda hafif dalgalanma normaldir, Google yeni yapıyı yeniden işlerken geçici iniş çıkışlar görülebilir. Önemli olan, bu doğal dalgalanmayı gerçek bir kayıptan ayırt edebilmektir; bunun için denetim aşamasındaki başlangıç ölçümleriniz referans noktanızdır. Şunları yakından takip edin:

• Search Console: İndeksleme durumunu, kapsama hatalarını ve 404 raporlarını izleyin. Beklenmedik 404 artışı, atlanmış bir yönlendirmenin işaretidir; ilgili eski URL'yi tespit edip hemen 301 ekleyin. Bu, yayın sonrası en sık karşılaşılan ve en hızlı çözülmesi gereken sorundur.
• Sıralama ve organik trafik: Denetim aşamasındaki "dokunulmaz" sayfaların trafiğini karşılaştırın; ciddi ve kalıcı düşüş varsa içerik veya yönlendirme tarafında bir kayıp var demektir. Birkaç haftada toparlamayan düşüşler incelenmeli.
• Core Web Vitals: Saha verisi (75. yüzdelik) birikmesi zaman alır; LCP (≤ 2,5 sn), INP (≤ 200 ms) ve CLS'nin (≤ 0,1) "iyi" eşiklerinde kaldığını haftalar boyunca takip edin. Lab ölçümü iyiyken saha verisi kötüyse, gerçek kullanıcı cihazları/şebekesi farkını araştırın.
• Dönüşüm: Yenilemenin asıl hedefi buydu; form gönderimleri, teklif talepleri ve satışların eski siteye göre nasıl seyrettiğini ölçün. Görsel olarak daha güzel ama daha az dönüşen bir site, başarılı bir yenileme değildir.

Bakım sürekli bir süreçtir: güvenlik güncellemeleri, içerik tazeleme, performans izleme, yedekleme ve kırık link kontrolü yenilemenin kazanımlarını korur. CMS çekirdeği, tema ve eklentileri düzenli güncellemek, bilinen açıkların (CVE) çoğunun güncellenmemiş bileşenlerden sömürüldüğü gerçeği nedeniyle kritiktir. Bakımsız bir site, ne kadar iyi yenilenirse yenilensin güvenlik ve SEO açısından hızla değer kaybeder. İzlemede kullanacağınız hız ölçümünün pratiğini PageSpeed Insights rehberinde bulabilirsiniz.

Yenilemede en sık yapılan hatalar

Onlarca yenileme projesinde tekrar tekrar gördüğümüz hatalar bellidir; çoğu, sürecin bir aşamasını atlamaktan kaynaklanır. Yenilemeye başlamadan önce bu listeyi bir kontrol noktası olarak kullanın:

• Denetimi atlamak: Tasarımdan başlamak, çalışan sayfaların ve değerli URL'lerin farkında olmadan silinmesine yol açar.
• 301 yönlendirmeleri unutmak veya yanlış kurmak: Yenilemede SEO kaybının bir numaralı sebebidir. URL değişiyorsa kalıcı yönlendirme şarttır; 302 (geçici) kullanmak değer aktarımını sekteye uğratır.
• İçeriği sıfırlamak: Redesign görünümü yenilemektir; iyi sıralanan içeriği "yeni baştan yazalım" diye silmek yıllık trafiği riske atar.
• Erişilebilirliği ve performansı sona bırakmak: Bunlar sonradan eklenen değil, baştan tasarlanan özelliklerdir. Sonradan müdahale hem pahalı hem eksik kalır.
• Staging'siz canlıya geçmek: Yönlendirme haritasını ve formları test etmeden yayınlamak, hataları en pahalı yerde -canlı sitede- bulmak demektir.
• Yasal metinleri güncellememek: Yeni tasarımda KVKK aydınlatma, çerez rızası ve (varsa) mesafeli satış metinlerinin taşınmaması hem hukuki risk hem güven kaybı yaratır.
• Yayın sonrası izlemeyi bırakmak: Atlanmış bir 404'ü veya dönüşüm düşüşünü haftalar sonra fark etmek, kolayca düzeltilebilecek bir sorunu kalıcı kayba çevirir.

Web sitenizi yenilemeyi düşünüyor ama nereden başlayacağınızdan emin değilseniz, bu sürecin tamamını -denetimden yayın sonrası izlemeye- birlikte planlayabiliriz. Mevcut sitenizin durumunu ölçüp önceliklerinizi netleştirmek için ücretsiz analiz formumuzu doldurabilir, tasarım ve geliştirme tarafında web ve mobil UI/UX tasarımı hizmetimizi ya da daha kapsamlı projeler için özel yazılım hizmetimizi inceleyebilirsiniz. Doğru kurgulanmış bir yenileme, mevcut değerinizi kaybetmeden sitenizi hem daha hızlı hem daha çok iş yapan bir varlığa dönüştürür.

Yenilerken Hız, Mobil ve Erişilebilirlik: Yenilemenin Asıl Kazancı Nerede?

Web sitesi yenileme projelerinde asıl kazanç, çoğu kişinin sandığı gibi yalnızca "daha modern görünüm" değildir; ölçülebilir değerin büyük kısmı performans (Core Web Vitals), mobil deneyim ve erişilebilirlik üçgeninden gelir. Bu üç başlık aynı zamanda Google'ın sıralama sinyalleri, kullanıcı dönüşümü ve yasal uyum (EAA) ile doğrudan ilişkilidir. Pratik olarak söylersek: yeni tasarımı eski altyapının üzerine giydirirseniz "güzel ama yavaş, mobilde bozuk ve erişilemez" bir site elde edersiniz; doğru yapılan bir yenileme ise bu üç eksende ölçülebilir bir sıçrama yaratır. Bu yüzden müşterilerimizde gördüğümüz en sağlıklı yaklaşım, redesign'ı "kozmetik tazeleme" değil, hız + mobil + erişilebilirlik kazanımının planlı bir fırsatı olarak ele almaktır.

Bu üç eksenin neden bir arada değerlendirilmesi gerektiğini de vurgulayalım: çoğu zaman aynı tasarım kararı her üçünü birden etkiler. Örneğin hero bölümündeki devasa bir görseli optimize etmek hem LCP'yi düşürür (hız), hem mobil veri tüketimini azaltır (mobil deneyim), hem de o görsele anlamlı bir alt metni eklediğinizde erişilebilirliği iyileştirir. Aynı şekilde, butonu 24x24 pikselden 48x48 piksele büyütmek hem dokunmatik mobil hedef boyutunu, hem WCAG 2.2'nin minimum hedef boyutu kriterini karşılar. Dolayısıyla yenilemeyi bu üç başlığı ayrı ayrı değil, birbirini besleyen bir bütün olarak kurgulamak, hem işçilikten hem de bütçeden tasarruf ettirir. Aşağıda her üç ekseni de yenileme bağlamında somut adımlarla açıyoruz; her bölümün başında konuyu önce net biçimde cevaplayıp ardından ayrıntılandırıyoruz.

Yenilerken Core Web Vitals'ı (LCP/INP/CLS) Nasıl Kazanca Çeviririz?

Kısa cevap: yeni tasarım kararlarını, üç temel metriğin "iyi" eşiklerini hedefleyerek alırsınız. 2026 Haziran itibarıyla Google'ın saha verisine dayalı (75. yüzdelik) "iyi" eşikleri şunlardır: LCP (Largest Contentful Paint) ≤ 2,5 sn, INP (Interaction to Next Paint) ≤ 200 ms, CLS (Cumulative Layout Shift) ≤ 0,1. Yenileme, bu metrikleri tasarım aşamasında dahil etmek için ideal andır; çünkü sayfa şablonları, hero kurgusu ve font seçimi sıfırdan belirlenir. Mevcut bir sitede CWV iyileştirmesi çoğu zaman "yamalama" işidir; yenilemede ise bu metrikler bir kısıt değil, tasarım girdisi olarak baştan masaya yatırılır.

Bir noktayı baştan netleştirelim: bu eşikler "ortalama" değil, ziyaretçilerin 75. yüzdeliğinin gördüğü değerdir. Yani sitenizin LCP'sinin "iyi" sayılması için ziyaretlerin en az dörtte üçünde LCP'nin 2,5 saniyenin altında kalması gerekir. Bu nüans yenilemede önemlidir; çünkü hızlı bir geliştirme makinesinde veya fiber bağlantıda "harika" görünen bir sayfa, orta seviye bir telefonda mobil veride ölçüldüğünde eşiğin üstüne çıkabilir. Bu yüzden yenileme testlerini laboratuvar (lab) verisiyle değil, mümkünse gerçek kullanıcı (saha / CrUX) verisiyle doğrulamak gerekir.

Burada kritik bir değişimi hatırlatalım: 12 Mart 2024'te INP, FID'in (First Input Delay) yerini alarak resmî Core Web Vital oldu ve FID emekliye ayrıldı. INP'nin önemi, tek bir ilk etkileşimi değil sayfadaki TÜM etkileşimleri ve etkileşimin tam yaşam döngüsünü (giriş gecikmesi + işleme + sunum) ölçmesidir. Yani yeni sitenizde menü açılması, filtre uygulanması, sepete ekleme gibi her etkileşim INP'ye yansır. Bu da redesign'da "ne kadar JavaScript yüklüyoruz" sorusunu doğrudan bir kullanıcı deneyimi metriğine bağlar. Pratikte gözlemlediğimiz şey şudur: eski sitelerin INP sorunları neredeyse her zaman "üst üste birikmiş üçüncü taraf script'leri" kaynaklıdır; pazarlama etiketleri, canlı sohbet widget'ları, A/B test araçları, sosyal medya gömüleri ana iş parçacığını tıkar. Yenileme, bu birikmiş yükü gözden geçirip gerçekten gerekli olanları yeniden, kontrollü biçimde eklemek için ender bir fırsattır.

Her metrik için yenileme aşamasında alınabilecek somut tasarım/geliştirme kararları şöyle özetlenebilir:

LCP tarafında en görünür kazanç hero bölümünden gelir. Eski sitelerde çok rastladığımız tablo, devasa ve optimize edilmemiş bir hero görseli ya da otomatik oynatılan bir videodur; bunlar LCP'yi 2,5 saniyenin çok üstüne taşır. Yenileme sırasında LCP görselini preload etmek, kritik CSS'i satır içine almak ve yazı tipini preload + font-display: swap ile yüklemek belirleyicidir. Böylece metin fontu beklemeden hemen görünür, en büyük içerik öğesi erken boyanır. Modern format kullanımı da kritiktir: aynı hero görselini WebP veya AVIF olarak sunmak, JPEG/PNG'ye göre ciddi boyut tasarrufu getirir ve doğrudan LCP'ye yansır. Yenilemede sunucu/altyapı seçimi de bu denkleme girer; statik/edge barındırma (CDN üzerinden sunulan içerik) ilk bayt süresini (sunucu yanıtını) kısaltır ve LCP'nin "sunucu" ayağını rahatlatır.

CLS, yenilemede en kolay kazanılan ama en sık ihmal edilen metriktir. En yaygın kök neden görsele yer ayrılmamasıdır: tarayıcı görselin boyutunu sonradan öğrenince sayfa "zıplar". Çözüm nettir; her img, video, iframe ve reklam alanına AÇIK width & height (veya aspect-ratio) verin, banner gibi dinamik içeriğe önceden yer rezerve edin. Fonttan kaynaklı kaymayı da @font-face üzerindeki size-adjust tanımlayıcısı ciddi biçimde azaltır; pratikte CLS'yi örneğin 0,15'ten 0,02'ye düşürebilen bir müdahaledir. Türkçe siteler için burada gözden kaçan bir ayrıntı vardır: web fontunun yedek (fallback) sistem fontuyla metrik açısından uyumlu olması, font yüklenirken oluşan "metin yeniden akışı" kaymasını azaltır. Yenilemede font değiştiriyorsanız bu adımı baştan kurgulamak, sonradan yamamaktan çok daha temizdir. Ayrıca çerez bandı, bildirim çubuğu veya lisans/kampanya şeridi gibi sayfanın üstüne sonradan inen öğelere de yer rezerve etmek, ilk saniyelerdeki kaymayı önler.

INP tarafında ise yenilemenin en büyük fırsatı "JavaScript diyeti"dir. Eski sitelerde biriken eklenti/etiket yığını, ana iş parçacığını uzun görevlerle doldurur ve her tıklama yanıtını geciktirir. Yeni mimaride az script, kod bölme ve uzun görevleri küçük parçalara ayırma INP'yi eşiğin altına çekmenin temel yoludur. Pratik bir örnek: eski WordPress sitelerinde birikmiş 20-30 eklentinin her biri kendi JavaScript'ini yükler; yenilemede bu yığını gerçekten gerekli olanlarla sınırlamak ya da daha hafif bir altyapıya (örneğin az-JS felsefesiyle çalışan modern bir framework'e) geçmek INP'yi tek başına dramatik biçimde iyileştirebilir. Burada altyapı seçimi devreye girer; ağır eklentili bir kurulum ile sade, performans-öncelikli bir mimari arasındaki farkın ne anlama geldiğini hangi CMS seçilmeli rehberimizde ve hazır site mi özel yazılım mı karşılaştırmamızda ayrıntılı ele alıyoruz.

Bu konunun ölçüm ve düzeltme detayları için site hızı ve SEO (Core Web Vitals) rehberimizi okumanızı öneririz; yenileme öncesi ve sonrası ölçüm için ise PageSpeed Insights'ı nasıl yorumlayacağınızı anlatan yazımız pratik bir başlangıç sunar. Yenilemeyi ölçülebilir kılmak isterseniz basit bir disiplin uygulayın: yenileme öncesinde mevcut sayfaların LCP/INP/CLS değerlerini kaydedin, yenilemeden sonra aynı sayfaları tekrar ölçün ve farkı bir tabloya dökün. Böylece "site daha hızlı oldu" gibi öznel bir ifade yerine, müşteriye somut, rakamsal bir kazanç sunmuş olursunuz.

Son olarak şunu vurgulayalım: Core Web Vitals bir sıralama sinyalidir ve müşterilerimizde gördüğümüz örüntü, üç eşiği birden geçen sitelerin ölçülebilir organik SEO iyileşmesi, daha düşük hemen çıkma oranı ve daha yüksek etkileşim elde etmesidir. Yani hız kazanımı yalnızca "teknik bir tik" değil, doğrudan iş sonucudur. İyi bir tasarımın hız ve dönüşümle ilişkisini bütüncül görmek için iyi web tasarımı nasıl olmalı yazımız da bu bölümü tamamlar.

Mobil Deneyimi Yenilerken Neye Dikkat Etmeli?

Kısa cevap: yenilemeyi mobil-öncelikli (mobile-first) kurgulamadan başlatırsanız, en kalabalık kitlenizi en kötü deneyimle karşılarsınız. 2026 itibarıyla mobil cihazlar küresel web trafiğinin yaklaşık %60'ını oluşturuyor (kaynağa ve döneme göre yaklaşık %52-64 arası değişebilir); Türkiye gibi pazarlarda bu oran %80'lere çıkabiliyor. Yani çoğu sitede ziyaretçinin yarıdan fazlası telefondan geliyor. Bu nedenle yenilemede mobil "küçültülmüş masaüstü" değil, birincil tasarım hedefi olmalıdır.

İkinci kritik gerçek SEO ile ilgili: Google'ın Mobile-First Indexing (mobil öncelikli indeksleme) yaklaşımı artık varsayılandır; Google sitenizin MOBİL sürümünü indeksler ve sıralar. Bunun yenileme açısından sonucu nettir: mobilde gizlediğiniz ya da "sonra ekleriz" dediğiniz içerik, Google için pratikte yok hükmündedir. Yeni tasarımda masaüstündeki tüm anlamlı içeriğin (metin, başlıklar, yapısal veri/JSON-LD) mobilde de tam olarak bulunduğundan emin olmak gerekir. Yenilemede sık yapılan bir hata, mobilde uzun metinleri "daha temiz görünsün" diye sekmelerin (accordion) arkasına gizlerken bu içeriği tamamen DOM'dan çıkarmaktır; içeriği gizlemek (CSS ile katlamak) sorun değildir, ama tamamen kaldırmak SEO kaybı doğurur.

Mobil-öncelikli yenileme için somut ilkeler:

• Önce küçük ekran: Tasarımı önce telefonda kurun, sonra büyük ekrana genişletin (progressive enhancement). Tersi yön, yani masaüstünden küçültme, genelde bozuk bir mobil deneyim üretir. Pratikte tasarım dosyalarını (Figma vb.) önce mobil artboard'da hazırlamak, ekibi "mobilde ne fedakarlık edeceğiz" yerine "masaüstünde neyi zenginleştireceğiz" sorusuna yönlendirir.
• İçerik temelli breakpoint: Sabit cihaz boyutlarına saplanmak yerine içeriğin bozulduğu noktada kırılım koyun. Yaygın referanslar telefon için ~360-480px, tablet için ~768px, masaüstü için ~1024px ve üzeridir. Modern CSS ile container queries (öğenin kapsayıcısına göre uyum) ve clamp() tabanlı akışkan (fluid) tipografi, yenilemede çok daha dayanıklı bir düzen sağlar; ekran genişliği yerine bileşenin bulunduğu alana göre uyum sağladığı için, ileride yeni cihaz boyutları çıktığında bile düzen bozulmaz.
• Dokunmatik hedef boyutu: WCAG 2.2'nin SC 2.5.8 (AA) kriteri minimum 24x24 CSS piksel (veya yeterli boşluk) ister; Apple HIG 44x44 pt, Google Material 48x48 dp önerir. Pratik tavsiyemiz butonlar ve bağlantılar için en az 44-48px hedef alanı bırakmaktır. Eski sitelerde sık gördüğümüz "yan yana minik linkler" sorununu yenilemede ortadan kaldırın; özellikle alt menülerde ve filtre alanlarında dokunma hedeflerinin birbirine yapışık olması, mobil kullanıcıyı yanlış öğeye tıklatır ve terk oranını yükseltir.
• Mobilde performans: Mobil cihazlar daha yavaş CPU ve şebeke kullanır; bu yüzden görsel optimizasyonu, lazy-load (görünüm alanına girince yükleme) ve az JavaScript, mobilde Core Web Vitals için belirleyicidir. Masaüstünde "yeterince hızlı" görünen bir sayfa, orta seviye bir telefonda eşiklerin altında kalabilir. Bu yüzden yenileme testlerini mutlaka gerçek bir orta-segment telefonda ve mobil veride yapın.
• Mobil form/ödeme akışı: Mobilde dönüşüm masaüstünden düşük olabilir; bu yüzden form ve ödeme akışını ayrıca optimize edin. Otomatik doldurma (autofill), doğru klavye tipleri (e-posta alanında e-posta klavyesi, telefon alanında numara klavyesi), tek elle erişilebilir yerleşim ve alan sayısının azaltılması terk oranını düşürür. Mobil ekranda "baş parmak bölgesi" (ekranın alt-orta kısmı) en kolay erişilen alandır; birincil eylem butonunu bu bölgeye yerleştirmek dönüşüme katkı sağlar.

Yenileme bu noktada bir denge işidir: bir yandan görünümü tazelerken bir yandan mobil dönüşüm akışını sadeleştirmek gerekir. Mobil-öncelikli tasarımın ilke ve detayları için mobil uyumlu (responsive) web tasarım rehberimize, dönüşüm akışını mobilde sadeleştirme tarafında ise dönüşüm odaklı landing page rehberimize bakabilirsiniz. Genel UI/UX ilkelerini (görsel hiyerarşi, Hick ve Fitts yasaları, mikro etkileşimler) yenilemeye taşımak isterseniz UI/UX tasarım rehberimiz temel çerçeveyi verir. Yenilenecek sitenizin mevcut altyapısını teknik olarak hızlıca görmek isterseniz e-ticaret altyapı tespit aracımız ile hangi platform üzerinde olduğunuzu kontrol edebilir, yenileme kararını veriyle alabilirsiniz.

WCAG 2.2 ile Erişilebilirliği Yenilemenin Bir Parçası Yapmak

Kısa cevap: erişilebilirlik artık "sonra eklenecek bir özellik" değil, yenilemenin altyapısıdır; çünkü hem yasal (EAA) hem de SEO/dönüşüm açısından kazandırır. Yenileme, mevcut bir sitedeki erişilebilirlik borcunu temizlemek için en uygun fırsattır: şablonlar yeniden yazıldığı için anlamlı HTML, doğru kontrast ve klavye erişimi baştan doğru kurulabilir. Mevcut bir sitede erişilebilirliği sonradan iyileştirmek genellikle "üzerine ARIA yapıştırma" çabasına dönüşür; oysa yenilemede doğru, anlamlı HTML iskeletini kurmak hem daha az iş hem de daha kalıcı bir çözümdür.

Standart tarafında durum nettir: WCAG 2.2, 5 Ekim 2023'te resmî W3C Recommendation (web standardı) oldu ve WCAG 2.1'e göre 9 yeni başarı kriteri ekledi (odak görünürlüğü, sürükleme hareketleri, minimum hedef boyutu, tutarlı yardım, gereksiz tekrar girişin önlenmesi, erişilebilir kimlik doğrulama gibi). Aralık 2024'te bir güncelleme aldı ve aynı belge ISO/IEC 40500:2025 olarak da kabul edildi. (WCAG 3.0 ise hâlâ taslak/araştırma aşamasındadır; henüz bir standart değildir, dolayısıyla yenileme projelerinde hedef sürüm 2.2'dir.) Uygunluk seviyeleri A (asgari), AA (yasal/sektör standardı ve pratik hedef) ve AAA (en yüksek) olarak ayrılır; çoğu yasa ve yenileme projesi AA seviyesini hedeflemelidir. AAA her sayfada tam karşılanması beklenen bir seviye değildir; ölçüt AA'dır.

Yasal boyut yenilemeyi aciliyetli kılan asıl etken. Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025'te yürürlüğe girdi; EN 301 549 teknik standardına ve dolayısıyla WCAG 2.1 AA'ya uyum zorunlu hale geldi. İhlal cezaları ülkeye göre 100.000 EUR'a ya da yıllık cironun %4'üne kadar çıkabiliyor; piyasada olan eski hizmetler için geçiş süresi 28 Haziran 2030'a kadar tanınmış durumda. Bunun Türkiye'deki firmalar için anlamı şudur: AB'ye ürün veya hizmet satan (e-ticaret, bankacılık, e-kitap, ulaşım vb.) işletmeler de kapsama girebilir. Türkiye'de özel sektör için EAA kadar kapsamlı tek bir genel yasa henüz aynı sertlikte olmasa da, AB'ye satış yapanlar için bu yükümlülük gerçektir; ayrıca erişilebilirlik SEO ve dönüşüm açısından da fayda sağlar. Dolayısıyla bir yenileme planlıyorsanız, AA uyumunu baştan kapsam içine almak hem riski hem de ileride çıkacak ikinci bir "uyum projesi" maliyetini önler. Pratik bir tavsiye: yenileme sözleşmesine "teslim edilecek site WCAG 2.2 AA hedefler" maddesini açıkça yazın; bu hem ajansı hem müşteriyi koruyan, ölçülebilir bir taahhüttür.

Pratikte yenilemede en çok karşılaştığımız erişilebilirlik hatalarını ve düzeltmelerini şöyle sıralayabiliriz; bunlar WebAIM'in yıllık raporlarında da tespit edilen hataların büyük çoğunluğunu oluşturur:

Bu hataların ötesinde, yenilemede baştan doğru kurmanız gereken temel uygulamalar şunlardır: anlamlı (semantic) HTML kullanın (başlık hiyerarşisini h1-h2-h3 mantığıyla kurun, butonu button ile yapın), tüm anlamlı görsellere alt metni verin, sitenin tamamını klavyeyle gezilebilir kılın, görünür bir odak halkası (focus ring) bırakın, yeterli kontrast sağlayın, form etiketlerini doğru bağlayın ve ARIA'yı yalnızca gerçekten gerektiğinde kullanın. ARIA konusunda altın kural şudur: "yanlış ARIA, ARIA yokluğundan kötüdür"; mümkün olan her yerde doğal HTML öğesini tercih edin, ARIA'yı yalnızca yerel bir karşılığı olmayan durumlar için kullanın. Renk tek başına bilgi taşımamalı (renk körlüğü); örneğin bir hata durumunu yalnızca kırmızıyla değil, metin ve ikonla da belirtin. WCAG 2.2'nin getirdiği görünür odak ve minimum hedef boyutu kriterleri, mobil ve klavye kullanıcıları için yenilemenin görünür kalite farkını oluşturur.

Türkçe siteler için erişilebilirliğin gözden kaçan bir boyutu da karakter ve dil tutarlılığıdır. Sayfa kodlamasının UTF-8 olması ve lang="tr" tanımının doğru verilmesi, hem ekran okuyucuların doğru telaffuzu hem de tarayıcının doğru büyük/küçük harf dönüşümü (özellikle noktalı/noktasız I ayrımı) için gereklidir. Seçtiğiniz yazı tipinin ç, ğ, ı, İ, ö, ş, ü karakterlerini eksiksiz desteklediğini yenileme sırasında test edin; bazı popüler fontlarda "İ/ı" sorunları çıkar ve bu hem estetik hem de okunabilirlik kaybına yol açar.

Erişilebilirliğin standartları, hata tipleri ve test yöntemleri üzerine derinleşmek isterseniz web erişilebilirliği (accessibility) rehberimiz bu bölümü tamamlar. Erişilebilir, hızlı ve mobil-öncelikli bir yeniden tasarımı bir ekiple yürütmek isterseniz web ve mobil UI/UX tasarımı hizmetimizi inceleyebilir; tam kontrol gerektiren, performans-kritik projeler için özel yazılım/website geliştirme hizmetimize bakabilirsiniz. Mevcut sitenizin hız, mobil ve erişilebilirlik durumunu yenileme öncesi ölçtürmek için ise ücretsiz analiz ve teklif sihirbazımızdan başlayabilirsiniz.

Özetle: bir web sitesi yenilemesinin asıl getirisi, görsel tazelemenin ötesinde hız (LCP/INP/CLS), mobil deneyim ve erişilebilirlik (WCAG 2.2 AA) eksenlerinde elde edilen kalıcı kazançtır. Bu üç başlığı yenilemenin başında kapsam içine alırsanız, hem Google sıralamasında hem dönüşüm oranında hem de yasal uyumda ileriye dönük bir avantaj kurarsınız; sonradan eklemeye çalışırsanız çoğu zaman ikinci bir proje ve ikinci bir maliyet doğar. Müşterilerimizde gördüğümüz en sürdürülebilir sonuç, bu üç ekseni yenilemenin başında bir kontrol listesine bağlayan, yenileme öncesi ve sonrası değerleri ölçen ve farkı somut rakamlarla ortaya koyan projelerden çıkar.

Yenilemede En Sık Görülen Hatalar ve Bunlardan Nasıl Kaçınılır?

Web sitesi yenilemede en pahalı hatalar tasarımla değil, geçiş yönetimiyle ilgilidir: 301 yönlendirmesiz URL değişikliği, iyi performans gösteren içeriğin silinmesi, ve baştan/sonra ölçüm kurulmadan "körlemesine" yayına geçilmesi. Müşterilerimizde gördüğümüz klasik senaryo şudur: site daha güzel, daha hızlı, daha modern olur, ama yayından üç hafta sonra organik trafik yarıya iner, telefonlar susar ve kimse nedenini bilemez. Bu üç hatanın ortak özelliği, hepsinin yayın anında değil, yayından haftalar sonra ortaya çıkmasıdır; bu gecikme, kök neden ile sonucu birbirinden koparttığı için teşhisi zorlaştırır. Aşağıda yenileme projelerinde en sık karşılaştığımız hataları, neden olduklarını ve nasıl önleneceğini somut olarak ele alıyoruz. Bu bölüm, web sitesi yenileme rehberinin önceki aşamalarını tamamlayan "tuzaklardan kaçınma" katmanıdır.

İşin özünü tek tabloda görmek isterseniz, en sık yedi hatayı, kök nedenini ve önleyici adımını şöyle özetleyebiliriz:

Hata 1: 301 yönlendirme yapılmadan URL yapısını değiştirmek

Yenilemede en kritik, en sık ve en pahalı hata budur. URL yapısı değişiyorsa (örneğin /hizmetler/web-tasarim iken /cozumler/kurumsal-web oluyorsa, ya da CMS değişimiyle URL kalıpları toptan değişiyorsa) eski adresten yeni adrese kalıcı 301 yönlendirme şarttır. Bunu atlarsanız iki şey aynı anda kaybolur: Google'ın yıllarca biriktirdiği sıralama değeri ve dış sitelerin verdiği backlink otoritesi. Eski URL'lere gelen kullanıcı ve botlar 404 "sayfa bulunamadı" hatasıyla karşılaşır; bot bu sayfayı zamanla indeksten düşürür, kullanıcı geri tuşuna basar. Üstelik bu kayıp tek seferlik değildir: o sayfaya yıllar içinde verilmiş tüm dış bağlantılar artık boşa giden bir adrese işaret ettiği için, başka sitelerin size kazandırdığı otorite de çöp olur.

URL değişikliğinin sinsi tarafı, çoğu zaman bilinçli bir karar olmadan, "yan etki" olarak gerçekleşmesidir. Yenilemede şu durumların hepsi URL'leri sessizce değiştirir ve hepsi 301 gerektirir:

• CMS değişimi (örneğin WordPress'ten headless bir altyapıya geçiş URL kalıbını baştan kurar).
• Kategori/menü yeniden yapılanması (sayfa başka bir üst klasörün altına taşınır).
• Dil/yerelleştirme eklenmesi (kök URL'lerin /tr/ altına alınması gibi).
• Sondaki eğik çizgi (trailing slash), büyük/küçük harf veya Türkçe karakter normalizasyonu.
• Ürün/blog slug'larının "SEO dostu" diye yeniden yazılması.

Doğrusu, yenileme öncesinde mevcut tüm URL'leri çıkarıp (analytics + Search Console + site haritası + sunucu erişim logları birleştirilerek) eski URL → yeni URL eşleme tablosu hazırlamaktır. Tek bir kaynağa güvenmeyin: Search Console "Google'ın bildiği" URL'leri, analytics "trafik alan" URL'leri, erişim logları ise "botların ve dış bağlantıların hâlâ istediği" URL'leri gösterir; bunlar tam örtüşmez. Her eski sayfanın bir karşılığı olmalı; karşılığı kalmayan sayfa en yakın ilgili sayfaya yönlendirilmeli, gerçekten anlamsızsa bilinçli olarak 410 ("kalıcı gitti") verilmelidir. Dikkat edilecek noktalar:

• 301 kullanın, 302 değil. 301 "kalıcı taşındı" der ve sıralama değerini aktarır; 302 "geçici" demektir ve değeri taşımaz. Yanlış kod seçimi en sinsi tuzaklardandır; çünkü tarayıcıda fark edilmez, yalnızca arama motoru farklı davranır.
• Zincir ve döngü yönlendirmeden kaçının. A → B → C şeklinde zincir yerine A → C doğrudan kurun; her ek atlama hız ve tarama bütçesi kaybettirir, bazı durumlarda da değer aktarımını seyreltir. Döngü (A → B → A) ise sayfayı tamamen erişilemez kılar.
• İlgili sayfaya yönlendirin, toptan anasayfaya değil. "Eşi olmayan her sayfayı anasayfaya 301'le" kısayolu, Google tarafından çoğunlukla "yumuşak 404" (soft 404) gibi algılanır ve değer aktarmaz. Konu eşleşmesini koruyun.
• Yönlendirmeyi staging ortamında test edin. Yayına geçmeden önce eşleme tablosunun her satırını kontrol edin; özellikle Türkçe karakter veya büyük/küçük harf farkı olan URL'lerde sorun çıkar.
• www/non-www ve http/https tutarlılığını koruyun. Tek kanonik biçim belirleyin; tüm varyantlar oraya 301'lensin. HTTPS zaten zorunlu temeldir ve Let's Encrypt ile ücretsiz sağlanır; yenilemede http kalıntılarını da kanonik https'e yönlendirin.
• Kanonik (canonical) etiketi ile yönlendirmeyi çelişkiye düşürmeyin. 301 hedefi ile sayfanın rel=canonical işaret ettiği adres aynı olmalı; çelişki, Google'a karışık sinyal gönderir.

Bu konuyu daha derin işleyen kaynaklarımız için teknik SEO denetimi rehberine ve genel çerçeve için SEO nedir, nasıl yapılır yazımıza göz atabilirsiniz. Yenileme bir teknik SEO projesidir; "tasarım işi" değildir.

Hata 2: İyi performans gösteren içeriği silmek veya seyreltmek

"Redesign" kelimesi yanıltıcıdır; çoğu kişi bunu "her şeyi sıfırdan yaz" diye anlar. Oysa yenileme görünümü tazelemektir, mevcut değeri çöpe atmak değil. Müşterilerimizde gördüğümüz tipik kayıp şudur: yıllardır belirli anahtar kelimelerde ilk sırada olan, ayda yüzlerce ziyaretçi getiren bir blog yazısı ya da hizmet sayfası, "eski tasarıma ait" diye silinir veya 200 kelimeye indirgenir. Sayfa gidince ya da içeriği seyreltilince sıralama da gider. Burada kritik bir nüans var: Google bir sayfayı, üzerindeki kelimelerin bütünü ve derinliği üzerinden sıralar. Tasarım uğruna metni "ferahlatmak" adına paragrafları kırpmak, aslında o sayfanın sıralandığı sorgulara verdiği cevabı zayıflatır.

Doğru yaklaşım, yenileme öncesinde bir içerik envanteri ve performans haritası çıkarmaktır:

• Hangi sayfalar en çok organik trafik alıyor? (Search Console + analytics)
• Hangi sayfalar hangi anahtar kelimelerde sıralanıyor? (özellikle ilk 3 ve ilk 10 sıradakiler dokunulmaz kabul edilmeli)
• Hangi sayfalar dönüşüm üretiyor (form, teklif, arama)?
• Hangi sayfalara dışarıdan en çok bağlantı (backlink) gelmiş? (otorite taşıyan sayfalar önceliklidir)
• Hangileri gerçekten ölü ve temizlenebilir?

Bu haritayı çıkardıktan sonra her sayfa için bilinçli bir karar verin. Pratikte dört eylemden biri olur:

İyi performans gösteren sayfaların metnini, başlık yapısını (H1/H2 hiyerarşisini) ve URL'sini koruyun; sadece görünümü ve kullanılabilirliği iyileştirin. İçerik ve SEO baştan planlanmalı, sonradan eklenmemelidir; bu ilke web sitesi nasıl yapılır rehberinde de vurguladığımız temel kuraldır. Sayfa içi optimizasyonu korumak için on-page SEO yazımız pratik bir kontrol listesi sunar.

Hata 3: Önce ve sonra ölçüm kurmadan yayına geçmek

Ölçümsüz yenileme, körlemesine ameliyat gibidir: işe yaradı mı yaramadı mı asla bilemezsiniz. Sık gördüğümüz hata, eski sitenin trafik, dönüşüm ve hız verisini kaydetmeden yeni siteye geçmektir. Bu durumda yeni site daha kötü performans gösterse bile karşılaştıracak bir taban (baseline) olmadığından sorun fark edilmez; fark edildiğinde de geri dönüş zorlaşır. Daha kötüsü, taban olmayınca sorumluluk da belirsizleşir: trafik düşüşü "mevsimsellik mi, yoksa yenileme mi" sorusuna kimse net cevap veremez.

Yayın öncesinde şu taban metrikleri kayıt altına alın:

• Organik trafik ve anahtar kelime sıralamaları (Search Console). En az son 3 ayın eğilimini ekran görüntüsü/dışa aktarma olarak saklayın; tek günün verisi yanıltır.
• Dönüşüm oranı (form gönderimi, teklif talebi, arama, satış). Mutlak sayı kadar oranı da kaydedin.
• Core Web Vitals taban değerleri: LCP (iyi eşik 2,5 saniyenin altı), INP (iyi eşik 200 ms'nin altı), CLS (iyi eşik 0,1'in altı) — hepsi 75. yüzdelik saha verisiyle değerlendirilir. INP, 12 Mart 2024'te FID'in (First Input Delay) yerini alarak resmî Core Web Vital oldu; eski "FID iyiydi" verisine güvenmeyin, çünkü INP etkileşimin tüm yaşam döngüsünü (giriş gecikmesi + işleme + sunum) ölçtüğü için çok daha kapsamlıdır ve genelde daha sıkı bir testtir.
• En çok ziyaret edilen 20-30 sayfanın tek tek trafik ve dönüşüm değeri. Toplam iyi görünürken bireysel kilit sayfalar çökmüş olabilir; ortalama bunu gizler.
• İndekslenen sayfa sayısı ve mevcut 404/hata profili (Search Console kapsam raporu), ki yayın sonrası artışı net görebilesiniz.

Yayın sonrası izleme de en az taban kadar önemlidir. Site haritasını (sitemap) Search Console'a yeniden gönderin, 404 hatalarını ve indeksleme durumunu takip edin, CWV'yi izleyin. İlk haftalarda sıralama ve trafikte dalgalanma normaldir; Google yeni yapıyı yeniden tarayıp değerlendirirken geçici iniş-çıkışlar olur. Bu evrede panik yapıp aceleyle değişiklik yapmak yerine, önce eşleme tablosunda ve indekslemede sorun olup olmadığını kontrol edin: 404'lerde ani artış varsa 301 haritasında eksik vardır; "taranıyor ama indekslenmedi" çoğalıyorsa kanonik veya içerik sinyallerine bakın. Hangi metriğin ne kadar sürede toparlanması beklendiğini bilmek de panik refleksini engeller; kabaca şu çerçeve işe yarar:

Hız tarafında neyi neden ölçtüğünüzü anlamak için Core Web Vitals rehberimiz ve pratik araç kullanımı için PageSpeed Insights yazımız yol gösterir.

Hata 4: Yenilemeyi yalnızca görsel mesele sanmak

Yenileme kararı çoğu zaman "site eski görünüyor" hissiyle alınır, ama gerçek sorunlar genelde yüzeyin altındadır: yavaşlık (CWV başarısızlığı), mobil uyumsuzluk, erişilebilirlik ve yasal eksikler, yönetilemeyen içerik altyapısı. Sadece görünümü yenileyip bu temel sorunları çözmezseniz altı ay sonra yine aynı noktadasınız. Hatta yeni tasarım, ağır hero görselleri, video arka planlar ve gösterişli animasyonlarla geldiğinde, görünüm güzelleşirken hız ve erişilebilirlik daha da kötüleşebilir. Bu yüzden 2026'nın ana ekseni "gösterişli efekt" değil, hız + sadelik + performans-öncelikli tasarımdır. Yenileme sırasında mutlaka şunları da elden geçirin:

• Mobil-öncelik: Google mobil-öncelikli indekslemeyi varsayılan kullanır; sitenizin mobil sürümü indekslenir ve sıralanır. Mobilde eksik içerik doğrudan SEO kaybıdır. Bugün küresel web trafiğinin yaklaşık %60'ı mobilden gelir (Türkiye gibi pazarlarda bu oran %80'e çıkabilir), dolayısıyla "önce mobil tasarla, sonra masaüstüne genişlet" yaklaşımı tercih edilmelidir. Dokunmatik hedefleri yeterince büyük tutun (pratik öneri en az 44-48 px; WCAG 2.2 SC 2.5.8 asgari 24x24 CSS pikseli ister).
• Görsel kaynaklı CLS: Yeni tasarımda eklenen her img/video/iframe/reklam alanına açık genişlik-yükseklik (veya aspect-ratio) verin; aksi halde sayfa yüklenirken içerik kayar ve CLS bozulur. Bu, yenilemede yeni eklenen görsellerle en sık tekrar açılan bir hatadır.
• Erişilebilirlik: Yenileme, WCAG 2.2 AA'ya (5 Ekim 2023'te resmî W3C standardı, ayrıca ISO/IEC 40500:2025) uyum için en doğru fırsattır. WebAIM'in yıllık taramalarında en sık görülen hatalar bellidir: düşük metin kontrastı, alt-metni olmayan görseller, boş bağlantılar, etiketsiz form alanları, boş butonlar ve eksik dil tanımı. Bunlar tam da yenilemede kolayca düzeltilebilecek şeylerdir. Görsellere alt metni, formlara etiket, yeterli kontrast (gövde metni için en az 4,5:1, büyük metin için 3:1), görünür odak halkası ve klavyeyle tam gezinme ekleyin. AB'ye ürün/hizmet satan firmalar için Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025'te yürürlüğe girdi (EN 301 549 / WCAG 2.1 AA zorunlu); piyasadaki eski hizmetler için geçiş süresi 28 Haziran 2030'a kadar. Bu da erişilebilirliği "güzel olsa iyi olur"dan "altyapı" seviyesine taşır.
• Yasal metinler: Yenilemeyi KVKK uyumunu güncellemek için kullanın. Çerez bandı ve çerez politikası, aydınlatma metni ile açık rıza/ticari ileti izninin AYRI düzenlenmesi (KVKK'nın güncel İlke Kararı bunu pekiştirdi; tek kutuda "kabul ediyorum" hukuken sakıncalı), e-ticaret varsa 6502 sayılı kanun gereği mesafeli satış sözleşmesi, ön bilgilendirme formu ve iade/cayma koşulları güncel olmalı.
• Türkçe karakter ve dil: Yeni font seçtiyseniz Türkçe karakterleri (ç, ğ, ı, İ, ö, ş, ü) ve özellikle noktalı/noktasız I ayrımını desteklediğini test edin; bazı popüler fontlarda "İ/ı" sorunları çıkar. UTF-8 ve lang="tr" tanımının korunduğundan emin olun; bu tanım hem erişilebilirlik hem doğru büyük/küçük harf dönüşümü için gereklidir.

Bu konuların derinine inmek isterseniz web erişilebilirliği rehberimiz ve mobil uyumlu tasarım yazımız kapsamlı kaynaklardır.

Hata 5: Altyapıyı ve güvenliği yenileme dışında bırakmak

Görünüm yenilenir ama site hâlâ güncellenmemiş bir CMS çekirdeği, terk edilmiş eklentiler ve zayıf admin parolalarıyla çalışmaya devam ederse, yeni tasarım eski güvenlik borçlarının üzerine inşa edilmiş olur. Bilinen açıkların (CVE) çoğu güncellenmemiş bileşenlerden sömürülür; OWASP Top 10:2025'te yazılım tedarik zinciri riski (A03 Software Supply Chain Failures) artık ayrı bir başlıktır ve güvenlik yapılandırma hatası (A02 Security Misconfiguration) listede 5. sıradan 2. sıraya yükselmiştir. WordPress özelinde en büyük risk çoğunlukla parlak bir sıfır-gün açığı değil, güncellenmemiş veya terk edilmiş üçüncü taraf eklentiler ve korumasız yönetici girişleridir.

Yenileme, bu güvenlik borcunu kapatmak için doğal bir andır. Bu pencerede şunları yapın:

• Kullanılmayan eklenti ve temaları tamamen silin (devre dışı bırakmak yetmez; kod sunucuda durdukça saldırı yüzeyidir).
• Çekirdek, tema ve eklentileri güncel sürüme taşıyın; bakımı bırakılmış eklentileri bakımı sürenlerle değiştirin.
• HTTPS/TLS'i (Let's Encrypt ile ücretsiz, TLS 1.2/1.3) zorunlu kılın ve tüm http varyantlarını https'e 301'leyin.
• Yönetici girişine güçlü parola + 2FA (iki faktörlü doğrulama) ekleyin; giriş formuna rate-limit (kaba kuvvet önleme) koyun.
• Form ve girişlerde sunucu tarafı doğrulama, CSRF token ve girdi temizleme (injection/XSS önleme) uygulayın.
• Düzenli, otomatik, sürümlü ve site dışı (off-site) yedekleme kurun; geri yükleme prosedürünü en az bir kez test edin.
• Önüne CDN + WAF (örn. Cloudflare) koyarak bot/DDoS trafiğini ve yaygın saldırı kalıplarını filtreleyin.

Bunlar yalnızca teknik değil hukuki bir gerekliliktir de: kişisel veri işleyen sitelerde veri güvenliği teknik ve idari tedbirleri KVKK m.12 kapsamında zorunludur, dolayısıyla bir güvenlik açığı aynı anda hem teknik hem hukuki risktir. Bu çerçeveyi web sitesi güvenliği rehberimizde ayrıntılı işliyoruz.

Hata 6: Yanlış altyapı/CMS seçimiyle yenilemek

Bazı projelerde gerçek sorun tasarım değil, yanlış altyapıdır: ağır eklentilerle şişmiş, yönetimi zorlaşmış bir kurulum. Aynı altyapıda kalıp sadece temayı değiştirirseniz, altı ay sonra yine aynı yavaşlık ve aynı yönetim derdiyle baş başa kalırsınız. Yenileme, altyapıyı yeniden değerlendirmek için doğal bir andır. WordPress hâlâ tüm web'in yaklaşık %41,9'unu (CMS pazarının %59,5'i; Haziran 2026, W3Techs) çalıştırır ve 60.000'i aşan eklenti ekosistemiyle güçlüdür; en yakın rakibi olan Shopify (%5,2) ve Wix (%4,3) ile arasındaki fark hâlâ büyüktür. Ancak "herkes kullanıyor" otomatik olarak "size uygun" demek değildir. İçerik ağırlıklı bir pazarlama sitesi için headless CMS + modern framework (Next.js, Astro) hız ve çok kanallılık avantajı sunabilir; yüksek performans/ölçek gereken özgün bir ürün için ise özel yazılım daha doğru olabilir.

Pratik karar çerçevesi şu üç eksende düşünmektir:

Bu kararda sahiplik ve taşınabilirliği de hesaba katın: hazır kurucularda içerik ve tasarım platforma kilitlidir (vendor lock-in) ve çıkış zordur; açık kaynak CMS veya özel yazılımda kod ve veri sizindir. Seçim mantığını hangi CMS seçilmeli yazımızda ve "hazır mı özel mi" kararını ilgili karşılaştırma yazımızda derinlemesine ele alıyoruz.

Hata 7: B2B/kurumsal dönüşümü göz ardı eden yenileme

Estetik olarak çok güzel ama lead üretmeyen bir kurumsal site, yenilemenin amacını ıskalamış demektir. Kurumsal ve B2B sitelerde asıl iş güven inşası ve potansiyel müşteri üretimidir; B2B'de satış döngüsü uzun ve çok karar vericilidir, dolayısıyla site tek başına "satış" değil "eğitim ve güven" rolü oynar. Bu yüzden dönüşüm genelde "satın al" değil "iletişime geç / teklif iste / demo planla"dır. Yeni tasarım uğruna işe yarayan dönüşüm yollarını bozmak, en pahalı görünmez hatadır: form sayfası taşınır ama linki güncellenmez, CTA butonu "tasarıma uymuyor" diye küçültülür, referans ve vaka çalışmaları "dağınık duruyor" diye kaldırılır.

Yenilerken şu dönüşüm öğelerini koruyun veya güçlendirin:

• Üst-katlamada (above the fold) net değer önerisi taşıyan bir anasayfa.
• Tek, net birincil CTA (her ekranda "ne yapmalıyım" sorusu cevaplı olmalı; Hick Yasası gereği seçenek kalabalığı kararı geciktirir).
• Referanslar, müşteri logoları, vaka çalışmaları ve gerçek ekip/adres/telefon gibi güven öğeleri.
• Kısa ve sürtünmesiz formlar (az alan, doğru klavye tipleri, mobilde otomatik doldurma).
• İçerik pazarlaması varlıkları (rehber, vaka, hesap aracı) ve danışmanlık/demo randevu akışı.

Yerel SEO açısından bir nüans daha: yenilemede firma adı-adres-telefon (NAP) bilgilerini değiştirdiyseniz, bunları site, Google Business profili ve dizinlerde birebir aynı tutun; tutarsızlık yerel sıralamayı düşürür. Görünüm güzelleşirken dönüşüm yolları kopmasın. Bu konuda kurumsal web sitesi rehberimiz ve B2B web sitesi tasarımı yazımız ayrıntılı çerçeve sunar.

Sonuç: Yenileme Bir Tasarım Projesi Değil, Bir Geçiş Projesidir

Web sitesi yenileme, görünümü tazelemekten çok daha fazlasıdır; özünde mevcut değeri (sıralama, içerik, trafik, dönüşüm) kaybetmeden yeni bir temele taşıma operasyonudur. En sık üç hata olan 301'siz geçiş, iyi içeriğin silinmesi ve ölçümsüz yayın, bu değerin sessizce buharlaşmasına yol açar. Bunlardan kaçınmanın yolu disiplinli bir geçiş planıdır: yenileme öncesinde URL eşleme tablosu ve içerik/performans envanteri çıkarmak, taban metrikleri (organik trafik, dönüşüm, Core Web Vitals) kaydetmek, staging ortamında 301 haritasını ve erişilebilirliği test etmek, ve yayın sonrası Search Console üzerinden 404, indeksleme ve CWV'yi yakından izlemek.

Özetle başarılı bir yenilemenin altın kuralı: önce ölç, sonra taşı, sonra tekrar ölç. Tasarımı güzelleştirirken altyapı, hız, erişilebilirlik, güvenlik ve yasal uyumu da aynı projeye dahil edin; çünkü bunlar yenilemenin görünmeyen ama kalıcı kazanımlarıdır. Geçici tasarım modaları gelir geçer; hız, erişilebilirlik, mobil-öncelik, net hiyerarşi ve güvenlik gibi kalıcı ilkeler ise her zaman kazandırır. Bir başka deyişle: trend, ilkenin yerini almaz; markanıza uyuyorsa kullanılır, körü körüne takip edilmez.

Sitenizi yenilemeyi düşünüyor ama trafiğinizi ve sıralamanızı kaybetmekten çekiniyorsanız, doğru yerdesiniz. Alis Dijital olarak Kayseri merkezli ekibimizle, yenileme projelerinde 301 yönlendirme haritasından içerik korumaya, Core Web Vitals iyileştirmesinden KVKK uyumuna kadar geçişin her adımını planlıyoruz. Mevcut sitenizin bir denetimden geçirilmesini isterseniz ya da yenileme öncesi yol haritanızı birlikte çıkarmak isterseniz, web ve UI/UX tasarımı hizmetimize göz atabilir veya ücretsiz bir analiz ve teklif talebiyle başlayabilirsiniz. Doğru kurgulanmış bir yenileme, sitenizi yalnızca daha güzel değil; daha hızlı, daha güvenli ve daha çok dönüşüm getiren bir varlığa dönüştürür.