Rapport HTTPS de Google Search Console

En bref — Le rapport HTTPS de Google Search Console indique combien de vos pages Google affiche dans leur version sécurisée (HTTPS), plutôt que dans leur ancienne version non sécurisée (HTTP), et explique pourquoi certaines restent en HTTP. Google préfère utiliser la version HTTPS : sur un site sain, cette proportion devrait donc atteindre ou approcher 100 %.

À quoi sert le rapport HTTPS

Lorsqu’une page est accessible à la fois à l’adresse http://example.com/page et à l’adresse https://example.com/page, Google cherche généralement à afficher la version HTTPS (sécurisée) dans les résultats. Le rapport HTTPS permet de vérifier si cela se passe bien sur votre site : il compte les pages indexées en HTTPS et celles qui restent en HTTP.

Deux précisions avant de l’interpréter :

• Il ne couvre que les pages indexées par Google, et non toutes les pages du site.
• Il présente un échantillon, pas une liste exhaustive. Le total n’est donc pas un inventaire exact.

Pourquoi une page apparaît en HTTP

Lorsqu’une page apparaît en HTTP, cela ne signifie généralement pas que toute la sécurité du site est défaillante. Plusieurs causes sont possibles : un élément du site indique à Google de préférer HTTP, la version HTTPS est absente ou renvoie une erreur, Google a interrompu ses vérifications après des erreurs à l’échelle du site, ou l’URL est simplement nouvelle et n’a pas encore été évaluée. Commencez par ces causes fréquentes, chacune correspondant à un signal que vous pouvez repérer et corriger :

• Une balise « canonical » de la page pointe vers l’adresse HTTP.
• Votre sitemap contient la version HTTP de l’URL.
• La version HTTPS redirige vers HTTP, dans le mauvais sens.
• La version HTTPS est bloquée dans votre fichier robots.txt.
• Le certificat SSL est réellement défectueux.

Comment corriger le problème

Identifiez la cause correspondante ci-dessus, puis faites pointer le signal vers HTTPS : corrigez la balise canonical, mettez le sitemap à jour, réparez la redirection pour qu’elle mène de HTTP vers HTTPS (jamais l’inverse) ou intervenez sur le certificat. Demandez ensuite à Google de revérifier la page ; l’outil Inspection de l’URL permet de solliciter une nouvelle exploration. Au fil du temps, la proportion HTTPS devrait se rapprocher de 100 %.

L’erreur d’interprétation la plus fréquente

HTTPS n’est pas un facteur de classement majeur. C’est bien un signal, mais il reste très léger. Adoptez HTTPS pour la sécurité, la confiance des visiteurs et la propreté de vos données analytiques et de vos URL canoniques, non dans l’espoir de gagner des positions. Si vous voyez « HTTPS non évalué », ne supposez pas non plus que l’état est sans conséquence : il peut s’agir d’une version HTTPS absente, d’un arrêt des vérifications après des erreurs globales, du choix d’une URL canonique HTTP ou — seul cas réellement peu préoccupant — d’une URL nouvelle qui n’a pas encore été explorée. Déterminez le cas applicable avant de corriger quoi que ce soit ou décider d’attendre.

Vous voulez le détail de chaque motif d’erreur et son rapport avec la canonicalisation et le rapport d’indexation des pages ? Passez à l’onglet Advanced.

En bref — Le rapport HTTPS indique combien d’URL indexées Google sert en HTTPS plutôt qu’en HTTP ; il repose sur un échantillon, pas sur une liste exhaustive. Google préfère indexer la version HTTPS d’une page disponible sous les deux protocoles, mais une ligne HTTP ne signifie pas nécessairement qu’un signal contradictoire a supplanté cette préférence : l’équivalent HTTPS peut être absent, le traitement peut avoir échoué à l’échelle du site ou l’URL peut être nouvelle et non explorée. La préférence HTTPS n’est qu’un signal parmi ceux que Google évalue pour choisir la canonique. Ce rapport, le rapport d’indexation des pages et l’Inspection de l’URL sont liés sans être interchangeables. HTTPS reste un signal de classement léger : corrigez ces problèmes pour la confiance et une canonicalisation propre, non pour gagner des positions.

Ce que mesure réellement le rapport

La documentation l’énonce ainsi : “The HTTPS report shows how many indexed URLs on your site are HTTP vs HTTPS.” (traduction) « Le rapport HTTPS indique combien d’URL indexées de votre site sont en HTTP ou en HTTPS. » Deux termes nuancent fortement cette phrase, et beaucoup de lecteurs négligent les deux.

Premièrement, indexées : le rapport ne porte que sur les URL déjà indexées par Google, pas sur l’ensemble de vos URL. Deuxièmement, il s’agit d’un échantillon : “The report isn’t a comprehensive list of all detected items.” (traduction) « Le rapport ne constitue pas une liste exhaustive de tous les éléments détectés. » C’est donc un diagnostic, pas un inventaire. Ne cherchez pas à rapprocher ce nombre du total de vos pages : les populations diffèrent. Le rapport est disponible pour les propriétés de domaine et les propriétés avec préfixe d’URL HTTPS.

Search Console associe chaque URL HTTP à son équivalent HTTPS en ignorant les paramètres : une chaîne de requête telle que ?utm_source= n’empêche donc pas l’association. En revanche, une URL HTTPS dont la structure diffère n’est pas considérée comme la version sécurisée de l’URL HTTP. Si votre migration a modifié les chemins et pas seulement le protocole, la page HTTPS ne sera pas reconnue ici comme l’équivalent, même si elle fonctionne parfaitement. Puisque le rapport échantillonne des URL indexées au lieu d’explorer en direct toutes vos URL, l’absence d’une URL ne prouve pas qu’elle est saine : elle peut ne pas être indexée ou ne pas appartenir à l’échantillon. Servez-vous du rapport pour repérer des tendances, pas comme audit exhaustif URL par URL.

Pourquoi des lignes HTTP apparaissent

Le modèle mental utile tient dans cette phrase : “If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version.” (traduction) « Si une page de votre site possède une adresse HTTP et une adresse HTTPS, Google préfère indexer la version HTTPS. » HTTPS est la préférence par défaut, mais une ligne HTTP ne signifie pas toujours qu’un signal plus fort l’a emporté. Examinez les causes dans cet ordre :

1. HTTPS absent ou en erreur. Il n’existe pas encore d’équivalent HTTPS fonctionnel, ou celui-ci renvoie une erreur.
2. Un signal contradictoire. Un élément du site vote explicitement pour HTTP : une balise canonical, une entrée de sitemap, une redirection inversée ou un blocage par robots. Les cinq motifs nommés ci-dessous relèvent de cette catégorie.
3. Un échec de traitement à l’échelle du site. Google a rencontré tant d’erreurs qu’il a interrompu le traitement des URL en attente, ou un problème global, tel qu’un certificat défectueux, empêche toute évaluation.
4. Une URL réellement nouvelle ou non explorée. Google ne l’a jamais vue ou l’a vue sans encore l’explorer. C’est le seul cas où ses propres consignes recommandent une courte attente, d’environ une journée, avant une nouvelle vérification.

Le choix entre HTTPS et HTTP n’est qu’un signal parmi ceux que Google pondère pour sélectionner une URL canonique. Leur nombre n’est pas fixe, et je ne donnerai pas de chiffre précis sans source vérifiable. Chaque motif nommé ci-dessous correspond à la cause 2 ; l’état « HTTPS non évalué » recouvre les causes 1, 3 et 4.

Les motifs d’erreur — “why HTTP pages aren’t served over HTTPS” (traduction) « pourquoi les pages HTTP ne sont pas servies en HTTPS »

Voici les états du rapport. Chacun correspond à un signal contradictoire précis et appelle une correction précise.

• Page HTTP associée à une balise canonical — “The HTTP page has a <link rel="canonical"> tag, indicating that the HTTP version is canonical.” (traduction) « La page HTTP possède une balise link rel=“canonical” indiquant que la version HTTP est canonique. » Vous avez explicitement désigné l’URL HTTP comme préférée. Correction : déclarez plutôt l’URL HTTPS comme canonique.
• Certificat HTTPS non valide — “The HTTPS URL has an invalid SSL certificate.” (traduction) « L’URL HTTPS possède un certificat SSL non valide. » Google ne teste une URL HTTPS que si son certificat est valide ; le problème touche généralement tout le site plutôt qu’une seule page. Corrigez le certificat.
• Sitemap pointant vers HTTP — “A sitemap on your site is pointing to an HTTP URL that was indexed as canonical.” (traduction) « Un sitemap de votre site pointe vers une URL HTTP indexée comme canonique. » Votre sitemap vote pour HTTP. Mettez-le à jour afin qu’il contienne les URL HTTPS.
• Redirection depuis HTTPS — “The HTTPS URL exists, but redirects to an HTTP URL.” (traduction) « L’URL HTTPS existe, mais redirige vers une URL HTTP. » La redirection va dans le mauvais sens. Elle doit toujours mener de HTTP vers HTTPS, jamais l’inverse. Dans l’étude technique d’Ahrefs portant sur plus d’un million de domaines, une proportion non négligeable de sites commettait précisément cette erreur.
• URL HTTPS bloquée par robots.txt — “The HTTPS URL is present, but is blocked from crawling by a robots.txt rule.” (traduction) « L’URL HTTPS existe, mais une règle robots.txt en bloque l’exploration. » Google ne peut pas explorer la version HTTPS pour la confirmer et revient donc à HTTP. Autorisez l’URL HTTPS dans robots.txt.
• HTTPS non évalué — il s’agit d’un état générique, pas d’une panne unique. La documentation précise : “This error can be caused by any of the following conditions” (traduction) « Cette erreur peut être due à l’une des conditions suivantes » : l’URL HTTP n’a aucun équivalent HTTPS ; les deux existent, mais Google a choisi HTTP comme canonique ; Google a rencontré tant d’erreurs qu’il a cessé de traiter les URL en attente ; une erreur globale, par exemple un mauvais certificat SSL, empêche l’évaluation ; ou Google n’a jamais vu l’URL, ou l’a vue sans l’explorer. Ne considérez pas cet état comme bénin par défaut : recherchez sa cause. Une URL véritablement nouvelle ou non explorée est le seul cas pour lequel Google recommande sous condition d’attendre environ une journée après l’exploration. Un équivalent HTTPS absent, une canonique HTTP ou une erreur globale exigent une correction, pas de la patience.
• Autres problèmes — “Another error occurred that is not covered in the list of errors.” (traduction) « Une autre erreur, absente de cette liste, s’est produite. » Il s’agit de la catégorie résiduelle.

Rectifions un mythe répandu : la page d’aide actuelle ne comporte ni ligne « noindex » ni ligne « HSTS ». Ces notions connexes méritent d’être comprises : un noindex sur la page HTTPS peut effectivement empêcher son indexation et son affichage, tandis que HSTS impose HTTPS dans le navigateur et soutient les bonnes redirections. Elles ne sont toutefois pas des catégories de ce rapport. Ne cherchez pas des lignes inexistantes.

Articulation entre préférence HTTPS, canonicalisation et rapport d’indexation

Le rapport HTTPS ne fonctionne pas en vase clos, mais il n’est pas interchangeable avec les autres outils. Trois surfaces distinctes de Search Console peuvent concerner la même URL, chacune apportant une information différente :

Une même cause profonde peut les affecter : un conflit de canonique peut apparaître ici comme ligne HTTP et, dans l’indexation des pages, comme « Page en double : Google n’a pas choisi la même URL canonique que l’utilisateur ». Cela reste une hypothèse à vérifier pour chaque URL, non une correspondance automatique. Consultez l’Inspection de l’URL avant de conclure que les deux rapports décrivent le même problème.

Contenu mixte et dépendances non sécurisées

Le contenu mixte — une page HTTPS qui charge des ressources HTTP comme des images, des scripts ou des feuilles de style — n’est pas un motif nommé dans ce rapport, et la documentation actuelle de Google ne le cite pas parmi ses causes. Il faut néanmoins le corriger pour ses risques propres : les navigateurs le signalent ou le bloquent, et il constitue une véritable faille de sécurité. Ne le diagnostiquez toutefois pas à partir de ce rapport. Si une page reste en HTTP après exclusion des cinq motifs nommés, vérifiez séparément le contenu mixte dans les outils de développement du navigateur ou avec un robot d’exploration. Il en va de même pour HSTS : cette protection utile au niveau du navigateur ne correspond pas non plus à une ligne du rapport.

HTTPS comme signal de classement : la version honnête

HTTPS est présenté comme facteur de classement depuis l’annonce faite en 2014 par l’équipe Google chargée des webmasters, notamment Zineb Ait Bahajji et Gary Illyes. À l’époque, il a été décrit comme un signal léger, de moindre poids que des éléments tels que la qualité du contenu. Je n’ai pas pu reconfirmer mot pour mot cette annonce de 2014 sur une copie accessible lors de cette mise à jour : considérez donc le chiffre précis comme rapporté, et non comme une garantie textuelle. Le constat durable ne change pas : HTTPS n’a jamais été présenté comme un levier de classement puissant. Il fait aussi partie des recommandations plus larges sur l’expérience sur la page. Rien de cela ne provient du rapport HTTPS lui-même : celui-ci ne montre ni effet sur le classement, ni clics, ni trafic. Il diagnostique uniquement la mise en œuvre du protocole. Corrigez donc HTTPS pour la sécurité, la confiance des utilisateurs, la fiabilité des données de provenance dans les outils analytiques et une canonicalisation nette, pas pour un gain de positions. C’est un prérequis, pas un moteur de croissance.

Corriger puis confirmer

La méthode reste la même quel que soit le motif étudié : elle part de la cause, pas du libellé de la ligne.

1. Identifiez la cause. Le rapport fournit un point de départ échantillonné ; confirmez ce qui se produit vraiment : HTTPS absent, signal contradictoire, erreur globale ou URL réellement nouvelle.
2. Corrigez à la source. Réparez la canonique, l’entrée de sitemap, le sens de la redirection, la règle robots ou le certificat. Supprimer des liens vers l’URL ne corrige rien : cela masque le symptôme sans traiter la cause.
3. Confirmez dans l’Inspection de l’URL, en examinant séparément le test en direct et l’état indexé ; juste après une correction, ils peuvent diverger.
4. Surveillez le groupe échantillonné, pas seulement une URL. Le rapport HTTPS reclassifie les URL selon son propre calendrier ; aucun délai universel ne peut être promis. Pour une URL réellement nouvelle et non explorée, seule situation assortie d’une recommandation conditionnelle, attendez environ une journée avant de revérifier.

J’ai accompagné de nombreux sites dans leur migration entre protocoles — ma conférence SMX East 2016, Mieux vaut prévenir que guérir avec HTTPS, en donne la version longue — et la leçon revient toujours : disposer d’une version HTTPS ne suffit pas. Si vos balises canonical, sitemaps ou redirections pointent encore vers HTTP, Google peut continuer à indexer HTTP. Alignez tous les signaux et le rapport finira par se corriger.

Résumé par l’IA

Version condensée de l’onglet Advanced :

• Mesure : nombre d’URL indexées servies par Google en HTTPS ou en HTTP. Le rapport est un échantillon, pas une liste exhaustive, disponible pour les propriétés de domaine et les propriétés avec préfixe d’URL HTTPS. L’association ignore les paramètres d’URL, mais pas un changement de structure.
• Préférence par défaut : Google préfère indexer la version HTTPS d’une page présente sous les deux protocoles. Une ligne HTTP ne prouve toutefois pas qu’un signal contradictoire l’a emporté. Vérifiez, dans l’ordre : HTTPS absent ou en erreur, signal contradictoire (les cinq motifs nommés), échec de traitement global, puis URL réellement nouvelle ou non explorée.
• Sept lignes : page HTTP associée à une balise canonical · certificat HTTPS non valide · sitemap pointant vers HTTP · redirection HTTPS→HTTP dans le mauvais sens · URL HTTPS bloquée par robots.txt · HTTPS non évalué (état générique : cherchez la cause, ne le supposez pas bénin) · autres problèmes.
• Mythes : la page d’aide actuelle ne comporte ni ligne « noindex », ni ligne « HSTS », ni ligne « contenu mixte ». Ce sont des notions connexes, pas des catégories du rapport.
• Trois surfaces liées : rapport HTTPS (vue échantillonnée du protocole), rapport d’indexation des pages (état d’indexation et canonique choisie) et Inspection de l’URL (état indexé et état en direct). Elles peuvent partager une cause, mais il faut vérifier cette hypothèse URL par URL.
• Classement : HTTPS est un signal léger, introduit en 2014, et relève de l’expérience sur la page ; le rapport ne fournit cependant aucune donnée de classement, de clics ou de trafic. Corrigez pour la confiance et une canonicalisation propre, pas pour gagner des positions.
• Boucle de correction : identifier la cause → la corriger à la source, sans seulement supprimer des liens → vérifier séparément le test en direct et l’état indexé dans l’Inspection de l’URL → suivre l’échantillon jusqu’à ce qu’il tende vers 100 % HTTPS, sans promettre de délai.

Documentation officielle

Documentation primaire publiée par Google.

Google

• Rapport HTTPS — Aide Search Console — contenu du rapport, motifs d’erreur et sous-causes de l’état « HTTPS non évalué ».
• Le nouveau rapport HTTPS dans Search Console (sept. 2022) — annonce du lancement du rapport.
• HTTPS comme signal de classement (août 2014) — annonce initiale du signal de classement.
• Indexation des pages HTTPS par défaut (déc. 2015) — contexte sur l’indexation HTTPS par défaut de Google.
• Canonicalisation des URL — place de la préférence HTTPS parmi les signaux canoniques de Google.
• Regrouper les URL en double avec rel=canonical — déclaration de l’URL HTTPS comme canonique.
• Comprendre l’expérience sur la page — place de HTTPS dans l’expérience sur la page.

Citations de la source

Déclarations publiques de Google. Chaque lien mène directement au passage cité dans la page source.

Google — ce que montre le rapport

• “The HTTPS report shows how many indexed URLs on your site are HTTP vs HTTPS.” (traduction) « Le rapport HTTPS indique combien d’URL indexées de votre site sont en HTTP ou en HTTPS. » — Aide Search Console. Accéder à la citation
• “The report isn’t a comprehensive list of all detected items.” (traduction) « Le rapport ne constitue pas une liste exhaustive de tous les éléments détectés. » — Aide Search Console. Accéder à la citation
• “If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version.” (traduction) « Si une page de votre site possède une adresse HTTP et une adresse HTTPS, Google préfère indexer la version HTTPS. » — Aide Search Console. Accéder à la citation

Google — les motifs d’erreur

• “The HTTP page has a <link rel="canonical"> tag, indicating that the HTTP version is canonical.” (traduction) « La page HTTP possède une balise link rel=“canonical” indiquant que la version HTTP est canonique. » — Aide Search Console. Accéder à la citation
• “The HTTPS URL has an invalid SSL certificate.” (traduction) « L’URL HTTPS possède un certificat SSL non valide. » — Aide Search Console. Accéder à la citation
• “A sitemap on your site is pointing to an HTTP URL that was indexed as canonical.” (traduction) « Un sitemap de votre site pointe vers une URL HTTP indexée comme canonique. » — Aide Search Console. Accéder à la citation
• “The HTTPS URL exists, but redirects to an HTTP URL.” (traduction) « L’URL HTTPS existe, mais redirige vers une URL HTTP. » — Aide Search Console. Accéder à la citation
• “The HTTPS URL is present, but is blocked from crawling by a robots.txt rule.” (traduction) « L’URL HTTPS existe, mais une règle robots.txt en bloque l’exploration. » — Aide Search Console. Accéder à la citation
• “Another error occurred that is not covered in the list of errors.” (traduction) « Une autre erreur, absente de cette liste, s’est produite. » — Aide Search Console. Accéder à la citation

Google — HTTPS comme signal de classement (août 2014)

• HTTPS is a “very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (traduction) « un signal très léger, qui affecte moins de 1 % des requêtes mondiales et pèse moins que d’autres signaux tels qu’un contenu de grande qualité ». — Zineb Ait Bahajji & Gary Illyes, Google Webmaster Central Blog, 2014. Lire l’annonce

Motifs d’erreur — aide-mémoire

Signification et correction de chaque ligne. Rappel : le rapport couvre un échantillon d’URL indexées. Une ligne HTTP peut signaler qu’un signal contradictoire l’a emporté sur la préférence HTTPS de Google, mais aussi qu’un équivalent HTTPS manque, que le traitement a échoué à l’échelle du site ou que l’URL est simplement nouvelle et non évaluée. Examinez le motif précis.

Éléments absents du rapport, contrairement à un mythe répandu : la page d’aide actuelle ne contient ni ligne « noindex », ni ligne « HSTS », ni ligne « contenu mixte ». Ces concepts sont liés au sujet, mais ne constituent pas des catégories du rapport.

Repères rapides

• Périmètre : uniquement des URL indexées, sous forme d’échantillon, pas d’inventaire exhaustif.
• Disponibilité : propriétés de domaine et propriétés avec préfixe d’URL HTTPS.
• Préférence : Google privilégie la version HTTPS lorsque les deux existent ; une ligne HTTP ne signifie pas automatiquement qu’un signal a battu HTTPS. Vérifiez si HTTPS manque, si l’évaluation s’est interrompue ou si l’URL est simplement nouvelle.
• Sens correct de la redirection : HTTP → HTTPS, jamais HTTPS → HTTP.
• Poids dans le classement : léger, présenté en 2014 comme inférieur à 1 % des requêtes ; le rapport lui-même ne montre aucune donnée de classement.

Liste de contrôle pour diagnostiquer une ligne HTTP

Lorsqu’une URL apparaît en HTTP, parcourez cette liste afin de trouver le signal contradictoire :

• Balise canonical — le rel="canonical" de la page HTTP pointe-t-il vers HTTP ? Faites-le pointer vers l’URL HTTPS.
• Sitemap — un sitemap contient-il la version HTTP ? Remplacez-la par HTTPS.
• Redirections — l’URL HTTPS redirige-t-elle vers HTTP ? Inversez le sens pour obtenir HTTP → HTTPS.
• robots.txt — l’exploration de l’URL HTTPS est-elle bloquée ? Autorisez-la.
• Certificat SSL — le certificat est-il valide pour tout le site ? Google ne testera HTTPS qu’une fois le certificat valide.
• Contenu mixte — la page HTTPS charge-t-elle des ressources HTTP non sécurisées ? Passez-les en HTTPS.
• « HTTPS non évalué » ? — ne concluez pas automatiquement que tout va bien. Déterminez s’il manque HTTPS, si HTTP a été choisi comme canonique, si une erreur globale existe ou, seul cas peu préoccupant, si l’URL est nouvelle et non explorée.
• Nouvelle vérification — utilisez l’Inspection de l’URL, demandez l’indexation et attendez la réévaluation.
• Recoupement — comparez la décision canonique du rapport d’indexation des pages pour la même URL.

Les modèles mentaux

1. HTTPS est la préférence par défaut, mais une ligne HTTP peut avoir plusieurs causes. Google préfère indexer la version HTTPS d’une page disponible sous les deux protocoles. Quand une URL apparaît en HTTP, posez successivement ces questions : HTTPS est-il absent ou en erreur ? Un élément vote-t-il explicitement pour HTTP, comme l’un des motifs nommés ? Google a-t-il interrompu le traitement après des erreurs globales ? Ou s’agit-il simplement d’une URL nouvelle qu’il n’a pas encore traitée ?

2. Chaque motif nommé correspond à un signal contradictoire. Balise canonical · entrée de sitemap · sens de redirection · règle robots · certificat. Repérez le signal en cause, faites-le pointer vers HTTPS et corrigez-le : toute la boucle de réparation tient là.

3. « Non évalué » exige un diagnostic, pas une conclusion par défaut. Cet état générique recouvre de véritables problèmes — HTTPS absent, canonique HTTP, erreur globale — mais aussi un cas réellement peu préoccupant : une URL nouvelle que Google n’a pas encore explorée. Identifiez lequel s’applique avant de corriger ou d’attendre.

4. Le rapport HTTPS, l’indexation des pages et l’Inspection de l’URL sont liés, mais non interchangeables. Le protocole HTTPS ou HTTP n’est qu’un signal parmi ceux que Google pondère pour choisir la canonique. Ces trois surfaces peuvent partager une cause, mais il faut confirmer cette hypothèse URL par URL plutôt que supposer une correspondance systématique.

5. Corrigez HTTPS pour la confiance, pas pour le classement. C’est un signal de classement léger et un élément de l’expérience sur la page. Les vrais bénéfices sont la sécurité, la confiance des utilisateurs, des données de provenance propres et une canonicalisation sans ambiguïté.

Prouver qu’une correction HTTPS a pris effet

Confirmer la redirection et le certificat

Test à exécuter — Interrogez l’URL HTTP et suivez sa chaîne de redirections avec curl -I ou le panneau Réseau du navigateur, puis chargez l’URL HTTPS finale. Résultat attendu — HTTP redirige directement vers HTTPS, la réponse finale réussit et le navigateur signale un certificat valide. Interprétation d’un échec — Une redirection inversée, une boucle ou un problème de certificat empêche encore d’atteindre proprement la destination HTTPS. Fenêtre de surveillance — Immédiate. Déclencheur de retour arrière — Annulez la modification de redirection si elle boucle, aboutit en HTTP ou rend l’URL de production indisponible.

Confirmer l’alignement de tous les signaux canoniques

Test à exécuter — Inspectez la page HTTPS active et son entrée de sitemap, puis vérifiez l’URL dans l’Inspection de l’URL de Search Console. Résultat attendu — La canonique de la page pointe vers HTTPS, le sitemap contient HTTPS et l’URL inspectée expose la canonique HTTPS prévue sans blocage robots. Interprétation d’un échec — Au moins un signal du site vote encore pour HTTP ou empêche Google d’évaluer HTTPS. Fenêtre de surveillance — Les signaux du site changent immédiatement ; la canonique sélectionnée par Google peut nécessiter une nouvelle exploration. Déclencheur de retour arrière — Arrêtez le déploiement si la modification pointe les canoniques vers le mauvais ensemble d’URL ou retire du sitemap des pages qui doivent y figurer.

Confirmer l’absence de dépendances non sécurisées

Test à exécuter — Chargez la page HTTPS avec les panneaux Console et Réseau du navigateur ouverts, puis explorez un ensemble représentatif de modèles à la recherche de ressources en http://. Résultat attendu — Aucune erreur active de contenu mixte et aucune ressource nécessaire demandée en HTTP. Interprétation d’un échec — Les modèles, hébergeurs de ressources ou contenus enregistrés émettent encore des dépendances non sécurisées. Fenêtre de surveillance — Immédiatement après le déploiement. Déclencheur de retour arrière — Revenez en arrière si le passage à HTTPS casse des scripts, styles, images ou parcours de paiement indispensables.

Confirmer le reclassement de l’URL par Search Console

Test à exécuter — Après une nouvelle exploration, vérifiez l’Inspection de l’URL et la ligne du rapport HTTPS pour le groupe concerné. Résultat attendu — Google voit la version HTTPS et le groupe d’erreurs HTTP diminue sans perte correspondante de pages qui doivent rester indexées. Interprétation d’un échec — Google n’a pas encore réexploré les URL ou un autre signal contradictoire subsiste. Fenêtre de surveillance — Attendez la réexploration et l’actualisation du rapport échantillonné ; un état immédiat « non évalué » ne constitue pas un échec. Déclencheur de retour arrière — Enquêtez ou annulez la modification si le nombre d’URL devant être indexées baisse tandis que les erreurs HTTPS persistent.

Outils pour exploiter le rapport HTTPS

• Google Search Console — rapport HTTPS — le rapport lui-même : répartition HTTPS et HTTP et lignes “why HTTP isn’t served over HTTPS” (traduction) « pourquoi HTTP n’est pas servi en HTTPS ».
• Inspection de l’URL (GSC) — vérifie comment une URL précise a été explorée, rendue et indexée, affiche la canonique choisie et permet de demander une nouvelle exploration.
• Rapport d’indexation des pages (GSC) — confirme si une URL est indexée et quelle canonique Google a choisie.
• Outils de développement du navigateur — les panneaux Sécurité et Console signalent directement le contenu mixte et les problèmes de certificat.
• Robots d’audit de site — Ahrefs Site Audit et Screaming Frog SEO Spider repèrent à grande échelle les canoniques vers HTTP, redirections inversées, entrées HTTP dans les sitemaps, blocages robots et contenus mixtes.
• Ahrefs Webmaster Tools — exploration et audit gratuits pour les sites que vous avez validés.

Ressources utiles

Mes conférences

• Mieux vaut prévenir que guérir avec HTTPS (SMX East 2016, SlideShare) — ma conférence sur la migration HTTPS, ou la version longue de la leçon « alignez tous les signaux ».

Mes articles connexes

• Google utilise environ 40 signaux de canonicalisation — place de la préférence HTTPS parmi les signaux canoniques.
• 11 types de redirections et leur effet sur le SEO — pourquoi une redirection doit toujours aller de HTTP vers HTTPS.
• Étude SEO technique d’Ahrefs sur plus d’un million de domaines — données réelles sur les sites qui redirigent dans le mauvais sens et d’autres problèmes de protocole.
• Migration de site web : le guide définitif — pour les lecteurs préparant une migration HTTP→HTTPS.

Autres auteurs

• Rapport HTTPS — Aide Search Console — source principale.
• Google lance un nouveau rapport HTTPS dans Search Console — compte rendu du lancement par Barry Schwartz dans Search Engine Land.
• Confusion autour de l’état HTTPS non valide dans Google Search Console — Search Engine Roundtable documente les difficultés réelles de la communauté face à cet état.
• Why HTTPS Matters — introduction de web.dev à l’importance de HTTPS pour la sécurité, la confiance et les performances, au-delà du SEO.
• Corriger le contenu mixte — guide de web.dev pour repérer et corriger les ressources HTTP sur les pages HTTPS, ces dépendances non sécurisées pouvant nuire au déploiement HTTPS.
• HTTPS comme signal de classement (août 2014) — annonce originale de Google présentant HTTPS comme un signal léger.
• r/TechSEO — communauté utile pour diagnostiquer les états « HTTPS non valide » ou « non évalué ».

Testez vos connaissances : le rapport HTTPS

Cinq questions rapides sur l’interprétation et la correction du rapport HTTPS de Search Console. Choisissez une réponse pour chacune, puis vérifiez.

Journal des modifications