Önce sitenizde neyin aksadığını bulun
Ziyaretçiler hizmetlerinizi anlamakta veya sitede aradığını bulmakta zorlanıyorsa, altyapıyı değiştirmeden tasarımı ve içeriği yenilemek yeterli olabilir. Sorun teknik yapıdaysa ve ihtiyaç duyduğunuz özellikleri geliştirmeyi ya da bakımı zorlaştırıyorsa siteyi yeniden yapmak gerekebilir. Bazen de yalnızca tek bir sorunu düzeltmek yeterlidir.
Önce aksayan noktayı bulun. Daha az talep gelmesi ya da analitik sonuçların beklentiyi karşılamaması, tek başına yeni site gerektiği anlamına gelmez. Ölçümde bir değişiklik, bozuk bir form veya farklı bir ziyaretçi kitlesi de aynı sonuca yol açabilir.
Küçük bir düzeltme mi, yeni tasarım mı, yeni altyapı mı?
Proje adları tedarikçiler arasında değişebilir. Tasarım yenileme çalışması; yapı, erişilebilirlik ve kullanıcı yolculuklarında kapsamlı çalışmalar içerebilir, yalnızca renk değiştirmek değildir. Yeniden geliştirme, uygulamanın önemli bir bölümünü değiştirir; ancak aynı CMS'i, içeriği ve URL'leri koruyabilir.
Her tedarikçiden neyin kalacağını, neyin değişeceğini ve nedenini açıklamasını isteyin. Platform kararı ile tasarım kararı ilişkilidir, fakat birbirinin yerine geçmez.
| Yaklaşım | Tipik kapsam | İstenecek kanıt |
|---|---|---|
| Hedefli düzeltme | Formu, entegrasyonu, şablonu veya performans darboğazını düzeltmek | Tekrarlanabilir sorun ve düzeltmenin işe yarayıp yaramadığını gösteren test |
| Tasarım yenileme | İçeriği, gezinmeyi, sayfa düzenlerini ve görsel kimliği gözden geçirmek | Kullanıcı yolculuğu bulguları ve mevcut sistemin değişiklikleri desteklediğinin doğrulanması |
| Yeniden geliştirme | Uygulama kodunun veya platform bileşenlerinin önemli bir kısmını değiştirmek | Belgelenmiş sınırlamalar, değerlendirilmiş alternatifler ve geçiş planı |
Değişikliğe başlamadan mevcut durumu kaydedin
Önemli görevleri belirleyin: hizmet bulmak, talep göndermek, alışverişi tamamlamak veya ürün güncellemek. Bunları kullanımınızı temsil eden cihazlarda test edin. Başarılı gönderimlerin gerçekten ulaşıp ulaşmadığını ve ekibin rutin içerik değişikliklerini tamamlayabildiğini kontrol edin.
Trafik kaynaklarını, taleplerin niteliğini ve ilgili dönemleri karşılaştırın. Ölçüm değişikliklerini ve mevsimsel talebi dikkate alın. Dönüşüm oranının yanında gerçek talep sayısını da kaydedin.
Tekrarlanan hataları, bakım emeğini ve barındırma hizmetinde yaşanan aksaklıkları da toplayın. Denetim, her kusuru siteyi değiştirme gerekçesine dönüştürmek yerine önerilen değişiklikleri kanıtlarla ilişkilendirmelidir.
Tasarımı yenilemek ne zaman yeterli olur?
Sunduğunuz hizmet değişmiş, markanız sitede tutarsız görünmeye başlamış veya ziyaretçiler ne yapacağını anlamakta zorlanıyor olabilir. Altyapınız içerik yayımlamaya, entegrasyonlara ve bakıma hâlâ uygunsa, tasarımı yenileyerek onu koruyabilirsiniz. Böylece gereksiz bir taşıma işine de girmemiş olursunuz.
Önce ziyaretçinin en önemli işlemini gerçek içerikle bir prototipte deneyin. Aradığı hizmeti bulabiliyor, örnekleri anlayabiliyor ve size ulaşabiliyor mu? Telefonda ve klavyeyle kullanımın yanı sıra formdaki hata mesajlarını da kontrol edin.
Tüm tasarımı yenilemekle birkaç bölümü düzeltmeyi karşılaştırın. Birinin mutlaka daha ucuz olduğunu varsaymayın. Kapsamlı içerik çalışması gerektiren bir yenileme, küçük bir sitenin baştan yapılmasından daha fazla iş içerebilir. Yapılacakların maliyetini ve hangi hazırlıklara ihtiyaç duyulduğunu öğrenin.
Siteyi baştan yapmak ne zaman gerekir?
İhtiyaç duyduğunuz özellikleri mevcut altyapıda geliştiremiyorsanız veya desteği biten bileşenler ciddi bakım yükü yaratıyorsa, yeniden geliştirme seçeneğini değerlendirebilirsiniz. Tekrarlanan arızalar, verileri değiştirmenin zorluğu ve güvenilmez entegrasyonlar araştırılmalıdır; bunlar tek başına siteyi baştan yapma kararı değildir.
Önce sürüm güncellemesinin, bir bileşeni değiştirmenin veya kodun belirli bir bölümünü iyileştirmenin yeterli olup olmayacağını sorun. Yeni ve karmaşık bir iş akışı gerekiyorsa platform seçmeden önce en zor kısmını prototiple deneyin.
Yeni yazılan kod kendiliğinden daha güvenli, hızlı ya da ölçeklenebilir olmaz. Erişim yetkileri, güncel bağımlılıklar, yedekten dönüş, izleme ve gerçekçi yük testleri yine gerekir. Büyük projeyi planlarken mevcut güvenlik açıklarını bekletmeyin. Headless mimari de bir seçenek olabilir; ancak getirdiği ek sistem ve bakım işinin neden gerekli olduğu açıklanmalı.
Nedeni bulmak için performans ölçümlerini kullanın
Google PageSpeed Insights, mevcut olduğunda gerçek kullanıcı verilerini simüle edilmiş laboratuvar testleriyle birleştirir. İnsanların yaşadığı deneyimi anlamak için saha verisini, tekrarlanabilir sorunları araştırmak için laboratuvar bulgularını kullanın. Küçük bir sitenin yeterli herkese açık saha verisi olmayabilir.
Core Web Vitals; yükleme, etkileşimlere yanıt hızı ve sayfa düzeninin sabitliğini kapsar. Saha sonuçlarını mobil ve masaüstü için ayrı değerlendirin; laboratuvar puanı bu ölçümlerin yerine geçmez.
Yeniden yazımı onaylamadan önce gecikmenin kaynağını sorun. Büyük medya dosyaları, üçüncü taraf betikler veya yavaş bir entegrasyon hedefli çalışma gerektirebilir. Hangi sayfaların ve ziyaretçilerin yapmak istediği işlemlerin iyileşmesi gerektiğini belirleyin; önerilen uygulamayı başlangıç durumuyla karşılaştırın.
İki örnek üzerinden düşünelim
Bu senaryolar karar sürecini gösterir. Pixel Shield vaka incelemeleri veya sonuç vaatleri değildir.
Hizmetlerini sitesinde iyi anlatamayan bir danışmanlık şirketi
Bir danışmanlık şirketinin desteklenen CMS'i ve güvenilir formu olduğunu, fakat hizmet sayfalarının belirsiz ve mobilde kullanımının zor olduğunu varsayalım. Yenileme, hizmeti ve iletişim sürecini netleştirebilir. Önce başlangıç durumunu kaydedin; ardından işlemleri tamamlayabilmeyı ve uygun talepleri değerlendirin. Sonuçları benzer trafik kaynakları ve dönemlerle karşılaştırın.
Kampanyalarda sorun yaşayan ve stokları elle güncelleyen bir perakendeci
Kampanya trafiğinde sitesi aksayan, personeli sistemler arasında sürekli stok verisi kopyalayan bir perakendeci düşünün. Kapasiteyi, veri tabanı davranışını ve entegrasyon hatalarını araştırın. Hedefli düzeltme, kısmi değişim veya yeniden geliştirme uygun olabilir. Başarı ölçütleri, üzerinde anlaşılan yükte güvenilir deneme alışverişleri ve stok kayıtlarını düzeltmeye harcanan ölçülmüş sürenin azalması olabilir.
Otomasyonu ayrı bir gereksinim olarak ele alın
İletişim formundan CRM'e elle kopyalama yapmak mutlaka siteyi yeniden geliştirmeyi gerektirmez. Desteklenen bir bağlantı veya küçük bir entegrasyon sorunu çözebilir. Hangi verinin ne zaman aktarılacağını, kimin erişebileceğini ve alıcı hizmet çalışmazsa ne olacağını belirleyin.
Yeniden denemeleri, mükerrer kayıtları ve gerektiğinde insan kontrolünü test edin. Yayın sonrası entegrasyon sorumluluğunu da kapsama dahil edin. Yalnızca otomasyon istendiği için değil, genel sistem uygun bir çözümü uygulanamaz kıldığında yeniden geliştirin.
Arama görünürlüğü ve veri geçişini gerçek değişikliklere göre planlayın
Risk, projeye verilen addan çok nelerin değiştiğine bağlıdır. Google'ın URL taşıma rehberi; eski sayfaları ilgili hedeflerle eşleştirmeyi, mümkünse kalıcı sunucu yönlendirmeleri kullanmayı, iç bağlantı ve canonical referanslarını güncellemeyi ve yeni site haritasını göndermeyi önerir. Geçişi izlemeyi ve geçici sıralama dalgalanmaları olabileceğini hesaba katmayı da tavsiye eder. Mümkün olduğunda birbirinden bağımsız büyük değişiklikleri aynı anda yapmayın.
URL'ler değişmese bile yeni ortamı test edin. Google'ın barındırma taşıma rehberi; geçişten önce sayfaları, formları ve dosyaları kontrol etmeyi, sonrasında sayfaların doğru açıldığını ve bot erişimini kontrol etmeyi kapsar.
Ayrıca aktarılan kayıtları, içerik bütünlüğünü ve erişim yetkilerini kimin kontrol edeceğini belirleyin. Geçiş provası yapın ve bu sırada gelen taleplerin veya siparişlerin nasıl işleneceğini de kapsayan geri dönüş planı hazırlayın.
Teklifleri aynı ölçütlerle karşılaştırın
Mümkünse küçük düzeltmeleri, tasarım yenilemeyi ve yeniden geliştirmeyi ayrı seçenekler olarak açıklayan yazılı bir öneri isteyin. Geliştirme, içerik, test, taşıma, eğitim ve bakım için nelerin yapılacağını karşılaştırın. Kendi ekibinizin ayıracağı zamanı ve geçiş sırasında eski ve yeni sistemleri birlikte çalıştırmanın maliyetini de hesaba katın.
Sitenizin neye ihtiyacı olduğunu birlikte inceleyelim
Mevcut sitenizi, yaşadığınız sorunları ve sitenin işinize nasıl katkı sağlamasını istediğinizi bizimle paylaşın. Tasarımı yenilemenin mi, altyapıyı değiştirmenin mi yoksa birkaç sorunu düzeltmenin mi daha uygun olacağını birlikte değerlendirelim.
Sık sorulan sorular
Tasarımı yenilemek her zaman yeniden geliştirmekten ucuz mudur?
Hayır. Gerçek kapsamı, içerik çalışmasını, entegrasyonları, testleri ve sürekli maliyetleri karşılaştırın. Projenin adı hangi seçeneğin daha az emek gerektirdiğini belirlemez.
Yavaş bir site yeniden geliştirilmeli mi?
Her zaman değil. Önce nedeni teşhis edin ve hedefli düzeltmeleri test edin. Doğrulanmış sınırlamalar gereken iyileştirmeleri mevcut sistemde uygulanamaz kılıyorsa yeniden geliştirme anlamlı olur.
CMS'imizi ve mevcut sayfa adreslerini koruyabilir miyiz?
Çoğu zaman evet. Bunu brifte açıkça kararlaştırın ve teslim edilen siteyi test edin. CMS'i veya URL'yi korumak; içerik, işlev ve arama erişilebilirliği kontrollerine duyulan ihtiyacı ortadan kaldırmaz.
