Mixed Content Hatası: HTTPS Sitenizde Karışık İçerik Çözümü

SSL sertifikanızı kurdunuz, adres çubuğunda https:// yazıyor; ama beklediğiniz tam kapalı kilit yerine yanında küçük bir "i" işareti, sarı bir üçgen ya da "Güvenli değil" notu duruyor. Bazı görseller hiç yüklenmiyor, kaydırıcılar bozuk, JavaScript çalışmıyor. Bu, yüz binlerce sitenin SSL'e geçtikten sonra yaşadığı en yaygın sorundur: mixed content (karışık içerik) hatası. İyi haber, bu sorunun kökeni nettir ve çözümü tekrarlanabilir bir süreçtir. Bu rehber, mixed content hatası çözümü için sertifikanın ötesine geçer; sorunun tarayıcı seviyesinde nasıl çalıştığını ve onu kalıcı olarak nasıl kapatacağınızı adım adım gösterir.

Mixed content tam olarak nedir?

Bir sayfa https:// üzerinden yüklendiğinde tarayıcı, o sayfanın tüm kaynaklarının da şifreli kanaldan gelmesini bekler. Ancak sayfanın HTML'i güvenli (https://) gelirken içindeki bazı kaynaklar — bir görsel, bir CSS dosyası, bir font, bir <script> ya da bir <iframe> — hâlâ eski http:// adresleriyle çağrılıyorsa, sayfa "karışık" hâle gelir. Yani güvenli bir sayfanın içinde güvensiz bir borudan akan veri vardır.

Tarayıcı bunu ciddiye alır, çünkü tek bir HTTP kaynağı bile saldırgana sayfanın görünümünü değiştirme veya kullanıcıyı izleme fırsatı verebilir. Sonuç: kilit "tam güvenli" görünmez, bazı kaynaklar sessizce engellenir ve site bozuk görünür.

Pasif ve aktif mixed content arasındaki kritik fark

Tüm karışık içerik aynı tehlikeyi taşımaz, bu yüzden tarayıcılar ikiye ayırır:

Bu ayrım çok önemlidir: Sitenizde sadece kilit "kusurlu" görünüyorsa büyük ihtimalle pasif içerik (bir-iki HTTP görsel) vardır. Ama kaydırıcı dönmüyor, menü açılmıyor, form gönderilmiyorsa, neredeyse kesinlikle aktif içerik engellenmiştir. Modern Chrome ve Firefox, aktif mixed content'i istisnasız bloklar; pasif içeriği de giderek daha sıkı engellemeye doğru gidiyorlar. Yani "şimdilik çalışıyor" demek, yarın da çalışacak demek değildir.

Adım 1: Sorunlu kaynağı tarayıcı konsolundan bulun

Tahminle uğraşmayın; tarayıcı size tam olarak hangi dosyanın suçlu olduğunu söyler.

1. Sorunlu sayfayı açın, klavyeden F12 ile geliştirici araçlarını açın.
2. Console sekmesine geçin ve sayfayı yenileyin.
3. Şuna benzer satırları arayın:

Mixed Content: The page at 'https://ornek.com/' was loaded over HTTPS,
but requested an insecure image 'http://ornek.com/logo.png'.
This content should also be served over HTTPS.

Bu satır, sorunlu dosyanın tam URL'sini ve türünü (image, script, stylesheet…) verir. "blocked" kelimesi geçen satırlar aktif içeriktir ve önceliğiniz olmalıdır. Birkaç dakikada hangi kaynakların düzeltilmesi gerektiğini tam liste hâlinde çıkarmış olursunuz.

İpucu: Konsola hiç bakmadan, sitenizin güvenlik durumunu dışarıdan hızlıca görmek isterseniz Hostmana'nın ücretsiz SSL ve HTTP başlık denetim araçlarını kullanabilirsiniz; sertifika zinciri ve güvenlik sinyalleri tek ekranda özetlenir.

Adım 2: WordPress kullanıyorsanız — en hızlı yol

Karışık içeriğin en yaygın kaynağı WordPress'tir; çünkü site URL'si, eski yazılardaki resim bağlantıları ve tema ayarları yıllar içinde http:// olarak veritabanına yazılmış olabilir. Sıralı çözüm:

1. Site adresini HTTPS'e çekin. Ayarlar → Genel bölümünde WordPress Adresi (URL) ve Site Adresi (URL) alanlarını http:// yerine https:// yapıp kaydedin. Bu, sitenin temel iskeletini güvenli hâle getirir.

2. Veritabanındaki eski bağlantıları toplu değiştirin. Eski yazıların gövdesinde gömülü http://ornek.com/... görselleri kalmış olabilir. Better Search Replace gibi bir eklenti ile http://ornek.com ifadesini https://ornek.com ile değiştirin.

Önce yedek alın. Veritabanında toplu değişiklik geri alınması zor bir işlemdir. İşleme başlamadan önce mutlaka bir yedek alın; düzenli yedekleme alışkanlığı zaten her site için olmazsa olmazdır.

3. Otomatik düzeltici eklenti. Tek tek uğraşmak istemiyorsanız Really Simple SSL gibi bir eklenti, hem mixed content çoğunlukla otomatik düzeltir hem de HTTPS yönlendirmesini kurar. Yine de kalıcı temizlik için 1. ve 2. adımları yapmanız, eklentiye bağımlılığı azaltır.

Adım 3: WordPress dışı siteler — elle düzeltme mantığı

Statik HTML, özel PHP uygulaması ya da başka bir altyapı kullanıyorsanız, çözüm tema ve şablon dosyalarınızdaki sabit kodlanmış (hardcoded) bağlantıları gözden geçirmektir. Burada üç pratik yaklaşım var:

• Mutlak HTTP'yi mutlak HTTPS'e çevirin: http://ornek.com/style.css → https://ornek.com/style.css. En açık ve önerilen çözümdür.
• Protokole bağlı göreli yol kullanın: //cdn.ornek.com/script.js yazımı, sayfa hangi protokolde açılırsa o protokolü kullanır. Tek bir kaynağı hem HTTP hem HTTPS sitelerde çalıştırmanız gerekiyorsa pratiktir.
• Site içi kaynaklarda kök-göreli yol: Aynı alan adındaki dosyalar için /images/logo.png gibi kök-göreli yol yazarsanız, protokol sorunu hiç doğmaz.

Şablonlarınızda grep benzeri bir aramayla http:// ifadesini tarayıp, kaynak çağrılarını (src=, href=, url(...)) tek tek HTTPS'e taşıyın. Bu, kalıcı ve eklentisiz çözümdür.

Adım 4: Asıl belalı kaynak — üçüncü taraf içerikler

En çok zaman alan vaka, sorunun sizin sunucunuzda olmamasıdır. Sayfanıza eklediğiniz dış servisler hâlâ HTTP üzerinden çağrılıyor olabilir:

• Eski bir harita gömme kodu (http://maps...)
• HTTP linkli bir YouTube/video iframe'i
• Reklam, sayaç, canlı destek veya yorum widget'ı
• CDN üzerinden çekilen bir font ya da ikon kütüphanesi

Çözüm sırası:

1. HTTPS sürümü var mı, bakın. Çoğu ciddi servis bugün HTTPS sunar; gömme kodundaki http:// ifadesini https:// yapmak çoğu zaman yeterlidir.
2. Servis HTTPS desteklemiyorsa, o kaynağı kaldırmaktan ya da HTTPS sunan bir alternatifle değiştirmekten başka güvenli yol yoktur. Bir aktif kaynağı "HTTP'de zorla yükletmek" mümkün değildir; tarayıcı kullanıcıyı korumak için engeller.
3. Reklam/analitik kodlarını güncel sürümle değiştirin. Sağlayıcıların yeni gömme kodları neredeyse her zaman protokolsüz veya HTTPS'tir.

Adım 5: CSP ile otomatik yükseltme (büyük sitelerin kestirmesi)

Yüzlerce eski bağlantısı olan büyük bir sitede her URL'yi elle düzeltmek günler alabilir. Bu durumda CSP (Content Security Policy) başlığındaki upgrade-insecure-requests direktifi, tarayıcıya "bu sayfadaki tüm HTTP isteklerini otomatik olarak HTTPS'e yükselt" talimatı verir. Sunucu tarafında HTTP başlığı olarak ya da sayfa <head> içinde meta etiketiyle eklenebilir:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Bu, görseller ve scriptler dahil tüm aynı-kaynak (ve HTTPS sunan dış kaynak) çağrılarını şeffafça HTTPS'e çevirir. Ancak bir kestirmedir, kalıcı çözümün yerini tutmaz: Yalnızca HTTPS sürümü gerçekten var olan kaynaklar için işe yarar; HTTPS desteği olmayan bir kaynak yine de yüklenmez. En sağlıklısı, kaynakları kalıcı olarak HTTPS'e taşıyıp upgrade-insecure-requests'i bir güvenlik ağı olarak kullanmaktır.

Adım 6: HTTPS yönlendirmesini sağlamlaştırın

Mixed content'i temizledikten sonra, ziyaretçilerin siteyi http:// ile açtığında bile HTTPS'e düşmesini garanti altına alın. Apache tabanlı sunucularda site kök dizinindeki .htaccess dosyasına şu kural eklenir:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

R=301 kalıcı yönlendirme demektir ve arama motorlarına asıl adresin HTTPS olduğunu bildirir. Kontrol panelinizden (DirectAdmin veya Plesk) "HTTPS'e zorla yönlendir" seçeneği varsa, onu kullanmak daha temizdir. Yönlendirme stabil çalışınca, istenirse HSTS başlığıyla tarayıcıya "bu siteye her zaman HTTPS ile bağlan" talimatı verilebilir — ama HSTS'i yalnızca SSL'inizin sorunsuz olduğundan emin olduktan sonra açın.

Düzelttiniz ama uyarı sürüyorsa — kontrol listesi

Çoğu zaman sorun çözülmüştür ama tarayıcı eski durumu gösterir. Şunları sırasıyla kontrol edin:

• Tarayıcı önbelleği: Gizli/Incognito sekmede deneyin veya önbelleği temizleyip sayfayı sert yenileyin (Ctrl+F5).
• Birden çok sayfa: Mixed content sayfa bazlıdır. Ana sayfa temiz olsa da bir iç sayfada eski bir HTTP görsel kalmış olabilir; konsolu sorunlu sayfada açın.
• Tema/eklenti güncellemesi sonrası geri dönüş: Bir tema güncellemesi eski HTTP bağlantılarını geri getirebilir; düzeltmeden sonra kritik şablonları sürüm kontrolünde tutun.
• www farkı: Sertifika ve yönlendirme hem ornek.com hem www.ornek.com sürümünü kapsamalı; aksi halde bir sürüm temiz, diğeri sorunlu görünebilir.
• CDN/önbellek katmanı: CDN kullanıyorsanız, kaynak sunucuda düzeltme yaptıktan sonra CDN önbelleğini de purge (boşaltma) edin; yoksa CDN eski HTTP içeriği servis etmeye devam eder.

Türkiye'deki site sahipleri için bir not: .com.tr, .org.tr gibi .tr uzantılı alan adlarında mixed content çözümü birebir aynı mantıkla işler; uzantının yerli olması hiçbir ek engel çıkarmaz. KVKK uyumu kapsamında HTTPS pratik bir zorunluluk hâline geldiğinden, bu temizliği tamamlamak hem teknik hem yasal açıdan sizi rahatlatır.

Sonuç

Mixed content hatası, "SSL kurdum ama tam güvenli olmadı" sorununun neredeyse her zamanki sebebidir ve çözümü sistematiktir: önce konsoldan suçlu kaynağı bulun, ardından kaynağı (WordPress'te toplu değiştirme, başka altyapılarda elle ya da CSP ile) HTTPS'e taşıyın, üçüncü taraf içerikleri güncel HTTPS sürümleriyle değiştirin, en son yönlendirme ve önbelleği sağlamlaştırın. Pasif ile aktif içerik ayrımını aklınızda tutarsanız, "neden bu görsel yükleniyor da o script çalışmıyor" sorusunu da kolayca yanıtlarsınız.

Sertifika zincirinizi, karışık içerik sinyallerinizi ve site güvenliğinizi tek ekrandan görmek için Hostmana'nın ücretsiz site denetim araçlarını kullanabilir, takıldığınız adımlarda bilgi bankamızdaki kurulum yazılarına başvurabilirsiniz. Karmaşık bir kurulumda elinizden tutacak bir uzman isterseniz uzaktan canlı destek ile ekranınızı paylaşıp adım adım ilerleyebilir; otomatik Let's Encrypt destekli, HTTPS'e hazır bir altyapı için ise hosting paketlerimizi inceleyebilirsiniz.