Mevcut web siteniz beklentiyi karşılamıyorsa ilk soru çoğu zaman aynıdır: web sitesi yenileme mi yeniden yapım mı? Bu karar yalnızca tasarım beğenisine göre verilmemeli. Sayfa açılış süresi, mobil kullanılabilirlik, içerik yapısı, teknik borç, entegrasyon ihtiyacı ve güvenlik seviyesi birlikte değerlendirilmelidir. Benzer görünen iki sorunun arkasında, aslında tamamen farklı teknik nedenler olabilir. Bir sitede 1-2 saniyelik performans iyileştirmesi yeterli olurken, başka bir projede eski altyapı nedeniyle tüm sistemi yeniden kurmak daha düşük riskli bir seçenek haline gelebilir.

İşin yatırım boyutu da en az teknik taraf kadar önemlidir. Kısmi revizyon, kısa vadede daha ekonomik görünebilir; ancak eski kod tabanı üzerinde yapılan her ek geliştirme bakım maliyetini artırıyorsa birkaç ay sonra toplam sahip olma maliyeti yükselir. Öte yandan yalnızca ana sayfa ve birkaç şablonda sorun varsa tüm sistemi çöpe atmak gereksizdir. Sağlıklı bir karar için ölçülebilir bir çerçeve gerekir.

Bu rehberde karar sürecini teknik ve ticari açıdan ele alıyoruz. Amacımız tek bir doğru cevap vermek değil; mevcut sitenin performansına göre hangi yatırımın daha mantıklı olduğunu netleştirmek.

Kararı neye göre vermelisiniz?

İlk bakılması gereken alanlar nettir: hız, dönüşüm, bakım zorluğu, güvenlik, içerik yönetimi ve yeni ihtiyaçlara uyum. Örneğin son 12 ayda sitenizde 3'ten fazla kritik eklenti sorunu yaşandıysa ve her güncelleme ayrı bir risk yaratıyorsa, mesele yalnızca tasarım değildir. Benzer şekilde mobilde hemen çıkma oranı masaüstüne kıyasla belirgin biçimde yüksekse, sorun kullanıcı deneyimi ve performans katmanında olabilir.

Pratik bir değerlendirme tablosu bu noktada oldukça işe yarar:

  • Kısmi revizyon adayı: Altyapı güncel, yönetim paneli kullanılabilir, SEO yapısı korunabilir, sorun belirli şablonlarda toplanmış.
  • Yeniden yapım adayı: Kod tabanı eski, sayfalar yamalı ilerlemiş, güvenlik açıkları sıklaşıyor, yeni entegrasyonlar mevcut mimariye sığmıyor.

Buradaki en kritik nokta, sorunun yüzeyde mi yoksa çekirdekte mi olduğudur. Menü tasarımı kötü diye tüm sistemi baştan yazmak doğru değildir. Ancak ürün listeleme, üyelik, teklif akışı ve CRM entegrasyonu gibi çekirdek fonksiyonlar sorunluysa kozmetik dokunuşlar sadece zaman kazandırır.

Kısmi revizyon hangi durumlarda doğru yatırımdır?

Kısmi revizyon, mevcut sistemin omurgası sağlamsa güçlü bir seçenektir. Özellikle çalışan bir CMS yapınız varsa, URL mimarisi düzgünse ve ekip içerik girmekte zorlanmıyorsa tam yeniden yapım yerine hedefli bir dönüşüm yapılabilir. Buradaki amaç “görünümü biraz değiştirmek” değil, sınırlı müdahaleyle ölçülebilir iyileşme elde etmektir.

Revizyonun mantıklı olduğu somut işaretler

  • Core Web Vitals metriklerinde küçük sapmalar vardır; örneğin LCP 2.5 saniye sınırının biraz üzerindedir ve görsel optimizasyonla düşürülebilir.
  • Trafik kaybı yapısal değildir. Organik görünürlük korunuyordur, ancak belirli açılış sayfaları düşük performans veriyordur.
  • İçerik envanteri değerlidir. 200'den fazla sayfanın URL yapısını değiştirmek, kazanılmış SEO otoritesini gereksiz yere riske atabilir.
  • Entegrasyonlar çalışıyordur. Formdan CRM'e veri akışı, stok veya teklif API bağlantıları stabil şekilde devam ediyordur.

Örnek senaryo: B2B hizmet sunan bir şirketin 80 sayfalık kurumsal sitesi var. Yönetim paneli güncel, blog trafiği iyi, ancak mobil dönüşüm zayıf. İncelemede sorunların çoğu ağır görseller, gereksiz script yükü ve karışık teklif formunda toplanıyor. Böyle bir tabloda yeniden yapım yerine; bileşen optimizasyonu, form akışının sadeleştirilmesi, tasarım sistemi güncellemesi ve teknik SEO temizliği daha rasyoneldir. Süre de daha kısadır. Çoğu projede 3-6 haftalık kontrollü revizyon, tam yeniden yapıma göre daha az operasyonel risk taşır.

Yeniden yapım ne zaman kaçınılmaz hale gelir?

Bazı projelerde revizyon, aslında eski yapıyı ayakta tutma çabasına dönüşür. Özellikle 5 yıldan eski, farklı ajanslar veya ekipler tarafından parça parça geliştirilmiş sitelerde bu tabloya sık rastlanır. Kod okunabilir değildir, eklentiler birbiriyle çakışır, staging ortamı yoktur, güncelleme sonrası canlı sitede hata çıkar. Böyle bir durumda yeni tasarım eklemek sorunu çözmez.

Yeniden yapımı işaret eden teknik göstergeler

  • Teknik borç yüksektir. Aynı fonksiyon için birden fazla kod yaklaşımı kullanılmıştır. Her değişiklik beklenmedik yan etkiler üretir.
  • Güvenlik riski artmıştır. Desteklenmeyen tema, eski PHP sürümü ya da güncellenmeyen paketler bulunur.
  • Bilgi mimarisi bozulmuştur. Kullanıcı, 3 tıklamada ulaşması gereken içeriğe 7-8 adımda gidiyordur.
  • Yeni iş ihtiyaçları mevcut yapıya sığmıyordur. Bayi paneli, çok dilli yapı, üyelik akışı, self-servis teklifleme veya ERP/CRM entegrasyonu gibi gereksinimler sonradan eklenemeyecek kadar büyümüştür.

Örnek: Üretim sektöründe çalışan bir şirket, web sitesi üzerinden teknik doküman, ürün varyantı ve bayi talebi yönetmek istiyor. Mevcut sitede her ürün sayfası manuel kopyalanmış, filtreleme yok, yönetim panelinde rol bazlı yetkilendirme bulunmuyor. Ayrıca CRM'e veri aktarımı Excel ile yapılıyor. Bu durumda kısmi revizyon, kısa sürede yeni darboğazlar yaratır. Baştan planlanmış bir mimari; modüler içerik modeli, API katmanı, gelişmiş arama ve rol yönetimiyle daha sağlıklı ilerler.

Performans verileri nasıl okunmalı?

Kararı veriye dayandırmak istiyorsanız yalnızca “site yavaş” demek yetmez. En az 4 veri kaynağını birlikte yorumlamak gerekir: analitik veriler, kullanıcı davranışı, teknik testler ve iş sonuçları. Ölçüm yapılmadan verilen kararlar, çoğu zaman tasarım odaklı ama etkisi sınırlı yatırımlarla sonuçlanır.

Bakılması gereken başlıca metrikler

  • Açılış süresi ve Core Web Vitals: LCP, CLS, INP gibi metrikler kullanıcı deneyiminin teknik tarafını gösterir.
  • Dönüşüm oranı: Trafik artıyor ama form gönderimi sabit kalıyorsa sorun içerik hiyerarşisi veya akış tasarımı olabilir.
  • Mobil / masaüstü farkı: Mobilde ciddi sapma varsa responsive yapı yalnızca görsel değil, fonksiyonel olarak da sorunludur.
  • Hata oranı: 404 sayfaları, bozuk yönlendirmeler, form hataları ve JavaScript çakışmaları kararda etkilidir.

Kısa bir kontrol listesi de işinizi kolaylaştırır:

  1. En çok trafik alan ilk 20 sayfayı belirleyin.
  2. Bu sayfalarda dönüşüm, çıkış oranı ve hız verilerini karşılaştırın.
  3. Mobil oturumları ayrı inceleyin.
  4. Yönetim panelinde içerik üretim süresini ölçün; örneğin yeni bir sayfanın yayına alınması 15 dakika mı sürüyor, 2 saat mi?

Tek bir metriğe bakarak hüküm vermek yanıltıcı olabilir. LCP iyi olabilir ama kullanıcı teklif formunu tamamlayamıyordur. Ya da tasarım eski görünürken SEO ve dönüşüm performansı güçlüdür. Böyle bir durumda yeniden yapımın gerekçesi zayıflar.

Maliyet, süre ve risk nasıl karşılaştırılır?

Yatırım kararında yalnızca ilk teklif tutarı değil, geçiş riski de hesaba katılmalıdır. Kısmi revizyonun düşük maliyetli görünmesi sık karşılaşılan bir durumdur; ancak eski sistem üzerinde yapılan her özel geliştirme test süresini uzatabilir. Yeniden yapım ise daha yüksek bir başlangıç bütçesi ister, fakat bakım maliyetini daha öngörülebilir hale getirebilir.

İki yaklaşımın pratik farkı

  • Kısmi revizyon: Yayına alma süresi daha kısadır. Mevcut SEO varlıkları korunur. Ancak eski mimarinin sınırları devam eder.
  • Yeniden yapım: İlk aşamada analiz, UX, yazılım, test ve veri taşıma süreçleri gerekir. Süre daha uzundur; çoğu projede 8-16 hafta aralığı gerçekçidir. Buna karşılık ölçeklenebilirlik artar.

Risk kalemlerini de ayrıca değerlendirmek gerekir:

  • Mevcut URL'lerin değişmesi
  • Form ve entegrasyon akışlarının kesintiye uğraması
  • İçerik taşıma hataları
  • Ekiplerin yeni yönetim paneline adaptasyonu

Bu yüzden karar toplantısında şu soru mutlaka sorulmalıdır: “6 ay sonra tekrar aynı problemi yaşar mıyız?” Cevap evetse kısa vadeli tasarruf yanıltıcı olabilir.

Doğru karar için uygulanabilir bir değerlendirme modeli

Kararı daha nesnel hale getirmek için basit bir puanlama modeli kullanılabilir. Her başlığa 1 ile 5 arası puan verin. 1 iyi durumu, 5 ise yüksek problemi temsil etsin.

  • Performans ve hız
  • Mobil kullanılabilirlik
  • SEO altyapısı
  • Güvenlik ve güncellik
  • İçerik yönetim kolaylığı
  • Entegrasyon kapasitesi
  • Gelecek 12 aylık iş ihtiyaçlarına uyum

Toplam puan 14'ün altındaysa kısmi revizyon çoğu zaman yeterli olur. 15-24 bandında hibrit yaklaşım düşünülebilir: çekirdek sayfaları ve bileşenleri yeniden ele alırken bazı sistem parçalarını korumak. 25 ve üzeri puan ise tam yeniden yapımın güçlü bir aday olduğunu gösterir. Bu kesin bir mühendislik standardı değildir; karar vermeyi kolaylaştıran pratik bir çerçevedir.

Daha teknik ekipler için şu mantık da kullanılabilir:

if (technical_debt > 7 and integration_need == "high"):
    decision = "yeniden yapım"
elif (seo_assets == "strong" and core_architecture == "stable"):
    decision = "kısmi revizyon"
else:
    decision = "detaylı keşif gerekli"

Bu yaklaşım, duygusal veya görsel beğeniye dayalı kararları azaltır. Özellikle kurumsal web projelerinde pazarlama ekibi, BT ekibi ve yönetim farklı önceliklere sahiptir. Ortak bir değerlendirme matrisi, tartışmayı daha somut bir zemine taşır.

Son karar: önce teşhis, sonra yatırım

Web sitesi yenileme mi yeniden yapım mı sorusunun tek satırlık bir cevabı yok. Çalışan bir altyapıyı yalnızca eski görünüyor diye baştan kurmak gereksiz olabilir. Tersine, yapısal olarak yıpranmış bir sistemi kozmetik revizyonlarla taşımaya çalışmak daha pahalıya mal olabilir. En doğru yaklaşım; performans, kullanıcı deneyimi, içerik yönetimi, güvenlik ve entegrasyon gereksinimlerini birlikte incelemektir.

İyi bir karar, yalnızca bugünkü problemi çözmekle kalmaz. Önümüzdeki 12-24 ayda sitenin pazarlama, satış ve operasyon hedeflerine ne kadar uyacağını da hesaba katar. Önce teknik keşif yapılır, ardından yatırım planı çıkarılır. Sağlam karar tam da burada başlar.