Bu Site Güvenli Değil Uyarısı Nasıl Kaldırılır? 2026

bu site güvenli değil uyarısı nasıl kaldırılır: önce sorunun kaynağını ayırın

“Bu site güvenli değil” uyarısını kaldırmak için ilk iş, problemi ziyaretçi tarafı ile site sahibi tarafı diye ikiye ayırmaktır. URL doğrudan http:// ile açılıyorsa sorun çoğu zaman sertifikadan önce protokol seviyesindedir. URL https:// ile açılıyor ama tarayıcı yine uyarı veriyorsa bu kez sertifika, hostname, zincir, CDN ya da mixed content tarafına bakılır. MDN 2026 güncel rehberinde tüm sayfa ve alt kaynakların HTTPS üzerinden servis edilmesini temel kural olarak tanımlıyor.

Ziyaretçi tarafında yapılabilecekler sınırlıdır. Cihaz saatinin yanlış olması, kurumsal ağ üstünde trafiği kesen bir güvenlik yazılımı, bozuk DNS önbelleği veya eski tarayıcı sürümü geçici uyarı üretebilir. Ancak hata farklı cihazlarda ve farklı ağlarda da tekrarlanıyorsa kalıcı çözüm büyük olasılıkla site sahibinin elindedir. Özellikle ödeme, form veya giriş sayfasında bu uyarı görünüyorsa kullanıcı tarafında “devam et” demek yerine siteyi terk etmek daha güvenlidir.

• Sadece HTTP: Sertifika yok ya da HTTPS zorlaması kurulmamış olabilir.
• HTTPS var ama kırık kilit: En güçlü aday mixed content’tir.
• ERR_CERT_* hata kodları: Sertifika kapsamı, süre veya zincir sorunu düşünülmelidir.
• Sadece tek cihazda görünmesi: Saat, ağ, antivirüs veya önbellek kontrol edilir.

SSL sertifikası var ama site güvenli değil uyarısı neden sürer?

En yaygın yanlış varsayım şudur: “SSL sertifikası kurulduysa sorun bitmiştir.” Oysa tarayıcı, yalnız sertifikanın varlığına bakmaz; alan adı eşleşmesi, geçerlilik süresi, ara sertifika ve güven zinciri de doğrulanır. Mozilla Support 13 Mart 2026 güncellemesinde sertifika incelemesinde Subject Alt Name, issuer ve validity alanlarının birlikte kontrol edilmesini açıkça anlatıyor.

Burada en sık görülen teknik hata hostname/SAN uyumsuzluğudur. Örneğin sertifika yalnız example.com için üretilmiştir ama kullanıcı www.example.com sürümüne gider. Sonuç genelde ERR_CERT_COMMON_NAME_INVALID olur. Benzer biçimde CDN üstündeki edge sertifikası doğruyken origin sunucudaki sertifika eski kalmışsa, özellikle reverse proxy veya yanlış bypass kurgularında uyarı sadece bazı isteklerde tetiklenebilir. Bu yüzden CDN, load balancer ve origin katmanını tek parça düşünmek gerekir.

İkinci güçlü aday eksik ara sertifika veya bozuk zincirdir. Sertifika süresi dolmamış olsa bile tarayıcı zinciri tamamlayamazsa güven kırılır. Let’s Encrypt 23 Ocak 2025 güncellemesinde sertifikaların çoğu hosting sağlayıcı tarafından otomatik yönetilebildiğini vurguluyor; pratikte sorun sertifika edinmekten çok doğru dağıtım, yenileme ve sunucuya tam zinciri eksiksiz koyma aşamasında çıkıyor.

• ERR_CERT_COMMON_NAME_INVALID: www/non-www, alt alan adı veya CDN hostname eşleşmesini kontrol edin.
• ERR_CERT_AUTHORITY_INVALID: Yanlış CA, eksik chain veya yerel ağ müdahalesi ihtimali vardır.
• Süresi dolmuş sertifika: Otomatik yenileme çalışmıyor ya da sunucuda eski dosya servis ediliyordur.
• Doğru sertifika, yanlış sunucu: DNS veya CDN önbelleği eski endpoint’e gidiyor olabilir.

HTTP’den HTTPS’ye geçiş, 301 yönlendirme ve mixed content düzeltme adımları

Kalıcı çözüm için yalnız sertifika yüklemek yetmez; tüm URL mimarisi tek sürüme oturmalıdır. HTTP’den HTTPS’ye kalıcı 301 yönlendirme kurun, ardından www/non-www tercihini netleştirin ve kanonik URL’leri bu tercihle aynı hizaya getirin. MDN, kullanıcı HTTP ile gelse bile sunucunun 301 ile HTTPS sürüme yönlendirmesi gerektiğini; yine de ilk istekte downgrade riskini azaltmak için sonrasında HSTS kullanılması gerektiğini belirtir.

Mixed content tarafında asıl problem, sayfanın kendisi HTTPS açılırken içindeki script, font, görsel, iframe veya CSS çağrılarının hâlâ HTTP kalmasıdır. MDN Mixed Content sayfasına göre tarayıcılar bazı görsel istekleri otomatik yükseltebilir ama script, stylesheet, iframe ve font gibi blockable content türlerini engelleyebilir. Bu yüzden “ana sayfa açılıyor” demek sorunun çözüldüğü anlamına gelmez; kilit simgesi yine kaybolabilir.

WordPress tarafında klasik vaka, tema dosyalarında gömülü http:// asset yolları, eski medya URL’leri veya üçüncü taraf chat, analiz, canlı destek ve ödeme scriptleridir. E-ticaret temalarında font CDN’leri, ürün görselleri ve iframe tabanlı widget’lar sık sorun çıkarır. CDN kullanan projelerde de HTML HTTPS iken origin’den gelen bir CSS dosyası HTTP dönebilir. Bu nedenle tarayıcı Security paneli, Network filtresi ve sayfa kaynağı birlikte incelenmelidir.

• Tüm dahili asset URL’lerini HTTPS veya göreli yol yapısına taşıyın.
• 301 zinciri yerine tek atımlı yönlendirme kurgulayın.
• Kanonik, sitemap ve hreflang varsa HTTPS sürümle güncelleyin.
• Üçüncü taraf script sağlayıcılarının HTTPS desteğini ayrı doğrulayın.

HSTS ne zaman eklenir, preload ne zaman risklidir?

HSTS, tarayıcıya bu domainin her zaman HTTPS ile açılması gerektiğini söyler ve ilk düzeltmeler tamamlandıktan sonra önemli bir güven katmanı sağlar. MDN, HSTS’nin SSL stripping riskini ilk ziyaret hariç ciddi biçimde azalttığını vurgular. Yani HSTS, yönlendirme yerine geçen bir çözüm değil; temiz HTTPS kurgusunu güçlendiren bir katmandır.

Preload ise daha sert bir karardır. HSTS Preload List Submission gereksinimlerine göre preload için max-age en az 31536000 olmalı, includeSubDomains ve preload direktifleri bulunmalıdır. Aynı kaynak, kaldırma sürecinin kolay olmadığını ve yeni kayıtların kararlı Chrome sürümüne ulaşmasının aylar sürebileceğini de açıkça söyler. Bu yüzden bütün alt alan adlarınız HTTPS için hazır değilse preload erken verilmiş bir karar olur.

• Önce tüm alt alan adlarının HTTPS çalıştığını doğrulayın.
• HSTS değerini aşamalı artırın; bir anda preload’a atlamayın.
• İç sistem subdomain’leri dahil her hostu test edin.
• HTTPS üstünde ikinci bir redirect varsa HSTS header’ı orada da gönderin.

Aynı domaini 3 kontrolden geçirelim: Security paneli, TLS taraması, HSTS kontrolü

Pratikte en temiz yöntem, aynı domaini üç ayrı pencereden okumaktır. İlk pencere Chrome DevTools Security panelidir: burada sertifika geçerli mi, ana bağlantı güvenli mi, mixed content uyarısı var mı hızlıca görülür. İkinci pencere bir TLS taramasıdır: protokol sürümleri, chain, hostname ve ara sertifika sorunları daha net ayrışır. Üçüncü pencere ise HSTS kontrolüdür: header gerçekten geliyor mu, preload koşulları karşılanıyor mu bunu gösterir.

Teknik SEO denetimlerinde tekrar eden sıra şudur: Security paneli kırık kilit gösterir, TLS taraması sertifikanın aslında geçerli olduğunu söyler, asıl suçlu ise sayfadaki tek bir HTTP font veya script çağrısı çıkar. Tersi de olur: sayfa yüzeyde temiz görünür ama TLS taraması www sürümünde SAN uyumsuzluğu yakalar. Bu yüzden yalnız tek araçla karar vermek yanıltıcıdır. Hata kodu, asset yükü ve header seviyesi aynı anda okunmalıdır.

Bu bölümü ekip içinde aktarırken güncel bir Chrome DevTools Security panel videosu eşliğinde ilerlemek faydalıdır; ama asıl doğrulama kendi domaininiz üstünde yapılmalıdır. Öncelik sırası nettir: önce HTTP ve sertifika hataları, sonra mixed content, en son HSTS preload. Çünkü preload yanlış zamanda eklenirse küçük bir yapılandırma hatası bile geri dönüşü yavaş bir probleme dönüşebilir.

• Security paneli: İlk bakışta kullanıcıya görünen güven durumunu doğrular.
• TLS taraması: Zincir, protokol ve hostname sorunlarını ayırır.
• HSTS kontrolü: Header, preload uygunluğu ve uzun vadeli riski gösterir.

Site sağlığı takibiyle uyarının geri gelmesini nasıl önlersiniz?

Bu uyarı çoğu zaman tek seferlik değil, bakım eksikliğinin sonucudur. Sertifika otomatik yenilemesi durmuş olabilir, yeni bir eklenti HTTP asset eklemiş olabilir ya da CDN geçişinde sadece bir alt alan adı unutulmuş olabilir. Bu nedenle HTTPS ve mixed content kontrollerini düzenli bir site sağlığı taraması içine almak daha doğrudur. Aynı şekilde periyodik bir site audit süreci ile yönlendirme, kanonik ve güven başlıkları birlikte izlenmelidir.

Burada SEO etkisi de doğrudandır. Güven uyarısı alan sayfalar kullanıcı güvenini düşürür, dönüşüm oranını baskılar ve özellikle form, sepet veya giriş adımlarında terk oranını artırır. Teknik tarafta ise karışık yönlendirme, yanlış kanonik ve kırık asset çağrıları taranabilirliği bozar. SEOYEN bu noktada Türkçe arayüz, TL bazlı fiyatlandırma ve yerel destekle süreci daha erişilebilir hale getirir. Ahrefs ve SEMrush kapsamlı denetim yetenekleri sunar; SEOYEN bunları Türkiye pazarına uyarlanmış, tek platformda toplayan bir Ahrefs alternatifi ve SEMrush alternatifi yaklaşımıyla konumlanır.

Özellikle mixed content ve sertifika görünürlüğünü hızlı gözden geçirmek için SEOYEN içindeki HTTPS / SSL Kontrolcüsü pratik bir kontrol adımı olarak işe yarar. Daha sürekli bir takip ihtiyacında ise ekip yapınıza göre güncel fiyatlandırma üzerinden uygun planı değerlendirebilirsiniz. Ama hangi araç kullanılırsa kullanılsın, kritik prensip değişmez: sertifika, yönlendirme, asset ve header katmanları birlikte izlenmediğinde bu uyarı geri gelir.

Adım Adım Bu site güvenli değil uyarısını kaldırma süreci

Aşağıdaki sıra, sorunu dağılmadan çözmek için en güvenli akıştır. Buradaki mantık, önce uyarının tipini ayırmak; sonra görünür semptomu değil kök nedeni kapatmaktır.

1. Uyarının ziyaretçi mi site mi kaynaklı olduğunu ayır

   Önce hatanın farklı cihaz ve ağlarda tekrarlanıp tekrarlanmadığını kontrol edin. Sadece tek kullanıcıda görünüyorsa cihaz saati, tarayıcı önbelleği veya ağ müdahalesi ihtimali vardır. Farklı tarayıcı ve cihazlarda da aynıysa sorunu site tarafında ele alın.

2. Sertifika geçerliliği ve hostname eşleşmesini kontrol et

   Sertifikanın süresine, issuer bilgisine ve Subject Alt Name kaydına bakın. Kullanıcının girdiği hostname ile sertifikanın kapsadığı hostname aynı değilse uyarı sürer. www, non-www ve alt alan adlarını tek tek doğrulamak gerekir.

3. HTTP kaynakları HTTPS’ye geçir ve 301 kur

   Ana sayfa, kategori, ürün, görsel ve script URL’lerini HTTPS sürüme taşıyın. Ardından HTTP’den HTTPS’ye tek atımlı 301 yönlendirme kurun. Kanonik etiketler, sitemap ve dahili linkler yeni sürümle uyumlu değilse düzeltmeyi tamamlamış sayılmazsınız.

4. Mixed content ve üçüncü taraf scriptleri temizle

   Tarayıcı Security paneli, Console ve Network görünümünden HTTP kalan asset’leri ayıklayın. Özellikle font, iframe, tag manager, chat widget ve tema dosyalarına dikkat edin. Sorun çoğu zaman ana şablonda kalan tek bir eski asset çağrısından çıkar.

5. HSTS eklemeden önce son doğrulamayı yap

   HTTPS akışı tamamen temizlenmeden HSTS preload kararı vermeyin. Tüm alt alan adları HTTPS desteklemiyorsa preload geri dönüşü zor bir risk üretir. Önce normal HSTS ile başlayıp davranışı izlemek daha güvenlidir.

6. Tarayıcı paneli ve TLS taramasıyla tekrar test et

   Düzeltme sonrası aynı domaini yeniden Security paneli, TLS taraması ve HSTS kontrolünden geçirin. Kırık kilit kalktı mı, chain temiz mi, header doğru mu bakın. Son adım mutlaka yeniden doğrulama olmalıdır; varsayım değil kanıt üzerinden kapanış yapın.

Sıkça Sorulan Sorular