WordPress mixed content hatası, SSL sertifikası aktif olan ve HTTPS üzerinden açılan bir WordPress sayfasının bazı görsel, CSS, JavaScript, yazı tipi veya diğer kaynakları güvenli olmayan HTTP bağlantılarıyla çağırması durumudur.
WordPress sitenizde SSL sertifikası
kurulmuş, adres çubuğunda
https:// bulunuyor ve
hosting panelinde SSL aktif
görünüyor olabilir.
Buna rağmen tarayıcıda güvenlik uyarısı alıyor, bazı görsellerin açılmadığını fark ediyor veya tasarım dosyalarının yüklenmediğini görüyorsanız sorun yalnızca sertifikadan kaynaklanmayabilir.
Eski HTTP görsel adresleri, veritabanındaki bağlantılar, WordPress URL ayarları, tema ve eklenti çıktıları, üçüncü taraf kaynaklar ve CDN yapılandırmaları bu soruna neden olabilir.
Bu rehberde WordPress mixed content hatasının 9 olası nedenini, Chrome geliştirici araçlarıyla nasıl tespit edileceğini ve hatanın kaynağına göre nasıl düzeltileceğini adım adım inceliyoruz.
WordPress SSL Aktif Ama Güvenli Değil Görünüyorsa Ne Yapılmalı?
Kısa cevap: İlk olarak tarayıcı geliştirici araçlarında Console ve Network bölümlerini açarak HTTP üzerinden yüklenmeye çalışılan kaynakları bulun.
Ardından WordPress yönetim panelindeki Ayarlar → Genel bölümünde WordPress Adresi ve Site Adresi değerlerini kontrol edin.
Eski HTTP bağlantıları görsellerde, CSS dosyalarında, tema ayarlarında veya veritabanında bulunuyorsa gerçek kaynaklarını tespit ederek HTTPS adresleriyle düzeltin.
Son aşamada önbelleği kontrollü temizleyin, sorunlu sayfayı yeniden açın ve güvenli olmayan kaynak isteklerinin devam edip etmediğini kontrol edin.
Tarayıcıda doğrudan “Bağlantınız gizli değil” veya bir sertifika doğrulama hatası görünüyorsa bu durum yalnızca mixed content olarak değerlendirilmemelidir.
Sertifika süresi, alan adı eşleşmesi, sertifika zinciri ve sunucunun TLS yapılandırması ayrıca incelenmelidir.
WordPress Mixed Content Hatası Nedir?
Mixed content, Türkçede karma içerik olarak ifade edilir. HTTPS üzerinden yüklenen bir web sayfasının HTTP üzerinden alt kaynak istemesiyle meydana gelir.
Örneğin WordPress sayfasının adresi güvenli olsa bile sayfadaki görselin HTTP adresinden çağrılması karma içerik oluşturabilir.
Mixed content kod örneği
Aşağıdaki örnekte sayfa HTTPS ile açılırken görsel HTTP üzerinden çağrılmaktadır:
<img
src="http://example.com/gorsel.jpg"
alt="Örnek görsel"
>Kaynak aynı sunucuda HTTPS üzerinden kullanılabiliyorsa adres uygun şekilde değiştirilebilir:
<img
src="https://example.com/gorsel.jpg"
alt="Örnek görsel"
>Ancak URL’yi yalnızca metin olarak değiştirmek yeterli değildir. İlgili dosyanın yeni HTTPS adresinde gerçekten erişilebilir olduğu doğrulanmalıdır.
Mixed content neden önemlidir?
Güvenli olmayan kaynakların yüklenmesi, veri bütünlüğü açısından risk oluşturabilir. Özellikle sayfada çalıştırılan JavaScript gibi kaynaklar kötü niyetli değişikliklere karşı daha hassastır.
Modern tarayıcılar bu nedenle bazı kaynak isteklerini otomatik HTTPS’e yükseltir, bazılarını ise engeller.
Ayrıntılı açıklama için MDN Mixed Content güvenlik belgesini inceleyebilirsiniz.
SSL Sertifikası Hatası ile WordPress Mixed Content Hatası Aynı mı?
Hayır. İki sorun benzer güvenlik belirtileri oluşturabilse de teknik olarak farklıdır.
| Özellik | Mixed content | Sertifika sorunu |
|---|---|---|
| Sayfanın HTTPS bağlantısı | Genellikle kurulmuştur | TLS doğrulaması başarısız olabilir |
| Temel neden | HTTP alt kaynaklar | Geçersiz veya uyumsuz sertifika |
| İlk kontrol | Console ve Network | Sertifika ayrıntıları |
| Örnek belirti | Engellenen HTTP CSS veya JavaScript | Alan adı eşleşmiyor |
| Çözüm | Kaynak URL ve entegrasyon düzeltmesi | Sertifika ve sunucu TLS düzeltmesi |
WordPress Mixed Content Hatası Chrome’da Nasıl Tespit Edilir?
Karma içerik sorununu çözmenin ilk adımı, hangi kaynağın HTTP üzerinden yüklendiğini bulmaktır.
Google Chrome geliştirici araçları bu amaçla kullanılabilir.
Chrome Console ile kontrol
- Hatalı sayfayı açın. SSL aktif olmasına rağmen güvenlik sorunu yaşadığınız sayfaya gidin.
- Geliştirici araçlarını açın. Masaüstünde sağ tıklayıp İncele seçeneğini kullanabilirsiniz.
- Console bölümüne geçin. Sayfayı yeniden yükleyin ve hata mesajlarını inceleyin.
- Mixed Content uyarısını bulun. HTTP üzerinden çağrılmaya çalışılan kaynağın tam adresini kaydedin.
- Network bölümünü inceleyin. Engellenen, otomatik HTTPS’e yükseltilen veya başarısız olan istekleri karşılaştırın.
- Kaynağın nereden geldiğini belirleyin. Sayfa içeriği, tema, eklenti, CSS dosyası veya üçüncü taraf kodlardan hangisinin isteği oluşturduğunu bulun.
Örnek tarayıcı uyarısı
Mixed Content:
The page was loaded over HTTPS,
but requested an insecure resource:
http://example.com/uploads/banner.jpgBu açıklayıcı örnekte sorun, görselin HTTP adresi üzerinden çağrılmasıdır.
Sayfadaki normal bir bağlantının başka bir HTTP sayfasına gitmesi, görsel veya JavaScript gibi HTTP alt kaynağın yüklenmesiyle aynı şey değildir.
Gerçek mixed content sorununu değerlendirirken tarayıcının oluşturduğu alt kaynak isteklerini esas alın.
Google’ın mixed content sorununu bulma ve düzeltme rehberi geliştirici araçlarıyla hata kaynağının nasıl araştırılacağını anlatmaktadır.
WordPress Mixed Content Hatasının 9 Olası Nedeni
WordPress Adresi veya Site Adresi Hâlâ HTTP Kullanıyor
WordPress’te SSL sertifikası kurulmuş olsa bile site URL ayarları eski HTTP adresini kullanıyor olabilir.
Bu durumda WordPress bazı kaynak veya bağlantıları güvenli olmayan adreslerle oluşturabilir.
Kontrol edilecek ayarlar
- WordPress yönetim paneline girin.
- Ayarlar → Genel bölümünü açın.
- WordPress Adresi (URL) alanını kontrol edin.
- Site Adresi (URL) alanını kontrol edin.
- Her iki adresin sitenin gerçek kurulum yapısıyla uyumlu olduğunu doğrulayın.
http://example.com
https://example.com
İki adresin birbirinden farklı olabileceği özel WordPress kurulumları bulunduğunu unutmayın. Amaç her iki alanı rastgele aynı yapmak değil, mevcut kurulumun doğru HTTPS yapılandırmasını belirlemektir.
wp-config.php
üzerinden yapılan
tanımlamaları
ve varsa proxy
yapılandırmasını
kontrol edin.WordPress’in resmi site adresi ve taşıma rehberini inceleyebilirsiniz.
Eski Yazı ve Sayfalardaki Görseller HTTP Üzerinden Çağrılıyor
WordPress sitesi geçmişte HTTP ile kullanılmışsa eski blog yazılarındaki görsel bağlantıları HTTP olarak kaydedilmiş olabilir.
Siteye sonradan SSL kurulması, içeriklerde kaydedilmiş bütün bağlantıların otomatik olarak düzeleceği anlamına gelmez.
Hangi alanlarda görülür?
- Eski blog yazılarındaki görseller
- Öne çıkan görseller
- Gutenberg görsel blokları
- Özel HTML blokları
- Eski galeri ve slider içerikleri
- Manuel eklenen arka plan görselleri
Örnek problem
<img
src="http://example.com/wp-content/uploads/urun.webp"
alt="Ürün görseli"
>Bu görselin gerçek HTTPS adresinde bulunması durumunda kaynak adresi güvenli bağlantıyla güncellenebilir.
Çözüm
Tarayıcı Console bölümünde görünen kaynak adresini ilgili WordPress yazısı veya sayfasıyla eşleştirin.
İçeriğin gerçek kaynağındaki eski HTTP adresini düzeltin ve sayfanın yeniden oluşturulmasını kontrol edin.
CSS, JavaScript veya Yazı Tipleri HTTP Adreslerinden Yükleniyor
Mixed content sorunlarının en önemli türlerinden biri, sayfanın çalışmasını veya görünümünü etkileyen kaynakların HTTP üzerinden istenmesidir.
Tarayıcı, HTTP üzerinden çağrılan aktif içeriklerin bir bölümünü güvenlik nedeniyle engelleyebilir.
Örnek hatalı CSS bağlantısı
<link
rel="stylesheet"
href="http://example.com/assets/site.css"
>Örnek hatalı JavaScript bağlantısı
<script
src="http://example.com/assets/app.js"
></script>
Benzer sorun
CSS içerisindeki
url()
alanları ve
@font-face
tanımlarında
da görülebilir.
Kontrol listesi
- Console’da engellenen dosyanın adresini bulun.
- Kaynağın tema veya eklentiye ait olup olmadığını belirleyin.
- Dosyanın HTTPS üzerinden erişilebilir olduğunu doğrulayın.
- Hatalı URL’nin gerçek kaynağını güncelleyin.
- Dosyanın yeniden yüklenip yüklenmediğini test edin.
HTTP JavaScript dosyalarını çalıştırmak için tarayıcı güvenliğini devre dışı bırakmayın. Sorunu güvenli kaynak bağlantısı üzerinden çözün.
WordPress Teması veya Sayfa Oluşturucusu Eski HTTP Adreslerini Kullanıyor
WordPress tema ayarlarında veya sayfa oluşturucularında bazı URL’ler doğrudan kaydedilmiş olabilir.
Özellikle HTTPS’e geçişten önce oluşturulmuş tasarımlarda arka plan görselleri, özel CSS kodları ve widget ayarları eski adresleri kullanabilir.
Sorunun bulunabileceği yerler
- Tema özelleştirme alanları
- Özel CSS düzenlemeleri
- Üst bilgi ve alt bilgi alanları
- Sayfa oluşturucunun görsel bileşenleri
- Widget ve blok ayarları
- Eski tasarım şablonları
Örnek CSS arka plan hatası
.ornek-alan{
background-image:
url("http://example.com/uploads/arka-plan.jpg");
}Buradaki kaynak, gerçek HTTPS adresinde erişilebilir durumdaysa URL güvenli bağlantıya çevrilebilir.
Hatalı kaynağın tema ayarlarından mı yoksa sayfa oluşturucunun kendi kayıt alanlarından mı geldiğini belirleyin.
Değişikliği ilgili sistemin desteklediği yöntemle yapın. Özellikle otomatik üretilen CSS dosyaları varsa ilgili aracın yeniden oluşturma mekanizmasını kullanın.
WordPress tasarım ve geliştirme hizmetlerimiz hakkında WordPress web tasarım hizmetleri sayfamızı inceleyebilirsiniz.
WordPress Eklentisi veya Üçüncü Taraf Bileşen HTTP Kaynağı Ekliyor
Bazı WordPress eklentileri kendi JavaScript, CSS, görsel veya iframe kaynaklarını sayfaya ekler.
Bu bağlantıların HTTP üzerinden oluşturulması karma içerik hatasına neden olabilir.
Hangi tür eklentiler araştırılmalı?
- Eski slider ve galeri eklentileri
- Form ve rezervasyon araçları
- Harita veya iframe bileşenleri
- Canlı destek ve sohbet araçları
- Reklam ve analiz entegrasyonları
- Özel kod ekleme eklentileri
Örneğin üçüncü taraf bir sohbet aracının betiği HTTP üzerinden çağrılıyorsa tarayıcı bu isteği engelleyebilir.
Hatalı eklenti nasıl belirlenir?
- Console’da HTTP kaynağının adresini bulun.
- Dosya adının hangi eklentiye ait olduğunu araştırın.
- Eklenti ayarlarında özel kaynak URL’si bulunup bulunmadığını kontrol edin.
- Desteklenen güncel HTTPS bağlantısını doğrulayın.
- Gerekirse test ortamında eklenti davranışını karşılaştırın.
WordPress Veritabanında Eski HTTP Adresleri Bulunuyor
WordPress sitesinde HTTP’den HTTPS’e geçiş yapıldığında eski adresler veritabanında kalmış olabilir.
Bu URL’ler yazı içeriği, tema ayarları, özel alanlar veya eklenti verileri içerisinde bulunabilir.
WordPress bazı eski site adreslerini otomatik olarak güvenli biçime çevirebilen mekanizmalara sahiptir. Ancak bu, bütün tema ve eklenti verilerindeki HTTP bağlantılarının kesinlikle düzeltileceği anlamına gelmez.
Neden doğrudan SQL ile değiştirilmemeli?
WordPress veritabanında bazı eklentiler verileri PHP serileştirilmiş biçimde saklayabilir.
Rastgele metin değiştirme işlemi bu veri yapılarını bozabilir.
Bütün veritabanında
kontrolsüz şekilde
http://
değerini
https://
ile değiştirmeyin.
Dış sitelere ait bağlantılar veya HTTPS desteği olmayan kaynaklar bulunabilir. Ayrıca serileştirilmiş veriler zarar görebilir.
Çözüm
Önce tam yedek oluşturun. Ardından sadece kendi eski alan adınızla ilgili URL’leri tespit edin.
Serileştirilmiş veriyi koruyabilen WordPress uyumlu arama-değiştirme yöntemlerini tercih edin.
İşlem sonrası site URL ayarlarını, görselleri, bağlantıları ve kritik eklentileri kontrol edin.
WordPress’in resmi taşıma ve veritabanı yönetimi rehberi bu işlemlerin dikkatli yapılması gerektiğini vurgular.
CDN veya WordPress Önbelleği Eski HTTP Bağlantılarını Sunuyor
WordPress sitesindeki eski HTTP adresleri düzeltilmiş olsa bile önbellek sistemleri eski HTML veya CSS çıktısını sunuyor olabilir.
Böylece site yöneticisi yeni sürümü görürken diğer ziyaretçiler eski bağlantıları kullanabilir.
Kontrol edilecek önbellek katmanları
- WordPress sayfa önbelleği
- CSS ve JavaScript optimizasyon önbelleği
- Sunucu tarafı önbellek
- CDN edge önbelleği
- Tarayıcı önbelleği
LiteSpeed Cache kullanılıyorsa
LiteSpeed Cache üzerinden üretilmiş eski sayfa veya CSS çıktıları bulunabilir.
Hatanın önbellekle ilişkili olduğunu doğruladıktan sonra ilgili katmanı kontrollü temizleyin.
Ancak LiteSpeed Cache’i tamamen kapatmak her mixed content hatası için gerekli değildir.
Önce kaynak URL’yi düzeltin. Ardından sayfa, sunucu ve gerekiyorsa CDN önbelleğini temizleyerek yeni HTML çıktısını kontrol edin.
Sadece önbelleği temizleyip hatalı HTTP adresini düzeltmemek kalıcı çözüm sağlamaz.
WordPress performans ayarlarının genel işleyişini öğrenmek için site hız testi rehberimizi inceleyebilirsiniz.
Reverse Proxy veya CDN Nedeniyle WordPress HTTPS Bağlantısını Yanlış Algılıyor
Bazı hosting ve CDN yapılandırmalarında ziyaretçi siteye HTTPS üzerinden bağlanırken WordPress’in çalıştığı arka sunucuya bağlantı farklı şekilde iletilebilir.
Sunucu, gelen isteği HTTP gibi algılarsa bazı URL’ler yanlış protokolle oluşturulabilir.
Örnek senaryo
Tarayıcıdan CDN’ye HTTPS bağlantısı kuruluyor.
WordPress, gelen isteği güvenli olmayan HTTP gibi algılayabiliyor.
Kontrol edilecek alanlar
- CDN ile origin sunucu arasındaki TLS durumu
- Güvenilir proxy başlıklarının işlenmesi
- WordPress’in HTTPS algılama davranışı
- Sunucu yönlendirme kuralları
- www ve www olmayan alan adı yönlendirmeleri
Çözüm
Hosting veya sunucu yönetiminde HTTPS algılamasının doğru yapıldığını kontrol edin.
CDN kullanılıyorsa ziyaretçi bağlantısı ve arka sunucu bağlantısının güvenlik ayarlarını birlikte değerlendirin.
Harici Görsel, iframe veya API Kaynağı HTTPS Desteklemiyor
Bazı WordPress siteleri farklı hizmetlerden görsel, iframe, video, harita veya API verisi alır.
Bu kaynakların eski HTTP adresleri kullanılması karma içerik uyarısı veya engellenen kaynak hatası oluşturabilir.
Örnek sorunlu iframe
<iframe
src="http://external.example/map"
title="Örnek içerik"
></iframe>
Böyle bir
kaynağın
HTTPS desteği
bulunmuyorsa
yalnızca URL’nin
başına
https://
yazmak
sorunu çözmez.
Çözüm seçenekleri
- Hizmet sağlayıcının resmi HTTPS adresini kullanın.
- Desteklenen güncel embed kodunu kontrol edin.
- Güvenli bağlantı sunulmuyorsa kaynağı kaldırmayı değerlendirin.
- Gerekli izinlerle güvenli biçimde barındırılabilecek içerikleri kendi sunucunuzdan sunmayı değerlendirin.
- Kaynağın işlevini koruyan güvenli bir alternatif kullanın.
Tarayıcıda güvensiz içerik yükleme izni vererek hatayı geçici olarak gizlemek kalıcı çözüm değildir.
Ayrıca başka bir sitenin HTTPS desteklemediği kaynağını gelişigüzel proxy üzerinden sunmak, güvenlik ve kullanım hakkı riskleri oluşturabilir.
WordPress Mixed Content Hatası: 9 Neden ve Çözüm Tablosu
Aşağıdaki tablo, sorunun kaynağını belirlemek ve ilk müdahaleyi seçmek için hazırlanmıştır.
| Olası neden | Kontrol | Çözüm |
|---|---|---|
| WordPress URL ayarları | Ayarlar → Genel | Kuruluma uygun HTTPS adresi |
| Eski görseller | Görsel src adresleri | Kaynak görsel URL’sini düzeltme |
| HTTP CSS / JavaScript | Console ve Network | Güvenli kaynak kullanımı |
| Tema veya sayfa oluşturucu | Tema ve özel CSS | Eski URL’leri düzeltme |
| Eklenti veya harici kod | Eklenti kaynakları | Desteklenen HTTPS entegrasyonu |
| Veritabanı HTTP kayıtları | Eski alan adı URL’leri | Yedekli, güvenli arama-değiştirme |
| Önbellek veya CDN | Sunulan HTML / CSS | Kaynağı düzeltip önbelleği yenileme |
| HTTPS algılama sorunu | Proxy ve sunucu ayarları | Güvenilir HTTPS yapılandırması |
| Harici kaynak HTTP | iframe / API / medya | Güvenli alternatif veya resmi HTTPS URL |
WordPress Mixed Content Hatası Adım Adım Nasıl Düzeltilir?
Hatanın kaynağını bulmadan bütün SSL eklentilerini değiştirmek veya veritabanında toplu düzenleme yapmak doğru olmayabilir.
Bunun yerine aşağıdaki kontrol sırasını izleyin.
- SSL sertifikasını doğrulayın. Sertifikanın geçerli olduğundan ve doğru alan adı için sunulduğundan emin olun.
- Hatalı sayfayı belirleyin. Sorunun tüm sitede mi yoksa belirli sayfalarda mı görüldüğünü kontrol edin.
- Console uyarılarını inceleyin. Güvenli olmayan HTTP kaynak adreslerini kaydedin.
- WordPress URL ayarlarını kontrol edin. WordPress ve site adreslerinin kurulumla uyumlu HTTPS yapılandırmasını doğrulayın.
- Kaynak dosyayı bulun. Hatalı adresin görsel, tema, eklenti, CSS veya veritabanı kaynaklı olduğunu belirleyin.
- Güvenli bağlantıyı doğrulayın. Dosyanın HTTPS üzerinden gerçekten açıldığını kontrol edin.
- Kaynakta düzeltme yapın. İlgili WordPress ayarı, içerik veya entegrasyon üzerinden eski bağlantıyı güncelleyin.
- Önbellek katmanlarını yenileyin. Gerekliyse WordPress, CDN ve tarayıcı önbelleğini kontrollü temizleyin.
- Canlı siteyi yeniden test edin. Console ve Network üzerinden karma içerik uyarılarının devam edip etmediğini doğrulayın.
Her düzenlemede aynı anda birçok farklı ayarı değiştirmek yerine, öncelikle tek bir hatalı kaynak üzerinde neden ve çözüm ilişkisini doğrulayın.
Sonuç başarılıysa aynı sorunu oluşturan diğer kaynaklarda benzer düzeltmeyi uygulayın.
WordPress Veritabanındaki HTTP Adresleri HTTPS’e Nasıl Çevrilir?
HTTPS geçişi sırasında eski HTTP adreslerini düzeltmek için WordPress uyumlu arama-değiştirme yöntemleri kullanılabilir.
Ancak bu işlem dikkatli planlanmalıdır.
1. Önce tam yedek alın
Veritabanı ve WordPress dosyalarının geri yüklenebilir yedeğini oluşturun.
2. Eski URL’yi kesin olarak belirleyin
Örneğin kendi sitenizde eski alan adı şu biçimdeyse:
http://example.comyeni hedef adresiniz şu olabilir:
https://example.comBunlar temsilî adreslerdir. Gerçek işlemde mevcut alan adınızı kullanın.
3. Önce deneme çalıştırın
WP-CLI erişimi bulunan ve doğru yapılandırılmış WordPress kurulumlarında, örneğin aşağıdaki komutla yalnızca değişikliklerin önizlemesi yapılabilir:
wp search-replace \
'http://example.com' \
'https://example.com' \
--all-tables-with-prefix \
--dry-run
--dry-run
seçeneği değişiklikleri
uygulamak yerine
deneme sonucu
oluşturmak
için kullanılır.
4. Değişiklik kapsamını değerlendirin
Komutun hangi tablolarda ve kaç alanda eşleşme bulduğunu inceleyin.
WordPress’in dışında kalan tablolar veya özel entegrasyon verileri varsa bunları ayrıca değerlendirin.
Bu bölümdeki örnek komut yalnızca deneme amacıyla verilmiştir.
Gerçek değiştirme işlemi öncesinde geri yükleme planı, test ortamı ve serileştirilmiş veri desteği kontrol edilmelidir.
WP-CLI komut seçenekleri için WordPress resmi WP-CLI search-replace dokümantasyonunu inceleyebilirsiniz.
HTTPS Yönlendirmesi ve Content Security Policy Mixed Content Hatasını Çözer mi?
HTTPS yönlendirmesi, HTTP üzerinden gelen sayfa isteklerinin güvenli adrese aktarılmasını sağlayabilir.
Ancak ana sayfanın HTTPS’e yönlenmesi, içindeki bütün kaynak adreslerinin doğru olduğu anlamına gelmez.
301 yönlendirmesi neden tek başına yeterli değil?
Sayfanın HTTP sürümünden HTTPS sürümüne yönlenmesi önemlidir.
Fakat HTML içinde hâlâ HTTP JavaScript dosyası çağrılıyorsa tarayıcı isteği güvenlik kurallarına göre engelleyebilir.
CSP upgrade-insecure-requests nedir?
Content Security
Policy’nin
upgrade-insecure-requests
yönergesi,
güvenli olmayan
belirli alt
kaynak isteklerinin
HTTPS’e
yükseltilmesini
sağlayabilir.
Content-Security-Policy: upgrade-insecure-requestsBu örnek bir HTTP yanıt başlığı yönergesidir; WordPress makale gövdesine yapıştırılarak uygulanmaz.
Ayrıca bu yöntemin çalışması için hedef kaynakların HTTPS üzerinden erişilebilir olması gerekir.
Güvenlik yönergeleri bazı HTTP kaynaklarını yükseltmeye yardımcı olsa bile hatalı adreslerin asıl kaynağını düzeltmek daha doğru yaklaşımdır.
Ayrıca eski
block-all-mixed-content
yönergesi
güncel standartlarda
kullanımdan
kaldırılmıştır.
Yeni kurulumlarda
eski yönergelere
dayanmayın.
Teknik ayrıntılar için MDN Mixed Content dokümantasyonunu inceleyebilirsiniz.
WordPress Mixed Content Hatası SEO’yu Etkiler mi?
HTTPS, web sitesi güvenliği açısından önemli bir altyapı unsurudur.
Mixed content sorunu nedeniyle görseller, CSS veya JavaScript dosyalarının yüklenmemesi kullanıcı deneyimini etkileyebilir.
Örneğin önemli bir ürün görseli açılmıyor veya sayfanın etkileşimli bileşeni çalışmıyorsa kullanıcı sayfadan beklediği işlevi alamayabilir.
Ancak mixed content hatasının her durumda doğrudan belirli bir sıralama kaybına neden olacağı söylenemez.
Sorunun etkisi yüklenemeyen kaynağın sayfa işlevi, içerik sunumu ve erişilebilirlik üzerindeki önemine bağlıdır.
Teknik SEO açısından diğer kontrol alanlarını görmek için teknik SEO kontrol listemizi inceleyebilirsiniz.
Site güvenliğiyle performans sorunlarını birbirinden ayırmak için Core Web Vitals rehberimiz de yardımcı olabilir.
WordPress HTTPS Geçişi Sonrası Güvenlik Kontrol Listesi
Mixed content hatasını düzelttikten sonra yalnızca ana sayfayı değil, farklı sayfa türlerini de kontrol edin.
- SSL sertifikası geçerli ve doğru alan adına ait mi?
- WordPress Adresi ve Site Adresi HTTPS yapılandırmasına uygun mu?
- Ana sayfada mixed content uyarısı bulunuyor mu?
- Blog yazılarındaki görseller HTTPS üzerinden yükleniyor mu?
- CSS ve JavaScript dosyalarında engellenen HTTP isteği var mı?
- Tema ve sayfa oluşturucunun eski URL’leri düzeltildi mi?
- Harici iframe ve API kaynakları güvenli bağlantı kullanıyor mu?
- WordPress eklentilerinin yüklediği kaynaklar kontrol edildi mi?
- Veritabanında kalan HTTP adresleri güvenli biçimde incelendi mi?
- Gerekli önbellek katmanları yenilendi mi?
- Mobil ve masaüstünde kritik sayfalar test edildi mi?
- Form, sepet ve ödeme işlemleri beklendiği gibi çalışıyor mu?
- HTTP sayfa adresleri uygun HTTPS adreslerine yönleniyor mu?
- Tarayıcı Console ve Network kontrolleri tekrar yapıldı mı?
WordPress ve Teknik Site Yönetimiyle İlgili Diğer Rehberler
Mixed content hatasıyla karıştırılabilen farklı WordPress ve teknik SEO problemlerini aşağıdaki rehberlerde inceleyebilirsiniz.
WordPress Mobil Görünüm Bozukluğu
Mobilde kayma, bozuk yerleşim ve masaüstü ile mobil arasındaki görüntü farklılıkları.
Mobil görünüm rehberini okuyunWordPress İletişim Formu Mail Gelmiyor
Form gönderildikten sonra e-posta bildirimlerinin ulaşmaması problemini inceleyin.
Form e-posta sorunları rehberiWeb Sitesi Hızlandırma Rehberi
Önbellek, kaynak yükleme ve web performansı hakkında bilgi alın.
Site hızlandırma rehberiTeknik SEO Kontrol Listesi
İndeksleme, site mimarisi ve diğer teknik SEO kontrollerini değerlendirin.
Teknik SEO rehberiCore Web Vitals
Sayfa deneyimi, yükleme performansı ve etkileşim ölçütleri hakkında bilgi edinin.
Core Web Vitals rehberiWeb Sitesi Yenilenince SEO Sıralamaları
Web sitesi taşıma veya yenileme sonrasında organik görünürlük kayıplarını inceleyin.
Site yenileme SEO rehberiBenzer içerikler için Web Tasarım ve Site Yönetimi kategorimizi ziyaret edebilirsiniz.
WordPress Mixed Content Hatası Hakkında Sık Sorulan Sorular
WordPress mixed content hatası nedir?
HTTPS üzerinden açılan WordPress sayfasının HTTP üzerinden görsel, CSS, JavaScript veya başka alt kaynaklar çağırmasıdır. Modern tarayıcılar bu istekleri güvenlik kurallarına göre yükseltebilir veya engelleyebilir.
SSL sertifikası aktif ama site neden güvenli değil görünüyor?
Sayfada mixed content bulunabilir. Ancak sertifika süresi, alan adı eşleşmesi veya TLS yapılandırması da soruna neden olabilir. Önce tarayıcının gerçek hata mesajını inceleyin.
WordPress mixed content hatası nasıl bulunur?
Sorunlu sayfayı Chrome’da açın. Geliştirici araçlarındaki Console ve Network bölümlerini inceleyin. HTTP üzerinden çağrılan veya engellenen kaynakları bulun.
Mixed content hatası SSL yenilenince düzelir mi?
SSL sertifikası zaten geçerliyse yalnızca sertifikayı yenilemek HTTP kaynak bağlantılarını düzeltmez. Mixed content kaynaklarının ayrı ayrı bulunması gerekir.
WordPress’te HTTP adreslerini HTTPS yapmak yeterli mi?
Kaynakların gerçek HTTPS adreslerinde erişilebilir olması ve ilgili bağlantıların doğru kaynaktan güncellenmesi gerekir. Özellikle veritabanı, tema, eklenti ve CDN kaynaklı kayıtlar ayrıca kontrol edilmelidir.
LiteSpeed Cache mixed content hatasına neden olur mu?
Eski HTTP bağlantılarını içeren önbellek çıktıları veya belirli optimizasyon davranışları sorunun devam etmesine katkıda bulunabilir. Ancak her mixed content hatasının nedeni LiteSpeed Cache değildir.
Mixed content hatası görsellerin açılmamasına neden olur mu?
Evet. Bazı görseller otomatik olarak HTTPS’e yükseltilirken HTTPS üzerinden erişilemeyen veya belirli güvenlik kurallarına takılan kaynaklar yüklenmeyebilir.
WordPress mixed content hatası SEO’yu etkiler mi?
Karma içerik nedeniyle önemli sayfa kaynaklarının yüklenmemesi kullanıcı deneyimini ve sayfa işlevlerini etkileyebilir. Ancak her mixed content hatasının doğrudan belirli bir sıralama kaybı yaratacağı garanti değildir.
Mixed content hatası sadece bazı sayfalarda olabilir mi?
Evet. Örneğin yalnızca bir blog yazısında HTTP görsel bulunuyorsa sorun o sayfada görülebilir. Diğer sayfaların doğru çalışması bütün sitenin hatasız olduğu anlamına gelmez.
SSL eklentisi kurmak mixed content sorununu çözer mi?
Bazı eklentiler belirli URL düzeltme işlemlerini kolaylaştırabilir. Ancak her hatayı otomatik çözecekleri garanti değildir. Öncelik hatalı kaynağı tespit edip kalıcı olarak düzeltmektir.
HTTPS yönlendirmesi mixed content sorununu tamamen çözer mi?
Her zaman hayır. HTTP sayfa adreslerinin HTTPS’e yönlenmesi önemlidir, fakat sayfanın içinde HTTP alt kaynak çağrıları kalmış olabilir.
WordPress’te mixed content düzeldikten sonra ne kontrol edilmeli?
Farklı sayfa türlerinde Console ve Network kontrollerini tekrarlayın. Görseller, CSS, JavaScript, formlar, sepet ve ödeme gibi kritik işlevleri test edin.
Sonuç: SSL Sertifikası Aktifse Önce HTTP Kaynaklarını Kontrol Edin
WordPress mixed content hatası, SSL sertifikası aktif olmasına rağmen site içindeki bazı kaynakların HTTP üzerinden çağrılmasıyla oluşabilir.
Sorunu çözmek için önce tarayıcının gösterdiği gerçek hata mesajını inceleyin.
Ardından WordPress URL ayarları, eski görseller, CSS ve JavaScript dosyaları, tema, eklenti, veritabanı, CDN ve harici kaynak bağlantılarını kontrol edin.
Kalıcı çözüm, hatalı HTTP bağlantısını oluşturan kaynağın düzeltilmesine dayanır.
Düzenleme sonrasında önbelleği yenileyin ve farklı sayfalarda güvenli kaynak yüklemelerini yeniden test edin.
WordPress Sitenizin Teknik Altyapısını Geliştirin
WordPress sitelerinde güvenli kaynak kullanımı, doğru teknik yapılandırma ve düzenli bakım, istikrarlı bir web deneyimi oluşturulmasına yardımcı olur.
Zeymedya Reklam Ajansı, WordPress web tasarım, teknik SEO ve dönüşüm optimizasyonu hizmetleri sunmaktadır.
Web sitesi geliştirme çalışmalarımızı öğrenmek için WordPress web tasarım hizmetleri sayfamızı inceleyebilirsiniz.
Organik görünürlüğe yönelik teknik çalışmalar için SEO hizmetlerimizi ziyaret edebilirsiniz.
Ajansımızın diğer hizmetleri hakkında bilgi için tüm hizmetlerimizi görüntüleyebilirsiniz.
Zeymedya ile İletişime GeçinWordPress Mixed Content Hatası İçin Resmi Teknik Kaynaklar
Bu içerikte HTTPS karma içerik davranışı, WordPress URL yapılandırması ve güvenli kaynak yükleme açıklamaları aşağıdaki resmi teknik belgeler esas alınarak hazırlanmıştır.
-
MDN – Mixed Content
Mixed content tanımı, otomatik HTTPS yükseltmesi, engellenen kaynak türleri ve güvenlik davranışları.
-
Google web.dev – Fixing Mixed Content
Chrome geliştirici araçlarıyla karma içerik tespiti ve kaynak URL düzeltmeleri.
-
Google web.dev – What Is Mixed Content?
HTTP alt kaynaklarının oluşturduğu güvenlik riskleri ve tarayıcıların davranışı.
-
WordPress Developer – Migrating WordPress
WordPress ve Site Adresi ayarları, alan adı taşıma ve veritabanı işlemleri.
-
WordPress Developer – wp_update_urls_to_https()
WordPress adres ayarlarının HTTPS’e geçirilmesine ilişkin çekirdek işlevi.
-
WordPress Developer – wp_should_replace_insecure_home_url()
WordPress’in eski HTTP site adresleri için otomatik değiştirme koşulları.
-
WordPress WP-CLI – Search Replace
Veritabanında kontrollü arama-değiştirme, dry-run ve komut seçenekleri.
-
WordPress.com – HTTPS and SSL
SSL etkin sitelerde güvenli olmayan kaynakların tespiti ve karma içerik açıklamaları.
Güncellik notu: Tarayıcı güvenlik davranışları, WordPress sürümleri ve hosting altyapıları zaman içerisinde değişebilir. Canlı site değişikliklerinden önce güncel resmi belgeleri kontrol edin.
