Web sitesi yenileme projesine başlamadan önce amaç, kullanıcı, içerik, teknoloji ve yayın sorumlulukları netleştirilmelidir. Yalnızca “daha modern görünsün” hedefiyle başlayan projeler kısa sürede kişisel tasarım tartışmalarına sıkışır. Doğru sorular ise ekibi ortak bir iş sonucuna bağlar, kapsamı görünür kılar ve yayın gününde ortaya çıkabilecek içerik, SEO veya entegrasyon risklerini erken aşamada azaltır.
Aşağıdaki 12 soru bir teklif formunu doldurmak için değil, projenin neden yapılacağını ve ne zaman başarılı sayılacağını anlamak için kullanılmalıdır. Her sorunun cevabı ilk günden kesin olmak zorunda değildir. Belirsiz alanları açıkça işaretlemek bile yanlış varsayımla ilerlemekten daha değerlidir.
1. Web sitesini neden şimdi yeniliyoruz?
Yenileme kararını tetikleyen somut durum nedir? Marka değiştiği için mi, site mobilde çalışmadığı için mi, ürün yapısı büyüdüğü için mi, içerik yönetimi zorlaştığı için mi yoksa nitelikli talep üretmediği için mi?
Birden fazla neden olabilir; ancak öncelik sırası gerekir. “Eski görünüyor” tek başına yeterli bir problem tanımı değildir. Eski görünümün güveni, içerik tüketimini veya dönüşüm akışını nasıl etkilediği açıklanmalıdır. Böylece tasarım tercihi bir iş gerekçesine bağlanır.
Başlangıç notunda şunları yazın:
- Bugünkü temel problem
- Problemin kullanıcıya ve ekibe etkisi
- Yenileme ertelenirse oluşacak risk
- Projenin sağlaması beklenen ana değişim
2. Öncelikli kullanıcılarımız kimler?
“Herkes” hedef kitle değildir. Satın alma kararı veren kişiyle ürünü araştıran teknik uzman farklı sorular sorabilir. Mevcut müşteri destek ararken potansiyel müşteri güven kanıtı arar. İş ortağı teknik dokümana, aday ise kültür ve çalışma biçimine ihtiyaç duyar.
Öncelikli kullanıcı grupları için şu bilgileri tanımlayın:
- Siteye hangi nedenle gelir?
- İlk olarak hangi bilgiyi arar?
- Karar vermesini ne zorlaştırır?
- Hangi kanıt ona güven verir?
- Başarılı oturumun sonunda ne yapmalıdır?
Bu cevaplar navigasyon, sayfa sırası ve içerik derinliğini belirler. Kullanıcı araştırması yoksa satış, destek ve operasyon ekiplerinin tekrarlanan soruları iyi bir başlangıç kaynağıdır.
3. Sitenin birincil dönüşümü nedir?
Kurumsal sitede dönüşüm her zaman “satın al” değildir. Teklif talebi, keşif görüşmesi, demo isteği, bayi başvurusu, doküman indirme veya belirli bir vaka çalışmasını inceleme olabilir.
Birincil dönüşüm tek ve açık olmalıdır. İkincil dönüşümler, henüz ana adıma hazır olmayan ziyaretçinin ilerlemesini sağlar. Örneğin XRenk için “Proje başlat” birincil; “İşlerimizi incele” ise güven ve bağlam oluşturan ikincil adımdır.
CTA kararlarını verirken şunları kontrol edin:
- CTA metni kullanıcının ne olacağını anlamasını sağlıyor mu?
- Tıklama sonrası sayfa beklentiyi karşılıyor mu?
- Form gerekli bağlamdan fazlasını istiyor mu?
- Mobilde birincil ve ikincil adım ayrışıyor mu?
Formdan önce ziyaretçinin hangi kanıtları görmesi gerektiğini belirlemek için kurumsal sitede teklif toplama akışını inceleyin.
4. Hangi ürün ve hizmetler öncelikli?
Şirketin sunduğu her şeyi aynı görsel ağırlıkla göstermek kullanıcıyı kararsız bırakır. Ticari öncelik, kullanıcı talebi ve marka konumlandırması birlikte değerlendirilmelidir.
Hizmetleri yalnızca isim olarak listelemek yerine her biri için problem, kapsam, teslim ve ilgili kanıt tanımlayın. Bir hizmet diğerinin parçasıysa ilişkiyi açıkça gösterin. Prodüksiyon gibi farklı bir marka veya ortak tarafından sunulan alanları ana hizmetle karıştırmayın.
XRenk hizmet mimarisi, özel yazılım, web, görünürlük, reklam ve marka sistemlerini birbirine bağlı fakat görevleri açık alanlar olarak ele alır.
5. Mevcut içerikten ne korunacak?
Taşıma kararı yalnızca sayfayı yeni tasarıma kopyalamak değildir. Önce içerik envanteri çıkarılmalı ve her URL için bir karar verilmelidir: koru, güncelle, birleştir, yönlendir veya kaldır.
Değerlendirme ölçütleri şunlardır:
- İçerik hâlâ doğru ve güncel mi?
- Kullanıcı için belirli bir soruyu yanıtlıyor mu?
- Organik görünürlük veya referans değeri var mı?
- Başka bir sayfayla tekrar ediyor mu?
- Yeni marka ve hizmet yapısıyla uyumlu mu?
- Yasal veya operasyonel nedenle korunması gerekiyor mu?
İçerik envanteri yapılmadan belirlenen takvim, yazım ve onay işini görünmez bırakır. Tasarım tamamlandığında gerçek metinlerin hâlâ hazır olmaması en sık yayın gecikmesi nedenlerinden biridir.
6. Yeni bilgi mimarisi nasıl kurulacak?
Bilgi mimarisi, şirketin iç departmanlarını değil kullanıcının araştırma yolunu yansıtmalıdır. Ana navigasyonda her sayfayı göstermek gerekmez; önemli görevleri anlaşılır gruplara ayırmak gerekir.
İyi bir sitemap çalışması şu ilişkileri kurar:
- Ana sayfadan hizmetlere
- Hizmetlerden ilgili vaka çalışmalarına
- Vakalardan kullanılan yöntemlere
- Blog içeriklerinden hizmet ve proje sayfalarına
- Bütün karar yollarından uygun iletişim adımına
Her sayfanın benzersiz bir görevi ve arama niyeti olmalıdır. Aynı konuyu küçük farklarla tekrar eden sayfalar hem bakım yükü hem de anlam belirsizliği yaratır.
7. Hangi gerçek kanıtları gösterebiliriz?
Yenileme projesi sırasında görsel boşlukları doldurmak için sahte dashboard, stok ekip fotoğrafı veya doğrulanmamış metrik kullanmak kolaydır. Ancak bu unsurlar gerçek marka güvenini taşımaz.
Kullanılabilecek kanıtları önceden listeleyin:
- Gerçek ürün ve proje ekranları
- Canlı site veya ürün bağlantıları
- Proje bağlamı ve teslimler
- Doğrulanabilir nitel sonuçlar
- Gerçek ekip, süreç veya üretim görüntüleri
- Teknik dokümanlar ve yöntem içerikleri
Gerçek materyal eksikse bunu proje riski olarak kaydedin. Nötr bir görsel çözüm kullanmak, yapılmamış bir işi varmış gibi göstermekten daha doğrudur.
Platform kararını yalnız teknoloji adıyla vermeyin. Hazır sistem ile özel yazılım karşılaştırması, süreç uyumu ve toplam maliyeti aynı çerçevede değerlendirmenize yardımcı olur.
8. Teknik platform hangi ihtiyaçları karşılamalı?
Teknoloji seçimi yalnızca geliştirme ekibinin alışkanlığına göre yapılmamalıdır. İçerik yönetimi, entegrasyonlar, çok dil, güvenlik, performans, barındırma ve bakım sorumluluğu birlikte değerlendirilmelidir.
Sorulması gerekenler:
- İçeriği kim, ne sıklıkta güncelleyecek?
- Onay ve yayın akışı gerekiyor mu?
- CRM, form, analitik veya ürün sistemleriyle entegrasyon var mı?
- Çoklu dil veya bölge planı var mı?
- Site hangi ortamda barındırılacak?
- Yedekleme, güncelleme ve güvenlik takibi kimde olacak?
- Gelecekte hangi sayfa türlerinin çoğalması bekleniyor?
CMS gerekmeyen küçük ve kontrollü bir içerik yapısı dosya tabanlı yönetilebilir. Çok sayıda editör ve sık içerik akışı varsa yönetim aracı daha anlamlı olabilir. İhtiyaç olmayan esnekliği baştan eklemek sistemi gereksiz karmaşıklaştırır.
9. SEO geçiş planı hazır mı?
URL yapısını değiştirmek yalnızca navigasyon kararı değildir. Eski sayfaların geçmiş bağlantıları, indeks durumu ve kullanıcı yer imleri olabilir. Her eski URL için yeni karşılık veya gerekçeli kaldırma kararı verilmelidir.
Geçiş planında şu maddeler bulunmalıdır:
- Mevcut URL ve metadata envanteri
- Yeni URL haritası
- Birebir 301 yönlendirmeler
- Canonical ve hreflang kararları
- İç bağlantı güncellemeleri
- Sitemap ve robots kontrolü
- Yapılandırılmış veri doğrulaması
- Yayın sonrası kırık bağlantı ve tarama denetimi
SEO ve GEO çalışmalarında geçiş, içerik mimarisiyle aynı planın parçasıdır. Eski URL'lerin tamamını ana sayfaya yönlendirmek doğru eşleşme sağlamaz.
10. Erişilebilirlik ve performans hedefleri neler?
Erişilebilirlik ile performans son hafta eklenecek kontrol listeleri değildir. Renk, tipografi, hareket, bileşen ve içerik kararlarını baştan etkiler.
Hedefleri somutlaştırın:
- Klavye ile bütün temel görevler tamamlanabilmeli.
- Focus durumu görünür olmalı.
- Mobil dokunma alanları yeterli olmalı.
- Form etiketleri ve hata mesajları anlaşılır olmalı.
- Reduced motion tercihinde içerik kaybolmamalı.
- Ana görsel boyutları ve oranları önceden belirlenmeli.
- Gereksiz üçüncü taraf scriptler yüklenmemeli.
- Kritik içerik ağır animasyona bağımlı olmamalı.
Bu hedeflerin tasarım kabul kriterlerine yazılması, geliştirme sonunda büyük yeniden çalışma riskini azaltır.
11. İçerik ve karar onayını kim yönetecek?
Web sitesi projelerinde gecikme çoğu zaman teknik geliştirmeden değil, dağınık karar akışından gelir. Her departmanın farklı yorum yaptığı ve son karar sahibinin belli olmadığı durumda ekip aynı ekranı tekrar tekrar düzenler.
Proje başlamadan şu roller belirlenmelidir:
- İş hedefinden sorumlu proje sahibi
- Günlük geri bildirim ve koordinasyon sorumlusu
- İçerik yazarları ve konu uzmanları
- Hukuki veya uyum onayı veren kişi
- Teknik entegrasyon sahibi
- Son yayın onayı veren karar sahibi
Geri bildirim tek yerde, gerekçeli ve önceliklendirilmiş biçimde toplanmalıdır. “Daha çarpıcı olsun” yerine hangi kullanıcı görevinin neden yeterince görünür olmadığı açıklanmalıdır.
12. Başarıyı yayın sonrasında nasıl ölçeceğiz?
Yeni sitenin yayına girmesi projenin sonu değil, ilk gerçek kullanım verisinin başlangıcıdır. Başarı ölçütleri proje öncesi belirlenmezse ekip yalnızca sayfa görüntüleme veya form adedi gibi bağlamsız sayılara bakar.
İş hedefiyle ilişkili göstergeler seçin:
- Doğru hizmet sayfalarına ulaşan ziyaretçiler
- Vaka çalışmasından teklif adımına geçiş
- Nitelikli form gönderimleri
- Form hata ve terk noktaları
- Organik olarak bulunan öncelikli konu kümeleri
- Mobil ve masaüstü görev tamamlama farkları
- Satış ekibinin aldığı başvuruların bağlam kalitesi
Ölçümleme yalnızca gerçekten kullanılacak verileri toplamalı ve kullanıcı gizliliğini gözetmelidir. İlk yayın sonrası içerik, CTA ve kullanıcı akışı için düzenli iyileştirme backlog'u oluşturulmalıdır.
Cevapları proje briefine dönüştürün
Bu 12 sorunun yanıtı tek bir belgede toplanabilir. İyi bir proje briefi en az şu bölümleri içerir:
- Problem ve hedef
- Öncelikli kullanıcılar
- Dönüşüm hiyerarşisi
- Sayfa ve içerik kapsamı
- Gerçek asset envanteri
- Teknik ve entegrasyon ihtiyaçları
- SEO geçiş planı
- Erişilebilirlik ve performans hedefleri
- Roller, onay akışı ve takvim varsayımları
- Yayın ve ölçümleme planı
Belirsiz alanları “sonra bakarız” diye gizlemek yerine varsayım olarak işaretleyin. Böylece keşif sırasında doğrulanabilir ve kapsam değişikliği olduğunda etkisi görülebilir.
URL taşıma planı örneği
Bu tablo yöntemi gösteren temsili adreslerdir; gerçek bir müşterinin geçiş kaydı veya uygulanmış yönlendirme listesi değildir. Yayından önce mevcut sitenin gerçek URL envanteriyle değiştirilir.
| Eski adres | Yeni adres / karar | Beklenen HTTP | Sorumlu | Yayın sonrası kontrol |
|---|---|---|---|---|
| /eski-hizmet | /hizmetler/ilgili-hizmet | Tek adım 301, hedef 200 | Geliştirici | Canonical ve iç bağlantılar yeni adresi göstermeli |
| /urun/eski-ad | /urunler/yeni-ad | Tek adım 301, hedef 200 | İçerik ve geliştirme | Ürün kapsamı gerçekten eşdeğer olmalı |
| /kaldirilan-kampanya | Eşdeğer yoksa yönlendirme yok | 404 veya 410 | İçerik sorumlusu | Ana sayfaya toplu yönlendirme yapılmamalı |
URL taşıma planı örneğini CSV olarak indirin. Dosyayı Excel veya benzeri bir tabloda açıp temsili satırları kendi URL envanterinizle değiştirin. Bu dosya bir sunucu yönlendirme kuralı değildir; karar ve kontrol listesidir.
Form kontrolünde boş/yanlış girişin hata, geçerli gönderimin tek kayıt, aynı gönderimin tekrarının sıfır ek kayıt oluşturduğunu eski ve yeni sitede ayrı deneyin. Adana web tasarım kapsamını bu envanterle birlikte görüşebilirsiniz.
Sık sorulan sorular
Web sitesi yenileme projesi ne kadar sürer?
Süre; sayfa ve dil kapsamına, içerik hazırlığına, entegrasyonlara, karar akışına ve ekibin onay kapasitesine bağlıdır. Keşif yapılmadan verilen kesin süre çoğu zaman görünmeyen işleri hesaba katmaz.
Mevcut sitenin bütün içeriği taşınmalı mı?
Hayır. Her içerik güncellik, kullanıcı ihtiyacı, görünürlük ve yasal gereklilik açısından değerlendirilmelidir. Koruma, güncelleme, birleştirme, yönlendirme veya kaldırma kararı verilmelidir.
Yenileme sırasında SEO kaybı nasıl azaltılır?
URL envanteri ve birebir yönlendirmeler hazırlanmalı; metadata, canonical, iç bağlantılar, sitemap ve yapılandırılmış veri kontrol edilmelidir. Yayından sonra kırık bağlantı ve tarama denetimi yapılmalıdır.
Sonuç: Tasarımdan önce doğru karar çerçevesini kurun
Web sitesi yenileme, yalnızca yeni bir arayüz üretme işi değildir. Marka, içerik, teknoloji ve dönüşüm sistemini ortak hedef etrafında yeniden düzenleme fırsatıdır. Bu 12 soruya verdiğiniz yanıtları uygulanabilir bir kapsam hâline getirmek için web tasarım yaklaşımımızı inceleyebilir veya projenizi başlatabilirsiniz.
Kaynaklar ve ek okuma
-
Google Search Central: URL değişiklikleriyle site taşıma: Eski ve yeni adresleri eşleştirme, yönlendirme ve taşıma sonrası izleme adımlarını açıklar; yazıdaki URL taşıma planının teknik dayanağıdır.
-
web.dev: Core Web Vitals: Yenileme öncesi ve sonrası performansı aynı kullanıcı deneyimi ölçütleriyle değerlendirmek için LCP, INP ve CLS tanımlarını sağlar.