SSL/TLS ve HSTS Header Kontrolü

SSL/TLS, istemci ile sunucu arasındaki veri iletimini şifreleyen kriptografik güvenlik protokolüdür. 2026 itibarıyla TLS 1.3 handshake süresi ortalama 100 ms altına düşmüş olup, bu geçiş arama motoru sıralamalarında doğrudan pozitif sinyal üretmektedir. HSTS header yapılandırması ise bu güvenlik katmanını kalıcı hale getiren zorunlu tamamlayıcıdır.

SSL ve TLS Protokollerinin Teknik Ayrımı

SSL (Secure Sockets Layer) ve TLS (Transport Layer Security) sıklıkla birbirinin yerine kullanılsa da teknik açıdan aynı protokol değildir. SSL 3.0, 2015 yılında IETF tarafından resmen kullanımdan kaldırılmıştır. Bugün "SSL sertifikası" olarak adlandırılan yapı, gerçekte TLS protokolü üzerinde çalışır.

Bu ayrım yalnızca terminolojik değildir. SSL 3.0 ve TLS 1.0/1.1 versiyonları POODLE, BEAST ve CRIME gibi bilinen saldırı vektörlerine açıktır. Dolayısıyla sunucunuzda bu eski protokol versiyonlarının aktif olup olmadığını kontrol etmek, güvenlik denetiminin ilk adımıdır. Nginx yapılandırmasında ssl_protocols TLSv1.2 TLSv1.3; direktifiyle yalnızca güncel versiyonları aktif bırakmak, söz konusu açıkları kapatır.

TLS 1.3 Handshake Sürecinin Performans Avantajı

TLS 1.2'de handshake süreci iki tam gidiş-dönüş (2-RTT) gerektirirken, TLS 1.3 bunu tek gidiş-dönüşe (1-RTT) indirmiştir. Bu fark, özellikle mobil ağlarda ve yüksek gecikmeli bağlantılarda sayfa yükleme süresini doğrudan etkiler. Daha önce bağlantı kurulmuş istemciler için sıfır gidiş-dönüş (0-RTT) resumption desteği de bu versiyonla gelmiştir.

Ancak 0-RTT özelliği replay attack riskini beraberinde getirir. Bu nedenle 0-RTT yalnızca idempotent istekler (GET gibi) için etkinleştirilmelidir. POST veya PUT gibi durum değiştiren isteklerde 0-RTT kullanımı güvenlik açığı oluşturur. Nginx'te bu kontrol ssl_early_data on; direktifiyle aktifleştirilir, ancak uygulama katmanında Early-Data header'ının kontrol edilmesi zorunludur.

Sertifika Türleri ve Doğrulama Seviyeleri

TLS sertifikaları üç doğrulama seviyesinde sınıflandırılır: Domain Validation (DV), Organization Validation (OV) ve Extended Validation (EV). DV sertifikaları yalnızca alan adı sahipliğini doğrular ve dakikalar içinde alınabilir. OV sertifikaları kuruluş bilgilerini teyit eder. EV sertifikaları ise en kapsamlı doğrulama sürecini içerir.

SEO perspektifinden bakıldığında, sertifika türü sıralama algoritmasında doğrudan bir faktör değildir. Bot, DV ile EV arasında ayrım yapmaz. Aksine kritik olan, sertifikanın geçerli olması, zincir bütünlüğünün sağlanması ve mixed content hatası üretmemesidir. Dolayısıyla teknik SEO denetimlerinde sertifika türünden çok, sertifika zincirinin eksiksizliğine ve süresinin dolup dolmadığına odaklanmak gerekir.

Sertifika Zinciri Bütünlüğü ve Ara Sertifika Eksikliği

Bir TLS sertifikası tek başına çalışmaz. Root CA (Kök Sertifika Otoritesi) ile sunucu sertifikası arasında bir veya birden fazla ara sertifika (intermediate certificate) bulunur. Sunucu yapılandırmasında bu ara sertifikaların eksik bırakılması, belirli tarayıcı ve bot kombinasyonlarında güven zincirinin kırılmasına neden olur.

Bu sorun masaüstü tarayıcılarda genellikle fark edilmez, çünkü modern tarayıcılar eksik ara sertifikayı cache'den tamamlayabilir. Ancak Googlebot ve diğer tarama botları bu toleransı göstermez. Log dosyalarında belirli sayfaların taranmadığını fark edip nedenini araştırdığınızda, sorunun ara sertifika eksikliği olduğunu keşfetmek nadir değildir. openssl s_client -connect example.com:443 -servername example.com komutuyla sertifika zincirini doğrulayabilir ve eksik halkaları tespit edebilirsiniz.

Mixed Content Hatalarının SEO Etkisi ve Tespiti

Mixed content, HTTPS üzerinden sunulan bir sayfada HTTP kaynaklarının (resimler, scriptler, CSS dosyaları) yüklenmesidir. Bu durum tarayıcılarda güvenlik uyarısı tetikler ve sayfanın "tam güvenli" statüsünü kaybetmesine neden olur. Arama motoru botları için bu sinyal, sitenin HTTPS geçişinin tamamlanmamış olduğu anlamına gelir.

Mixed content iki kategoride incelenir: passive mixed content (resimler, videolar) ve active mixed content (scriptler, iframe'ler). Active mixed content modern tarayıcılarda otomatik olarak engellenir ve sayfa işlevselliğini bozar. Tespiti için Chrome DevTools Console sekmesinde "Mixed Content" uyarılarını filtreleyebilirsiniz. Toplu tespit için Screaming Frog'da "Insecure Content" raporunu çalıştırarak tüm sitedeki HTTP kaynak referanslarını listeleyip, bu URL'leri HTTPS karşılıklarıyla değiştirin.

HTTPS Geçişinde Canonical ve Redirect Yapılandırması

HTTP'den HTTPS'e geçiş, yalnızca sertifika kurmak değildir. Tüm HTTP URL'lerin 301 redirect ile HTTPS karşılıklarına yönlendirilmesi, canonical etiketlerin HTTPS versiyonuna güncellenmesi ve internal linklerin düzeltilmesi gerekir. Bu adımlardan birinin atlanması, duplicate content sorununa ve tarama bütçesi israfına yol açar.

Nginx'te bu yönlendirme şu şekilde yapılandırılır:

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

Apache'de ise .htaccess dosyasına şu kurallar eklenir:

    
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]     
    

Redirect sonrasında Search Console'da hem HTTP hem HTTPS property'lerinin ayrı ayrı doğrulanmış olması ve sitemap'in HTTPS URL'leri içermesi zorunludur.

HSTS Header Yapısının Teknik Anatomisi

HSTS (HTTP Strict Transport Security), tarayıcıya belirli bir süre boyunca siteye yalnızca HTTPS üzerinden bağlanmasını emreden bir HTTP yanıt başlığıdır. Bu başlık aktif olduğunda, kullanıcı adres çubuğuna http:// yazsa bile tarayıcı otomatik olarak HTTPS'e yönlendirir. Böylece ilk HTTP isteği ve 301 redirect aşaması tamamen ortadan kalkar.

HSTS header'ının temel yapısı şöyledir:

    
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
    

Bu üç parametrenin her biri ayrı bir işlev taşır. max-age değeri saniye cinsinden HSTS politikasının geçerlilik süresini belirler. includeSubDomains direktifi tüm alt alan adlarını kapsama alır. preload ise siteyi tarayıcıların yerleşik HSTS listesine dahil etme talebini bildirir.

max-age Değerinin Stratejik Belirlenmesi

max-age parametresi, HSTS politikasının tarayıcı belleğinde ne kadar süre tutulacağını tanımlar. 31536000 saniye (1 yıl) standart üretim değeridir. Ancak HSTS'yi ilk kez uygulayan sitelerin doğrudan bu değerle başlaması risklidir.

Önerilen yaklaşım kademeli artıştır. İlk aşamada max-age=300 (5 dakika) ile başlayın. Site genelinde HTTPS yapılandırmasının sorunsuz çalıştığını teyit ettikten sonra bu değeri 604800 (1 hafta), ardından 2592000 (1 ay) ve son olarak 31536000 (1 yıl) seviyesine çıkarın. max-age değeri 1 yılın altında olan siteler preload listesine kabul edilmez. Bu kademeli geçiş, olası bir yapılandırma hatasında kullanıcıların siteye erişiminin uzun süre engellenmesini önler.

includeSubDomains Direktifinin Riskleri

includeSubDomains parametresi, HSTS politikasını ana domain altındaki tüm subdomain'lere uygular. Bu direktif, subdomain takeover saldırılarına karşı ek koruma sağlar. Ancak aktifleştirilmeden önce tüm subdomain'lerin HTTPS yapılandırmasının tamamlanmış olması zorunludur.

Sahadaki en sık karşılaşılan hata, bu direktifi aktifleştirdikten sonra HTTP üzerinde çalışan bir staging veya API subdomain'inin keşfedilmesidir. staging.example.com henüz HTTPS'e geçmemişken includeSubDomains aktifleştirilirse, o subdomain tamamen erişilemez hale gelir. Çözüm, tüm subdomain'leri listeleyip her birinin HTTPS durumunu doğrulamak ve ancak tam geçiş sağlandıktan sonra bu direktifi eklemektir.

HSTS Preload Listesine Dahil Olma Süreci

HSTS preload, tarayıcıların kaynak koduna gömülü bir HSTS listesine sitenizi ekletme sürecidir. Bu listeye dahil olan siteler için tarayıcı, ilk ziyarette bile HTTP bağlantısına izin vermez. Dolayısıyla "ilk istek HTTP üzerinden gider" açığı tamamen kapanır.

Preload listesine başvurmak için hstspreload.org adresini kullanın. Kabul şartları net ve kesindir: geçerli bir TLS sertifikası, tüm HTTP trafiğin HTTPS'e yönlendirilmesi, ana domain'de HSTS header'ının bulunması, max-age değerinin en az 31536000 olması, includeSubDomains ve preload direktiflerinin aktif olması. Listeye eklenmek haftalar sürebilir, ancak listeden çıkmak aylar alır. Bu nedenle preload başvurusu geri dönüşü zor bir karardır ve tüm altyapı kontrolleri tamamlanmadan yapılmamalıdır.

HSTS Header Yapılandırmasının Sunucu Bazında Uygulanması

HSTS header'ı sunucu yapılandırma dosyasında veya uygulama katmanında tanımlanır. Farklı sunucu yazılımları için yapılandırma sözdizimi değişir.

Nginx'te:

    
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    

Apache'de:

    
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    

Cloudflare kullanıyorsanız, bu başlık CDN panelinden SSL/TLS > Edge Certificates > HSTS yolunu izleyerek aktifleştirilebilir. Buradaki always parametresi kritiktir: Nginx'te bu parametre olmadan HSTS header'ı yalnızca başarılı (2xx, 3xx) yanıtlara eklenir. Hata sayfalarında header eksik kalır ve güvenlik açığı oluşur.

Certificate Transparency ve CT Log Takibi

Certificate Transparency (CT), bir alan adı için düzenlenen tüm TLS sertifikalarının herkese açık log sunucularına kaydedilmesini zorunlu kılan bir mekanizmadır. Bu sistem, yetkisiz sertifika düzenlemelerini tespit etmeye yarar. Kötü niyetli bir aktör, alan adınız için sahte bir sertifika düzenlettirirse CT loglarında bu kayıt görünür.

CT loglarını izlemek için crt.sh üzerinden alan adınızı sorgulayabilirsiniz. Bu sorgu, alan adınız için düzenlenmiş tüm sertifikaları listeler. Tanımadığınız bir sertifika otoritesinden düzenleme varsa, bu durum subdomain takeover veya man-in-the-middle girişimine işaret edebilir. LinkedIn üzerindeki güvenlik mühendisliği topluluklarında paylaşılan vaka analizleri gösteriyor ki, CT log takibini otomatize eden kurumlar, yetkisiz sertifika düzenlemelerini ortalama 4 saat içinde tespit edebilmektedir.

OCSP Stapling ile Sertifika Doğrulama Performansı

Bir tarayıcı HTTPS bağlantısı kurarken, sunucu sertifikasının iptal edilip edilmediğini kontrol etmek zorundadır. Geleneksel yöntemde tarayıcı, sertifika otoritesinin OCSP (Online Certificate Status Protocol) sunucusuna ayrı bir istek gönderir. Bu ek istek, bağlantı kurma süresini uzatır ve gizlilik endişesi yaratır.

OCSP Stapling, bu sorunu sunucu tarafında çözer. Sunucu, OCSP yanıtını periyodik olarak kendisi alır ve TLS handshake sırasında sertifika ile birlikte istemciye iletir. Böylece tarayıcı harici bir sorgu yapmak zorunda kalmaz. Nginx'te bu özellik şu şekilde aktifleştirilir:

    
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
    

Bu yapılandırma, TLS handshake süresini ortalama 30-100 ms kısaltır ve Core Web Vitals metriklerine doğrudan olumlu yansır.

Cipher Suite Seçiminin Güvenlik ve Uyumluluk Dengesi

Cipher suite, TLS bağlantısında kullanılacak şifreleme algoritmalarının kombinasyonunu tanımlar. Anahtar değişimi, şifreleme ve mesaj doğrulama algoritmalarının doğru seçimi hem güvenlik hem de tarayıcı uyumluluğu açısından kritiktir.

TLS 1.3 ile cipher suite seçimi büyük ölçüde basitleşmiştir. Bu versiyon yalnızca üç cipher suite destekler: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 ve TLS_CHACHA20_POLY1305_SHA256. Eski ve zayıf algoritmaları (RC4, 3DES, MD5) desteklemenin hiçbir geçerli nedeni yoktur. Nginx'te cipher suite yapılandırması ssl_ciphers direktifiyle kontrol edilir. Mozilla'nın SSL Configuration Generator aracını kullanarak sunucu türünüze ve hedef uyumluluğunuza uygun cipher suite listesini otomatik olarak oluşturabilirsiniz.

HTTP Security Header Ekosistemi ve HSTS'nin Yeri

HSTS, tek başına yeterli bir güvenlik önlemi değildir. Kapsamlı bir HTTP güvenlik header stratejisi; Content-Security-Policy (CSP), X-Content-Type-Options, X-Frame-Options, Referrer-Policy ve Permissions-Policy başlıklarını da içerir. Bu başlıkların her biri farklı bir saldırı vektörüne karşı koruma sağlar.

securityheaders.com üzerinden sitenizi taratarak mevcut header yapılandırmanızın puanını görebilirsiniz. A+ skoru almak için minimum gereksinim tüm temel güvenlik başlıklarının doğru yapılandırılmasıdır. Güvenlik header eksikliği, botun güven skorlamasında negatif sinyal üretir ve özellikle YMYL (Your Money Your Life) kategorisindeki sitelerde sıralama kaybına yol açabilir.

Content-Security-Policy ile Mixed Content Önleme

CSP header'ı, sayfada yüklenecek kaynakların hangi kaynaklardan gelebileceğini tanımlayan güçlü bir güvenlik mekanizmasıdır. HTTPS geçişinde mixed content sorunlarını kökten çözmek için CSP'nin upgrade-insecure-requests direktifi kullanılır. Bu direktif, tarayıcıya sayfadaki tüm HTTP kaynak referanslarını otomatik olarak HTTPS'e yükseltmesini emreder.

Uygulaması şu şekildedir:

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

Bu tek satırlık başlık, özellikle binlerce sayfaya sahip sitelerde mixed content temizliğinin ilk acil müdahalesidir. Ancak kalıcı çözüm değildir. Kaynak kodundaki HTTP referanslarının HTTPS olarak güncellenmesi yine zorunludur, çünkü tüm tarayıcılar ve botlar CSP'yi aynı düzeyde işlemez.

TLS Sertifika Süresinin İzlenmesi ve Otomasyon

Sertifika süresinin dolması, sitenin tamamen erişilemez hale gelmesine neden olur. Tarayıcılar, süresi dolmuş sertifika için kullanıcıya tam sayfa güvenlik uyarısı gösterir. Botlar ise o URL'yi taramayı bırakır. Bu kesinti birkaç saat bile sürse, indekslemede ciddi kayıplara yol açar.

Let's Encrypt sertifikaları 90 günlük döngülerle çalışır ve certbot aracıyla otomatik yenilenebilir. Ancak otomasyona güvenmek yetmez; otomasyon başarısız olduğunda sizi uyaracak bir izleme katmanı da gereklidir. Certbot'un cron job yapılandırmasını certbot renew --deploy-hook "systemctl reload nginx" komutuyla oluşturun ve Uptime Robot veya benzeri bir izleme aracında sertifika süresi kontrolü tanımlayın. Sertifika süresinin dolmasına 14 gün kala uyarı tetikleyen bir monitoring kuralı, bu riski ortadan kaldırır.

SSL/TLS Yapılandırma Testinin Sistematik Uygulanması

Sunucu yapılandırmasının doğruluğunu test etmeden üretime almak, güvenlik denetiminin en temel ihlalidir. Bu testin standart aracı SSL Labs'ın (ssllabs.com) sunduğu SSL Server Test'tir. Bu araç, sertifika zinciri bütünlüğü, protokol desteği, cipher suite güvenliği, key exchange gücü ve bilinen açıklara (Heartbleed, POODLE, DROWN) karşı direnci tek bir raporda özetler.

A+ skoru almak için TLS 1.2 ve 1.3 dışındaki tüm protokollerin devre dışı bırakılması, Forward Secrecy destekleyen cipher suite'lerin önceliklendirilmesi ve HSTS header'ının aktif olması gerekir. Her sunucu yapılandırma değişikliğinden sonra bu testi tekrarlamak, standart bir operasyonel adım olmalıdır. Çoğu uzman aksini iddia etse de, SSL Labs skoru tek başına güvenliğin tam göstergesi değildir; ancak bilinen konfigürasyon hatalarını yakalamak için en pratik başlangıç noktasıdır.

Subdomain Takeover Riski ve TLS Koruma Katmanı

Subdomain takeover, kullanılmayan bir subdomain'in DNS kaydının hâlâ aktif olduğu ancak arkasındaki servisin (hosting, CDN, SaaS) iptal edildiği durumda gerçekleşir. Saldırgan, aynı serviste yeni bir hesap oluşturarak o subdomain'i kendi kontrolüne alabilir. Bu durumda HSTS includeSubDomains direktifi aktifse, saldırganın HTTP üzerinden sahte içerik sunması engellenir; ancak saldırgan kendi TLS sertifikası düzenlettirirse bu koruma yetersiz kalır.

Korunmanın ilk adımı, tüm DNS kayıtlarını periyodik olarak taramak ve kullanılmayan subdomain CNAME kayıtlarını silmektir. dig veya nslookup komutlarıyla subdomain'lerinizin hangi servislere yönlendiğini kontrol edin. CNAME kaydının hedefinde "404" veya varsayılan servis sayfası dönen subdomain'ler, takeover riskinin doğrudan göstergesidir.

Core Web Vitals Üzerinde TLS Performans Etkisi

TLS handshake süresi, Time to First Byte (TTFB) metriğinin doğrudan bileşenidir. TTFB ise Largest Contentful Paint (LCP) skorunu etkiler. Dolayısıyla TLS yapılandırması, Core Web Vitals performansına teknik düzeyde bağlıdır.

TLS 1.3 geçişi, OCSP Stapling aktivasyonu ve HTTP/2 multiplexing desteğinin birlikte uygulanması, handshake süresini toplamda 100-200 ms kısaltabilir. Bu iyileşme, özellikle mobil ağlarda LCP skoruna doğrudan yansır. Chrome DevTools'un Security sekmesinden bağlantı protokolü versiyonunu, cipher suite'i ve sertifika detaylarını tek bir görünümde inceleyebilirsiniz. Lighthouse raporundaki TTFB değeriyle bu verileri çaprazlamak, TLS kaynaklı gecikmeleri izole etmenin en pratik yoludur.

Arama Motoru Botlarının HTTPS Doğrulama Davranışı

Googlebot, bir siteyi tararken TLS bağlantısını standart bir tarayıcı gibi doğrular. Sertifika hatası, zincir eksikliği veya protokol uyumsuzluğu durumunda bot, o sayfayı taramayı reddedebilir. Bu ret, Search Console'da "Sunucu hatası (5xx)" veya "DNS çözümleme hatası" olarak raporlanabilir; gerçek neden ise TLS katmanındadır.

Bu sorunu teşhis etmek için log dosyalarında Googlebot'un aldığı HTTP durum kodlarını filtreleyin. 200 kodu alması gereken URL'lerde 0 veya bağlantı zaman aşımı (connection timeout) görüyorsanız, sorun büyük olasılıkla TLS katmanındadır. curl -I -v https://example.com/sorunlu-sayfa 2>&1 | grep -i "SSL\|TLS\|certificate" komutuyla TLS handshake sürecini detaylı olarak izleyebilir ve botun karşılaştığı hatayı simüle edebilirsiniz.

HTTP/2 ve HTTP/3 Protokollerinin TLS Bağımlılığı

HTTP/2 protokolü, teknik olarak şifrelenmemiş bağlantıda da çalışabilir, ancak pratikte tüm büyük tarayıcılar HTTP/2'yi yalnızca TLS üzerinde destekler. HTTP/3 ise QUIC protokolünü temel alır ve TLS 1.3'ü yapısal olarak zorunlu kılar. Bu durum, TLS yapılandırmasını yalnızca bir güvenlik önlemi olmaktan çıkarıp, performans optimizasyonunun temel bileşeni haline getirmiştir.

HTTP/3'ün sunduğu 0-RTT bağlantı kurulumu, UDP tabanlı iletişim ve bağımsız akış multiplexing'i, TLS 1.3 altyapısı olmadan çalışmaz. Dolayısıyla HTTP/3'e geçiş planlarken TLS 1.3 desteğinin aktif ve doğru yapılandırılmış olması ön koşuldur. Nginx'te HTTP/3 desteği listen 443 quic; direktifiyle aktifleştirilir ve Alt-Svc header'ı ile tarayıcılara bildirilir.

Çoklu Domain ve Wildcard Sertifika Yönetimi

Birden fazla alan adı veya subdomain işleten siteler için sertifika yönetimi karmaşıklaşır. Wildcard sertifika (*.example.com), ana domain altındaki tüm birinci seviye subdomain'leri tek sertifika ile kapsar. Ancak ikinci seviye subdomain'leri (sub.sub.example.com) kapsamaz.

SAN (Subject Alternative Name) sertifikaları, farklı alan adlarını tek bir sertifikada birleştirmeye olanak tanır. E-ticaret altyapısında ana site, CDN subdomain'i, API subdomain'i ve mobil subdomain'inin tamamını tek bir SAN sertifikasıyla yönetmek hem operasyonel basitlik hem de yenileme takibi açısından avantajlıdır. Let's Encrypt ile SAN sertifikası almak için certbot komutuna -d example.com -d www.example.com -d api.example.com parametrelerini eklemek yeterlidir.

SSL/TLS ve HSTS Denetimi İçin Kontrol Matrisi

Kapsamlı bir güvenlik denetimi, sistematik kontrol gerektirir. Aşağıdaki maddeler, her teknik SEO denetiminde kontrol edilmesi gereken kritik noktaları içerir:

• TLS 1.2 ve 1.3 dışındaki protokolleri devre dışı bırakın: SSL 3.0, TLS 1.0 ve TLS 1.1 bilinen saldırı vektörlerine açıktır ve modern tarayıcılar tarafından zaten desteklenmemektedir.
• Sertifika zincir bütünlüğünü doğrulayın: Ara sertifika eksikliği, botların ve bazı mobil tarayıcıların siteye erişimini engelleyebilir.
• Mixed content taraması yapın: Tek bir HTTP kaynak referansı bile sayfanın güvenlik statüsünü düşürür ve tarayıcıda uyarı tetikler.
• HSTS header'ını kademeli olarak uygulayın: Düşük max-age değeriyle başlayıp aşamalı olarak artırmak, yapılandırma hatalarının etkisini sınırlar.
• OCSP Stapling'i aktifleştirin: TLS handshake süresini kısaltarak hem kullanıcı deneyimini hem de bot tarama performansını iyileştirir.
• CT loglarını izleyin: Alan adınız için yetkisiz sertifika düzenlemelerini erken tespit etmek, subdomain takeover ve phishing saldırılarına karşı kritik bir savunma hattıdır.

Preload Listesinden Çıkışın Operasyonel Maliyeti

HSTS preload listesine dahil olmak kolay, çıkmak ise operasyonel bir kabus olabilir. Listeden çıkarılma talebi hstspreload.org üzerinden yapılır, ancak tarayıcıların güncelleme döngüsü nedeniyle bu değişikliğin tüm kullanıcılara ulaşması 3-6 ay sürer. Bu süre zarfında, sitenizde HTTPS yapılandırmasında bir sorun varsa, etkilenen kullanıcılar siteye erişemez.

İşin mutfağında durum farklıdır: preload listesine eklenme kararı, altyapı ekibinin "geri dönüşü olmayan bir düğme" olarak değerlendirmesi gereken bir adımdır. HTTPS altyapısının %100 stabil olduğundan emin olmadan, tüm subdomain'lerin kontrol altında olduğunu doğrulamadan ve sertifika yenileme otomasyonunun hatasız çalıştığını test etmeden bu adımı atmak, ileride ciddi erişilebilirlik sorunlarına davetiye çıkarır.

TLS yapılandırması ve HSTS politikası, bir sitenin hem güvenlik duruşunu hem de teknik SEO performansını doğrudan belirler. Bu iki katmanı birlikte yönetmeyen siteler, arama motoru botlarıyla güven ilişkisini kontrol altında tutamaz.