“Sitemizi birkaç yıl önce yaptırdık, artık yenilemeli miyiz?” sorusunun tek bir takvim cevabı yoktur. Eski bir site düzenli bakımla işini iyi yapabilir; yeni bir site ise yanlış içerik veya zor kullanım nedeniyle beklentiyi karşılamayabilir.

Yenileme kararını vermeden önce sorunları üç gruba ayırın: İçerik düzenlemesiyle çözülebilenler, belirli bölümlerin iyileştirilmesini gerektirenler ve altyapıya kadar uzananlar. Bu ayrım, ihtiyacınızdan büyük bir projeye başlamanızı önleyebilir.

İşletmeniz değişti, siteniz aynı kaldıysa

Yeni bir müşteri grubuna hizmet veriyor, farklı bir ürün sunuyor veya başka pazarlara açılıyor olabilirsiniz. Menü yapınız ve sayfa içerikleriniz hâlâ önceki iş modelini anlatıyorsa ziyaretçi yanlış bir izlenim edinir.

Önce mevcut sayfaları listeleyin. Hangi hizmetlerin eksik, hangi bilgilerin eski olduğunu belirleyin. Sorun birkaç sayfadan ibaretse içerik ve gezinme düzenlemesi yeterli olabilir. Yeni iş modeliniz farklı kullanıcı rolleri veya sistem bağlantıları gerektiriyorsa daha kapsamlı bir proje düşünülmelidir.

Temel görevler telefonda tamamlanamıyorsa

Ziyaretçi menüyü açabiliyor, ürünleri karşılaştırabiliyor ve iletişim kurabiliyor mu? Sayfanın küçük ekrana sığması tek başına yeterli değildir. Form alanları, hata mesajları ve açılan pencereler de gerçek telefonlarda denenmelidir.

Örnek bir görev listesi hazırlayın: Hizmet bulma, belge indirme, ürün inceleme ve talep gönderme. Her görevde kullanıcıyı durduran noktaları kaydedin. Bu liste, yenileme projesinin tasarım tercihleri yerine gerçek sorunlar etrafında tanımlanmasını sağlar.

Performans sorunları günlük kullanımı etkiliyorsa

Sayfanın geç açılması, butonların geç yanıt vermesi veya içerik yüklenirken yer değiştirmesi araştırılmalıdır. Google’ın Core Web Vitals yaklaşımı yüklenme, etkileşim ve görsel kararlılığı ayrı ölçümlerle ele alır. Web Vitals açıklaması

Tek bir test puanından hareketle bütün siteyi yeniden yaptırmayın. Önce büyük görseller, gereksiz bileşenler, sunucu yanıtı ve şablon sorunları incelensin. Bazen sınırlı bir teknik iyileştirme yeterlidir; bazen mevcut yapının sınırları ortaya çıkar.

Güncelleme yapmak işletme için zorlaştıysa

Bir telefon numarası değiştirmek bile uzun yazışmalar gerektiriyorsa içerik yönetimini değerlendirin. Ekibinizin hangi alanları düzenleyebileceğini, yanlışlıkla yapılan değişikliğin nasıl geri alınacağını ve yetkilerin nasıl ayrılacağını belirleyin.

Bakımı yapılmayan bileşenler, belirsiz alan adı sahipliği veya yalnızca tek kişinin bildiği erişimler de proje kapsamına alınmalıdır. Bunlar yalnızca görsel yenilemeyle çözülmez; sahiplik ve bakım düzeni gerektirir.

Yenilemede mevcut kazanımları koruyun

Yeni siteye geçişte çalışan sayfaların adreslerini, önemli içerikleri ve ölçüm kurulumlarını envantere alın. Adres değişiyorsa eski ve yeni sayfalar arasında uygun bir yönlendirme planı oluşturun. Google’ın site taşıma rehberi, URL eşleştirmesini ve geçiş sonrası izlemeyi bu sürecin parçaları olarak ele alır. Google site taşıma rehberi

Küçük iyileştirme ile kapsamlı yenilemeyi ayırın

Bir sitede eski fotoğraflar, güncel olmayan açıklamalar ve birkaç çalışmayan bağlantı bulunması, mutlaka yeni bir altyapı gerektiği anlamına gelmez. Mevcut yapı kolay güncellenebiliyor ve temel görevleri yerine getiriyorsa içerik düzenlemesiyle önemli ilerleme sağlanabilir. Sorunun ölçeğini belirlemeden alınan yenileme kararı, bütçeyi asıl ihtiyaçtan uzaklaştırabilir.

Buna karşılık aynı sorun çok sayıda sayfada tekrarlanıyor, yeni bir içerik türü eklemek zorlaşıyor veya iş modelinin gerektirdiği özellikler mevcut yapıya uymuyorsa daha kapsamlı çalışma gerekebilir. Örneğin yalnızca tanıtım amacıyla kurulmuş bir siteden müşteri hesabı, sipariş takibi ve farklı yetkiler içeren bir portal beklemek, birkaç görsel düzenlemeyle karşılanamayabilir.

Öneri olarak sorun listenize her madde için çözüm düzeyi ekleyin: İçerik, belirli bölüm, ortak şablon veya altyapı. Ardından tahmini etki ve uygulama çabasını birlikte değerlendirin. Bu tablo, sağlayıcılardan aynı kapsam için görüş almanızı kolaylaştırır. “Siteyi modernleştirelim” ifadesi tek başına karşılaştırılabilir teklif üretmez.

Kullanıcı testini proje başlamadan yapın

Ekibiniz siteyi bildiği için bazı sorunları fark etmeyebilir. İşletmenizi yakından tanımayan birkaç kişiden gerçekçi görevler yapmasını isteyin. “İlgili hizmeti bulun ve görüşme talebi gönderin” gibi bir görev verin; yol boyunca sürekli tarif etmeyin. Nerede durduklarını ve hangi bilgiyi aradıklarını gözlemleyin.

Bu çalışma bir kullanıcı araştırmasının bütününü oluşturmaz, ancak varsayımları sorgulamak için yararlı olabilir. Bir kişi menüdeki terimi anlamıyorsa konu yalnızca yazı boyutu değildir. Aynı anda herkes hizmet kapsamını bulamıyorsa bilgi düzenini incelemek gerekir. Bulguları kişisel beğeniyle karıştırmadan, gözlenen davranış üzerinden yazın.

Görevleri farklı telefon ve bilgisayarlarda da deneyin. Bağlantı hızı, ekran boyutu ve giriş yöntemi deneyimi değiştirebilir. Yenileme kapsamına girecek maddeler böylece “bizce daha güzel olur” yerine “kullanıcı şu adımı tamamlayamıyor” gerekçesine dayanır.

İçerik envanteri olmadan tasarıma başlamayın

Yeni tasarım hazırlanırken metinlerin sonra yazılacağını düşünmek yaygın bir planlama hatasıdır. Gerçek başlıklar, açıklamalar ve belgeler bilinmeden oluşturulan sayfa, sonradan içeriği taşımakta zorlanabilir. Önce mevcut sayfaları, önemli dosyaları, formları ve içerik sahiplerini listeleyin.

Her içerik için korunacak, birleştirilecek, yeniden yazılacak veya kaldırılacak kararını gerekçesiyle verin. Çok ziyaret edilen bir rehberle artık sunulmayan hizmet sayfası aynı şekilde ele alınmamalıdır. Kullanıcının hâlâ ihtiyaç duyduğu bilgiyi, sadece eski göründüğü için çıkarmayın. Kaldırılacak sayfalarda uygun geçişi planlayın.

İçerik sorumluları metin doğruluğunu, tasarım ekibi sunumu ve teknik ekip uygulamayı birlikte değerlendirmelidir. Gerçek metinle çalışmak, tekrarları ve eksikleri daha erken fark etmeyi sağlar. Sitedeki dil seçenekleri varsa her dilin kapsamını ayrıca kontrol edin; bir dilde yapılan değişikliğin diğerine otomatik yansıdığını varsaymayın.

Teslim ölçütlerini somut görevlerle yazın

“Mobil uyumlu ve hızlı site” ifadesi yerine doğrulanabilecek maddeler oluşturun. Örneğin kullanıcı bir hizmeti bulabilmeli, formu gönderebilmeli ve başarı bilgisini görebilmelidir. İçerik yöneticisi belirlenen alanları düzenleyebilmeli, hata durumunda nasıl destek alacağını bilmelidir. Gerektiğinde teknik performans hedeflerini uzmanınızla ayrıca tanımlayın.

Erişilebilirliği de görsel tasarımın sonuna bırakmayın. Klavye kullanımı, okunabilir metin, alan etiketleri ve anlaşılır hata mesajları kontrol kapsamına alınabilir. Tek bir otomatik puanın bütün kullanıcı deneyimini doğruladığını varsaymayın. Projenin kapsamına göre teknik ve kullanıcı odaklı incelemeler birlikte yapılmalıdır.

Kabul aşamasında yalnızca ana sayfayı değil, farklı içerik türlerini deneyin. Uzun başlık, çok sayıda ürün, eksik görsel ve hatalı form girişi gibi durumlar da uygulansın. Böylece şablonun yalnızca sunum örneklerinde değil, günlük içerikte çalıştığı görülür.

Yayın gününden sonraki sorumlulukları planlayın

Yeni sitenin yayına alınması projenin bütün işlerinin bittiği anlamına gelmez. İlk günlerde form teslimi, önemli bağlantılar, yönlendirmeler ve ölçüm verileri izlenmelidir. İşletme adına bu kontrolleri kimin takip edeceği ve sorunların hangi kanaldan iletileceği belirli olsun.

İçerik güncelleme, teknik bakım ve yeni geliştirme taleplerinin kapsamını da ayırın. Bir başlığı değiştirmekle müşteri paneline yeni bir iş akışı eklemek aynı iş değildir. Sorumluluklar yazılı olduğunda site yeniden kısa sürede yönetilemeyen bir yapıya dönüşmez. Yenilemenin kalıcı değeri, yayından sonra ekibin siteyi sürdürebilmesiyle ortaya çıkar.

Kararı bir ihtiyaç listesine bağlayın

Yenileme teklifinden önce “Yeni sitede kullanıcı hangi işi daha kolay yapacak?” sorusunu cevaplayın. Ardından kapsamı, öncelikleri ve kabul ölçütlerini yazın. Küçük düzenleme yeterliyse onu uygulayın; kapsamlı yenileme gerekiyorsa projeyi somut kullanıcı görevleri, sürdürülebilir yönetim ve güvenilir geçiş planıyla başlatın.