SSL/TLS Sertifikaları

TL;DR — SSL/TLS sertifikası, sunucunuzda bulunan ve asma kilit ile https:// bağlantısını mümkün kılan dosyadır. Ucuz ve pahalı seçenekler vardır, ancak SEO açısından hepsi aynıdır — Google yalnızca URL’nizin https:// ile başlayıp başlamadığını kontrol eder; hangi sertifikayı satın aldığınıza bakmaz. Let’s Encrypt’in ücretsiz sertifikası da pahalı bir sertifika kadar iyi sıralanır. Size gerçekten zarar veren şey bozuk sertifikadır: süresi dolarsa veya yanlış yapılandırılırsa tarayıcılar korkutucu bir uyarı gösterir ve ziyaretçiler ayrılır.

SSL sertifikası aslında nedir

Modern HTTPS uses TLS certificates to authenticate a domain and establish encrypted connections. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 Google recommends HTTPS and uses it as one canonicalization signal, but certificate price or validation tier is not a documented ranking boost. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Genişletmek için dokunun

The chart groups observed certificate issuance by duration, from three days or less through more than 200 days. The 47-to-100-day bucket dominates this captured period.

Güvenli bir siteyi yüklediğinizde tarayıcınız ve sunucu şifrelemeyi kurmak için kısa bir el sıkışması gerçekleştirir. Sertifika, bu el sıkışması sırasında sunucunun gönderdiği şeydir. İki iş yapar: sitenin kime ait olduğunu (bir ölçüde — aşağıda daha fazlası var) doğrular ve bağlantıyı karıştıran anahtarı taşır.

İnsanlar “SSL sertifikası” der, ancak modern protokol aslında TLS’dir. “SSL” adı kaldı. (HTTPS merkezi, bu adlandırma ayrıntısını ve “HTTPS sıralamalara yardımcı olur mu?” sorusunun tamamını ele alır — bu sayfa HTTPS’nin en fazla küçük bir eşitlik bozucu olduğunu zaten bildiğinizi varsayar ve sertifikanın kendisine odaklanır.)

Daha pahalı bir sertifika SEO’ya yardımcı olur mu?

Hayır. Bu, en yaygın efsanedir. Google, HTTPS geçerli ve çalışır durumda olduğu sürece sertifika türleri, sertifika otoriteleri veya fiyatları arasında herhangi bir sıralama farkı belgelemiyor — 300 dolarlık yıllık bir sertifika ile ücretsiz bir sertifika arasındaki farkı anlayamaz. Google’dan John Mueller, biri SSL’nin SEO’yu artırdığını iddia ettiğinde bunu açıkça şöyle ifade etti: “this does not ‘Boost your website’s SEO’, sorry.”

Dolayısıyla Let’s Encrypt’in ücretsiz sertifikası, bir sertifika satıcısının sattığı en pahalı seçenekle aynı şekilde sıralanır. Ekstra para, sıralama avantajı değil, insanların güvendiğine dair sinyaller satın alır (doğrulama seviyeleri hakkında Gelişmiş sekmesinde daha fazla bilgi var).

Sertifikaların seçenekleri

İki şey değişir ve bunları birbirinden ayrı tutmak faydalıdır:

• Ne kadar doğrulama yaptıkları. Temel bir sertifika yalnızca alan adını kontrol ettiğinizi kanıtlar. Daha pahalı olanlar şirketinizin yasal kimliğini doğrular. Google açısından bunun farkı yoktur.
• Neyi kapsadıkları. Tek bir sertifika bir ana bilgisayar adını, bir dizi alt alan adını (“wildcard”) veya belirli bir ad listesini (“SAN” sertifikası) kapsayabilir.

SEO için gerçekten önemli olan kısım

Çalışan bir sertifika görünmezdir. Bozuk olan ise sorundur:

• Süresi dolmuş sertifikalar tam ekran tarayıcı uyarısı gösterir. Ziyaretçiler sayfanızı hiç görmeden çıkar; bu bir sıralama çöküşü gibi görünebilir, ancak aslında insanlar kapıdan geri dönmektedir.
• Ciddi biçimde bozuk bir sertifika, Google’ın sayfanın HTTPS sürümünü değil HTTP sürümünü tercih etmesine de yol açabilir — Google normalde HTTPS’yi tercih eder, ancak kendi kılavuzu kötü bir sertifikanın bunu geçersiz kıldığını söyler (HSTS bile bunu durduramaz).
• Yeterince sorun varsa, Google HTTPS sayfalarınızı tamamen taramayı bile durdurabilir; bu da zamanla sayfaların aramadan çıkmasına yol açar.

Bu yüzden sertifika için pratik kural basit: ucuz (veya ücretsiz) olanı satın alın ve süresinin dolmasına asla izin vermeyin. Otomatik yenilemeyi kurun ve unutun.

Gerçek ayrıntıları — DV ile OV ve EV arasındaki farkı, wildcard ile SAN’ı, sertifika zincirlerini, kısalan geçerlilik süresini ve bir sertifika bozulduğunda tarayıcılara tam olarak ne olduğunu — istiyor musunuz? Gelişmiş sekmesine geçin.

TL;DR — Google, DV/OV/EV doğrulama derinliği veya ücretsiz ve ücretli düzenleme arasında bir sıralama farkı belgelemiyor — daha pahalı bir sertifika sıralama değil, insan ve kuruluş güveni satın alır. Doğrulama derinliği (DV/OV/IV/EV) ile kapsama alanı (tek alan adı/wildcard/SAN) iki bağımsız karardır; hiçbiri belgelenmiş bir sıralama faktörü değildir. Let’s Encrypt ve ücretsiz otomatik (ACME) düzenleme bir taviz değildir — aynı şifreleme, aynı muamele. Sertifikaların SEO’yu etkilediği yer arızadır: süresi dolmuş, kendinden imzalı, ana bilgisayar adı uyuşmayan veya zinciri kırılmış bir sertifika kullanıcılar için sayfayı bozar, Google’ın normal HTTPS-HTTP kanonik tercihini HTTP sürümüne geri çevirebilir (HSTS bunu geçersiz kılamaz) ve — Google’ın kendi belgelerine göre — yeterli HTTPS sorunu “Google’ın HTTPS sayfalarınızı taramayı durdurmasına yol açabilir”. CA/Browser Forum’un 2029’a kadar azami geçerliliği 47 güne indirmesiyle otomatik yenileme artık zorunludur. HTTPS merkezi, ücretsiz bir DV sertifikasının OV/EV ile aynı sinyali aldığını tanıtır; burada bunun tüm ayrıntılarını ele alıyoruz.

HTTPS merkezi, HTTPS’nin en fazla bir eşitlik bozucu sinyal olduğunu, Google’ın sertifikaya değil şemaya baktığını ve ücretsiz bir DV sertifikasının pahalı bir OV/EV ile aynı sinyali aldığını açıklar. Bu makale tam olarak orada bırakılan noktadan devam eder ve sertifikanın kendisine bir katman daha derin iner. HTTPS’nin sıralamalara yardımcı olup olmadığını yeniden tartışmayacağım; merkezi okuduğunuzu varsayın. Burada merkezin yalnızca değindiği soruları yanıtlamak istiyorum: DV/OV/EV gerçekte ne demektir, kapsama alanı nasıl çalışır, ücretsiz otomatik sertifikalar neden yeterlidir, sertifika zincirleri kendi testlerinizden gizlenecek şekilde nasıl bozulur ve bir sertifika kötüleştiğinde yalnızca kullanıcıların değil, taramanın da başına gerçekten ne gelir.

”SSL sertifikası” aslında TLS sertifikasıdır

SSL, modern TLS kurulumları için artık kullanılmayan bir terimdir. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 Arama kılavuzu, ticari sertifika seviyesinden çok geçerli ve erişilebilir HTTPS’ye odaklanır. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Önce kısa bir adlandırma notu, sonra devam edeceğim: SSL (Secure Sockets Layer) artık kullanımdan kaldırılmış protokoldür; bugün düzenlenen her şey TLS (Transport Layer Security) üzerinde çalışır. “SSL sertifikası” günlük kullanımda kalan addır — Google’ın kendi Search Console dizeleri hâlâ “SSL certificate problems” der. Bu yazının geri kalanında “sertifika” diyeceğim.

Doğrulama derinliği: DV, OV, IV ve EV

Sertifikalar, sertifika otoritesinin (CA) sizin adınıza kefil olmadan önce ne kadar kontrol yaptığını açıklayan farklı doğrulama seviyelerinde düzenlenir. SSL.com’un açıklamasına göre:

• DV (Domain Validation) “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” Bu, hızlı, ucuz veya ücretsizdir ve genellikle otomatiktir (alan adını bir DNS kaydıyla veya CA’nın alabileceği bir dosyayla kontrol ettiğinizi kanıtlarsınız).
• OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.”
• IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.”
• EV (Extended Validation), “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.”

SEO açısından önemli nokta şudur: Google doğrulama seviyeleri arasında bir sıralama farkı belgelemiyor. Merkez, temel sinyalin URL şemasını okuduğunu ortaya koyuyor — Illyes bunu URL’nin önündeki ilk beş karaktere bakmak olarak açıkladı. HTTPS geçerli ve çalışır durumdaysa DV, OV ve EV sertifikalarının tümü aynı muameleyi görür. Aralarındaki fiyat farkı CA’nın inceleme çabasını ve sorumluluğunu yansıtır, Google’ın tercihini değil — web.dev bunu açıkça şöyle söyler: “different CAs charge different amounts of money for the service of vouching for your public key.” Ekstra para yalnızca insanlara ve kuruluşlara yönelik güven satın alır.

EV için geriye kalan tek insana yönelik sav da büyük ölçüde ortadan kalktı: EV’nin tarayıcı adres çubuğundaki özel gösterimi fiilen yok oldu. Chrome, Chrome 77’den (2019) itibaren yeşil şirket adı arayüzünü kaldırdı ve Firefox 70 aynı yıl bunu izledi. Bu nedenle eskiden EV fiyatını haklı çıkarmak için kullanılan “müşteriler çubukta şirket adımızı görür” iddiası, başlıca tarayıcılarda artık geçerli değil — satın alma kararı veriyorsanız güncel tarayıcı davranışını doğrulayın, ancak şu an bu görsel sinyal mevcut değil.

Kapsama alanı: tek alan adı, wildcard ve SAN

Doğrulama derinliği bir eksendir. Kapsama alanı — bir sertifikanın gerçekte hangi ana bilgisayar adlarını güvenceye aldığı — tamamen ayrı bir eksendir. Her kapsam genellikle DV veya OV olarak düzenlenebilir (CA/B politikası uyarınca wildcard’lar genellikle EV olarak sunulmaz):

• Tek alan adı — örneğin www.example.com olmak üzere tam olarak bir ana bilgisayar adını kapsar.
• Wildcard — bir DNS etiketi derinliğinde tek bir ana bilgisayar adı desenini kapsar. web.dev sınırı kesin olarak şöyle açıklar: “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” Son cümle tuzaktır — wildcard, ikinci düzey alt alan adlarını kapsamaz.
• SAN / çok alan adlı (UCC) — sertifikanın Subject Alternative Names alanında bulunan belirli ana bilgisayar adlarının açık bir listesidir. web.dev, anahtarınızı birden fazla DNS adına eşlemek için “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” bulunduğunu belirtir. SAN sertifikası tamamen farklı alan adlarını bile kapsayabilir; bu da birkaç ilişkili mülkünüz olduğunda wildcard kapsamını gereğinden fazla büyütmek istemiyorsanız işe yarar.

Pratik SEO arızası wildcard’ın tek etiketlik sınırında gizlenir. *.example.com kullandığınızı ve birinin staging.blog.example.com oluşturduğunu düşünün — bu iki etiket derinliğindedir, wildcard’ın dışındadır ve bir sertifika hatasıyla veya eşleşmeyen bir sertifikayla hizmet verir. Google veya bir kullanıcı buraya ulaşırsa, kapsandığını düşündüğünüz sayfada bozuk sertifika deneyimiyle karşılaşır.

Bir başka kapsama tuzağı: apex ana bilgisayar adınızda geçen bir test, her yerde kapsam olduğunu kanıtlamaz. Bir istemci bağlandığı tam ana bilgisayar adını istemeli ve SNI aracılığıyla o adı gerçekten içeren bir sertifika almalıdır — CDN’lerde, yük dengeleyicilerde ve SNI tabanlı paylaşımlı barındırmada aynı alan adının arkasındaki farklı edge’ler, bölgeler veya origin’ler meşru olarak farklı sertifikalar sunabilir. Herkese açık her ana bilgisayar adını bağımsız olarak test edin; example.com üzerinde alınan tek bir temiz SSL Labs sonucunun www., bölgesel bir edge veya farklı bir origin arkasındaki alt alan adı hakkında konuştuğunu varsaymayın.

Let’s Encrypt ve ücretsiz otomatik düzenleme

Let’s Encrypt ve diğer ücretsiz CA’ler ACME protokolü üzerinden DV sertifikaları düzenler — Certbot gibi istemcilerin sizin için yürüttüğü otomatik bir istek/doğrulama/düzenleme döngüsü. İnsanların burada yanlış anladığı iki şey var:

1. Ücretsiz daha zayıf demek değildir. Let’s Encrypt sertifikası ücretli olanla aynı TLS şifreleme gücünü sağlar ve Google’ın sinyali şema tabanlı olduğu için sıralama açısından da tamamen aynı muameleyi görür. Gerçek ödünler bunun yalnızca DV olması (OV/EV kimlik incelemesi yoktur) ve kısa ömürlü olmasıdır.
2. Kısa geçerlilik süresi otomatikleştirildiğinde bir özelliktir. Kısa ömürlü sertifikalar, bir anahtar ele geçirilirse maruz kalma penceresini küçültür ve — kritik olarak — hiçbir insanın yenilemeyi hatırlamasını gerektirmez. Otomasyon, en kısa geçerlilik süresini en güvenli süreye dönüştürür.

Bu ikinci nokta yalnızca Let’s Encrypt kullanıcıları için değil, herkes için yakında önemli olacak.

Sertifika geçerlilik süresindeki değişim (2026–2029) — şimdi otomatikleştirin

Sektör, sertifika geçerlilik sürelerini sabit bir takvimle kısaltıyor. CA/Browser Forum, Ballot SC-081v3’ü (oylama 11 Nisan 2025’te kapandı) kabul ederek maksimum TLS sertifikası geçerliliğini aşamalı biçimde düşürüyor:

• 398 gün bugün
• 15 Mart 2026 tarihinden itibaren 200 gün
• 15 Mart 2027 tarihinden itibaren 100 gün
• 15 Mart 2029 tarihinden itibaren 47 gün

Let’s Encrypt de kendi yolunda daha hızlı ilerliyor: Şubat 2026 güncellemesine göre, varsayılan sertifika geçerliliğini sonraki iki yıl içinde iki adımda — “from 90 days to 64 days, and then 45 days” — azaltıyor; yenileme zamanı bugün 90 günlük sertifikada yaklaşık 60. günden, sertifikalar 45 güne indiğinde yaklaşık 30. güne kayacak. Bu güncelleme daha önceki, daha kesin takvimin yerini aldı; her adımın kesin yayın tarihlerini henüz kesinleşmemiş kabul edin ve belirli bir tarihe güvenmeden önce Let’s Encrypt’in kendi değişiklik günlüğünü kontrol edin.

Operasyonel çıkarım açık: yenilemeniz henüz otomatik değilse bunu 2027’den önce düzeltin. 398 günde idare edilebilen manuel yenileme düzeni, 47–100 günde neredeyse kesin bir kesinti reçetesine dönüşür. DigiCert’in oylamaya ilişkin kapsamı bunu iyi ifade eder — manuel yeniden doğrulama teknik olarak mümkün kalır, ancak “doing so would be a recipe for failure and outages.” Otomasyon, güzel olsa iyi olur kategorisinden çıkıp tek makul seçeneğe dönüşür.

Sertifika zinciri / ara sertifika arızaları

Bu, yeterince açıklanmayan kısımdır ve Google’ın belgeleri mekanizmayı anlatmaz; bu yüzden gerçekte nasıl çalıştığını açıklayayım.

Tarayıcı yalnızca güven deposuna gömülü küçük bir dizi kök sertifikaya güvenir. Sunucunuzun sertifikası — yaprak veya son varlık sertifikası — neredeyse hiçbir zaman doğrudan bir kök tarafından imzalanmaz. Bunun yerine zincir şöyledir: yaprak → bir veya daha fazla ara sertifika → güvenilir kök. Bir istemcinin yaprağınıza güvenmesi için sunucunuz, istemcinin zaten güvendiği bir köke kadar yolu kurabilmesi amacıyla yaprağı ve ara sertifikaları göndermelidir.

Klasik yanlış yapılandırma, yalnızca yaprağı gönderen ve ara sertifikayı atlayan sunucudur. Bunun sinsi olmasının nedeni şudur: masaüstü Chrome çoğu zaman yine çalışır, çünkü başka sitelerde karşılaştığı ara sertifikaları önbelleğe alır ve eksik kısmı tamamlayabilir. Bu yüzden dizüstü bilgisayarında test yapan kişi yeşil asma kilit görür ve her şeyin yolunda olduğunu varsayar. Bu sırada mobil tarayıcılar, birçok API/HTTP istemcisi ve önbelleğe alınmış ara sertifikaya sahip olmayan diğer araçlar el sıkışmasını doğrudan başarısız kılar. Bu, TLS katmanındaki “benim makinemde çalışıyor” hatasıdır.

Bunu yakalamak için masaüstü Chrome’da yapılan nokta kontrolüne güvenmeyin. Zinciri sıfırdan kuran bir araç kullanın:

• SSL Labs Server Test, “extra download” / eksik zincir sorunlarını açıkça işaretler.
• Komut satırındaki openssl s_client -connect example.com:443 -showcerts, sunucunun gerçekte gönderdiği her sertifikayı gösterir; böylece ara sertifikanın orada olduğunu doğrulayabilirsiniz.

Bir sertifika geçersiz, süresi dolmuş veya kendinden imzalı olduğunda ne olur

En önemli bölüm budur ve temiz biçimde ikiye ayrılır — çünkü kullanıcılar ile tarayıcılar bozuk bir sertifikayı tarayıcılardan farklı deneyimler.

Kullanıcılar ve tarayıcılar ne yapar. Sertifikanın kesin olarak başarısız olması — süresinin dolması, kendinden imzalı olması, ana bilgisayar adının eşleşmemesi veya CA’nın güvenilmemesi — HTTP’nin aldığı sakin “Not Secure” etiketini değil, tam ekran bir geçiş uyarısını tetikler. Kullanıcılar geri döner. En iyi belgelenmiş örnek Glenn Gabe’in “A Wolf in Panda’s Clothing” çalışmasıdır — bir e-ticaret sitesinin trafiği bir Google Panda güncellemesine denk gelen tarihte çöktü ve sahibi bir ceza olduğunu düşündü. Gerçek neden, ziyaretçilerin siteye ulaşmadan ayrılmasına yol açan süresi dolmuş sertifikanın tarayıcı uyarılarıydı. Gabe’in ifadesiyle: “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” Sertifikayı yenileyin; trafik yaklaşık sekiz gün içinde geri geldi. Kendinden imzalı sertifikalar da gerçek dünyada aynı şekilde davranır — kesin bir geçiş uyarısı gösterir; bu yüzden dahili/geliştirme/test ortamları için uygundur, herkese açık üretim sitesinde ise asla kullanılmamalıdır.

Google ne yapar. Bu, neredeyse her rakip sayfanın atladığı ve “sinyal şema tabanlıdır” çerçevesinden daha önemli bir ayrıntıdır. Google’ın kendi kanonikleştirme kılavuzu, bozuk sertifikanın Arama’da görünmez olmadığını açıkça söyler: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” ve kötü sertifikaları bu sorunlardan biri olarak doğrudan adlandırır — “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” Başka bir deyişle, gerçekten bozuk bir sertifika Google’ın sayfanın hangi sürümünü kanonik kabul ettiğini HTTP’ye geri çevirebilir — bunun aramada neyin göründüğü üzerinde gerçek bir etkisi vardır; yalnızca tarama bütçesiyle ilgili bir dipnot değildir.

Ayrı olarak Google’ın Search Console belgeleri, sertifika arızalarının tarama sonucu da olduğunu söyler: geçersiz bir sertifika “typically affects an entire site,” ve “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” Bu olduğunda kalan URL’ler “HTTPS not evaluated.” olarak etiketlenir. Burada iki ayrı mekanizma vardır — HTTP’ye geri dönen kanonik tercih ve ayrı bir tarama erişimi kısıtlaması — ve her ikisi de temel https:// sıralama sinyaline dokunmadan aynı görünür belirtiyi (sayfaların dizinden çıkmasını) üretebilir. Sertifikayı düzeltin; burada peşinden gidilecek bir sıralama faktörü yoktur, ancak “şema değişmedi, dolayısıyla zararsız” diye bir mazeret de yoktur.

Google’ın bu hataları tetikleyen kendi listesi, arıza sınıflandırmasıyla örtüşür: ana bilgisayar adının sertifikanın adlarıyla eşleşmemesi — “The host name of your site does not match any of the Subject Names in your SSL certificate” — ve “not recognized by major web browsers” olan sertifikalar (kendinden imzalı, güvenilmeyen CA’ye ait, bozuk veya güncel olmayan/henüz geçerli olmayan).

Süre sonu izleme ve otomatik yenileme

Sürenin dolması en yaygın ve önlenebilir sertifika arızasıdır; etki alanı da asimetriktir — genellikle tek tek bir sayfayı değil, tüm siteyi aynı anda bozar (Google: “Typically this affects an entire site”). Çözüm hiçbir zaman takvim hatırlatıcısı değildir. Gerçek otomasyonu kurun:

• Kendi sunucunuzda ACME / Certbot veya platformunuzun sunduğu eşdeğer.
• Sizin için otomatik olarak düzenleyen ve yenileyen ana bilgisayar veya CDN tarafından yönetilen sertifikalar (Cloudflare, çoğu yönetilen host ve birçok PaaS platformu).
• Yenileme otomatik olsa bile yaklaşan süre sonu ve el sıkışması arızaları için arka plan önlemi olarak uyarı veren üçüncü taraf sertifika/çalışırlık izleyicisi.

Geçerlilik süreleri 47 güne yaklaşırken manuel hatırlatıcılar matematiksel olarak sürdürülemez hale gelir — ölçeklenebilen tek yaklaşım otomasyondur.

Alt alan adları arasında karma sertifika kurulumları

Bu, karma içerikten farklıdır (HTTPS sayfasının HTTP alt kaynakları yüklemesi — merkezde ele alınır). Karma sertifika, sitenin farklı bölümlerinin farklı platformlarda veya farklı takvimlerde farklı sertifikalarla güvenceye alınmasıdır. Yaygın örnek şudur: ana alan adınızın sağlam bir sertifikası vardır, ancak blog.example.com kendi sertifikasıyla farklı bir platformda çalışır ve sertifikası kendi zamanında sona erer; ya da ayrı bir CDN’deki pazarlama alt alan adı wildcard’ın tek etiketlik sınırı nedeniyle hiç kapsanmamıştır; ya da SNI tabanlı çok kiracılı barındırma, ana alan adı nokta kontrolünde kusursuz görünürken bir alt alan adının yenilemesini sessizce bozar.

Ders şudur: ana sayfanızdaki geçerli asma kilit size başka yerlerdeki kapsam hakkında hiçbir şey söylemez. Alt alan adlarının envanterini çıkarın, her ana bilgisayarın geçerli ve izlenen sertifika kapsamına sahip olduğunu doğrulayın (kendi sertifikası, ona ulaşan bir wildcard veya onu listeleyen bir SAN ile) ve tüm mülkü tek bir ana bilgisayar adına yapılan SSL Labs kontrolüyle onaylamaya çalışmayın.

Yaygın efsaneler

• “Ücretli veya EV sertifikası ücretsiz DV sertifikasından daha iyi sıralanır.” Hayır — sinyal şema tabanlıdır; doğrulama derinliği Google tarafından görünmez.
• “Wildcard sertifikaları alt-alt alan adları dahil tüm alt alan adlarını kapsar.” Hayır — yalnızca bir DNS etiketi; *.example.com, foo.bar.example.com adresini kapsamaz.
• “Süresi dolmuş sertifika doğrudan sıralamamı düşürür.” Temel sıralama sinyali üzerinden değil — ancak Google’ın normal HTTPS-HTTP kanonik tercihini HTTP’ye geri çevirebilir (HSTS bunu geçersiz kılamaz) ve ayrıca yeterli HTTPS sorunu Google’ın HTTPS sayfalarınızı tamamen taramayı durdurmasına yol açabilir. Her ikisi de gerçektir; hiçbiri sıralama sinyalinin içinden geçmez.
• “Let’s Encrypt sertifikaları ücretli olanlardan daha düşük kalitededir.” Hayır — aynı şifreleme, aynı sıralama muamelesi; fark yalnızca DV doğrulaması ve kısa (yakında sektör standardı olacak) geçerlilik süreleridir.
• “Ana sayfam geçerli bir asma kilit gösteriyorsa tüm sitemin sertifikaları iyidir.” Hayır — alt alan adları ayrı ve farklı takvimlerde sertifika taşır.
• “Zincir hataları nadirdir veya eski bir sorundur.” Hayır — yalnızca yaprağı sunan her yığında yaygındır ve masaüstü Chrome’un önbelleklemesi bunu test yapan kişiden gizler.

Bu, HTTPS merkezi altındaki sertifika düzeyinde derinlemesine incelemedir; taşıma kılavuzu, karma içerik ve HSTS için oradan başlayın.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış özeti:

• Google sertifika seviyeleri arasında bir sıralama farkı belgelemiyor. HTTPS geçerli olduğu sürece DV, OV, IV ve EV aynı muameleyi görür ve ücretsiz Let’s Encrypt sertifikası ücretli olanla eşittir. Daha pahalı sertifika insan/kuruluş güveni satın alır, SEO değil. John Mueller: “this does not ‘Boost your website’s SEO’, sorry.”
• İki bağımsız eksen: doğrulama derinliği (DV = alan adı kontrolü → OV/IV = kimlik → EV = sıkı kuruluş incelemesi) ve kapsama alanı (tek alan adı / wildcard / SAN). Google bunların hiçbirini görmez.
• Wildcard’lar yalnızca bir DNS etiketini kapsar. *.example.com, foo.example.com adresini kapsar ancak foo.bar.example.com adresini kapsamaz. SAN sertifikaları açık ana bilgisayar adlarını listeler ve alan adlarını aşabilir.
• EV’nin tarayıcı arayüzü yok oldu (Chrome 77 / Firefox 70, 2019); böylece insanlara yönelik son avantajı da ortadan kalktı.
• Ücretsiz otomatik düzenleme (ACME/Certbot) bir taviz değildir — aynı şifreleme, aynı sıralama. Kısa geçerlilik süreleri otomatikleştirildiğinde özelliktir.
• Geçerlilik süresi değişimi: CA/B Forum Ballot SC-081v3 maksimumu 398 → 200 (Mart 2026) → 100 (Mart 2027) → 47 gün (Mart 2029) olarak indiriyor; Let’s Encrypt de kendi varsayılanını önümüzdeki iki yıl içinde 90 → 64 → 45 güne çekiyor (Şubat 2026 güncellemesine göre; kesin adım tarihleri henüz belirlenmedi). Yenilemeyi şimdi otomatikleştirin.
• Zincir arızaları sizden gizlenebilir: sunucu yalnızca yaprağı gönderir ve ara sertifikayı atlar; masaüstü Chrome bunu önbellekten bulup çalışır, mobil/API istemcileri başarısız olur. SSL Labs veya openssl s_client -showcerts ile teşhis edin.
• Sertifika bozulduğunda kullanıcılar ve Google: kullanıcılar tam ekran uyarı görür ve geri döner (Gabe’in Panda sanılan süresi dolmuş sertifika vakası); temel sıralama sinyali değişmez, ancak bozuk sertifika Google’ın normal HTTPS-HTTP kanonik tercihini HTTP’ye çevirebilir (HSTS bunu geçersiz kılamaz) ve ayrı olarak Google “stop crawling your HTTPS pages” yapabilir — iki farklı mekanizma, aynı görünür belirti.
• Sürenin dolması tüm siteyi aynı anda bozar; yenilemeyi otomatikleştirin ve izleyin. Alt alan adları arasındaki karma sertifika (karma içerikten farklıdır), ana sayfadaki asma kilidinin alt alan adı kapsamı hakkında hiçbir şey söylememesi demektir.

Resmî belgeler

Arama motorlarından ve standart kuruluşlarından sertifikalar hakkında birincil kaynak belgeleri.

Google

• HTTPS report (Search Console Help) — “invalid certificate”, “affects an entire site” ve “stop crawling your HTTPS pages” ifadeleri.
• SSL certificate problems (Search Console Help) — ana bilgisayar adı uyuşmazlığı ve güvenilmeyen/kendinden imzalı sertifika hataları.
• Enable HTTPS on your servers (web.dev) — CA’ler, CSR’ler, wildcard kapsamı ve çok adla eşleme.
• Consolidating duplicate URLs (Google Search Central) — kanonik tercih dili: Google HTTPS’yi “except when there are issues or conflicting signals” tercih eder ve kötü sertifikaları bu sorunlardan biri olarak adlandırır; HSTS’nin bu tercihi geçersiz kılamayacağını belirtir.

Sertifika otoriteleri ve standartlar

• DV, OV, IV, and EV Certificates (SSL.com) — doğrulama seviyelerinin tanımları.
• Let’s Encrypt — ücretsiz, otomatik DV sertifika otoritesi.
• ACME protocol / Certbot — kendi barındırdığı kurulumların çoğunun kullandığı otomasyon istemcisi.
• Shorter Certificate Lifetimes and Rate Limits (Let’s Encrypt) — Let’s Encrypt’in geçerlilik süresini kısaltma planı.
• CA/Browser Forum — sertifika azami geçerlilik sürelerini belirleyen kuruluş (Ballot SC-081v3).

Kaynaktan alıntılar

Kayıtlara geçmiş ifadeler. Her bağlantı, alıntılanan bölüme giden derin bir bağlantıdır.

Google — Search Console sertifika hataları

• “The HTTPS URL has an invalid SSL certificate. Typically this affects an entire site.” — Google Search Console Help, HTTPS report. Jump to quote
• “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” — Google Search Console Help, HTTPS report. Bu konu için en önemli tek satır: bozuk sertifikanın gerçek tarama sonucu. Jump to quote
• “The host name of your site does not match any of the Subject Names in your SSL certificate.” — Google Search Console Help, SSL certificate problems. Jump to quote
• “Your site uses an SSL certificate which is not recognized by major web browsers.” — Google Search Console Help, SSL certificate problems. Jump to quote

Google — kanonik tercih ve kötü sertifikalar

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” / “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (Türkçesi: Google, sorunlar veya çelişen sinyaller olmadıkça eşdeğer HTTP sayfalarına göre HTTPS sayfalarını kanonik olarak tercih eder; kötü TLS/SSL sertifikalarından kaçının, çünkü Google’ın HTTP’yi çok güçlü biçimde tercih etmesine neden olurlar ve HSTS bu tercihi geçersiz kılamaz.) — Google Search Central, Consolidating duplicate URLs. Read the source

Google / web.dev — sertifika kapsamı ve maliyet

• “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” — web.dev, Enable HTTPS on your servers. Jump to quote (Türkçesi: Wildcard sertifikalarında wildcard yalnızca bir DNS etiketine uygulanır; *.example.com, foo.example.com ve bar.example.com adreslerinde çalışır, ancak foo.bar.example.com adresinde çalışmaz.)
• “Different CAs charge different amounts of money for the service of vouching for your public key.” (Türkçesi: Farklı CA’ler açık anahtarınızı doğrulama hizmeti için farklı miktarlarda ücret alır.) — web.dev, Enable HTTPS on your servers. Jump to quote

SSL.com — doğrulama seviyeleri

• “Domain Validation (DV) is the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (Türkçesi: Alan adı doğrulaması (DV), en düşük doğrulama seviyesidir ve sertifikayı isteyen kişinin sertifikanın koruduğu alan adını kontrol ettiğini doğrular.) Jump to quote
• “Extended Validation (EV), like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (Türkçesi: Genişletilmiş doğrulama (EV), OV gibi bir kuruluşun kimliğini doğrular; ancak EV daha yüksek bir güven standardını temsil eder ve daha sıkı doğrulama kontrolleri gerektirir.) Jump to quote

John Mueller, Google Search Relations (Search Engine Journal’ın Mayıs 2023’te aktardığı sosyal medya yanıtı)

• “@EncryptedFence this does not ‘Boost your website’s SEO’, sorry.” Mueller’ın Mastodon yanıtından, Search Engine Journal aracılığıyla alıntılanmıştır — Google’ın sahip olduğu bir sayfa değil, şema tabanlı çerçeveyi destekleyen ENDÜSTRİ düzeyinde bir doğrulamadır. Doğrudan alıntı yapacaksanız orijinal gönderiyle karşılaştırın. Read the coverage

Glenn Gabe, GSQi (süresi dolmuş sertifika vaka çalışması, Eylül 2013)

• “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” Sektör vaka çalışması; 2013’teki tarayıcı arayüzü ayrıntıları günceldir denemez, ancak teşhis dersi kalıcıdır. Read the case study

Hangi sertifikayı almalıyım?

Yukarıdan aşağıya ilerleyin. İlk iki soru önemli olan her şeyi belirler; geri kalanı kapsam hesabıdır.

1. Google’ın siteyi sıralamasına ihtiyacınız var mı? Bu, zaten https:// üzerinde bulunarak çözülür — herhangi bir geçerli sertifika size aynı sıralama sinyalini verir. Bu nedenle bu soru sizi hiçbir zaman daha pahalı bir sertifikaya yöneltmez. Devam edin.

2. İnsanlara doğrulanmış kuruluş kimliğini göstermeniz gerekiyor mu (ve yasal/uyum gereklilikleri bunu zorunlu kılıyor mu)?

• Hayır (ezici çoğunluk — bloglar, içerik siteleri, çoğu e-ticaret sitesi) → DV sertifikası. Let’s Encrypt’ten ücretsiz, otomatik, tamam.
• Evet (bankacılık ve uyum ekibinin OV/EV gerektirdiği bazı düzenlemeye tabi/kurumsal bağlamlar) → OV (veya belirli bir gereklilik adını veriyorsa EV). EV’nin artık özel bir tarayıcı göstergesi sunmadığını (Chrome 77+/Firefox 70+) bilin; ödediğiniz şey görünür bir rozet değil, inceleme kaydıdır.

3. Kaç ana bilgisayar adını güvenceye alıyorsunuz? (kapsama alanı — 2. adımdan bağımsız)

• Tek ana bilgisayar adı (yalnızca www.example.com) → tek alan adlı sertifika.
• Bir alan adının altındaki birçok birinci düzey alt alan adı (shop., blog., app. example.com) → wildcard (*.example.com). Ancak bunların hiçbirinin ikinci düzey (api.staging.example.com) olmadığını doğrulayın — wildcard bunları kapsamaz.
• Belirli ve karışık bir liste, muhtemelen farklı alan adları arasında (example.com + example.net + brand.io) → her adı listeleyen SAN / çok alan adlı (UCC) sertifika.
• Wildcard’ın ulaşamadığı ikinci düzey alt alan adları → o düzeyde ikinci bir wildcard kullanın veya bunları SAN sertifikasına açıkça ekleyin.

4. Hangi anahtar algoritması ve bu ana bilgisayar adına gerçekte kaç edge/origin hizmet veriyor? RSA ile ECDSA arasında seçim güvenlik/istemci uyumluluğu dengesidir, sıralama aracı değildir — bazı eski veya gömülü istemciler ECDSA’yı desteklemez; bu yüzden seçim yapmadan önce CDN’nizin veya yük dengeleyicinizin ne sunduğunu kontrol edin. Ana bilgisayar adının önünde birden fazla edge, bölge veya origin varsa (CDN, SNI tabanlı paylaşımlı barındırma, birden çok yük dengeleyici), her yolu bağımsız olarak test edin; birindeki temiz sonuç diğerlerinin kapsandığını doğrulamaz.

5. Yenileme otomatik olacak mı?

• Evet → iyi; kısa geçerlilik süreleri sorun değildir (ve kısalıyor — 2029’a kadar azami 47 gün).
• Hayır → önce bunu düzeltin. Manuel yenileme zaten kırılgandır ve geçerlilik süreleri kısaldıkça işlemez hale gelir. ACME/Certbot veya host/CDN tarafından yönetilen bir sertifika kullanın.

Canlı bir sertifika hatasını ayıklamak yerine belirti hangisi?

• Masaüstü Chrome’da çalışıyor, mobilde/araçlarda çalışmıyor → neredeyse her zaman eksik ara sertifika (zincir) hatasıdır. SSL Labs veya openssl s_client -showcerts ile test edin ve tam zinciri kurun.
• Tüm site aniden uyarı veriyor / düştü → önce süre sonunu kontrol edin (tüm siteyi aynı anda bozar).
• Tek bir alt alan adı uyarıyor, diğerleri iyi → karma sertifika / kapsam boşluğu — bu ana bilgisayar kendi sertifikası veya wildcard’ın tek etiketlik sınırı tarafından kapsanmıyor.
• Uyarı yanlış siteyi adlandırıyor → ana bilgisayar adı uyuşmazlığı (sertifikanın Subject Names alanında hizmet verdiğiniz ana bilgisayar adı yok).

Sertifika sağlığı kontrol listesi

Sertifikalarınızın geçerli ve kapsayıcı olduğunu, sessizce süresinin dolmayacağını doğrulamak için bir geçiş:

• Herkese açık her ana bilgisayar adı (apex, www ve her alt alan adı) yalnızca ana sayfa değil, geçerli ve güvenilir bir sertifika üzerinden sunuluyor.
• Tam zincir kurulu (yaprak ve ara sertifika) — masaüstü Chrome nokta kontrolüyle değil, SSL Labs veya openssl s_client -showcerts ile doğrulandı.
• Yenileme otomatiktir (ACME/Certbot, host/CDN yönetimli veya PaaS) — hiçbir yerde insan hatırlatıcısına dayalı yenileme yok.
• Bir sertifika/çalışırlık izleyicisi, yaklaşan süre sonu ve el sıkışması arızaları için arka plan önlemi olarak uyarı verir.
• Ana bilgisayar adı uyuşmazlığı yok — sunulan her ana bilgisayar sertifikanın Subject Alternative Names alanında listelenmiş veya ona ulaşan bir wildcard ile kapsanmış.
• Wildcard’lar için tek etiket sınırı kontrol edildi — ikinci düzey alt alan adları (a.b.example.com) *.example.com dışında sessizce kalmıyor.
• Herkese açık üretim ana bilgisayarında kendinden imzalı sertifika yok (yalnızca geliştirme/test için uygundur).
• Doğrulama derinliği SEO beklentisiyle değil, insan/uyum ihtiyacıyla seçildi (DV sıralama için yeterlidir; OV/EV sıralama değil kimlik satın alır).
• Google Search Console HTTPS raporu, “invalid certificate” / “HTTPS not evaluated” işaretleri için incelendi.
• Farklı platformlardaki/CDN’lerdeki alt alan adlarının envanteri çıkarıldı — her birinin izlenen kendi yenilemesi var.

Zihinsel modeller

1. Tek bir eksen değil, iki eksen. Bir sertifikanın doğrulama derinliği (DV/OV/IV/EV) ve kapsama alanı (tek alan adı/wildcard/SAN) vardır. Bunlar bağımsızdır — DV wildcard veya OV tek alan adlı sertifikanız olabilir. Her birine ayrı karar verin ve Google’ın hiçbirini görmediğini hatırlayın.

2. Sıralama sinyali sertifika seviyelerini ayırt etmez. Geçerli ve çalışan bir sertifikayla https:// üzerinde olmak, sertifika otoritesinden, fiyattan veya doğrulama seviyesinden bağımsız olarak (küçük) sinyali aynı şekilde kazandırır. Bu nedenle “hangi sertifika SEO’ya yardımcı olur” sorusu seviyeler arasında kategori hatasıdır — hiçbiri diğerinden daha fazlasını yapmaz. Bu, geçerliliğin kendisinin görünmez olduğunu söylemek değildir — 3. maddeye bakın.

3. Sertifika sorunları sıralama seviyesi değil; kanonik tercih, tarama erişimi ve kullanıcı deneyimi acil durumudur. Sertifika bozulduğunda kullanıcılar tarayıcı uyarısında geri döner; Google’ın normal HTTPS-HTTP kanonik tercihi HTTP’ye dönebilir (HSTS bunu geçersiz kılamaz) ve yeterli HTTPS sorunu Google’ın HTTPS sayfalarınızı taramayı tamamen durdurmasına yol açabilir. Bunların hiçbiri sıralama sinyalinin kendisinden geçmez — ancak “şema değişmedi” ifadesi bozuk sertifikayı zararsız saymak için neden değildir. Sertifikayı düzeltin; peşinden gidilecek bir sıralama faktörü yoktur.

4. Geçerlilik süreleri kısalırken bütün oyun otomasyondur. Sektör 47 günlük sertifikalara doğru ilerliyor. Yenileme otomatikleştirildiğinde kısa geçerlilik süreleri kesinlikle daha güvenlidir (daha küçük tehlikeye maruz kalma penceresi, unutabilecek insan yok). Gerçek tek risk otomasyon yapmamaktır.

5. Ana sayfadaki asma kilit bir ana bilgisayar adını kanıtlar, daha fazlasını değil. Alt alan adlarında kapsam, süre sonu takvimleri ve platformlar farklıdır. Her ana bilgisayarın envanterini çıkarın ve izleyin — tek yeşil asma kilitten genelleme yapmayın.

6. Dizüstü bilgisayarınızı değil, zinciri test edin. Masaüstü Chrome ara sertifikaları önbelleğe alır ve sizi yanıltır. Temiz bir oluşturucudan (SSL Labs, openssl s_client) doğrulama yapın; böylece eksik ara sertifika hatası gizlenemez.

SSL/TLS sertifikaları — kısa başvuru

Doğrulama derinliği (CA neyi doğruladı)

Kapsama alanı (hangi ana bilgisayar adlarını güvenceye alır)

Geçerlilik süresi değişimi (CA/Browser Forum azami geçerliliği)

Sertifika bozulduğunda

Hızlı bilgiler

• Ücretsiz DV (Let’s Encrypt) = ücretliyle aynı şifreleme + aynı sıralama.
• Google’ın sinyali sertifikayı değil şemayı okur.
• Yeterli HTTPS sorunu Google’ın HTTPS sayfalarınızı taramasını durdurabilir.
• Yenilemeyi ACME/Certbot veya host/CDN yönetimli sertifika üzerinden otomatikleştirin.

Bir sertifikayı ve tam zincirini inceleyin

Sertifika hata ayıklama için en kullanışlı komut. -showcerts, sunucunun gerçekten gönderdiği her sertifikayı yazdırır — eksik bir ara sertifikayı yakalamanın en hızlı yoludur.

macOS / Linux

# Show the full chain the server sends (leaf + intermediates)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Just the expiry dates (notBefore / notAfter)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# The hostnames the cert actually covers (Subject Alternative Names)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

-servername bayrağı SNI’yi ayarlar — bir IP’nin birden çok sertifika sunduğu paylaşımlı/CDN barındırmada doğru sertifikayı test etmek için önemlidir.

Windows (PowerShell) — süre sonunu ve kapsanan adları kontrol edin

# Pull the served certificate and read its expiry + Subject Alternative Names
$req = [Net.HttpWebRequest]::Create("https://example.com")
$req.GetResponse().Dispose()
$cert = $req.ServicePoint.Certificate
$cert2 = [System.Security.Cryptography.X509Certificates.X509Certificate2]$cert
"Expires: " + $cert2.NotAfter
$cert2.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } |
  ForEach-Object { $_.Format($true) }

Chrome DevTools Console — güvenli olmayan alt kaynak URL’lerini işaretleme

HTML’de hâlâ başvurulan http:// alt kaynaklarını listelemek için herhangi bir sayfada Console’a yapıştırın (sertifikaları denetlerken hızlı bir karma-içerik nokta kontrolü):

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.getAttribute('src') || el.getAttribute('href'))
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('insecure:', u));

Her ana bilgisayar adında kapsamı kontrol etmek için harici bir doğrulayıcı (SSL Labs), ana bilgisayar başına komut dosyası çalıştırmaktan daha iyidir — ancak bunlar önünüzdeki kutu için hızlı kontrollerdir.

Sertifika karşıtı kalıplar

Tekrar tekrar gördüğüm arıza biçimleri:

EV/OV’yi “SEO için” satın almak. Google doğrulama derinliğini göremez. Var olmayan bir sıralama avantajı için daha fazla para ödemek saf israftır. Doğrulama derinliğini yalnızca gerçek bir insan güveni veya uyum nedeni varsa satın alın.

Sertifikayı yalnızca masaüstü Chrome’da doğrulamak. Chrome ara sertifikaları önbelleğe alır ve başka her yerde başarısız olan kırık bir zincirin üzerinde yeşil asma kilit gösterir. Her zaman temiz bir oluşturucudan (SSL Labs, openssl s_client -showcerts) doğrulayın.

Manuel yenileme hatırlatıcıları. Takvim kaydı yenileme sistemi değildir. Birinin tatilde olduğu sırada tüm siteyi aynı anda bozabilir — ayrıca geçerlilik süreleri 47 güne doğru kısaldıkça her yıl daha kötü hale gelir. Otomatikleştirin.

Wildcard’ın alan adının altındaki her şeyi kapsadığını varsaymak. *.example.com tek bir DNS etiketinde durur. staging.api.example.com kapsam dışıdır ve bir kullanıcı veya Googlebot erişene kadar kimsenin fark etmediği hataları verir.

Yalnızca ana sayfayı nokta kontrolü yapmak. Diğer platformlardaki/CDN’lerdeki alt alan adlarının kendi sertifikaları ve kendi takvimleri vardır. Geçerli bir apex asma kilidi, blog. adresi veya bir pazarlama alt alan adının sessizce süresinin dolması hakkında hiçbir şey söylemez.

Herkese açık üretimde kendinden imzalı sertifikalar. Kesin bir tarayıcı geçiş uyarısı gösterir ve çoğu doğrulayıcı ile tarayıcı tarafından işaretlenir/başarısız kabul edilir. Dahili/geliştirme/test için uygundur; herkese açık üretimde asla kullanmayın.

Bozuk bir sertifikayı sıralama seviyesi sorunu veya zararsız bir şey olarak görmek. Bu bir sıralama seviyesi aracı değildir, ancak zararsız da değildir: bozuk bir sertifika Google’ın kanonik tercihini HTTPS’den HTTP’ye çevirebilir, tarama erişimini kısıtlayabilir ve kullanıcıların geri dönmesi nedeniyle dönüşümleri çökertebilir. Sertifikayı düzeltin; sıralama faktörlerinin peşine düşmeyin ve “şema değişmedi” ifadesinin hiçbir şey olmadığını varsaymayın.

Sertifika yenileme ve dağıtım SOP’si

1. Ana bilgisayar adı envanteri tutun. Apex’i, www’yi, alt alan adlarını, daha derin alt alan adlarını, CDN veya yük dengeleyici uç noktalarını, sertifika otoritesini, kapsam türünü, yenileme sahibini ve otomasyon yolunu kaydedin.
2. Süre sonunu sertifika otoritesinden bağımsız izleyin. Başarısız otomasyonu araştırmak ve takvimi sertifikanın gerçek ömrüyle hizalamak için yeterince erken uyarı verin; tek başına takvim hatırlatıcısı yenileme sistemi değildir.
3. Otomatik yenilemeyi uygulayın. ACME, host veya CDN iş akışının eski sertifikayı bellekte tutan her sunum sürecini manuel adım olmadan isteyebildiğini, doğrulayabildiğini, kurabildiğini, etkinleştirebildiğini ve yeniden yükleyebildiğini doğrulayın.
4. Adayı doğrulayın. Üretimde kullanmadan önce istenen ana bilgisayar adlarını/SAN’ları, wildcard derinliğini, sertifika otoritesini, geçerlilik penceresini ve eksiksiz ara sertifika zincirini kontrol edin.
5. Her sunum katmanına dağıtın. TLS’yi sonlandıran her edge’i, proxy’yi, yük dengeleyiciyi ve origin’i güncelleyin; tek bir başarılı uç noktanın tüm bölgeleri veya ana bilgisayar adlarını kapsadığını varsaymayın.
6. Harici test edin. Temiz bir zincir doğrulayıcı ve temsili ana bilgisayarlar üzerinde SNI kullanan openssl s_client kullanın. Tarayıcının önbelleğe alınmış ara sertifikalarını paylaşmayan istemcileri de dahil edin.
7. Döngüyü kapatın. İzlemenin yeni süre sonunu gördüğünü doğrulayın, dağıtımı kaydedin ve hâlâ önceki sertifikayı sunan uç noktaları araştırın.

Başarısız bir yenilemeyi erişilebilirlik olayı olarak ele alın. HSTS kullanan bir ana bilgisayarda ziyaretçiler sertifika hatasını güvenle geçemez.

Sertifika inceleme araç seti

• SSL Labs Server Test — sunulan sertifikayı, zinciri, ana bilgisayar adı kapsamını, protokol desteğini ve uç nokta farklılıklarını harici olarak doğrular.
• openssl s_client — bir ana bilgisayar adının SNI ile tam olarak ne sunduğunu inceleyin ve tam zinciri yazdırın; tarihler ve Subject Alternative Names için bunu openssl x509 ile birlikte kullanın.
• Tarayıcı sertifika görüntüleyicisi ve DevTools — etkilenen istemcide kullanıcıya gösterilen ana bilgisayar adını, güveni ve süre sonu hatasını yeniden üretin.
• Bağımsız sertifika izleme — sertifika otoritesi veya CDN yenilemenin otomatik olduğunu söylese bile envanterdeki her ana bilgisayar adı için uyarı verin.
• Google Search Console HTTPS raporlaması — daha geniş HTTPS sunum sorunlarını izleyin; uç nokta düzeyindeki teşhis için sertifika araçlarını kullanın.

Yalnızca IP veya ana sayfaya göre değil, ana bilgisayar adına göre test edin. Paylaşımlı altyapı, SNI’ye, bölgeye veya edge düğümüne bağlı olarak farklı bir sertifika sunabilir.

Sertifika yayınlama testleri

Test 1: ana bilgisayar adı ve zincir kapsamı

• Amaç: Herkese açık her ana bilgisayar adının, gerçekten üzerinde adının bulunduğu güvenilir bir sertifika almasını kanıtlamak.
• Yöntem: Apex, openssl s_client -servername, her alt alan adı sınıfı ve tek etiketlik wildcard tarafından kapsanmayan daha derin ana bilgisayarlar için SSL Labs ve www çalıştırın.
• Beklenen sonuç: Ana bilgisayar adı bir SAN ile eşleşir, zincir eksiksizdir ve temiz bir istemci önbelleğe alınmış ara sertifika sağlamadan doğrular.
• Arıza tetikleyicisi: Ad uyuşmazlığı, kendinden imzalı yaprak, eksik ara sertifika veya bir uç noktada farklı sertifika.
• Sonraki işlem: Sertifika kapsamını veya sunum zincirini düzeltin, yeniden dağıtın ve etkilenen her uç noktayı yeniden test edin.

Test 2: yenileme otomasyonu provası

• Amaç: Yenilemenin varsayım değil, işletilen bir süreç olduğunu doğrulamak.
• Yöntem: Desteklenen hazırlık veya deneme yenileme yolunu çalıştırın, ardından iş akışının TLS’yi sonlandıran her katmana yenisini kurup etkinleştirebildiğini doğrulayın.
• Beklenen sonuç: Doğrulama, düzenleme, dağıtım ve izleme manuel kurtarma adımı olmadan tamamlanır.
• Arıza tetikleyicisi: Başarısız alan adı doğrulaması, izin hatası, eski edge düğümü veya önceki sertifikayı bildirmeye devam eden izleme.
• Sonraki işlem: Üretim yenileme penceresi acil hale gelmeden otomasyonu onarın ve tekrarlayın.

Test 3: dağıtım sonrası istemci kontrolü

• Amaç: Tek bir tarayıcının gizlediği uç nokta ve istemci farklılıklarını yakalamak.
• Yöntem: Birden çok ağ ve temiz istemciyi test edin, sunulan seri numaralarıyla süre sonu tarihlerini karşılaştırın ve daha geniş sonuçlar için Search Console HTTPS raporlamasını inceleyin.
• Beklenen sonuç: Test edilen tüm uç noktalar amaçlanan sertifikayı sunar ve sayfalar HTTPS üzerinden taranabilir kalır.
• Arıza tetikleyicisi: Bölgesel tutarsızlık, sertifika uyarısı, HTTPS raporunda gerileme veya başarısız tarama.
• Sonraki işlem: Eksik uç noktayı ileri taşıyın veya dağıtım yolu düzeltilirken son geçerli sertifikayı geri yükleyin.

Kendinizi test edin: SSL/TLS Sertifikaları

Sertifikaların SEO ile ilişkisi hakkında beş kısa soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Zaman ayırmaya değer kaynaklar

Konuşmalarım

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — TLS, yaygın sertifika/uygulama arızaları ve taşıma tuzakları üzerine derinlemesine incelemem. Bing ve Baidu ile TLS SNI taşımasının dizinden çıkarma riskini de burada işaret ettim — aynı yıl Search Engine Land, SNI tabanlı HTTPS taşımalarından kaynaklanan gerçek Bing tarama/sıralama düşüşlerini bildirdi. (Sürekli geçerli uyarı: bu sistemlere ilişkin anlayışım budur ve sunumdaki benimsenme istatistikleri 2016’ya aittir — bu rakamları güncelmiş gibi alıntılamayın.)

İlgili yazılarım

• The Beginner’s Guide to Technical SEO — sertifikaların ve HTTPS’nin daha geniş teknik çerçeveye nasıl oturduğu.

Diğerlerinden (resmî / yetkili)

• Google’ın HTTPS report ve SSL certificate problems belgeleri — Search Console’un gösterdiği sertifika hatalarının ve anlamlarının kesin listesi.
• Google’ın Enable HTTPS on your servers (web.dev) belgesi — CA’ler, CSR’ler ve wildcard/çok ad kapsamı, doğrudan Google’dan.
• Google’ın Consolidating duplicate URLs belgesi — kötü sertifikaları Google’ın HTTPS yerine HTTP’yi tercih etmesinin nedeni olarak adlandıran kanonik tercih kılavuzu.
• SSL Labs Server Test — TLS yapılandırmanızı derecelendirir ve en önemlisi eksik sertifika zincirlerini işaretler.

Sektörün farklı yerlerinden

• DV, OV, IV, and EV Certificates (SSL.com) — her doğrulama seviyesinin CA tarafından yazılmış açık tanımları.
• A Wolf in Panda’s Clothing — How An Expired SSL Certificate Could Impact Organic Search Traffic (Glenn Gabe, GSQi) — süresi dolmuş sertifikanın Panda cezası sanıldığı vaka çalışması.
• Google: SSL Certificate Does Not Boost SEO (Search Engine Journal) — John Mueller’ın düz “does not boost your SEO” yanıtı.
• Shorter Certificate Lifetimes and Rate Limits (Let’s Encrypt) — ücretsiz CA’nın Şubat 2026’da varsayılan süresini 90 günden 64 ve 45 güne indirme güncellemesi.
• TLS Certificate Lifetimes Will Officially Reduce to 47 Days (DigiCert) — CA/Browser Forum Ballot SC-081v3 aşamalı geçiş takvimi.
• SSL errors that affect SEO (SISTRIX) — ana bilgisayar adı, süre sonu, protokol ve karma içerik sorunlarına pratik bakış.
• Certbot (EFF) — sertifika düzenleme ve yenilemeyi otomatikleştirmek için standart ACME istemcisi.

Alıntılanmaya değer istatistikler

• Sertifikanın azami geçerlilik süresi 2029’a kadar 47 güne düşüyor. CA/Browser Forum Ballot SC-081v3 (oylama 11 Nisan 2025’te kapandı), azamiyi 398 günden → 200 güne (Mart 2026) → 100 güne (Mart 2027) → 47 güne (Mart 2029) aşamalı olarak indiriyor — otomatik yenilemeyi zorunlu kılan sayı. Source
• Let’s Encrypt varsayılan geçerlilik süresini 90 günden 64 ve 45 güne indiriyor. Şubat 2026 güncellemesine göre ücretsiz CA, sonraki iki yıl içinde iki adımda ilerliyor; bu duyuruda her adımın kesin yayın tarihleri belirtilmedi. Source
• Bozuk sertifika “Typically this affects an entire site.” Google’ın etki alanını kendi çerçevelemesi — süre sonu ve zincir arızaları nadiren tek bir sayfayı bozar, her şeyi aynı anda bozar. Source
• Yeterli HTTPS sorunu Google’ın HTTPS sayfalarınızı taramasını durdurabilir. Google’ın raporundaki “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages” ifadesi, temel sıralama sinyalinden ayrı bir tarama erişimi sonucunu anlatır — kötü bir sertifikanın tetikleyebileceği Google’ın kanonik tercihinin HTTP’ye dönmesinden de ayrı. Source
• Kötü bir sertifika Google’ın HTTPS kanonik tercihini geçersiz kılabilir ve HSTS bunu durduramaz. Google’ın kılavuzu kötü TLS/SSL sertifikalarını, Google’ın HTTP sürümünü “very strongly” tercih etmesinin nedeni olarak adlandırıyor. Source

Değişiklik günlüğü