Web Sitesi Yayına Alındıktan Sonra: Bakım, Güncelleme ve Yedekleme Rehberi

Bir web sitesi projesinin en çok yanlış anlaşılan anı yayın günü. İşletme sahibi için iş orada bitiyor; oysa site, yayına alındığı gün en güncel hâlindedir ve o günden sonra her ay biraz eskir. Yazılım güncelleme ister, alan adının ve sertifikanın süresi dolar, telefon numarası ya da ekip değişir, form bir gün sessizce çalışmayı bırakır. Web sitesi bir kez basılıp dağıtılan bir broşür değil; düzenli kontrol isteyen, yaşayan bir altyapıdır. Bu rehberde yayına aldığımız hekim ve kurumsal sitelerde izlediğimiz bakım takvimini, en sık unutulan alan adı, hosting ve SSL konusunu, doğru yedekleme düzenini ve her bakımdan sonra neleri test ettiğimizi anlatıyoruz.

Web sitesi yayına alındıktan sonra neden bakım ister?

Kısa cevap: çünkü site yayına alındığı gün en güncel hâlindedir ve o günden sonra yazılımı, süreli hizmetleri ve içeriği eskimeye başlar. Bakım, siteyi yeniden yapmak değil; sitenin çalışır, güvenli ve doğru kalmasını sağlayan düzenli kontrollerin adıdır.

Siteyi yerinde duran bir broşür gibi düşünmek kolay. Oysa site yerinde dursa bile etrafındaki her şey değişiyor. Eskimenin dört kaynağı var:

• Yazılım: WordPress gibi içerik yönetim sistemli sitelerde çekirdek, tema ve eklentiler düzenli olarak güncellenir; bu güncellemelerin bir kısmı keşfedilen güvenlik açıklarını kapatır. Güncellenmeyen tek bir eklenti, sitenin en zayıf halkası olabilir.
• Süreli hizmetler: alan adı, hosting, SSL sertifikası ve kurumsal e-postanın her birinin bir bitiş tarihi var. Biri yenilenmezse site ya hiç açılmaz ya da ziyaretçiyi bir uyarıyla karşılar.
• Dış dünya: tarayıcılar, Google'ın kuralları, e-posta sağlayıcılarının spam filtreleri ve kişisel veri uygulamaları değişir. Dün sorunsuz çalışan bir form, bugün e-postası spam klasörüne düşen bir forma dönüşebilir.
• İçerik: adres, telefon, çalışma saatleri, ekip, sunulan hizmetler ve fiyat bilgisi gibi detaylar zamanla değişir. Klinikten ayrılmış bir hekimin hâlâ ekip sayfasında durması, ziyaretçiye sitenin takip edilmediğini söyler.

Statik sitelerde, yani yönetim paneli ve veritabanı olmadan hazır sayfalar olarak yayınlanan sitelerde yazılım yükü belirgin biçimde hafiftir; güncellenecek eklenti yoktur. Ama süreli hizmetler, form, içerik ve yedek konusu statik sitede de aynen geçerlidir.

Bakımsız sitenin belirtileri

• Tarayıcının adres çubuğunda "güvenli değil" ya da sertifika uyarısı çıkıyor.
• Telefonlar çalıyor ama iletişim formundan uzun zamandır tek mesaj gelmedi.
• Sitede eski telefon numarası, taşınmadan önceki adres ya da artık verilmeyen bir hizmet duruyor.
• Yönetim panelinde bekleyen güncelleme bildirimleri birikmiş.
• Search Console'dan gelen hata e-postaları okunmadan arşivleniyor.
• Alt bilgideki telif yılı ve son blog yazısının tarihi birkaç yıl öncesini gösteriyor.
• Gömülü harita, video ya da yorum alanı boş bir kutu olarak görünüyor.

Hangi bakım işi ne sıklıkla yapılmalı?

Kısa cevap: yedek ve güvenlik güncellemeleri sürekli, test ve kontrol işleri aylık ya da üç aylık, yenileme tarihleri ve hukuki metinler yıllık. Aşağıdaki takvim, yayına aldığımız sitelerde izlediğimiz düzenin sade bir özeti; site ne kadar sık değişiyorsa sıklıklar o kadar sıkılaştırılabilir.

Takvimdeki en önemli sütun aslında üçüncüsü. Bakımın aksadığı sitelerde sorun çoğu zaman bilgisizlik değil, sahipsizliktir: işletme ajansın baktığını, ajans işletmenin takip ettiğini düşünür. Her satırın yanında bir isim yazılı olduğunda takvim gerçekten işler.

Siteye yeni bir form, canlı destek aracı ya da reklam takip kodu eklendiğinde hukuki metinlerin de güncellenmesi gerekir. Hangi metnin neyi kapsadığını web sitesi hukuki metinleri rehberimizde anlattık.

Alan adı, hosting ve SSL sertifikası neden en sık unutulan konu?

Kısa cevap: çünkü üçü de yılda bir ya da daha seyrek hatırlanan, kimsenin günlük işi olmayan kalemler; ama biri aksadığında site erişilemez hâle gelir. Üstelik bitiş uyarıları çoğu zaman kimsenin okumadığı bir e-posta adresine gidiyor.

Alan adı: hem sitenin hem e-postanın adresi

Alan adının süresi dolduğunda kayıt firması alan adının yönlendirmesini keser; site açılmaz, o alan adıyla çalışan kurumsal e-posta adresleri de posta alamaz. Süresi dolan alan adı bir süre daha eski sahibi tarafından geri alınabilir, ancak bu dönem sınırlıdır ve uzantıya göre değişir; dönem bittiğinde alan adı serbest kalır ve başkası tarafından alınabilir.

• Otomatik yenileme açık olsun: bu ayar her kayıt firmasında varsayılan olarak açık gelmeyebilir; panelde tek tek kontrol edin.
• Kayıtlı kart güncel olsun: kartın süresi dolmuşsa otomatik yenileme de çalışmaz. Kart yenilendiğinde alan adı ve hosting panellerindeki ödeme bilgisini güncellemek en çok unutulan adımlardan biridir.
• Uyarılar doğru kişiye gitsin: kayıt hesabındaki e-posta adresi ayrılmış bir çalışana, eski bir ajansa ya da artık bakılmayan bir adrese aitse bitiş uyarıları boşa gider.
• Alan adı işletmenin adına kayıtlı olsun: alan adı, markanın kendisi kadar değerli bir varlıktır. Ajansın ya da bir çalışanın kişisel hesabında duran alan adının nasıl devralınacağını hesap ve erişim devri rehberimizde anlattık.

".tr" uzantılı alan adları, 14 Eylül 2022'den bu yana Bilgi Teknolojileri ve İletişim Kurumu bünyesindeki TRABİS (.tr Ağ Bilgi Sistemi) üzerinden, yetkili kayıt kuruluşları aracılığıyla yönetiliyor. Bu alan adlarında da yenileme tarihini ve kayıt bilgilerinin güncelliğini aynı titizlikle takip etmek gerekiyor.

Hosting: sitenin dosyalarının durduğu yer

Hosting süresi dolduğunda site kapanır. Hizmet sona erdikten sonra dosyaların ne kadar süre saklanacağı firmaya göre değişir; elinizde güncel bir yedek yoksa geri dönüş olmayabilir. Bu yüzden hosting yenilemesi ile yedekleme aynı kontrol listesinde durmalı.

SSL sertifikası: kısalan ömür, artan önem

SSL sertifikası (bugünkü teknik adıyla TLS) ziyaretçiyle site arasındaki bağlantıyı şifreler ve adres çubuğundaki kilidi sağlar. Süresi dolduğunda tarayıcılar siteyi açmadan önce ziyaretçiye bir güvenlik uyarısı gösterir; form dolduracak ya da randevu alacak birinin o uyarıyı geçip devam etmesi beklenmez.

Sertifika ömürleri de kısalıyor. Tarayıcı üreticileri ile sertifika sağlayıcılarının oluşturduğu CA/Browser Forum, Nisan 2025'te kabul ettiği kararla herkese açık TLS sertifikalarının azami geçerlilik süresini kademeli olarak düşürdü:

Yılda bir kez elle sertifika yenilemek bu takvimde artık gerçekçi değil; otomatik yenileme artık şart. Hosting panelinizde sertifikanın otomatik yenilendiğini doğrulayın ve hatırlatma e-postasına güvenmeyin: ücretsiz sertifika sağlayıcısı Let's Encrypt, süre dolum hatırlatma e-postalarını Haziran 2025'te sonlandırdı.

Web sitesi yedeği nasıl alınmalı, hosting firmasının yedeği yeter mi?

Kısa cevap: 3-2-1 kuralıyla: en az üç kopya, iki farklı ortam ve bunlardan biri farklı bir konumda. Hosting firmasının otomatik yedeği bu düzenin yalnızca bir parçasıdır; tek başına yetmez.

Yalnızca hosting yedeğine güvenmek neden riskli?

• Aynı çatı altında: hesap askıya alınır, ödeme aksar ya da hizmet sona ererse siteyle birlikte yedeğe de erişilemeyebilir.
• Geriye dönük süre sınırlı: yedeklerin kaç gün geriye gittiği pakete göre değişir. Sitedeki zararlı bir kod haftalar sonra fark edilirse temiz yedek çoktan silinmiş olabilir.
• Kapsam eksik olabilir: WordPress gibi sistemlerde site, dosyalar ve veritabanı birlikte geri yüklenmeden ayağa kalkmaz. Paketin ikisini birden kapsadığından emin olun.
• Geri yüklemeyi kimin yapacağı belirsiz: kriz anında yedeğin nerede olduğunu ve nasıl yükleneceğini bilen kimse yoksa yedeğin varlığı tek başına işe yaramaz.

Doğru yedekleme düzeni

1. Neyin yedeklendiğini bilin: içerik yönetim sistemli sitede dosyalar ve veritabanı; statik sitede sitenin kaynak dosyaları ve görselleri. Site üzerinden toplanan form kayıtları varsa bunlar kişisel veridir ve yedekte de korunmalıdır.
2. Sıklığı değişim hızına göre belirleyin: düzenli blog yazısı eklenen bir site daha sık, yıllarca aynı kalan bir tanıtım sitesi daha seyrek yedeklenebilir.
3. Büyük güncellemeden önce elle yedek alın: WordPress'in kendi belgeleri de güncellemeye başlamadan önce yedek alınmasını öneriyor. Tema değişikliği, büyük eklenti güncellemesi ya da sunucu taşıması öncesinde bu adım atlanmamalı.
4. Bir kopyayı hosting dışına alın: bulut depolama ya da işletmenin kendi arşivi olabilir; önemli olan hosting hesabından bağımsız olması.
5. Geri yüklemeyi test edin: yedeği bir test ortamına kurup sitenin gerçekten açıldığını görmek, yedekleme düzeninin tek gerçek sınavıdır. Hiç geri yüklenmemiş bir yedek, yedekten çok bir umuttur.
6. Yedeklere erişim işletmede olsun: yedekler yalnızca ajansın ya da geliştiricinin hesabında durmamalı.

Bakımdan sonra neler test edilmeli, bakım ne zaman yetmez?

Kısa cevap: ziyaretçinin size ulaştığı her yol: form, telefon ve WhatsApp butonları, mobil görünüm, ölçüm kodları ve hız. Güncelleme ekranı "başarılı" dese bile bu yollardan biri bozulmuş olabilir; bu yüzden her bakımdan sonra siteyi bir ziyaretçi gözüyle dolaşmak gerekir.

• İletişim formu: deneme mesajı gönderin ve mesajın gerçekten gelen kutusuna düştüğünü görün. Formun ekranda "gönderildi" yazması, mesajın ulaştığı anlamına gelmez.
• Telefon ve WhatsApp butonları: telefondan tıklandığında doğru numarayı açtıklarını kontrol edin.
• Mobil görünüm: ana sayfayı, hizmet sayfalarını ve iletişim sayfasını telefonda açıp kayan, üst üste binen ya da kaybolan bölüm olup olmadığına bakın.
• Ölçüm ve dönüşüm takibi: güncellemeler ölçüm kodunu ya da form gönderim olayını bozabilir. Analytics'te ziyaretin ve form dönüşümünün hâlâ kaydedildiğini kontrol edin; kurulumun nasıl yapıldığını GA4 ve dönüşüm takibi rehberimizde anlattık.
• Sayfa hızı: yeni bir eklenti ya da büyük bir görsel siteyi fark ettirmeden yavaşlatabilir; neye bakılacağını web sitesi hızı ve Core Web Vitals rehberimizde anlattık.

Form neden sessizce çalışmayı bırakır?

Sahada en sık karşılaştığımız arızalardan biri bu: site açılıyor, form "mesajınız gönderildi" diyor ama mesaj kimseye ulaşmıyor ya da spam klasöründe kalıyor. İşletme bunu çoğu zaman haftalar sonra, "son zamanlarda formdan kimse yazmıyor" diye fark ediyor. Tipik nedenler şunlar: sunucunun e-posta gönderim ayarının değişmesi, formun bağlı olduğu e-posta hesabının şifresinin değişmesi ve alan adının e-posta doğrulama kayıtlarının eksik olması.

Bu doğrulama kayıtlarının adı SPF ve DKIM: bir e-postanın gerçekten o alan adı adına gönderildiğini alıcı sunucuya kanıtlayan DNS kayıtları. Google'ın gönderici yönergeleri, Gmail adreslerine e-posta gönderen herkesten en az SPF ya da DKIM kurmasını istiyor ve SPF, DKIM ile DMARC'ın birlikte kurulmasını öneriyor. Kayıtlar eksikse formdan gelen mesaj spam klasörüne düşebilir ya da hiç teslim edilmeyebilir.

Sahadan not: yayına aldığımız bir sitede bir görseli güncelleyip yeni hâlini eski dosyayla aynı adla yüklediğimizde, sunucuda yeni görsel dururken ziyaretçilere bir süre eskisi gösterilmeye devam etti. Nedeni, hosting firmasının içerik dağıtım ağıydı (CDN): aynı adı taşıyan dosyanın önbellekteki eski kopyasını sunmayı sürdürüyordu. O günden beri değişen her görsele yeni bir dosya adı veriyoruz, örneğin sonuna "-v2" ekleyerek; bu, önbelleğin temizlenmesini beklemekten çok daha güvenilir bir yöntem.

Bakım ne zaman yetmez?

Bakım, sağlam bir temeli çalışır ve güncel tutar; temelin kendisini değiştirmez. Telefonda dağılan bir tasarım, kimsenin güncelleyemediği bir altyapı ya da artık güncelleme almayan bir tema düzenli bakımla düzelmez.

Aynı sorunlar her ay yeniden çıkıyorsa, her güncelleme bir şeyi bozuyorsa ya da siteye yeni bir sayfa eklemek başlı başına bir projeye dönüşüyorsa, konu artık bakım değil yenilemedir. Bu işaretleri ve SEO'yu kaybetmeden geçiş planını web sitesi yenileme rehberimizde anlattık.