Hızlı Cevap
Karışık içerik uyarıları şudur: HTTPS bir sayfanın HTTP kaynak çağırmasıdır. Doğrudan ceza gibi çalışmaz; ancak script, CSS, iframe veya görsel çağrıları render’ı, güven sinyalini ve kullanıcı davranışını bozarsa tarama, indeksleme ve dönüşüm üzerinden dolaylı SEO kaybı yaratabilir.
Önemli Noktalar
- Mixed content çoğunlukla ceza değil, dolaylı teknik SEO riskidir.
- Script ve CSS hataları görsellerden daha yüksek öncelik taşır.
- HTTPS geçişinde canonical, sitemap ve alt kaynaklar birlikte temizlenmelidir.
- DevTools, GSC ve site geneli crawl birlikte kullanılmalıdır.
Karışık içerik uyarısı nedir, SEO cezası mıdır?
mixed content terimi, HTTPS ile açılan bir sayfanın bir alt kaynağı HTTP üzerinden çağırmasıdır. MDN’nin güncel çerçevesi bu konuyu yalnız eski aktif ve pasif ayrımıyla değil, upgradable content ve blockable content yaklaşımıyla açıklar. Görsel, video ve ses gibi bazı istekler uygun koşullarda HTTPS’e yükseltilebilirken; script, stylesheet, iframe, fetch ve font istekleri gibi kaynaklar doğrudan engellenebilir (MDN, 2025-11-30).
SEO açısından ilk netlik şu olmalı: karışık içerik uyarısı çoğu durumda doğrudan bir ceza değildir. Google’ın HTTPS’i sıralama sinyali olarak tanımlayan birincil açıklaması, güvenli protokolün pozitif bir sinyal olduğunu söyler; mixed content sorunu ise bu sinyali temiz biçimde uygulamanızı bozan teknik bir problem gibi çalışır (Google Search Central, 2014-08-07). 2026 çerçevesinde pratik sonuç, sıralama kaybının çoğunlukla render eksilmesi, güven zedelenmesi ve bozulmuş kullanıcı davranışı üzerinden gelmesidir.
Bu yüzden soruyu ceza mı yoksa teknik risk mi diye kurmak daha doğrudur. Sayfa açılıyor gibi görünse bile kritik JavaScript veya CSS yüklenmiyorsa, Googlebot’un ve kullanıcının gördüğü sürüm birbirinden ayrılabilir. Buna karşılık tek tük bir HTTP görseli kalmışsa, sorun daha çok güven algısı ve dönüşüm tarafında hissedilir. Yani mixed content etkisi, hangi kaynağın HTTP kaldığına göre değişir; tek tip bir SEO etkisinden söz etmek doğru olmaz.
Tarama, render, güven ve dönüşüm etkisini ayrı değerlendirin
Tarama tek başına yeterli değildir; Google sayfayı render ederek anlamaya çalışır. web.dev’in mixed content düzeltme rehberi, engellenen script ve stylesheet çağrılarının sayfanın beklenen halini bozduğunu net biçimde anlatır (web.dev, 2019-09-07). Bu özellikle JavaScript SEO tarafında önemlidir; menü, ürün varyasyonu, filtreleme, lazy-load blokları veya form bileşenleri kritik bir script’e bağlıysa, sayfa teknik olarak erişilebilir görünür ama işlevsel içerik eksik render edilir.
Teknik etki ile kullanıcı etkisini ayırmak gerekir. HTTP script, CSS ve iframe çağrıları genelde en kritik gruptur; çünkü render’ı, etkileşimi ve bileşen görünürlüğünü doğrudan bozabilir. HTTP görseller ve fontlar bazı tarayıcılarda otomatik yükseltilse bile her zaman sorunsuz değildir. Bozuk ikonlar, kaymış butonlar, yüklenmeyen ürün görselleri veya eksik font dosyaları kullanıcıya kalitesiz ve güvensiz bir sayfa algısı verir.
Ticari etki çoğu zaman sıralama etkisinden önce görünür hale gelir. Özellikle teklif formu, ödeme adımı, rezervasyon veya lead sayfalarında adres çubuğundaki uyarı, eksik tasarım öğeleri ve yarım çalışan üçüncü taraf etiketler güven duygusunu düşürür. Organik oturum sayısı aynı kalsa bile form tamamlama oranı, sepete ekleme davranışı veya demo talebi azalabilir. Bu nedenle mixed content bazen önce SEO raporunda değil, dönüşüm raporunda yakalanır.
Bir diğer karışan konu da Core Web Vitals ile ilişkisidir. Karışık içerik doğrudan bir Core Web Vitals metriği değildir; ancak bloklanan kaynaklar layout kayması, etkileşim gecikmesi veya algılanan yüklenme kalitesini dolaylı etkileyebilir. Bu yüzden teknik ekiplerin, performans bozulmasını yalnız hız problemi gibi değil, güvenlik kaynaklı render sorunu olarak da okuyabilmesi gerekir.
HTTPS’e geçince neden mixed content uyarısı çıkar?
HTTPS’e geçişten sonra mixed content uyarısının artmasının en yaygın nedeni, ana sayfa URL’leri taşınırken alt kaynakların eski mutlak HTTP adreslerinde kalmasıdır. Tema dosyaları, medya kütüphanesi, CDN görselleri, reklam etiketleri, chatbot widget’ları, canlı destek script’leri ve yıllardır dokunulmamış üçüncü taraf entegrasyonları burada klasik kırılma noktalarıdır. Özellikle ortak header veya footer dosyasında kalan tek bir HTTP çağrı, site genelinde yüzlerce URL’ye aynı sorunu taşıyabilir.
Google’ın güncel canonical ve site move dokümanları, HTTPS geçişinde yalnızca yönlendirme açmanın yetmediğini; canonical, sitemap ve site içi URL sinyallerinin de yeni protokolle tutarlı olması gerektiğini vurgular (Google Search Central, 2026-07-10; Google Search Central, 2026-06-17). Yani sayfa 301 ile HTTPS’e gidiyor olabilir; ancak canonical hâlâ HTTP’yi işaret ediyorsa, XML sitemap eski URL’leri taşıyorsa veya içerik içi varlıklar HTTP ise geçiş hijyeni eksik kalır.
Risk önceliğini kaynak türüne göre okumak işinizi hızlandırır. Script ve CSS birinci önceliktir; iframe ve üçüncü taraf etiketler hemen arkasından gelir. Görsel ve font hataları bazen daha düşük teknik risk taşır; ama güven rozetleri, ürün görselleri, ödeme ikonları veya marka öğeleri bu varlıklara bağlıysa ticari etkisi büyür. Mixed download vakaları da unutulmamalıdır; HTTPS sayfadan HTTP dosya indirtmek, güven algısını zayıflatır ve tarayıcı engeline takılabilir (MDN, 2025-11-30).
2026’da sağlıklı HTTPS migration yaklaşımı, yalnız URL taşımaya değil, tüm alt kaynakların protokol bütünlüğüne bakmayı gerektirir. Başka bir deyişle, yönlendirme tamamlandı demekle iş bitmez; sayfanın render ettiği her dosya, her etiket ve her medya çağrısı yeni protokolle uyumlu olmalıdır.
Mixed content hatalarını nasıl tespit edip önceliklendirirsiniz?
Teşhise tek araçla değil, katmanlı bir akışla gidin. İlk durak genelde Chrome DevTools Console ve Network panelleridir. Console, hangi kaynakta mixed content uyarısı oluştuğunu hızlıca gösterir; Network ise isteğin kaynağını, response davranışını ve zincirleme etkiyi izlemenizi sağlar. Chrome for Developers rehberleri, Console tarafında hata mesajlarını yorumlamayı ve Network tarafında istekleri filtreleyip hangi dosyanın bozulduğunu izlemeyi temel iş akışı olarak konumlandırır (Chrome for Developers, 2024-09-21; Chrome for Developers, 2024-10-14).
İkinci katmanda Google Search Console URL Denetleme Aracı yer alır. Burada amaç yalnız indeksleme durumuna bakmak değil; Google’ın indekslenen ve canlı test edilen sürümde sayfayı nasıl gördüğünü anlamaktır. Render kırığı şüphesinde canlı test görünümü, yüklenen kaynaklar ve canonical verisi birlikte okunmalıdır. Özellikle JavaScript’e bağlı bloklar, kullanıcı tarafında görünür olup Google tarafında eksik kalıyorsa mixed content uyarısı basit bir güvenlik mesajından daha ciddi bir SEO sorunudur.
Üçüncü katman site geneli önceliklendirmedir. Önce en çok trafik alan landing page’leri, sonra gelir üreten sayfaları, ardından şablon bazlı tekrar eden hataları listeleyin. Bu noktada Türkçe arayüzlü bir site sağlığı taraması ve URL bazlı HTTPS / SSL kontrolcüsü, teknik ekip olmayan pazarlama ekiplerinin de hangi URL’nin gerçekten temizlendiğini doğrulamasını kolaylaştırır. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer benzeri araçlar tarama çıktısı sunabilir; SEOYEN ise bunu tek platformda, Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek ile Türkiye pazarı için daha operasyonel hale getirir.
- Önce render’ı bozan script ve CSS isteklerini kapatın.
- Sonra organik giriş alan landing page’lerdeki görsel, font ve iframe sorunlarını temizleyin.
- En son düşük trafikli ama tekrar eden şablon hatalarını toplu kapatın.
Bu bölüm için kısa bir DevTools ekran kaydı hazırlamak da faydalıdır. Özellikle ajans, geliştirici ve içerik ekibi aynı kontrol listesini aynı sırayla uygularsa, mixed content temizliği bir defalık müdahaleden çıkıp tekrarlanabilir bir operasyon standardına dönüşür.
30 günlük saha notu: reklam etiketi, CDN görseli ve eski tema dosyası
30 günlük saha notlarında en öğretici tabloyu üç kaynak türü verir: reklam etiketi, CDN görseli ve eski tema dosyası. Render’ı bozan reklam script’i genelde ilk 24-48 saatte fark edilir; sayfanın bazı bileşenleri çalışmaz, konsolda bloklanan istek görünür ve Google’ın canlı test görünümü eksik kalabilir. Burada sıralama etkisi dolaylıdır; ancak teknik hasar hızlıdır ve sorun çözülene kadar sayfanın algılanan kalitesi düşer.
CDN üzerindeki HTTP görsel ise çoğu zaman daha sinsi ilerler. Sayfa indekslenmeye devam eder; fakat ürün görseli, güven rozeti veya hero alanı boş kaldığında kullanıcı güveni aşınır. Özellikle e-ticaret SEO ve lead odaklı sayfalarda bu tip görsel kusurlar, sıralama grafiğinden önce dönüşüm grafiğinde kendini gösterir. Bu yüzden görsel hatalarını yalnız kozmetik eksik gibi okumak çoğu ekip için maliyetli bir yanılgı olur.
Eski tema dosyasında kalan HTTP çağrısı ise en geniş yayılımlı problemdir. Header, footer veya ortak component içinde kaldığı için tek dosya yüzlerce URL’de uyarı üretir. HTTPS geçişlerinde teknik ekiplerle tekrar tekrar görülen desen şudur: bir script tek sayfada büyük hasar verir, ortak tema çağrısı ise site genelinde yavaş ama geniş bir kalite erozyonu yaratır. Bu nedenle sahada önce etki şiddeti, sonra yayılım alanı birlikte okunur.
İzleme tarafında 30 günlük pencere faydalıdır çünkü ilk hafta teknik kırıklar, ikinci hafta kullanıcı davranışı, sonraki haftalarda ise organik landing page trendi daha net ayrışır. Böylece mixed content temizliği sonrası iyileşmenin sıralama mı, render mı, yoksa güven ve dönüşüm mü kaynaklı olduğunu daha sağlıklı yorumlayabilirsiniz.
Mixed content sorunları nasıl düzeltilir ve tekrar önlenir?
Düzeltmenin çekirdeği basittir: HTTP çağrıyı kaldırın ya da geçerli HTTPS karşılığıyla değiştirin. Bunun için veritabanındaki eski mutlak URL’leri, tema ayarlarını, CDN origin adreslerini, reklam ve analitik etiketlerini, font ve iframe kaynaklarını tek tek güncelleyin. Aynı domain içindeki dosyalarda göreli yol kullanımı uygunsa bunu standartlaştırmak, sonraki geçişlerde aynı hatanın geri dönme olasılığını düşürür.
CSP upgrade-insecure-requests bazı durumlarda geçici kalkan olabilir. MDN bunu tüm istekleri HTTPS’e yükselten bir politika olarak açıklar; ancak kaynak HTTPS tarafında gerçekten yoksa istek yine başarısız olur (MDN, 2025-11-30). Bu nedenle CSP, kalıcı düzeltmenin yerine geçen bir sihirli buton değil; geçiş döneminde yüzey alanını daraltan yardımcı bir katmandır. Özellikle üçüncü taraf sağlayıcı güvenli endpoint vermiyorsa, asıl iş sağlayıcıyı değiştirmek veya entegrasyonu revize etmektir.
Düzeltmeden sonra iş bitmez. Yeniden crawl alın, kritik URL’lerde canlı test yapın, canonical ve sitemap’ın HTTPS kaldığını doğrulayın, yönlendirme zinciri oluşmadığını kontrol edin. Ardından organik landing page’leri ve sıralama takibi raporu verisini birkaç hafta birlikte izleyin. 2026’da iyi uygulama standardı, mixed content temizliğini bir kerelik görev değil, yayın öncesi kalite kontrol maddesi olarak yönetmektir.
- Deployment öncesi şablon taraması yapın.
- Yeni üçüncü taraf etiketleri HTTPS endpoint açısından onaylayın.
- Migration checklist’ine canonical, sitemap ve sertifika kontrolünü sabitleyin.
Kalıcı önleme için içerik ekibi, geliştirici ekip ve pazarlama ekiplerinin aynı protokol standardında buluşması gerekir. Yeni banner, script, widget veya medya yüklenirken HTTPS dışı kaynak kabul etmeyen basit bir yayın kuralı, sonradan yapılacak pahalı teknik temizliğin önüne geçer.
| Kaynak türü | Tarayıcı davranışı | SEO riski | Öncelik |
|---|---|---|---|
| Script | Genelde engellenir | Render ve içerik görünürlüğü bozulabilir | Çok yüksek |
| CSS | Genelde engellenir | Yerleşim ve kullanıcı algısı bozulabilir | Çok yüksek |
| Görsel | Bazı durumlarda HTTPS’e yükseltilebilir | Güven ve dönüşüm tarafında dolaylı risk | Orta |
| Font | Sıkça engellenir veya bozulur | Marka algısı ve kullanılabilirlik etkilenebilir | Orta-yüksek |
| Iframe | Genelde engellenir | Gömülü kritik içerik kaybolabilir | Yüksek |
| Üçüncü taraf etiket/CDN | Kaynağa göre değişir | Hem render hem güven sinyali riski taşır | Yüksek |
| Mixed download | Tarayıcı engeline takılabilir | Güven zayıflar, kullanıcı işlemi yarım kalabilir | Orta-yüksek |
Adım Adım Mixed content tespit ve düzeltme akışı
Aşağıdaki akış, geliştirici ve pazarlama ekiplerinin aynı terminolojiyle ilerlemesini sağlar. Amaç yalnız uyarıyı susturmak değil; hangi mixed content kaynağının SEO, güven ve dönüşüm tarafında daha kritik olduğunu hızlıca ayırmaktır.
- Problemli URL listesini çıkarın. DevTools, crawl çıktısı ve Search Console verisinden mixed content görülen URL’leri tek havuzda toplayın. Böylece tekil hata ile şablon bazlı hata ayrılır ve dağınık teşhis yerine site genelinde görünürlük elde edilir.
- Kaynak türüne göre sınıflandırın. Script, CSS, görsel, font, iframe, üçüncü taraf etiket ve mixed download gruplarını ayırın. Önceliklendirme kaynağın sayısı kadar etkilediği işlevi de dikkate almalıdır; aynı sayıda hatanın etkisi her zaman aynı değildir.
- HTTP çağrılarını güvenli hale getirin. Mutlak HTTP URL’leri HTTPS karşılıklarıyla değiştirin. Tema, CMS, medya ayarı ve veritabanı tarafında kalan eski adresleri topluca temizleyin; gerekiyorsa göreli yol standardı tanımlayın.
- Üçüncü taraf ve CDN kontrollerini yapın. Reklam etiketi, analitik script’i, widget, font sağlayıcısı ve CDN endpoint’lerinin güvenli sürüm sunduğunu doğrulayın. HTTPS desteği vermeyen entegrasyonları geçici politika ile değil, kalıcı çözümle kapatın.
- Geçiş hijyenini yeniden doğrulayın. Canonical, XML sitemap, iç linkler, yönlendirmeler ve sertifika sağlığını birlikte kontrol edin. Sayfa HTTPS olsa bile destekleyen sinyaller hâlâ HTTP ise geçiş eksik kabul edilmelidir.
- Düzeltme sonrası etkisini izleyin. Yeniden crawl, canlı URL testi ve organik landing page izleme ile hatanın geri dönmediğini doğrulayın. Teknik temizlik tamamlandıktan sonra davranış ve dönüşüm verisini birkaç hafta daha birlikte okuyun.
Kaynaklar
Sıkça Sorulan Sorular
Karışık içerik uyarısı, HTTPS ile açılan bir sayfanın alt kaynaklarından en az birini HTTP üzerinden çağırdığında oluşur. Bu kaynak script, CSS, görsel, font, iframe veya dosya indirme bağlantısı olabilir. Tarayıcılar bazı görsel türlerini otomatik olarak HTTPS’e yükseltmeye çalışsa da script ve stylesheet gibi kritik kaynakları genelde engeller. SEO tarafında önemli nokta, bu uyarının tek başına bir ceza anlamına gelmemesi. hangi kaynağın etkilendiğine göre render, güven ve kullanıcı davranışını bozabilmesidir.
Genelde doğrudan bir ceza gibi çalışmaz. fakat dolaylı sıralama riski üretir. Eğer HTTP kalan kaynak script, CSS veya iframe ise Googlebot sayfayı eksik render edebilir ve kritik içeriği beklenen haliyle göremeyebilir. Eğer sorun görsel, font veya güven rozetlerinde ise kullanıcı güveni ve dönüşüm davranışı zayıflayabilir. Sonuç olarak mixed content hatası çoğu zaman sıralamayı tek başına değil, render kalitesi, sayfa algısı ve kullanıcı etkileşimi üzerinden olumsuz etkiler.
Çünkü HTTPS geçişi çoğu zaman yalnız sayfa adresini düzeltir. alt kaynaklar ise eski HTTP adreslerinde kalır. Tema dosyaları, CDN bağlantıları, medya URL’leri, reklam etiketleri, canlı destek script’leri ve eski mutlak linkler bu sorunun ana kaynaklarıdır. Ayrıca canonical, XML sitemap ve yönlendirme ayarları yeni protokolle tutarlı değilse, geçiş teknik olarak tamamlanmış görünse bile mixed content riski sürer. En sık hata, ana URL’yi HTTPS’e taşırken alt varlık URL’lerini unutmak olur.
Evet, özellikle render’a bağlı sayfalarda etkileyebilir. Tarama düzeyinde Google URL’ye ulaşabilir. ancak kritik script veya CSS dosyaları mixed content nedeniyle engellenirse sayfanın görünür hali eksik kalır. Bu da içerik bloklarının, filtreleme bileşenlerinin, ürün detaylarının veya form alanlarının Google tarafından beklenen biçimde görülmemesine yol açabilir. Sonuç olarak indeksleme sorunları, eksik içerik algısı veya yanlış canonical yorumu gibi dolaylı teknik etkiler ortaya çıkabilir.
En sağlıklı yöntem, birkaç katmanlı teşhis akışı kurmaktır. İlk olarak Chrome DevTools Console ve Network panellerinde hangi URL’nin, hangi kaynak türünde uyarı ürettiğini görün. Ardından Search Console URL Denetleme Aracı ile canlı test ve render görünümünü kontrol edin. Son aşamada site genelinde crawl çıktısı ve gerekiyorsa log analiziyle, sorunun tekil mi yoksa şablon bazlı mı olduğunu ayırın. Önceliklendirme yaparken trafik alan landing page’ler ve render’ı bozan istekler başa alınmalıdır.
Temel çözüm, HTTP çağrılarını HTTPS karşılıklarıyla değiştirmektir. Bunun için CMS ayarları, tema dosyaları, veritabanı içindeki eski URL’ler, CDN origin adresleri ve üçüncü taraf script entegrasyonları gözden geçirilmelidir. Geçici olarak CSP upgrade-insecure-requests politikası yardımcı olabilir. ancak HTTPS sürümü olmayan kaynağı sihirli biçimde düzeltmez. Düzeltme sonrasında yeniden crawl almak, kritik URL’lerde canlı test yapmak, canonical ve sitemap’ın HTTPS kaldığını kontrol etmek ve sıralama ile dönüşüm verisini birlikte izlemek gerekir.