Un client m'appelle un matin, paniqué. Son site a perdu 40 % de trafic organique en deux semaines. Pas de pénalité manuelle dans la Search Console, pas de contenu supprimé, pas de changement d'algorithme annoncé. Après vingt minutes à fouiller, je trouve : le certificat SSL avait expiré depuis dix-huit jours. Personne n'avait vu le bandeau rouge dans le navigateur. Personne n'avait vérifié. Et Google avait tranquillement commencé à déclasser les pages concernées.
Voilà le vrai problème avec le SSL et le SEO. Tout le monde sait qu'il faut du HTTPS. Presque personne ne surveille ce qui se passe après l'installation. Or c'est précisément là que se nichent les erreurs qui coûtent des positions — et parfois des clients.
J'ai installé, cassé, réinstallé et débogué des certificats sur une bonne soixantaine de sites ces dernières années. Voici ce que j'ai appris à la dure, et ce que vous devriez éviter de reproduire.
Points clés à retenir
- Un certificat expiré ou mal configuré peut faire chuter le trafic organique en quelques jours, sans pénalité manuelle visible.
- Le contenu mixte (ressources chargées en HTTP sur une page HTTPS) bloque le chargement et envoie un signal de mauvaise qualité aux moteurs.
- Les redirections HTTP → HTTPS doivent être en 301, directes, et couvrir aussi les liens internes, les sitemaps et les balises hreflang.
- Tous les types de certificats ne se valent pas : un certificat wildcard mal déployé peut exposer des sous-domaines entiers.
- La surveillance de l'expiration n'est pas optionnelle. Un rappel par e-mail ne suffit pas.
- Une chaîne de redirection cassée ou bouclée génère des erreurs d'exploration qui freinent l'indexation.
Les erreurs d'installation d'un certificat SSL qui plombent vraiment le SEO
Je vais être direct : la majorité des erreurs que je rencontre ne viennent pas de l'achat du certificat. Elles viennent de la configuration qui suit. On installe, on voit le cadenas vert, on se dit que c'est réglé. Sauf que le cadenas vert ne raconte qu'une partie de l'histoire.
Erreur n°1 : ignorer le contenu mixte
Le contenu mixte, c'est quand votre page se charge en HTTPS mais que certaines ressources — une image, un script, une police, une iframe — sont encore appelées en HTTP. Le navigateur bloque alors ces éléments. Résultat : une page qui s'affiche à moitié, des images cassées, parfois un design complètement défiguré.
Sur un site vitrine que j'ai repris, un carrousel d'images ne s'affichait plus du tout après le passage au SSL. Le développeur précédent avait codé les URL des images en dur en http://. On a perdu en gros 15 % du taux de clics sur cette page en un mois, parce que la vignette de résultat affichait un visuel cassé. Pas dramatique. Mais évitable.
Le vrai risque SEO, c'est ceci : si Googlebot rencontre des ressources bloquées, il rend la page dans un état dégradé. Et une page qui se charge mal, avec un temps d'affichage qui explose, c'est un signal négatif. Pour détecter le problème :
- Ouvrez les outils de développement de votre navigateur, onglet Console, et cherchez les messages de blocage.
- Inspectez le rapport dédié dans la Search Console (section « Contenu mixte » ou « Améliorations »).
- Faites un scan complet via un outil de crawl qui remonte les URL en
http://restantes dans le code source.
La correction est souvent simple — une recherche-remplacement dans les fichiers de thème — mais elle doit être systématique. Je vérifie maintenant chaque page de chaque site après install. Toujours.
Erreur n°2 : mal gérer les redirections HTTP → HTTPS
Installer un certificat ne redirige rien du tout. Vous avez un site accessible en http:// et en https:// — deux versions pour un même contenu. C'est le scénario classique du contenu dupliqué, et Google doit alors choisir laquelle indexer. Vous lui facilitez rarement la tâche.
Deux erreurs que je vois régulièrement sur ce terrain :
- La redirection est faite en 302 au lieu de 301. Une redirection temporaire n'annonce pas un transfert définitif. Les signaux de classement ne sont pas consolidés de la même façon.
- La redirection pointe vers
https://www.example.compour certains liens et vershttps://example.compour d'autres. Vous créez deux versions du domaine. Les liens externes se répartissent entre les deux. Personne n'y gagne.
Ce que vous devez faire : une redirection 301 unique, directe, de http vers https, en choisissant une seule version du domaine (avec ou sans www) et en vous y tenant partout. Dans les liens internes, le canonical, le sitemap, les balises hreflang. Partout.
Erreur n°3 : croire que configurer le SSL se limite à l'installer
La question qu'on me pose le plus souvent est : « Comment configurer le SSL ? » Et la réponse courte, c'est que la configuration ne s'arrête pas à l'installation du certificat sur le serveur. Il y a au moins quatre couches à vérifier.
Côté serveur : le certificat doit être attaché au bon domaine, avec la clé privée correspondante, et la chaîne intermédiaire complète. Une chaîne incomplète passe sur certains navigateurs et échoue sur d'autres — souvent sur des mobiles anciens, ce qui vous coupe tout un pan de trafic.
Côté CMS : dans WordPress ou autre, la configuration « site URL » doit être passée en https://. Sinon vous générez des redirections en cascade depuis l'administration.
Côté contenu : tous les liens internes doivent pointer vers la version HTTPS. Un lien interne en HTTP qui redirige est une redirection évitable. Multipliée sur un site de 500 pages, ça crée un vrai coût d'exploration.
Côté monitoring : vous devez avoir une alerte en cas d'expiration ou d'erreur de chaîne. Pas une notification par mail qu'on ignore dans une boîte surchargée. Une surveillance automate.
Erreur n°4 : ne pas savoir où se trouve le certificat
Ça paraît bête, mais je vois des gens paniquer parce qu'ils ne retrouvent pas le fichier. Alors, où se trouve le certificat SSL ? Il existe à deux endroits : sur votre serveur (dans un répertoire de configuration, souvent /etc/ssl/ ou un gestionnaire de certificats type Let's Encrypt avec ses fichiers dédiés), et dans l'émetteur qui vous l'a délivré (votre compte chez le fournisseur).
Sur un hébergement mutualisé, c'est souvent l'interface du panneau de contrôle qui gère tout, et vous n'avez même pas accès aux fichiers. Sur un serveur dédié, vous êtes responsable. Sur un CDN comme Cloudflare, le certificat vit dans l'infrastructure du CDN, et vous devez en plus gérer le certificat côté serveur d'origine.
Ma règle : documenter l'emplacement, la date d'expiration et la procédure de renouvellement dès l'installation. Sur un papier. Dans un wiki. Peu importe. La personne qui reprendra le site dans six mois vous remerciera — ou maudira votre absence de documentation.
Le renouvellement, angle mort numéro un
Je reviens sur mon client du début. Son certificat avait expiré. Le renouvellement était censé être automatique via Let's Encrypt. Sauf qu'un sous-domaine avait été migré sur un autre serveur, et le script de renouvellement ne couvrait plus ce domaine. Personne ne s'en était rendu compte.
La question « comment mettre à jour un certificat SSL ? » cache souvent ce type de piège. Mettre à jour techniquement, c'est simple : soit le renouvellement automatique fonctionne, soit vous téléchargez le nouveau certificat et le réinstallez à la main. Mais vérifier que le renouvellement a bien eu lieu, c'est autre chose.
- Un certificat expiré génère une erreur de sécurité dans le navigateur. Les visiteurs rebondissent. Google peut retirer le site des résultats.
- Sur un site e-commerce, j'ai vu un certificat expiré un week-end de soldes. Le taux de conversion est tombé à zéro. Pas à 10 %. À zéro. Les gens ne cliquent pas sur un site qui affiche un avertissement.
- Un test d'expiration externe, automatisé, envoyé sur un canal réellement surveillé, coûte quelques euros par an et évite ce genre de scénario.
Le piège du renouvellement automatique : il fonctionne presque toujours. Et quand il échoue, c'est souvent sur le site que personne ne regarde. Celui qui n'est pas dans votre tableau de bord habituel.
Que faire face à un problème de certificat de sécurité SSL ?
Vous tombez sur un message d'avertissement. « Votre connexion n'est pas sécurisée », « le certificat n'est pas valide ». Premier réflexe : ne pas paniquer, et identifier la cause exacte. Le message dépend du problème.
- Certificat expiré : renouvelez et réinstallez immédiatement. Priorité absolue.
- Nom de domaine incorrect : le certificat ne couvre pas le domaine. Vérifiez la liste des noms couverts (Common Name + Subject Alternative Names).
- Chaîne incomplète : il manque le certificat intermédiaire. Votre serveur doit présenter la chaîne complète.
- Contenu mixte : le certificat est valide, mais la page charge des ressources en HTTP. Ce n'est pas un problème de certificat au sens strict, mais le message est souvent confusant.
Un test rapide : ouvrez le site dans un navigateur, cliquez sur le cadenas, inspectez le certificat. Vous verrez immédiatement la date d'expiration et l'émetteur. Si le cadenas est vert et que le certificat est récent, le problème est ailleurs — probablement le contenu mixte ou la chaîne.
Les types de certificats et leurs pièges SEO
| Type de certificat | Ce qu'il couvre | Erreur fréquente | Impact SEO |
|---|---|---|---|
| Simple (mono-domaine) | Un seul nom de domaine | Oublier un sous-domaine utilisé pour un blog ou une boutique | Sous-domaine non sécurisé, erreurs navigateur, baisse de confiance |
| Wildcard | Tous les sous-domaines de premier niveau | Croire qu'il couvre les sous-domaines de sous-domaines | Sous-domaine non couvert = erreur de sécurité |
| Multi-domaine (SAN) | Plusieurs domaines distincts | Oublier d'ajouter un domaine redirigé, ce qui crée une erreur | Perte de trafic sur le domaine oublié |
| Gratuit (Let's Encrypt) | Domaine unique ou multi | Renouvellement automatique non surveillé | Expiration silencieuse, chute de trafic |
Le vrai piège du wildcard, c'est qu'il ne protège pas les sous-domaines imbriqués. Un certificat *.example.com couvre blog.example.com mais pas shop.blog.example.com. J'ai vu un site perdre des semaines de référencement sur un sous-domaine de blog parce que cette règle avait été mal comprise.
La checklist que je fais maintenant systématiquement
Après chaque installation, je vérifie cinq choses. Ça prend dix minutes et ça évite des semaines de réparation.
- Le certificat est valide, la chaîne complète, et couvre tous les domaines et sous-domaines actifs.
- Aucune ressource en HTTP ne subsiste dans le code source (contenu mixte).
- La redirection HTTP → HTTPS est en 301, directe, et cohérente sur tout le site.
- Les liens internes, le canonical, le sitemap et les balises hreflang pointent tous vers HTTPS.
- Une surveillance externe est en place, et j'ai reçu une alerte de test pendant la première semaine.
Un client m'a dit un jour : « Mais enfin, le SSL, c'est un cadenas, pas de la magie. » Il avait raison. C'est un cadenas. Sauf que sous ce cadenas se joue une bonne partie de la confiance que Google — et surtout vos visiteurs — vous accordent. Et un cadenas qu'on oublie de renouveler, c'est un rideau de fer qui tombe sur votre référencement.
La prochaine fois que vous verrez un certificat expiré quelque part, pensez à cette question : combien de temps s'est écoulé avant que quelqu'un le remarque ? La réponse vous en dira long sur la robustesse de votre installation.
