Kurumsal web sitesi yenileme projesi, çoğu şirkette bir tasarım işi gibi başlar ve bir veri taşıma işi gibi biter. Tasarım aşamasında herkes heyecanlıdır: yeni renkler, yeni görseller, daha modern bir ana sayfa. Yayına geçtikten iki hafta sonra ise gündem değişir. Organik trafik düşmüştür, formların bazıları CRM'e düşmemektedir, satış ekibi eski bir ürün sayfasının linkini gönderdiğinde müşteri 404 sayfasıyla karşılaşmaktadır.
Bu yazının amacı, redesign projesini görsel bir tazeleme olarak değil, üç ayrı işin birleşimi olarak planlamanıza yardımcı olmak: kapsam kararı, içerik envanteri ve URL/teknik geçiş. Bu üçünden herhangi biri eksik kalırsa proje ya bitmez ya da bittikten sonra kazandığından çok kaybettirir.
Yazı boyunca kullanılan sayılar, tablolar ve senaryolar açıkça varsayımsaldır. Kendi sitenizin sayfa sayısı, trafik dağılımı ve teknik altyapısı bu rakamları ciddi biçimde değiştirir. Amaç, karar mantığını aktarmak; hazır bir bütçe veya takvim vermek değil.
Yenileme kararını neye dayandırmalısınız?
İlk soru "nasıl yenileyelim" değil, "ne bozuk". Bu soruya net cevap veremeyen projeler, yeni sitede eski problemleri tekrar üretir.
Pratikte redesign talebi genellikle şu beş nedenden birinden gelir ve her biri farklı bir kapsam gerektirir:
Görsel eskime ve marka uyumsuzluğu. Site, şirketin bugünkü kurumsal kimliğini yansıtmıyor. Logo değişmiş, renk paleti güncellenmiş ama site eski görünümde kalmış. Bu genellikle en dar kapsamlı iştir: tasarım katmanı yenilenir, bilgi mimarisi büyük ölçüde korunur. Kurumsal kimlik ile web sitesi arasındaki bu uyum beklentisi, kurumsal kimlik hizmetimizin de tanımladığı gibi, sitenin şirketin fiziksel varlığı ve sunduğu hizmetle tutarlı olmasını gerektirir.
Konumlandırma ve ürün değişikliği. Şirket yeni bir segmente açılmış, ürün portföyü değişmiş ya da tek üründen platforma geçilmiş. Bu durumda asıl iş mesaj ve bilgi mimarisidir. Tasarım, o yeni yapının sonucu olarak değişir. Bu tip projelerde sayfa yapısını olduğu gibi taşımak en büyük hatadır.
Dönüşüm performansı. Trafik var ama form doldurulmuyor, demo talebi gelmiyor. Burada dikkatli olmak gerekir: dönüşüm sorunu her zaman tasarımdan kaynaklanmaz. Teklif yanlış konumlanmış, hedef kitle yanlış olabilir, formda gereksiz alan olabilir. Mochatouch'ın dönüşüm oranı optimizasyonu yazısında sıralanan analiz kaynakları burada karar vermeden önce bakılması gereken yerleri gösteriyor: analitik verisi, A/B testleri, kullanıcı anketleri ve ısı haritaları (Dönüşüm Oranı Optimizasyonu). Bu verilere bakmadan "siteyi yenileyelim, dönüşüm artar" demek, pahalı bir tahmin yapmaktır.
Teknik borç. CMS eski, güncelleme alamıyor, sayfa hızı düşük, mobil deneyim bozuk, güvenlik güncellemeleri gecikiyor. Bu, tasarımdan bağımsız bir platform değişikliği kararıdır ve çoğu zaman en riskli geçişi doğurur, çünkü URL yapısı, form entegrasyonları ve analitik kurulumu topluca değişir.
Operasyonel yavaşlık. Pazarlama ekibi tek bir landing page için iki hafta beklemek zorunda kalıyor, içerik yayınlamak geliştirici gerektiriyor. Bu bir hız problemidir ve çözümü yeni bir görsel dil değil, editörün kendi başına sayfa kurabileceği bir bileşen sistemidir.
Bu nedenleri ayırmanın pratik faydası şudur: proje sonunda başarıyı neye göre ölçeceğinizi baştan belirlersiniz. Teknik borç nedeniyle yapılan bir yenilemeden "lead sayısı ikiye katlansın" beklemek, projeyi başarısız ilan etmenin kolay yoludur.
Yenileme mi, kademeli iyileştirme mi?
Her problem tam yenileme gerektirmez. Kaba bir ayrım şöyle yapılabilir:
| Durum | Muhtemelen yeterli olan | Tam yenileme gerekçesi zayıf/güçlü |
|---|---|---|
| Ana sayfa mesajı ürünü anlatmıyor, diğer sayfalar iyi | Ana sayfa ve birkaç ürün sayfasının yeniden yazımı | Zayıf |
| Sitede 40 sayfa var, 30'u güncel değil ve sahibi yok | İçerik temizliği ve birleştirme | Zayıf |
| CMS güncellenemiyor, geliştirici bulunamıyor | Platform geçişi | Güçlü |
| Ürün yapısı değişti, mevcut menü yeni portföyü taşımıyor | Bilgi mimarisi + tasarım | Güçlü |
| Site mobilde kullanılamıyor, şablon responsive değil | Frontend yeniden yapımı | Güçlü |
Tablodaki ayrım keskin değil. Gerçek projelerde birden fazla satır aynı anda geçerli olur. Yine de bu soruyu sormak, "her şeyi baştan yapalım" refleksini bir adım geciktirir ve bütçenin nereye gittiğini netleştirir.

İlgili okuma: Kurumsal Kimlik Kılavuzu Nasıl Hazırlanır ve Ekiplere Nasıl Uygulatılır?
Kapsamı tanımlamak: proje neyi içerir, neyi içermez
Redesign projelerinde en sık yaşanan bütçe ve takvim sapması, kapsamın yazılı olmamasından doğar. "Web sitesi yenileme" ifadesi, farklı kişilerin kafasında farklı bir iş tanımına karşılık gelir.
Kapsam dokümanında en az şu başlıkların net cevabı olmalıdır:
Sayfa kümesi. Yenilenecek sayfaların listesi, tek tek. "Kurumsal site" demek yetmez. Blog dahil mi? Kariyer sayfaları? Türkçe dışındaki diller? Eski kampanya landing page'leri? Yardım merkezi? Bu listenin çıkarılması, bir sonraki bölümdeki içerik envanterinin de başlangıcıdır.
Şablon sayısı. Tasarım maliyeti sayfa sayısıyla değil, şablon sayısıyla ölçeklenir. Tipik bir B2B kurumsal sitede ana sayfa, çözüm/ürün sayfası, sektör sayfası, hakkımızda, blog listeleme, blog detay, kaynak merkezi, iletişim ve landing page şablonu gibi 8-12 şablon bulunur. Şablonların hangi bileşenlerden oluşacağını baştan konuşmak, "bu sayfa diğerine benzemiyor" tartışmalarını azaltır.
İçerik sorumluluğu. Metinleri kim yazacak? Bu, projelerin en çok geciktiği yerdir. Tasarım biter, geliştirme biter, altı sayfa lorem ipsum ile bekler. İçerik üretimi ajansta mı, şirkette mi, karma mı? Ürün uzmanının kaç saat ayıracağı takvime yazılı mı?
Teknik kapsam. CMS seçimi, hosting, form altyapısı, CRM entegrasyonu, analitik kurulumu, çok dillilik, erişilebilirlik hedefi, performans hedefi. Bunların her biri ayrı bir iş kalemidir.
Kapsam dışı olanlar. Bu bölüm en az diğerleri kadar önemlidir. Ürün içi arayüz, müşteri portalı, e-ticaret modülü, eski blog yazılarının yeniden yazımı, video prodüksiyon. Yazılı olarak kapsam dışına alınmayan her şey, proje ortasında "bunu da halledersiniz değil mi" olarak geri gelir.
Ekip ve karar mekanizması
Kurumsal sitelerde paydaş sayısı fazladır ve bu, tasarım turlarının sonsuza kadar uzamasının ana nedenidir. Baştan tanımlanması gereken üç rol vardır:
- Karar verici: Tasarım ve mesaj onayını kim verir? Tek kişi olmalı. Komite onayı, ortalama bir site üretir.
- Katkı verenler: Satış, ürün, İK, hukuk. Bunlar görüş bildirir, onay vermez. Görüşlerinin hangi aşamada toplanacağı belli olmalıdır.
- Uygulayıcılar: Tasarım, içerik, geliştirme, SEO.
Tasarım turu sayısını baştan sınırlamak da faydalıdır. Örneğin şablon başına iki revizyon turu, üçüncü tur ek iş olarak fiyatlanır. Bu bir katılık değil, geri bildirimi disipline etme yöntemidir.
Takvim: neyin ne zaman beklenmesi gerektiği
Ajansla çalışan projelerde beklenti yönetimi, takvimin kendisi kadar önemlidir. Mochatouch'ın dijital pazarlama onboarding yazısındaki yaklaşım, her dönem için hem beklenebilecek çıktıyı hem de beklenmemesi gerekeni yazmayı öneriyor (Dijital Pazarlama Ajansıyla İlk 90 Gün). Aynı mantığı redesign projesine taşımak, yönetim katıyla yapılan konuşmaları belirgin şekilde kolaylaştırır.
Aşağıdaki takvim tamamen örnek amaçlıdır ve orta ölçekli bir B2B kurumsal sitesi (yaklaşık 40-60 sayfa, blog dahil, tek dil) varsayımına dayanır. Sayfa sayısı, dil sayısı, entegrasyon karmaşıklığı ve içerik üretim kapasitesi bu tabloyu her iki yöne de kaydırır.
| Aşama | Beklenebilecek çıktı | Bu aşamada beklenmemesi gereken |
|---|---|---|
| Keşif ve envanter | Sayfa envanteri, trafik ve dönüşüm verisi, karar gerekçesi, kapsam dokümanı | Tasarım taslağı |
| Bilgi mimarisi | Yeni menü yapısı, sayfa haritası, URL planı taslağı | Nihai metinler |
| Tasarım | Şablon tasarımları, bileşen kütüphanesi, mobil görünümler | Yayına hazır sayfa |
| İçerik üretimi | Sayfa metinleri, görsel ihtiyaç listesi, meta açıklamalar | SEO sonuçları |
| Geliştirme | Çalışan staging sitesi, form ve entegrasyon testleri | Trafik verisi |
| Geçiş ve yayın | Yönlendirme haritası, canlı site, izleme kurulumu | Kararlı organik performans |
| Yayın sonrası izleme | Hata tespiti, indeksleme takibi, ilk düzeltmeler | Nihai trafik değerlendirmesi |
Son satır özellikle önemlidir. Yayına alma, projenin bitişi değil; izleme döneminin başlangıcıdır. Bu dönemi baştan takvime ve bütçeye yazmayan ekipler, yayından sonra çıkan sorunları "ek iş" olarak tartışmak zorunda kalır.
İçerik envanteri: projenin en atlanan ama en belirleyici adımı
İçerik envanteri, sitenizdeki her URL'nin tek bir tabloda listelenmesi ve her biri için bir karar verilmesidir. Bu adım sıkıcıdır, bu yüzden atlanır. Atlandığında sonuç şu olur: yeni site yayına girer, eski sitedeki 80 sayfanın nereye gittiği kimse tarafından bilinmez, arama motorlarından gelen trafik kaybolur, satışın yıllardır paylaştığı linkler kırılır.
Envanter tablosunda hangi sütunlar olmalı?
Minimum set şudur:
- URL: Tam adres.
- Sayfa başlığı ve tipi: Ürün sayfası, blog, kaynak, kurumsal, landing page.
- Son 12 ayın organik trafiği: Analitik aracınızdan. Google Analytics gibi araçlar hangi sayfaların en çok trafik aldığını göstermek için kullanılır.
- Dönüşüm sayısı: Bu sayfadan kaç form, kaç demo talebi geldi.
- Giriş sayfası mı: Kullanıcılar siteye bu sayfadan mı giriyor, yoksa içeriden mi geliyorlar.
- Dış bağlantı var mı: Başka siteler bu sayfaya link vermiş mi.
- İçerik sahibi: Bu sayfanın doğruluğundan kim sorumlu.
- Son güncelleme tarihi.
- Karar: Taşı, yeniden yaz, birleştir, sil, yönlendir.
- Yeni URL: Karar "sil" değilse hedef adres.
Bu tablo genellikle bir e-tabloda tutulur ve projenin tek referans belgesi haline gelir. Tasarımcı da, geliştirici de, içerik yazarı da buraya bakar.
Beş karardan hangisini ne zaman vermeli?
Taşı. Sayfa güncel, performansı iyi, mesajı doğru. Yeni tasarıma olduğu gibi aktarılır, URL korunur. En ucuz karardır ve mümkün olduğunca tercih edilmelidir.
Yeniden yaz. Sayfa gerekli ama içeriği eski, mesajı yeni konumlandırmayla uyumsuz veya çok zayıf. URL korunabilir, içerik değişir.
Birleştir. Aynı konuyu farklı derinliklerde anlatan üç sayfa varsa, bunları tek güçlü sayfaya toplamak hem kullanıcı hem arama motoru açısından genellikle daha iyidir. Birleştirilen sayfaların URL'leri hedef sayfaya yönlendirilir. Birleştirme kararı verirken hangi URL'nin ana sayfa olarak kalacağına, trafiği ve dış bağlantısı en yüksek olana bakarak karar vermek makul bir başlangıç noktasıdır.
Sil. Sayfa artık geçerli değil: kapanmış bir ürün, geçmiş bir etkinlik, alakasız bir duyuru. Trafiği ve dış bağlantısı yoksa silinebilir. Trafiği varsa silinmez, ilgili bir sayfaya yönlendirilir.
Yönlendir. Sayfa kaldırılıyor ama trafiği, dış bağlantısı veya satışın paylaştığı bir geçmişi var. En yakın anlamlı sayfaya yönlendirilir.
Varsayımsal bir envanter örneği
Aşağıdaki tablo, hayali bir B2B SaaS şirketinin sitesinden alınmış gibi düşünülmüş bir örnektir. Rakamlar öğretim amaçlı uydurulmuştur; hiçbir müşteri verisine dayanmaz.
| URL | Tip | 12 aylık organik oturum | Dönüşüm | Dış bağlantı | Karar | Gerekçe |
|---|---|---|---|---|---|---|
| /cozumler/tedarik-planlama | Ürün | 4.200 | 38 | Var | Yeniden yaz | Trafik iyi, mesaj eski ürün paketine göre yazılmış |
| /cozumler/tedarik-planlama-v2 | Ürün | 180 | 2 | Yok | Birleştir | Yukarıdaki sayfanın kopyası, kafa karıştırıyor |
| /blog/2021-lojistik-trendleri | Blog | 90 | 0 | Yok | Sil | Güncelliğini yitirmiş, güncelleme maliyeti değmiyor |
| /blog/stok-devir-hizi-nasil-hesaplanir | Blog | 6.800 | 12 | Var | Taşı | Sitenin en çok trafik alan sayfası, dokunma |
| /webinar/mart-2023 | Etkinlik | 40 | 0 | Yok | Yönlendir | Kaynak merkezine yönlendir, tarihli içerik |
| /hakkimizda | Kurumsal | 1.100 | 4 | Var | Yeniden yaz | Ekip ve yatırım bilgisi güncel değil |
| /fiyatlandirma | Kurumsal | 3.400 | 51 | Yok | Yeniden yaz | Dönüşümün önemli kısmı burada, dikkatle ele alınmalı |
Bu tablodan çıkarılacak pratik ders, karar dağılımının nadiren eşit olmasıdır. Tipik bir sitede trafiğin ve dönüşümün büyük çoğunluğu az sayıda sayfada toplanır. Envanterin en önemli işlevi, o sayfaları tespit edip projenin geri kalanında onları özel bir dikkatle ele almanızı sağlamaktır. 12 ayda 6.800 oturum getiren bir blog yazısının URL'sini "daha düzenli görünsün" diye değiştirmek, kazanılan hiçbir şey karşılığında ciddi bir risk almaktır.
Envanterden bilgi mimarisine geçiş
Envanter bittiğinde elinizde kalması gereken sayfa listesi, yeni menü yapısının ham maddesidir. Burada iki tuzak vardır.
Birincisi, eski menüyü olduğu gibi kopyalamak. Eski menü, şirketin eski organizasyon şemasını yansıtıyor olabilir. B2B alıcısı şirketinizin departman yapısını bilmez; kendi problemini arar. Menüyü problem, çözüm, sektör veya rol eksenlerinden hangisinin alıcınıza daha anlamlı geldiğine göre kurgulamak genellikle daha iyi sonuç verir.
İkincisi, her sayfaya menüde yer açmaya çalışmak. Menü bir arşiv değil, bir navigasyon aracıdır. Arka planda kalan sayfalara iç bağlantılar, arama ve kaynak merkezi üzerinden ulaşılır.
Site yapısını belirlerken hedef, ziyaretçinin aradığı bilgiye hızlı ulaşmasıdır. Bu yapı kararı, XML site haritasının da temelini oluşturur; kurumsal SEO tarafında site haritası oluşturmak ve arama motorlarının siteyi anlamasını kolaylaştırmak teknik SEO adımlarının başında sayılır (Kurumsal SEO).

URL geçişi ve teknik hazırlık
Projenin en teknik ve en riskli bölümü burasıdır. Tasarımdaki bir hata sonradan düzeltilir. Yönlendirme haritasındaki bir hata, düzeltilene kadar her gün trafik kaybettirir.
Yönlendirme haritası nasıl hazırlanır?
Yönlendirme haritası, envanter tablosunun doğal devamıdır: eski URL, yeni URL, yönlendirme tipi.
Temel ilkeler:
URL'yi gerekmedikçe değiştirmeyin. Her yönlendirme küçük bir risktir ve yönetilmesi gereken bir kayıttır. Yeni tasarım, URL değişikliği gerektirmez. URL sadece bilgi mimarisi gerçekten değiştiyse veya mevcut yapı anlamsızsa (örneğin ?p=1847 biçiminde ise) değişmelidir.
Kalıcı yönlendirme kullanın. Sayfa kalıcı olarak taşındıysa 301 kullanılır. Geçici durumlar için 302 vardır ama redesign geçişinde geçici bir durum nadiren söz konusudur.
Zincir yönlendirmelerden kaçının. A sayfası B'ye, B de C'ye yönlendiriyorsa, A doğrudan C'ye bağlanmalıdır. Bu durum özellikle daha önce bir kez taşınmış sitelerde sık görülür; eski yönlendirme kurallarını da kontrol etmek gerekir.
Ana sayfaya toplu yönlendirme yapmayın. Silinen 30 sayfanın hepsini ana sayfaya yönlendirmek kolaydır ama kullanıcı açısından kötü bir deneyimdir. Ürün sayfası arayan biri ana sayfaya düştüğünde çoğunlukla geri döner. En yakın anlamlı sayfa yoksa, düzgün bir 404 sayfası göstermek daha dürüst bir çözümdür.
Yönlendirmeleri yayın öncesi test edin. Staging ortamında ya da bir tabloda tek tek kontrol etmek, yayın gecesi sürpriz yaşamaktan ucuzdur.
Kontrol edilmesi gereken teknik kalemler
Yönlendirmelerin dışında, geçişte gözden kaçan ve sonradan pahalıya mal olan başlıklar:
- Form ve CRM entegrasyonu: Her form, doğru alanlarla, doğru CRM kaydını oluşturuyor mu? Test formu gönderip CRM'de kaydı görmeden yayına geçilmemeli.
- Analitik ve dönüşüm izleme: Yeni sitede izleme kodu her sayfada var mı? Dönüşüm hedefleri yeni URL'lere göre güncellendi mi? Reklam platformlarının dönüşüm etiketleri taşındı mı? Bu kalem atlandığında, yayından sonraki performans tartışması verisiz yapılır.
- Robots.txt ve noindex: Staging ortamında arama motorlarını engellemek için konulan kurallar yayında kaldırıldı mı? Bu, redesign projelerinin klasik felaketidir: site canlıya alınır,
noindexetiketi unutulur, birkaç hafta içinde sayfalar indeksten düşer. - XML site haritası: Yeni URL yapısına göre üretildi mi, arama konsoluna gönderildi mi?
- Sayfa hızı ve mobil uyumluluk: Sayfa hızı, mobil uyumluluk ve HTTPS kullanımı teknik SEO'nun temel kalemleri arasında sayılır. Yeni tasarımın ağır görselleri, eski siteye göre daha yavaş bir sonuç üretebilir; bu yayın öncesi ölçülmelidir.
- HTTPS ve sertifika: Özellikle hosting değişiyorsa, sertifikanın yeni sunucuda çalıştığı doğrulanmalı.
- Sayfa başlıkları ve meta açıklamalar: Taşınan sayfaların mevcut başlıkları korunuyor mu, yoksa şablon otomatik olarak hepsini mi eziyor?
- İç bağlantılar: Eski URL'lere gövde metni içinden verilen linkler güncellendi mi? Bunlar yönlendirme üzerinden çalışır ama zamanla zincir oluşturur.
- Çok dilli yapı: Diller arası ilişki etiketleri (hreflang) doğru kurulmuş mu, her dilin karşılığı doğru sayfaya işaret ediyor mu?
- Erişilebilirlik: Renk kontrastı, klavye ile gezinme, görsellerin alternatif metinleri. Kurumsal alıcılarda, özellikle kamu ve büyük şirket satın alma süreçlerinde bu kalem sorulabilir.
Platform değişiyorsa ek riskler
CMS değişikliği, yenileme projesinin riskini belirgin şekilde artırır. Blog yazılarının toplu aktarımında görseller kaybolabilir, tablolar bozulabilir, özel biçimlendirmeler kaybolur. Aktarım sonrası en azından en çok trafik alan sayfaların tek tek gözle kontrol edilmesi gerekir.
Ayrıca eski platformda çalışan ve kimsenin hatırlamadığı entegrasyonlar olabilir: bir e-posta aracının form bağlantısı, bir canlı destek widget'ı, satış ekibinin kullandığı bir takvim gömme kodu. Bunların envanteri de sayfa envanteri kadar gereklidir.
Yayına alma kontrol listesi
Aşağıdaki liste, yayın gününde ve sonrasında sırayla yapılması önerilen kontrolleri içerir. Bu bir öneri çerçevesidir; sitenizin karmaşıklığına göre maddeler eklenmeli veya çıkarılmalıdır.
Yayından önce (staging ortamında):
- Tüm şablonlar masaüstü ve mobilde gözden geçirildi.
- Her formdan test gönderimi yapıldı ve CRM'de karşılığı görüldü.
- Otomatik e-postalar (teşekkür mesajı, iç bildirim) çalışıyor.
- Analitik kodu tüm sayfalarda mevcut, gerçek zamanlı raporda görünüyor.
- Dönüşüm hedefleri ve reklam etiketleri yeni URL'lere göre güncellendi.
- Yönlendirme haritası hazır, en az trafiği yüksek sayfalar için test edildi.
- 404 sayfası tasarlandı ve faydalı bağlantılar içeriyor.
- Sayfa başlıkları ve meta açıklamalar kontrol edildi.
- Sayfa hızı ölçüldü, eski siteyle karşılaştırıldı.
- Yedek alındı ve geri dönüş planı yazıldı.
Yayın anında:
noindexetiketi ve staging robots kuralları kaldırıldı.- Yönlendirmeler devreye alındı.
- HTTPS ve sertifika doğrulandı.
- XML site haritası güncellendi ve arama konsoluna gönderildi.
- Ana sayfa, en çok trafik alan beş sayfa ve tüm dönüşüm sayfaları canlıda tek tek kontrol edildi.
Yayından sonraki ilk hafta:
- Arama konsolunda tarama hataları ve indeksleme durumu izleniyor.
- 404 kayıtları günlük kontrol ediliyor, eksik yönlendirmeler ekleniyor.
- Analitikte oturum, sayfa görüntüleme ve dönüşüm sayıları önceki döneme göre karşılaştırılıyor.
- Satış ekibinden geri bildirim toplandı: paylaştıkları linkler çalışıyor mu?
- Form gönderimlerinin CRM'e düşmeye devam ettiği doğrulandı.
Yayından sonraki ilk üç ay:
- Organik trafik ve sıralama değişimleri sayfa bazında izleniyor.
- Kullanıcı davranışı verisi (ısı haritası, kayıt izleme) toplanıp incelendi.
- Dönüşüm performansı düşük sayfalar için test planı hazırlandı.
Son grup, projenin kapanışı değil devamıdır. Dönüşüm optimizasyonunun tek seferlik bir işlem olmadığı, kullanıcı davranışı ve rekabet sürekli değiştiği için düzenli veri analizi ve testin gerekli olduğu, CRO yaklaşımının temel önermesidir. Yeni site, bu döngünün daha iyi bir başlangıç noktası olmalıdır; bitiş noktası değil.
Yayın sonrası trafik düşüşünü nasıl yorumlamalı?
Yenileme sonrası trafikte dalgalanma olağandır. Asıl mesele, dalgalanmanın hangi türden olduğunu ayırt edebilmektir. Aşağıdaki varsayımsal senaryo, yorum mantığını göstermek içindir.
Diyelim ki yayından üç hafta sonra organik oturum sayısı, önceki üç haftaya göre 12.000'den 9.600'e düştü. Yüzde 20'lik bir düşüş. Panik yapmadan önce sorulacak sorular şunlardır:
Düşüş hangi sayfalarda? Eğer düşüşün tamamı, kararla silinen 30 blog yazısından geliyorsa bu beklenen bir sonuçtur ve zaten kabul edilmiş bir maliyettir. Eğer düşüş, URL'si korunan ana ürün sayfalarındaysa teknik bir problem aranmalıdır.
Karşılaştırma dönemi adil mi? B2B'de mevsimsellik güçlüdür. Ağustos ile Ekim'i karşılaştırmak yanıltıcıdır. Mümkünse geçen yılın aynı dönemiyle de bakılmalıdır.
İndeksleme tamamlandı mı? URL değiştiyse, arama motorlarının yeni yapıyı taraması zaman alır. Üçüncü hafta, henüz nihai bir değerlendirme dönemi değildir.
Ölçüm aynı mı? Yeni sitede analitik kurulumu değiştiyse, sayılar farklı şeyleri ölçüyor olabilir. Bot filtreleme, iç trafik hariç tutma, oturum tanımı gibi ayarlar sıfırdan kurulmuş olabilir.
Bu dört soru cevaplanmadan verilen "redesign trafiği düşürdü" hükmü, çoğu zaman yanlış aksiyona yol açar. Doğru ilk aksiyon, düşüşün sayfa kırılımını çıkarmak ve o kırılımın envanterdeki kararlarla uyuşup uyuşmadığına bakmaktır.
Aynı şekilde, dönüşüm sayısındaki bir düşüşün sebebi tasarım olmayabilir. Formun bir alanı zorunlu hale gelmiş olabilir, CRM'e giden veri akışında bir kayıp olabilir, teşekkür sayfası dönüşüm olarak sayılmıyor olabilir. Teknik doğrulama yapılmadan tasarım suçlanmamalıdır.

Sık yapılan hatalar
Bu bölüm, önceki bölümlerde dolaylı olarak değinilen risklerin toplu bir özeti değil; ayrıca konuşulmayı hak eden davranış kalıpları.
Tasarımla başlamak. Envanter ve bilgi mimarisi yapılmadan tasarıma başlanan projelerde, tasarım genellikle bir kez daha yapılır. Çünkü sayfa yapısı netleştiğinde şablonların yetmediği ortaya çıkar.
İçeriği son haftaya bırakmak. İçerik üretimi, projelerin en yavaş ve en çok bağımlılık içeren parçasıdır. Ürün uzmanının görüşünü almak, hukuktan onay çıkarmak, referans müşteriden izin istemek haftalar sürer. İçerik takvimini projenin başında kurmak ve düzenli bir ritme bağlamak, bu işi yönetilebilir kılar; içerik üretiminde ritmi bozan şeyin genellikle yeni bir bilgi değil, planlama disiplinsizliği olduğu gözlemi burada da geçerlidir (B2B İçerik Takvimi).
Eski siteyi hemen kapatmak. Yayından sonra en az birkaç hafta eski sitenin bir kopyasına (yayına kapalı biçimde) erişebilmek, kaybolan bir içeriği bulmak için değerlidir.
Ölçüm kurulumunu geliştirmenin son adımı saymak. Analitik, ölçüm ve CRM entegrasyonu, yayın gününde "bir de şunu ekleyelim" diye yapılacak işler değildir. Bunlar test edilmesi gereken işlevlerdir.
Başarıyı tanımlamamak. Proje bittiğinde neye bakılacağı baştan yazılmazsa, değerlendirme herkesin kendi beklentisine göre yapılır. Ölçütün ne olduğu kadar, ne zaman ölçüleceği de yazılmalıdır. Teknik borç nedeniyle yapılan bir yenilemede üç ay sonra sayfa hızına ve yayın hızına bakmak anlamlıdır; dönüşüm oranına bakmak çoğu zaman erkendir.
Her şeyi aynı anda değiştirmek. Tasarım, içerik, URL yapısı, CMS ve hosting aynı anda değişirse, bir sorun çıktığında sebebini bulmak zorlaşır. Mümkünse platform geçişini ve tasarım yenilemesini ayırmak, teşhis kabiliyetinizi korur. Bu her zaman mümkün değildir ama mümkün olduğunda ciddi bir avantaj sağlar.
Nereden başlamalı?
Elinizde henüz kapsam dokümanı yoksa, sıralama şu olabilir:
Önce yenileme gerekçesini bir sayfada yazın: hangi problem, hangi kanıt, projeden sonra neye bakacağız. Sonra içerik envanterini çıkarın; bu adım tek başına, projenin gerçek büyüklüğünü size gösterir ve genellikle ilk tahminden farklı bir tablo ortaya koyar. Envanter bittiğinde kapsamı ve kapsam dışını yazın, karar vericiyi belirleyin, takvimi aşama aşama kurun.
Bu üç adım tamamlandığında, ajansla veya iç ekiple yapacağınız konuşma niteliksel olarak değişir. "Sitemizi yenilemek istiyoruz" cümlesi yerine, kaç sayfanın taşınacağını, kaç şablon gerektiğini, hangi entegrasyonların taşınması gerektiğini ve başarının nasıl ölçüleceğini içeren bir brief ile masaya oturursunuz. Bu brief, hem teklif kalitesini hem de proje sonunda elinize geçen sonucu doğrudan etkiler.
Sıkça Sorulan Sorular
Kurumsal web sitesi yenileme projesi ne kadar sürer?
Genel bir süre vermek yanıltıcı olur, çünkü takvimi belirleyen şey sayfa sayısından çok şablon sayısı, içerik üretim kapasitesi, dil sayısı ve entegrasyon karmaşıklığıdır. Süreyi tahmin etmenin en sağlıklı yolu, aşamaları ayrı ayrı ele almaktır: envanter ve kapsam, bilgi mimarisi, tasarım, içerik, geliştirme, geçiş ve yayın sonrası izleme. Bu aşamalardan hangisinin sizde darboğaz olacağını baştan tespit edin. Çoğu B2B şirketinde bu darboğaz içerik üretimidir, tasarım değil.
Yenileme sırasında URL'lerimizi değiştirmeli miyiz?
Gerekmedikçe hayır. Yeni bir tasarım, URL değişikliği gerektirmez. URL'yi yalnızca bilgi mimarisi gerçekten değiştiyse, mevcut yapı anlamsızsa veya sayfalar birleştiriliyorsa değiştirin. Değiştirdiğiniz her URL için kalıcı (301) yönlendirme kurun, zincir yönlendirme oluşturmayın ve yönlendirmeleri yayın öncesi test edin. Trafiği ve dış bağlantısı en yüksek sayfalara özellikle dokunmamak, alınabilecek en kolay risk azaltma kararıdır.
İçerik envanterini çıkarmadan projeye başlanabilir mi?
Teknik olarak başlanabilir ama bu, projenin gerçek büyüklüğünü bilmeden bütçe ve takvim taahhüdü vermek anlamına gelir. Envanter olmadan hangi sayfaların taşınacağı, hangilerinin yeniden yazılacağı ve kaç yönlendirme gerekeceği bilinmez. Ayrıca yayın sonrası trafik değişimini yorumlamak için de referans noktanız olmaz. Envanter, projenin en ucuz sigortasıdır.
Yayından sonra trafik düşerse ne yapmalıyız?
Önce düşüşün sayfa kırılımını çıkarın. Düşüş, bilinçli olarak silinen sayfalardan geliyorsa bu beklenen bir sonuçtur. URL'si korunan önemli sayfalardan geliyorsa teknik bir sorun arayın: noindex etiketi kalmış olabilir, yönlendirme eksik olabilir, analitik kurulumu farklı ölçüyor olabilir. Karşılaştırma döneminin mevsimsel olarak adil olup olmadığını da kontrol edin. URL yapısı değiştiyse indekslemenin oturması zaman alır; ilk birkaç hafta nihai değerlendirme için erkendir.
Dönüşüm oranımız düşükse yeni bir site bu sorunu çözer mi?
Her zaman değil. Dönüşüm sorununun kaynağı tasarım olabileceği gibi, teklifin kendisi, hedef kitlenin yanlışlığı, formun uzunluğu veya mesajın netliği de olabilir. Yenileme kararı vermeden önce analitik verisine, kullanıcı davranışına ve mümkünse kullanıcı geri bildirimine bakmak, doğru problemi çözdüğünüzden emin olmanızı sağlar. Ayrıca dönüşüm iyileştirmesi tek seferlik bir proje değil, sürekli bir test ve ölçüm döngüsüdür; yeni site bu döngünün başlangıcı olabilir, yerine geçemez.
Projede karar sürecini nasıl hızlandırırız?
Tek bir karar verici belirleyin ve bu kişiyi baştan yazılı olarak duyurun. Diğer paydaşları katkı veren olarak konumlandırın; görüşlerini hangi aşamada ve hangi formatta toplayacağınızı önceden söyleyin. Tasarım revizyon turu sayısını sınırlayın ve geri bildirimleri dağınık kanallardan değil tek bir yerde toplayın. Kurumsal projelerde takvimin en çok kaydığı yer üretim değil, onay bekleme süreleridir.
Not: Bu yazıdaki tüm rakamsal örnekler, tablolar ve senaryolar açıkça varsayımsal öğretim örnekleridir. Gerçek bir müşteri projesine, ölçülmüş bir sonuca veya sektör ortalamasına dayanmazlar. Kendi projenizin kapsamı, takvimi ve risk profili için kendi verinizle çalışın.


