Comment passer son site WordPress en HTTPS ?

Apprenez à passer votre site WordPress en HTTPS en toute sécurité grâce à ce guide complet en 10 étapes simples et sans extension.

Ce tutoriel fait suite au meetup WP Bordeaux du 8 février 2018 qui avait réuni près de 40 personnes. Sur cet échantillon plutôt représentatif, pas une personne ayant basculé en HTTPS ne l’a fait de manière correcte. La plupart du temps les utilisateurs se sont arrêtés à l’activation du SSL côté hébergeur – OVH le fait nativement ce qui peut vous exposer à des situations de contenus dupliqués sur Google.

Ce tutoriel se veut également le plus complet sur la bonne méthode à adopter pour passer proprement un site de HTTP à HTTPS. La quasi-totalité des informations disponibles à ce sujet sont actuellement erronées ou partiellement complètes alors même que les conséquences techniques peuvent être catastrophiques et notamment pour votre référencement.

Notez également que la méthode décrite ici est standardisée pour WordPress, elle ne repose pas sur une extension qui ferait le travail à votre place. Je déconseille fortement le recours à une extension pour réaliser ce type de manipulation et notamment pour des questions de performances.

À quoi sert un certificat SSL ?

C’est sans doute la question que l’on me pose le plus souvent dès lors qu’on évoque ce passage à HTTPS. Nous pouvons dénombrer 3 raisons majeures : la sécurité, le référencement et les prérequis techniques pour WordPress.

Le certificat SSL renforce votre sécurité

Un certificat SSL est ni plus ni moins qu’un fichier de données qui active le protocole HTTPS sur un serveur. Ce protocole assure une connexion sécurisée en chiffrant les échanges entre l’internaute et le serveur. Par exemple, sur votre page de connexion au back-office, un site classique sans chiffrage expose le mot de passe en clair sur le réseau Internet. Vous comprenez dès lors l’importance d’un tel passage en matière de sécurité.

Tous les certificats disposent d’un niveau de sécurité satisfaisant, la différence entre un certificat gratuit et payant est liée aux questions d’assurance (utile pour les sites e-commerce) et à la réputation délivrée par ces derniers.

La présence d’un certificat SSL améliore indirectement votre référencement

C’est également une recommandation officielle de la part de Google qui affiche désormais un avertissement dans son navigateur Chrome pour les sites non sécurisés. Google a même annoncé qu’à partir de la version 154 de Chrome, son navigateur demanderait l’autorisation de l’internaute avant d’ouvrir pour la première fois un site public qui n’utilise pas HTTPS. Disposer d’un site en HTTPS n’améliore pas directement le référencement mais la perception générale que peuvent en avoir vos visiteurs avec la présence d’un cadenas au niveau de la barre d’adresse du navigateur.

WordPress a besoin d’un certificat SSL

Sans certificat, WordPress fonctionne toujours, mais la prise en charge de HTTPS figure parmi les prérequis recommandés par WordPress.org pour héberger un site. L’écran Outils > Santé du site signale d’ailleurs un site qui ne l’utilise pas, et certaines fonctionnalités en dépendent : les mots de passe d’application, qui permettent à un service externe de se connecter à votre site par l’API REST, ne sont disponibles qu’en HTTPS, hors environnement local.

Pour en savoir plus, je vous recommande la lecture de cet article sur l’intérêt de disposer d’un certificat SSL et comment le choisir.

Quelles étapes pour passer en HTTPS ?

Après la théorie, place à la pratique !

Toutes les étapes décrites ci-dessous sont obligatoires, aucune n’est facultative. Il faut compter environ une heure de travail pour les mener à bien en étant à l’aise avec la technique.

Étape n°1 – Sauvegarder votre base de données

Avant même d’aller plus loin, il est fortement recommandé d’effectuer une sauvegarde de votre base de données MySQL ou MariaDB. Elle sera nécessaire en cas de restauration.

Étape n°2 – Déployer un certificat SSL

Rendez-vous chez votre hébergeur qui vous mettra à disposition un certificat gratuit de type Let’s Encrypt. Un certificat Let’s Encrypt est valable 90 jours, et c’est votre hébergeur qui se charge de le renouveler automatiquement. Pour un site e-commerce, je préconise l’achat d’un certificat qui embarquera une assurance. Payant ou non, un certificat émis depuis le 15 mars 2026 ne peut toutefois plus dépasser 200 jours de validité, une durée maximale qui passera à 100 jours en mars 2027 puis à 47 jours en mars 2029, selon les exigences du CA/Browser Forum : assurez-vous que son renouvellement est automatisé.

En règle générale, la génération d’un SSL gratuit s’opère par simple clic. Vérifiez que ce dernier n’est pas déjà actif : chez OVHcloud, par exemple, le certificat Let’s Encrypt, et donc le HTTPS, est activé par défaut depuis le 6 août 2025 pour tout nouveau nom de domaine ou sous-domaine associé à un hébergement web. Cela peut avoir pour conséquence de dupliquer votre site sur les moteurs de recherche si vous ne procédez pas aux étapes qui suivent. Un cas d’école constaté à maintes reprises lors d’audits de sites WordPress que je réalise régulièrement.

Une fois le certificat actif, saisissez l’URL de votre site dans votre navigateur favori en ajoutant https:// juste devant le nom de domaine. La page doit s’afficher sans alerte de sécurité. S’il y manque des images, des styles ou des scripts, il s’agit probablement de contenu mixte, ce que nous verrons à l’étape n°6.

Étape n°3 – Rediriger le trafic vers HTTPS

Pour l’instant, nous avons donc un site accessible de 2 façons : en HTTP ou en HTTPS. Il nous faut conserver une seule variante de sorte que les visiteurs et les robots de Google soient orientés vers la bonne version sécurisée.

Nous allons avoir recours aux traditionnelles redirections de type 301, celles qui permettent d’indiquer de manière seo-friendly l’URL permanente d’un nouveau contenu. Il va de soi que nous n’allons pas poser autant de 301 qu’il y a de contenus sur votre site, ce serait interminable et contre-productif.

Ouvrez simplement le fichier .htaccess situé à la racine de votre site et ajoutez les lignes suivantes tout en haut, avant le bloc # BEGIN WordPress : placées après lui, elles ne redirigeraient plus les adresses de vos articles et de vos pages.

# BEGIN Redirect HTTP to HTTPS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://wpchannel.com/$1 [R=301,L]
</IfModule>
# END Redirect HTTP to HTTPS

Prenez soin de remplacer le nom de domaine par le vôtre. Il existe une alternative pour détecter automatiquement le domaine mais il me semble plus fiable et performant de l’indiquer directement.

Si votre site tourne sous nginx, le fichier .htaccess n’est pas lu : la redirection se déclare dans la configuration du serveur, avec un bloc server dédié au port 80, ou depuis l’interface de votre hébergeur s’il gère cette configuration pour vous. Là encore, remplacez example.com par votre domaine :

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Retournez à présent dans votre navigateur Web et actualisez la page : vous serez redirigé automatiquement vers la version HTTPS. Ceci est valable pour l’ensemble des URLS de ce domaine, faites donc le test en ouvrant une page de votre site. Remplacez le https:// par http:// et constatez la redirection vers l’équivalent HTTPS. Magique non ?

Grâce à cette technique, les moteurs de recherche remplaceront progressivement vos anciennes adresses par les nouvelles. Comptez tout de même quelques semaines, voire davantage, pour un site de taille moyenne, selon la documentation de Google sur les déplacements de site.

Étape n°4 – Réécrire les URLS en base de données

WordPress stocke les URLS présentes dans vos contenus en chemin absolu. En termes clairs, si vous faites un lien dans le corps de texte d’une page vers une autre page, l’URL du lien est entière. Il nous faut donc les modifier en masse de sorte que http:// soit remplacé par https:// à l’aide d’un script spécialisé comme Search Replace DataBase.

Les techniques manuelles consistant à rechercher / remplacer les URLS directement dans un éditeur de code sont à proscrire car vous ne pouvez gérer les données sérialisées. Ce type de données sont très utilisées dans les constructeurs de pages par exemple.

Ce script gratuit est généralement utilisé pour modifier l’adresse d’un site et trouve aussi son utilité pour le passage à HTTPS.

Téléchargez-le à l’aide du lien ci-dessous, décompressez l’archive puis envoyez le dossier à la racine Web de votre serveur :

Exécutez le script dans le navigateur en saisissant le nom du dossier à la suite de votre domaine. Pour ma part, je l’ai nommé srdb ce qui donne example.com/srdb pour atteindre la page du script.

Renseignez d’abord les accès à votre base de données dans les champs database name, username, pass et host : vous les trouverez dans votre fichier wp-config.php (constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST), car le script ne les remplit plus de lui-même depuis sa version 4.1. Cliquez ensuite sur Test connection.

Dans le champ replace, saisissez l’URL sous la forme http://example.com et https://example.com dans le champ with. Rappelez-vous la chose suivante : nous remplaçons uniquement la partie qui change. Il n’y a donc pas à se poser la question de la présence ou non d’un slash à la fin.

Dans le champ columns to exclude, saisissez guid : la documentation de WordPress demande de ne jamais modifier cette colonne, qui permet aux lecteurs de flux RSS de reconnaître les articles déjà publiés.

Cliquez ensuite sur Do a safe test run pour effectuer un test. Une liste d’éléments sera alors disponible table par table vous permettant de vérifier que tout fonctionne parfaitement.

Si les tests sont concluants, cliquez sur Search and Replace pour procéder aux remplacements. Une fois les changements opérés, cliquez sur delete me pour supprimer le script du serveur ou faites le manuellement à l’aide de votre client FTP favori. Il ne faut jamais laisser ce genre de script sur votre serveur par mesure de sécurité.

Cette étape devrait régler la quasi-totalité des problématiques de contenus mixtes dans vos pages.

Vous pouvez aussi préférer le recours à la ligne de commande avec WP-CLI qui fonctionnera de manière optimale : la commande wp search-replace gère elle aussi les données sérialisées. Lancez-la d’abord avec l’option --dry-run, qui affiche le nombre de remplacements sans rien enregistrer, puis sans cette option :

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

Depuis WordPress 5.7, l’écran Outils > Santé du site propose aussi, une fois le certificat actif, un bouton Mettre à jour votre site pour utiliser le HTTPS dans l’élément « Votre site n’utilise pas HTTPS ». Il passe les adresses du site en https:// et remplace à l’affichage les liens http:// vers votre site dans le contenu et l’extrait de vos publications, les widgets Texte et le CSS additionnel. Il ne réécrit en revanche ni les liens enregistrés dans votre base de données ni la configuration du serveur : il ne dispense donc pas des étapes n°3 et n°4. Ce bouton n’apparaît pas si les adresses du site sont fixées dans le fichier wp-config.php.

Étape n°5 – Modifier le fichier wp-config.php

Ce fichier de configuration est généré lors de l’installation de votre WordPress. Il relie votre installation à votre base de données mais offre de nombreuses autres options de configuration.

Nous allons y ajouter la ligne suivante, au-dessus de la ligne require_once ABSPATH . 'wp-settings.php';, qui force l’usage de HTTPS en back-office :

define ('FORCE_SSL_ADMIN' , true);

Vérifiez également si les adresses du site sont fixées dans ce fichier par les constantes WP_HOME et WP_SITEURL : si c’est le cas, passez-les en https://. Vous pouvez aussi les y ajouter. Cette technique offre l’avantage de bloquer ce réglage en back-office et évite une erreur de manipulation qui serait liée à un changement accidentel d’URL. Voici un exemple pour ce site :

/** Définir l'URL par défaut */
define('WP_HOME', 'https://wpchannel.com');
define('WP_SITEURL', 'https://wpchannel.com');

Dans Réglages > Général, les champs Adresse web de WordPress (URL) et Adresse web du site (URL) doivent désormais commencer par https:// ; ils apparaissent grisés lorsque ces constantes sont définies. Notez que WordPress active de lui-même FORCE_SSL_ADMIN dès que l’adresse web de WordPress commence par https://.

Attention si votre site se trouve derrière un proxy inverse ou un CDN qui gère lui-même le certificat : votre serveur reçoit alors toutes les requêtes en HTTP, et la redirection de l’étape n°3 comme FORCE_SSL_ADMIN provoquent une boucle de redirections. Configurez dans ce cas la redirection vers HTTPS au niveau de ce service. S’il transmet l’en-tête X-Forwarded-Proto (vérifiez-le auprès de votre hébergeur), indiquez à WordPress le protocole d’origine en ajoutant ces lignes au même endroit du fichier wp-config.php, uniquement dans ce cas :

// Behind a reverse proxy or CDN that handles HTTPS: trust the protocol it forwards.
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && str_contains( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
	$_SERVER['HTTPS'] = 'on';
}

Étape n°6 – Vérifier la présence de contenus mixtes

Cette étape est sans doute la plus compliquée car elle requiert des compétences en développement Web pour WordPress. Certaines pages de votre site vont probablement combiner des URLS en HTTP et d’autres HTTPS et ce, malgré la réécriture opérée en base. C’est souvent le cas pour des URLS saisies en dur dans le code d’un thème, d’une extension ou d’un mu-plugins. En théorie, cela ne devrait pas être le cas dans un monde parfait où les développements sont bien faits.

Pour identifier de tels cas, parcourez les pages principales de votre site qui utilisent des gabarits différents, c’est-à-dire faisant appel à des fichiers PHP différents du thème. Ouvrez la console des outils de développement de votre navigateur : chaque ressource appelée en HTTP sur une page en HTTPS y est signalée comme contenu mixte. Chrome et Firefox tentent de charger en HTTPS les images, les sons et les vidéos concernés, bloquent ceux qui n’y sont pas disponibles et bloquent aussi les scripts et les iframes appelés en HTTP : une partie de la page peut donc disparaître sans autre avertissement. Sous Firefox, l’onglet Médias de la fenêtre Informations sur la page liste aussi l’adresse de chaque image.

Étape n°7 – Vérifier Google Analytics

Universal Analytics, dont les propriétés et les vues demandaient de préciser le protocole du site, ne traite plus aucune donnée depuis le 1^er juillet 2023 : Google Analytics 4 l’a remplacé. Dans Google Analytics 4, ouvrez Administration > Collecte et modification des données > Flux de données pour vérifier l’URL de votre flux Web, puis contrôlez après la bascule que les visites de vos pages en HTTPS sont bien mesurées.

Étape n°8 – Ajouter les propriétés Google Search Console

Si vous suivez votre site avec une propriété de domaine, vous n’avez rien à ajouter : elle regroupe déjà les données de toutes les variantes de votre domaine, en HTTP comme en HTTPS. Avec des propriétés de préfixe d’URL, ajoutez-en une pour la version en https:// de votre site, en gardant l’ancienne pour suivre la bascule. Google ne permet plus de lui indiquer votre version préférée depuis 2019 : ce sont vos redirections 301 et vos balises canoniques qui le renseignent.

Soumettez ensuite le plan de site de la version en HTTPS dans le rapport sur les sitemaps : Google le recommande pour l’aider à découvrir vos nouvelles adresses. Inutile en revanche de passer par l’outil Changement d’adresse, que Google demande de ne pas utiliser pour un passage de HTTP à HTTPS.

Étape n°9 – Modifier le fichier robots.txt

Le fichier robots.txt, présent à la racine de tous les sites développés sous WordPress, contient des instructions relatives à l’indexation par les moteurs de recherche. Si vous utilisez SEOPress PRO, vous pouvez le modifier directement depuis votre back-office. Pensez donc à mettre à jour l’URL du plan de site que l’on insère souvent en première ligne.

Étape n°10 – Mettre à jour les liens entrants

Il va de soi que vous ne pourrez contacter chaque webmaster un par un pour lui demander de mettre à jour les liens entrants – les fameux backlinks, pour les passer en HTTPS. Néanmoins, vous avez la main sur vos différents profils de réseaux sociaux (Facebook, LinkedIn, Instagram, etc.) ou encore votre fiche d’établissement Google (anciennement Google My Business).

Quels outils pour vérifier la qualité de votre certificat SSL ?

De nombreux outils sont disponibles pour vérifier la bonne mise en place d’un certificat SSL.

Avec du Let’s Encrypt, le déploiement est assuré par votre hébergeur si bien que vous ne devriez pas rencontrer de problèmes. Sur du certificat payant, c’est une toute autre histoire et il faudra bien s’assurer que tout est ok.

Je vous conseille donc de tester vos sites avec SSL Labs ou encore SSL Checker.

Pour les utilisateurs avancés, vous pouvez également vérifier le niveau de sécurité de vos en-têtes à l’aide de Security Headers. Quelques optimisations dans votre fichier .htaccess vous donneront la note de A mais attention à ne pas tout casser !

En résumé, le passage à HTTPS n’est plus une option mais une nécessité pour bien des aspects : confiez-moi cette mission !

Vous éditez déjà le .htaccess : profitez-en pour bloquer l’accès aux répertoires de WordPress.