Mixed Content Hatası Nedir? Karışık İçerik Sorunu Nasıl Çözülür?

Mixed content hatası nedir?

Mixed content hatası (karışık içerik hatası), HTTPS ile açılan bir sayfanın görsel, script ya da stil dosyası gibi kaynaklardan en az birini güvensiz HTTP adresinden yüklemeye çalışmasıdır. Tarayıcı bu kaynağı engeller ya da adres çubuğundaki güvenli kilit simgesini kaldırır. Sonuç olarak sayfa bozuk görünür ve ziyaretçi siteye güvenmez.

Türkçede "karışık içerik" denir, çünkü tek sayfada güvenli ve güvensiz bağlantı karışık biçimde bulunur. Sayfanın kendisi şifreli gelir, ancak içindeki bir parça şifresiz yoldan iner. Bu parçayı ağ üzerinde dinleyen ya da değiştiren biri, sayfanın görünümünü ve davranışını etkileyebilir.

Tarayıcı konsolu hatayı genellikle "Mixed Content" ifadesiyle başlayan bir mesajla bildirir. Mesajda sayfanın HTTPS ile yüklendiği, ancak HTTP ile bir kaynak istendiği yazar. Örneğin eski bir yazıya gömdüğünüz http:// ile başlayan bir görsel adresi bu uyarıyı üretir.

Bu yazı SSL sertifikasının ne olduğunu baştan anlatmaz. O konuyu SSL sertifikası ve HTTPS güvenliği rehberimizde ele aldık. Burada sertifika kuruluyken bile neden hata çıktığına ve onu nasıl temizleyeceğinize odaklanıyoruz.

Mixed content hatasından kim sorumlu: ziyaretçi mi, site sahibi mi, sunucu yöneticisi mi?

Ziyaretçi olarak sorumluluk size ait değildir, çünkü hata sayfanın kaynak kodundaki HTTP adreslerinden doğar. Düzeltmeyi site sahibi ya da siteyi yöneten teknik kişi yapar. Sunucu yöneticisi ise yönlendirme ve başlık ayarlarında devreye girer. Önce rolünüzü belirleyin, çünkü yanlış yerde zaman kaybetmek sorunu uzatır.

Hosting paketi kullanıyorsanız sunucu ayarlarının bir kısmı sağlayıcınızın elindedir. Bu nedenle panelde yapamadığınız bir ayar için destek talebi açmak doğru yoldur. Ayrıca sayfayı yapan ajans ya da yazılımcı varsa, adresleri kaynak kodda düzeltmek onların işidir.

Pasif ve aktif karışık içerik arasındaki fark nedir?

Pasif karışık içerik görsel, video ve ses gibi sayfayla etkileşime girmeyen kaynaklardır. Aktif karışık içerik ise script, stil dosyası ve iframe gibi sayfanın davranışını değiştirebilen kaynaklardır. web.dev rehberine göre aktif içerikte saldırgan sayfanın tamamına hâkim olabilir. Bu yüzden modern tarayıcılar aktif içeriği varsayılan olarak engeller.

Ayrım MDN belgelerindeki sınıflandırmaya dayanır. Dolayısıyla bir görselin sorunsuz görünmesi, sayfanızın temiz olduğu anlamına gelmez. Tarayıcı o görseli sessizce yükseltmiş olabilir. Aynı sayfadaki bir script ise HTTP olduğu için çalışmaz ve tarayıcı onu tamamen durdurur.

Mixed content hatası SEO ve güveni nasıl etkiler?

Doğrudan etkisi güven ve işlevdedir. Tarayıcı güvenli kilit simgesini kaldırdığında ziyaretçi uyarı görür, ödeme ya da form sayfasında bu durum çıkış nedenine dönüşür. Engellenen bir script, menüyü, sepeti ya da formu bozabilir. Bu yüzden sorun yalnızca estetik değildir.

Arama tarafında Google, HTTPS'i olumlu bir kalite göstergesi olarak kullanır. web.dev'in HTTPS etkinleştirme rehberi de bunu belirtir. Karışık içerik, sayfanın HTTPS olmasının faydasını zayıflatır. Ancak tek bir engellenen görsel için sıralama kaybı vaat etmiyoruz, çünkü böyle bir rakam yayımlanmış değildir.

Dolaylı etki ise kullanıcı davranışında görünür. Bozuk düzen, çalışmayan buton ve güvenlik uyarısı hemen çıkma oranını artırabilir. Hız tarafı için site hızının SEO'yu nasıl etkilediğini anlatan yazımıza bakabilirsiniz. Teknik denetimin genel çerçevesi için teknik SEO ipuçları yazımız yardımcı olur.

Mixed content hatası hangi nedenlerle ortaya çıkar?

Hatanın kaynağı neredeyse her zaman geçmişten kalan bir http:// adresidir. Site HTTP döneminde yayına girdiyse, o günlerde yazılan içerik eski adresleri taşır. Sertifika sonradan kurulunca sayfa HTTPS olur ama içerik aynı kalır. Bu yüzden eski siteler yeni sitelerden daha sık sorun yaşar.

• HTTP döneminden kalan yazı, görsel ve gömülü içerik adresleri.
• Temada ya da özel CSS'te elle yazdığınız http:// adresleri.
• Başka bir siteden kopyalayıp yapıştırdığınız içerik parçaları.
• Eklenti ayarlarında kayıtlı eski alan adı ya da kaynak adresi.
• CDN ya da alt alan adı için tanımladığınız HTTP adresleri.
• Yorum, form ya da kullanıcı içeriğiyle gelen güvensiz bağlantılar.

Nedeni bilmek çözümün yerini belirler. Örneğin içerikteki adresler için veritabanı değişimi gerekir. Temadaki adresler için dosyayı düzenlersiniz. Proxy kaynaklı sorunda ise sunucu ayarı devreye girer.

Tarayıcılar karışık içeriği neden engeller?

Engelin amacı, HTTPS'in verdiği korumayı bir tek zayıf halkayla boşa çıkarmamaktır. HTTP ile inen bir dosya yolda okunabilir ya da değiştirilebilir. MDN bunu dinleme ve ortadaki adam (MITM) saldırıları olarak tanımlar. Saldırgan bir script'i değiştirirse sayfanın tamamını etkileyebilir.

Pasif içerikte risk daha düşüktür ama sıfır değildir. Bir görselin değiştirilmesi yanıltıcı bilgi gösterebilir. Ayrıca kaynak isteği, ziyaretçinin hangi sayfada olduğunu ağa sızdırabilir. Bu yüzden tarayıcılar önce yükseltmeyi dener, yükseltemezse uyarı verir ya da engeller.

Siz bir site sahibi olarak bu mantıktan şunu çıkarın: uyarıyı bastırmak yerine kaynağı HTTPS'e taşıyın. Tarayıcı uyarısını gizlemek hiçbir güvenlik kazandırmaz.

Mixed content hatasını tarayıcı konsolunda nasıl bulursunuz?

Chrome'da sayfayı HTTPS ile açın, F12 ile geliştirici araçlarını başlatın ve Console ile Issues sekmelerine bakın. web.dev'e göre Issues sekmesi her güvensiz kaynağı, engellenip engellenmediğiyle birlikte listeler. Firefox ve Safari ise konsola mesaj yazar. Adım adım şöyle ilerleyin.

1. Sayfayı gizli pencerede açın, çünkü eklentiler konsolu kirletebilir.
2. Geliştirici araçlarını açıp sayfayı sert yenileyin.
3. Console sekmesinde "Mixed Content" ifadesini arayın.
4. Issues sekmesinde güvensiz kaynağın adresini ve türünü not edin.
5. Sayfa kaynağını (Ctrl+U) açıp "http://" araması yapın.

Kaynak adresi bulunca nereden geldiğini anlayın. Adres içerikte yazılıysa yazıyı düzenlersiniz. Temadan geliyorsa tema dosyasına bakarsınız. Eklentiden geliyorsa eklenti ayarını kontrol edersiniz. Bir adres birden çok sayfada tekrar ediyorsa toplu düzeltme gerekir, bunu aşağıda anlatıyoruz.

Konsol mesajı üç bilgi taşır: hangi sayfada olduğunuz, hangi kaynağın istendiği ve kaynağın türü. Kaynağın türü, pasif mi aktif mi olduğunu söyler. Aktif türde sayfada işlev kaybı bekleyin. Adres ise düzeltmenin nereden başlayacağını gösterir. Aynı alan adından gelen çok sayıda satır, tek bir ayarın sorun olduğuna işaret eder.

Hangi sayfalardaki mixed content hatasını önce düzeltmelisiniz?

Binlerce sayfa varsa hepsini aynı anda temizlemek gerçekçi değildir. Önceliği, hatanın ziyaretçiye ve gelire verdiği zarara göre belirleyin. Para ya da kişisel veri girilen sayfalar en başta gelir. Ardından en çok trafik alan sayfalara geçin. Son olarak arşiv içeriği ele alın.

Toplu değişim çoğu zaman dördüncü grubu da kendiliğinden kapatır. Dolayısıyla önce ilk iki grubu elle doğrulayın, sonra toplu işlemi çalıştırın. Bu sıra, en riskli sayfaları ilk günden güvenceye alır.

Mixed content hatasını sitenin tamamında nasıl taratırsınız?

Tek sayfayı bulmak kolaydır, ancak yüzlerce sayfalı sitede elle gezmek verimsizdir. Bu durumda tarama araçları ve veritabanı aramasını birlikte kullanın. MDN, kontrol için LinkChecker, mcdetect gibi araçları örnek verir. Ayrıca kendi içeriğinizi veritabanında "http://" ifadesiyle aramak çoğu kaynağı hızla ortaya çıkarır.

• Sitenizin sayfalarını tarayan bir araçla HTTP kaynaklarını listeleyin.
• Veritabanında içerik ve meta tablolarında "http://" geçen kayıtları sayın.
• Tema ve eklenti dosyalarında sabit yazdığınız adresleri arayın.
• Sitemap ve kanonik adreslerin HTTPS olduğunu doğrulayın.

Kırık bağlantıları ayrıca temizlemek isterseniz kırık link kontrol aracımız bu işi kolaylaştırır. Sitenin hangi altyapıyı kullandığını bilmiyorsanız site altyapı tespiti aracı hangi yönteme gideceğinizi seçmenize yardım eder.

Önce sertifika ve HTTPS yönlendirmesi doğru çalışıyor mu?

Karışık içerik temizliğine başlamadan önce sertifikanın geçerli olduğunu doğrulayın. Süresi dolan ya da yanlış alan adına ait bir sertifika, mixed content'ten farklı bir uyarı üretir. Bu uyarı tam sayfa tarayıcı hatası olarak çıkar, konsoldaki bir satır değildir. İki sorunu karıştırmak teşhisi bozar.

Sertifika durumunu SSL sorgulama aracımızla kontrol edebilirsiniz. Alt alan adlarınız çoksa wildcard SSL yazımız hangi sertifika türünün gerektiğini açıklar. Hepsini tek sertifikayla kapatamadığınız alt alan adı, kendi başına bir karışık içerik kaynağı olabilir.

Ardından HTTP adresinin HTTPS'e yönlendiğini test edin. Yönlendirme yoksa aynı içerik iki adreste yaşar ve ziyaretçi bazen güvensiz sürümü açar. Ayarı sunucu bölümünde ele alıyoruz. Zincirlerin SEO etkisini anlamak için yönlendirme zinciri yazımıza bakın.

Mixed content hatasını düzeltmek için adım sırası nedir?

Sıra önemlidir, çünkü yanlış sırada yapılan düzeltme iş tekrarı yaratır. Önce sertifikayı doğrularsınız, sonra kaynağı düzeltirsiniz, en sonda güvenlik ağını eklersiniz. Her adımdan sonra konsolu yeniden kontrol edin. Böylece hangi adımın işe yaradığını görürsünüz.

1. Sertifikanın geçerli olduğunu ve HTTP'nin HTTPS'e yönlendiğini doğrulayın.
2. Konsolda güvensiz kaynakları listeleyin ve türüne göre ayırın.
3. Yedek alın, ardından içerikteki adresleri toplu değiştirin.
4. Tema, eklenti ve özel koddaki adresleri elle düzeltin.
5. Harici kaynakların HTTPS sürümünü kullanın ya da kaynağı kaldırın.
6. CSP upgrade-insecure-requests başlığını güvenlik ağı olarak ekleyin.
7. Önbelleği temizleyip sayfaları yeniden test edin.

Aşağıdaki bölümler bu adımları sırayla açıyor. Büyük ve çok dilli sitelerde her adım için ayrı zaman ayırmanız gerekir.

WordPress'te mixed content hatası nasıl düzeltilir?

WordPress'te ilk adım, Ayarlar, Genel bölümünde "WordPress Adresi" ile "Site Adresi" alanlarının https:// ile başladığını doğrulamaktır. Bu iki alan, temanın ve eklentilerin ürettiği adreslerin temelidir. Alanlar http:// ise birçok kaynak güvensiz çıkar. Değiştirdikten sonra yeniden giriş yapmanız gerekebilir.

Sonraki adım tema ve eklentilerdir. Tema ayarlarında, özelleştirici alanında ya da sayfa oluşturucu eklentilerde elle yazılmış http:// adresleri kalabilir. Logo, arka plan görseli ve özel CSS içindeki adresleri tek tek kontrol edin. Bu adresler veritabanı değişiminden etkilenmeyen yerlerde de durabilir.

• Genel ayarlarda iki adresin https:// olduğunu doğrulayın.
• Tema özelleştiricideki logo ve arka plan adreslerini kontrol edin.
• Özel CSS ve widget alanlarındaki http:// adreslerini arayın.
• Eklenti ayarlarında kayıtlı eski adresleri güncelleyin.
• Önbellek eklentisini ve CDN önbelleğini temizleyin.

Sitenin genel mimarisi hakkında karar veriyorsanız WordPress mi özel kodlama mı yazımız çerçeve sunar. Ayarları değiştirmeden önce mutlaka yedek alın. Yedek planı için web sitesi yedekleme stratejisi rehberine göz atın.

Veritabanındaki http:// adresleri toplu nasıl değiştirirsiniz?

İçerikteki eski adresler veritabanında durur, bu yüzden toplu düzeltme için arama-değiştirme gerekir. WordPress için en güvenli yol WP-CLI'ın search-replace komutudur. WP-CLI belgesine göre komut PHP serileştirilmiş veriyi akıllıca işler ve birincil anahtar değerlerini değiştirmez. Düz SQL REPLACE ise serileştirilmiş veriyi bozabilir, bu yüzden onu önermiyoruz.

Önce veritabanı yedeği alın, ardından değişikliği simüle edin. Aşağıdaki örnekte example.com yerine kendi alan adınızı yazarsınız. Komutları sunucuya SSH ile bağlanıp WordPress klasöründe çalıştırırsınız.

wp db export yedek-oncesi.sql
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

İlk komut yedeği dosyaya yazar. İkinci komut --dry-run ile raporu gösterir ama veritabanına kaydetmez. Rapor beklediğiniz sayıda değişiklik gösteriyorsa üçüncü komutu çalıştırırsınız. --skip-columns=guid seçeneği, yazıların kalıcı kimlik adreslerini korur. Bu örnek WP-CLI belgesindeki komut yapısına dayanır.

Alan adının www'li ve www'siz sürümlerini ayrı ayrı değiştirmeniz gerekebilir. Ayrıca tablo öneki farklıysa --all-tables seçeneği kapsamı genişletir. Bu seçenek tüm tablolara dokunur, bu nedenle yalnızca yedeğiniz varsa kullanın.

Eklentiyle mixed content düzeltmek güvenli mi?

Eklentiler kalıcı çözüm değil, hızlı bir yamadır. Bazı eklentiler sayfa çıktısındaki http:// adreslerini her istekte anında https:// ile değiştirir. Bu yaklaşım sorunu gizler, ancak kaynağı düzeltmez. Eklentiyi kaldırdığınızda hata geri döner, üstelik her sayfada küçük bir işlem yükü ekler.

Veritabanı arama-değiştirme eklentileri ise WP-CLI'ın yaptığı işi panelden yapar. Serileştirilmiş veriyi destekleyen birini seçin, işlemden önce de yedek alın. Belirli bir ürünü öne çıkarmıyoruz, çünkü seçim sitenizin yapısına bağlıdır.

Yani en sağlıklı sıra şudur: önce kaynağı düzeltin, sonra CSP başlığını güvenlik ağı olarak ekleyin. Eklentiyi yalnızca geçiş döneminde kullanın.

CSP upgrade-insecure-requests mixed content hatasını nasıl çözer?

upgrade-insecure-requests, tarayıcıya tüm http:// adreslerini https:// gibi ele almasını söyleyen bir Content-Security-Policy yönergesidir. MDN'e göre yönerge, çok sayıda eski güvensiz adresi olan siteler için tasarlanmıştır. Hem kendi alan adınızdaki hem üçüncü taraf alt kaynakları yükseltir. Böylece koddaki adresleri tek tek düzeltmek zorunda kalmazsınız.

Content-Security-Policy: upgrade-insecure-requests;

Başlığı sunucu ayarından ekleyebilirsiniz. HTML içine meta etiketiyle koymak da mümkündür, ancak başlık daha sağlam bir yoldur. Apache'de mod_headers etkinse tek satır yeterlidir. Nginx'te de tek satır yazarsınız. Örnekte yalnızca yönerge değeri gösteriliyor, kendi yapılandırmanıza uyarlayın.

# Apache (mod_headers gerekir)
Header always set Content-Security-Policy "upgrade-insecure-requests"

# Nginx (server bloğu içinde)
add_header Content-Security-Policy "upgrade-insecure-requests" always;

Sınırı bilin: kaynak HTTPS üzerinden gerçekten yoksa istek başarısız olur ve HTTP'ye geri dönülmez. Yönerge ayrıca HSTS'in yerini tutmaz. MDN, üst düzey gezinmede SSL stripping saldırılarını önlemek için Strict-Transport-Security başlığının ayrıca ayarlanmasını önerir. Test için Content-Security-Policy-Report-Only başlığını yanında kullanabilirsiniz.

.htaccess ve sunucu yönlendirmesi mixed content hatasını çözer mü?

Hayır, tek başına çözmez. HTTP'den HTTPS'e yönlendirme, ziyaretçinin sayfaya HTTPS ile girmesini sağlar. Sayfa içindeki http:// kaynak adreslerini ise tarayıcı kendisi değerlendirir. Tarayıcı engellenebilir bir kaynağı sunucuya hiç sormadan engeller. Bu nedenle yönlendirme gereklidir, ama yeterli değildir.

Apache belgeleri, HTTP'den HTTPS'e yönlendirme için ayrı bir HTTP sanal sunucusunda Redirect kullanmayı en temiz yöntem olarak önerir. Sunucu yapılandırmasına erişemiyorsanız .htaccess içinde mod_rewrite alternatifi vardır. Nginx tarafında ise return 301 kullanırsınız.

# Apache sanal sunucu (tercih edilen)
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

# Apache .htaccess alternatifi
RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

# Nginx
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Apache örnekleri resmi belgedeki "Forcing HTTPS" tarifinden gelir. 301 kodu, arama motorlarına HTTPS sürümünün kalıcı adres olduğunu söyler. web.dev de aynı yönde 301 kullanmanızı önerir. Yönlendirme döngüsü yaşarsanız, genellikle CDN ya da proxy arkasında sunucunun HTTPS'i algılayamamasıdır.

Mixed content ile HSTS arasındaki ilişki nedir?

HSTS (HTTP Strict Transport Security), tarayıcıya siteye her zaman HTTPS ile bağlanmasını söyleyen bir yanıt başlığıdır. web.dev'e göre bu başlık, ziyaretçi http:// adresine tıklasa bile HTTPS kullanımını sağlar ve SSL stripping saldırılarını önler. Böylece yönlendirme gecikmesi de azalır.

HSTS karışık içeriği tek başına çözmez, çünkü sayfa içindeki kaynak adreslerini düzeltmez. Ancak üst düzey gezinmeyi güvenceye alır. CSP yükseltmesi alt kaynakları, HSTS ise sayfa girişlerini kapsar. İkisi birbirini tamamlar.

Dikkat edin: HSTS'i açmak geri alması zor bir karardır. Tarayıcı kuralı süre boyunca hatırlar. Kuralı alt alan adlarını da kapsayacak şekilde kurarsanız ve bunlardan biri HTTPS sunmuyorsa ziyaretçi o adrese giremez. Bu yüzden önce kısa bir süreyle deneyin ve tüm alt alan adlarının HTTPS çalıştığından emin olun. Kararsızsanız bu ayarı sağlayıcınıza danışın.

CDN, ters vekil sunucu ve yük dengeleyici arkasında mixed content nasıl çıkar?

CDN ya da yük dengeleyici HTTPS'i sonlandırıp arkadaki sunucuya HTTP ile bağlanıyorsa, uygulama kendini HTTP'de sanabilir. Bu durumda WordPress gibi uygulamalar sayfa adreslerini http:// olarak üretir. Ziyaretçi HTTPS ile gelir, ama içerideki adresler güvensiz çıkar. Karışık içerik de buradan doğar.

WordPress belgesi bu durum için proxy başlığını okuyan bir yapılandırma örneği verir. Sunucu, X-Forwarded-Proto başlığında https görürse uygulamaya HTTPS'te olduğunu söyler. Örneği wp-config.php dosyasına kendi altyapınıza göre uyarlarsınız.

define( 'FORCE_SSL_ADMIN', true );
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

Bu kodu yanlış yere koyarsanız yönetim paneline giremeyebilirsiniz. Dolayısıyla önce dosyanın bir kopyasını alın. CDN'in kendi panelinde HTTPS yönlendirme ve otomatik yeniden yazma seçenekleri olabilir. Seçeneklerin adı sağlayıcıya göre değişir, bu yüzden sağlayıcınızın belgesine bakın.

Harici kaynaklardaki mixed content hatası nasıl çözülür?

Harici kaynaklar sizin elinizde olmadığı için ayrı bir strateji gerekir. Yazı tipi, reklam kodu, widget, gömülü video ve eski ortak bağlantılar bu gruptadır. Önce kaynağın HTTPS sürümü var mı diye adresi https:// ile deneyin. Çoğu sağlayıcı artık HTTPS sunar, bu durumda adresi değiştirmek yeterlidir.

• HTTPS sürümü varsa adresi https:// olarak güncelleyin.
• Gömülü iframe adreslerini sağlayıcının güncel embed kodundan yenileyin.
• HTTPS desteği olmayan kaynağı kaldırın ya da yerine eşdeğerini koyun.
• Lisansı uygunsa dosyayı kendi sunucunuza alıp oradan sunun.

Kaynağın HTTPS sürümü yoksa CSP yükseltmesi de işe yaramaz, çünkü istek başarısız olur. Böyle bir kaynağı sitede tutmak hem güvenlik hem işlev açısından risklidir. Güvenlik tarafında geniş çerçeve için OWASP Top 10 rehberimize göz atabilirsiniz.

E-ticaret sitelerinde mixed content hatası neden daha sık çıkar?

E-ticaret sitelerinde içerik tek yerden gelmez, bu yüzden eski adres kalma ihtimali yüksektir. Ürün görselleri tedarikçi XML dosyasından, açıklamalar toplu içe aktarmadan, bannerlar kampanya araçlarından gelebilir. Her kanal farklı bir adres biçimi taşır. Örneğin içe aktardığınız bir ürün görseli http:// ile kayıtlı olabilir.

Ödeme ve sepet sayfalarında hata daha pahalıdır, çünkü ziyaretçi uyarıyı görünce ödemeden vazgeçebilir. Ödeme sağlayıcısının gömülü formu HTTP ile çağrılıyorsa form hiç yüklenmeyebilir. Bu yüzden sepet, ödeme ve hesap sayfalarını ayrıca test edin.

Hız ve dönüşüm tarafı için e-ticarette sayfa hızı satışları etkiler mi yazımıza bakın. Mağazanızın teknik ve ticari yönünü birlikte ele almak isterseniz e-ticaret danışmanlığı hizmetimiz bu konuları kapsar.

Düzeltmeden sonra mixed content hatasının bittiğini nasıl doğrularsınız?

Düzeltme sonrası doğrulama, yalnızca ana sayfaya bakmak demek değildir. Farklı sayfa türlerini ve farklı cihazları test edin. Önbellek eskiyi göstermeye devam edebilir, bu yüzden her kontrolden önce önbelleği temizleyin. Aşağıdaki listeyi sırayla uygulayın.

1. Site önbelleğini ve CDN önbelleğini temizleyin.
2. Gizli pencerede ana sayfa, bir yazı, bir ürün ve sepet sayfasını açın.
3. Her sayfada Console ve Issues sekmelerinin temiz olduğunu görün.
4. Kilit simgesinin tam göründüğünü doğrulayın.
5. Mobil cihazda en az bir sayfayı yeniden deneyin.
6. Search Console'da HTTPS mülkünü ve sitemap'i kontrol edin.

Arama tarafı için Search Console kullanım rehberimiz raporları nasıl okuyacağınızı gösterir. Kanonik etiketler, iç bağlantılar ve sitemap adresleri de HTTPS olmalıdır. Aksi hâlde arama motoru eski sürümü taramaya devam eder.

Mixed content hatasını ne zaman kendiniz çözmemelisiniz?

Dürüst olalım: bazı durumlarda sorunu hosting sağlayıcınıza ya da deneyimli bir geliştiriciye bırakmak daha akıllıcadır. Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıdaki komutlar resmi belgelere dayanır. Yine de canlı bir sitede yanlış komut ciddi hasara yol açabilir.

• Veritabanı yedeği alamıyorsanız arama-değiştirme yapmayın.
• SSH erişiminiz ve komut deneyiminiz yoksa sağlayıcıdan destek isteyin.
• Paylaşımlı hostingde sunucu başlığını panelden ayarlayamıyorsanız talep açın.
• Ödeme sayfası bozulduysa önce test ortamında deneyin.
• wp-config.php ya da yapılandırma dosyasında neyin değiştiğinden emin değilseniz durun.

Hosting seçimi bu işi kolaylaştırır ya da zorlaştırır. Ayrıntı için web sitesi için hosting nasıl seçilir yazımıza bakın. Güvenlik duvarı kaynaklı engeller için ModSecurity ve 403 hatası yazımız da işe yarar.

Mixed content hatasını önlemek için hangi alışkanlıkları edinmelisiniz?

En ucuz çözüm, sorunu hiç üretmemektir. Yeni içerik eklerken bütün adresleri https:// ile yazın. Aynı alan adındaki kaynaklar için göreli adres kullanabilirsiniz. Ayrıca site taşıma ve tema değişimi gibi büyük işlerden sonra konsol kontrolünü rutine bağlayın.

• Yeni içeriği yayımlamadan önce önizlemede konsolu kontrol edin.
• Dışarıdan aldığınız embed kodlarının HTTPS sürümünü seçin.
• CSP upgrade-insecure-requests başlığını güvenlik ağı olarak tutun.
• Report-Only modunda ihlal raporu toplamayı düşünün.
• Test sitesinde yapılan değişimi canlıya almadan adresleri gözden geçirin.

Teknik temizlik, SEO ve tasarım kararlarını birlikte yönetmek isterseniz SEO danışmanlığı ve web tasarım hizmetlerimiz bu çerçevede çalışır. Konu uzmanlık gerektirdiğinde ekibimiz sürece destek verir. Kaynaklar için MDN'in karışık içerik belgesi ve web.dev'in mixed content rehberi iyi başlangıçtır. Bu yazı hukuki ya da kurumsal güvenlik danışmanlığı yerine geçmez.