Sertifikat SSL/TLS

TL;DR — Sertifikat SSL/TLS adalah berkas di server yang memungkinkan ikon gembok dan https://. Ada versi murah dan mahal, tetapi nilainya sama untuk SEO: Google melihat skema https://, bukan merek atau harga sertifikat. Sertifikat gratis dari Let’s Encrypt diperlakukan sama seperti sertifikat mahal. Masalah yang sebenarnya adalah sertifikat rusak: jika kedaluwarsa atau salah konfigurasi, browser menampilkan peringatan keras dan pengunjung pergi.

Apa sebenarnya sertifikat SSL itu?

HTTPS modern memakai sertifikat TLS untuk mengautentikasi domain dan membentuk koneksi terenkripsi. 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 merekomendasikan HTTPS dan memakainya sebagai salah satu sinyal kanonisasi, tetapi harga sertifikat atau tingkat validasinya bukan faktor peningkat peringkat yang didokumentasikan. 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

Ketuk untuk memperbesar

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.

Saat Anda membuka situs aman, browser dan server melakukan proses awal singkat untuk menyiapkan enkripsi. Sertifikat diserahkan server selama proses ini. Fungsinya ada dua: memberikan jaminan mengenai pemilik situs (dengan tingkat pemeriksaan yang berbeda-beda) dan membawa kunci yang mengenkripsi koneksi.

Orang sering menyebutnya “SSL certificate” (terjemahan) “sertifikat SSL”, padahal protokol modern sebenarnya adalah TLS. Sebutan “SSL” telanjur melekat. Panduan HTTPS membahas istilah tersebut dan pertanyaan apakah HTTPS membantu peringkat; halaman ini berfokus pada sertifikatnya.

Apakah sertifikat yang lebih mahal membantu SEO?

Tidak. Ini salah satu mitos paling umum. Google tidak mendokumentasikan perbedaan peringkat berdasarkan jenis, penerbit, atau harga sertifikat. Selama HTTPS valid dan berfungsi, Google tidak membedakan sertifikat seharga USD 300 per tahun dari sertifikat gratis. John Mueller dari Google menanggapinya dengan tegas: “this does not ‘Boost your website’s SEO’, sorry.” (terjemahan) “ini tidak ‘meningkatkan SEO situs web Anda’, maaf.”

Karena itu, sertifikat gratis dari Let’s Encrypt diperlakukan sama seperti pilihan termahal yang dijual penerbit sertifikat. Biaya tambahan membeli tingkat verifikasi dan kepercayaan untuk manusia, bukan keunggulan peringkat.

Jenis-jenis sertifikat

Dua aspek berbeda dan sebaiknya tidak dicampuradukkan:

• Seberapa jauh identitas diverifikasi. Sertifikat dasar hanya membuktikan bahwa Anda mengendalikan domain. Sertifikat yang lebih mahal dapat memverifikasi identitas hukum perusahaan. Bagi Google, perbedaan ini tidak memengaruhi peringkat.
• Cakupannya. Satu sertifikat dapat mencakup satu nama host, seluruh kelompok subdomain dengan wildcard, atau daftar nama tertentu melalui sertifikat SAN.

bagian itu sebenarnya penting untuk SEO

Sertifikat yang berfungsi tidak terasa oleh pengguna. Sertifikat rusak menimbulkan masalah:

• Sertifikat kedaluwarsa memicu peringatan browser satu layar penuh. Pengunjung pergi sebelum sempat melihat halaman; akibatnya dapat menyerupai penurunan peringkat, padahal orang berhenti di pintu masuk.
• Sertifikat yang benar-benar rusak juga dapat membuat Google lebih memilih versi HTTP daripada versi HTTPS. Google biasanya memilih HTTPS, tetapi panduannya menyatakan bahwa sertifikat buruk dapat mengalahkan preferensi tersebut, bahkan ketika HSTS diterapkan.
• Jika masalah HTTPS cukup banyak, Google bahkan dapat berhenti merayapi halaman HTTPS, yang pada akhirnya dapat membuat halaman hilang dari hasil Penelusuran.

Aturan praktisnya sederhana: pilih sertifikat murah atau gratis dan jangan pernah membiarkannya kedaluwarsa. Siapkan pembaruan otomatis.

Ingin membahas DV, OV, dan EV; wildcard dibanding SAN; rantai sertifikat; pemendekan masa berlaku; serta dampak tepatnya bagi perayap saat sertifikat rusak? Buka tab Lanjutan.

TL;DR — Google tidak mendokumentasikan perbedaan peringkat antara tingkat validasi DV/OV/IV/EV atau sertifikat gratis dan berbayar. Harga yang lebih tinggi membeli kepercayaan manusia atau organisasi, bukan peringkat. Kedalaman validasi dan cakupan nama host (domain tunggal, wildcard, atau SAN) merupakan dua keputusan terpisah; keduanya bukan faktor peringkat yang terdokumentasi. Penerbitan otomatis gratis melalui ACME, termasuk Let’s Encrypt, tidak mengorbankan kekuatan enkripsi atau perlakuan Google. Risiko SEO muncul ketika sertifikat kedaluwarsa, ditandatangani sendiri, tidak cocok dengan nama host, atau rantainya rusak. Kegagalan ini menghalangi pengguna, dapat membuat Google kembali memilih versi HTTP sebagai kanonis meskipun HSTS aktif, dan dapat menghentikan perayapan halaman HTTPS. Karena masa berlaku maksimum akan menyusut menjadi 47 hari pada 2029, pembaruan otomatis wajib.

Panduan HTTPS menjelaskan bahwa HTTPS umumnya hanya sinyal pembeda, bahwa Google melihat skema dan bukan sertifikat, serta bahwa sertifikat DV gratis memperoleh sinyal yang sama dengan sertifikat OV atau EV mahal. Artikel ini melanjutkan pembahasan hingga ke sertifikatnya: arti DV/OV/IV/EV, cara kerja cakupan nama host, alasan sertifikat otomatis gratis tetap layak, cara kegagalan rantai dapat luput dari pengujian Anda, dan apa yang terjadi pada perayapan—bukan hanya pengguna—ketika sertifikat rusak.

“Sertifikat SSL” sebenarnya adalah sertifikat TLS

SSL adalah obsolete terminology untuk modern TLS deployments. 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 penelusuran panduan focuses pada valid, accessible HTTPS alih-alih commercial sertifikat tier. 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

Catatan istilah: SSL (Secure Sockets Layer) adalah protokol lama yang sudah tidak digunakan; sertifikat modern berjalan pada TLS (Transport Layer Security). Istilah “SSL certificate” (terjemahan) “sertifikat SSL” tetap bertahan dalam percakapan sehari-hari, bahkan antarmuka Search Console Google masih menyebut “masalah sertifikat SSL”. Selanjutnya, artikel ini cukup memakai istilah “sertifikat”.

Kedalaman validasi: DV vs OV vs IV vs EV

Sertifikat diterbitkan dengan tingkat validasi berbeda, yang menunjukkan seberapa jauh otoritas sertifikat (CA) melakukan pemeriksaan sebelum menjamin identitas pemohon. Menurut penjelasan SSL.com:

• DV (Domain Validation) adalah “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (terjemahan) “ lowest tingkat dari validation, dan verifies itu siapa pun yang meminta sertifikat mengendalikan domain yang dilindungi sertifikat.” Prosesnya cepat, murah atau gratis, dan biasanya otomatis melalui bukti kontrol berupa catatan DNS atau berkas yang dapat diambil CA.
• 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.” (terjemahan) “memverifikasi identitas organisasi—misalnya perusahaan, lembaga nirlaba, atau badan pemerintah—yang tercantum sebagai Subjek sertifikat, beserta lokasi operasinya.”
• IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (terjemahan) “memverifikasi identitas orang yang tercantum sebagai Subjek sertifikat.”
• 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.” (terjemahan) “seperti OV, EV memverifikasi identitas organisasi. Namun, EV mewakili standar kepercayaan yang lebih tinggi daripada OV dan memerlukan pemeriksaan validasi yang lebih ketat.”

Poin yang relevan bagi SEO: Google tidak mendokumentasikan perbedaan peringkat antar-tingkat validasi. Sinyal dasarnya membaca skema URL—Illyes menggambarkannya sebagai melihat lima karakter pertama URL. Selama HTTPS valid dan berfungsi, sertifikat DV, OV, dan EV memperoleh perlakuan yang sama. Perbedaan harga mencerminkan upaya pemeriksaan dan tanggung jawab CA, bukan preferensi Google. web.dev menyatakan bahwa “different CAs charge different amounts of money for the service of vouching for your public key.” (terjemahan) “CA yang berbeda mengenakan biaya berbeda untuk layanan penjaminan kunci publik Anda.” Biaya tambahan itu membeli kepercayaan manusia dan organisasi, bukan peringkat.

Satu alasan EV yang dahulu terlihat oleh pengguna juga hampir lenyap: perlakuan khusus EV di bilah alamat browser pada praktiknya sudah hilang. Chrome menghapus tampilan hijau nama perusahaan mulai Chrome 77 pada 2019, lalu Firefox 70 menyusul pada tahun yang sama. Karena itu, alasan “pelanggan melihat nama perusahaan kami di bilah alamat” tidak lagi berlaku di browser utama. Periksa perilaku browser terkini saat membuat keputusan pembelian, tetapi sinyal visual tersebut kini umumnya tidak ada.

Cakupan: domain tunggal vs wildcard vs SAN

Kedalaman validasi adalah satu sumbu. Cakupan—nama host mana yang benar-benar diamankan sertifikat—merupakan sumbu lain yang terpisah. Setiap cakupan umumnya dapat diterbitkan sebagai DV atau OV; kebijakan CA/B biasanya tidak menawarkan wildcard untuk EV.

• Domain tunggal — mencakup tepat satu nama host, misalnya www.example.com.
• Wildcard — mencakup pola nama host sedalam satu label DNS. web.dev menjelaskan batasnya: “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.” (terjemahan) “Wildcard hanya berlaku pada satu label DNS; pola tersebut mencakup subdomain tingkat pertama, tetapi tidak subdomain tingkat kedua.” Klausa terakhir adalah hal yang sering menjebak: wildcard tidak mencakup subdomain tingkat kedua.
• SAN / multidomain (UCC) — daftar nama host tertentu di bidang Subject Alternative Names sertifikat. web.dev mencatat adanya “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).” (terjemahan) “Anda dapat memetakan kunci ke lebih dari satu nama DNS, termasuk beberapa nama berbeda, misalnya domain contoh utama dan alternatif beserta subdomain www-nya.” Sertifikat SAN bahkan dapat mencakup beberapa domain yang benar-benar berbeda. Ini berguna bila Anda memiliki sejumlah properti terkait dan tidak ingin menyediakan cakupan wildcard yang berlebihan.

Risiko praktis bagi SEO tersembunyi pada batas satu label wildcard. Misalnya, Anda memakai *.example.com, lalu seseorang membuat staging.blog.example.com. Nama tersebut sedalam dua label sehingga berada di luar cakupan wildcard dan akan memicu kesalahan sertifikat atau menyajikan sertifikat yang tidak cocok. Google maupun pengguna akan mendapati halaman rusak yang Anda kira sudah tercakup.

Jebakan lain: lulus pengujian pada domain apex tidak membuktikan cakupan di semua tempat. Klien harus meminta nama host yang tepat dan menerima sertifikat yang mencantumkan nama tersebut melalui SNI. Pada CDN, penyeimbang beban, dan hosting bersama berbasis SNI, edge, wilayah, atau origin berbeda di balik domain yang sama dapat menyajikan sertifikat berbeda. Uji setiap nama host publik secara terpisah; hasil SSL Labs yang bersih untuk example.com tidak otomatis mewakili www., edge regional, atau subdomain dengan origin berbeda.

Let’s Encrypt dan penerbitan otomatis gratis

Let’s Encrypt dan CA gratis lainnya menerbitkan sertifikat DV melalui protokol ACME, yaitu alur permintaan, tantangan, dan penerbitan otomatis yang dijalankan klien seperti Certbot. Ada dua kesalahpahaman umum:

1. Gratis tidak berarti lebih lemah. Sertifikat Let’s Encrypt menyediakan kekuatan enkripsi TLS yang sama dengan sertifikat berbayar dan, karena sinyal Google berbasis skema, memperoleh perlakuan peringkat yang sama. Perbedaannya adalah validasi hanya DV dan masa berlaku singkat.
2. Masa berlaku singkat menjadi kelebihan setelah prosesnya otomatis. Jika kunci bocor, jangka paparan lebih pendek; yang terpenting, tidak ada orang yang harus mengingat jadwal pembaruan. Otomatisasi membuat masa berlaku yang lebih singkat justru lebih aman.

Kedua poin ini segera relevan bagi semua pengguna sertifikat, bukan hanya Let’s Encrypt.

Perubahan masa berlaku sertifikat (2026–2029)—otomatiskan sekarang

Industri sedang memangkas masa berlaku sertifikat menurut jadwal tetap. CA/Browser Forum mengesahkan Ballot SC-081v3 setelah pemungutan suara ditutup pada 11 April 2025, sehingga masa berlaku maksimum sertifikat TLS berkurang bertahap:

• 398 hari saat ini
• 200 hari mulai 15 Maret 2026
• 100 hari mulai 15 Maret 2027
• 47 hari mulai 15 Maret 2029

Let’s Encrypt juga bergerak lebih cepat. Menurut pembaruan Februari 2026, masa berlaku bawaan akan diturunkan dalam dua tahap selama dua tahun berikutnya—“from 90 days to 64 days, and then 45 days” (terjemahan) “dari 90 hari menjadi 64 hari, lalu 45 hari”—sementara waktu pembaruan bergeser dari sekitar hari ke-60 untuk sertifikat 90 hari menjadi sekitar hari ke-30 untuk sertifikat 45 hari. Pembaruan ini menggantikan jadwal sebelumnya yang lebih spesifik. Anggap tanggal pelaksanaan setiap tahap belum pasti dan periksa log perubahan Let’s Encrypt sebelum mengandalkan tanggal tertentu.

Kesimpulan operasionalnya tegas: jika pembaruan belum otomatis, benahi sebelum 2027. Jadwal manual yang masih dapat bertahan pada 398 hari hampir pasti menimbulkan gangguan pada 47–100 hari. DigiCert merangkumnya dengan baik: validasi ulang manual tetap mungkin secara teknis, tetapi “doing so would be a recipe for failure and outages.” (terjemahan) “melakukannya akan menjadi resep kegagalan dan gangguan layanan.” Otomatisasi bukan lagi pelengkap, melainkan satu-satunya pilihan yang masuk akal.

Rantai sertifikat dan kegagalan sertifikat intermediate

Topik ini jarang dijelaskan dan dokumentasi Google tidak membahas mekanismenya. Berikut cara kerjanya.

Browser hanya mempercayai sejumlah kecil sertifikat root yang ditanamkan dalam penyimpanan kepercayaannya. Sertifikat server Anda—sertifikat leaf atau entitas akhir—hampir tidak pernah ditandatangani langsung oleh root. Rantainya adalah leaf → satu atau beberapa sertifikat intermediate → root tepercaya. Agar klien mempercayai leaf, server harus mengirim leaf beserta intermediate sehingga klien dapat membangun jalur menuju root yang sudah dipercaya.

Salah konfigurasi klasik terjadi ketika server hanya mengirim leaf dan menghilangkan intermediate. Masalah ini berbahaya karena Chrome desktop sering tetap berfungsi: browser menyimpan intermediate yang pernah ditemui di situs lain dan dapat mengisi kekosongan. Penguji di laptop melihat gembok hijau lalu mengira semuanya baik-baik saja, sedangkan browser seluler, banyak klien API/HTTP, dan alat lain tanpa cache tersebut gagal melakukan handshake. Ini adalah bug “berfungsi di komputer saya” pada lapisan TLS.

Untuk menangkapnya, jangan mengandalkan pemeriksaan singkat di Chrome desktop. Gunakan alat yang membangun rantai dari awal:

• SSL Labs’ Server Test menandai “extra download” (terjemahan) “unduhan tambahan” dan masalah rantai tidak lengkap secara jelas.
• openssl s_client -connect example.com:443 -showcerts pada command baris menampilkan setiap sertifikat yang benar-benar dikirim server sehingga Anda dapat memastikan intermediate tersedia.

Apa yang terjadi ketika sertifikat tidak valid, kedaluwarsa, atau ditandatangani sendiri?

Ini bagian terpenting dan terbagi jelas menjadi dua, karena pengguna dan perayap mengalami sertifikat rusak dengan cara berbeda.

Yang dilakukan pengguna dan browser. Kegagalan keras—sertifikat kedaluwarsa, ditandatangani sendiri, nama host tidak cocok, atau CA tidak tepercaya—memicu peringatan satu layar penuh, bukan sekadar label “Tidak Aman” seperti pada HTTP. Pengguna pun pergi. Kasus terdokumentasi terbaik adalah tulisan Glenn Gabe, “A Wolf in Panda’s Clothing” (terjemahan) “Serigala Berbaju Panda”. Trafik sebuah situs ecommerce anjlok pada tanggal yang bertepatan dengan pembaruan Google Panda sehingga pemilik mengira terkena penalti. Penyebab sebenarnya adalah sertifikat kedaluwarsa yang memicu peringatan browser; pengunjung pergi sebelum membuka situs. Seperti kata Gabe: “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.” (terjemahan) “Terkadang masalah yang tampak seperti masalah SEO sebenarnya bukan masalah SEO. Gangguan teknis yang muncul bersamaan dengan pembaruan algoritme dapat membingungkan.” Setelah sertifikat diperbarui, trafik pulih dalam sekitar delapan hari. Sertifikat yang ditandatangani sendiri memicu peringatan keras yang sama di internet publik; sertifikat ini hanya cocok untuk lingkungan internal, pengembangan, atau staging, bukan situs produksi publik.

Apa yang dilakukan Google. Inilah nuansa yang dilewatkan banyak halaman pesaing, dan dampaknya lebih besar daripada sekadar rumusan “sinyalnya berbasis skema”. Panduan kanonisasi Google menegaskan bahwa sertifikat rusak tidak luput dari Penelusuran: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (terjemahan) “Google lebih memilih halaman HTTPS daripada halaman HTTP yang setara sebagai kanonis, kecuali jika ada masalah atau sinyal yang bertentangan,” dan secara khusus menyebut sertifikat buruk sebagai salah satu masalah tersebut—“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.” (terjemahan) “Hindari sertifikat TLS/SSL yang buruk dan pengalihan HTTPS ke HTTP karena keduanya membuat Google sangat memilih HTTP. Penerapan HSTS tidak dapat mengalahkan preferensi kuat ini.” Dengan kata lain, sertifikat yang benar-benar rusak dapat membalik versi kanonis ke HTTP biasa. Ini memengaruhi apa yang tampil di Penelusuran, bukan sekadar anggaran perayapan.

Secara terpisah, dokumentasi Search Console Google menyatakan bahwa kegagalan sertifikat juga berdampak pada perayapan: sertifikat tidak valid “typically affects an entire site,” (terjemahan) “biasanya memengaruhi seluruh situs,” dan “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (terjemahan) “jika situs memiliki banyak masalah HTTPS, Google dapat berhenti merayapi halaman HTTPS Anda.” Saat itu terjadi, URL lainnya diberi label “HTTPS not evaluated” (terjemahan) “HTTPS belum dievaluasi”. Jadi terdapat dua mekanisme berbeda: preferensi kanonis dapat berbalik ke HTTP, dan akses perayapan dapat dibatasi. Keduanya dapat menimbulkan gejala serupa—halaman keluar dari indeks—tanpa mengubah sinyal peringkat dasar https://. Perbaiki sertifikat; tidak ada faktor peringkat lain yang perlu dikejar, tetapi juga jangan menganggapnya aman hanya karena skema URL tidak berubah.

Daftar pemicu Google sesuai dengan jenis kegagalannya: nama host tidak cocok dengan nama pada sertifikat—“The host name of your site does not match any of the Subject Names in your SSL certificate” (terjemahan) “Nama host situs Anda tidak cocok dengan Subject Name mana pun dalam sertifikat SSL”—atau sertifikat “not recognized by major web browsers” (terjemahan) “tidak dikenali browser web utama”, misalnya karena ditandatangani sendiri, CA tidak tepercaya, rusak, kedaluwarsa, atau belum berlaku.

Pemantauan masa berlaku dan pembaruan otomatis

Kedaluwarsa adalah kegagalan sertifikat yang paling umum sekaligus paling mudah dicegah. Dampaknya tidak simetris: biasanya seluruh situs rusak sekaligus—Google menyebut “Typically this affects an entire site” (terjemahan) “Biasanya masalah ini memengaruhi seluruh situs”—bukan satu halaman pada satu waktu. Solusinya bukan pengingat kalender, melainkan otomatisasi nyata:

• ACME / Certbot pada server Anda sendiri, atau layanan setara dari platform.
• Sertifikat yang dikelola host atau CDN (Cloudflare, sebagian besar host terkelola, banyak platform PaaS) yang menerbitkan dan memperbarui sertifikat secara otomatis.
• Pemantau sertifikat atau uptime pihak ketiga yang memberi peringatan menjelang kedaluwarsa dan saat handshake gagal, sebagai perlindungan cadangan meski pembaruan otomatis.

Ketika masa berlaku menyusut menuju 47 hari, pengingat manual tidak lagi dapat dipertahankan; otomatisasi adalah satu-satunya pendekatan yang dapat diskalakan.

Konfigurasi sertifikat campuran pada subdomain

Hal ini berbeda dari mixed content atau konten campuran, yaitu halaman HTTPS yang memuat sub-sumber daya HTTP dan dibahas di hub. Mixed-sertifikat terjadi ketika bagian-bagian situs diamankan oleh sertifikat berbeda dengan jadwal atau platform berbeda. Pola umumnya: domain utama memiliki sertifikat yang andal, tetapi blog.example.com berjalan di platform lain dengan masa berlaku sendiri; subdomain pemasaran pada CDN terpisah tidak tercakup oleh batas satu label wildcard; atau hosting multitenan berbasis SNI diam-diam gagal memperbarui satu subdomain sementara pemeriksaan singkat pada domain utama tampak sempurna.

Pelajarannya: gembok valid di halaman utama tidak memberi tahu apa pun tentang cakupan di tempat lain. Buat inventaris subdomain dan pastikan setiap host memiliki sertifikat valid yang dipantau—sertifikatnya sendiri, wildcard yang menjangkaunya, atau SAN yang mencantumkannya. Jangan mengandalkan satu pemeriksaan SSL Labs untuk menilai seluruh properti.

Mitos umum

• “A paid or EV certificate ranks better than a free DV cert.” (terjemahan) “Sertifikat berbayar atau EV mendapat peringkat lebih baik daripada DV gratis.” Tidak. Sinyalnya berbasis skema; kedalaman validasi tidak terlihat oleh Google.
• “Wildcard certificates cover all subdomains, including sub-subdomains.” (terjemahan) “Sertifikat wildcard mencakup semua subdomain, termasuk subdomain tingkat kedua.” Tidak. Cakupannya hanya satu label DNS; *.example.com tidak mencakup foo.bar.example.com.
• “An expired certificate directly hurts my rankings.” (terjemahan) “Sertifikat kedaluwarsa langsung merusak peringkat saya.” Bukan melalui sinyal peringkat dasar. Namun, sertifikat kedaluwarsa dapat membalik preferensi kanonis Google dari HTTPS ke HTTP—HSTS tidak dapat mengalahkannya—dan masalah HTTPS yang banyak dapat menghentikan perayapan halaman HTTPS. Kedua dampak itu nyata, tetapi tidak bekerja melalui sinyal peringkat dasar.
• “Let’s Encrypt certificates are lower quality than paid ones.” (terjemahan) “Sertifikat Let’s Encrypt berkualitas lebih rendah daripada sertifikat berbayar.” Tidak. Enkripsi dan perlakuan peringkatnya sama; perbedaannya adalah validasi hanya DV dan masa berlaku singkat yang segera menjadi standar industri.
• “If my homepage shows a valid padlock, my whole site’s certs are fine.” (terjemahan) “Jika halaman utama menampilkan gembok valid, semua sertifikat situs pasti baik.” Tidak. Subdomain dapat memakai sertifikat terpisah dengan jadwal berbeda.
• “Chain errors are rare or a legacy problem.” (terjemahan) “Kesalahan rantai jarang terjadi atau hanya masalah lama.” Tidak. Masalah ini umum pada tumpukan yang hanya menyajikan leaf, dan cache Chrome desktop menyembunyikannya dari penguji.

Ini adalah pembahasan mendalam tingkat sertifikat di bawah panduan HTTPS; untuk panduan migrasi, konten campuran, dan HSTS, mulailah dari sana.

Ringkasan AI

Ringkasan singkat dari versi lanjutan:

• Google tidak membedakan tingkat sertifikat untuk peringkat. Selama HTTPS valid, DV, OV, IV, dan EV diperlakukan sama, dan sertifikat Let’s Encrypt gratis setara dengan sertifikat berbayar. Harga yang lebih tinggi membeli kepercayaan manusia atau organisasi, bukan SEO. John Mueller: “this does not ‘Boost your website’s SEO’, sorry.” (terjemahan) “ini tidak ‘meningkatkan SEO situs web Anda’, maaf.”
• Dua sumbu yang terpisah: kedalaman validasi (DV = kontrol domain → OV/IV = identitas → EV = pemeriksaan organisasi yang ketat) dan cakupan (domain tunggal, wildcard, atau SAN). Google tidak melihat keduanya.
• Wildcard hanya mencakup satu label DNS. *.example.com mencakup foo.example.com, tetapi bukan foo.bar.example.com. Sertifikat SAN mencantumkan nama host secara eksplisit dan dapat melintasi domain.
• Tampilan EV di browser sudah hilang sejak Chrome 77 dan Firefox 70 pada 2019, sehingga keunggulan visualnya bagi manusia juga hilang.
• Penerbitan otomatis gratis melalui ACME/Certbot bukan kompromi: enkripsinya dan perlakuan peringkatnya sama. Masa berlaku pendek menjadi kelebihan jika pembaruan telah diotomatisasi.
• Pergeseran masa berlaku: CA/B Forum Ballot SC-081v3 memangkas maksimum 398 → 200 (Maret 2026) → 100 (Maret 2027) → 47 hari (Maret 2029). Let’s Encrypt secara terpisah menurunkan nilai bawaannya dari 90 → 64 → 45 hari dalam dua tahun setelah pembaruan Februari 2026; tanggal setiap tahap belum dikunci. Otomatiskan pembaruan sekarang.
• Kegagalan rantai dapat tersembunyi: server hanya mengirim sertifikat leaf dan tidak mengirim intermediate. Chrome desktop dapat memakai cache sehingga tampak berhasil, sementara klien seluler atau API gagal. Diagnosis dengan SSL Labs atau openssl s_client -showcerts.
• Pengguna dan Google saat sertifikat rusak: pengguna mendapat peringatan layar penuh lalu keluar; sinyal peringkat dasar tidak berubah, tetapi sertifikat rusak dapat membalik preferensi kanonis HTTPS-ke-HTTP ke HTTP meskipun ada HSTS. Secara terpisah, Google dapat “stop crawling your HTTPS pages” (terjemahan) “berhenti merayapi halaman HTTPS Anda”—dua mekanisme berbeda dengan gejala yang sama.
• Kedaluwarsa merusak seluruh situs sekaligus; otomatiskan pembaruan dan pemantauan. Mixed-cert pada subdomain, berbeda dari mixed content, berarti gembok halaman utama tidak membuktikan cakupan subdomain.

Dokumentasi resmi

Primary-sumber dokumentasi pada certificates dari mesin pencari dan standards bodies.

Google

• Laporan HTTPS (Bantuan Search Console) — memakai istilah “invalid certificate” (terjemahan) “sertifikat tidak valid”, “affects an entire site,” (terjemahan) “memengaruhi seluruh situs,” dan “stop crawling your HTTPS pages” (terjemahan) “berhenti merayapi halaman HTTPS Anda”.
• Masalah sertifikat SSL (Bantuan Search Console) — kesalahan ketidakcocokan nama host serta sertifikat tidak tepercaya atau ditandatangani sendiri.
• Mengaktifkan HTTPS pada server (web.dev) — CA, CSR, cakupan wildcard, dan pemetaan banyak nama.
• Menggabungkan URL duplikat (Google Search Central) — menjelaskan preferensi kanonis HTTPS “except when there are issues or conflicting signals” (terjemahan) “kecuali jika ada masalah atau sinyal yang bertentangan”, menyebut sertifikat buruk sebagai salah satu masalah, dan menegaskan bahwa HSTS tidak dapat mengalahkan preferensi tersebut.

Otoritas sertifikat dan standar

• Sertifikat DV, OV, IV, dan EV (SSL.com) — definisi setiap tingkat validasi.
• Let’s Encrypt — otoritas sertifikat DV gratis dan otomatis.
• Protokol ACME / Certbot — klien otomatisasi yang digunakan banyak konfigurasi mandiri.
• Masa Berlaku Sertifikat yang Lebih Pendek dan Batas Laju (Let’s Encrypt) — rencana pemendekan masa berlaku Let’s Encrypt saat ini.
• CA/Browser Forum — badan yang menetapkan batas maksimum masa berlaku sertifikat melalui Ballot SC-081v3.

Kutipan dari sumber

Pernyataan langsung dari sumber. Setiap tautan pendukung mengarah ke bagian yang dikutip.

Google — kesalahan sertifikat di Search Console

• “The HTTPS URL has an invalid SSL certificate. Typically this affects an entire site.” (terjemahan) “URL HTTPS memiliki sertifikat SSL yang tidak valid. Biasanya masalah ini memengaruhi seluruh situs.” — Bantuan Search Console Google, laporan HTTPS. Buka kutipan
• “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (terjemahan) “Jika situs memiliki banyak masalah HTTPS, Google dapat berhenti merayapi halaman HTTPS Anda.” — Bantuan Search Console Google, laporan HTTPS. Ini baris terpenting dalam topik ini: sertifikat rusak memiliki konsekuensi nyata bagi perayapan. Buka kutipan
• “The host name of your site does not match any of the Subject Names in your SSL certificate.” (terjemahan) “Nama host situs Anda tidak cocok dengan satu pun Subject Name dalam sertifikat SSL.” — Bantuan Search Console Google, masalah sertifikat SSL. Buka kutipan
• “Your site uses an SSL certificate which is not recognized by major web browsers.” (terjemahan) “Situs Anda menggunakan sertifikat SSL yang tidak dikenali browser web utama.” — Bantuan Search Console Google, masalah sertifikat SSL. Buka kutipan

Google — kanonis preferensi dan buruk sertifikat

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (terjemahan) “Google lebih memilih halaman HTTPS daripada halaman HTTP yang setara sebagai kanonis, kecuali jika ada masalah atau sinyal yang bertentangan.” / “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.” (terjemahan) “Hindari sertifikat TLS/SSL buruk dan pengalihan HTTPS ke HTTP karena keduanya membuat Google sangat memilih HTTP. HSTS tidak dapat mengalahkan preferensi kuat ini.” — Google penelusuran Central, Consolidating duplicate URLs. dibaca source

Google / web.dev — cakupan dan biaya sertifikat

• “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.” (terjemahan) “Pada sertifikat wildcard, wildcard hanya berlaku pada satu label DNS; cakupannya tidak menjangkau subdomain tingkat kedua.” — web.dev, Enable HTTPS pada server Anda. berpindah untuk quote
• “Different CAs charge different amounts of money for the service of vouching for your public key.” (terjemahan) “CA yang berbeda mengenakan biaya berbeda untuk layanan penjaminan kunci publik Anda.” — web.dev, Enable HTTPS pada server Anda. berpindah untuk quote

SSL.com — tingkat validasi

• “Domain Validation (DV) is the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (terjemahan) “Validasi Domain (DV) adalah tingkat validasi terendah dan memverifikasi bahwa pemohon sertifikat mengendalikan domain yang dilindungi.” berpindah untuk 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.” (terjemahan) “Seperti OV, Extended Validation (EV) memverifikasi identitas organisasi. Namun, EV mewakili standar kepercayaan lebih tinggi dan memerlukan pemeriksaan validasi lebih ketat.” berpindah untuk quote

John Mueller, Google penelusuran Relations (social-media reply relayed oleh mesin pencari Journal, dapat 2023)

• John Mueller menjawab @EncryptedFence bahwa sertifikat SSL tidak “meningkatkan SEO situs web Anda”. Quoted dari Mueller’s Mastodon reply via mesin pencari Journal — INDUSTRY-tier corroboration dari OFFICIAL scheme-based rumusan, bukan sebuah Google-owned halaman. Confirm terhadap original post jika quoting directly. dibaca coverage

Glenn Gabe, GSQi (expired-sertifikat case study, Sept 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.” (terjemahan) “Ada kalanya masalah yang tampak seperti masalah SEO sebenarnya bukan masalah SEO. Gangguan teknis yang muncul bersamaan dengan pembaruan algoritme dapat membingungkan.” Industry case study; 2013 browser-UI detail adalah dated tetapi diagnostic lesson adalah evergreen. dibaca case study

Sertifikat mana yang sebaiknya dipilih?

Ikuti alurnya dari atas ke bawah. Dua pertanyaan pertama menentukan hal yang penting; Selebihnya adalah perhitungan cakupan.

1. Apakah Anda memerlukan sertifikat tertentu agar situs mendapat peringkat di Google? Hal itu sudah dipenuhi dengan memakai https://: sertifikat valid apa pun memberikan sinyal peringkat yang sama. Karena itu, pertanyaan ini tidak pernah mengarah pada sertifikat yang lebih mahal. Lanjutkan.

2. Apakah Anda perlu menampilkan identitas organisasi terverifikasi kepada manusia, dan apakah hal tersebut diwajibkan oleh hukum atau kepatuhan?

• Tidak (sebagian besar kasus—blog, situs konten, dan mayoritas ecommerce) → sertifikat DV. Pilih Let’s Encrypt gratis, aktifkan otomatisasi, selesai.
• Ya (perbankan atau konteks perusahaan/industri teregulasi yang mewajibkan OV/EV) → OV, atau EV jika persyaratan tertentu menyebutkannya. EV tidak lagi menampilkan indikator khusus di browser utama sejak Chrome 77 dan Firefox 70; Anda membayar catatan pemeriksaan, bukan lencana yang terlihat.

3. Berapa banyak nama host yang diamankan? (cakupan yang tidak bergantung pada langkah 2)

• Satu nama host (hanya www.example.com) → sertifikat domain tunggal.
• Banyak subdomain tingkat pertama di bawah satu domain (shop., blog., app. example.com) → wildcard (*.example.com). Pastikan tidak ada nama host tingkat kedua seperti api.staging.example.com, karena wildcard tersebut tidak akan mencakupnya.
• Daftar khusus yang mencakup beberapa domain (example.com + example.net + brand.io) → sertifikat SAN / multidomain (UCC) yang mencantumkan setiap nama.
• subdomain tingkat kedua yang tidak dapat dicakup wildcard → gunakan wildcard kedua pada tingkat tersebut, atau tambahkan semua nama secara eksplisit ke sertifikat SAN.

4. Algoritme kunci mana yang digunakan, dan berapa banyak edge atau origin yang menyajikan nama host tersebut? RSA dibanding ECDSA adalah pertukaran keamanan dan kompatibilitas klien, bukan tuas peringkat. Beberapa klien lama atau tertanam tidak mendukung ECDSA, jadi periksa kemampuan CDN atau penyeimbang beban sebelum memilih. Jika nama host dilayani lebih dari satu edge, wilayah, atau origin—misalnya CDN, hosting bersama berbasis SNI, atau beberapa penyeimbang beban—uji setiap jalur secara terpisah. Hasil bersih pada satu jalur tidak memastikan jalur lain tercakup.

5. Apakah pembaruan akan otomatis?

• Ya → bagus; masa berlaku singkat tidak bermasalah dan akan terus memendek hingga maksimum 47 hari pada 2029.
• Tidak → benahi terlebih dahulu. Pembaruan manual sudah rapuh dan tidak dapat dipertahankan ketika masa berlaku menyusut. Gunakan ACME/Certbot atau sertifikat yang dikelola host/CDN.

Sedang men-debug kesalahan sertifikat aktif? Kenali gejalanya:

• Berfungsi di Chrome desktop, tetapi gagal di perangkat seluler atau alat → hampir selalu intermediate yang hilang dari rantai. Uji dengan SSL Labs atau openssl s_client -showcerts dan pasang rantai lengkap.
• Seluruh situs tiba-tiba menampilkan peringatan atau turun → periksa kedaluwarsa terlebih dahulu karena masalah ini merusak seluruh situs sekaligus.
• Satu subdomain menampilkan peringatan sementara yang lain normal → sertifikat campuran / kesenjangan cakupan; host tidak dicakup sertifikat atau melampaui batas satu label wildcard.
• Peringatan nama situs salah → ketidakcocokan nama host; Subject Names sertifikat tidak mencantumkan host yang disajikan.

Daftar periksa kesehatan sertifikat

Lakukan satu putaran pemeriksaan untuk memastikan sertifikat valid, tercakup, dan tidak kedaluwarsa diam-diam:

• Setiap nama host publik (apex, www, dan setiap subdomain) disajikan melalui sertifikat yang valid dan tepercaya — bukan hanya halaman utama.
• rantai lengkap sudah terpasang (leaf dan intermediate) — diverifikasi dengan SSL Labs atau openssl s_client -showcerts, bukan pemeriksaan singkat di Chrome desktop.
• Pembaruan sudah otomatis (ACME/Certbot, host/CDN-managed, atau PaaS) — tidak ada pembaruan yang bergantung pada pengingat manusia.
• Pemantau sertifikat/uptime memberi peringatan menjelang kedaluwarsa dan saat handshake gagal sebagai perlindungan cadangan.
• Tidak ada ketidakcocokan nama host; setiap host yang disajikan tercantum dalam Subject Alternative Names atau tercakup wildcard yang sesuai.
• Wildcards diperiksa untuk batas satu label — tidak ada subdomain tingkat kedua (a.b.example.com) diam-diam berada di luar *.example.com.
• tidak ada sertifikat yang ditandatangani sendiri pada host produksi publik mana pun (baik untuk dev/staging saja).
• Anda memilih kedalaman validasi berdasarkan kebutuhan manusia atau kepatuhan, bukan harapan SEO. DV cukup untuk peringkat; OV/EV membeli verifikasi identitas.
• Laporan HTTPS Search Console Google ditinjau untuk penanda *“invalid certificate” (terjemahan) “sertifikat tidak valid” dan *“HTTPS not evaluated” (terjemahan) “HTTPS belum dievaluasi”.
• Subdomain pada platform atau CDN berbeda diinventarisasi; pembaruan masing-masing dipantau.

Model mental

1. Dua sumbu, bukan satu. Sertifikat memiliki kedalaman validasi (DV/OV/IV/EV) dan cakupan (domain tunggal, wildcard, atau SAN). Keduanya independen: Anda dapat memakai wildcard DV atau sertifikat domain tunggal OV. Putuskan secara terpisah dan ingat bahwa Google tidak melihat keduanya.

2. Sinyal peringkat tidak membedakan tingkat sertifikat. Memakai https:// dengan sertifikat valid dan berfungsi memperoleh sinyal kecil yang sama tanpa memandang penerbit, harga, atau tingkat validasi. Karena itu, pertanyaan “sertifikat mana yang membantu SEO” merupakan kesalahan kategori; tidak ada tingkat yang memberi manfaat peringkat lebih besar. Namun, ini tidak berarti validitas sertifikat tidak terlihat—lihat poin 3.

3. Masalah sertifikat adalah keadaan darurat bagi preferensi kanonis, akses perayapan, dan UX—bukan masalah tingkat peringkat. Saat sertifikat rusak, pengguna pergi karena peringatan browser; preferensi kanonis Google dari HTTP ke HTTPS dapat berbalik ke HTTP dan HSTS tidak dapat mengalahkannya; banyak masalah HTTPS juga dapat membuat Google berhenti merayapi halaman HTTPS Anda. Dampak ini tidak bekerja melalui sinyal peringkat dasar, tetapi “skemanya tidak berubah” bukan alasan untuk menganggap sertifikat rusak aman. Perbaiki sertifikat; tidak ada faktor peringkat lain yang perlu dikejar.

4. Otomatisasi adalah kunci ketika masa berlaku menyusut. Industri bergerak menuju sertifikat 47 hari. Setelah pembaruan otomatis, masa berlaku singkat justru lebih aman: jangka paparan lebih pendek dan tidak ada orang yang harus mengingat jadwal. Risiko sebenarnya adalah tidak melakukan otomatisasi.

5. Gembok di halaman utama hanya membuktikan satu nama host. Cakupan, jadwal kedaluwarsa, dan platform berbeda antar-subdomain. Inventarisasikan dan pantau setiap host; jangan menyimpulkan semuanya dari satu gembok hijau.

6. Uji rantai, bukan laptop Anda. Chrome desktop menyimpan intermediate dalam cache sehingga hasilnya dapat menyesatkan. Validasi dengan pembangun rantai yang bersih seperti SSL Labs atau openssl s_client agar intermediate yang hilang tidak tersembunyi.

Lembar ringkas sertifikat SSL/TLS

Kedalaman validasi (apa yang diverifikasi CA)

Cakupan (nama host yang diamankan)

Perubahan masa berlaku maksimum (CA/Browser Forum)

Ketika sertifikat rusak

Fakta singkat

• DV gratis dari Let’s Encrypt memberi enkripsi dan perlakuan peringkat yang sama seperti sertifikat berbayar.
• Sinyal Google membaca skema, bukan sertifikat.
• Masalah HTTPS yang banyak dapat membuat Google berhenti merayapi halaman HTTPS Anda.
• Otomatiskan pembaruan melalui ACME/Certbot atau sertifikat yang dikelola host/CDN.

Memeriksa sertifikat dan rantai lengkapnya

Perintah paling berguna untuk men-debug sertifikat. -showcerts menampilkan setiap sertifikat yang benar-benar dikirim server, sehingga menjadi cara tercepat menemukan intermediate yang hilang.

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"

Flag -servername menetapkan SNI — penting pada hosting bersama atau CDN di mana satu IP menyajikan beberapa sertifikat, karena itu Anda menguji sertifikat yang tepat.

Windows (PowerShell) — periksa kedaluwarsa dan nama yang dicakup

# 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—menandai URL sub-sumber daya yang tidak aman

Tempelkan ke Console pada halaman mana pun untuk mencantumkan http:// sub-sumber daya yang masih dirujuk di HTML (sebuah pemeriksaan singkat konten campuran saat Anda mengaudit sertifikat):

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

Untuk memeriksa cakupan setiap nama host, validator eksternal seperti SSL Labs lebih baik daripada skrip per host. Namun, potongan ini berguna untuk pemeriksaan cepat pada halaman di depan Anda.

Antipola sertifikat

Pola kegagalan yang terus saya temui:

*Membeli EV/OV “for SEO” (terjemahan) “untuk SEO”. Google tidak melihat kedalaman validasi. Membayar lebih untuk manfaat peringkat yang tidak ada hanyalah pemborosan. Pilih tingkat validasi lebih tinggi hanya untuk kebutuhan nyata akan kepercayaan manusia atau kepatuhan.

Memverifikasi sertifikat hanya di Chrome desktop. Chrome menyimpan intermediate dalam cache dan dapat menampilkan gembok hijau pada rantai rusak yang gagal di tempat lain. Selalu validasi dengan pembangun rantai yang bersih seperti SSL Labs atau openssl s_client -showcerts).

Pengingat pembaruan manual. Entri kalender bukan sistem pembaruan. Kegagalan saat seseorang sedang berlibur dapat merusak seluruh situs sekaligus, dan risikonya meningkat ketika masa berlaku menyusut menuju 47 hari. Otomatiskan.

Menganggap wildcard mencakup semua yang ada di bawah domain. *.example.com berhenti pada satu label DNS. staging.api.example.com tidak tercakup dan akan memicu kesalahan yang tidak diketahui hingga pengguna atau Googlebot mengaksesnya.

Hanya memeriksa halaman utama. Subdomain pada platform atau CDN lain memiliki sertifikat dan jadwal sendiri. Gembok valid pada domain apex tidak memberi informasi tentang blog. atau subdomain pemasaran yang kedaluwarsa diam-diam.

Sertifikat yang ditandatangani sendiri pada produksi publik. Sertifikat ini memicu layar peringatan browser dan dinyatakan gagal oleh sebagian besar validator dan perayap. Gunakan hanya untuk lingkungan internal, pengembangan, atau staging—bukan situs publik.

Menganggap sertifikat rusak sebagai masalah tingkat peringkat atau tidak berbahaya. Ini bukan tuas tingkat peringkat, tetapi juga tidak aman: sertifikat rusak dapat membalik preferensi kanonis Google dari HTTPS ke HTTP, membatasi akses perayapan, dan menurunkan konversi karena pengguna pergi. Perbaiki sertifikat; jangan mengejar faktor peringkat dan jangan menganggap tidak terjadi apa-apa hanya karena “skemanya tidak berubah”.

SOP pembaruan dan penerapan sertifikat

1. Pelihara inventaris nama host. Catat apex, www, subdomain, subdomain yang lebih dalam, endpoint CDN atau penyeimbang beban, penerbit sertifikat, jenis cakupan, penanggung jawab pembaruan, dan jalur otomatisasi.
2. Pantau kedaluwarsa secara independen dari penerbit. Beri peringatan cukup awal untuk menyelidiki kegagalan otomatisasi dan sesuaikan jadwal dengan masa berlaku sertifikat yang sebenarnya; pengingat kalender saja bukan sistem pembaruan.
3. Uji pembaruan otomatis. Pastikan alur ACME, host, atau CDN dapat meminta, memvalidasi, memasang, mengaktifkan, dan memuat ulang setiap proses penyaji yang masih menyimpan sertifikat lama di memori, tanpa langkah manual.
4. Validasi kandidat. Periksa nama host/SAN yang diminta, kedalaman wildcard, penerbit, rentang masa berlaku, dan rantai intermediate lengkap sebelum digunakan di produksi.
5. Terapkan di setiap lapisan penyaji. Perbarui setiap edge, proxy, penyeimbang beban, dan origin yang mengakhiri TLS; jangan menganggap satu endpoint yang berhasil mencakup semua wilayah atau nama host.
6. Uji dari luar. Gunakan validator rantai yang bersih dan openssl s_client dengan SNI terhadap host perwakilan. Sertakan klien yang tidak berbagi cache intermediate browser.
7. Tutup siklusnya. Pastikan pemantauan melihat tanggal kedaluwarsa baru, catat penerapan, dan selidiki endpoint yang masih menyajikan sertifikat sebelumnya.

Perlakukan kegagalan pembaruan sebagai insiden ketersediaan. Pada host HSTS, pengunjung tidak dapat melewati kesalahan sertifikat dengan aman.

Perangkat pemeriksaan sertifikat

• SSL Labs Server Test — validasi eksternal untuk sertifikat yang disajikan, rantai, cakupan nama host, dukungan protokol, dan perbedaan endpoint.
• openssl s_client — periksa persis apa yang disajikan nama host dengan SNI dan tampilkan rantai lengkap; pasangkan dengan openssl x509 untuk tanggal dan Subject Alternative Names.
• Penampil sertifikat browser dan DevTools — reproduksi kesalahan nama host, kepercayaan, dan kedaluwarsa yang dialami pengguna pada klien terdampak.
• Pemantauan sertifikat independen — beri peringatan untuk setiap nama host yang diinventarisasi, meski penerbit atau CDN mengklaim pembaruan sudah otomatis.
• Laporan HTTPS Search Console Google — pantau masalah penyajian HTTPS yang lebih luas; gunakan alat sertifikat untuk diagnosis tingkat endpoint.

Uji berdasarkan nama host, bukan hanya IP atau halaman utama. Infrastruktur bersama dapat menyajikan sertifikat berbeda bergantung pada SNI, wilayah, atau node edge.

Pengujian rilis sertifikat

Uji 1: cakupan nama host dan rantai

• Tujuan: Buktikan bahwa setiap nama host publik menerima sertifikat tepercaya yang benar-benar mencantumkan nama tersebut.
• metode: Jalankan SSL Labs dan openssl s_client -servername terhadap domain apex, www, setiap kelas subdomain, dan host lebih dalam yang tidak tercakup wildcard satu label.
• Hasil yang diharapkan: Nama host cocok dengan SAN, rantai lengkap, dan klien bersih dapat memvalidasi tanpa intermediate dari cache.
• Pemicu kegagalan: Ketidakcocokan nama, leaf yang ditandatangani sendiri, intermediate hilang, atau sertifikat berbeda pada satu endpoint.
• Tindakan berikutnya: Perbaiki cakupan sertifikat atau rantai yang disajikan, terapkan ulang, dan uji kembali setiap endpoint terdampak.

Uji 2: simulasi otomatisasi pembaruan

• Tujuan: Pastikan pembaruan merupakan proses operasional, bukan sekadar asumsi.
• metode: Uji alur pembaruan pada staging atau melalui simulasi yang didukung, lalu verifikasi alur dapat memasang dan mengaktifkan pengganti pada setiap lapisan yang mengakhiri TLS.
• Hasil yang diharapkan: Validasi, penerbitan, penerapan, dan pemantauan selesai tanpa langkah penyelamatan manual.
• pemicu kegagalan: Validasi domain gagal, kesalahan izin, node edge usang, atau pemantauan terus melaporkan sertifikat sebelumnya.
• Tindakan berikutnya: Perbaiki otomatisasi dan ulangi sebelum jendela pembaruan produksi menjadi mendesak.

Uji 3: pemeriksaan klien setelah penerapan

• Tujuan: Temukan perbedaan endpoint dan klien yang tersembunyi saat hanya memakai satu browser.
• Metode: Uji beberapa jaringan dan klien bersih, bandingkan nomor seri serta tanggal kedaluwarsa yang disajikan, lalu periksa laporan HTTPS Search Console untuk dampak lebih luas.
• Hasil yang diharapkan: Semua endpoint yang diuji menyajikan sertifikat yang dimaksud dan halaman tetap dapat dirayapi melalui HTTPS.
• Pemicu kegagalan: Ketidakkonsistenan regional, peringatan sertifikat, regresi laporan HTTPS, atau kegagalan perayapan.
• Tindakan berikutnya: Terapkan sertifikat ke endpoint yang tertinggal atau pulihkan sertifikat valid terakhir sambil memperbaiki jalur penerapan.

Uji pemahaman Anda: sertifikat SSL/TLS

Lima pertanyaan singkat tentang hubungan sertifikat dan SEO. Pilih satu jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Sumber daya yang layak dibaca

Presentasi saya

• Lebih Baik Aman daripada Menyesal dengan HTTPS — SMX East 2016 (SlideShare) — pembahasan mendalam tentang TLS, kegagalan umum sertifikat dan implementasi, serta jebakan migrasi. Di sini saya juga menandai risiko deindeksasi TLS SNI pada Bing dan Baidu; pada tahun yang sama, Search Engine Land melaporkan penurunan perayapan dan peringkat Bing akibat migrasi HTTPS berbasis SNI. Catatan: ini adalah pemahaman saya tentang sistem tersebut, dan statistik adopsi dalam presentasi berasal dari 2016—jangan kutip angkanya sebagai data terkini.

Tulisan terkait saya

• Panduan pemula untuk SEO teknis — posisi sertifikat dan HTTPS dalam gambaran teknis yang lebih luas.

Sumber resmi dan berwenang

• Laporan HTTPS dan masalah sertifikat SSL Google — daftar definitif kesalahan sertifikat yang ditampilkan Search Console beserta artinya.
• Mengaktifkan HTTPS di server (web.dev) — CA, CSR, serta cakupan wildcard dan banyak nama, langsung dari Google.
• Menggabungkan URL duplikat Google — panduan preferensi kanonis yang menyebut sertifikat buruk sebagai penyebab Google memilih HTTP daripada HTTPS.
• SSL Labs Server Test — menilai konfigurasi TLS dan, yang terpenting, menandai rantai sertifikat tidak lengkap.

Sumber industri

• Sertifikat DV, OV, IV, dan EV (SSL.com) — definisi jelas dari CA untuk setiap tingkat validasi.
• A Wolf in Panda’s Clothing—How an Expired SSL Certificate Can Impact Organic Search Traffic (Glenn Gabe, GSQi) — studi kasus sertifikat kedaluwarsa yang disangka sebagai penalti Panda.
• Google: Sertifikat SSL Tidak Meningkatkan SEO (Search Engine Journal) — jawaban tegas John Mueller bahwa sertifikat tidak meningkatkan SEO.
• Masa Berlaku Sertifikat yang Lebih Pendek dan Batas Laju (Let’s Encrypt) — pembaruan Februari 2026 tentang penurunan masa berlaku bawaan dari 90 menjadi 64 lalu 45 hari.
• Masa Berlaku Sertifikat TLS Akan Resmi Berkurang Menjadi 47 Hari (DigiCert) — jadwal bertahap Ballot SC-081v3 CA/Browser Forum.
• Kesalahan SSL yang Memengaruhi SEO (SISTRIX) — ringkasan praktis tentang nama host, kedaluwarsa, protokol, dan konten campuran.
• Certbot (EFF) — klien ACME standar untuk mengotomatiskan penerbitan dan pembaruan sertifikat.

Statistik yang layak dikutip

• Masa berlaku maksimum sertifikat turun menjadi 47 hari pada 2029. Ballot SC-081v3 CA/Browser Forum, yang pemungutan suaranya berakhir 11 April 2025, menurunkan batas dari 398 hari → 200 (Maret 2026) → 100 (Maret 2027) → 47 (Maret 2029). Angka ini membuat pembaruan otomatis wajib. Source
• Let’s Encrypt menurunkan masa berlaku bawaan dari 90 menjadi 64 lalu 45 hari. Menurut pembaruan Februari 2026, CA gratis tersebut menjalankan dua tahap selama dua tahun berikutnya; tanggal pasti setiap tahap tidak disebutkan dalam pengumuman. Source
• *Sertifikat rusak “typically affects an entire site” (terjemahan) “biasanya memengaruhi seluruh situs”. Itulah rumusan Google tentang luas dampaknya: kegagalan kedaluwarsa dan rantai jarang merusak satu halaman; biasanya semuanya rusak sekaligus. Source
• Masalah HTTPS yang banyak dapat membuat Google berhenti merayapi halaman HTTPS Anda. Ini konsekuensi akses perayapan yang terpisah dari sinyal peringkat dasar dan juga terpisah dari pembalikan preferensi kanonis ke HTTP yang dapat dipicu sertifikat buruk. Source
• Sertifikat buruk dapat mengalahkan preferensi kanonis HTTPS Google dan HSTS tidak dapat mencegahnya. Panduan Google menyebut sertifikat TLS/SSL buruk sebagai penyebab Google memilih versi HTTP “dengan sangat kuat”. Source

Log perubahan