Forcer HTTPS et www : la redirection canonique propre

Forcer le HTTPS et le www : pourquoi et comment ?

Forcer le HTTPS et une seule version d’URL (www ou non-www) consiste à rediriger en 301 toutes les variantes d’un domaine (http://, https://, avec ou sans www) vers une unique version canonique. Cela évite le contenu dupliqué aux yeux de Google et regroupe l’autorité SEO sur une seule adresse au lieu de la diluer sur quatre.

Un site accessible en http://exemple.fr, https://exemple.fr, http://www.exemple.fr et https://www.exemple.fr en même temps, sans redirection, existe en réalité en quatre versions distinctes pour les moteurs de recherche. Chaque version peut être indexée séparément, recevoir des liens différents et diluer le référencement au lieu de le concentrer. C’est un problème que je croise encore régulièrement sur des sites repris en maintenance, souvent hérités d’une migration d’hébergeur mal terminée.

Cet article s’adresse à toute personne qui gère un site WordPress, un site statique ou un site derrière un CDN, et qui veut sécuriser cette redirection sans casser l’accès au site ni créer de boucle infinie.

Prérequis avant de commencer :

• Accès FTP/SSH ou au gestionnaire de fichiers de l’hébergement
• Accès à la zone DNS du domaine
• Un certificat SSL déjà installé et valide sur le domaine
• Une sauvegarde récente du site (fichiers + base de données)
• Idéalement, un accès à Google Search Console pour suivre l’indexation après coup

Étape 1 : choisir sa version canonique

Avant de toucher au code, tranche une question simple : www ou non-www ? Il n’y a pas de bonne réponse universelle, seulement une cohérence à respecter.

• www reste répandu sur les sites institutionnels et les grandes marques, historiquement lié à la séparation possible entre sous-domaine et domaine racine (utile si tu veux un jour héberger le site principal ailleurs qu’un blog ou une app sur un sous-domaine séparé).
• non-www est devenu la norme sur la majorité des sites PME et startups depuis quelques années, perçu comme plus lisible à l’oral et à l’écrit.

Le choix technique compte moins que la cohérence : une fois décidé, cette version doit être partout identique, dans les liens internes, le sitemap XML, les balises canonical, Google Search Console et les campagnes publicitaires. Change d’avis après coup et tu recrées le problème que tu voulais résoudre.

Étape 2 : forcer le HTTPS partout

Le HTTPS n’est plus négociable en 2026 : Chrome affiche un avertissement explicite sur toute page en http://, et Google traite le HTTPS comme un signal de classement depuis longtemps. Si ton certificat SSL est posé mais que http:// reste accessible sans redirection, corrige-le en priorité.

Sur un hébergement Apache (mutualisé classique type OVH, o2switch, IONOS), la redirection se fait dans le fichier .htaccess, à placer tout en haut, avant les règles WordPress :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Sur Nginx, la configuration se fait dans le bloc serveur écoutant le port 80 :

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

Si le site est derrière Cloudflare, active directement l’option “Always Use HTTPS” dans l’onglet SSL/TLS : c’est plus fiable qu’une règle côté serveur, et ça évite un aller-retour inutile entre Cloudflare et ton hébergeur. Retrouve le détail de la configuration DNS associée dans le guide configurer ses DNS sur Cloudflare.

Si ton certificat n’est pas encore valide ou expire bientôt, règle ça avant de forcer quoi que ce soit : forcer du HTTPS vers un certificat cassé transforme un problème SEO en site totalement inaccessible. Les erreurs de cadenas cassé sont traitées dans erreur de certificat SSL et certificat SSL expiré.

Étape 3 : forcer www ou non-www

Une fois le HTTPS forcé, ajoute la redirection de version. Exemple pour forcer le non-www (à adapter dans l’autre sens si tu choisis www) via .htaccess sur Apache :

RewriteCond %{HTTP_HOST} ^www\.exemple\.fr$ [NC]
RewriteRule ^(.*)$ https://exemple.fr/$1 [L,R=301]

Pour forcer www à l’inverse :

RewriteCond %{HTTP_HOST} ^exemple\.fr$ [NC]
RewriteRule ^(.*)$ https://www.exemple.fr/$1 [L,R=301]

Sur Nginx, la logique est similaire avec deux blocs serveur distincts, un pour chaque nom d’hôte, l’un servant le site, l’autre redirigeant en 301 vers l’autre. Sur Cloudflare, une “Redirect Rule” (menu Rules) fait le travail sans toucher au serveur d’origine, ce qui simplifie beaucoup la maintenance.

Sur un hébergement géré comme Infomaniak ou Hostinger, l’interface propose souvent une case à cocher “rediriger www vers domaine principal” directement dans le panneau d’hébergement, sans passer par le fichier de configuration. Vérifie toujours si cette option existe avant d’écrire une règle manuelle, ça évite les conflits.

Étape 4 : vérifier l’absence de boucle de redirection

Une redirection mal écrite crée facilement une boucle infinie : le navigateur affiche alors ERR_TOO_MANY_REDIRECTS. C’est l’erreur la plus fréquente sur ce type de manipulation, généralement causée par deux règles qui se contredisent (une redirection HTTPS côté Cloudflare et une autre côté serveur, chacune pensant que l’autre n’a pas encore fait son travail).

Teste systématiquement les quatre combinaisons possibles après chaque modification :

Utilise un outil de vérification d’en-têtes HTTP (ou l’onglet réseau du navigateur) pour confirmer qu’il n’y a jamais plus d’un seul saut de redirection avant d’arriver sur la version finale en 200. Si tu vois plusieurs 301 qui s’enchaînent, c’est le signe de règles superposées à nettoyer. Le diagnostic complet de ce type de boucle est détaillé dans ERR_TOO_MANY_REDIRECTS.

Étape 5 : aligner le reste du site sur la version choisie

La redirection serveur ne suffit pas seule. Vérifie et corrige aussi :

• La balise <link rel="canonical"> sur chaque page, qui doit pointer vers l’URL exacte choisie
• Le sitemap XML, qui ne doit contenir que des URLs dans la bonne version
• L’adresse du site dans les réglages WordPress (Réglages > Général), champs “Adresse WordPress” et “Adresse du site”
• Les propriétés déclarées dans Google Search Console (ajoute la propriété canonique si elle n’existe pas encore)
• Les liens internes en dur dans le contenu, souvent oubliés après une migration

Si le contenu affiche un cadenas barré ou des ressources bloquées après le passage au HTTPS, c’est généralement un problème de contenu mixte, détaillé dans contenu mixte WordPress.

Pièges courants

• Rediriger côté Cloudflare ET côté serveur avec des règles contradictoires : choisis un seul point de redirection, pas les deux.
• Oublier de mettre à jour le sitemap : Google continue de crawler d’anciennes URLs pendant des semaines si le sitemap n’est pas à jour.
• Changer de version canonique après coup : ça génère une nouvelle vague de 301 et une perte temporaire de positions SEO, à éviter sauf nécessité réelle.
• Forcer HTTPS avant que le certificat soit posé : rends le site inaccessible pour rien, vérifie toujours l’ordre des opérations.
• Ne pas tester sur mobile : certains caches d’app ou navigateurs mobiles gardent en mémoire l’ancienne redirection plus longtemps que sur desktop.

Une redirection propre change rarement le trafic du jour au lendemain, mais elle évite un problème plus grave : des positions SEO durablement diluées entre plusieurs versions d’un même site. Si tu prépares un changement d’hébergeur en parallèle, coordonne les deux : le guide changer d’hébergeur sans perdre son référencement couvre les points de vigilance à ne pas manquer au même moment.

Le point à retenir : une seule version d’URL, une seule règle de redirection, testée sur les quatre combinaisons possibles avant de passer à autre chose.