Un certificat SSL installé. Une redirection 301 posée. Et deux semaines plus tard, le trafic organique qui dégringole de 40 %. C'est le mail que je reçois le plus souvent de la part de gens qui ont migré leur site HTTP vers HTTPS en pensant que ça se résumait à cocher une case chez leur hébergeur.
Je vais être direct : passer en HTTPS est simple. Ne pas y perdre de positionnement, c'est une autre histoire. J'ai fait cette migration sur une dizaine de sites, dont un qui m'a coûté trois mois de récupération, et j'ai fini par comprendre pourquoi certains s'en sortent indemnes quand d'autres plongent. La réponse n'est presque jamais technique au sens strict. Elle est dans les détails qu'on oublie.
Points clés à retenir
- La redirection 301 est le minimum vital, pas la solution complète : encore faut-il qu'elle soit correcte et définitive.
- Migrer tout d'un coup est souvent une erreur. Un découpage par groupes de pages permet de détecter une casse avant qu'elle ne touche tout le site.
- Le contenu mixte (fichiers internes encore appelés en HTTP) est la cause n°1 de mauvaise passe silencieuse.
- Le canal Search Console sert à vérifier, pas à déclarer : ce que vous y envoyez n'accélère rien par magie.
- Sur un e-commerce, la question du crawl budget change complètement la donne.
- Comptez plusieurs semaines d'observation avant de conclure quoi que ce soit sur vos positions.
Pourquoi une migration HTTP vers HTTPS fait perdre du positionnement
La première fois, j'ai cru que c'était Google qui « pénalisait » la migration. Faux. Ce qui pénalise, c'est ce qu'on casse pendant qu'on migre.
Quand un moteur de recherche voit arriver une URL qu'il ne connaît pas encore (la version HTTPS), il doit la traiter comme une page nouvelle. Il la recrawle, la réévalue, la replace dans son index. Si votre redirection est propre, il transfère les signaux de la vieille URL vers la nouvelle. Si elle ne l'est pas, il voit deux pages concurrentes qui se disputent le même contenu, ou pire, il tombe sur des erreurs.
Le problème ? Presque personne ne vérifie que la redirection fonctionne vraiment. On la pose, on se dit que c'est bon, on attend. Et là, surprise : une partie des URLs ne redirige pas parce qu'elles avaient des paramètres, ou parce qu'un plugin les interceptait avant la règle serveur.
Le vrai coupable n'est pas HTTPS
Dans 8 cas sur 10 que j'ai traités, la chute venait d'un seul truc : le contenu mixte. Vous passez en HTTPS, mais des images, des scripts, des polices ou des fichiers CSS continuent d'être appelés en http:// dans votre code. Le navigateur bloque ces ressources. La page se charge mal, lentement, ou affiche un cadenas cassé.
Et un moteur de recherche, lui, note cette dégradation. Pas parce qu'il déteste le HTTP, mais parce que votre page est devenue objectivement moins bonne à afficher.
La bonne nouvelle : ce point précis est très bien documenté, et facile à auditer avec un outil de développeur. La mauvaise nouvelle : personne ne le fait avant de basculer.
Préparer la migration HTTPS sans casser son référencement
Il y a une phase qu'on saute systématiquement parce qu'elle semble inutile. C'est celle qui sauve le plus de trafic.
Avant de toucher à la production, dupliquez votre site sur un environnement de test et migrez cette copie en HTTPS. Vous y verrez en clair tout ce qui ne fonctionne plus : les appels HTTP oubliés, les formulaires qui refusent d'envoyer, les redirections mal ordonnées. Une heure passée sur la préproduction m'a épargné, une fois, un désastre de deux semaines.
La checklist que je fais avant chaque bascule
Ce n'est pas exhaustif, mais ça couvre l'essentiel :
- Crawler le site en préprod pour identifier les ressources internes encore en HTTP.
- Vérifier que la balise canonique pointe bien vers la version HTTPS, sur chaque modèle de page (article, catégorie, produit, page statique).
- Contrôler le fichier sitemap : il doit lister les URLs HTTPS, pas les anciennes.
- Décider du type de redirection. 301, définitive. Jamais de 302, jamais de chaîne de redirections (A vers B vers C, c'est un coup à perdre tout le jus en route).
- Anticiper le HSTS si votre hébergeur le propose, mais ne l'activez pas tout de suite. On y revient.
Faut-il migrer tout le site d'un coup ?
Non. Et je vais défendre cette position fort : sur tout site de plus de quelques centaines de pages, la migration en un bloc est un pari inutile.
Migrez par lots. Commencez par les pages les moins stratégiques : mentions légales, pages annexes, articles anciens qui ne génèrent presque aucun trafic. Observez pendant une à deux semaines. Si rien ne s'effondre, montez d'un cran. Gardez les pages à fort trafic (accueil, pages catégorie principales, articles piliers) pour la fin, quand vous avez la preuve que le reste tient.
Le bénéfice est simple : si quelque chose casse, vous le voyez sur un périmètre réduit, et vous pouvez revenir en arrière sans avoir sacrifié vos pages les plus rentables.
Ce que personne ne dit sur le crawl budget et les performances
Changer de protocole, ce n'est pas juste changer une lettre dans l'URL. C'est demander à un moteur de recherche de traiter l'intégralité de votre site comme du contenu frais. Chaque URL doit être revisitée, réévaluée, réindexée.
Sur un site de 500 pages, ce coût de recrawl passe sans problème. Sur un catalogue de 50 000 produits, c'est une autre affaire. Le robot consacre un budget de crawl limité, et il va le répartir entre vos nouvelles URLs et tout le reste. Résultat possible : certaines pages restent bloquées dans l'ancienne version beaucoup plus longtemps que prévu.
Ma règle, sur les gros volumes : ne pas migrer plus de 20 à 25 % des URLs en même temps, et espacer les lots de deux semaines minimum. Entre chaque vague, je jette un œil aux statistiques d'exploration pour vérifier que le robot traite bien les nouvelles pages.
| Type de site | Approche recommandée | Durée d'observation par lot |
|---|---|---|
| Blog, moins de 200 pages | Migration globale possible | 2 à 3 semaines après bascule |
| Site vitrine, 200 à 1 000 pages | Deux ou trois lots | 2 semaines entre chaque lot |
| E-commerce, plus de 5 000 URLs | Lots de 20 % maximum | 3 semaines et plus |
| Plateforme à très gros volume | Migration progressive étalée sur plusieurs mois | Surveillance continue |
L'effet HSTS sur la latence perçue
Un mot sur le HSTS (HTTP Strict Transport Security), parce qu'on le présente souvent comme un interrupteur magique. Il dit au navigateur « à partir de maintenant, ce site ne se charge qu'en HTTPS ». Une fois activé, le navigateur ne redemande plus la version HTTP, donc une requête en moins à chaque visite, donc un aller-retour réseau économisé.
Le piège : c'est irréversible côté navigateur. Si vous vous trompez en l'activant, ou si une page critique n'est pas prête, vous ne pouvez plus revenir en arrière pour vos visiteurs déjà passés dessus. Je le réserve à la fin de migration, une fois tout vérifié, jamais avant.
Comment suivre l'efficacité de la migration
Le suivi, c'est là que la plupart des gens abandonnent. Ils regardent les positions tous les jours, paniquent, changent quelque chose, et rendent le diagnostic impossible.
Ce qu'il faut regarder, et dans quel ordre :
- La bonne prise en compte des URLs HTTPS dans l'index, sur un échantillon de pages que vous suivez manuellement. Le canal d'inspection d'URL dans Search Console fait ça très bien, page par page.
- Le rapport sur les erreurs d'exploration : toute URL HTTPS qui renvoie une erreur est une fuite à colmater immédiatement.
- Le trafic organique, agrégé par groupe de pages, pas page par page. Une page isolée peut fluctuer sans signification ; un groupe, non.
- Les positions moyennes, mais avec un délai. Les premiers jours après migration ne veulent rien dire.
Mon repère personnel : si après trois semaines le trafic n'est pas revenu à son niveau d'avant, avec une tolérance de 10 %, il y a un problème à chercher. Pas à attendre.
Faut-il soumettre le nouveau sitemap à Search Console ?
Oui, soumettez-le. Mais comprenez ce que ça fait : c'est une déclaration d'intention, pas un coup d'accélérateur. Le robot prendra connaissance des nouvelles URLs, il ne va pas pour autant les traiter en priorité absolue. Cette action aide à la découverte, elle n'accélère pas le transfert des signaux.
Le vrai geste utile, en parallèle, c'est de s'assurer qu'aucune page du site ne pointe encore, en interne, vers une version HTTP par un lien dur. Un lien interne en HTTP, c'est un signal qui dit au robot « cette vieille adresse compte encore ».
Combien de temps faut-il pour récupérer ses positions ?
Comptez trois à six semaines dans le meilleur des cas, plusieurs mois si le site est volumineux ou si une erreur a été commise. Et il y a un détail qu'on oublie : les positions récupérées ne sont pas toujours identiques. Sur les requêtes très concurrentielles, un déplacement de quelques crans peut persister, parce que la page HTTPS est traitée comme une page rafraîchie, et le moteur en profite pour tout réévaluer.
Le cas WordPress et les pièges qui viennent avec
Sur WordPress, la migration est plus simple en surface, mais elle cache deux ou trois bombes à retardement.
Le réglage général d'abord : changer l'adresse du site de http:// à https:// dans les paramètres. Facile. Sauf que si vous le faites avant que le certificat soit actif, vous vous retrouvez enfermé dehors. J'ai fait cette erreur une fois, en pleine soirée, sur le site d'un client. Le temps de comprendre, j'ai bien cru que j'allais devoir tout restaurer.
Ensuite, la base de données. Toutes les URLs codées en dur dans le contenu des articles, dans les champs personnalisés, dans les options d'un builder, ne changent pas avec le réglage général. Il faut les mettre à jour autrement, avec précaution, jamais à l'aveugle. Un remplacement de masse mal fait casse des données sérialisées, et là, c'est la restauration complète.
Enfin, les plugins de cache et de redirection. Beaucoup posent leurs propres règles, qui entrent en conflit avec celle du serveur. Résultat : des redirections en boucle, ou des pages qui ne redirigent jamais. Testez toujours vos règles réelles, sur les vraies URLs, une par une si nécessaire.
Ce qu'il faut vraiment retenir
Migrer un site HTTP vers HTTPS n'a jamais été un problème de certificat. Le certificat, c'est la partie simple. Ce qui décide si vous gardez votre positionnement ou non, c'est la rigueur de la préparation, le découpage de la bascule, et l'honnêteté avec laquelle vous auditez ce que vous avez cassé.
Je dirais même plus : la meilleure migration que j'aie faite, celle qui n'a pas bougé d'un cran dans les résultats, est aussi celle où j'ai passé le plus de temps à ne rien migrer. Trois semaines à préparer, tester, vérifier. La bascule elle-même a pris une heure.
Le paradoxe, c'est que tout le monde veut aller vite. Et c'est exactement ce qui met les sites par terre.
