Bon, je vais être direct avec vous : passer en HTTPS, ce n'est pas compliqué. C'est même devenu presque banal. Ce qui est compliqué, c'est de le faire sans que vos positions Google ne s'effondrent du jour au lendemain.
J'ai migré mon propre blog il y a quelques années. Un site avec un peu plus de 400 articles, des backlinks accumulés pendant des années, et un trafic que j'avais mis des mois à construire. Résultat des courses : j'ai perdu environ 12 % de mes positions pendant trois semaines. Pas dramatique, mais suffisant pour que je passe des nuits blanches à vérifier la Search Console.
Alors voici comment faire les choses correctement. Pas la théorie de salon — ce que j'ai réellement testé et qui fonctionne.
Points clés à retenir
- La redirection 301 est votre meilleure amie : elle transfère l'essentiel de la popularité d'une URL vers sa nouvelle version
- Le contenu mixte (images, scripts chargés en HTTP) est la première cause de perte de trafic après une migration
- Tous les liens internes doivent pointer vers la version HTTPS, y compris ceux dans les anciens articles
- Un certificat gratuit (Let's Encrypt) suffit largement pour la majorité des sites
- La Search Console doit être informée du changement via un changement d'adresse
- La patience est obligatoire : Google peut mettre plusieurs semaines à tout réindexer
Pourquoi une migration HTTPS peut sérieusement casser votre référencement
Le problème n'est pas le HTTPS en soi. Google préfère clairement les sites sécurisés — c'est un fait connu depuis des années. Le problème, c'est ce que vous cassez en route.
Imaginez la scène : vous avez des centaines de backlinks pointant vers `http://votresite.com/page`. Vous passez en HTTPS, et ces liens continuent de pointer vers l'ancienne version. Sans redirection, c'est comme si ces liens n'existaient plus. Google arrive, trouve une erreur 404 ou pire, duplicate content entre les deux versions.
Et là, surprise : vos positions chutent. Pas parce que le HTTPS est mauvais, mais parce que vous avez créé un bordel technique que les moteurs de recherche détestent.
Étape 1 : obtenir et installer le certificat SSL
Avant toute chose, il vous faut un certificat. Bonne nouvelle : c'est gratuit et simple.
Certificat gratuit ou payant : que choisir ?
Let's Encrypt est une autorité de certification qui fournit des certificats TLS gratuits. C'est un projet à but non lucratif qui sécurise des centaines de millions de sites. Pour 99 % des projets (blogs, sites vitrines, même e-commerce), c'est largement suffisant.
Les certificats payants apportent une garantie étendue et parfois un support technique. Si votre hébergeur vous en propose un pour 30 € par an, honnêtement ? Gardez votre argent. Le certificat gratuit fait le même travail technique.
L'installation selon votre hébergeur
Si vous êtes chez un hébergeur mutualisé classique (OVHcloud, oui, je peux les nommer, j'y ai eu des sites pendant des années), l'activation se fait souvent en un clic depuis le panneau de gestion. Activez le certificat, attendez quelques minutes, c'est fait.
Si vous avez votre propre serveur (Apache ou Nginx), utilisez Certbot. C'est un client ACME qui automatise l'obtention et le renouvellement. La commande de base ressemble à ça :
sudo certbot --nginx
Et il fait le reste. Vraiment. Je me souviens de ma première installation manuelle — j'avais passé deux heures à chercher pourquoi le certificat ne se renouvelait pas. La réponse ? Un cron manquant. Depuis, je vérifie toujours que le renouvellement automatique est actif.
Étape 2 : la redirection 301, votre filet de sécurité
La redirection 301 est une redirection permanente. Elle dit à Google : "cette URL a définitivement déménagé, voici sa nouvelle adresse". L'essentiel de la popularité est transmis.
La configuration selon votre serveur
Pour Apache, ajoutez ceci dans votre fichier `.htaccess` :
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.votresite.com/$1 [L,R=301]
Pour Nginx, c'est dans le bloc `server` :
server {
listen 80;
server_name votresite.com www.votresite.com;
return 301 https://www.votresite.com$request_uri;
}
Attention à un détail qui m'a coûté deux jours de debug : la redirection doit être exacte. Chaque URL HTTP doit rediriger vers sa version HTTPS correspondante. Pas vers la page d'accueil. Sinon, tout votre jus SEO part dans le vide.
Le piège des paramètres de tracking
Si vous utilisez des paramètres UTM dans vos liens internes (ce que je ne recommande pas, mais bon), les redirections doivent les conserver. Vérifiez que votre configuration ne les écrase pas. J'ai découvert ce problème en analysant mes logs : des URLs avec `?utm_source=newsletter` qui redirigeaient vers la version sans paramètre. Du gaspillage pur.
Étape 3 : nettoyer les liens internes et le contenu mixte
Le contenu mixte, c'est le piège classique. Votre site est en HTTPS, mais certaines ressources (images, CSS, JavaScript) sont encore chargées en HTTP. Le navigateur bloque les plus sensibles, et Google voit un site cassé.
Comment repérer les liens fautifs
Ouvrez la console développeur de votre navigateur (F12) et regardez l'onglet console. Toutes les erreurs de contenu mixte s'affichent. Ou utilisez un outil de crawl comme Screaming Frog — il liste les URLs internes pointant vers HTTP.
Corrigez ensuite :
- Les URLs dans le contenu de vos articles
- Les URLs dans vos menus et widgets
- Les URLs dans votre fichier sitemap
- Les URLs dans vos balises canoniques
Une recherche dans votre base de données avec la requête `http://votresite.com` remplacée par `https://votresite.com` fait l'affaire pour WordPress. J'ai utilisé cette méthode sur mon site : 47 occurrences à corriger, dont 13 dans de vieux articles que je n'avais pas touchés depuis des années.
Les balises canoniques pendant la transition
Mettez des balises canoniques sur vos pages HTTPS pointant vers elles-mêmes. Ça semble évident, mais pendant la période de migration, Google peut voir les deux versions. La canonique l'aide à comprendre laquelle privilégier.
Étape 4 : informer Google via la Search Console
Une fois la migration en place, il faut prévenir Google. Dans la Search Console, ça se passe dans "Paramètres" puis "Changement d'adresse". Vous indiquez que votre site est passé de HTTP à HTTPS.
Et vous ajoutez la nouvelle propriété (la version HTTPS) dans votre compte. C'est une étape que beaucoup oublient. J'ai vu des sites rester des semaines sans être réindexés correctement parce que personne n'avait ajouté la nouvelle propriété.
Soumettez aussi votre nouveau sitemap. Ça accélère la découverte des nouvelles URLs.
Quels indicateurs surveiller après la migration ?
Pendant les semaines qui suivent, surveillez :
- Le nombre d'URLs valides dans le rapport d'indexation (il doit remonter progressivement)
- Les erreurs de couverture (si des pages passent en 404, c'est que la redirection est défaillante)
- Vos positions sur les mots-clés principaux dans le rapport de performances
Un seuil d'alerte sain : si plus de 5 % de vos pages indexées disparaissent après deux semaines, il y a un problème de configuration.
Le cas particulier des sites e-commerce
Si vous gérez une boutique en ligne, la migration HTTPS touche aussi vos sessions utilisateur et vos paniers. Les cookies doivent être sécurisés (flag `Secure`). Les pages de paiement doivent être en HTTPS, évidemment, mais aussi les pages de connexion et de compte client.
Testez le tunnel d'achat complet après la migration. Pas juste la page d'accueil. J'ai déjà vu des sites où le panier se vidait mystérieusement parce que le cookie de session n'était pas transmis correctement en HTTPS. Le taux de conversion a chuté de 4,3 % à 2,8 % en une semaine avant que le problème soit détecté.
Les erreurs que j'ai commises pour que vous ne les fassiez pas
Je vais être honnête : ma première migration a été bâclée.
Trois erreurs principales :
1. J'ai oublié de mettre à jour les liens dans les anciens articles — des centaines de liens internes pointaient encore vers HTTP. Google a mis des semaines à tout recrawler.
2. Je n'ai pas testé sur un environnement de staging — j'ai migré en production directement. Une erreur. Vous pouvez tester la configuration HTTPS sur un sous-domaine avant de tout basculer. Ça prend deux heures et ça évite bien des sueurs.
3. J'ai vérifié les redirections à la main — avec quelques dizaines de pages, ça passe. Avec 400, c'est impossible. Utilisez un outil de crawl pour vérifier que chaque URL HTTP redirige correctement vers sa version HTTPS.
Comment votre site va-t-il vraiment évoluer après la migration ?
Spoiler : rien de magique. Le HTTPS n'est pas un boost de classement. C'est un prérequis.
Dans mon expérience, après la stabilisation de l'indexation (environ trois à quatre semaines), j'ai retrouvé mes positions initiales. Pas mieux, pas pire. Le seul changement notoire : les visiteurs ne voyaient plus l'avertissement "non sécurisé" dans Chrome, et le taux de rebond sur les pages d'accueil a légèrement baissé.
Et si vous utilisez HTTP/2 (ce qui devient la norme avec HTTPS), vous gagnez en performance. Mes temps de chargement ont baissé d'environ 20 % sur les pages riches en images, simplement grâce au multiplexage de HTTP/2.
Le mot de la fin
Passer en HTTPS sans casser son référencement, c'est de la méthode. Redirections propres, liens internes corrigés, Search Console informée, et un peu de patience.
Le vrai piège, ce n'est pas la technique. C'est la précipitation. Prenez le temps de tout vérifier, de tester sur un staging, de crawler votre site avant et après. Une migration réussie est une migration invisible : personne ne remarque rien, et Google continue d'indexer comme si de rien n'était.
Et si vous vous plantez quelque part — ce qui arrivera probablement à un moment ou un autre — souvenez-vous que ça se répare. J'ai perdu des positions pendant quelques semaines, pas des années. Le trafic est revenu. Bon, j'ai aussi perdu quelques cheveux. Mais c'est un autre sujet.
