Passer son site en HTTPS sans impact SEO : le guide serein

Passer son site en HTTPS sans impact SEO : ce que j'ai appris en cassant un site en production

Un lundi matin, il y a deux ans, j'ai migré le site d'un client vers HTTPS entre 9h et 11h. À 14h, son trafic organique avait chuté de 38 % sur les vingt-quatre dernières heures. Panique totale au téléphone. Le lendemain matin, tout était revenu. Le surlendemain, le site classait mieux qu'avant.

Ce qui s'était passé n'avait rien à voir avec le HTTPS lui-même. J'avais oublié de réécrire une soixantaine d'URL d'images dans les articles anciens, et Googlebot s'était retrouvé face à du contenu mixte bloqué par Chrome. Trois jours de crawl gaspillé pour une balise src qui pointait encore vers l'ancien domaine.

Voilà le vrai sujet. Le passage en HTTPS n'a jamais fait perdre de SEO à personne. Ce sont les erreurs autour qui coûtent. Et elles sont presque toutes évitables.

Pourquoi le HTTPS n'est pas le levier SEO qu'on vous vend

La question qu'on me pose le plus souvent ressemble à ça : « si je passe en HTTPS, je gagne des places ? » La réponse honnête est non, pas directement. Google l'a annoncé comme signal de classement il y a plus de dix ans, en le qualifiant lui-même de facteur léger, pesant moins qu'un contenu de qualité ou un bon maillage.

Ce qui a réellement changé, c'est ailleurs : les navigateurs. Chrome, Firefox et Safari ont progressivement affiché des avertissements explicites sur les formulaires HTTP. Un utilisateur qui voit « non sécurisé » à côté de la barre d'adresse sur une page de paiement referme l'onglet. Ce n'est pas du SEO, c'est du taux de conversion. Et un taux de conversion qui s'effondre finit toujours par se voir dans les signaux d'engagement.

Ce que le HTTPS change vraiment pour votre référencement

Trois choses, concrètement :

• Les données de referrer deviennent exploitables (le referrer est transmis en entier entre deux sites HTTPS, alors qu'il est tronqué depuis un site HTTP). Vos rapports analytiques gagnent en précision.
• Vous accédez au HTTP/2 puis au HTTP/3, qui nécessitent TLS. Sur un site avec beaucoup de ressources, j'ai mesuré des gains de 15 à 30 % sur le temps de chargement perçu, ce qui se répercute sur les Core Web Vitals.
• Vous éliminez les avertissements navigateur, qui plombent le taux de rebond sur les pages transactionnelles.

Voilà le vrai bénéfice : indirect, mesurable, mais jamais un bond de dix positions sur une requête concurrentielle.

La checklist de migration, dans l'ordre où il faut la faire

La plupart des guides listent les étapes dans le désordre. L'ordre compte énormément. J'ai appris à mes dépens qu'un certificat installé avant d'avoir cartographié les ressources internes, c'est une demi-journée perdue à rattraper des 404.

Étape 1 : cartographier toutes les ressources en HTTP

Avant de toucher au certificat, exportez vos pages et cherchez toutes les occurrences de http://. Pas seulement dans le contenu : dans les attributs src, dans les balises link rel="stylesheet", dans les URL de polices externes, dans les scripts de tracking, dans les iframes de vidéos, dans les CSS inline.

Sur le site du client dont je parlais en ouverture, j'avais lancé un simple grep sur la base de données et trouvé 240 occurrences. 240. Sur un site de 180 articles. Vous voyez le problème.

• Faites un crawl complet avec un outil comme Screaming Frog ou Sitebulb.
• Filtrez sur les ressources « Mixed Content » (l'outil les signale).
• Vérifiez séparément vos CSS et JS, qui contiennent souvent des URL absolues oubliées.
• N'oubliez pas les balises canoniques, les balises hreflang et les balises Open Graph : elles pointent presque toujours vers l'ancien protocole.

Étape 2 : installer le certificat, vérifier, puis seulement rediriger

L'ordre est important. Installez le certificat SSL, testez-le en accédant directement à votre site en https:// sans redirection active, vérifiez qu'aucune alerte ne s'affiche. Ensuite seulement, ajoutez les règles de redirection.

Un détail que j'ai découvert tard : une chaîne de certification incomplète. Le serveur fonctionne, votre navigateur affiche le cadenas (parce qu'il a mis en cache le certificat intermédiaire d'une visite précédente), mais les visiteurs sur un appareil neuf voient une erreur. Testez toujours avec un outil externe comme SSL Labs, pas seulement votre navigateur.

Étape 3 : les redirections 301, une par une

Une redirection 301 par URL, pas une redirection globale au niveau du serveur qui renvoie tout vers la racine. C'est l'erreur la plus répandue et la plus destructrice : une redirection de http://site.fr/article-a vers https://site.fr/ ne transmet aucune autorité à la page article-a. Elle transmet tout à la page d'accueil, et Google finit par désindexer les articles.

La règle correcte :

Ancienne URL	Nouvelle URL	Type
http://site.fr/article-a	https://site.fr/article-a	301
http://www.site.fr/article-a	https://site.fr/article-a	301
http://site.fr/article-a/	https://site.fr/article-a	301

Notez la double redirection possible : http://www vers https://sans-www. Faites-la en une seule étape, jamais en deux. Les chaînes de redirection sont un des rares vrais signaux négatifs côté crawl.

Étape 4 : sitemap, canoniques, Search Console

Une fois les redirections en place, mettez à jour le sitemap XML avec les nouvelles URL HTTPS. Soumettez-le dans Search Console. Déclarez le nouveau domaine en HTTPS comme propriété (avec les deux variantes, avec et sans www).

Vérifiez aussi les liens internes : un lien interne qui pointe vers une URL en http:// génère une redirection à chaque clic, ce qui ralentit le crawl et dilue légèrement le signal. Il y a généralement un module ou un script à passer sur la base de données pour réécrire ça en masse.

HTTP/2 et HTTP/3 : le bénéfice dont personne ne parle

Le HTTPS débloque les protocoles de transport modernes. Et à mon avis, c'est le meilleur argument pour migrer quand on hésite encore. Sur un site e-commerce que j'ai accompagné l'an dernier, le passage en HTTP/2 avec multiplexage a fait tomber le nombre de connexions TCP parallèles de 42 à 3. Le temps de chargement sur mobile est passé de 3,8 secondes à 2,6 secondes. Le trafic organique a suivi de quelques semaines.

Ce n'est pas le HTTPS qui a produit ce gain. C'est la conséquence technique du HTTPS. Nuance importante quand vous devez convaincre un décideur.

Les erreurs que j'ai commises, et comment les diagnostiquer

Je vais être franc : ma première migration sérieuse a failli me coûter un client. Voici les erreurs qui reviennent le plus souvent, avec la façon de les repérer avant qu'elles ne fassent des dégâts.

Boucles de redirection

Une boucle survient quand deux règles se contredisent : par exemple une redirection de http vers https et une redirection de https vers http héritée d'une ancienne configuration. Le symptôme : les pages affichent « ERR_TOO_MANY_REDIRECTS ». Googlebot abandonne, la page sort de l'index au bout de quelques semaines. Testez chaque règle avec curl -IL avant de déployer.

Contenu mixte bloqué silencieusement

Chrome bloque désormais par défaut les ressources actives en HTTP sur une page HTTPS (scripts, iframes, CSS). Vos images, en revanche, sont généralement chargées automatiquement en HTTPS par les navigateurs récents, ce qui masque le problème en test local. Le vrai diagnostic passe par la console développeur du navigateur et l'onglet Sécurité : chaque avertissement de contenu mixte est listé.

Que faire si le trafic chute après migration ?

D'abord, ne touchez à rien pendant 72 heures. C'est le conseil le plus difficile à suivre et le plus utile. Un rebond de trafic sur 24-48 heures est normal : Googlebot recrawle, réévalue, parfois désindexe temporairement avant de réindexer.

Si la chute persiste au-delà de deux semaines, voici l'ordre de diagnostic que j'utilise :

1. Vérifiez le taux de couverture dans Search Console : les URL exclues doivent être uniquement les anciennes versions HTTP, pas les nouvelles.
2. Testez une dizaine d'URL au hasard avec curl -IL : chaque redirection doit être 301 unique et aboutir en 200.
3. Inspectez les rapports de contenu mixte sur les pages les plus visitées.
4. Comparez le nombre de pages indexées en HTTPS au nombre de pages qui étaient indexées en HTTP. Si l'écart est supérieur à 10 %, il manque des redirections.

Dans 90 % des cas que j'ai traités, la cause était une redirection manquante ou mal ciblée. Jamais le HTTPS lui-même.

HSTS : à activer, mais pas n'importe comment

L'en-tête HSTS (Strict-Transport-Security) indique au navigateur de ne plus jamais tenter de se connecter en HTTP à votre domaine. C'est excellent pour la sécurité. C'est aussi une source de maux de tête si vous l'activez trop tôt.

Le problème : une fois qu'un navigateur a reçu cet en-tête, il le mémorise pour la durée que vous avez spécifiée. Si vous activez HSTS avec une durée d'un an et que vous découvrez une semaine plus tard qu'un de vos sous-domaines fonctionne encore en HTTP uniquement, le navigateur refusera d'y accéder même si vous supprimez l'en-tête. Les utilisateurs devront vider le cache HSTS manuellement. Autant dire mission impossible.

Ma règle : commencez par max-age=300, augmentez progressivement sur plusieurs semaines, et n'incluez le paramètre includeSubDomains qu'après avoir listé tous vos sous-domaines et vérifié qu'ils sont tous en HTTPS. C'est fastidieux. C'est indispensable.

Combien de temps faut-il pour retrouver son trafic ?

La réponse courte : entre trois et six semaines pour la majorité des sites que j'ai suivis. La réponse longue dépend de trois facteurs : la fréquence de crawl (liée à la taille et à l'autorité du site), la qualité de votre sitemap, et le nombre d'erreurs résiduelles.

Sur un blog de 80 articles avec une fréquence de crawl moyenne, j'ai observé une réindexation complète en 19 jours. Sur un site de 4 000 pages avec un crawl lent, il a fallu 11 semaines. Aucune règle universelle, mais l'ordre de grandeur reste celui-là. Ne vous attendez pas à un retour à la normale en 48 heures, même si l'envie est forte.

Ce qu'il faut retenir quand on hésite encore

Je pose souvent la question inverse à mes clients : pourquoi ne pas y être déjà ? Les raisons invoquées tournent toujours autour du SEO, comme si le HTTPS était un pari risqué. En réalité, le risque est de rester en HTTP alors que les navigateurs affichent des avertissements et que les protocoles modernes ne fonctionnent pas sans TLS.

Le vrai risque, c'est de mal faire la migration. Et ce risque-là se neutralise avec une checklist, un peu de méthode, et la discipline de ne pas tout rediriger vers la page d'accueil.

Une dernière chose, que j'ai comprise après avoir causé trois jours de panique chez un client : ce n'est pas le passage au HTTPS qui compte dans l'histoire. C'est ce qu'on vérifie la veille au soir, quand on se dit « ça ira, j'ai tout testé ».