Rediriger HTTP vers HTTPS sur WordPress : configurations

Mis à jour le 1er novembre 2026. Ce guide couvre désormais LiteSpeed, Cloudflare et les reverse proxies, la mise à jour des URL en base avec WP-CLI, le contenu mixte, HSTS et une série de tests curl.

Un site accessible en HTTP et en HTTPS présente deux adresses pour chaque page. Les moteurs peuvent indexer l’une ou l’autre. La solution : une redirection permanente (301) de toutes les requêtes HTTP vers HTTPS, des adresses WordPress corrigées, puis des contrôles.

Vérifier le certificat avant toute redirection

Une redirection vers un HTTPS défaillant rend le site inaccessible. Testez d’abord la connexion sécurisée :

curl -sI https://exemple.fr/

La réponse doit être HTTP/2 200 ou HTTP/1.1 200, sans erreur de certificat. Pour lire le sujet, l’émetteur et la date d’expiration :

echo | openssl s_client -connect exemple.fr:443 -servername exemple.fr 2>/dev/null | openssl x509 -noout -subject -issuer -enddate

Le sujet doit correspondre au domaine (et à www) et notAfter doit être dans le futur. Pour installer un certificat, voir notre guide Let’s Encrypt avec Certbot.

Où placer la redirection

Placez la redirection au niveau du serveur, avant PHP : elle couvre aussi les fichiers statiques.

Environnement	Emplacement recommandé	Remarque
Apache avec accès à la configuration	`VirtualHost` du port 80	Solution recommandée par la documentation Apache
Apache mutualisé	`.htaccess` à la racine	Avant le bloc `# BEGIN WordPress`
Nginx	Bloc `server` du port 80	`return 301`
LiteSpeed	`.htaccess`	Règles de réécriture au format Apache
Cloudflare ou proxy	Bord du réseau ou origine, pas les deux sans contrôle	Attention aux boucles
Extension WordPress	Dernier recours	Ajoute du code, peut doubler une règle existante

Visez une seule adresse canonique, par exemple https://exemple.fr, atteinte en un seul saut depuis toutes les variantes.

Apache

Dans le VirtualHost

Avec accès à la configuration, la documentation Apache recommande une directive Redirect dans un hôte virtuel dédié au port 80 :

<VirtualHost *:80>
    ServerName exemple.fr
    ServerAlias www.exemple.fr
    Redirect permanent "/" "https://exemple.fr/"
</VirtualHost>

Redirect conserve le chemin : http://exemple.fr/contact/ devient https://exemple.fr/contact/. Vérifiez la syntaxe avec sudo apachectl configtest, puis rechargez le service.

Dans le .htaccess

Sur un hébergement mutualisé, placez ce bloc au début du .htaccess, avant # BEGIN WordPress. Il traite HTTP et la variante www en un seul saut :

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.exemple\.fr$ [NC]
RewriteRule ^ https://exemple.fr%{REQUEST_URI} [L,R=301]

Placée après le bloc WordPress, la règle peut ne jamais s’exécuter. Apache doit aussi autoriser les .htaccess (AllowOverride All ou FileInfo). Notre générateur de redirection .htaccess produit ces variantes.

Nginx

Déclarez un bloc pour le port 80 et, si nécessaire, un bloc HTTPS pour la variante www :

server {
    listen 80;
    listen [::]:80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://exemple.fr$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.exemple.fr;
    ssl_certificate     /etc/letsencrypt/live/exemple.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;
    return 301 https://exemple.fr$request_uri;
}

Le certificat doit couvrir www.exemple.fr. Le bloc principal server_name exemple.fr sur le port 443 reste inchangé. Testez avec sudo nginx -t, puis sudo systemctl reload nginx.

LiteSpeed

LiteSpeed Web Server se présente comme un remplaçant direct d’Apache : utilisez la règle .htaccess ci-dessus. Avec OpenLiteSpeed, deux différences comptent :

le chargement des .htaccess doit être activé (« Auto Load from .htaccess ») au niveau du serveur ou de l’hôte virtuel ;
seules les règles mod_rewrite sont lues (pas Header), et un redémarrage est nécessaire après chaque modification.

Derrière Cloudflare ou un reverse proxy

Le principe de la boucle

Derrière un proxy, l’origine reçoit souvent la requête en HTTP, même si le visiteur est en HTTPS. La condition %{HTTPS} !=on reste vraie et l’origine redirige sans fin : ERR_TOO_MANY_REDIRECTS.

Les modes SSL de Cloudflare

Mode	Connexion Cloudflare vers l’origine	Usage
Flexible	HTTP	Origine sans certificat ; boucle si l’origine redirige vers HTTPS
Full	HTTPS, certificat non validé	Certificat autosigné
Full (strict)	HTTPS, certificat validé	Recommandé
Strict (SSL-Only Origin Pull)	Toujours HTTPS validé	Origine qui n’accepte que HTTPS

En cas de boucle en mode Flexible, Cloudflare recommande de passer en Full ou Full (strict), ou de supprimer la redirection à l’origine. L’option « Always Use HTTPS » redirige au bord du réseau.

Lire X-Forwarded-Proto

Le proxy transmet le protocole d’origine dans l’en-tête X-Forwarded-Proto. Pour Apache :

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Pour Nginx, dans le bloc qui reçoit le trafic du proxy :

if ($http_x_forwarded_proto != "https") {
    return 301 https://$host$request_uri;
}

WordPress doit aussi savoir que la requête est sécurisée, sinon il génère des liens en HTTP ou boucle sur l’administration. Ajoutez dans wp-config.php, avant la ligne require_once ABSPATH . 'wp-settings.php'; :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
    $_SERVER['HTTPS'] = 'on';
}

Certains proxies envoient une liste comme http,https, d’où la recherche de https dans la valeur. Cet en-tête peut être falsifié : ne vous y fiez que si l’origine n’est joignable qu’à travers le proxy.

Régler WordPress

Dans Réglages > Général, passez en https:// l’« Adresse web de WordPress (URL) » et l’« Adresse web du site (URL) ». Si l’administration est inaccessible, définissez-les dans wp-config.php :

define( 'WP_HOME', 'https://exemple.fr' );
define( 'WP_SITEURL', 'https://exemple.fr' );
define( 'FORCE_SSL_ADMIN', true );

Ces constantes priment sur la base de données. FORCE_SSL_ADMIN impose HTTPS pour la connexion et l’administration ; il remplace FORCE_SSL_LOGIN, obsolète depuis WordPress 4.0.

Mettre à jour les URL en base avec WP-CLI

Les contenus gardent des URL en http:// écrites en dur. N’utilisez ni sed sur un export ni un REPLACE SQL : les données sérialisées seraient corrompues. WP-CLI détecte ces colonnes et les traite en PHP. Sauvegardez, puis faites un essai :

wp db export avant-https.sql
wp search-replace 'http://exemple.fr' 'https://exemple.fr' --skip-columns=guid --dry-run --report-changed-only

Relancez sans --dry-run une fois le rapport validé. Répétez pour http://www.exemple.fr si cette variante existait. Les éditeurs de pages stockent parfois les URL au format JSON échappé ; une seconde passe les couvre :

wp search-replace 'http:\/\/exemple.fr' 'https:\/\/exemple.fr' --skip-columns=guid --dry-run

Ajoutez --all-tables si des extensions utilisent des tables non enregistrées dans WordPress. La colonne guid est exclue : c’est un identifiant, pas une adresse à modifier. Videz ensuite les caches (extension, serveur, CDN).

Corriger le contenu mixte

Une page HTTPS qui charge une ressource en http:// déclenche un avertissement, ou un blocage pour les scripts. Repérez ces ressources dans la console ou l’onglet Réseau des outils de développement. Cherchez aussi dans le thème et les extensions :

grep -rn "http://exemple.fr" wp-content/themes/ wp-content/plugins/

L’en-tête Content-Security-Policy: upgrade-insecure-requests demande au navigateur de charger ces ressources en HTTPS. C’est un filet de sécurité temporaire : si la ressource n’existe pas en HTTPS, elle échoue. Il ne remplace ni la correction des URL ni HSTS. Le même travail sur PrestaShop est décrit dans PrestaShop en HTTPS : contenu mixte et redirections.

HSTS, avec prudence

L’en-tête Strict-Transport-Security demande au navigateur de n’utiliser que HTTPS pendant max-age secondes. Il est ignoré s’il est reçu en HTTP. Une erreur le rend difficile à annuler : le navigateur doit revenir en HTTPS pour lire max-age=0.

Commencez court, puis augmentez par paliers en vérifiant le site à chaque étape : 300 secondes, une semaine (604800), un mois (2592000), puis un an (31536000). Pour Apache, dans le VirtualHost du port 443 (module mod_headers) :

Header always set Strict-Transport-Security "max-age=300"

Pour Nginx, dans le bloc server HTTPS :

add_header Strict-Transport-Security "max-age=300" always;

Sur Nginx, un bloc location qui définit son propre add_header n’hérite pas de celui du server. N’ajoutez includeSubDomains que si tous les sous-domaines répondent en HTTPS. La liste de préchargement (preload) exige au moins un an et includeSubDomains. Le site hstspreload.org la déconseille par défaut, car le retrait prend des mois.

Vérifier avec curl

Sous Windows PowerShell, utilisez curl.exe, car curl y est un alias d’Invoke-WebRequest.

curl -sI http://exemple.fr/
curl -sI http://www.exemple.fr/article-test/
curl -sIL --max-redirs 5 http://www.exemple.fr/
curl -sI https://exemple.fr/ | grep -i strict-transport-security

Test	Résultat attendu
`http://exemple.fr/`	`301`, `location: https://exemple.fr/`
URL profonde en HTTP	`301` vers la même URL en HTTPS
Chaîne complète avec `-L`	Une seule 301, puis `200`
`https://www.exemple.fr/`	`301` vers `https://exemple.fr/`
En-tête HSTS	Présent, avec le `max-age` voulu

Si curl signale le nombre maximal de redirections atteint, une boucle subsiste. Sans terminal, notre vérificateur de code d’état HTTP affiche la chaîne de redirections.

Search Console

Une propriété de type domaine couvre déjà les deux protocoles ; sinon, ajoutez la propriété https://exemple.fr/. Soumettez un sitemap en HTTPS, puis inspectez une ancienne URL HTTP. N’utilisez pas l’outil de changement d’adresse : Google indique qu’il ne s’applique pas à un passage de HTTP à HTTPS. Suivez ensuite le rapport « Indexation des pages », puis les Core Web Vitals de WordPress.

Questions fréquentes

Faut-il une redirection 301 ou 302 pour passer en HTTPS ?

Une 301, qui signale un changement définitif. La 302 sert aux redirections temporaires.

Le passage en HTTPS fait-il perdre du référencement ?

Pas si la migration est propre : une seule 301 par URL, liens internes, balises canoniques et sitemap en HTTPS.

Pourquoi ERR_TOO_MANY_REDIRECTS apparaît-il après l’activation ?

L’origine reçoit du HTTP alors que le visiteur est en HTTPS, typiquement derrière Cloudflare en mode Flexible ou un proxy. Passez en Full (strict) ou ajoutez la condition sur X-Forwarded-Proto, puis retestez avec curl -sIL --max-redirs 5.

Faut-il activer HSTS tout de suite ?

Non. Activez-le une fois la redirection et le contenu mixte corrigés, avec un max-age court. Augmentez par paliers, et ne demandez le préchargement que si vous pouvez garantir HTTPS sur tous les sous-domaines à long terme.

Sources

Apache HTTP Server 2.4, « Redirecting and Remapping with mod_rewrite », section Forcing HTTPS : https://httpd.apache.org/docs/2.4/rewrite/remapping.html
Apache HTTP Server 2.4, « When not to use mod_rewrite » : https://httpd.apache.org/docs/2.4/rewrite/avoid.html
nginx, module ngx_http_headers_module (add_header, paramètre always, héritage) : https://nginx.org/en/docs/http/ngx_http_headers_module.html
LiteSpeed Web Server, documentation : https://docs.litespeedtech.com/lsws/
OpenLiteSpeed, « Rewrite Rules » : https://docs.openlitespeed.org/config/rewriterules/
Cloudflare, « Encryption modes », mise à jour du 16 avril 2026 : https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/
Cloudflare, « ERR_TOO_MANY_REDIRECTS », mise à jour du 1er septembre 2026 : https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/
WordPress Advanced Administration, « HTTPS », mise à jour du 14 octobre 2026 : https://developer.wordpress.org/advanced-administration/security/https/
WP-CLI, wp search-replace : https://developer.wordpress.org/cli/commands/search-replace/
MDN, Strict-Transport-Security : https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security
MDN, upgrade-insecure-requests : https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/upgrade-insecure-requests
HSTS Preload List Submission : https://hstspreload.org/
Aide Search Console, outil de changement d’adresse : https://support.google.com/webmasters/answer/9370220

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →