Quand un client me contacte parce que son navigateur affiche « Non sécurisé » à côté de l'adresse de son site, la question du passage en WordPress HTTPS arrive vite sur la table. Ce petit cadenas manquant n'est pas qu'un détail cosmétique : il pèse sur la confiance des visiteurs, sur les taux de conversion et, depuis plusieurs années, sur le référencement. En tant que consultant SEO et formateur à Arras, j'accompagne régulièrement des sites qui doivent basculer de HTTP vers HTTPS, et j'ai constaté que cette opération se passe très bien quand elle est méthodique, et très mal quand elle est bâclée. Dans cet article, je vous détaille la procédure complète que j'applique pour migrer un site WordPress en HTTPS proprement, sans perdre le trafic organique durement acquis.
Je vais volontairement rester concret. Vous trouverez ici les étapes de préparation, l'installation du certificat, la correction des contenus mixtes, le remplacement des URL en base et la mise en place des redirections. L'objectif est simple : que vous compreniez chaque geste, plutôt que de cliquer aveuglément sur un bouton en priant pour que tout se passe bien.
Pourquoi le passage en WordPress HTTPS n'est plus une option
Le protocole HTTPS chiffre les échanges entre le navigateur du visiteur et votre serveur. Cela empêche qu'un intermédiaire malveillant lise ou modifie les données qui circulent : formulaires de contact, identifiants de connexion, informations de paiement. Sur un site WordPress, où l'on se connecte régulièrement à un back-office, cette protection est loin d'être accessoire. Sans elle, vos identifiants d'administration peuvent transiter en clair.
Au-delà de la sécurité, il y a l'affichage. Les navigateurs modernes signalent désormais les pages en HTTP comme « non sécurisées ». Pour un internaute qui découvre votre site, ce message est anxiogène : il crée un doute au moment précis où vous cherchez à instaurer la confiance. J'ai vu des pages de contact perdre en performance à cause de cet avertissement. Le HTTPS est aujourd'hui un standard attendu, au même titre qu'un site qui s'affiche correctement sur mobile.
Enfin, côté référencement, Google a annoncé de longue date que le HTTPS constitue un signal positif, même s'il reste léger comparé au contenu ou aux liens. Le vrai enjeu SEO n'est donc pas tant le gain du HTTPS que la manière dont vous menez la migration. Une bascule mal préparée génère des erreurs, des boucles de redirection ou des contenus mixtes qui, eux, peuvent réellement dégrader votre visibilité. C'est tout l'objet de la méthode que je vais partager, et c'est le cœur de mon travail d'expert SEO au quotidien.
Étape 1 : préparer la migration avant de toucher au certificat
La précipitation est la première cause d'échec. Avant même de penser au certificat SSL, je prends toujours le temps de préparer le terrain. La première précaution est évidente mais trop souvent négligée : réaliser une sauvegarde complète du site, à la fois les fichiers et la base de données. Une migration HTTPS touche des données sensibles, notamment les URL stockées en base. Si quelque chose se passe mal, vous devez pouvoir revenir en arrière en quelques minutes.
Ensuite, je dresse un inventaire. Je note l'adresse actuelle du site, la présence ou non d'un CDN, les scripts externes chargés (widgets, polices, cartes, systèmes de statistiques), et les éventuels liens codés en dur dans le thème ou dans des blocs personnalisés. Ce recensement me permet d'anticiper les points qui risquent de rester en HTTP après la bascule. Je vérifie aussi la version de WordPress et des extensions : une migration est le mauvais moment pour découvrir qu'un plugin critique n'est plus maintenu.
Je recommande également de choisir un créneau calme pour l'opération, en dehors des pics de trafic, et de garder sous la main l'accès à l'hébergement (panel, FTP, base de données) car la bascule ne se fait pas uniquement depuis l'administration WordPress. Cette phase paraît fastidieuse, mais c'est elle qui transforme une migration stressante en une formalité maîtrisée. Si votre site a été construit sans réelle vision de sa maintenance, c'est aussi l'occasion de repenser sa base : je traite ce sujet dans mes accompagnements autour de la création de site internet WordPress.

Étape 2 : obtenir et installer le certificat SSL
Le certificat SSL est ce qui permet techniquement le chiffrement et l'affichage du fameux cadenas. Aujourd'hui, la plupart des hébergeurs proposent des certificats gratuits, souvent via l'autorité Let's Encrypt, directement activables depuis leur panneau de gestion. Dans la majorité des cas, l'installation se résume à quelques clics dans l'interface de l'hébergeur, qui se charge du renouvellement automatique. C'est la voie que je privilégie pour un site vitrine ou un blog classique.
Après activation, la première vérification consiste à taper l'adresse de votre site en préfixant par https:// dans le navigateur. Si le certificat est correctement installé, la page se charge et le cadenas apparaît. À ce stade, votre site est accessible en HTTPS, mais il reste aussi accessible en HTTP : rien n'est encore terminé. Beaucoup de personnes s'arrêtent ici en croyant la migration faite, et c'est précisément là que naissent les problèmes de contenus mixtes et de duplication d'adresses.
Je contrôle aussi que le certificat couvre bien la bonne variante du domaine. Un site accessible avec et sans « www » a besoin que le certificat prenne en compte ces deux formes ; un simple test dans le navigateur sur chaque variante permet de repérer un avertissement. Ce contrôle évite de découvrir, une fois la migration lancée, qu'une partie des visiteurs tombe sur une alerte de sécurité. La rigueur sur cette étape est indissociable d'une bonne stratégie de référencement : un certificat mal configuré peut faire fuir aussi bien les internautes que les robots.
Étape 3 : mettre à jour les adresses dans WordPress
Une fois le certificat en place, il faut indiquer à WordPress que son adresse officielle est désormais en HTTPS. Le réglage le plus visible se trouve dans le menu Réglages puis Général de l'administration : les deux champs « Adresse web de WordPress » et « Adresse web du site » doivent passer de http:// à https://. C'est une action simple, mais elle a un effet immédiat sur la façon dont WordPress construit ses liens internes et ses ressources.
Attention toutefois : modifier ces champs suffit pour les nouvelles pages générées, mais ne corrige pas les anciennes URL déjà enregistrées dans le contenu de vos articles, dans vos images ou dans vos réglages d'extensions. C'est pour cela que cette étape ne peut pas rester isolée. Elle doit être suivie du remplacement des URL en base de données, que j'aborde juste après.
Sur certaines configurations, l'adresse du site est définie directement dans le fichier de configuration de WordPress, ce qui grise les champs dans l'administration. La modification se fait alors dans ce fichier, sur le serveur. Je vérifie toujours ce point, car une valeur figée dans le code prendra le dessus sur ce que vous saisissez dans l'interface. La gestion fine de ces réglages fait partie des bases que j'enseigne dans mes formations autour de WordPress.
Étape 4 : remplacer les URL en base de données
C'est le cœur technique de la migration, et l'étape que je vois le plus souvent mal réalisée. Pendant toute la vie du site en HTTP, chaque image insérée, chaque lien interne, chaque référence dans un widget a enregistré une adresse commençant par http://. Ces adresses sont stockées dans la base de données. Si vous ne les remplacez pas, vos pages en HTTPS continueront d'appeler des ressources en HTTP, ce qui provoque les fameux contenus mixtes.
Le remplacement consiste à parcourir la base et à substituer les anciennes adresses par leurs équivalents en HTTPS. Une extension de recherche-remplacement dédiée fait ce travail proprement, en gérant correctement les données sérialisées, ces structures particulières que WordPress utilise pour stocker certains réglages et qui se corrompent si on les modifie à la main. C'est un point crucial : un simple remplacement brutal dans la base, sans outil adapté, peut casser des réglages de thème ou d'extension. C'est aussi pour cela que la sauvegarde préalable prend tout son sens.
Après le remplacement, je vide systématiquement les caches : cache de WordPress, cache des extensions d'optimisation, et cache du navigateur pour mes tests. Un cache non vidé fait croire à un problème persistant alors que la correction est déjà effective. Je recharge ensuite plusieurs pages types du site pour vérifier que les images et les liens pointent bien vers des adresses sécurisées. Ce contrôle visuel, combiné à l'inspection de l'étape suivante, me donne une vision fiable de l'état réel de la migration.
Étape 5 : traquer et corriger les contenus mixtes
Un contenu mixte apparaît lorsqu'une page servie en HTTPS charge malgré tout une ressource en HTTP : une image, un script, une feuille de style, une police. Le navigateur, par sécurité, peut alors bloquer cette ressource ou dégrader l'affichage du cadenas. Résultat : le site paraît « à moitié sécurisé », ce qui envoie un mauvais signal aussi bien aux visiteurs qu'aux moteurs de recherche.
Pour les détecter, j'utilise la console du navigateur, accessible via les outils de développement. Elle liste précisément les ressources chargées en HTTP sur une page HTTPS, avec un message d'avertissement explicite. Je passe en revue les pages représentatives du site : accueil, page de contact, articles de blog, pages produits le cas échéant. Souvent, l'origine du problème est identifiable immédiatement : une bannière, un widget de réseau social, une carte intégrée ou une police externe appelée en HTTP.
La correction dépend de la source. Pour un contenu géré dans WordPress, le remplacement en base a normalement déjà réglé le cas. Pour un élément codé en dur dans le thème ou dans un script externe, il faut modifier l'appel pour qu'il utilise HTTPS. Je vérifie alors que le service tiers concerné propose bien une version sécurisée, ce qui est presque toujours le cas aujourd'hui. Cette chasse demande de la patience, mais elle est indispensable pour obtenir un cadenas pleinement valide sur l'ensemble du site.
Étape 6 : mettre en place les redirections 301
À ce stade, votre site fonctionne en HTTPS, mais il reste techniquement accessible en HTTP. Cela signifie que chaque page existe potentiellement en deux versions, ce qui est problématique pour le référencement : les moteurs voient de la duplication et ne savent pas quelle version privilégier. La solution est la redirection permanente, dite redirection 301, qui envoie automatiquement tout visiteur et tout robot de la version HTTP vers la version HTTPS correspondante.
Cette redirection se met généralement en place au niveau du serveur, dans le fichier de configuration du site. Elle force l'ensemble du trafic vers HTTPS, page par page, en conservant le chemin d'origine. L'intérêt du code 301 est qu'il indique aux moteurs de recherche que le changement est définitif : ils transfèrent alors progressivement la valeur SEO des anciennes adresses HTTP vers les nouvelles adresses HTTPS. C'est ce mécanisme qui préserve votre positionnement.
Après la mise en place, je teste plusieurs adresses en tapant volontairement la version HTTP pour vérifier qu'elle bascule bien vers HTTPS. Je m'assure aussi de l'absence de boucle de redirection, ce comportement où le navigateur tourne en rond et finit par afficher une erreur. Ce risque existe notamment quand une redirection est configurée à plusieurs endroits à la fois, par exemple au niveau du serveur et via une extension. Un seul point de redirection, propre et unique, est toujours préférable à une accumulation de règles qui se contredisent.
Récapitulatif des étapes et points de contrôle
Pour garder une vision claire de l'ensemble, voici le tableau de synthèse que je reprends avec mes clients. Il résume la séquence et, surtout, le point de contrôle qui confirme que chaque étape est réellement terminée. Je vous conseille de ne jamais passer à l'étape suivante tant que le contrôle de l'étape en cours n'est pas validé.
| Étape | Action principale | Point de contrôle |
|---|---|---|
| 1. Préparation | Sauvegarde complète et inventaire des ressources externes | Sauvegarde fichiers + base restaurable, liste des scripts tiers établie |
| 2. Certificat SSL | Activer le certificat chez l'hébergeur | La page s'ouvre en https:// avec le cadenas, sur www et sans www |
| 3. Réglages WordPress | Passer les deux adresses du site en https:// | Les champs Général affichent https:// (ou le fichier de config est à jour) |
| 4. Remplacement des URL | Substituer les http:// par https:// en base de données | Images et liens internes pointent vers des adresses sécurisées, caches vidés |
| 5. Contenus mixtes | Détecter et corriger les ressources restées en HTTP | Aucun avertissement de contenu mixte dans la console du navigateur |
| 6. Redirections 301 | Forcer HTTP vers HTTPS au niveau du serveur | Toute adresse HTTP bascule en HTTPS, sans boucle de redirection |
Les vérifications SEO après la migration
Une fois la bascule terminée, le travail n'est pas totalement fini. Je considère qu'une migration HTTPS réussie se juge dans les jours et les semaines qui suivent, pas seulement le jour J. La première action est de déclarer la version HTTPS du site dans les outils de suivi de Google, notamment la Search Console, où le HTTP et le HTTPS sont traités comme des propriétés distinctes. Sans cette déclaration, vous perdez la visibilité sur les performances réelles de votre nouvelle version.
Je surveille ensuite l'indexation : je vérifie que les pages en HTTPS apparaissent progressivement dans les résultats et que les anciennes adresses HTTP se effacent au profit des nouvelles. Je contrôle aussi le fichier des règles d'exploration et le plan du site pour m'assurer qu'ils référencent bien les adresses sécurisées. Un plan de site qui pointe encore vers du HTTP envoie un signal contradictoire aux moteurs.
Enfin, je garde un œil sur les statistiques de trafic. Une légère fluctuation dans les premiers jours est normale, le temps que les moteurs digèrent la migration. En revanche, une chute franche et durable est le signe d'un problème à investiguer : redirection mal configurée, contenus mixtes persistants ou pages orphelines. Savoir distinguer une variation banale d'un vrai symptôme évite autant les paniques inutiles que les négligences coûteuses, et c'est là que l'expérience fait la différence.
Les erreurs que je vois le plus souvent
Au fil des accompagnements, certaines erreurs reviennent avec une régularité frappante. La plus fréquente est de croire que l'installation du certificat suffit. Comme je l'ai expliqué, le certificat n'est que la première brique : sans remplacement des URL et sans redirections, le site reste bancal. La deuxième erreur classique est le remplacement brutal des adresses directement dans la base, sans outil gérant les données sérialisées, ce qui casse des réglages et génère des dysfonctionnements difficiles à diagnostiquer.
J'observe aussi beaucoup de redirections en double, configurées simultanément par une extension et par le serveur, sources de lenteurs et de boucles. À l'inverse, certains oublient complètement les redirections et laissent leur site accessible dans les deux protocoles pendant des mois, créant une duplication qui brouille le référencement. Enfin, l'oubli d'une ressource tierce codée en dur, comme une police appelée en HTTP, laisse subsister des contenus mixtes que le propriétaire ne remarque pas, faute de regarder la console de son navigateur.
La bonne nouvelle, c'est que chacune de ces erreurs est évitable avec la méthode décrite ici. Le passage en HTTPS n'a rien d'insurmontable : il demande simplement de la rigueur, de suivre les étapes dans l'ordre et de valider chaque point de contrôle avant d'avancer. C'est exactement cette discipline qui sépare une migration invisible pour vos visiteurs d'une migration qui laisse des traces dans vos statistiques.
Conclusion
Migrer un site WordPress en HTTPS est aujourd'hui incontournable, autant pour la sécurité de vos visiteurs que pour la crédibilité de votre marque et la solidité de votre référencement. Comme vous l'avez vu, la réussite ne tient pas à un bouton magique mais à un enchaînement d'étapes maîtrisées : préparation et sauvegarde, installation du certificat, mise à jour des réglages, remplacement des URL en base, chasse aux contenus mixtes et redirections 301 propres. Chaque étape a son point de contrôle, et c'est le respect de cet ordre qui garantit une bascule sans perte de trafic.
Si vous préférez confier cette opération à quelqu'un qui l'a menée de nombreuses fois, ou si vous voulez simplement un regard extérieur pour valider votre migration, je peux vous accompagner. Que ce soit pour sécuriser un site vitrine, une boutique ou un blog à fort trafic, l'important est de le faire proprement du premier coup. Contactez-moi pour échanger sur votre projet et faisons en sorte que votre passage en HTTPS soit une formalité plutôt qu'une source d'inquiétude.