Web Sitesi Güvenliği ve Hosting Kontrol Listesi

Web sitesi güvenliği, hosting ayarlarından tarayıcıya giden başlıklara, hesap erişiminden yedeklere kadar birbirine bağlı küçük kontrollerden oluşur. Bunların hiçbiri tek başına siteyi korumaz, ama eksik biri diğerlerini boşa çıkarabilir. Blog, haber ya da e-ticaret sitesi işletiyorsanız ve hosting seçerken ya da mevcut hostinginizi denetlerken neye bakacağınızı bilmek istiyorsanız, bu kontrol listesi savunma ve denetim sırasıyla ilerler. Saldırı yöntemlerinin ayrıntısı bu konunun dışındadır; amaç sitenizin açıklarını kapatmak, ziyaretçiyi ve arama botlarını kesintisiz karşılamaktır.

Güvenlik ve arama görünürlüğü neden aynı konu

Güvenlik zayıflığı doğrudan görünürlük sorununa dönüşebilir. Sunucu yanıt vermediğinde Googlebot sayfaya ulaşamaz. Google'ın HTTP durum kodları, ağ ve DNS hataları belgesi (yeni sekmede açılır), 5xx ve 429 sunucu hatalarının Google tarayıcılarının taramayı geçici olarak yavaşlatmasına yol açtığını söyler. 500, 502 ve 503 için yavaşlamanın, hata veren tekil URL sayısıyla ölçeklendiği yazılıdır. Sunucu yeniden 2xx dönmeye başlayınca Google tarama hızını kademeli artırır. Belgeye göre 500, 502 ve 503 döndürmeyi sürdüren URL'ler dizinleme hattı tarafından kaldırılır; zaten dizinde olanlar bir süre saklanır, hatalar sürerse sonunda düşürülür. 5xx yanıtlarıyla alınan içerik yok sayılır.

Bu yüzden bir güvenlik önlemi yanlış yapılandırıldığında da zarar verebilir. Aşırı sıkı bir güvenlik duvarı kuralı Googlebot'u engeller, aşırı yüklü bir sunucu 5xx döndürür, çalışmayan bir sertifika ziyaretçiyi uyarıyla karşılar. Belge ayrıca 401 ve 403 gibi 4xx kodlarının (429 hariç) tarama hızını etkilemediğini, bu yüzden tarama hızını sınırlamak için kullanılmaması gerektiğini söyler. Güvenlik ve SEO ayrı iki ekibin işi gibi görünür; oysa ikisinin ortak ölçüsü kullanılabilirliktir.

Konunun dışında kalanlar

Saldırıya uğramış bir sitenin temizlenmesi ayrı bir iştir; adımlar için hacklenmiş site ve spam link temizliği yazısına bakın. Penetrasyon testi, uyumluluk denetimi ve hukuki yükümlülükler de bu konunun dışındadır.

Neyi korumak istiyorsunuz: risk önceliği

Tehdit modellemesi büyük bir kurum işi gibi görünür, ama küçük bir yayıncı için bir tabloyla başlar. Sitenizde değer taşıyan şeyleri yazın, her birinin kaybolması ya da yetkisiz kişiye geçmesi halinde ne olacağını belirleyin.

Tabloyu doldurmak yarım saat sürer ve sonraki bütün kararların sırasını belirler. Satış yapmayan bir blogda içerik arşivi ve alan adı en üstte olur, e-ticarette müşteri verisi ve erişilebilirlik öne çıkar.

Savunmayı katmanlara ayırmak

MDN'nin web güvenliği sayfası (yeni sekmede açılır) konuyu dört bölüme ayırır: saldırılar, savunmalar, tehdit modelleme ve kimlik doğrulama. Sayfa tehdit modellemeyi, bir sitenin hangi tehditlerle karşılaştığını ve hangi savunmalara ihtiyaç duyduğunu belirlemek için yapılandırılmış bir süreç olarak tarif eder. Bir yayıncı için pratik karşılığı şudur: önce neyi korumak istediğinizi yazın, sonra katmanları sırayla gözden geçirin.

Hosting seçerken ve denetlerken sorulacak sorular

Marka önermek yerine her sağlayıcıya sorulabilecek soruları yazılı yanıtlatmak daha sağlam bir yöntemdir. Bu soru tablosunu bir hosting firmasıyla görüşürken ya da mevcut sözleşmenizi denetlerken kullanın.

Karar kuralı: yanıtı alamadığınız her soru bir risk satırıdır. Bu satırları risk kaydınıza yazın ve cevaplanmamış üç satırdan fazlası varsa sağlayıcıyı yeniden değerlendirin.

Hosting türüne göre sorumluluk paylaşımı

Bu tablo ayrımı anlatmak içindir, sağlayıcıların hizmeti değişir. Önemli olan sorumluluğun kimde olduğunu sözleşmede ve destek yazışmasında yazılı hale getirmektir. “Sunucu güvenliği hosting firmasının işidir” varsayımı, yedek ve uygulama güncellemesi gibi sizde kalan işleri görünmez kılar.

Destek yazışmasında yazılı hale getirilecekler

Sözlü yanıt kesintide kanıt sayılmaz. Hosting firmasından şu bilgileri e-postayla ya da destek kaydıyla alın.

• Yedeğin hangi aralıkla alındığı ve en eski saklanan yedeğin tarihi.
• Geri yükleme isteğinin hangi kanaldan, kim tarafından ve hangi süre beklentisiyle iletileceği.
• Kaynak limiti aşıldığında sitenin kapanıp kapanmayacağı ya da yavaşlayıp yavaşlamayacağı.
• Sertifikayı kimin yenilediği ve yenileme başarısız olursa kimin haberdar edileceği.
• Planlı bakımın önceden duyurulup duyurulmadığı.

Karar kuralı: yazılı yanıt vermeyen bir madde için kendi önleminizi kurun. Örneğin yedek sıklığı belirsizse siz sunucu dışına ayrıca yedek alın. Uygulama önerisi: bu yanıtları risk kaydınızın yanına tarihiyle saklayın, çünkü sağlayıcı değiştirirken ya da bir anlaşmazlıkta ilk başvuracağınız belge bu olur.

Sunucu ve sertifika temelleri

MDN, tüm sayfalar ve alt kaynaklar için HTTPS kullanılmasını temel uygulamalar arasında sayar. Sertifika ve HTTPS taşıma ayrıntıları ayrı konulardır: süre dolması için sertifika yenileme ve otomasyon, taşıma sonrası karma içerik ve HSTS için HTTPS sonrası karma içerik kontrolü.

Sunucu tarafında yazılım sürümleri, gereksiz servislerin kapatılması ve dosya izinleri gibi ayarlar hosting türüne göre değişir. Paylaşımlı hostingde bu ayarlar sağlayıcıdadır ve sizin göreviniz doğru soruları sormaktır; kendi sunucunuzu yönetiyorsanız sorumluluk size geçer. Hangi durumda olduğunuzu açıkça yazın: “sunucu güncellemesi kimde?” sorusunun yanıtı tek bir kişi ya da firma olmalı.

Yanıt süresi ve önbellek

Yavaş yanıt hem kullanıcı hem tarama için sorundur. Önbellek ve CDN ayarlarının SEO etkisi için TTFB, önbellek ve CDN yazısına bakın. Güvenlik açısından önemli olan nokta şudur: kişisel sayfaları, yönetim ekranlarını ve oturum gerektiren yanıtları herkese açık önbelleğe sokmayın.

Alan adı ve DNS kayıtları

Alan adı, sitenin ve e-postanın ortak kökenidir. Kayıt firması hesabı ele geçirilirse site yönlendirilebilir, e-posta okunabilir. Kayıt kilidi gibi korumaların sunulup sunulmadığını kayıt firmasına sorun, hesabı kişisel bir e-postaya değil ortak bir adrese bağlayın ve DNS kayıtlarını gözden geçirirken adı bilinmeyen kayıtları araştırın. DNS değişikliklerinin kim tarafından, hangi tarihte yapıldığını bir değişiklik defterine yazın.

Hesaplar, roller ve sırlar

MDN'nin kimlik doğrulama bölümü parola, tek kullanımlık parola, federe kimlik, passkey ve oturum yönetimini sayar. Sayfanın temel uygulamalar özetinde güçlü kimlik doğrulama için önce passkey, ardından zamana bağlı tek kullanımlık parola (TOTP) tercih edilir; yalnızca paroladan kaçınılması istenir. Operasyonel güvenlik başlığı kaynak kodunun korunmasını, sırların güvenli yönetimini ve bağımlılıkların yönetilmesini kapsar.

Ayrılan çalışan ve ajans erişimi

Eski çalışanların ve eski ajansın erişimleri en kolay unutulan açıklardan biridir. Bir sözleşme bittiğinde ya da bir kişi ayrıldığında erişim listesini aynı gün gözden geçirin. Bu işi bir kontrol listesi maddesi yapın, hafızaya bırakmayın.

Güncelleme, yedek ve geri yükleme

Uygulama önerisi: güncelleme, yedek ve geri yükleme birlikte düşünülür: güncelleme bir şeyi bozarsa geri yükleme çıkış yoludur.

• Uygulama ve eklenti güncellemelerini bir test ortamında deneyin, sonra canlıya alın.
• Yedeği sunucunun dışında ve ayrı bir hesapta saklayın.
• Her çeyrekte bir geri yüklemeyi gerçekten deneyin ve süreyi kaydedin.
• Güncellemeden önce son yedeğin tarihini yazın.
• Kullanılmayan eklentileri, temaları ve eski sürümleri kaldırın.

Yedek türleri ve saklama

Bu tablo bir çalışma önerisidir, bir standart değildir; sıklığı kaybetmeyi göze alabileceğiniz veri miktarına göre belirleyin. Yedeğin işe yaradığını yalnızca geri yükleme denemesi gösterir.

Güncelleme sırası

1. Güncellemeden önce son yedeğin tarihini ve geri yükleme yolunu kontrol edin.
2. Güncellemeyi test ortamında uygulayın ve ana sayfa, giriş, arama ve ödeme akışlarını elle açın.
3. Canlıda düşük trafikli bir saatte uygulayın.
4. Uygulamadan sonra günlüklerde yeni hata kümesi arayın.
5. Sorun varsa geri alın ve nedenini kaydedin.

Erişim envanteri kontrol listesi

Erişim listesi, kimin hangi sisteme girebildiğini tek yerde toplar. Altı satırı doldurun.

• Hosting paneli, alan adı kaydı, içerik yönetim paneli ve e-posta için ayrı satır açın.
• Her satırda kişi adı, rol ve son gözden geçirme tarihi yazsın.
• Ortak hesapları kişisel hesaplara ayırın.
• İki adımlı doğrulamanın her hesapta açık olduğunu işaretleyin.
• Ajans ve dış uzman erişimlerine bitiş tarihi koyun.
• Listeyi çeyrekte bir ve her ayrılışta güncelleyin.

Karar kuralı: bitiş tarihi olmayan bir dış erişim, sürekli erişim sayılır ve gerekçesi yazılmadan açık kalmaz.

WAF ve hız sınırı: koruma ile tarama dengesi

Web uygulaması güvenlik duvarı (WAF), gelen istekleri kurallara göre değerlendirir. Cloudflare'in WAF belgeleri (yeni sekmede açılır) özel kurallardan, yönetilen kural setlerinden ve hız sınırlama kurallarından söz eder. Özel kurallar, siteyi ve API'leri kötü amaçlı gelen trafikten korumak için kendi kurallarınızı yazmanızı sağlar. Yönetilen kurallar, önceden hazırlanmış ve düzenli güncellenen kural setleridir ve davranışları ayarlanabilir. Hız sınırlama kuralları, bir ifadeyle eşleşen gelen istekler için sınırlar tanımlamanıza ve sınır aşılınca uygulanacak eylemi seçmenize izin verir. Belge ayrıca Security Events ekranıyla engellenen isteklerin gözden geçirilebileceğini ve güvenlik yapılandırmasının örneklenmiş günlüklere göre ayarlanabileceğini yazar.

Bu, bir sağlayıcının belgesidir; başka bir sağlayıcıda adlar ve eylemler farklı olabilir. Belge ilgili sayfada kural eylemlerinin ve önce günlüğe alma yaklaşımının ayrıntılarını verir.

Koruma ile tarama arasındaki denge

Uygulama önerisi: yeni bir WAF kuralını önce yalnızca izleyerek (etkisini günlükte görerek) başlatın, sonra uygulayın. Kuralın engellediği isteklerde Googlebot da olabilir. Googlebot'un doğrulanması için Googlebot erişimini doğrulama yazısına bakın; kötü bot trafiğinin nasıl yönetileceği kötü bot trafiği yönetimi yazısındadır.

Tarayıcı tarafı güvenlik: HTTPS, CSP, çerezler ve SRI

MDN temel uygulamalar olarak şunları sayar: tüm sayfa ve alt kaynaklarda HTTPS, mümkünse sıkı bir içerik güvenliği politikası (CSP) veya en azından satır içi JavaScript'i yasaklayan bir CSP, clickjacking koruması için frame-ancestors, çerezlerde SameSite, Secure ve HttpOnly ile kısa oturum süreleri, girdi doğrulama ve ardından çıktı kodlama ya da temizleme, CDN gibi dış kaynaklardan yüklenen betikler için Subresource Integrity (SRI). Sayfa, ayrıca sitenizin iyi güvenlik uygulamalarını taradığını söylediği HTTP Observatory aracını anar.

Başlıkların ayrıntısı, hangi başlığın neyi yaptığı ve yayına nasıl alınacağı için HTTP güvenlik başlıkları, CSP ve Referrer-Policy yazısına bakın. İki uyarıyı unutmayın. İlki, CSP'yi önce yalnızca raporlama modunda deneyin; aksi halde siteyi görünmez biçimde bozabilirsiniz. İkincisi, başlık eklemek sunucu yanıtını değiştirir; değişiklikten sonra ana sayfa, ödeme ve giriş sayfalarını elle açıp kontrol edin.

Başlıkları devreye alma sırası

1. HTTPS ve yönlendirmeyi doğrulayın.
2. Çerez niteliklerini kontrol edin.
3. Düşük riskli başlıkları ekleyin ve sayfaları açıp bakın.
4. CSP'yi raporlama kipinde başlatın, raporları okuyun ve politikayı daraltın.
5. Değişiklik defterine başlığı, tarihi ve geri alma yolunu yazın.

Girdi doğrulama, çıktı kodlama ve oturumlar

MDN girdi güvenliği için önce doğrulama, ardından çıktının kodlanması ya da temizlenmesi sırasını verir. Formlarınız, arama kutunuz ve yorum alanlarınız bu sıranın uygulanacağı yerlerdir. Hazır bir içerik yönetim sistemi kullanıyorsanız bu işin büyük kısmı yazılımın sorumluluğundadır; sizin göreviniz yazılımı ve eklentileri güncel tutmak ve eklenti seçerken bakımının sürdüğünü kontrol etmektir. Özel kod yazdırdıysanız geliştiriciden hangi alanlarda doğrulama ve kodlama yapıldığını yazılı isteyin.

Oturum çerezlerinde SameSite, Secure ve HttpOnly nitelikleri ile kısa yaşam süreleri MDN'nin önerdiği uygulamalardır. Bunları kontrol etmek için tarayıcı geliştirici araçlarında çerez listesine bakmanız yeterlidir; nitelikler eksikse yazılım veya hosting ayarından açıp açılamayacağını sorun.

Üçüncü taraf kod ve bağımlılıklar

MDN tedarik zinciri saldırılarını ve harici betikler için SRI kullanımını ayrı ayrı anar. Sitenize eklediğiniz her ölçüm, reklam, sohbet ya da yorum betiği, sizin kontrolünüzde olmayan bir kodu sitenizin içinde çalıştırır. Bunların performans etkisi ayrı bir ölçüm konusudur (üçüncü taraf scriptlerin performans denetimi); güvenlik tarafında kural basittir: her betiğin sahibi, amacı ve kaldırılma ölçütü bir listede dursun.

İzleme ve kesinti planı

Bir sorunu fark etmenin en kötü yolu ziyaretçi şikayetidir. Dışarıdan çalışan bir erişilebilirlik izleyicisi kurun: ana sayfa, giriş sayfası, ödeme sayfası ve bir ürün sayfası için durum kodunu ve yanıt süresini kontrol etsin. Search Console'daki tarama istatistikleri, sunucu durumu bölümüyle robots.txt, DNS ve bağlantı sorunlarını son 90 güne ait bir ek kayıt olarak sunar.

Planlı bakım gerektiğinde sunucunun 503 yanıtı ve yeniden deneme bilgisi vermesi doğru yoldur; ayrıntı hosting kesintisinde 5xx hataları ve tarama etkisi yazısındadır.

Neyi izleyin

Olay planı: kim neyi ne zaman yapar

Plan, bir kişinin yokluğunda da işlemelidir. Her aşama için bir yedek sorumlu yazın ve iletişim bilgilerini hosting paneline erişemeseniz bile ulaşabileceğiniz bir yerde tutun.

Örnek senaryo: oyuncakçı e-ticaret sitesi

Örnek senaryo: küçük bir oyuncakçı, çevrimiçi mağazasını paylaşımlı hostingde işletiyor. Bayram öncesi kampanyada trafik arttı ve sunucu aralıklı 5xx dönmeye başladı. Aynı hafta ajansla yapılan sözleşme bittiği halde eski ajansın yönetim hesabı açık kalmıştı. Kontrol listesine göre ilk iş, sunucu durumuna ve günlüklere bakmaktı: 5xx kampanya sayfasında yoğunlaşıyordu. Kaynak limiti aşımı konuşuldu, önbellek ve hosting planı gözden geçirildi. İkinci iş erişim listesiydi: eski ajansın hesabı kapatıldı, tüm yönetici hesaplarında iki adımlı doğrulama açıldı.

Üçüncü iş WAF kurallarıydı. Kampanya için eklenen sıkı bir hız sınırı, gerçek müşterileri sepet adımında engelliyordu. Kural izleme moduna alındı, günlükteki etkisi incelendikten sonra sınır gevşetildi. Bu üç iş birbirinden bağımsız görünse de ortak sebebi yoktu; ortak çözümü bir kontrol listesiydi. Kampanya bittikten sonra oyuncakçı olay planını yazdı: kampanya haftasında kimin hangi uyarıyı alacağı, hosting ile iletişimin hangi kanaldan yapılacağı, WAF kurallarını kimin değiştirebileceği ve her değişikliğin nereye not edileceği. Sonraki kampanyada aynı üç sorun yaşanmadı çünkü her biri için bir sahip ve bir kontrol vardı. Plan bir kez yazıldı, her kampanyadan önce yeniden okundu.

Örnekten çıkan karar tablosu

Yanlış anlaşılan nokta: “güvenlik eklentisini kurduk, iş bitti”. Eklenti yeni bir kural katmanı ekler ve bu katman tarama ya da müşteri erişimini engelleyebilir. Uygulama önerisi: eklentiyi açtıktan sonra ilk hafta tarama yanıtlarını ve engellenen istekleri her gün okuyun, sonra haftalığa geçin.

Üç aylık denetim takvimi

DNS kayıtlarını gözden geçirirken kullanılmayan alt alan adı kayıtlarını silmek ayrı bir iştir; sahipsiz kalan kayıtların neden önemli olduğunu askıda kalan DNS kaydı ve alt alan adı ele geçirme konusu açıklar.

Kontrol listesi: on beş madde

• Sertifika yenileme otomatik ve izleniyor.
• Tüm sayfalar ve alt kaynaklar HTTPS ile sunuluyor.
• Yedek sunucu dışında saklanıyor ve geri yükleme denendi.
• Yönetim hesaplarında iki adımlı doğrulama açık.
• Eski çalışan ve ajans erişimleri kapatıldı.
• Uygulama, eklenti ve sunucu sürümleri güncelleme sorumlusuyla yazılı.
• WAF ve hız sınırı kuralları günlük verisiyle ayarlandı ve gözden geçiriliyor.
• Googlebot erişimi güvenlik kurallarından sonra doğrulandı.
• CSP ve diğer başlıklar önce izleme modunda denendi.
• Çerezlerde SameSite, Secure ve HttpOnly kullanılıyor.
• Harici betikler listelendi, SRI mümkün olan yerde kullanıldı.
• Dışarıdan erişilebilirlik izleme açık.
• Bakım sırasında 503 ve yeniden deneme bilgisi veriliyor.
• Olay planı rol ve yedek sorumluyla yazılı.
• Kullanılmayan alt alan adı kayıtları temizlendi.

Maddeleri sahiplerine dağıtmak

Liste yalnız kontrol edilmekle kalmaz, sahiplenilmelidir. Her madde için bir rol adı, bir sonraki kontrol tarihi ve kanıtın nerede durduğu yazılmadığında liste ilk olayda işe yaramaz. Küçük bir ekipte bir kişi birden çok rol taşıyabilir; yine de rolün adı yazılı olmalıdır, çünkü kişi tatildeyken ya da ayrıldığında sorumluluk boşta kalmamalıdır.

Uygulama önerisi: listeyi üç sütunlu bir tabloya çevirin: madde, sorumlu rol, kanıt. Kanıt bir ekran görüntüsü ya da yapılandırma sayfasının adı olabilir; kanıt dosyasına yetkisiz kişilerin erişemediğinden emin olun, çünkü kanıt dosyası kendisi bir güvenlik riski olabilir. Parola, API anahtarı ya da kurtarma kodu kanıt olarak kaydedilmez; yalnız “var ve yetkili kişi biliyor” bilgisi yazılır.

Sorumluluk dağıtırken iki kuralı koruyun. Birincisi, aynı kişi hem kuralı ekleyip hem onaylamasın; küçük sitelerde bu mümkün değilse en azından değişiklik defterine yazılan kayıt ikinci bir kişiye gösterilsin. İkincisi, bir maddeyi devreden çıkarmak yazılı karar gerektirsin: neden gereksiz, kim onayladı, ne zaman yeniden bakılacak. Sessizce atlanan madde bir sonraki denetimde fark edilmeyen açığa dönüşür.

Son olarak listenin kendisini de eskitmeyin. Sitenize yeni bir ödeme sağlayıcısı, yeni bir ajans ya da yeni bir eklenti girdiğinde listeye karşılık gelen madde eklenmelidir. Her çeyrek denetiminde listede olmayan ama sitede çalışan bir bileşen aramak, listede olup sitede artık bulunmayan maddeyi silmek kadar önemlidir.

Önceliklendirmeyi bir takvime bağlayın: ilk iki grup bu ay, sonraki iki grup bir sonraki çeyrekte kapansın. Bitmeyen madde için tarih değil gerekçe yazılsın; böylece liste ilerlemeyi gösteren bir belgeye dönüşür, suçlama aracına değil.

Eksik maddeleri sıralamak

Bu sıra bir uygulama önerisidir. Sitenizin tehdit tablosu farklı çıkarsa sırayı ona göre değiştirin ve gerekçesini yazın.

Karar kuralı: bu maddelerden beşten fazlası eksikse önce hesap erişimi, yedek ve sertifika maddelerini kapatın; çünkü bu üçü kesinti ve veri kaybının en doğrudan nedenleridir.

Sık Sorulan Sorular

Güvenlik ayarları SEO'yu etkiler mi?

Dolaylı olarak evet. Google belgesi 5xx ve 429 hatalarının taramayı geçici yavaşlattığını, kalıcı 500, 502 ve 503 yanıtlarının URL'lerin dizinden düşmesine yol açabileceğini yazar. Yanlış kurulmuş bir güvenlik duvarı kuralı bu sonuca götürebilir.

WAF nedir ve küçük bir site için gerekli mi?

WAF gelen istekleri kurallara göre değerlendirir. Cloudflare belgeleri özel kurallar, yönetilen kural setleri ve hız sınırlama kurallarını tarif eder. Gerekliliği sitenizin riskine ve hosting sağlayıcınızın sunduklarına bağlıdır.

Hız sınırı koymak Googlebot'u engeller mi?

Yanlış ayarlanırsa engelleyebilir. Kuralı önce izleme modunda deneyin ve Googlebot isteklerinin etkilenmediğini günlükte doğrulayın.

Hangi güvenlik başlıklarını eklemeliyim?

MDN, CSP, çerez nitelikleri ve harici betikler için SRI gibi uygulamaları sayar. Başlıkları önce izleme modunda deneyip ana sayfa, giriş ve ödeme akışlarını elle kontrol edin.

Hosting sağlayıcısı seçerken neye bakmalıyım?

Yedeğin yeri ve geri yükleme denemesi, sertifika yönetimi, güncelleme sorumluluğu, kaynak limiti aşım davranışı, panel erişim güvenliği, günlük saklama süresi ve destek yanıt süresine bakın.

Saldırıya uğradıysam bu listeyle düzelir mi?

Hayır. Bu liste önleyici denetimdir. Saldırıya uğramış bir sitenin temizliği için ayrı bir süreç gerekir.

Sonuç

Güvenlik, hosting ve arama görünürlüğü ortak bir hedefte buluşur: siteniz ziyaretçiye ve arama botuna doğru, hızlı ve kesintisiz yanıt versin. Kontrol listesini katmanlara göre yürütün, önce hesap erişimi, yedek ve sertifika gibi en doğrudan risklerini kapatın, ardından WAF, başlıklar ve üçüncü taraf kod gibi katmanları ekleyin. Her yeni kuralı izleme modunda deneyin ve değişikliklerden sonra Googlebot erişimini doğrulayın.

Altyapısı sağlam bir sitenin otoritesini destekleyecek bağlantı kazanımı için backlink paketlerimize göz atabilirsiniz.