Certificati SSL/TLS

TL;DR — Un certificato SSL/TLS è il file sul server che rende possibili il lucchetto e https://. Esistono versioni economiche e costose, ma per la SEO sono equivalenti: Google controlla che l’URL inizi con https://, non quale certificato hai acquistato. Un certificato gratuito di Let’s Encrypt si posiziona esattamente come uno costoso. Il vero danno arriva da un certificato guasto: se scade o è configurato male, i browser mostrano un avviso allarmante e gli utenti abbandonano il sito.

Che cos’è davvero un certificato SSL

Il protocollo HTTPS moderno usa certificati TLS per autenticare un dominio e stabilire connessioni cifrate. 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 consiglia HTTPS e lo usa come uno dei segnali di canonicalizzazione, ma il prezzo o il livello di convalida del certificato non rappresentano un vantaggio di ranking documentato. 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

Tocca per espandere

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.

Quando apri un sito sicuro, il browser e il server eseguono un rapido handshake per impostare la cifratura. Il certificato è ciò che il server presenta durante questo handshake. Svolge due funzioni: attesta, con diversi gradi di certezza, chi possiede il sito e contiene la chiave usata per cifrare la connessione.

Si parla ancora di “certificato SSL”, ma il protocollo moderno è in realtà TLS: il nome “SSL” è semplicemente rimasto nell’uso comune. L’hub HTTPS spiega questa particolarità terminologica e affronta la domanda “HTTPS aiuta il ranking?”; qui presumo che tu sappia già che HTTPS è al massimo un piccolo fattore di spareggio e approfondisco il certificato stesso.

Un certificato più costoso aiuta la SEO?

No. È il mito più comune. Google non documenta differenze di ranking tra tipi di certificato, autorità emittenti o prezzi: finché HTTPS è valido e funziona, non distingue un certificato da 300 USD all’anno da uno gratuito. John Mueller di Google lo ha detto senza mezzi termini a chi sosteneva che SSL migliorasse la SEO: “this does not ‘Boost your website’s SEO’, sorry.” (traduzione) «Questo non migliora la SEO del sito, mi dispiace».

Un certificato gratuito di Let’s Encrypt si posiziona quindi esattamente come l’opzione più costosa proposta da un fornitore. Il denaro in più compra segnali di fiducia rivolti alle persone, non un vantaggio nel ranking.

In cosa differiscono i certificati

Variano due aspetti, che conviene tenere distinti:

• Quanto verificano. Un certificato di base dimostra soltanto il controllo del dominio; quelli più costosi verificano l’identità legale dell’azienda. Per Google non fa differenza.
• Che cosa coprono. Un certificato può coprire un solo nome host, un insieme di sottodomini tramite wildcard oppure un elenco specifico di nomi tramite SAN.

La parte che conta davvero per la SEO

Un certificato funzionante è invisibile. Uno guasto crea problemi:

• I certificati scaduti generano un avviso a schermo intero. Gli utenti abbandonano il sito prima di vedere la pagina: può sembrare un crollo del ranking, ma sono persone fermate all’ingresso.
• Un certificato gravemente danneggiato può far preferire a Google la versione HTTP della pagina invece di quella HTTPS. Google normalmente preferisce HTTPS, ma le sue indicazioni dicono che un certificato non valido prevale su questa preferenza, e neppure HSTS può impedirlo.
• Se i problemi sono numerosi, Google può perfino interrompere del tutto la scansione delle pagine HTTPS, che col tempo possono uscire dalla ricerca.

La regola pratica è semplice: scegli il certificato economico, anche gratuito, e non lasciarlo mai scadere. Configura il rinnovo automatico.

Vuoi approfondire DV, OV ed EV, wildcard e SAN, catene di certificazione, la riduzione della durata e ciò che accade ai crawler quando un certificato si rompe? Passa alla scheda Avanzato.

TL;DR — Google non documenta differenze di ranking tra i livelli di convalida DV, OV ed EV né tra emissione gratuita e a pagamento: un certificato più costoso compra fiducia umana e organizzativa, non posizionamento. Profondità della convalida e ambito di copertura sono decisioni indipendenti e nessuna è un fattore di ranking documentato. Let’s Encrypt e l’emissione automatica gratuita tramite ACME non sono un compromesso. I certificati incidono sulla SEO quando falliscono: un certificato scaduto, autofirmato, non corrispondente al nome host o con catena incompleta può rompere la pagina, spostare la preferenza canonica di Google da HTTPS a HTTP e indurre Google a interrompere la scansione delle pagine HTTPS. Con la validità massima diretta verso 47 giorni nel 2029, il rinnovo automatico è obbligatorio.

L’hub HTTPS spiega che HTTPS è al massimo un segnale di spareggio, che Google guarda lo schema e non il certificato e che un DV gratuito riceve lo stesso trattamento di un OV o EV costoso. Questo articolo prosegue da lì e scende di un livello: che cosa significano DV, OV ed EV, come funziona la copertura, perché i certificati gratuiti e automatici vanno bene, come si rompono le catene senza che i test abituali se ne accorgano e che cosa succede davvero alla scansione quando un certificato non è valido.

”Certificato SSL” è in realtà un certificato TLS

SSL è una terminologia obsoleta per le implementazioni TLS moderne. 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 Le indicazioni per la ricerca si concentrano su un HTTPS valido e accessibile, non sul livello commerciale del certificato. 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

Una breve nota sul nome: SSL, Secure Sockets Layer, è il protocollo deprecato; tutto ciò che viene emesso oggi usa TLS, Transport Layer Security. “Certificato SSL” sopravvive come espressione colloquiale e persino Search Console usa ancora la formula “SSL certificate problems”. Nel resto dell’articolo userò semplicemente “certificato”.

Profondità della convalida: DV vs OV vs IV vs EV

I certificati vengono emessi con diversi livelli di convalida, che descrivono quanto l’autorità di certificazione, o CA, ha verificato prima di garantire per il richiedente. Secondo la classificazione di SSL.com:

• DV (Domain Validation) è “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (traduzione) «il livello minimo di convalida e verifica che chi richiede il certificato controlli il dominio protetto». È rapido, economico o gratuito e in genere automatizzato tramite un record DNS o un file recuperabile dalla 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.” (traduzione) «verifica l’identità e la sede operativa dell’organizzazione indicata nel certificato».
• IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (traduzione) «verifica l’identità della persona indicata come soggetto del certificato».
• 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.” (traduzione) «come OV verifica l’identità di un’organizzazione, ma richiede controlli più rigorosi e rappresenta uno standard di fiducia superiore».

Il punto rilevante per la SEO è questo: Google non documenta differenze di ranking tra i livelli di convalida. Il segnale di base legge lo schema dell’URL; Illyes lo ha descritto come l’osservazione dei primi cinque caratteri davanti all’URL. Finché HTTPS è valido e funziona, DV, OV ed EV ricevono lo stesso trattamento. La differenza di prezzo riflette il lavoro di verifica e la responsabilità della CA, non una preferenza di Google. web.dev lo riassume così: “different CAs charge different amounts of money for the service of vouching for your public key.” (traduzione) «Le diverse CA applicano prezzi differenti per il servizio con cui garantiscono la chiave pubblica». Il sovrapprezzo compra fiducia umana e organizzativa.

Anche l’ultimo argomento rivolto agli utenti a favore di EV è quasi scomparso: il trattamento speciale nella barra degli indirizzi non esiste più. Chrome ha rimosso l’interfaccia verde con il nome dell’azienda da Chrome 77 nel 2019 e Firefox 70 lo ha seguito nello stesso anno. Il messaggio “i clienti vedono il nome dell’azienda nella barra” non giustifica più il prezzo nei browser principali; verifica comunque il comportamento corrente prima di una decisione d’acquisto.

Ambito di copertura: dominio singolo vs wildcard vs SAN

La profondità della convalida è un asse. L’ambito di copertura, cioè quali nomi host protegge il certificato, è un asse del tutto separato. In genere ogni ambito può essere emesso come DV o OV; le wildcard di solito non sono offerte come EV secondo le regole CA/B:

• Dominio singolo: copre esattamente un nome host, per esempio www.example.com.
• Wildcard: copre uno schema di nomi host profondo una sola etichetta DNS. web.dev precisa il limite: “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.” (traduzione) «La wildcard si applica a una sola etichetta DNS». La wildcard non copre i sottodomini di secondo livello.
• SAN / multidominio (UCC): elenca nomi host specifici nei Subject Alternative Names. web.dev spiega che esistono “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).” (traduzione) «È possibile associare la chiave a più nomi DNS distinti». Un SAN può comprendere domini diversi ed è utile per un gruppo limitato di proprietà correlate.

Il rischio SEO pratico si nasconde nel limite di una sola etichetta. Se usi *.example.com e qualcuno crea staging.blog.example.com, quel nome è profondo due etichette, quindi resta fuori dalla wildcard e può mostrare un errore o un certificato non corrispondente. Google e gli utenti vedranno un certificato rotto su una pagina che pensavi fosse coperta.

Un’altra trappola: un test superato sul dominio principale non dimostra la copertura ovunque. Il client deve richiedere il nome host esatto e ricevere un certificato che lo includa, tramite SNI. CDN, bilanciatori e hosting condiviso possono servire certificati diversi da edge, regioni o origini diverse dietro lo stesso dominio. Verifica ogni nome host pubblico in modo indipendente. Un test su example.com non prova la copertura di www..

Let’s Encrypt ed emissione automatica gratuita

Let’s Encrypt e altre CA gratuite emettono certificati DV tramite il protocollo ACME, un ciclo automatico di richiesta, verifica ed emissione eseguito da client come Certbot. Due aspetti vengono spesso fraintesi:

1. Gratuito non significa più debole. Un certificato Let’s Encrypt offre la stessa forza di cifratura TLS e lo stesso trattamento nel ranking di uno a pagamento. I compromessi reali sono la sola convalida DV e la breve durata.
2. La breve durata è un vantaggio quando il rinnovo è automatico. Riduce la finestra di esposizione in caso di compromissione della chiave e nessuno deve ricordarsi manualmente di rinnovare.

Quest’ultimo punto sta per riguardare tutti, non solo gli utenti di Let’s Encrypt.

Il cambiamento della durata dei certificati (2026–2029) — automatizza ora

Il settore sta riducendo la durata dei certificati secondo un calendario fisso. Il CA/Browser Forum ha approvato il Ballot SC-081v3, la cui votazione si è chiusa l’11 aprile 2025, riducendo gradualmente la validità massima TLS:

• 398 giorni oggi
• 200 giorni dal 15 marzo 2026
• 100 giorni dal 15 marzo 2027
• 47 giorni dal 15 marzo 2029

Let’s Encrypt segue anche un percorso proprio e più rapido. Nell’aggiornamento di febbraio 2026 prevede due fasi nei due anni successivi, “from 90 days to 64 days, and then 45 days” (traduzione) «da 90 a 64 giorni e poi a 45 giorni», spostando il rinnovo da circa il sessantesimo giorno di un certificato da 90 giorni a circa il trentesimo quando la durata sarà di 45 giorni. L’aggiornamento sostituisce un calendario precedente più specifico: le date esatte delle singole fasi non sono ancora fissate e vanno verificate nel changelog.

La conseguenza operativa è netta: se il rinnovo non è già automatico, sistemalo prima del 2027. Una cadenza manuale tollerabile a 398 giorni diventa quasi una garanzia di interruzione a 47–100 giorni. DigiCert osserva che la riconvalida manuale rimarrà tecnicamente possibile, ma “doing so would be a recipe for failure and outages.” (traduzione) «farlo sarebbe una ricetta per guasti e interruzioni». L’automazione diventa l’unica scelta ragionevole.

Catena dei certificati / errori dei certificati intermedi

È il problema meno spiegato e la documentazione di Google non ne descrive il meccanismo. Ecco come funziona.

Un browser considera attendibile solo un piccolo insieme di certificati root inclusi nel proprio archivio. Il certificato del server, detto leaf o entità finale, quasi mai è firmato direttamente da una root. La catena è: leaf → uno o più certificati intermedi → root attendibile. Il server deve inviare il leaf e gli intermedi, così il client può costruire il percorso fino a una root già fidata.

La configurazione errata classica invia solo il leaf e omette l’intermedio. È insidiosa perché Chrome desktop spesso continua a funzionare: conserva in cache gli intermedi incontrati su altri siti e colma la lacuna. Chi prova dal portatile vede un lucchetto verde, mentre browser mobili, client API/HTTP e altri strumenti senza quella cache falliscono completamente l’handshake. È il classico “sul mio computer funziona” applicato a TLS.

Per rilevarlo non affidarti a un controllo occasionale in Chrome desktop. Usa uno strumento che costruisca la catena da zero:

• SSL Labs Server Test segnala in modo esplicito il download aggiuntivo e le catene incomplete.
• openssl s_client -connect example.com:443 -showcerts mostra ogni certificato realmente inviato dal server, così puoi confermare la presenza dell’intermedio.

Che cosa succede quando un certificato non è valido, è scaduto o è autofirmato

Questa è la sezione più importante e si divide nettamente in due, perché utenti e crawler vivono un certificato guasto in modo diverso.

Che cosa fanno utenti e browser. Un errore grave — certificato scaduto, autofirmato, nome host non corrispondente o CA non attendibile — genera un avviso interstiziale a schermo intero, non la discreta etichetta “Not Secure” di HTTP. Gli utenti abbandonano. Il caso meglio documentato è “A Wolf in Panda’s Clothing” di Glenn Gabe: il traffico di un ecommerce crollò in coincidenza con un aggiornamento Panda e il proprietario pensò a una penalizzazione. La causa reale era un certificato scaduto. Gabe scrisse: “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.” (traduzione) «Non tutti i problemi che sembrano SEO lo sono: gli inconvenienti tecnici coincidenti con gli aggiornamenti algoritmici possono confondere la diagnosi». Dopo il rinnovo, il traffico recuperò in circa otto giorni. I certificati autofirmati causano lo stesso interstiziale: vanno bene per ambienti interni, di sviluppo o staging, mai per la produzione pubblica.

Che cosa fa Google. È la sfumatura che quasi tutte le pagine concorrenti perdono. Le indicazioni sulla canonicalizzazione chiariscono che un certificato rotto non è invisibile alla Ricerca: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (traduzione) «Google preferisce le pagine HTTPS come canoniche salvo problemi o segnali contrastanti». Tra questi problemi nomina direttamente i certificati non validi: “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.” (traduzione) «I certificati non validi fanno preferire fortemente HTTP e HSTS non può prevalere». Un certificato davvero guasto può quindi far scegliere come canonica la versione HTTP, con un effetto reale su ciò che appare nei risultati.

Separatamente, la documentazione di Search Console descrive una conseguenza sulla scansione: un certificato non valido “typically affects an entire site,” (traduzione) «in genere interessa l’intero sito» e “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (traduzione) «se i problemi HTTPS sono numerosi, Google può smettere di eseguire la scansione delle pagine HTTPS». Gli URL rimasti vengono indicati come “HTTPS not evaluated” (traduzione) «HTTPS non valutato». Esistono dunque due meccanismi distinti: il ritorno della preferenza canonica a HTTP e una limitazione dell’accesso del crawler. Entrambi possono far uscire pagine dall’indice senza modificare il segnale di ranking di base di https://.

L’elenco di Google coincide con questa tassonomia: il nome host che non compare nei nomi del certificato — “The host name of your site does not match any of the Subject Names in your SSL certificate” (traduzione) «il nome host non corrisponde ai Subject Names del certificato» — e i certificati “not recognized by major web browsers” (traduzione) «non riconosciuti dai principali browser», perché autofirmati, emessi da una CA non attendibile, danneggiati, scaduti o non ancora validi.

Monitoraggio della scadenza e rinnovo automatico

La scadenza è l’errore più comune e più evitabile. Il raggio d’azione è asimmetrico: di solito rompe l’intero sito in una volta — Google scrive “Typically this affects an entire site” (traduzione) «In genere interessa l’intero sito» — non una pagina alla volta. La soluzione non è un promemoria sul calendario, ma una vera automazione:

• ACME / Certbot sul server o l’equivalente fornito dalla piattaforma.
• Certificati gestiti dall’host o dalla CDN, come Cloudflare e molte piattaforme PaaS, che emettono e rinnovano automaticamente.
• Un monitor esterno per certificati e uptime, che avvisi in prossimità della scadenza e in caso di handshake fallito anche se il rinnovo è automatico.

Con durate dirette verso 47 giorni, i promemoria manuali diventano matematicamente insostenibili: l’automazione è l’unico approccio scalabile.

Configurazioni con certificati diversi tra sottodomini

È diverso dal mixed content, cioè una pagina HTTPS che carica risorse HTTP. Una configurazione mixed-cert usa certificati differenti per parti diverse del sito, con scadenze o piattaforme separate. Il dominio principale può avere un certificato impeccabile mentre blog.example.com usa un’altra piattaforma, un sottodominio marketing resta fuori dal limite della wildcard oppure un hosting multitenant basato su SNI interrompe silenziosamente il rinnovo di un solo host.

La lezione è che un lucchetto valido sulla homepage non dice nulla sulla copertura altrove. Crea un inventario dei sottodomini, verifica che ogni host sia coperto e monitorato con un certificato proprio, una wildcard adeguata o un SAN e non usare un solo controllo SSL Labs per certificare l’intera proprietà.

Miti comuni

• “Un certificato a pagamento o EV si posiziona meglio di un DV gratuito.” No: il segnale dipende dallo schema e Google non vede la profondità di convalida.
• “Le wildcard coprono tutti i sottodomini, compresi quelli più profondi.” No: una sola etichetta DNS; *.example.com non copre foo.bar.example.com.
• “Un certificato scaduto danneggia direttamente il ranking.” Non tramite il segnale di base, ma può riportare la preferenza canonica a HTTP e, separatamente, indurre Google a interrompere la scansione delle pagine HTTPS.
• “I certificati Let’s Encrypt sono di qualità inferiore.” No: stessa cifratura e stesso trattamento; cambiano la convalida solo DV e la breve durata.
• “Se la homepage ha un lucchetto valido, tutto il sito è a posto.” No: i sottodomini possono usare certificati e scadenze separati.
• “Gli errori di catena sono rari o superati.” No: sono comuni quando lo stack invia solo il leaf e la cache di Chrome desktop li nasconde.

Questo è l’approfondimento sui certificati sotto l’hub HTTPS; per il piano di migrazione, il mixed content e HSTS, parti da lì.

Riepilogo AI

Una sintesi della versione avanzata:

• Google non documenta differenze di ranking tra i livelli dei certificati. Finché HTTPS è valido, DV, OV, IV ed EV ricevono lo stesso trattamento e un certificato Let’s Encrypt gratuito equivale a uno a pagamento. John Mueller: “this does not ‘Boost your website’s SEO’, sorry.” (traduzione) «non migliora la SEO del tuo sito, mi dispiace».
• Due assi indipendenti: profondità della convalida e ambito di copertura. Nessuno dei due è visibile a Google.
• Le wildcard coprono una sola etichetta DNS. *.example.com copre foo.example.com, ma non foo.bar.example.com. I SAN elencano nomi host espliciti e possono comprendere domini diversi.
• L’interfaccia speciale EV nei browser è scomparsa con Chrome 77 e Firefox 70 nel 2019, eliminando l’ultimo vantaggio visibile agli utenti.
• L’emissione automatica gratuita tramite ACME o Certbot non è un compromesso: stessa cifratura e stesso trattamento. Le durate brevi sono un vantaggio quando il rinnovo è automatico.
• Riduzione della durata: il Ballot SC-081v3 del CA/B Forum porta la validità massima da 398 a 200 giorni nel 2026, 100 nel 2027 e 47 nel 2029. Let’s Encrypt sta passando separatamente da 90 a 64 e poi a 45 giorni. Automatizza subito il rinnovo.
• Gli errori di catena possono restare nascosti: il server invia solo il leaf, Chrome desktop usa un intermedio in cache e funziona, mentre client mobili e API falliscono. Diagnostica con SSL Labs o openssl s_client -showcerts.
• Utenti e Google reagiscono diversamente: gli utenti vedono un avviso a schermo intero; Google può tornare a preferire HTTP come canonico e, separatamente, “stop crawling your HTTPS pages” (traduzione) «interrompere la scansione delle pagine HTTPS».
• La scadenza può rompere tutto il sito in una volta. Automatizza e monitora il rinnovo; un lucchetto valido sulla homepage non dimostra la copertura dei sottodomini.

Documentazione ufficiale

Documentazione primaria sui certificati proveniente dai motori di ricerca e dagli organismi di standardizzazione.

Google

• Rapporto HTTPS (guida di Search Console) — certificati non validi: “affects an entire site,” (traduzione) «interessa l’intero sito» e “stop crawling your HTTPS pages” (traduzione) «interrompere la scansione delle pagine HTTPS».
• Problemi del certificato SSL (guida di Search Console) — nomi host non corrispondenti e certificati autofirmati o non attendibili.
• Abilitare HTTPS sui server (web.dev) — CA, CSR, copertura wildcard e associazione di più nomi.
• Consolidare gli URL duplicati (Google Search Central) — preferenza canonica di HTTPS, eccezioni per i certificati non validi e limite di HSTS.

Autorità di certificazione e standard

• Certificati DV, OV, IV ed EV (SSL.com) — definizioni dei livelli di convalida.
• Let’s Encrypt — autorità DV gratuita e automatizzata.
• Protocollo ACME / Certbot — client di automazione usato da molte configurazioni self-hosted.
• Durate più brevi e limiti di frequenza (Let’s Encrypt) — piano corrente di riduzione della durata.
• CA/Browser Forum — organismo che stabilisce la validità massima, incluso il Ballot SC-081v3.

Citazioni dalla fonte

Dichiarazioni attribuite. Ogni collegamento porta direttamente al passaggio citato.

Google — errori dei certificati in Search Console

• “The HTTPS URL has an invalid SSL certificate. Typically this affects an entire site.” (traduzione) «L’URL HTTPS ha un certificato SSL non valido. In genere ciò interessa l’intero sito». — Guida di Google Search Console, rapporto HTTPS. Vai alla citazione
• “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (traduzione) «Se un sito presenta molti problemi HTTPS, Google può interrompere la scansione delle sue pagine HTTPS». — Guida di Google Search Console, rapporto HTTPS. È la frase più importante sul reale effetto di scansione. Vai alla citazione
• “The host name of your site does not match any of the Subject Names in your SSL certificate.” (traduzione) «Il nome host del sito non corrisponde a nessuno dei Subject Names del certificato SSL». — Guida di Google Search Console, problemi del certificato SSL. Vai alla citazione
• “Your site uses an SSL certificate which is not recognized by major web browsers.” (traduzione) «Il sito usa un certificato SSL non riconosciuto dai principali browser web». — Nella stessa guida di Google Search Console sui problemi del certificato SSL. Vai alla citazione

Google — preferenza canonica e certificati non validi

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (traduzione) «Google preferisce come canoniche le pagine HTTPS rispetto alle equivalenti HTTP, salvo problemi o segnali contrastanti». / “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.” (traduzione) «Evita certificati TLS/SSL non validi e reindirizzamenti da HTTPS a HTTP, perché inducono Google a preferire fortemente HTTP; HSTS non può prevalere su questa preferenza». — Google Search Central, consolidamento degli URL duplicati. Leggi la fonte

Google / web.dev — copertura e costo

• “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.” (traduzione) «Nei certificati wildcard, la wildcard si applica a una sola etichetta DNS: *.example.com funziona per foo.example.com e bar.example.com, ma non per foo.bar.example.com». — web.dev, abilitare HTTPS sui server. Vai alla citazione
• “Different CAs charge different amounts of money for the service of vouching for your public key.” (traduzione) «Le diverse CA applicano prezzi differenti per il servizio con cui garantiscono la chiave pubblica». — web.dev, abilitare HTTPS sui server. Vai alla citazione

SSL.com — livelli di convalida

• “Domain Validation (DV) is the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (traduzione) «La Domain Validation è il livello minimo e verifica che il richiedente controlli il dominio protetto dal certificato». Vai alla citazione
• “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.” (traduzione) «Come OV, EV verifica l’identità di un’organizzazione, ma richiede controlli più rigorosi e rappresenta uno standard di fiducia superiore». Vai alla citazione

John Mueller, Google Search Relations (risposta social riportata da Search Engine Journal, maggio 2023)

• @EncryptedFence — “this does not ‘Boost your website’s SEO’, sorry.” (traduzione) «Questo non migliora la SEO del sito, mi dispiace». Citazione dalla risposta Mastodon di Mueller riportata da Search Engine Journal: conferma di settore, non una pagina Google ufficiale. Verifica il post originale prima di citarla direttamente. Leggi l’articolo

Glenn Gabe, GSQi (caso di studio su un certificato scaduto, settembre 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.” (traduzione) «A volte i problemi SEO non sono davvero problemi SEO; gli inconvenienti tecnici che coincidono con gli aggiornamenti algoritmici possono trarre in inganno». Caso di studio di settore; l’interfaccia dei browser del 2013 è datata, ma la lezione diagnostica resta valida. Leggi il caso di studio

Quale certificato scegliere?

Procedi dall’alto verso il basso. Le prime due domande determinano ciò che conta; il resto è calcolo della copertura.

1. Vuoi che Google posizioni il sito? Questo requisito è già soddisfatto dall’uso di https://: qualsiasi certificato valido offre lo stesso segnale. La risposta non porta mai a un certificato più caro.

2. Devi mostrare alle persone un’identità organizzativa verificata o rispettare un requisito legale o di conformità?

• No, come nella grande maggioranza di blog, siti di contenuti ed ecommerce → DV, gratuito con Let’s Encrypt e automatizzato.
• Sì, per esempio in contesti bancari, regolamentati o aziendali → OV, oppure EV se il requisito lo nomina espressamente. EV non mostra più un indicatore speciale nei browser moderni: paghi la verifica, non un badge visibile.

3. Quanti nomi host devi proteggere? Questo ambito è indipendente dal punto 2.

• Un solo nome host, come www.example.com → certificato a dominio singolo.
• Molti sottodomini di primo livello, come shop., blog. e app. → wildcard *.example.com; verifica che non esistano host di secondo livello come api.staging.example.com.
• Un elenco specifico anche su domini diversi, come example.com, example.net e brand.io → SAN / multidominio (UCC).
• Sottodomini profondi non raggiunti dalla wildcard → una seconda wildcard al livello giusto oppure un inserimento esplicito nel SAN.

4. Quale algoritmo di chiave e quanti edge o origin servono il nome host? RSA ed ECDSA sono una scelta di sicurezza e compatibilità, non di ranking. Alcuni client vecchi o integrati non supportano ECDSA, quindi verifica l’offerta di CDN e bilanciatore. Se più edge, regioni o origin servono lo stesso nome, prova ogni percorso: un risultato pulito su uno non conferma gli altri.

5. Il rinnovo sarà automatico?

• Sì → bene; le durate brevi non sono un problema.
• No → sistema prima questo aspetto. Usa ACME, Certbot o un certificato gestito dall’host o dalla CDN.

Stai diagnosticando un errore attivo?

• Funziona in Chrome desktop ma fallisce su mobile o negli strumenti → quasi sempre manca un certificato intermedio. Prova SSL Labs o openssl s_client -showcerts e installa la catena completa.
• L’intero sito mostra improvvisamente un avviso → controlla prima la scadenza.
• Un solo sottodominio mostra l’avviso → lacuna di copertura o configurazione mixed-cert.
• L’avviso nomina il sito sbagliato → il nome host non compare nei Subject Names.

Checklist dello stato del certificato

Un controllo per confermare che i certificati siano validi, coprano tutti gli host e non scadano in silenzio:

• Ogni nome host pubblico, dominio principale, www e ogni sottodominio, usa un certificato valido e attendibile, non soltanto la homepage.
• È installata la catena completa, leaf e intermedio, verificata con SSL Labs o openssl s_client -showcerts.
• Il rinnovo è automatico tramite ACME, Certbot, host, CDN o PaaS.
• Un monitor per certificati e uptime avvisa prima della scadenza e quando l’handshake fallisce.
• Nessuna mancata corrispondenza del nome host: ogni host compare nei SAN o è coperto da una wildcard adeguata.
• Le wildcard rispettano il limite di una sola etichetta: nessun host come a.b.example.com resta fuori da *.example.com.
• Nessun certificato autofirmato su host pubblici di produzione.
• La profondità di convalida è scelta per esigenze umane o di conformità, non per un’aspettativa SEO.
• Il rapporto HTTPS di Google Search Console è stato controllato per le segnalazioni di certificato non valido o HTTPS non valutato.
• I sottodomini su piattaforme o CDN diverse sono inventariati e ciascuno ha un rinnovo monitorato.

I modelli mentali

1. Due assi, non uno. Un certificato ha una profondità di convalida (DV/OV/IV/EV) e un ambito di copertura (dominio singolo, wildcard o SAN). Sono indipendenti: puoi avere una wildcard DV o un dominio singolo OV. Google non vede nessuno dei due.

2. Il segnale di ranking non distingue i livelli del certificato. Usare https:// con un certificato valido ottiene lo stesso piccolo segnale a prescindere da emittente, prezzo o livello. Chiedere quale livello aiuti la SEO è un errore di categoria; ciò non significa che la validità sia irrilevante.

3. I problemi del certificato sono un’emergenza di canonicalizzazione, accesso del crawler ed esperienza utente, non di livello di ranking. Quando un certificato si rompe, gli utenti abbandonano; Google può tornare a preferire HTTP come canonico e, con abbastanza problemi, interrompere la scansione HTTPS. Correggi il certificato, senza inseguire un fattore di ranking inesistente.

4. Con durate più brevi, l’automazione è tutto. Il settore va verso certificati da 47 giorni. Con rinnovo automatico, una durata breve è più sicura; il vero rischio è non automatizzare.

5. Il lucchetto della homepage dimostra la validità di un solo nome host. Copertura, scadenze e piattaforme cambiano tra sottodomini. Inventaria e monitora ogni host.

6. Verifica la catena, non il tuo portatile. Chrome desktop conserva gli intermedi in cache. Usa un validatore pulito come SSL Labs o openssl s_client perché un intermedio mancante non resti nascosto.

Certificati SSL/TLS — scheda rapida

Profondità della convalida (che cosa verifica la CA)

Ambito di copertura (quali nomi host protegge)

Riduzione della durata massima del CA/Browser Forum

Quando un certificato si rompe

Dati rapidi

• Un DV gratuito di Let’s Encrypt offre la stessa cifratura e lo stesso ranking di uno a pagamento.
• Il segnale di Google legge lo schema, non il certificato.
• Molti problemi HTTPS possono fermare la scansione delle pagine HTTPS.
• Automatizza il rinnovo con ACME/Certbot o con un certificato gestito.

Ispezionare un certificato e la sua catena completa

È il comando più utile per diagnosticare un certificato. -showcerts stampa ogni certificato realmente inviato dal server ed è il modo più rapido per trovare un intermedio mancante.

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"

L’opzione -servername imposta SNI, essenziale su hosting condivisi o CDN in cui un IP serve più certificati, così verifichi quello corretto.

Windows (PowerShell) — verificare scadenza e nomi coperti

# 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) }

Console di Chrome DevTools — individuare URL di risorse non sicure

Incolla nella console di qualsiasi pagina per elencare le risorse http:// ancora referenziate nell’HTML, come controllo rapido del mixed content:

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

Per verificare tutti i nomi host, un validatore esterno come SSL Labs è più efficiente di uno script host per host; questi restano controlli rapidi locali.

Anti-pattern dei certificati

Errori che incontro ripetutamente:

Acquistare EV o OV “per la SEO”. Google non vede la profondità della convalida. Pagare di più per un vantaggio di ranking inesistente è uno spreco; scegli quel livello solo per fiducia umana o conformità.

Verificare il certificato solo in Chrome desktop. Chrome conserva gli intermedi in cache e può mostrare un lucchetto verde su una catena che fallisce altrove. Valida da un ambiente pulito con SSL Labs o openssl s_client -showcerts.

Promemoria manuali per il rinnovo. Una voce nel calendario non è un sistema di rinnovo. Può rompere l’intero sito in una volta durante un’assenza e peggiora con durate dirette verso 47 giorni.

Presumere che una wildcard copra tutto sotto il dominio. *.example.com si ferma a una sola etichetta DNS. staging.api.example.com non è coperto e può generare errori fino a quando un utente o Googlebot lo visita.

Controllare soltanto la homepage. I sottodomini su altre piattaforme o CDN hanno certificati e scadenze propri. Un lucchetto valido sul dominio principale non dice nulla su blog. o sul marketing.

Certificati autofirmati nella produzione pubblica. Generano un interstiziale grave e falliscono nella maggior parte dei validatori e crawler. Sono adatti solo ad ambienti interni, sviluppo e staging.

Trattare un certificato guasto come problema di livello di ranking o come qualcosa di innocuo. Non è una leva di ranking, ma può riportare la preferenza canonica da HTTPS a HTTP, limitare la scansione e ridurre le conversioni. Correggi il certificato senza inseguire fattori di ranking.

SOP per rinnovo e distribuzione dei certificati

1. Mantieni un inventario dei nomi host. Registra dominio principale, www, sottodomini, endpoint CDN o bilanciatori, emittente, copertura, responsabile del rinnovo e percorso di automazione.
2. Monitora la scadenza indipendentemente dall’emittente. Avvisa con anticipo sufficiente per indagare un’automazione fallita; un calendario non basta.
3. Esercita il rinnovo automatico. Conferma che il flusso ACME, host o CDN possa richiedere, convalidare, installare, attivare e ricaricare ogni processo che conserva il vecchio certificato, senza passaggi manuali.
4. Convalida il candidato. Controlla nomi host e SAN, profondità della wildcard, emittente, finestra di validità e catena intermedia completa.
5. Distribuisci su ogni livello. Aggiorna edge, proxy, bilanciatori e origin che terminano TLS; un endpoint riuscito non copre automaticamente regioni e host.
6. Prova dall’esterno. Usa un validatore pulito e openssl s_client con SNI su host rappresentativi, compresi client senza intermedi in cache.
7. Chiudi il ciclo. Verifica che il monitoraggio rilevi la nuova scadenza, registra la distribuzione e indaga ogni endpoint che serve ancora il certificato precedente.

Tratta un rinnovo fallito come incidente di disponibilità. Su un host HSTS gli utenti non possono ignorare in sicurezza l’errore del certificato.

Toolkit per l’ispezione dei certificati

• SSL Labs Server Test — convalida esterna del certificato servito, della catena, della copertura, dei protocolli e degli endpoint.
• openssl s_client — mostra ciò che un nome host serve tramite SNI e stampa l’intera catena; abbinalo a openssl x509 per date e SAN.
• Visualizzatore del certificato e DevTools — riproducono l’errore di nome host, attendibilità o scadenza sul client interessato.
• Monitoraggio indipendente — avvisa per ogni host inventariato anche quando emittente o CDN dichiarano automatico il rinnovo.
• Rapporto HTTPS di Google Search Console — individua problemi più ampi; usa strumenti per certificati per la diagnosi del singolo endpoint.

Verifica per nome host, non soltanto per IP o homepage. L’infrastruttura condivisa può servire certificati diversi in base a SNI, regione o nodo edge.

Test di rilascio del certificato

Test 1: copertura del nome host e della catena

• Scopo: Dimostrare che ogni nome host pubblico riceva un certificato attendibile che lo includa.
• Metodo: Eseguire SSL Labs e openssl s_client -servername sul dominio principale, www, ogni classe di sottodominio e gli host profondi.
• Risultato atteso: Il nome host corrisponde a un SAN, la catena è completa e un client pulito la convalida senza usare intermedi in cache.
• Condizione di errore: Nome non corrispondente, leaf autofirmato, intermedio mancante o certificato diverso su un endpoint.
• Azione successiva: Correggere copertura o catena, ridistribuire e riprovare.

Test 2: prova del rinnovo automatico

• Scopo: Verificare che il rinnovo sia un processo operativo, non un presupposto.
• Metodo: Eseguire il percorso di staging o dry run supportato e verificare che il flusso installi e attivi il sostituto su ogni livello che termina TLS.
• Risultato atteso: Convalida, emissione, distribuzione e monitoraggio si completano senza intervento manuale.
• Condizione di errore: Convalida del dominio fallita, errore di permessi, nodo edge obsoleto o monitoraggio del vecchio certificato.
• Azione successiva: Riparare l’automazione e ripetere prima della finestra urgente.

Test 3: controllo del client dopo la distribuzione

• Scopo: Rilevare differenze tra endpoint e client nascoste da un solo browser.
• Metodo: Provare più reti e client puliti, confrontare seriali e scadenze e controllare il rapporto HTTPS di Search Console.
• Risultato atteso: Tutti gli endpoint servono il certificato previsto e le pagine restano scansionabili tramite HTTPS.
• Condizione di errore: Incoerenza regionale, avviso, regressione del rapporto HTTPS o scansione fallita.
• Azione successiva: Aggiornare l’endpoint mancante o ripristinare l’ultimo certificato valido mentre si corregge la distribuzione.

Mettiti alla prova: SSL/TLS Certificates

Five rapido domande on how certificates relate to SEO. Pick an risposta for ogni, poi verificare.

Risorse che meritano il tuo tempo

I miei interventi

• Meglio prevenire che curare con HTTPS — SMX East 2016 (SlideShare) — approfondimento su TLS, errori comuni di certificato e migrazione. È anche l’intervento in cui segnalai il rischio di deindicizzazione TLS SNI con Bing e Baidu. Le statistiche di adozione della presentazione risalgono al 2016 e non vanno citate come attuali.

I miei articoli correlati

• Guida per principianti alla SEO tecnica — dove si collocano certificati e HTTPS nel quadro tecnico generale.

Fonti ufficiali e autorevoli

• Rapporto HTTPS e problemi dei certificati SSL di Google — elenco definitivo degli errori mostrati da Search Console.
• Abilitare HTTPS sui server (web.dev) — CA, CSR e copertura wildcard o multinome.
• Consolidare gli URL duplicati — indicazioni sulla preferenza canonica e sui certificati non validi.
• SSL Labs Server Test — valuta la configurazione TLS e segnala le catene incomplete.

Dal settore

• Certificati DV, OV, IV ed EV (SSL.com) — definizioni dei livelli scritte da una CA.
• Un lupo travestito da Panda: l’impatto di un certificato SSL scaduto (Glenn Gabe, GSQi) — caso di studio scambiato per una penalizzazione Panda.
• Google: il certificato SSL non migliora la SEO (Search Engine Journal) — risposta diretta di John Mueller.
• Durate più brevi e limiti di frequenza (Let’s Encrypt) — piano di passaggio da 90 a 64 e 45 giorni.
• La durata dei certificati TLS scenderà a 47 giorni (DigiCert) — calendario del Ballot SC-081v3.
• Errori SSL che incidono sulla SEO (SISTRIX) — panoramica pratica di nome host, scadenza, protocollo e mixed content.
• Certbot (EFF) — client ACME standard per automatizzare emissione e rinnovo.

Statistiche degne di citazione

• La durata massima dei certificati scenderà a 47 giorni entro il 2029. Il Ballot SC-081v3 del CA/Browser Forum, votato l’11 aprile 2025, passa da 398 a 200 giorni nel 2026, 100 nel 2027 e 47 nel 2029, rendendo obbligatoria l’automazione. Fonte
• Let’s Encrypt sta passando da 90 a 64 e poi a 45 giorni. Secondo l’aggiornamento di febbraio 2026, la CA gratuita procederà in due fasi nei due anni successivi; l’annuncio non specifica le date esatte di ogni fase. Fonte
• Un certificato guasto “typically affects an entire site.” (traduzione) «In genere interessa l’intero sito». È il modo in cui Google descrive il raggio d’azione: scadenze ed errori di catena raramente rompono una sola pagina. Fonte
• Molti problemi HTTPS possono fermare la scansione delle pagine HTTPS da parte di Google. È una conseguenza sull’accesso del crawler, distinta dal segnale di ranking e dal possibile ritorno della preferenza canonica a HTTP. Fonte
• Un certificato non valido può prevalere sulla preferenza canonica HTTPS di Google e HSTS non può impedirlo. Le indicazioni di Google citano i certificati TLS/SSL non validi come causa di una preferenza molto forte per la versione HTTP. Fonte

Cronologia modifiche