Bir web sitesi projesinin en çok göz ardı edilen kısmı, teslimattan sonraki ilk altı aydır. Tasarım onaylanır, geliştirme biter, site yayına alınır ve herkes rahatlar. Ama sitenin gerçek testi tam da bu noktada başlar: kim, hangi sıklıkla, hangi araçla içeriği güncelleyecek? Bu soruya net bir cevap olmadan teslim edilen projelerin büyük kısmı, birkaç ay içinde yayınlandığı günkü haliyle donup kalıyor.
Sorumluluk neden belirsizleşir
Proje sürecinde tasarım ve geliştirme kararları net bir şekilde ajans veya geliştirici tarafından alınır. Ancak içerik güncelleme genellikle “müşteri tarafı” olarak bırakılır ve kimin bu işi yapacağı asla yazılı hale getirilmez. Sonuç olarak üç senaryodan biri yaşanır: işletme sahibi kendisi yapmaya çalışır ama teknik bilgisi yetmez, bir çalışana devredilir ama o kişi işten ayrıldığında bilgi kaybolur, ya da kimse dokunmaz ve site zamanla güncelliğini yitirir. Teslim toplantısında bu sorumluluğun isim isim belirlenmesi, sonraki altı ayın kaderini büyük ölçüde belirler.
Kim yapmalı: üç gerçekçi model
Birinci model, işletme içinde bir kişinin (genellikle pazarlama veya ofis sorumlusu) küçük güncellemeleri (fiyat değişikliği, yeni ürün ekleme, iletişim bilgisi düzeltme) üstlenmesidir. Bu model, CMS (içerik yönetim sistemi) kullanıcı dostu kurulmuşsa işler; değilse işletme sahibi birkaç denemeden sonra vazgeçer.
İkinci model, ajansla aylık bakım anlaşması yapmaktır. Bu durumda küçük metin değişiklikleri, görsel güncellemeleri ve kampanya sayfaları belirli bir ücret karşılığında ajans tarafından yapılır. Türkiye’deki küçük ve orta ölçekli işletmeler için tipik aylık bakım ücretleri, sitenin büyüklüğüne ve güncelleme sıklığına göre değişen bir aralıkta konumlanır; bu rakam sabit bir kural değil, kapsam ile doğru orantılı bir pazarlıktır.
Üçüncü model, karma yaklaşımdır: küçük metin değişiklikleri işletme içinde yapılır, yapısal değişiklikler (yeni sayfa, form ekleme, entegrasyon) ajansa bırakılır. Pratikte en sürdürülebilir model genellikle budur, çünkü her iki tarafın da yetkinliğine uygun işi üstlenmesini sağlar.
Nasıl yapılmalı: CMS mi, statik yapı mı
Site bir CMS (WordPress, Sanity, benzeri sistemler) üzerine kurulduysa, içerik güncellemesi görece kolaydır: metin kutuları, görsel yükleme alanları hazırdır. Ancak statik veya özel kodlu bir yapıda (örneğin performans odaklı Astro gibi framework’lerle kurulmuş bir site) inşa edildiyse, her metin değişikliği kod dosyasına dokunmayı gerektirebilir. Bu, teslim öncesi karar verilmesi gereken kritik bir noktadır: eğer işletme sık sık kendi başına güncelleme yapacaksa, bir CMS katmanı veya en azından güncellenmesi kolay bir içerik yapısı kurulmalı. Aksi halde her küçük değişiklik için ajansa dönme zorunluluğu, hem maliyeti hem de gecikmeyi artırır.
Pratik bir orta yol, sık değişen alanları (fiyat listesi, kampanya duyurusu, çalışma saatleri) ayrı ve kolay düzenlenebilir bileşenler halinde kurmak, nadiren değişen sayfaları (hakkımızda, hizmet açıklamaları) ise sabit tutmaktır. Bu, hem geliştirme maliyetini makul tutar hem de sık güncelleme ihtiyacını karşılar.
Ne sıklıkla güncellenmeli
Güncelleme sıklığı, sitenin amacına göre değişir ama birkaç genel kural verilebilir. Ürün veya fiyat bilgisi içeren sayfalar, değişiklik olduğu anda güncellenmeli; burada gecikme doğrudan güven kaybına yol açar (eski fiyatla gelen müşteri memnuniyetsizliği gibi). Blog veya makale içeriği, arama motoru görünürlüğünü korumak için düzenli bir ritimde (haftalık, iki haftalık) beslenmelidir; bu konuda tutarlılık, sıklıktan daha önemlidir — ayda bir düzenli yazı, dört ayda bir patlama şeklinde yazılan on yazıdan daha etkilidir. Kurumsal sayfalar (hakkımızda, ekip, sertifikalar) yılda bir veya iki kez gözden geçirilmeli, özellikle ekip değişikliği veya yeni bir yetkinlik kazanıldığında güncellenmelidir.
İhmal edilen bir diğer nokta, teknik güncellemedir: kullanılan yazılım kütüphaneleri, güvenlik yamaları, SSL sertifikası yenilemeleri gibi görünmeyen bakım işleri. Bunlar içerik güncellemesi kadar göze çarpmaz ama aksatıldığında sitenin çökmesine veya güvenlik açığına yol açabilir. Bu tür teknik bakımın kim tarafından, ne sıklıkla yapılacağı da teslim anlaşmasının bir parçası olmalı.
Teslim toplantısında sorulması gereken sorular
Bir web sitesi teslim edilirken, işletme sahibinin ajansına veya geliştiricisine şu soruları sorması, ileride yaşanacak belirsizlikleri büyük ölçüde önler: Hangi sayfaları ben kendim değiştirebilirim, hangileri kod bilgisi gerektirir? Bir metin veya görsel değiştirmek istediğimde hangi araca giriş yapacağım ve bu aracı nasıl kullanacağım konusunda bir eğitim veya rehber var mı? Yapısal bir değişiklik (yeni hizmet sayfası, form ekleme) istediğimde bu ayrı bir ücrete mi tabi, yoksa bir bakım paketine mi dahil? Site içeriğini güncellemezsem ne olur, arama motoru sıralamasını ne kadar etkiler?
Bu soruların cevapları yazılı olarak (sözleşme eki, kısa bir doküman) saklanmalı. Sözlü olarak verilen “tabii ki yardımcı oluruz” gibi cevaplar, altı ay sonra hangi tarafın ne yapacağı konusunda anlaşmazlığa dönüşebilir.
Güncellenmeyen sitenin somut maliyeti
Güncellenmeyen bir site sadece “eski görünmez”, aynı zamanda üç somut sorun yaratır. Birincisi, arama motorları düzenli güncellenen siteleri daha taze ve alakalı olarak değerlendirme eğilimindedir; uzun süre değişmeyen bir site, zamanla rakiplerinin gerisinde kalabilir. İkincisi, yanlış veya eski bilgi (kapanan bir şube, değişen fiyat, artık verilmeyen bir hizmet) doğrudan müşteri güvenini zedeler ve gereksiz telefon trafiğine yol açar. Üçüncüsü, kullanılmayan bir teknik altyapı (güncellenmemiş eklentiler, yamalanmamış güvenlik açıkları) siteyi saldırılara karşı savunmasız bırakır.
Eğitim ve devir süreci ihmal edilmemeli
Teslim toplantısında sorumluluk isimlendirilse bile, o kişinin sistemi gerçekten kullanabilmesi için pratik bir eğitim gerekir. Ekran görüntülü kısa bir kılavuz (hangi menüden hangi alana girilir, bir metin nasıl değiştirilir, bir görsel nasıl yüklenir) hazırlanması, sözlü bir anlatımdan çok daha kalıcıdır; çünkü sözlü anlatım birkaç hafta sonra unutulur, yazılı ve görsel bir kılavuz ise ihtiyaç anında tekrar başvurulabilir bir kaynak haline gelir. Ayrıca sorumlu kişi işten ayrıldığında bu kılavuzun yeni kişiye devredilmesi, bilgi kaybını önler. Küçük işletmelerde bu devir süreci çoğu zaman hiç yazılı hale getirilmez ve her personel değişikliğinde site güncelleme bilgisi sıfırdan öğrenilmeye çalışılır; bu da aylarca süren bir güncelleme sessizliğine yol açabilir.
Acil durum senaryosu için bir plan olmalı
Site güncellemesiyle ilgili bir başka gözden kaçan nokta, acil durum senaryosudur: yanlışlıkla silinen bir sayfa, bozulan bir form, hatalı yayınlanan bir fiyat bilgisi gibi durumlarda kime ulaşılacağı önceden belirlenmelidir. Bu senaryo için bir yedekleme (backup) düzeninin var olup olmadığı, varsa ne sıklıkla yedek alındığı ve bir sorun durumunda geri dönüş süresinin ne kadar olacağı teslim aşamasında netleştirilmelidir. Yedekleme düzeni olmayan bir sitede yapılan hatalı bir güncelleme, bazen düzeltilemeyecek kadar kalıcı hale gelebilir.
Bütçe planlamasına güncelleme maliyetini dahil edin
İşletmeler web sitesi bütçesini genellikle sadece kuruluş maliyeti olarak planlar ve teslim sonrası güncelleme maliyetini hesaba katmaz. Oysa yıllık bütçe planlamasında, sitenin yıl içinde alacağı güncelleme, bakım ve olası yapısal değişikliklerin maliyeti ayrı bir kalem olarak yer almalıdır. Bu kalemin baştan planlanmaması, ihtiyaç ortaya çıktığında “beklenmedik bir masraf” gibi algılanmasına ve güncellemenin ertelenmesine neden olur; ertelenen güncelleme ise yukarıda anlatılan somut maliyetleri (eski bilgi, düşen arama motoru performansı, güvenlik açığı) doğrudan büyütür.
Sonuç: sorumluluğu isimlendirin
Web sitesi teslimi bir bitiş değil, bir başlangıçtır. Projenin uzun vadeli başarısı, tasarımın kalitesinden çok, teslim sonrası kurulan güncelleme düzenine bağlıdır. Bu yüzden teslim toplantısında üç şeyi netleştirmek gerekir: güncellemeyi kim yapacak, hangi araçla yapacak ve ne sıklıkla yapacak. Bu üç soru yazılı olarak cevaplanmadan tamamlanan bir proje, teknik olarak bitmiş ama pratikte yarım kalmış demektir.