Web Sitesi Güvenliği: SSL'den Yedeklemeye Pratik Rehber

Web sitesi güvenliği, sitenizi, ziyaretçi verilerini ve alan adınızın itibarını yetkisiz erişime, zararlı koda ve veri kaybına karşı koruyan önlemlerin bütünüdür. Kurumsal bir site için sağlam başlangıç beş katmandan oluşur: otomatik yenilenen SSL, düzenli güncelleme, 3-2-1 kuralına uygun yedekleme, MFA ile giriş güvenliği ve sürekli izleme.

2026 sonbaharı bu konuyu takvime bağlı bir işe dönüştürüyor. 15 Mart 2026'dan beri yeni SSL sertifikaları en fazla 200 gün geçerli; bu kuralla alınan ilk sertifikaların süresi Eylül sonu ile Ekim başında doluyor. Google da Chrome 154 ile Ekim 2026'dan itibaren HTTPS desteklemeyen herkese açık sitelere girmeden önce kullanıcıya uyarı göstereceğini duyurdu.

Saldırganlar da hızlandı. WordPress güvenlik şirketi Patchstack'in 2026 raporuna göre 2025'te WordPress ekosisteminde 11.334 yeni açık bulundu; bu, bir önceki yıla göre %42 artış demek. Yoğun istismar edilen açıklarda toplu saldırının başlamasına kadar geçen medyan süre yalnızca 5 saat. Verizon'un 2026 Veri İhlali Araştırmaları Raporu da ihlallerin %31'inin bir yazılım açığının istismarıyla başladığını ve bu yolun 19 yılda ilk kez çalıntı şifreleri geçtiğini gösteriyor.

Bu rehberi teknik ekibi olmayan kurumsal site sahipleri için hazırladık. Kodlama bilgisi gerektirmeyen, ama web sitesi güvenliği için neyi kimden isteyeceğinizi netleştiren bir çerçeve sunuyor. Mobil uygulamanız varsa veri güvenliği ve KVKK tarafını mobil uygulama güvenliği rehberimizde ayrıca ele aldık.

Bu rehberde neler var?

• Web sitesi güvenliği neden bir işletme konusu?
• Yaygın saldırı türleri: sade dille
• SSL sertifikası: 2026'da değişen kurallar
• Güncelleme disiplini: açıkların girdiği kapı
• Yedekleme stratejisi: 3-2-1 kuralı
• Giriş güvenliği: şifre, MFA ve yetkiler
• Güvenlik başlıkları, WAF ve izleme
• Siteniz hacklendiyse: ilk 72 saat
• Güvenlik bakımını kim üstlenmeli?
• Site sahibi için güvenlik kontrol listesi
• Sıkça Sorulan Sorular

Web sitesi güvenliği neden bir işletme konusu?

Bir siteye yapılan saldırı çoğu zaman "site çöktü" gibi görünür bir sonuç doğurmaz. Saldırgan siteyi kapatmak yerine sessizce kullanmayı tercih eder: sayfalara spam bağlantı ekler, mobil ziyaretçileri başka sitelere yönlendirir ya da sunucunuzda oltalama (phishing) sayfası barındırır. Siz fark etmeden önce bunu Google, müşterileriniz ve resmi kurumlar fark edebilir.

Zayıf web sitesi güvenliğinin işletmeye yansıyan üç somut sonucu var:

• Arama görünürlüğü: Google, hacklenmiş veya zararlı içerik barındıran sayfaları Search Console Güvenlik sorunları raporunda işaretler. Bu sayfalar arama sonuçlarında uyarı etiketiyle ya da tarayıcıda tam sayfa uyarıyla görünebilir. Temizlikten sonra istediğiniz inceleme ise Google'ın ifadesiyle birkaç gün veya birkaç hafta sürebilir.
• Erişim engeli: Türkiye'de Ulusal Siber Olaylara Müdahale Merkezi USOM, zararlı yazılım yayan veya oltalama yapan adresleri zararlı bağlantılar listesinde yayımlar. Pek çok kurum bu listeyi güvenlik duvarında engelleme listesi olarak kullanır; oltalama sayfası barındıran bir kurumsal site, müşterisinin ofis ağından açılmayabilir.
• Yasal yükümlülük: İletişim formunuzdan topladığınız ad, telefon ve e-posta da kişisel veridir. Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararı, veri sorumlusunun ihlali öğrendiği andan itibaren en geç 72 saat içinde Kurul'a bildirimde bulunmasını öngörür.

Türkiye ayrıca hedef tahtasında üst sıralarda. Cloudflare'in 2026 ilk yarı DDoS raporuna göre Türkiye, Ankara'daki NATO Zirvesi öncesindeki dönemde, 2026'nın ikinci çeyreğinde en çok DDoS saldırısı alan 3. ülke oldu.

Yaygın saldırı türleri: sade dille

Saldırıların büyük bölümü hedef seçmez. Otomatik botlar interneti tarar; bilinen bir açığı olan eklentiyi veya zayıf şifreli yönetici panelini bulduğu her siteyi dener. "Benim sitem küçük, kimse uğraşmaz" düşüncesi bu yüzden geçerli değil: bot sitenin büyüklüğüne değil, açığına bakar.

Tedarik zinciri riskine bilinen bir örnek var. Eski tarayıcılar için kullanılan polyfill.io servisinin alan adı Şubat 2024'te el değiştirdi. Cloudflare'in aktardığına göre Haziran 2024'te bu servis, sitelere ziyaretçileri belirli koşullarda başka sitelere yönlendiren zararlı JavaScript enjekte etmeye başladı. Bu scripti yükleyen site sahipleri, kendi sunucularında hiçbir değişiklik olmadan etkilendi.

SQL injection ve XSS gibi uygulama katmanı açıkları özel yazılımlarda ayrı bir başlık. Bu rehber, site sahibinin kendisinin takip edebileceği katmanlara odaklanıyor; uygulama tarafında temel referans OWASP Top 10 listesidir.

SSL sertifikası: 2026'da değişen kurallar

SSL (teknik adıyla TLS) sertifikası, tarayıcı ile siteniz arasındaki trafiği şifreler ve ziyaretçinin doğru siteye bağlandığını doğrular. Adres çubuğundaki "https" bunun işaretidir. 2026, bu alanda iki büyük değişikliği aynı yıla topladı.

HTTPS artık varsayılan beklenti

Google'ın HTTPS by default duyurusuna göre Chrome, Nisan 2026'da Chrome 147 ile Gelişmiş Güvenli Tarama kullanıcılarında "Her zaman güvenli bağlantı kullan" ayarını devreye aldı. Ekim 2026'da Chrome 154 ile bu ayar tüm kullanıcılar için varsayılan hale geliyor. HTTPS sunmayan herkese açık bir siteye girmek isteyen kullanıcı, önce geçilebilir bir uyarı ekranı görecek.

Aynı duyuruya göre herkese açık sitelerde HTTPS kullanımı platforma göre yaklaşık %97 ile %99 arasında. Siteniz hâlâ HTTP ile açılıyorsa küçük bir azınlıktasınız ve ziyaretçinin ilk gördüğü şey bir uyarı olacak. HTTP'den HTTPS'e geçişin teknik adımlarını HTTP'yi HTTPS'e yönlendirme yazımızda, arama sıralamasına etkisini HTTPS ve SEO ilişkisi yazımızda anlattık.

Sertifika süreleri kısalıyor: 200, 100, 47 gün

Tarayıcı üreticileri ve sertifika otoritelerinin ortak kurulu CA/Browser Forum, SC-081v3 kararıyla sertifika ömrünü üç adımda kısaltıyor:

Ücretsiz sertifika sağlayıcısı Let's Encrypt bu takvimin de önüne geçiyor. Kuruluşun planına göre varsayılan sertifika süresi 10 Şubat 2027'de 90 günden 64 güne, 16 Şubat 2028'de 45 güne iniyor.

Site sahibi için pratik sonuç şu: sertifikayı elle yenilemek artık sürdürülebilir değil. Hosting panelinizde otomatik yenilemenin (ACME protokolü) açık olduğunu doğrulayın ve bitiş tarihine 14 gün kala uyarı veren bir izleme kurun. Yıllık ücretli bir sertifika paketi kullanıyorsanız, paket bir yıllık olsa da sertifikanın yıl içinde en az bir kez yeniden düzenlenmesi gerekir; bunun otomatik yapılıp yapılmadığını sağlayıcınıza sorun.

Kilit simgesi "güvenli site" demek değil

SSL yalnızca veriyi yolda korur. Hacklenmiş bir site de geçerli bir sertifikayla kilit simgesi gösterebilir; oltalama sayfalarının çoğu da HTTPS kullanır. Sertifika tek başına sunucudaki açığı, zayıf şifreyi veya eksik yedeği çözmez.

SSL kurulumunda sık atlanan üç nokta:

• Karışık içerik: HTTPS sayfada HTTP ile yüklenen görsel veya script, tarayıcı uyarısına ya da içeriğin engellenmesine yol açar.
• Tüm adreslerin yönlendirilmesi: "www" ve "www'suz", HTTP ve HTTPS sürümlerinin hepsi tek bir HTTPS adrese 301 ile gitmeli.
• HSTS başlığı: Tarayıcıya sitenizi yalnızca HTTPS ile açmasını söyler ve yönlendirmeden önceki kısa HTTP anını da kapatır.

Sertifika türü seçiminde çoğu kurumsal site için alan adı doğrulamalı (DV) ücretsiz sertifika yeterlidir. OV ve EV sertifikalar şifrelemeyi güçlendirmez; yalnızca kurum doğrulaması ekler.

Güncelleme disiplini: açıkların girdiği kapı

W3Techs verisine göre WordPress, Eylül 2026 itibarıyla tüm web sitelerinin %40,2'sinde çalışıyor. Bu yaygınlık WordPress'i saldırganlar için en verimli hedef yapıyor; ama web sitesi güvenliği açısından sorunun kaynağı çoğunlukla çekirdek yazılım değil.

Patchstack'in 2025 verisinde yeni açıkların %91'i eklentilerde, %9'u temalarda çıktı; WordPress çekirdeğinde ise yalnızca 6 açık raporlandı. Açıkların %46'sı kamuya duyurulduğu anda henüz yamasızdı. Aynı rapor, standart hosting savunmalarının test edilen saldırıların yalnızca %26'sını engellediğini gösteriyor. Hosting firmanızın güvenlik duvarı faydalı bir katman; ama güncellemenin yerini tutmuyor.

Sunucu tarafını da unutmayın. PHP'nin resmi destek takvimine göre PHP 8.1 ve öncesi artık güvenlik yaması almıyor; PHP 8.2'nin güvenlik desteği 31 Aralık 2026'da bitiyor. Siteniz PHP 8.2 veya daha eski bir sürümde çalışıyorsa yıl sonundan önce yükseltmeyi planlayın.

Pratik güncelleme takvimi

Güncellemeyi ertelemenin en sık bahanesi "siteyi bozar" korkusudur. Çözüm güncellemeyi ertelemek değil; güncellemeden önce yedek almak, değişikliği önce test ortamında denemek ve sorun çıkarsa dakikalar içinde geri dönebilmektir. Onlarca eklentiye bağımlı ve bakımı sürekli yük getiren bir sitede kalıcı çözüm arıyorsanız WordPress'ten özel kodlanmış siteye geçiş rehberimiz seçenekleri karşılaştırıyor.

Yedekleme stratejisi: 3-2-1 kuralı

Yedek, web sitesi güvenliğinde diğer tüm önlemler başarısız olduğunda elinizde kalan son sigortadır. ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı CISA, küçük işletmelere yönelik yedekleme rehberinde 3-2-1 kuralını önerir:

• 3 kopya: Biri canlı, ikisi yedek olmak üzere önemli verinin üç kopyası.
• 2 farklı ortam: Örneğin sunucu diski ve bulut depolama.
• 1 kopya dışarıda: En az bir kopya, sitenin çalıştığı altyapının dışında.

CISA ayrıca yedekleri şifrelemeyi, çevrimdışı bir kopya tutmayı ve geri yüklemeyi düzenli test etmeyi tavsiye eder; hedef, veriyi en az yedi gün geriye döndürebilmektir. Yedi gün önemli bir eşik, çünkü bir enfeksiyon çoğu zaman fark edilmeden günlerce sitede kalır ve son yedeğiniz de enfekte olabilir.

Hosting firmasının yedeği sizin yedeğiniz değil

Birçok hosting paketi otomatik yedek sunar ve bu iyi bir başlangıçtır. Ancak bu yedekler genellikle sitenizle aynı sağlayıcıda durur. Hesabınız askıya alınırsa, fatura sorunu yaşarsanız veya saldırgan panel erişimi elde ederse siteyi ve yedeği aynı anda kaybedebilirsiniz. Hosting yedeğini 3-2-1 kuralındaki kopyalardan biri olarak sayın; dışarıdaki kopya sizin kontrolünüzde olmalı.

Site tipine göre yedekleme planı

Bu tablo bir başlangıç çerçevesi; asıl ölçüt "bir günlük veri kaybını işletmem kaldırabilir mi?" sorusu. Sipariş alan bir e-ticaret sitesinde bir günlük sipariş kaybı, kurumsal bir sitedeki bir günlük içerik kaybından çok daha pahalıya patlar.

Yedeğe neyi dahil ettiğiniz de önemli: veritabanı, yüklenen dosyalar ve görseller, tema veya kod dosyaları, sunucu yapılandırması ve DNS kayıtlarının bir listesi. Şifre ve API anahtarı içeren yapılandırma dosyalarını şifreli saklayın. En kritik adım ise şu: üç ayda bir yedekten gerçekten geri yükleme yapın. Hiç denenmemiş bir yedeğin çalışıp çalışmadığını kriz anında öğrenmek istemezsiniz.

Giriş güvenliği: şifre, MFA ve yetkiler

Açık istismarı 2026'da birinci sıraya çıksa da çalınan veya tahmin edilen şifreler saldırganların hâlâ en rahat yolu. Yönetici paneline giren birinin açık aramasına gerek kalmaz.

Temel kurallar:

1. Her yönetim hesabında MFA açın. CISA'nın MFA rehberine göre en güçlü seçenek oltalamaya dayanıklı FIDO/WebAuthn yöntemleridir (donanım anahtarı, passkey); ancak herhangi bir MFA, hiç olmamasından iyidir. Mümkünse SMS yerine doğrulama uygulaması tercih edin.
2. Paylaşılan şifreyi kaldırın. Ajans, çalışan ve serbest geliştiricinin her birine ayrı hesap açın; ortak "admin" hesabı kullanmayın.
3. En az yetki ilkesini uygulayın. Blog yazarı yönetici olmamalı; içerik editörü eklenti yükleyememeli.
4. Ayrılan kişinin erişimini aynı gün kapatın. Eski çalışanlar ve iş birliği biten ajanslar, unutulmuş hesapların en yaygın sahibidir.
5. Giriş denemelerini sınırlayın. Belirli sayıda hatalı denemeden sonra geçici engelleme, kaba kuvvet saldırısını pratikte durdurur.
6. Şifre yöneticisi kullanın. Uzun ve benzersiz şifreleri ekibinizle güvenli biçimde paylaşmanın en pratik yolu budur.

Alan adı, DNS ve e-posta hesaplarını unutmayın

Web sitesi güvenliği yalnızca yönetim panelinden ibaret değil. Alan adını kaydettiğiniz firmadaki hesabı ele geçiren biri DNS kayıtlarını değiştirip sitenizi ve e-postanızı başka bir sunucuya yönlendirebilir. Bu hesaplarda da MFA'yı açın, alan adında transfer kilidini ve otomatik yenilemeyi etkinleştirin. Alan adının bağlı olduğu e-posta adresinin şirketinizin kontrolünde olduğundan emin olun; eski bir çalışanın kişisel e-postasına kayıtlı alan adı sessiz bir risktir.

Güvenlik başlıkları, WAF ve izleme

Önleme katmanlarını kurduktan sonra iki soru kalır: saldırı gelirse ne kadarını otomatik durdurabilirsiniz ve bir şey ters giderse ne kadar hızlı haberiniz olur?

Güvenlik başlıkları

HTTP güvenlik başlıkları, tarayıcıya sitenizi nasıl ele alacağını söyleyen kısa talimatlardır:

• Strict-Transport-Security (HSTS): Siteyi yalnızca HTTPS üzerinden açtırır.
• Content-Security-Policy (CSP): Sayfanın hangi kaynaklardan script ve içerik yükleyebileceğini sınırlar; enjekte edilen zararlı scriptin çalışmasını zorlaştırır.
• X-Frame-Options veya frame-ancestors: Sitenizin başka bir sayfada gizlice çerçeve içinde gösterilmesini engeller.

HSTS ve çerçeve başlıklarını kurmak hızlıdır; CSP ise sitenin kullandığı her kaynağı listelemeyi gerektirdiği için dikkatli test ister. Mevcut durumunuzu Mozilla'nın ücretsiz HTTP Observatory aracıyla birkaç saniyede görebilirsiniz.

WAF, CDN ve DDoS koruması

Web uygulaması güvenlik duvarı (WAF), bilinen saldırı kalıplarını sunucunuza ulaşmadan filtreler. CDN ile birlikte kullanıldığında DDoS trafiğini de karşılar. Burada otomasyon şart: Cloudflare'in raporunda ağ katmanı DDoS saldırılarının %90,60'ı 10 dakikadan kısa sürdü. Bu sürede bir insanın uyarıyı görüp müdahale etmesi pek mümkün değil.

İyi yapılandırılmış bir CDN çoğu zaman siteyi hızlandırır da. Hız ve altyapı katmanlarını birlikte nasıl kuracağınızı Core Web Vitals rehberimizde inceledik.

Sorunu müşteriden önce görün: izleme

Ücretsiz veya düşük maliyetli üç izleme katmanı çoğu kurumsal site için yeterlidir:

• Erişilebilirlik (uptime) izleme: Site kapandığında dakikalar içinde e-posta veya SMS uyarısı gönderir.
• Google Search Console: Sitenizi doğrulayın ve bildirim e-postalarını açın; Google bir güvenlik sorunu tespit ederse sizi buradan uyarır.
• Sertifika bitiş uyarısı: 200 günlük döngüde otomatik yenileme sessizce başarısız olabilir; bitişten en az 14 gün önce uyarı alın.

E-ticaret siteleri için bir katman daha var: ödeme sayfasındaki scriptler. Kart güvenliği standardı PCI DSS v4.0.1'in 6.4.3 ve 11.6.1 gereklilikleri, 31 Mart 2025'ten itibaren ödeme sayfası scriptlerinin envanterini ve yetkisiz değişikliklerin tespitini istiyor. Kart verisini tamamen yetkili bir ödeme kuruluşuna bırakan (SAQ A kapsamındaki) işletmeler bu iki gereklilikten muaf; ancak sitelerinin script saldırılarına açık olmadığını teyit etmeleri gerekiyor.

Siteniz hacklendiyse: ilk 72 saat

Hacklenmenin tipik belirtileri şunlardır:

• Google'da site:alanadiniz.com aramasında tanımadığınız, çoğu zaman yabancı dilde ürün veya ilaç başlıkları
• Yalnızca mobilde ya da yalnızca Google'dan gelen ziyaretçilerde başka siteye yönlendirme
• Tanımadığınız yönetici hesapları veya yakın zamanda değişmiş çekirdek dosyalar
• Search Console'dan güvenlik uyarısı, hosting firmasından spam veya kötüye kullanım bildirimi
• Açıklanamayan trafik düşüşü ya da sunucu kaynak kullanımında ani artış

Bu belirtilerden birini gördüğünüzde şu sırayı izleyin:

1. Sakin kalın ve kanıtı koruyun. Dosyaları hemen silmeyin; mevcut hâlin bir kopyasını alın. Saldırganın nereden girdiğini anlamak için bu kopyaya ihtiyacınız olacak.
2. Erişimi kesin. Siteyi bakım moduna alın; tüm yönetici, hosting, FTP ve veritabanı şifrelerini değiştirin, açık oturumları sonlandırın.
3. Kişisel veri etkilendi mi, değerlendirin. Form kayıtları, üye veya sipariş bilgileri sızdıysa KVKK kapsamındaki 72 saatlik bildirim süresi, ihlali öğrendiğiniz andan itibaren işler. Bu adımda bir hukuk danışmanıyla çalışmanızı öneririz.
4. Temiz yedekten geri dönün. Enfeksiyondan önceki son yedeği seçin; birkaç haftalık yedek geçmişi tam bu an için değerlidir.
5. Açığı kapatın. Geri yüklemeden sonra eklentileri, temayı, çekirdeği ve PHP sürümünü güncelleyin. Giriş kapısını kapatmadan geri yüklediğiniz site, aynı yoldan kısa sürede tekrar hacklenir.
6. Google'dan inceleme isteyin. Search Console Güvenlik sorunları raporunda yaptığınız düzeltmeleri açıklayarak inceleme talep edin. Temizlikten sonra sayfaların doğru HTTP durumu döndürdüğünü ve noindex ya da robots.txt ile oynanmadığını ücretsiz site analizi aracımızla hızlıca kontrol edebilirsiniz.
7. Engelleme listelerini takip edin. Alan adınız oltalama için kullanıldıysa USOM'un zararlı bağlantılar listesinde ve tarayıcı uyarılarında görünüp görünmediğini kontrol edin.

Bu süreç bir iş gününe sığmayabilir. Yine de ilk 72 saati planlı yöneten işletme, hem KVKK süresini hem de Google'daki görünürlük kaybını kontrol altında tutar.

Güvenlik bakımını kim üstlenmeli?

Web sitesi güvenliğinde en sık yaşanan sorun bilgi eksikliği değil, sorumluluk boşluğudur. Site sahibi hosting firmasının, hosting firması ajansın, ajans da site sahibinin ilgilendiğini düşünür. Aşağıdaki tablo tipik bir iş bölümünü gösteriyor:

Paylaşımlı hosting'de sunucu tarafını sağlayıcı yönetir; VPS veya bulut sunucuda ise işletim sistemi güncellemeleri de çoğunlukla sizin veya ajansınızın sorumluluğundadır. Sözleşmenizde "güvenlik" kelimesinin geçmesi yetmez; tablodaki her satır için sorumluyu yazılı olarak belirleyin.

Türkiye'de sık karşılaşılan bir tablo şöyle: bir sanayi firması kurumsal sitesini yıllar önce serbest çalışan bir geliştiriciye yaptırmış, geliştiriciyle iletişim kopmuş, yönetici şifresi yalnızca onda kalmış ve site eski bir PHP sürümünde çalışıyor. Bu durumda ilk iş yeni bir tasarım değil; erişimleri geri almak, yedek alıp açıkları kapatmak ve ardından siteyi güncel bir altyapıya taşımaktır. Sitenizin bu noktada olup olmadığını web sitesi yenileme sinyallerini anlattığımız yazıyla değerlendirebilirsiniz.

Site sahibi için güvenlik kontrol listesi

Aşağıdaki listeyi takviminize işleyin. Maddelerin çoğu teknik bilgi gerektirmez; gerektirenler için kimin sorumlu olduğunu bilmeniz yeterli.

Bir kerelik kurulum

• Tüm HTTP ve www varyasyonları tek bir HTTPS adrese 301 ile yönleniyor.
• SSL otomatik yenileme açık ve bitiş tarihi izleniyor.
• Yönetici, hosting, alan adı ve e-posta hesaplarında MFA açık.
• Ortak "admin" hesabı yok; herkesin kendi hesabı ve uygun yetkisi var.
• Alan adında transfer kilidi ve otomatik yenileme açık.
• Dış konumda, şifreli ve otomatik yedekleme çalışıyor.
• Search Console doğrulanmış, bildirimler açık.
• Uptime izleme ve en az HSTS güvenlik başlığı kurulu.

Düzenli rutin

• Haftalık: Eklenti, tema ve çekirdek güncellemeleri; yedeklerin başarıyla alındığının kontrolü.
• Aylık: Kullanılmayan eklenti ve hesapların temizliği; site: aramasıyla spam sayfa kontrolü.
• Üç ayda bir: Yedekten deneme geri yüklemesi, üçüncü parti script envanteri ve güvenlik başlıkları taraması.
• Yılda bir: PHP ve sunucu yazılımının destek tarihleri; hosting ve bakım sözleşmesindeki sorumluluk dağılımı.

Sıkça Sorulan Sorular

Ücretsiz SSL sertifikası yeterli mi?

Çoğu kurumsal site ve blog için evet. Let's Encrypt gibi ücretsiz, alan adı doğrulamalı (DV) sertifikalar, ücretli sertifikalarla aynı şifreleme gücünü sunar. Ücretli OV ve EV sertifikalar şifrelemeyi değil, kurum doğrulamasını ve destek hizmetini ekler.

Web sitesi ne sıklıkla yedeklenmeli?

Sıklığı, kaybetmeyi göze alabileceğiniz veri miktarı belirler. Nadiren güncellenen kurumsal bir sitede haftalık yedek yeterli olabilir; sipariş veya randevu alan sitelerde veritabanını saatlik ya da sürekli yedeklemek gerekir. Her durumda en az bir kopya hosting firmasının dışında durmalı ve en az yedi gün geriye dönebilmelisiniz.

Sitemin hacklendiğini nasıl anlarım?

En yaygın işaretler Google'da site:alanadiniz.com aramasında çıkan yabancı dilde spam sayfalar, yalnızca mobilde gerçekleşen yönlendirmeler, tanımadığınız yönetici hesapları ve Search Console'dan gelen güvenlik uyarılarıdır. Hosting firmanızdan gelen spam veya kötüye kullanım bildirimi de ciddi bir işarettir.

WordPress güvensiz mi?

WordPress çekirdeği düzenli güncellenen ve az açık çıkan bir yazılımdır. Patchstack'in 2025 verisine göre yeni açıkların %91'i eklentilerde, %9'u temalarda bulundu; çekirdekte yalnızca 6 açık raporlandı. Riski asıl belirleyen, kullandığınız eklenti sayısı ve güncelleme disiplininizdir.

Güvenlik eklentisi tek başına yeterli mi?

Hayır. Güvenlik eklentisi ve hosting güvenlik duvarı faydalı katmanlardır, ancak Patchstack'in testlerinde standart hosting savunmaları saldırıların yalnızca %26'sını engelledi. Güncelleme, MFA, dış konumda yedek ve izleme olmadan hiçbir eklenti siteyi tek başına korumaz.

SSL sertifikam neden daha sık yenileniyor?

CA/Browser Forum kararıyla 15 Mart 2026'dan itibaren düzenlenen sertifikalar en fazla 200 gün geçerli. Bu süre 15 Mart 2027'de 100 güne, 15 Mart 2029'da 47 güne iniyor. Otomatik yenileme kurulu değilse sertifikanın fark edilmeden sona ermesi ve ziyaretçilerin uyarı görmesi an meselesidir.

Hosting firması sitemin güvenliğinden sorumlu değil mi?

Hosting firması genellikle sunucu altyapısından ve ağ güvenliğinden sorumludur. Paylaşımlı hosting'de CMS, eklenti, kullanıcı hesabı ve içerik güvenliği ise çoğunlukla site sahibinin veya bakımı yapan ajansın sorumluluğundadır. Bu dağılımı sözleşmede yazılı olarak netleştirmek gerekir.

Web sitesi güvenliği SEO'yu etkiler mi?

Evet. Google hacklenmiş veya zararlı içerik barındıran sayfaları arama sonuçlarında uyarı etiketiyle gösterebilir ve temizlik sonrası inceleme günler ya da haftalar sürebilir. HTTPS kullanmayan siteler için de Chrome, Ekim 2026'dan itibaren kullanıcıya varsayılan olarak uyarı ekranı gösterecek.

Web sitesi güvenliği bir kerelik kurulum değil, takvime bağlı bir rutindir. SSL'i otomatiğe bağlamak, güncellemeleri haftalık işe dönüştürmek, 3-2-1 kuralıyla yedeklemek ve her hesapta MFA açmak, sitenizi otomatik botların aradığı kolay hedef olmaktan çıkarır.

Web tasarım ve web yazılım projelerimizde güvenliği yayından sonra eklenen bir katman olarak değil, altyapı kararlarının parçası olarak planlıyoruz. Mevcut sitenizin güvenlik durumunu birlikte gözden geçirmek için bizimle iletişime geçin.