HSTS: HTTP Katı Taşıma Güvenliği SEO İçin

TL;DR — HSTS, sunucunuzun tarayıcılara gönderdiği ve “sitem için her zaman HTTPS kullan — asla düz HTTP değil” diyen küçük bir talimattır. Normal bir HTTP→HTTPS yönlendirmesinin açık bıraktığı küçük bir güvenlik açığını kapatır ve SEO’ya zarar vermez. Ancak kasıtlı olarak katıdır: bir kez açıldığında, bozuk bir sertifika sitenizi ziyaretçilerin uyarıyı tıklayıp geçmesine izin vermeden çökertir. Yalnızca HTTPS kurulumunuz gerçekten sağlam olduğunda açın.

HSTS nedir

Zaten HTTPS üzerinde olmanız gerektiğini biliyorsunuz — sitenizin şifreli, kilitli sürümü. Bunu zorlamanın normal yolu bir yönlendirmedir: biri http://yoursite.com yazdığında, sunucunuz onu 301 adresine bir https://yoursite.com yönlendirmesi gönderir. Bu işe yarar, ancak küçük bir boşluk vardır. İlk istek — yönlendirme tetiklenmeden önceki istek — hâlâ güvenli olmayan HTTP üzerinden gider. Aynı Wi-Fi’de oturan bir saldırgan bu pencerede saldırabilir.

HSTS — HTTP Katı Aktarım Güvenliği — bu boşluğu kapatır. Sunucunuzun yanıtlarına eklediği kısa bir talimattır (bir “başlık”) — ancak yalnızca gerçekten güvenli bir bağlantı üzerinden sunulanlara; düz HTTP üzerinden gönderilen aynı başlık yok sayılır, çünkü aksi takdirde bir saldırgan onu enjekte edebilir veya kaldırabilir — bu, o tarayıcıya şunu söyler: önümüzdeki birkaç ay boyunca bu site için HTTP’yi asla deneme — doğrudan HTTPS’ye git. Bu, her tarayıcının kendisi için öğrenip sakladığı bir politikadır, sunucunuzu değiştiren bir şey değildir. Bir tarayıcı bunu gördüğünde, cihazdan hiçbir şey çıkmadan önce http:// bağlantılarını kendi başına https:// sürümüne yükseltir. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

HSTS SEO’ya yardımcı olur mu yoksa zarar verir mi?

Doğrudan ikisi de değil. HSTS bir güvenlik ve güven özelliğidir, bir sıralama kaldıracı değildir. Sizi sonuçlarda yukarı taşımaz — ancak doğru yapılırsa size zarar da vermez. Anlaşılması gereken tek şey, HSTS’nin yönlendirmelerinizin yerine geçmediğidir. HTTP’den HTTPS’ye gerçek sunucu tarafı 301 yönlendirmelerinize hâlâ ihtiyacınız var, çünkü Google ve Bing’in gerçekte gördüğü ve kullandığı şey budur. HSTS, gerçek insan ziyaretçiler için tarayıcının içinde çalışır; tarayıcılar buna güvenmez. İkisini de koruyun.

Tek büyük uyarı

HSTS kasıtlı olarak affetmez. Bir tarayıcı sitenizin yalnızca HTTPS olduğunu “öğrendiğinde”, sertifikanızın süresi dolarsa veya yanlış yapılandırılırsa siteyi hiç yüklemeyi reddeder — “yine de devam et” düğmesi olmadan. Bütün mesele budur (saldırganların insanları sahte bir HTTP sürümüne kandırmasını engeller), ancak bu, süresi dolmuş bir sertifikanın “can sıkıcı uyarı” durumundan “daha önce ziyaret etmiş herkes için site çöktü” durumuna geçmesi anlamına gelir.

Ayrıca preload adı verilen ve alan adınızı tarayıcının kendisine işleyen süper güçlü bir sürüm de var. Harika, ancak daha sonra preload listesinden çıkmak yavaş ve acı vericidir — aylar düşünün. Yani preload tek yönlü bir kapıdır: yalnızca emin olduğunuzda içinden geçin. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

Başlık sözdizimini, tarayıcıların asla görmediği tarayıcıya özel dahili yönlendirmeyi, preload gereksinimlerini ve gerçek kilitlenme senaryolarını mı istiyorsunuz? Gelişmiş sekmesine geçin.

TL;DR — HSTS is the Strict-Transport-Security response header, honored only when a browser receives it over a secure connection, and stored per-client as future policy for that host. It closes the “first request problem” a 301 alone leaves open: the initial HTTP request from a new visitor is insecure until the redirect fires, and that’s the window an SSL-stripping attacker wants. Three directives: max-age (required, seconds), includeSubDomains, preload. When a browser enforces HSTS it rewrites the URI to HTTPS internally, before any request reaches a server — RFC 6797 doesn’t mandate a specific status code for that rewrite, though tools often surface it as a 307 — so your server-side 301s are still mandatory for search engines and link equity; HSTS is on top of them, not instead. Preload bakes your domain into the browser via hstspreload.org (requires max-age ≥ 31536000, includeSubDomains, and preload) and is close to irreversible — removal is a separate submission that takes months to reach users. And HSTS is designed to hard-fail on any cert error, so enable it only when HTTPS is robust across every subdomain.

The HTTPS hub introduces HSTS as a browser-layer protection that sits on top of your 301s. This page is the deep dive: the exact header syntax, the internal redirect that trips SEOs up, the preload list’s near-irreversibility, and the real-world ways HSTS locks people out.

HSTS’nin gerçekten çözdüğü sorun: ilk istek

Düzgün bir şekilde taşınmış bir site hayal edin. Her http:// URL’si https:// karşılığına 301 yönlendirir, sertifika geçerlidir, canonical’lar HTTPS’yi işaret eder. Hava geçirmez görünüyor. Pek de değil.

Yepyeni bir ziyaretçi yoursite.com yazdığında (şema olmadan) veya eski bir http://yoursite.com bağlantısını tıkladığında, tarayıcının ilk isteği düz HTTP üzerinden gider. Sunucunuz 301 ile yanıt verir ve sonraki her istek güvenlidir. Ancak bu tek ilk gidiş-dönüş açıkta gerçekleşti — ve aynı ağdaki bir SSL soyma saldırganının istediği pencere tam olarak budur. HTTP isteğini yakalarlar, sunucunuza HTTPS’yi proxy’lerken kurbanı HTTP’de tutarlar ve her şeyi okur veya yeniden yazarlar.

HSTS eliminates that window for anyone who has visited before. web.dev is direct about the mechanism: “use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (web.dev). That last clause matters for performance too: a returning browser skips the HTTP→HTTPS round-trip entirely. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

Kesin olmaya değer iki sınır koşulu. İlk olarak, HSTS saklanan, istemci başına politikadır — güvenli bir bağlantı üzerinden iletilen bir başlıktan öğrenilen, o ana bilgisayar için o tek tarayıcının kendi durumunda yaşar; bir HTTP yanıtında gönderilen aynı başlık tamamen yok sayılır (düz HTTP’ye başlık enjekte edebilen veya kaldırabilen bir saldırgan aksi takdirde onu etkisiz hale getirebilir) ve onu hiç almamış bir istemci — yeni bir kurulum, farklı bir tarayıcı, bir tarayıcı — uygulanacak bir politikaya sahip değildir. İkinci olarak, yeniden yazma şema ve bağlantı noktasına duyarlıdır: örtük bir 80 numaralı bağlantı noktası isteği, örtük bir 443 numaralı bağlantı noktası isteği olur, ancak orijinal URI açıkça varsayılan olmayan bir bağlantı noktası adlandırdıysa, tarayıcı aynı bağlantı noktası numarasını korur ve bunun yerine HTTPS üzerinden bağlanır.

Başlık sözdizimi

HSTS, en fazla üç yönergeye sahip tek bir yanıt başlığıdır. MDN başına formlar şunlardır:

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

• max-age=<seconds> — zorunlu. “Tarayıcının, bir ana bilgisayara yalnızca HTTPS üzerinden erişilebileceğini hatırlaması gereken süre, saniye cinsinden” (MDN). 31536000 bir yıl; 63072000 iki yıldır. Saat, başlığı taşıyan her yanıtta sıfırlanır, bu nedenle aktif bir site politikasını sürekli yeniler. Bu, istemci başına göreli bir durumdur: başlığı kaldırmak onu hemen temizlemez — politikayı zaten öğrenmiş bir tarayıcı, saklanan max-age süresi dolana kadar onu uygulamaya devam eder. HSTS’yi zaten öğrenmiş istemciler için kapatmak istiyorsanız, güvenli bir yanıt üzerinden aktif olarak max-age=0 sunmanız gerekir; tarayıcı bir sonraki güvenli ziyaretinde politikayı unutur. (max-age=0 yalnızca öğrenilmiş bir politikayı temizler — ayrı ön yükleme listesinden bir alan adını kaldırmaz.)
• includeSubDomains — isteğe bağlı. “Bu yönerge belirtilirse, HSTS politikası ana bilgisayarın alan adının tüm alt alan adları için de geçerlidir” (MDN). Eşit ölçüde güçlü ve tehlikeli — aşağıdaki kilitlenme senaryolarına bakın.
• preload — isteğe bağlı. Tarayıcı ön yükleme listesinde yer alma niyetinizi bildiren bir bayrak. Kendi başına hiçbir şey yapmaz; hstspreload.org’a gönderim için bir ön koşuldur. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

Davranış, yine MDN’den: “Bir http URL’sini yüklemeden önce tarayıcı, alan adını HSTS ana bilgisayar listesine karşı kontrol eder. Alan adı, bir HSTS ana bilgisayarıyla büyük/küçük harf duyarlı olmayan bir eşleşmeyse veya includeSubDomains belirten bir ana bilgisayarın alt alan adıysa, tarayıcı URL şemasını https ile değiştirir.”

Dahili yükseltme tarayıcılarının asla görmediği şey (SEO’nun can alıcı noktası)

İşte HSTS hakkında en çok yanlış anlaşılan şey ve yönlendirmelerinizin yerini alamamasının nedeni.

Bir tarayıcı, HSTS altında bir http:// isteğini yükselttiğinde, herhangi bir ağ isteği yapılmadan önce URI’yi dahili olarak HTTPS’ye yeniden yazar — RFC 6797, şema değişiminin kendisini gerektirir ancak bunun için belirli bir durum kodu zorunlu kılmaz (RFC 6797 §8.3), bu nedenle belirli bir tarayıcı veya tarama aracı bu dahili adımı dilediği gibi temsil edebilir — çoğu bunu dahili bir 307 olarak görüntüler, ancak bu istemci/araca özgüdür, protokol garantisi değildir. SEO için önemli olan daha basittir ve etiketten bağımsız olarak geçerlidir: HTTP sürümü için hiçbir sunucuya başvurulmaz, bu nedenle hiçbir tarayıcı onu asla görmez. Googlebot ve Bingbot, geri dönen bir insanın Chrome’unun yaptığı gibi öğrenilmiş bir HSTS politikası taşımaz — sunucunuza taze olarak ulaşırlar ve orada görmeleri gereken şey gerçek, sunucu tarafı bir 301’dir. Evidence for this claim RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. Scope: RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. Confidence: high · Verified: 2026-07-17 RFC 6797 §8.3 — URI Loading and Port Mapping

So the rule is blunt: HSTS does not replace your server-side 301s. The 301 is what search engines use to understand the protocol move and to consolidate signals (301 and other permanent redirects don’t cause a loss in PageRank, per Google). The browser-only internal upgrade is a user-experience and security layer on top. You need both, doing different jobs:

• 301 (sunucu tarafı): tarayıcılar, dizinleme ve bağlantı değeri için.
• Dahili 307 tarzı yükseltme (tarayıcı tarafı, HSTS’den): geri dönen insanlar ve SSL soyma koruması için — kesin durum temsili istemci/araca göre değişir.

HSTS’nin “yönlendirmeyi hallettiği için 301’inizi bırakabileceğinizi” söyleyen herhangi bir rehber, size sessizce maliyet çıkaracak şekilde yanlıştır.

HSTS ön yükleme: neredeyse kalıcı sürüm

max-age, geri dönen ziyaretçileri korur, ancak bir başlangıç sorunu vardır: başlığınızı hiç almamış ilk kez gelen bir ziyaretçi, o ilk istekte hâlâ korumasızdır. Preload, alan adınızı tarayıcının kaynağına sabit kodlayarak bunu çözer; böylece tarayıcı, daha önce hiç bağlanmamış olsa bile HTTPS-only olduğunuzu bilir.

hstspreload.org adresinden kaydolursunuz. Gereksinimler kesindir:

1. “Serve a valid certificate.”
2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.”
3. “Serve all subdomains over HTTPS” — buna, bir DNS kaydı varsa özellikle www alt alan adı da dahildir.
4. Temel alan adının HTTPS yanıtında, “max-age en az 31536000 saniye (1 yıl) olmalıdır,” “includeSubDomains yönergesi belirtilmelidir,” ve “preload yönergesi belirtilmelidir.” şeklinde bir HSTS başlığı. (hstspreload.org)

Bu yüzden yukarıdaki iki yıllık örnek (max-age=63072000; includeSubDomains; preload) kişilerin gönderdiği biçimdir — bunların hstspreload.org tarafından yayınlanan tam gönderim gereksinimleri olduğunu unutmayın; bunları kalıcı bir sabit değil, güncel çıta olarak ele alın ve göndermeden önce canlı sayfayı yeniden kontrol edin.

İnsanlar bunları sürekli karıştırdığı için dört ayrı durumu netleştirmek yardımcı olur:

Kaldırma işlemi aynı dört durumu tersine ve aynı yavaşlıkta işletir: başlığınızdan preload yönergesini kaldırmak sizi kaldırma formuna uygun hale getirir, ardından gönderim bekliyor durumuna geçer ve alan adı, o sürüm döngüden çıkana kadar onu hâlâ yayınlayan bir tarayıcı sürümündeki herhangi bir kullanıcı için uygulanmaya devam eder.

Şimdi preload’u tek yönlü bir kapıya dönüştüren kısım. Gönderim sitesinin kendisinden: “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (hstspreload.org). Ve kendi tavsiyesi: “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.”

Pratik çeviri: preload gerçekten harika bir güvenlik duruşudur, ancak bir gün herhangi bir şeyi — eski bir alt alan adı, satın alınmış bir marka, dahili bir araç — düz HTTP üzerinden sunmanız gerekirse, her kullanıcıya ulaşmak için tarayıcı sürüm döngülerini beklemek zorunda kalırsınız. Kinsta’nın rehberi operasyonel gerçeği açıkça ortaya koyuyor: alan adınızı kaldırmanın zor ve zaman alıcı bir süreç olabileceğini. Preload’u kalıcı olarak kabul edin.

HSTS neden bir şeyler bozulduğunda can yakacak şekilde tasarlanmıştır

HSTS’nin katılığı bir hata değildir — tüm güvenlik garantisidir. web.dev takası şöyle açıklıyor: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (web.dev).

Google’ın vardığı sonuç, bunu açacak herkesin koluna dövme yapacağım cümledir: “HSTS’yi, sitenizin operasyonunun sertifika doğrulama hatalarıyla HTTPS dağıtımından asla kaçınmayacak kadar sağlam olduğundan emin olana kadar etkinleştirmeyin.” (web.dev).

“Sert başarısızlık” tam olarak şu anlama gelir: “yine de devam et” bağlantısı yok, tıklayıp geçme yok. Normal bir HTTPS sayfasında, süresi dolmuş bir sertifika, kararlı bir kullanıcının atlayabileceği korkutucu bir ara sayfa gösterir. Bir HSTS ana bilgisayarında tarayıcı doğrudan reddeder. Bu nedenle, kaçırılan bir sertifika yenilemesinin başarısızlık modu kategori değiştirir — *“insanlar korktuğu için trafik düşüşleri”*nden *“site, geri dönen her ziyaretçi için erişilemez.”*e.

Gerçek dünyadan kilitlenme senaryoları

HSTS’nin pratikte ısırdığı yollar neredeyse her zaman includeSubDomains veya ön yüklemenin gerçek HTTPS kapsamınızın önüne geçmesine dayanır:

• Unutulan alt alan adı. includeSubDomains üzerinde example.com ayarlarsınız, ancak legacy.example.com (eski bir uygulama, bir durum sayfası, bir satıcı aracı) yalnızca HTTP konuşur veya onu kapsamayan bir sertifikaya sahiptir. Başlığı gören her tarayıcı artık o alt alan adını yüklemeyi reddeder. O sunucuda hiçbir şey değişmedi — politika aşağı uzanıp onu bozdu.
• Joker sertifika boşluğu. Bir *.example.com joker karakteri foo.example.com’u kapsar ancak foo.bar.example.com’u kapsamaz (bir joker karakter bir DNS etiketi derinliğindedir). Daha derin bir alt alan adı HTTP’ye veya uyumsuz bir sertifikaya güveniyorsa, includeSubDomains onu kilitler.
• HSTS ana bilgisayarında süresi dolmuş sertifika. Yenileme otomasyonu başarısız olur, sertifika geçerliliğini yitirir ve atlanabilir bir uyarı yerine, politikanızı hatırlayan herkes için site kapalı olur — geçerli bir sertifika geri alana kadar ve yeniden bağlanıp taze bir güvenli yanıt alana kadar. Daha hızlı bir geçersiz kılma yoktur.
• Ön yükleme pişmanlığı. Ön yükleme yaptınız, ardından bir iş ihtiyacı alan adı altında yalnızca HTTP’ye özel bir hizmeti zorlar. Bunu geri almak iki ayrı, anlık olmayan iştir, tek değil: HTTPS üzerinden max-age=0 sunmak yalnızca eski max-age’leri zaten dolmadan önce yeniden bağlanan istemciler için öğrenilen politikayı temizlerken, alan adını ön yükleme listesinden çıkarmak, sunucunuzda yaptığınız her şeyden bağımsız olarak kullanıcılara ulaşması tarayıcı sürüm döngüleri — aylar — alan ayrı bir gönderimdir.
• Yerel geliştirme / hazırlama çakışmaları. example.com ile includeSubDomains’u ön yüklemek, aynı tepe noktası altındaki dev.example.com veya localhost tarzı bir dahili ana bilgisayarın HTTP’yi reddetmesine neden olarak yerel iş akışlarını şaşırtıcı şekillerde bozabilir.

Bunların hiçbiri HSTS’den kaçınma nedeni değil. Bunları aşamalı hale getirme nedenleridir: önce kısa max-age, her alt alan adını denetledikten sonra includeSubDomains ekleyin ve preload’u emin olduğunuzda saklayın.

HSTS bir sıralama hamlesi değildir (ve kurallaştırmaya dokunmaz)

To be clear on the SEO framing: HSTS is not a ranking signal. HTTPS itself is a deliberately tiny one — Google called it a “very lightweight signal” affecting fewer than 1% of queries — and HSTS is a layer on top of HTTPS, not a separate ranking input. It also doesn’t directly control canonicalization or indexing. Google’s own documentation is more specific than a flat “doesn’t matter,” though: Google prefers HTTPS as canonical over an equivalent HTTP page except when there’s an invalid certificate, insecure page dependencies, an HTTPS page that redirects to HTTP, or an HTTP rel="canonical" tag (Google: consolidating duplicate URLs). HSTS cannot fix or override any of that. It’s a browser-side policy with no influence on Google’s canonicalization logic — a bad certificate or a broken redirect chain can still push Google toward an HTTP canonical regardless of what your HSTS header says. Canonicalization is driven by your 301s, your certificate, your rel="canonical", and your internal links — HSTS earns its place for security, user trust, and closing the SSL-stripping gap — do it for those reasons, keep your 301s and certificate genuinely solid, and you’ll never see HSTS itself on a rankings report either way.

Daha geniş HTTP→HTTPS geçişini yapıyorsanız, HSTS açtığınız son şeydir, ilk değil — migrasyon oturduktan sonra, daha geniş site migrasyonu disiplininin bir parçası olarak devreye girer.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• HSTS = the Strict-Transport-Security response header. It tells browsers to always use HTTPS for your domain, closing the “first request problem” a 301 alone leaves open — the initial HTTP request from a new visitor is insecure until the redirect fires, which is the SSL-stripping window.
• Three directives: max-age (required, seconds; resets on every response; removing the header doesn’t clear a learned policy — you must serve max-age=0 over HTTPS instead), includeSubDomains (applies to all subdomains), and preload (a flag to opt into the browser preload list — token present, eligible, submitted, and actually listed are four separate states).
• The internal-upgrade crux: when a browser enforces HSTS it rewrites the URI to HTTPS internally before any request reaches a server — RFC 6797 doesn’t mandate a specific status code for that rewrite, though tools often show it as a 307 — so no server sees it and crawlers never see it. Your server-side 301s are still mandatory for search engines and link equity. HSTS is on top of your 301s, never instead of them.
• Preload hardcodes your domain into the browser via hstspreload.org (requires max-age ≥ 31536000, includeSubDomains, and preload). It’s close to irreversible — removal is a separate submission that takes months to reach users, browser by browser.
• Designed to hard-fail: an HSTS host with a broken/expired cert refuses to load, with no click-through. Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.”
• Lockout scenarios cluster around includeSubDomains and preload outrunning your HTTPS coverage: forgotten HTTP subdomains, wildcard-cert depth gaps, lapsed certs, preload regret, and staging collisions.
• Not a ranking signal — and can’t override canonicalization. Google prefers HTTPS as canonical except when a cert is invalid, dependencies are insecure, an HTTPS page redirects to HTTP, or the canonical tag points to HTTP — and HSTS has no power to fix or override any of that. Keep your 301s, certificate, and canonical tags doing the SEO work.

Resmi dokümantasyon

Tarayıcı ve standart ekiplerinden birincil kaynak dokümantasyon.

Google / web.dev

• Sunucularınızda HTTPS’yi etkinleştirin (web.dev) — HSTS bölümü: başlık, SSL-stripping, hard-fail uyarısı ve “HSTS’yi emin olmadan etkinleştirmeyin.”
• URL değişiklikleriyle site taşıma — sunucu tarafı 301’in neden hâlâ zorunlu olduğu (yönlendirmeler PageRank kaybettirmez).
• Sayfa deneyimini anlama — HTTPS’nin (ve dolayısıyla HSTS’nin) Google’ın çerçevesinde nerede yer aldığı.

Standartlar ve tarayıcı referansları

• MDN — Strict-Transport-Security — tam başlık sözdizimi, üç yönerge ve tarayıcının şemayı nasıl yükselttiği.
• RFC 6797 — HTTP Strict Transport Security (HSTS) — orijinal spesifikasyon.
• HSTS Preload Listesi gönderimi (hstspreload.org) — Chromium projesi tarafından sürdürülen kesin preload gereksinimleri ve kaldırma uyarıları.

Kaynaktan alıntılar

Google/web.dev ve Chromium preload hizmetinden kayıtlı ifadeler. Her bağlantı, kaynak sayfadaki alıntılanan pasaja atlar (veya onu işaret eder).

web.dev (Google) — HSTS’nin ne yaptığı ve uyarılar

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” Jump to quote
• “First, use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” Jump to quote
• “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” Jump to quote
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” Jump to quote

Chromium preload hizmeti — hstspreload.org

• “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (çeviri) «Preload listesine dahil olmanın kolayca geri alınamayacağını unutmayın. Alan adları kaldırılabilir, ancak bir değişikliğin Chrome güncellemesiyle kullanıcılara ulaşması aylar sürer ve diğer tarayıcılar hakkında garanti veremeyiz.» Kaynak
• “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (çeviri) «Tüm siteniz ve tüm alt alan adlarınız için uzun vadede HTTPS’yi destekleyebileceğinizden emin olmadıkça dahil olmayı talep etmeyin.» Kaynak

MDN — başlık davranışı

• “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (çeviri) «Bir http URL’sini yüklemeden önce tarayıcı, alan adını HSTS ana bilgisayar listesiyle karşılaştırır. Alan adı bir HSTS ana bilgisayarıyla büyük/küçük harf duyarsız bir eşleşmeyse veya includeSubDomains belirten birinin alt alan adıysa, tarayıcı URL şemasını https ile değiştirir.» Kaynak

HSTS’yi etkinleştirmeli miyim — ve ne kadar ileri gitmeli?

Bunu yukarıdan aşağıya doğru uygulayın. Her “hayır” bir dur işaretidir, bir belki değil. Başlamadan önce bir ayrım: aşağıdaki kesin max-age değerleri (canary için birkaç dakika, dinlenme durumu için bir yıl) Patrick’in operasyonel aşamalandırma önerileridir, protokol gereksinimleri değildir — tek zorunlu sayısal gereksinim, hstspreload.org’un ön yükleme minimumudur (max-age ≥ 31536000), bu adımda açıkça belirtilmiştir. Aşamalandırma sürelerini kendi risk toleransınıza ve dağıtım temponuza göre ayarlayın.

1. Tüm siteniz zaten geçerli bir sertifikayla HTTPS üzerinde mi ve geçiş oturdu mu?

• Hayır → HSTS’ye henüz dokunmayın. Önce HTTPS geçişini tamamlayın: her URL’ye 301 verin, karışık içeriği düzeltin, Search Console’da doğrulayın. HSTS son anahtar, ilk değil.
• Evet → devam edin.

2. Sertifika yenilemeniz otomatikleştirilmiş ve izleniyor mu (böylece bir gecikme size fark ettirmeden yaklaşamaz)?

• Hayır → Önce bunu düzeltin. Bir HSTS ana bilgisayarında süresi dolmuş bir sertifika bir uyarı değil, ciddi bir kesintidir. Otomatik yenileme + süre sonu uyarısını yerleştirin, sonra devam edin.
• Evet → devam edin. Henüz max-age olmadan kısa bir includeSubDomains (ör. birkaç dakikadan bir güne) etkinleştirin ve hiçbir şeyin bozulmadığını doğrulayın.

3. Her alt alan adını — www, eski uygulamalar, durum sayfaları ve satıcı ana bilgisayarları dahil — denetlediniz mi ve her birinin geçerli HTTPS sunduğunu doğruladınız mı?

• Hayır → includeSubDomains’i kapalı tutun. Şimdi eklemek, yalnızca HTTP veya uyumsuz sertifikalı herhangi bir alt alan adını kırarak aşağı uzanır.
• Evet → max-age’i bir yıla doğru yükseltin ve includeSubDomains ekleyin. Bu, çoğu site için güvenli ve güçlü bir dinlenme durumudur.

4. İlk ziyaret boşluğunu da kapatmak istiyor musunuz ve bu alan adı altında düz HTTP üzerinden bir daha asla bir şey sunmanız gerekmeyeceğinden emin misiniz?

• Hayır / emin değilim → Burada durun. max-age=31536000; includeSubDomains (ön yükleme yok) mükemmel bir duruştur. Emin değilseniz, ön yüklemenin marjinal kazancı geri döndürülemezliğine değmez.
• Evet, eminim → preload bayrağını ekleyin ve hstspreload.org adresine gönderin. Bunu kalıcı olarak kabul edin — kaldırma işleminin kullanıcılara ulaşması aylar sürer.

Separate, always-true branch: does enabling HSTS mean I can drop my 301s?

• Never. Crawlers don’t see HSTS’s browser-only internal upgrade. Keep your server-side 301s regardless of how far down this tree you go.

HSTS dağıtım kontrol listesi

Yukarıdan aşağıya çalışın — her aşama bir sonrakini kapılar. Buradaki aşamalı süreler operasyonel önerilerdir, protokol gereksinimleri değildir — tek zorunlu sayı, Aşama 3’teki ön yüklemenin max-age ≥ 31536000 minimumudur.

Herhangi bir şeyi etkinleştirmeden önce

• Tüm site (apex + www + tüm alt alan adları) geçerli bir sertifikayla HTTPS sunar.
• HTTP→HTTPS 301 yönlendirmeleri sunucu tarafında bire bir yerindedir.
• Sertifika otomatik yenilemesi yapılandırılmış ve süre sonu izleme/uyarı mevcuttur.
• HTTP→HTTPS geçişi oturdu (Search Console temiz, sıralama düşüşü yok).

Aşama 1 — güvenli olduğunu kanıtlayın

• Kısa bir Strict-Transport-Security (dakikalardan bir güne) ile max-age ekleyin.
• Henüz includeSubDomains yok. Henüz preload yok.
• Sitenin tarayıcılarda normal şekilde yüklendiğini ve hiçbir şeyin bozulmadığını doğrulayın.

Aşama 2 — taahhüt

• max-age’i en az 31536000’a (bir yıl) yükseltin.
• Geçerli HTTPS için her alt alan adını (www, eski, durum, satıcı dahil) denetleyin.
• Yalnızca bu denetim geçtikten sonra includeSubDomains ekleyin.
• Her alt alan adının HTTPS üzerinden yüklendiğini yeniden test edin.

Aşama 3 — ön yükleme (isteğe bağlı, neredeyse kalıcı)

• Bu alan adı altında bir daha asla HTTP’ye ihtiyacınız olmayacağından eminsiniz.
• Başlık max-age=31536000 (veya daha fazla) ; includeSubDomains; preload şeklindedir.
• 80 numaralı bağlantı noktasındaki HTTP, aynı ana bilgisayarda HTTPS’ye yönlendirir.
• hstspreload.org adresinde durumu gönderin ve doğrulayın.

Always true — don’t skip

• Server-side 301s stay in place (crawlers never see the browser-only internal upgrade).
• You have a documented rollback plan: max-age=0 served over HTTPS clears a learned (non-preloaded) policy for clients that reconnect before it would’ve expired anyway. Preloaded domains need the separate, slower removal-form process instead.

Zihinsel modeller

1. HSTS bir katmandır, bir yedek değil. Sunucu tarafı 301 = tarayıcılar ve bağlantı değeri için. Tarayıcı tarafı iç yükseltme (HSTS’den, genellikle 307 olarak gösterilir ancak RFC bu kesin kodu gerektirmez) = geri dönen insanlar ve SSL soyma koruması için. Farklı kitleler, farklı işler. Her ikisine de her zaman ihtiyacınız var; HSTS asla bir 301’i çıkarmaz.

2. HSTS, 301’in kapatamadığı bir boşluğu kapatır. Bir 301, ikinci istekten itibaren korur. İlk istek — yönlendirme tetiklenmeden önce — hâlâ HTTP’dir. HSTS (geri dönen ziyaretçiler için) ve ön yükleme (ilk kez gelen ziyaretçiler için), bu belirli pencereyi kapatan tek şeydir.

3. Kademeli artırın, asla atlamayın. max-age kısa → uzun. Çıplak başlık → includeSubDomains (bir alt alan adı denetiminden sonra) → preload (yalnızca eminseniz). Son basamak dışında her basamak geri alınabilir. Zaman kazanmak için basamakları atlamayın.

4. Katılık özelliktir ve iki yönlü keser. Bir saldırganı durduran aynı sert hata, bir sertifika bozulduğunda sizi de durdurur. Bu yüzden ön koşul “güvenlik istiyor musunuz?” değildir — herkes ister — “sertifika işlemleriniz asla başarısız olmayacak kadar sağlam mı?“dır.

5. Ön yükleme tek yönlü bir kapıdır. Önceden yüklenmemiş HSTS, bir istemci bir sonraki güvenli isteğini yaptığında ve max-age=0 aldığında gevşetilebilir — bundan daha hızlı değil ve yalnızca yeniden bağlanan istemciler için. Ön yükleme bunu bir adım öteye taşır: kaldırma, tarayıcı sürümü tarayıcı sürümü kullanıcılara aylar süren ayrı bir gönderimdir. Bunu “kolayca geri alamayacağımız kararlar” kovasına koyun ve ona göre davranın.

6. HSTS sıralamalarla dik ilişkilidir — ancak kötü bir kanonik sinyali de kurtaramaz. Bu bir sıralama sinyali değildir ve kanonikleştirmeyi veya dizine eklemeyi doğrudan kontrol etmez. Onu SEO getirisine göre değil, güvenlik ve güvene göre değerlendirin — hiç yok. Ama o bir güvenlik ağı da değildir: Google’ın HTTPS-kanonik tercihi, kötü bir sertifika, güvenli olmayan bağımlılıklar, bir HTTPS→HTTP yönlendirmesi veya bir HTTP kanonik etiketi karşısında geri çekilir ve HSTS’nin bunu geçersiz kılma gücü yoktur.

HSTS — hızlı başvuru

Başlık yönergeleri

Yaygın başlık değerleri (aşağıdaki hazırlık rakamları operasyonel önerilerdir, protokol gereksinimleri değildir — sert minimum ön yükleme satırıdır)

Yönlendirmeler: hangisi, kim görür

Fast facts

• Preload requires max-age ≥ 31536000 + includeSubDomains + preload — verified against hstspreload.org’s current published requirements.
• Preload removal is a separate submission that takes months to reach users, browser by browser — treat as permanent.
• On an HSTS host, a broken cert = hard-fail, no click-through.
• HSTS is not a ranking signal and does not replace your 301s.

HSTS başlığını ayarlayın

Başlığı yalnızca HTTPS sunucu bloğunuza ekleyin ve hiçbir şeyin bozulmadığını doğrulayana kadar kısa bir max-age ile başlayın. ; preload öğesini yalnızca hstspreload.org adresine göndermeyi düşünüyorsanız ekleyin — neredeyse geri alınamaz.

Apache (.htaccess)

<IfModule mod_headers.c>
  # Start short (300s) to prove it's safe; raise to 31536000 once confident.
  Header always set Strict-Transport-Security "max-age=300"
  # Full posture once every subdomain is verified HTTPS:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  # Only add ; preload when submitting to hstspreload.org:
  # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Nginx

# On the HTTPS (listen 443) server block:
add_header Strict-Transport-Security "max-age=300" always;
# Full posture once subdomains are verified:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Preload shape (near-irreversible):
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

HSTS’nin ayarlanıp ayarlanmadığını kontrol edin (ve geri okuyun)

macOS / Linux

# Print only the Strict-Transport-Security response header
curl -sI https://example.com/ | grep -i strict-transport-security
# → strict-transport-security: max-age=31536000; includeSubDomains

Windows (PowerShell)

# Same check in PowerShell
(Invoke-WebRequest -Uri "https://example.com/" -Method Head).Headers["Strict-Transport-Security"]

Chrome’da bir HSTS kaydını inceleyin ve temizleyin (DevTools / net-internals)

Test ediyorsanız ve bir tarayıcı temizlemeniz gereken bir HSTS politikası “öğrendiyse”:

1. Open a new tab and visit:  chrome://net-internals/#hsts
2. Under "Query HSTS/PKP domain", enter your host to see the stored policy.
3. Under "Delete domain security policies", enter the host and Delete.
   (This clears the *learned* policy — it does NOT remove a *preloaded* domain,
   which lives in the browser binary and can't be cleared this way.)

Bunu başlığınızın gerçekten saklandığını doğrulamak ve bir test ana bilgisayarını sıfırlamak için kullanın — üretim için bir düzeltme olarak değil, burada cevap HTTPS üzerinden aktif olarak max-age=0 sunmaktır (başlığı kaldırmak, bir istemcinin zaten öğrendiği bir politikayı temizlemez; yalnızca o istemci yeniden bağlanıp max-age=0 yanıtını aldığında etkili olur).

Sizi etkileyen HSTS hataları

1. Dropping your 301s because “HSTS handles it.” The classic. HSTS’s redirect is a browser-only internal upgrade crawlers never see. Remove your server-side 301s and search engines lose the signal that consolidates your move. Keep both, always.

2. Alt alan adlarını denetlemeden includeSubDomains öğesini etkinleştirmek. Bir alt alan adını çevrimdışına almanın en yaygın tek yoludur. Herhangi bir alt alan adı — eski bir uygulama, bir durum sayfası, bir satıcı ana bilgisayarı, www’nin kendisi — geçerli HTTPS üzerinde değilse, politika aşağı uzanır ve başlığı gören her tarayıcı için onu bozar.

3. İlk günden doğrudan bir yıllık max-age (veya ön yükleme) atlamak. Güvenlik ağı yok. Kısa başlayın (max-age=300), hiçbir şeyin bozulmadığını doğrulayın, sonra artırın. Yanlış yapılandırılmış bir sitede ayarlanan uzun bir max-age, tarayıcılarda bir yıl boyunca süren kendi kendine yapılan bir kesintidir.

4. HTTPS’ten önce preloading gerçekten kurşun geçirmezdir. Preload neredeyse geri alınamaz — kaldırma aylar sürer. Google’ın kendi sözü: sitenizin işleyişi yeterince sağlam olduğundan emin olana kadar HSTS’yi etkinleştirmeyin. Preload bu riski katlar.

5. Süresi dolmuş bir sertifikayı küçük bir sorun olarak ele almak. HSTS olmayan bir sitede süresi dolmuş bir sertifika atlanabilir bir uyarıdır. HSTS barındıran bir sunucuda ise bu, tıklamayla geçilemeyen sert bir kesintidir. HSTS’yi etkinleştirirseniz, sertifika yenileme otomasyonu ve son kullanma tarihi uyarıları lüks olmaktan çıkar.

6. Başlığı HTTP yanıtına eklemek. Tarayıcılar HTTP üzerinden gönderilen HSTS’yi yok sayar (tasarım gereği — bir saldırgan enjekte edebilir veya kaldırabilir). Sayılması için HTTPS yanıtında gönderilmesi gerekir.

7. Joker sertifika derinlik sınırını unutmak. *.example.com joker karakteri foo.bar.example.com’u kapsamaz. includeSubDomains’i açarsanız, bu sertifikaya güvenen daha derin herhangi bir alt alan adı kilitlenir.

Olay müdahale planı: bir HSTS sunucusu kilitlendi

1. Hatayı temiz bir ağdan ve birden fazla tarayıcıdan doğrulayın. Etkilenen ana bilgisayar adlarını ve tam sertifika hatasını kaydedin. Hatırlanan bir HSTS politikası, semptomun geri dönen ve ilk kez gelen ziyaretçiler arasında farklı olmasına neden olabilir.
2. Önce geçerli HTTPS’i geri yükleyin. Sertifika süresi dolmuşsa, uyumsuzsa veya bir ara sertifika eksikse, yenileyin veya değiştirin ve eksiksiz zinciri dağıtın. HSTS tarayıcısı güvenli bir HTTP atlama yolu sunmaz.
3. Politika kapsamını haritalayın. Canlı Strict-Transport-Security başlığını inceleyin ve includeSubDomains veya preload’ın kesintiyi gönderen ana bilgisayar adının ötesine taşıyıp taşımadığını belirleyin.
4. Etkilenen her alt alan adını envantere alın. Unutulmuş bir HTTP-only sunucu için, hizmeti korumaya, taşımaya veya yönlendirmeye karar vermeden önce önüne geçerli bir sertifika ve HTTPS uç noktası koyun.
5. Politikayı yalnızca erişim geri yüklendikten sonra düzeltin. Kapsam güvenli değilse, HTTPS yanıtlarındaki başlığı azaltın veya kaldırın. Bu, tarayıcıların zaten önbelleğe aldığı bir politikayı anında temizlemez ve preload kaldırma ayrı, yavaş bir süreçtir.
6. Kurtarmayı doğrulayın. Kök alan adını, www’yi ve etkilenen her alt alan adını geçerli bir zincir, doğru ana bilgisayar adı, tek atlamalı HTTP→HTTPS yönlendirmesi ve amaçlanan HSTS başlığı için test edin. Sertifika son kullanma tarihi izlemeyi aynı envanterde tutun.

HTTP yönlendirmesini kaldırmayın veya kullanıcılara uyarıyı atlamalarını söylemeyin. Kalıcı çözüm, aktif HSTS politikasının ulaştığı her yerde geçerli bir HTTPS uç noktasıdır.

Canlı bir HSTS politikasını denetleme

Act as a security-minded technical SEO. Review this Strict-Transport-Security
header, the HTTP redirect response, and the supplied subdomain inventory.

For the header, parse max-age, includeSubDomains, and preload. Explain the effective
scope, identify subdomains whose HTTPS or certificate coverage is unproven, and
separate browser-side HSTS behavior from the server-side 301 search engines need. Use
GET requests (HEAD can behave differently on some servers/clients), and record which
client or tool produced each observation and its version, since internal-redirect
representation is client/tool-specific rather than a fixed protocol value.

Recommend the next rollout stage: keep a short max-age canary, lengthen max-age,
add includeSubDomains, or consider preload. Do not recommend preload unless the
evidence shows a valid certificate, same-host HTTP→HTTPS redirects, HTTPS on every
subdomain, max-age of at least 31536000, includeSubDomains, and the preload token.

Return: observed configuration, risks, blocking evidence, next action, rollback
constraint, and exact validation checks.

HSTS kilidini triyajlama

Given the affected hostnames, browser error, certificate details, DNS/CDN layout,
and live response headers, identify whether this is an expired certificate, hostname
mismatch, incomplete chain, includeSubDomains spillover, or preload issue. Prioritize
restoring valid HTTPS. Explain why removing a header does not immediately erase a
cached browser policy, then provide recovery and verification steps.

HSTS inceleme araç seti

• HTTP Header Checker — canlı Strict-Transport-Security başlığını inceleyin ve HTTPS yanıtlarında göründüğünü doğrulayın.
• curl -I — bir tarayıcının hatırladığı HSTS durumuna güvenmeden HTTP yönlendirmesini HTTPS başlığıyla karşılaştırın.
• Tarayıcı DevTools’u — gerçek bir istemcinin gördüğü son yanıt başlıklarını ve sertifika hatasını doğrulayın.
• HSTS preload durumu — gönderim gereksinimlerini ve alan adının preload sürecinde zaten temsil edilip edilmediğini kontrol edin.

En az iki görünüm kullanın: komut satırı çıktısı sunucu yanıtını gösterirken, bir tarayıcı ayrıca istemci tarafı uygulamasını ve sertifika sert hatalarını ortaya çıkarır. Araçları karşılaştırırken HEAD yerine GET’i tercih edin — bazı sunucular ve istemciler ikisini farklı temsil eder — ve her okumanın arkasındaki tam istemciyi/aracı/sürümü not edin.

Aşamalı HSTS dağıtım testleri

Test 0: durum matrisi (değişiklikleri aşamalandırmadan önce bunu çalıştırın)

HSTS durumu tek bir gerçek değildir — birbiriyle çelişebilen birkaç bağımsız durumdur. Bunları ana bilgisayar adı başına ayrı ayrı takip edin:

Her gözlem için istemciyi, aracı ve sürümü kaydedin — iç yönlendirme temsili ve HSTS uygulama ayrıntıları tarayıcılara, tarayıcılara ve komut satırı araçlarına göre değişir ve bir istemciden gelen bayat bir okuma, gerçek olmayan bir çelişki gibi görünebilir.

Test 1: kısa max-age deneme amaçlı yayını

• Amaç: Başlığın yalnızca sağlıklı HTTPS yanıtlarından gönderildiğini kanıtlamak, istemcileri uzun bir politikaya bağlamadan önce.
• Yöntem: HTTP Header Checker ve curl -I ile temsili şablonları ve ana bilgisayarları inceleyin; dağıtılan değeri onaylanmış deneme amaçlı yayın yapılandırmasıyla karşılaştırın.
• Beklenen sonuç: HTTPS yanıtları amaçlanan kısa max-age değerini taşır; HTTP yine de HTTPS’ye sunucu tarafı kalıcı bir yönlendirme döndürür.
• Hata tetikleyicisi: Eksik veya yinelenen başlıklar, beklenmeyen uzun bir süre, sertifika hataları veya herhangi bir yönlendirme döngüsü.
• Sonraki adım: Başlığı veya HTTPS uç noktasını düzeltin ve dağıtımı deneme amaçlı yayın aşamasında tutun.

Test 2: includeSubDomains hazırlığı

• Amaç: Bir üst politikanın unutulmuş bir ana bilgisayar adını kilitlemesini önlemek.
• Yöntem: Bakımı yapılan alt alan adı envanterindeki her DNS ana bilgisayar adını geçerli bir HTTPS yanıtı, doğru sertifika adı ve eksiksiz zincir için test edin.
• Beklenen sonuç: Kapsamdaki her alt alan adı HTTPS üzerinden çalışır; eski, satıcı, geliştirme ve daha derin düzeydeki ana bilgisayarlar dahil.
• Hata tetikleyicisi: Yalnızca HTTP hizmeti, süresi dolmuş veya uyumsuz sertifika veya envanterde eksik ana bilgisayar adı.
• Sonraki adım: includeSubDomains eklemeden önce ana bilgisayarı düzeltin veya taşıyın.

Test 3: ön yükleme hazırlığı

• Amaç: Neredeyse kalıcı politikanın belgelenmiş gönderim gereksinimlerini karşıladığını doğrulamak.
• Yöntem: Geçerli bir sertifika, aynı ana bilgisayarda HTTP→HTTPS yönlendirmeleri, tüm alt alan adlarında HTTPS ve en az max-age 31536000 değerine sahip bir apex başlığı, includeSubDomains ve preload olduğunu doğrulayın.
• Beklenen sonuç: Her gereksinim karşılanır ve kuruluş yavaş kaldırma yolunu kabul eder.
• Hata tetikleyicisi: Başarısız herhangi bir teknik gereksinim veya yalnızca HTTP alt alan adı için çözülmemiş bir ihtiyaç.
• Sonraki adım: Göndermeyin; geri döndürülebilir aşamalı politikada kalın.

Zaman ayırmaya değer kaynaklar

Konuşmam

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — TLS, yaygın HTTPS uygulama hataları ve HSTS’nin hem kapattığı hem de büyütebileceği geçiş tuzakları hakkındaki derinlemesine incelemem. (Geçerli feragatname geçerlidir: bu sistemlere ilişkin anlayışımdır ve içindeki benimseme istatistikleri 2016 yılına aittir.)

İlgili yazılarım

• Teknik SEO Başlangıç Rehberi — HTTPS ve HSTS’nin büyük resimde nereye oturduğu.

Sektörden

• Sunucularınızda HTTPS’yi etkinleştirin (web.dev) — Google’ın kendi HSTS rehberi: başlık, SSL soyma ve sert hata uyarısı.
• MDN — Strict-Transport-Security — yetkili başlık referansı: sözdizimi, yönergeler ve şema yükseltme davranışı.
• HSTS Preload Listesi gönderimi (hstspreload.org) — Chromium projesinin ön yükleme gereksinimleri ve neredeyse geri döndürülemezlik uyarıları.
• RFC 6797 — HTTP Strict Transport Security — bir yönergenin tam ifadesine ihtiyaç duyduğunuzda orijinal spesifikasyon.
• HSTS — Nedir ve Nasıl Kullanılır (Kinsta) — tarayıcı düzeyinde dahili yönlendirmeyi, ön yükleme listesini ve kilitlenme risklerini kapsayan pratik bir uygulama rehberi.
• SSL Labs Sunucu Testi (Qualys) — TLS yapılandırmanızı derecelendirin ve HSTS’nin doğru şekilde sunulduğunu doğrulayın.

Alıntı yapmaya değer istatistikler ve gerçekler

• Ön yükleme, max-age ≥ 31536000 (1 yıl), includeSubDomains ve preload gerektirir. Tarayıcıya gömülü liste için kesin ve pazarlık edilemez gönderim çıtası. Kaynak
• Ön yükleme kaldırmanın kullanıcılara ulaşması aylar alır. Gönderim hizmetinden: “inclusion in the preload list cannot easily be undone… it takes months for a change to reach users with a Chrome update.” (çeviri) «ön yükleme listesine dahil edilme kolayca geri alınamaz… bir değişikliğin Chrome güncellemesiyle kullanıcılara ulaşması aylar alır.» Bu, ön yüklemeyi tek yönlü bir kapı yapan sayıdır. Kaynak
• HSTS ana bilgisayarları herhangi bir TLS hatasında sert hata verir. web.dev: sitenizi bir HSTS ana bilgisayarı olarak bilen istemciler “are likely to hard-fail if your site ever has an error in its TLS configuration.” (çeviri) «sitenizin TLS yapılandırmasında bir hata olursa sert hata verme olasılıkları yüksektir.» Tıklayarak geçme yok — süresi dolmuş bir sertifika kesintiye dönüşür. Kaynak
• HTTPS’nin kendisi “a very lightweight signal—affecting fewer than 1% of global queries.” Google’ın kendi çerçevesi — ve HSTS, HTTPS’nin üzerinde bir katmandır, ayrı bir sıralama girdisi değildir, bu nedenle SEO ağırlığı fiilen sıfırdır. Beklentileri buna göre doğru boyutlandırın. Kaynak

Kendini test et: HSTS

HSTS hakkında beş hızlı soru. Her biri için bir cevap seçin, ardından kontrol edin.

Değişiklik günlüğü