Sitenize SSL kurdunuz, adres çubuğunda https görünüyor ama kilit simgesi yerine bir uyarı çıkıyor, bazı görseller veya stiller yüklenmiyor ya da bir form çalışmıyor. Bunun en yaygın nedeni mixed content, Türkçesiyle karma içeriktir: sayfanın kendisi HTTPS ile gelir, ama içindeki bazı kaynaklar hâlâ http:// adresinden çağrılır.
Bu yazıda karma içeriğin ne olduğunu MDN ve web.dev tanımlarıyla açıklıyor, tarayıcıların bugün hangi kaynakları otomatik olarak HTTPS'e yükselttiğini ve hangilerini engellediğini anlatıyor, sonra sorunlu adresleri bulup kalıcı olarak düzeltmenin adımlarını veriyoruz: veritabanında http adreslerini değiştirmek, temadaki sabit adresleri düzeltmek ve upgrade-insecure-requests başlığını doğru yerde kullanmak.
Mixed content nedir?
MDN tanımına göre karma içerik, güvenli olarak yüklenen bir web sayfasının bazı kaynakları HTTP veya başka bir güvensiz protokolle getirmesidir. Güvensiz giden kaynaklar yolda görülebilir veya bir saldırgan tarafından değiştirilebilir. web.dev de aynı şeyi söyler: sayfanın ilk HTML'i güvenli HTTPS bağlantısıyla yüklenir, ama görseller, betikler, stil dosyaları gibi diğer kaynaklar HTTP üzerinden gelir.
Bu yüzden karma içerik yalnızca görsel bir uyarı değildir. HTTP ile gelen bir JavaScript dosyası değiştirilirse saldırgan sayfanın tamamını kontrol edebilir; web.dev, aktif karma içeriğin saldırgana çok daha fazla kontrol verdiğini vurgular. Pasif içerik (görsel, ses, video) daha az risklidir ama yine de değiştirilebilir veya kullanıcıyı izlemek için kullanılabilir.
Tarayıcılar bugün ne yapıyor: yükseltilebilir ve engellenebilir içerik
Eski sınıflandırma "pasif / aktif" veya spesifikasyondaki adıyla "optionally blockable / blockable" idi. MDN, bu kategorilerin yerini yükseltilebilir (upgradable) ve engellenebilir (blockable) ayrımının aldığını belirtir. MDN'e göre tarayıcılar görsel, video ve ses karma içerik isteklerini HTTP'den HTTPS'e otomatik olarak yükseltir, diğer tüm kaynak türleri için güvensiz istekleri engeller. Otomatik yükseltmede istenen dosya HTTPS üzerinde yoksa yüklenmez.
| Tür | Örnekler (MDN listesi) | Tarayıcı davranışı |
|---|---|---|
| Yükseltilebilir | src ile verilen <img> (SVG dahil), CSS görsel özellikleri (background-image, border-image), src ile <audio> ve <video>, <source> | https:// olarak istenir; HTTPS'te yoksa yüklenmez |
| Engellenebilir | <script src>, stil dosyaları dahil <link href>, <iframe src>, fetch() ve XMLHttpRequest, web fontları, <object>, sendBeacon, srcset veya <picture> ile verilen görseller | Engellenir, konsola uyarı düşer |
MDN iki ayrıntıya özellikle dikkat çeker: srcset veya <picture> ile verilen görseller yükseltilmez, engellenir. Ayrıca adres bir IP adresiyse (örneğin http://93.184.215.14/image.png) yükseltilebilir türdeki istekler de engellenir. WordPress temaları duyarlı görseller için srcset kullandığından, veritabanında kalmış http adresleri bazı görsellerin bazı ekran boyutlarında görünmemesine yol açabilir.
Ziyaretçiyseniz
Karma içerik sitenin kodundan kaynaklanır; ziyaretçi tarafında çözülecek bir şey yoktur. Kilit yerine uyarı görüyorsanız ve sayfa sizden şifre, kart bilgisi gibi hassas veri istiyorsa bilgi girmeyin ve site sahibine haber verin. Tarayıcınızın karma içerik engellemesini kapatmayın; bu engel sizi korumak için oradadır. Sertifikayla ilgili tam sayfa uyarılar ise ayrı bir konudur: SSL sertifika hataları.
Site sahibiyseniz: karma içeriği bulma
DevTools Console ve Issues
MDN'e göre geliştirici konsolu, karma içerik yükseltildiğinde veya engellendiğinde uyarı gösterir. Chrome'da F12 ile Geliştirici Araçları'nı açın, sayfayı yenileyin ve Console sekmesinde "Mixed Content" ile başlayan satırları arayın. web.dev'e göre Chromium tabanlı tarayıcılar karma içeriği ayrıca Issues sekmesinde listeler; Firefox ve Safari ise konsola mesaj yazar. Uyarı satırı, hangi sayfanın hangi http adresini istediğini gösterir; bu adres size kaynağın nereden geldiğini (yazı içeriği, tema dosyası, eklenti, harici servis) söyler.
Network sekmesinde filtre kutusuna http:// yazmak veya sayfa kaynağında (Ctrl+U) http:// aramak da hızlı bir yöntemdir. Tek bir sayfayı değil, şablonu farklı olan sayfaları da kontrol edin: ana sayfa, yazı, kategori, ürün, iletişim formu.
Komut satırından tarama
# Sayfa HTML'inde http:// ile başlayan src/href değerlerini listele
curl -s https://www.example.com/ | grep -oE '(src|href|srcset)="http://[^"]+"' | sort -uBu yöntem yalnızca HTML'deki adresleri gösterir; CSS dosyalarının içindeki url(http://...) çağrılarını ve JavaScript ile sonradan eklenen kaynakları görmek için DevTools gerekir.
Düzeltme 1: Veritabanındaki http adreslerini değiştirmek (WordPress)
Site HTTP iken eklenen görsellerin ve iç bağlantıların adresleri yazı içeriğinde, eklenti ayarlarında ve sayfa oluşturucu verilerinde http:// olarak kayıtlı kalır. Bunları tek tek düzeltmek yerine WP-CLI'nin search-replace komutu kullanılır. WP-CLI belgesine göre bu komut PHP serileştirilmiş verisini akıllıca ele alır ve birincil anahtar değerlerini değiştirmez. phpMyAdmin'de elle SQL REPLACE çalıştırmak bu güvenceyi vermez; serileştirilmiş ayarlar bozulabilir.
# 1) Yedek al
wp db export yedek-oncesi-https.sql
# 2) Kuru çalıştırma: değişiklik yapmaz, kaç kayıt etkileneceğini raporlar
wp search-replace 'http://www.example.com' 'https://www.example.com' --skip-columns=guid --dry-run
# 3) Rapor makulse gerçek değiştirme
wp search-replace 'http://www.example.com' 'https://www.example.com' --skip-columns=guid
# 4) Önbellekleri temizleyin (eklenti/sunucu önbelleği, CDN)Açıklamalar: --dry-run belgeye göre işlemin tamamını çalıştırıp raporu gösterir ama veritabanına kaydetmez. --skip-columns=guid, belgedeki örnekte de kullanılır; WordPress belgesi yazıların GUID sütununun hiçbir koşulda değiştirilmemesi gerektiğini söyler. Önekli WordPress tabloları dışında da veri tutan eklentiler varsa --all-tables seçeneği önek fark etmeksizin tüm tablolarda çalışır; karmaşık serileştirilmiş verilerde --precise daha yavaş ama daha güvenilir PHP işlemeyi zorlar. www'li ve www'siz eski adreslerin ikisi de kullanıldıysa komutu her iki eski adres için ayrı ayrı çalıştırın.
WP-CLI erişiminiz yoksa hostinginizin destek ekibinden yardım isteyebilir veya serileştirilmiş veriyi destekleyen bir arama-değiştirme aracı kullanabilirsiniz. Ayrıca Ayarlar > Genel bölümündeki "WordPress Address (URL)" ve "Site Address (URL)" değerlerinin https ile başladığından emin olun; aksi halde WordPress'in ürettiği bağlantılar http olarak çıkmaya devam eder.
Düzeltme 2: Temadaki ve eklentilerdeki sabit adresler
Konsoldaki http adresi tema veya eklenti dosyalarından geliyorsa veritabanı değişikliği işe yaramaz. Tema klasöründe arama yapın:
# Tema ve eklenti klasörlerinde http:// içeren satırları bul
grep -rn "http://" wp-content/themes/tema-adi/ --include=*.php --include=*.css --include=*.js
grep -rn "http://www.example.com" wp-content/plugins/ --include=*.phpDüzeltme yöntemleri:
- Kendi alan adınıza giden sabit adresleri, WordPress'in adres üreten fonksiyonlarıyla değiştirin: tema dosyaları için
get_template_directory_uri(), site içi bağlantılar içinhome_url(). Bu fonksiyonlar kayıtlı site adresini kullandığından https'e geçtiğinizde kendiliğinden doğru adres üretilir. - CSS içindeki
url(http://...)çağrılarını göreli yola (url(../img/arka-plan.jpg)) veya https adresine çevirin. - Harici kaynaklarda (yazı tipi, harita, video yerleştirme, reklam/analiz betiği) sağlayıcının https adresini kullanın. Sağlayıcı HTTPS sunmuyorsa o kaynak engellenmeye devam eder; alternatif bir servise geçmeniz gerekir.
- Hazır bir temanın dosyasını değiştirmek yerine alt tema (child theme) kullanın; aksi halde tema güncellemesi düzeltmenizi siler. Satın alınan tema veya eklentideyse geliştiricisine bildirin.
Düzeltme 3: Content-Security-Policy upgrade-insecure-requests
MDN'e göre upgrade-insecure-requests yönergesi, tarayıcıya sitenin tüm güvensiz adreslerini HTTPS adresleriyle değiştirilmiş gibi işlemesini söyler ve çok sayıda eski HTTP adresi olan siteler için tasarlanmıştır. Bu yönerge engellenebilir karma içeriği de dahil olmak üzere istekleri HTTPS'e yükseltir. Başlık olarak veya HTML'de meta etiketi olarak verilebilir:
# Apache (.htaccess veya VirtualHost, mod_headers gerekir)
<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule># Nginx (server bloğunda)
add_header Content-Security-Policy "upgrade-insecure-requests" always;<!-- veya HTML <head> içinde -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">MDN'in belirttiği sınırlar önemlidir:
- Yükseltilen kaynak HTTPS üzerinde yoksa istek başarısız olur, HTTP'ye geri dönülmez ve bu sessizce olur. Yani yönerge bozuk bir kaynağı onarmaz, yalnızca gizler.
- Üçüncü taraf sitelere giden bağlantılar (gezinmeler) yükseltilmez.
- HSTS'nin yerini tutmaz. Ziyaretçilerin HTTP adresine gelmesini önlemek için sunucuda HTTP'den HTTPS'e yönlendirme ve uygun bir
Strict-Transport-Securitybaşlığı yine gerekir. - Sitenizde zaten bir Content-Security-Policy başlığı varsa ikinci bir başlık eklemek yerine yönergeyi mevcut politikaya ekleyin.
Neden, belirti ve çözüm tablosu
| Neden | Belirti | Çözüm |
|---|---|---|
| Yazı içeriğinde eski http görsel adresleri | Konsolda yükseltildi uyarısı; srcset görselleri eksik | WP-CLI search-replace (önce yedek ve --dry-run) |
| Temada sabit http adresi | Tüm sayfalarda aynı uyarı, stil veya betik engelli | home_url() / get_template_directory_uri(), alt tema |
| CSS içinde url(http://...) | Font veya arka plan yüklenmiyor | Göreli yol veya https adresi |
| Harici servis HTTPS sunmuyor | Sadece o gömülü içerik çalışmıyor | Servisin https adresi veya alternatif servis |
| WordPress adresleri http | Yeni eklenen bağlantılar yine http | Ayarlar > Genel veya WP_HOME/WP_SITEURL |
| Önbellekte eski HTML | Düzeltmeye rağmen uyarı sürüyor | Eklenti, sunucu ve CDN önbelleğini temizleyin |
Sık Sorulan Sorular
Karma içerik SEO'yu etkiler mi?
Karma içerik, engellenen betik ve stiller yüzünden sayfanın bozuk görünmesine ve ziyaretçinin güvenlik uyarısı görmesine yol açar; bu da kullanıcı deneyimini doğrudan etkiler. Sorunun SEO'ya etkisine dair kesin bir sıralama kuralı belirtmeyeceğiz, ama temiz bir HTTPS kurulumu her açıdan doğru hedeftir.
SSL eklentisi karma içeriği çözer mi?
Bazı eklentiler sayfa çıktısındaki http adreslerini anlık olarak değiştirir. Bu geçici olarak işe yarayabilir, ama asıl adresler veritabanında ve temada kalır. Kalıcı çözüm adresleri kaynağında düzeltmektir. Eklentinin kendi HTTPS yönlendirmesi sunucu kuralıyla çakışırsa ERR_TOO_MANY_REDIRECTS döngüsüne de yol açabilir.
search-replace sonrası site bozuldu, ne yapmalıyım?
Aldığınız yedeği geri yükleyin (wp db import yedek-oncesi-https.sql), ardından komutu yazım hatası olup olmadığını kontrol ederek önce --dry-run ile yeniden deneyin. Eski ve yeni adresleri sonlarında eğik çizgi olmadan, birebir aynı biçimde yazmaya dikkat edin.
Kilit simgesi neden hâlâ görünmüyor?
Konsolda kalan bir uyarı, önbellekte duran eski bir sayfa veya sertifika sorunu olabilir. Önce önbellekleri temizleyip gizli pencerede test edin; konsol temizse sertifikayı kontrol edin: Let's Encrypt SSL kurulumu, HTTPS ve TLS 1.3 rehberi.
Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: ERR_TOO_MANY_REDIRECTS çözümü · SSL sertifika hataları · Let's Encrypt SSL kurulumu · .htaccess rehberi · Nginx yapılandırma rehberi · Veritabanı yedekleme stratejileri