Mixed Content Nedir? HTTPS Sonrası Karma İçerik ve HSTS

Karma içerik (mixed content), HTTPS ile açılan bir sayfanın içinde HTTP gibi güvenli olmayan bir adresten görsel, script, stil dosyası ya da başka bir kaynak çağırmasıdır. HTTPS geçişini tamamlayıp sertifikayı kurduktan sonra bile adres çubuğunda “güvenli değil” uyarısı görüyorsanız, tarayıcı konsolunda kırmızı hata satırları birikiyorsa ya da sayfanın bir bölümü boş kalıyorsa, çoğu zaman sorun bu kategoridedir. Mixed content nedir sorusunun kısa cevabı budur; asıl iş, hangi kaynağın nerede kaldığını bulmak ve sonra HSTS gibi kalıcı bir kararı güvenle devreye almaktır.

Bu yazı, HTTPS’e yeni geçmiş bir sitenin sahibi, geliştiricisi ya da teknik SEO sorumlusu için hazırlandı. Önce tarayıcıların karma içeriğe nasıl davrandığını, sonra aktif ve pasif ayrımının bugün ne anlama geldiğini anlatır. Ardından HSTS başlığını ne zaman ve hangi sırayla açacağınızı, preload listesinin neden ayrı ve ağır bir karar olduğunu ele alır. Son bölümlerde geçiş sonrası tarama yöntemi, doğrulama listesi ve geri dönüş planı yer alır. Belirli bir CMS, hosting paneli ya da CDN ürününün menü adları anlatılmaz; ilkeler ürün bağımsızdır.

Karma İçerik Nedir ve Tarayıcı Bunu Nasıl Ele Alır

MDN karma içerik belgesi (yeni sekmede açılır) karma içeriği şöyle tanımlar: güvenli biçimde yüklenmiş bir web sayfasının, HTTP ya da başka bir güvenli olmayan protokol üzerinden getirilen kaynakları kullanması. Aynı sayfada bir de karma indirme kavramı geçer: güvenli bir bağlamdan başlatılan ama güvenli olmayan bağlantı üzerinden alınan dosya indirmeleri. Örneğin HTTPS sayfasındaki bir indirme bağlantısı http:// ile başlıyorsa, bu karma indirmedir ve tarayıcılardan bunu engellemeleri beklenir. Pratikte çoğu tarayıcı engeller, kullanıcıyı riske karşı uyarır ve dosyayı tutma ya da silme seçeneği sunar.

Burada bir ayrım önemlidir. Sayfanın kendisi HTTPS ile gelmiş olabilir, adres çubuğundaki kilit de görünebilir; ama sayfanın içindeki tek bir HTTP isteği, o güvenlik garantisini deler. Ağın ortasındaki biri o güvenli olmayan isteği okuyabilir ya da değiştirebilir. Bir görsel için bu sınırlı bir risk gibi görünebilir, bir script için ise sayfanın tamamını değiştirebilecek bir kapı demektir. Tarayıcıların kuralları da bu farka göre kurulmuştur.

Eski model: aktif ve pasif

MDN’in karma içerik sayfası (yeni sekmede açılır), eski şartnamenin iki kategori kullandığını anlatır. Aktif karma içerik, sayfanın diğer bölümlerini değiştirebilecek kaynaklardır, örneğin script ve stil dosyaları; tarayıcıların bunları engellemesi zorunluydu. Pasif karma içerik ise sayfanın başka bir bölümünü değiştiremeyen görsel, video ve ses dosyalarıdır; tarayıcı bunları gösterebilir, engelleyebilir ya da kararı kullanıcıya bırakabilirdi. Bu sınıflandırma hâlâ konuşma dilinde yaşıyor ve çoğu denetim aracı raporlarında bu iki etiketi kullanıyor.

Güncel model: yükseltilebilir ve engellenebilir

MDN’e göre güncel yaklaşımda iki sınıf vardır. Yükseltilebilir (upgradable) içerik için tarayıcılar isteği otomatik olarak HTTP’den HTTPS’e çevirmelidir; bu küme, eski modeldeki “isteğe bağlı engellenebilir” kaynaklardan türemiştir. Engellenebilir (blockable) içerik ise yükseltilebilir olmayan her şeydir ve tarayıcı bunu engeller. Yani eskiden “pasif” sayılan bir görsel bugün çoğu durumda sessizce HTTPS’e yükseltilir, “aktif” sayılan bir script ise yüklenmez. Bu fark, geçiş sonrası hangi sorunun gözle görüleceğini belirler: engellenen kaynaklar sayfayı bozar ve fark edilir, yükseltilen kaynaklar ise çalıştığı için kolayca gözden kaçar.

Gözden kaçmanın bir bedeli vardır. Yükseltme, hedef sunucunun aynı kaynağı HTTPS ile de sunduğunu varsayar. Sunmuyorsa istek başarısız olur ve görsel kırık görünür. Bu sonuç MDN’in yazdığı bir cümle değil, yükseltme mantığından çıkan bir çıkarımdır; yine de eski bir üçüncü taraf sunucudaki görseller için sık görülen bir durumdur.

Konsol ne söyler, arama motoru ne görür

MDN, geliştirici konsolunun karma içerik yükseltildiğinde ya da engellendiğinde uyarı gösterdiğini belirtir. Bu yüzden ilk teşhis aracı tarayıcıdır. Arama tarafında ise Google’ın yinelenen URL belgesi, HTTPS sayfasını HTTP karşılığına tercih ettiğini, ancak sorun ya da çelişkili sinyal varsa bu tercihin bozulabileceğini söyler. Belge sorunlara örnek olarak geçersiz SSL sertifikasını, görsel dışındaki güvenli olmayan bağımlılıkları ve HTTPS’ten HTTP’ye yönlendirmeyi sayar. Yani karma içerik yalnızca kullanıcı deneyimi ya da güvenlik meselesi değildir; sayfanın arama sonuçlarında hangi adresle temsil edileceğini etkileyebilecek bir sinyal sorunudur. Bu belge, etkinin sıralamaya ne ölçüde yansıdığını sayısal olarak belirtmez.

Aktif ve Pasif Karma İçerik: Görsel, Script, Iframe

Hangi kaynağın hangi davranışı tetiklediğini bilmek, bir hata listesini önceliklendirmenin en kısa yoludur. Aşağıdaki tablo, MDN’in karma içerik sayfasındaki sınıflandırmanın özetidir. Bu tabloya “kesin” gözüyle bakmayın; tarayıcı sürümleri ve şartname zamanla değişir, o yüzden kendi hedef tarayıcılarınızda sonucu bir kez doğrulayın.

Tabloda dikkat çeken bir ayrıntı var: img src yükseltilirken aynı görselin srcset ya da picture içinden çağrılması engellenebilir sınıfta görünüyor. Yani bir sayfada masaüstü görseli sorunsuz yüklenirken mobil görseli, yalnızca farklı bir etiketten geldiği için kaybolabilir. MDN ayrıca CSS tarafında kendi içinde bir tutarsızlığa dikkat çeker: background-image gibi CSS görselleri bir bölümde yükseltilebilir, başka bir bölümde ise CSS’teki her url() kullanımı engellenebilir olarak listelenir. Sayfa bu çelişkiyi çözmüyor. Bu yüzden CSS içindeki http:// adreslerini “nasılsa yükselir” diye bırakmayın, kaynağı HTTPS’e çevirin.

Pasif sayılan kaynaklar: görsel, ses, video

Yükseltilebilir sınıftaki kaynaklar kullanıcıya en az hasar veren ama en çok sayıda görülen kalemdir. Eski blog yazılarında gövdeye gömülmüş görseller, bir zamanlar farklı alan adından yüklenmiş ürün fotoğrafları, içerik yönetim sisteminin eski sürümünden kalan sabit adresli görseller tipik örneklerdir. Tarayıcı bunların çoğunu sessizce yükseltir; ancak MDN’in belirttiği bir istisna var: host bir alan adı değil de IP adresi ise yükseltilecek istek bile engellenir. Örneğin alan adı yerine sayısal IP ile çağrılan bir görsel, aynı yolla bile olsa kırık görünür.

Kurgusal örnek: bir ajansın müşteri sitesi, üç yıl önce bir fotoğraf ortağından görselleri doğrudan IP adresi üzerinden bağlamış olsun. Geçiş günü ana sayfa normal görünür çünkü görsellerin büyük kısmı kendi alan adındadır. Yalnızca eski kampanya sayfalarında kırık görsel kalır ve bu sayfalar trafiğin küçük bölümünü aldığı için haftalarca fark edilmez. Bu örnek bir sayı ya da gerçek site sonucu taşımaz; amacı, sorunun çoğu zaman sitenin en çok bakılan yerinde değil kuyruğunda saklandığını göstermektir.

Aktif sayılan kaynaklar: script, stil, iframe, veri istekleri

Engellenebilir sınıftaki kaynaklar bir sayfayı gözle görülür biçimde bozar. HTTP’den çağrılan bir script yüklenmez; bu script menüyü açan kodsa menü çalışmaz, ölçüm kodu ise analitik verisi kaybolur. HTTP stil dosyası engellenirse sayfa stilsiz görünür. Iframe ile gömülen bir harita, form ya da video oynatıcı boş bir kutuya dönüşür. fetch ya da XMLHttpRequest ile HTTP bir API adresine istek yapan bir arayüz bileşeni, veri çekemediği için boş kalır. Bunlar kullanıcının hemen fark ettiği hatalardır; asıl risk, ölçüm ve izleme kodu gibi kullanıcı için görünmez ama işletme için önemli kaynakların sessizce düşmesidir.

Ek olarak web fontları da bu grupta yer alır. Font dosyasının adresi CSS içindeki eski bir @font-face kuralında http:// olarak kalmışsa tarayıcı onu yüklemez ve yedek bir yazı tipine düşer. Düzen kayması, başlıkların farklı genişlikte görünmesi ve ikon fontlarının kutu simgelerine dönmesi tipik sonuçlardır. Bu sorun SEO’yu doğrudan etkilemese de sayfa deneyimini bozar, bu da geçişin başarılı sayılmasını zorlaştırır.

Bağlantılar ve indirmeler

Sayfadaki sıradan bir bağlantı, yani a etiketi, karma içerik sayılmaz: MDN, güvenli bir bağlamdan güvenli olmayan bir üst düzey sayfaya gidişin karma içerik olmadığını yazar. Yine de iç bağlantıların http:// ile kalması genel olarak başka bir soruna yol açabilir: bu bağlantılar çoğunlukla bir yönlendirme adımı gerektirir ve tarama kaynaklarının gereksiz harcanmasına neden olabilir. İndirme bağlantıları ise ayrı ele alınmalıdır, çünkü download niteliği taşıyan http:// bağlantıları karma indirme olarak engellenebilir. PDF, fiyat listesi ve sunum dosyalarının bağlantılarını ayrıca tarayın.

Hangi çözüm hangi kaynağa uyar

Kaynak doğrudan sizin kontrolünüzdeyse çözüm basittir: adresi HTTPS’e çevirin ya da alan adını kaldırıp göreli yol kullanın. MDN’in önerdiği sıra da budur: her şeyi HTTPS üzerinden sunun, kendi alan adınızdaki kaynaklar için göreli ya da HTTPS bağlantı kullanın ve üçüncü taraf kaynakların HTTPS sürümünü tercih edin. Üçüncü taraf kaynağın HTTPS karşılığı yoksa seçenekler azdır: kaynağı başka bir sağlayıcıdan almak, dosyayı kendi sunucunuza taşımak (lisans izin veriyorsa) ya da o bileşeni kaldırmak. Başlık düzeyinde bir kestirme de vardır: MDN’in see-also bölümünde geçen Content-Security-Policy upgrade-insecure-requests yönergesi, engellenebilir karma içerik dahil tüm istekleri HTTPS’e çevirir. Bu yönerge geçici bir koruma ağı olarak yararlıdır, ama HTML’deki adresleri düzeltmenin yerine geçmez; hedef sunucu HTTPS sunmuyorsa istek yine başarısız olur ve kaynağın kendisi hâlâ yanlış adreste durur.

HSTS: Ne Zaman Açılır, Preload Riski

HSTS (HTTP Strict Transport Security), sunucunun tarayıcıya “bu siteye yalnızca HTTPS ile bağlan” dediği bir yanıt başlığıdır. MDN’in HSTS belgesine (yeni sekmede açılır) göre başlık, ana makinenin yalnızca HTTPS ile erişilmesi gerektiğini ve gelecekteki HTTP denemelerinin otomatik olarak HTTPS’e yükseltilmesini bildirir. HSTS nedir sorusunun kısa cevabı budur; ama bu başlığı açmak, yönlendirmeden farklı olarak tarayıcıya kalıcı bir söz vermektir. Bu nedenle sırası önemlidir: önce karma içerik temizlenir, sonra HSTS açılır.

Başlığın söz dizimi ve yönergeler

Başlık max-age yönergesiyle başlar. max-age, tarayıcının bu ana makinenin yalnızca HTTPS ile erişilmesi gerektiğini ne kadar süre hatırlayacağını saniye cinsinden belirtir. includeSubDomains eklenirse politika alan adının tüm alt alan adlarına da uygulanır. preload ise ayrı bir sürecin işaretidir ve MDN’e göre kullanıldığında max-age en az 31536000 saniye (bir yıl) olmalı, includeSubDomains da bulunmalıdır.

MDN’in vurguladığı iki ayrıntı pratikte kritiktir. Birincisi, başlık yalnızca HTTPS yanıtında geçerlidir: HTTP yanıtındaki HSTS başlığı tarayıcılar tarafından yok sayılır, çünkü aradaki bir saldırgan başlığı ekleyebilir ya da süresini kısaltabilir. Dolayısıyla HTTP’den HTTPS’e yönlendirme yapan 301 yanıtında HSTS başlığı olmamalıdır. İkincisi, HSTS ilk ziyarette etkisizdir: tarayıcı o sitede en az bir güvenli bağlantı kurup başlığı almadan politika devreye girmez. İlk ziyaretin açığı preload ile kapatılmaya çalışılır; bu da konunun risk tarafıdır.

Ne zaman açılır

Açmak için üç önkoşul gerekir. Birincisi, sertifikanın geçerli ve otomatik yenilenir olması. MDN, bir HSTS sitesinde sertifika hatası çıkarsa tarayıcının kullanıcıya “yine de devam et” seçeneği sunmadığını yazar; süresi dolmuş bir sertifika artık yalnızca bir uyarı değil, siteye tam erişim kaybıdır. İkincisi, sayfaların karma içerik üretmemesi; HSTS HTTP erişimini kapattığı için HTTP’de kalmış bir kaynağa dönüş yolu da kalmaz ve sorun, yönlendirme ya da önbellek gibi geçici açıklamalar ortadan kalktıkça daha görünür olur. Üçüncüsü, HTTP’den HTTPS’e yönlendirmelerin tüm yollar için çalışması ve test edilmiş olması. Google’ın site taşıma belgesi (yeni sekmede açılır) bu tarafta net: mümkünse sunucu tarafında kalıcı yönlendirme kullanın, 301 ya da 308 gibi kodları tercih edin ve yönlendirmeleri mümkün olduğunca uzun, genellikle en az bir yıl tutun.

Google’ın yinelenen URL belgesi (yeni sekmede açılır) HSTS’i HTTPS’i güçlendiren yöntemlerden biri olarak anar; diğerleri HTTP sayfayı HTTPS’e yönlendirmek ve HTTP sayfadan HTTPS’e rel=canonical vermektir. Aynı belge iki uyarı da yapar: geçersiz TLS sertifikaları ve HTTPS’ten HTTP’ye yönlendirmeler Google’ın HTTP’yi çok güçlü biçimde tercih etmesine yol açar ve HSTS bu tercihi geçersiz kılamaz. Yani HSTS, yönlendirme ve canonical işinin yerine geçen bir kısayol değil, onların üstüne eklenen bir katmandır.

Kademeli açma planı

MDN, kademeli bir plan tarif etmez; yalnızca bir yıl asgari, iki yıl örnek değerlerini verir. Kademeli sürüm hstspreload.org sayfasında yer alır: önce tüm alt alan adlarını ve iç içe alt alan adlarını inceleyip HTTPS ile düzgün çalıştıklarından emin olun, sonra max-age değerini aşamalı artırın. Sayfanın örnek aşamaları şunlardır: 5 dakika (max-age=300), bir hafta (max-age=604800) ve bir ay (max-age=2592000); her aşamada includeSubDomains eklenir. Aşamalar arasında bozuk sayfa, trafik ve gelir gibi göstergeleri izleyin ve bir sonraki aşamaya geçmeden önce o aşamanın tam max-age süresini bekleyin.

1. Tüm alt alan adlarının envanterini çıkarın, hangilerinin HTTPS sunduğunu doğrulayın.
2. Önce yalnızca ana alan adında, kısa bir max-age ile başlayın.
3. Her aşamada konsol hatalarını, Search Console tarama istatistiklerini ve sunucu günlüklerini izleyin.
4. Bir sonraki aşamaya geçmeden önce o aşamanın süresini tamamen bekleyin.
5. includeSubDomains kararını, alt alan adı envanteri temizlenmeden vermeyin.

Bu liste hstspreload.org’daki kademeli yaklaşımın bir yorumudur; sıra ve süreleri sitenizin riskine göre sertleştirebilir ya da gevşetebilirsiniz. Önemli olan, tek adımda bir yıllık max-age ile başlamamaktır, çünkü bir hata fark edildiğinde geri çekilmesi çok daha zordur.

Preload listesi ve riski

hstspreload.org (yeni sekmede açılır), listeye girmek için dört şartı sayar: geçerli sertifika, 80. portu dinliyorsanız aynı ana makinede HTTPS’e yönlendirme, DNS kaydı varsa www dahil tüm alt alan adlarının HTTPS sunması ve ana alan adında max-age en az 31536000, includeSubDomains ve preload içeren bir HSTS başlığı. Aynı sayfada üç uyarı öne çıkar. Birincisi, listeye dahil olmanın kolayca geri alınamayacağı; kaldırma yavaştır ve Chrome kullanıcıları bunu ancak tarayıcı güncellemesiyle alır, diğer tarayıcıların aynı hızda izleyeceği garanti değildir. İkincisi, preload’ın internet üzerinden erişilemeyen iç alt alan adları dahil tüm alt alan adlarını kapsaması; HTTPS sunamayan bir alt alan adı, alan adı listeye girdiğinde bozulabilir. Üçüncüsü, sitenin HSTS’i önerdiği hâlde preload’ı genel olarak önermemesi; çünkü tarayıcılar zaten HTTP gezinmelerini HTTPS’e yükseltir ve preload esas olarak etkin bir saldırgana karşı fayda sağlar.

Dolayısıyla preload’a başvurmak, “HSTS’i açtık, sıra sonraki adıma geldi” demek kadar basit değildir. Başvurmadan önce şu sorulara net cevap gerekir: tüm alt alan adları, şimdi ve uzun vadede, HTTPS sunabilecek mi? Eski bir sistem, kurumsal iç araç ya da kampanya alt alan adı HTTP’de kalıyor mu? Alan adı el değiştirirse ya da başka bir ekibe devredilirse bu söz geçerli kalacak mı? Bu soruların cevabı belirsizse, includeSubDomains ve preload olmadan bir yıllık HSTS çoğu site için yeterli bir güvenlik kazanımı sunar. Karar sizindir; yalnızca geri dönüşün maliyetinin farklı olduğunu bilerek verin.

Başlığı kapatma ve beklenmedik süreler

MDN’e göre HSTS’i devre dışı bırakmak için max-age=0 gönderilir, ancak bu yalnızca tarayıcı güvenli bir istek yapıp bu yanıtı aldığında etki eder; HTTP üzerinden politika kaldırılamaz. Başlığı yanıtlardan çıkarmak politikayı silmez: önceki başlık süresi dolana kadar geçerli kalır. Sabit bir max-age her yanıtta süreyi ileri ittiği için HSTS hiç sona ermeyebilir. Ayrıca alt alan adı politikaları bağımsız saklandığı için ana alan adında max-age=0 vermek alt alan adlarının kendi politikalarını silmez. Bu ayrıntıların tamamı, geri dönüş planının HSTS’yi açmadan önce yazılması gerektiğini gösterir.

Geçiş Sonrası Tarama ile Eksik Kaynakları Bulma

Karma içeriğin kaynağı üç yerde olur: sayfa şablonları, veritabanındaki içerik ve üçüncü taraf bileşenler. Tek bir yöntem hepsini yakalamaz. Aşağıdaki sıra, her katmanı ayrı kanıtla kapatmak için tasarlandı.

1. Tarayıcı konsolu ve örnek sayfalar

Ana şablonu temsil eden birkaç sayfayı açın: ana sayfa, kategori, tekil içerik, arama sonucu, sepet ya da form sayfası. Geliştirici konsolunda karma içerik uyarılarını arayın. MDN’in önerisiyle tarayıcıda tüm karma içeriği kapatıp test etmek de işe yarar; sayfanın hangi parçasının kaybolduğunu görmek, hangi kaynağın yükseltmeyle sessizce çalıştığını ortaya çıkarır. Her sayfada konsol çıktısını kaydedin, çünkü sorunlar şablona göre tekrarlanır ve bir sayfada düzelen hata başka bir şablonda kalmış olabilir.

2. Site genelinde tarama

Konsol tek sayfaya bakar; yüzlerce sayfa için bir tarayıcı gerekir. MDN, bu iş için HTTPSChecker (masaüstü tarayıcı), mcdetect (komut satırı) ve Mixed Content Checker (çevrimiçi) araçlarını anar. Başka bir tarama aracı da kullanabilirsiniz; önemli olan aracın yalnızca HTML etiketlerine değil, CSS dosyalarındaki url() adreslerine ve script içinde yazılmış adreslere de bakabilmesidir. Aracın neleri kapsadığını belgesinden okuyun; kapsamadığı yerleri elle ayrı kontrol edin.

3. Veritabanı ve içerik kaynağı

Eski içerikte karma içerik, çoğunlukla veritabanına gömülmüş mutlak adreslerdir. Blog gövdeleri, ürün açıklamaları, widget metinleri, menü ve özel alan değerleri aranmalıdır. Arama yaparken http:// ile başlayan kendi alan adınızı ve bilinen eski alan adlarınızı ayrı ayrı tarayın. Toplu değişiklik yapacaksanız yedek alın, önce bir kopya üzerinde deneyin ve serileştirilmiş alanları bozmayacak bir yöntem seçin. Sistem içerik sürümü tutuyorsa değişikliği bir revizyon olarak kaydetmek geri dönüşü kolaylaştırır.

4. Şablon, tema ve eklentiler

Tema dosyalarında sabit yazılmış adresler, eklentilerin kendi varlık yükleme kodları ve üçüncü taraf script etiketleri ayrı bir arama ister. Yazı tipi, ölçüm kodu, sohbet bileşeni, harita, harici form ve video oynatıcı gibi bileşenlerin adreslerini tek tek açın ve HTTPS karşılığının çalıştığını doğrulayın. Eski bir bileşenin HTTPS sunmadığı ortaya çıkarsa değiştirme ya da kaldırma kararı bu aşamada verilir.

5. Sayfanın dışındaki sinyaller

Karma içerik denetimi yalnızca HTML ile bitmez. Geçişte güncellenmesi gereken sinyalleri de bu tarama içinde toplayın: canonical etiketleri, hreflang bağlantıları, Open Graph ve Twitter görsel adresleri, JSON-LD içindeki url ve image alanları, robots.txt içindeki Sitemap satırı ve XML sitemap dosyaları. Google’ın site taşıma belgesi sitemap’lerin yeni adreslerle güncellenmesini ve yeni sitemap’in Search Console’a gönderilmesini söyler; HTTP’den HTTPS’e taşımada Adres Değişikliği aracına gerek olmadığını da ekler. Eski sitemap için Search Console’da uyarı görmek beklenen bir durumdur. Bu sinyaller HTTP kalırsa karma içerik uyarısı vermez, ama Google’a çelişkili adres bilgisi verir ve HTTPS tercihini zayıflatabilir.

Yönlendirme zincirlerini de bu sırada test edin. Google aynı belgede yönlendirmeleri test etmeyi önerir ve insanların sıkça yeni sitede var olmayan adreslere yönlendirdiğini belirtir. Birkaç yüz adreslik bir örneklemeyi toplu bir betikle HTTP’den HTTPS’e gönderip yanıt kodlarını ve son adresi karşılaştırmak, tek tek denetlemekten çok daha güvenilirdir. Zincir uzunluğu ve çeşitli sürümler (www, www’suz, sondaki eğik çizgi) arasındaki davranış için www, www’suz sürüm, HTTPS ve eğik çizgi standardizasyonu yazısındaki kontrolleri kullanabilirsiniz; bu yazı yalnızca tarayıcı güvenlik katmanına odaklanır.

6. Bulguları sınıflandırma

Tarama bir liste üretir; liste, düzeltme sırası olmadığı sürece iş sayılmaz. Her bulguyu üç soruyla işaretleyin: kaynak engellenebilir mi yoksa yükseltilebilir mi, hangi şablonda tekrarlanıyor ve kim sahibi? Engellenen script ve stil dosyaları ilk sıraya, çok sayıda sayfada tekrar eden şablon kaynakları ikinci sıraya, tek seferlik eski içerik görselleri üçüncü sıraya girer. Sorunların neredeyse tamamı, dört ya da beş kaynak noktasından yayılır; şablonda tek satırlık bir değişiklik yüzlerce sayfayı onarabilir.

Kurgusal örnek: bir yayıncı sitesinde tarama, binlerce sayfada tek bir reklam script adresini ve yüzlerce eski yazıda üç farklı görsel alan adını gösteriyor. Reklam adresi tema dosyasındaki tek bir satırdan geliyor ve düzeltilince tüm sayfalar onarılıyor. Eski görseller için ise veritabanında adres değiştirme betiği çalıştırılıyor. Örnek bilinçli olarak rakamsızdır; mesele, önceliği sayfa sayısına değil kaynağın tekrar ettiği noktaya göre vermenin tamir süresini kısaltmasıdır.

Teknik denetimin geri kalanıyla bağlantısını kurmak için teknik SEO denetimi kontrol listesi yazısına bakabilirsiniz; orada tarama, dizinleme, yönlendirme ve performans bulguları tek bir öncelik sırasında birleştirilir. Karma içerik bulgularını o listeye yeni bir satır olarak eklemek, ekibin farklı raporlar arasında kaybolmasını önler.

Doğrulama Listesi ve Geri Dönüş Planı

Düzeltmeler tamamlandığında iş bitmiş sayılmaz; kanıt toplanır, izleme süresi tanımlanır ve geri dönüş yolu yazılır. Aşağıdaki liste yayın öncesi ve sonrası için ortak kullanılabilir.

Doğrulama listesi

1. Tüm sertifika zinciri geçerli mi, otomatik yenileme çalışıyor mu, bitiş tarihi izleniyor mu?
2. Tüm HTTP adresleri, tüm yollar için tek adımda HTTPS karşılığına 301 ya da 308 ile yönleniyor mu?
3. HTTP yönlendirme yanıtında HSTS başlığı yok mu, HTTPS yanıtında doğru değerle var mı?
4. Şablon örneklerinde konsolda karma içerik uyarısı kalmadı mı?
5. Site genelinde tarama engellenebilir ve yükseltilebilir kaynak için temiz sonuç verdi mi?
6. Canonical, hreflang, Open Graph, JSON-LD, robots.txt ve sitemap adresleri HTTPS mi?
7. İndirme bağlantıları, PDF ve fiyat listesi gibi dosyalar HTTPS mi?
8. Üçüncü taraf bileşenler (ölçüm, harita, form, video, reklam) HTTPS ile çalışıyor mu?
9. Alt alan adı envanteri tamam mı, includeSubDomains kararı bu envantere göre mi veriliyor?
10. Geri dönüş adımları ve sorumlusu yazılı mı?

İzleme: Search Console ve günlükler

Geçiş sonrası ilk haftalarda üç kaynağa bakın. Search Console’daki sayfa dizinleme ve tarama istatistikleri raporları, HTTPS adreslerinin dizinde temsil edilip edilmediğini gösterir. Sunucu günlükleri, arama botlarının HTTP adreslerine hâlâ ne kadar geldiğini ve yönlendirme yanıtlarını alıp almadığını doğrular; günlük okumayı HTTP durum kodları rehberiyle birlikte yaparsanız 301, 302 ve 5xx ayrımı hızlanır. Üçüncü olarak kullanıcı tarafı hata izleme: konsol hatalarını toplayan bir araç ya da basit bir hata raporlama kodu, tarayıcılarda gerçekten engellenen kaynakları görmenizi sağlar.

Google, site taşıma sırasında sıralamada geçici dalgalanma beklenebileceğini yazar ve küçük ile orta ölçekli bir sitede sayfaların çoğunun birkaç hafta içinde taşınabildiğini belirtir. Bu cümleler garanti değildir. Dalgalanma süresi sitenizin boyutuna ve taranma sıklığına göre değişir; sayıdan çok yönlendirme, canonical ve sitemap tutarlılığını izleyin.

Geri dönüş planı

Plan, hangi değişikliğin hangi adımla geri alınabileceğini ayrı ayrı yazmalıdır. Çünkü her katmanın geri dönüş maliyeti farklıdır.

Tablonun son satırı özellikle önemlidir. Bir şeyler ters gittiğinde en kolay görünen çözüm HTTPS’i kapatıp HTTP’ye dönmektir; oysa Google’ın yinelenen URL belgesi HTTPS’ten HTTP’ye yönlendirmelerin Google’ı HTTP’yi çok güçlü biçimde tercih etmeye yönelttiğini söyler. Hata çözümünü ters yönlendirme ile yapmayın; sorunu kaynağında, yani kaynak adresinde ya da sertifika ayarında düzeltin. Sertifika sorununda kısa vadeli çözüm, sorunu çözene kadar HSTS süresini kısa tutmuş olmaktır, o yüzden kademeli açma planı aynı zamanda bir geri dönüş planıdır.

Sık yapılan hatalar

• HSTS’yi karma içerik temizlenmeden açmak: Engellenen kaynaklar kalıcı hâle gelir, geri dönüş seçeneği daralır.
• Tek adımda bir yıllık max-age: Hata fark edildiğinde politikanın süresi dolana kadar beklemek gerekir.
• includeSubDomains’i envanter olmadan eklemek: Unutulmuş HTTP alt alan adları erişilemez olur.
• Preload’ı rutin bir adım saymak: Kaldırma yavaştır ve tarayıcı güncellemelerine bağlıdır.
• Yalnızca HTML’i taramak: CSS içindeki url() adresleri, script içi adresler, JSON-LD ve sitemap atlanır.
• Yükseltilen görselleri sorun saymamak: Tarayıcı bugün düzeltir ama hedef HTTPS sunmuyorsa yarın kırılır.
• CSP yönergesini kalıcı çözüm sanmak: Kaynak adreslerini düzeltmeden başlıkla örtmek teknik borcu ertelemektir.
• Geçiş sonrası izlemeyi bırakmak: Eklenti güncellemesi ya da yeni içerik, eski adresleri geri getirebilir.

Sıkça Sorulan Sorular

Mixed content nedir, neden uyarı verir?

Mixed content, HTTPS ile açılan bir sayfanın görsel, script, stil dosyası ya da iframe gibi bir kaynağı HTTP gibi güvenli olmayan bir adresten çağırmasıdır. Güvenli olmayan istek ağda okunabildiği ya da değiştirilebildiği için tarayıcı bu kaynakları ya engeller ya da otomatik olarak HTTPS’e yükseltir ve konsolda uyarı gösterir.

Karma içerik arama sıralamasını doğrudan düşürür mü?

Google belgeleri karma içeriğin sıralamayı doğrudan düşürdüğünü söylemez. Google, HTTPS sayfayı HTTP karşılığına tercih ettiğini, ancak geçersiz sertifika ya da görsel dışındaki güvenli olmayan bağımlılık gibi sorunlarda bu tercihin bozulabileceğini söyler. Etkinin boyutu belgelerde sayısallaştırılmaz; bu yüzden karma içeriği sıralama garantisi vaadi olarak değil, temizlenmesi gereken bir kalite sorunu olarak ele alın.

HSTS nedir ve HTTPS yönlendirmesinin yerine geçer mi?

HSTS, tarayıcıya sitenin yalnızca HTTPS ile açılması gerektiğini söyleyen bir yanıt başlığıdır. Yönlendirmenin yerine geçmez: başlık yalnızca HTTPS yanıtında geçerlidir, ilk ziyarette etkisizdir ve Google’ın belgesine göre canonical ile yönlendirme gibi yöntemlerin üstüne eklenen bir güçlendirmedir. HTTP istekleri için 301 ya da 308 yönlendirmesi gerekir.

HSTS preload listesine ne zaman girilmeli?

Yalnızca ana alan adı ve tüm alt alan adları şimdi ve uzun vadede HTTPS sunabilecekse. Liste dahil iç alt alan adlarını kapsar, kaldırma yavaştır ve Chrome kullanıcıları için tarayıcı güncellemesine bağlıdır. hstspreload.org sitesi HSTS’i önerdiği hâlde preload’ı genel olarak önermediğini belirtir.

HSTS’i yanlışlıkla açtım, nasıl kapatırım?

HTTPS yanıtında max-age=0 gönderin. Bu yalnızca tarayıcı güvenli bir istek yapıp yanıtı aldığında etki eder; başlığı yanıtlardan sadece çıkarmak önceki politikayı silmez, süresi dolana kadar geçerli kalır. Preload listesine girildiyse süreç ayrı ve yavaştır.

Tarayıcı görselleri otomatik yükseltiyorsa düzeltmeye gerek var mı?

Evet. Yükseltme hedef sunucunun aynı kaynağı HTTPS ile de sunduğunu varsayar; sunmuyorsa görsel kırılır. IP adresiyle çağrılan görseller yükseltilmez, doğrudan engellenir. Ayrıca srcset ve CSS içindeki bazı kullanımlar engellenebilir sınıfta görünebilir. Adresleri HTTPS’e çevirmek hem güvenli hem de tahmin edilebilir sonuç verir.

Sonuç

Karma içerik ve HSTS, HTTPS geçişinin kapanış kontrolleridir ve sıraları önemlidir. Önce tarayıcıların neyi engellediğini ve neyi sessizce yükselttiğini bilin, sonra kaynak adreslerini şablon, veritabanı, üçüncü taraf bileşen ve sayfa dışı sinyal katmanlarında ayrı ayrı temizleyin. HSTS’i ancak sertifika, yönlendirme ve alt alan adı envanteri hazır olduğunda ve kısa bir max-age ile açın; preload’ı ise geri dönüşü zor, ayrı bir karar olarak değerlendirin. Her aşamada kanıt tutun: konsol çıktısı, tarama raporu, yönlendirme testi ve geri dönüş notu.

Teknik düzen hazır olduğunda, taranan ve dizine alınan sayfaların içeriği de sonucu belirler. Planlı, kaynaklı ve okunabilir metinler için Akua Adforce’ta SEO içerik yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır. Bu yazıdaki öneriler genel teknik rehberdir ve belirli bir sıralama, tarama sıklığı ya da dizinleme sonucu garanti etmez.