Passer son site au protocole HTTPS : la procédure et les redirections

Le HTTPS est la version chiffrée du protocole HTTP. Il est devenu la norme : Chrome et Firefox signalent comme « Non sécurisées » les pages en HTTP, les visiteurs hésitent à y saisir leurs coordonnées, et Google tient compte du HTTPS dans son classement.

Passer un site en HTTPS est une migration à part entière. Le nom de domaine ne change pas, mais le protocole de toutes les URL change, et Google considère http:// et https:// comme deux adresses différentes : chaque page doit être redirigée vers son équivalent en HTTPS, en un seul saut. Cet article donne la procédure, puis les règles de redirection, avec ou sans www, et l'ordre dans lequel les écrire. Pour l'autre côté, celui du visiteur, voir comment reconnaître un site sécurisé.

Le HTTPS apporte trois garanties :

• la confidentialité : les échanges entre le navigateur et le serveur sont chiffrés ; sur un Wi-Fi public, personne ne peut lire un mot de passe ou un numéro de carte ;
• l'intégrité : les pages et les données ne peuvent pas être modifiées pendant leur transport ;
• l'authentification : le certificat atteste que le site est bien celui de ce nom de domaine.

Chrome n'affiche plus de mention « Sécurisé » pour les sites en HTTPS : c'est l'inverse, les pages en HTTP portent la mention « Non sécurisé », qui passe au rouge dès qu'on y saisit des données. Le HTTPS est aussi un signal de classement pour Google, modeste : il ne remplace pas un contenu pertinent.

La plupart des hébergeurs fournissent gratuitement un certificat Let's Encrypt, à activer depuis l'espace client, et le renouvellent automatiquement. Pour un certificat payant, la procédure passe par une CSR (demande de signature de certificat), générée sur le serveur : elle contient la clé publique et le nom de domaine à certifier, et c'est elle que l'on transmet à l'autorité de certification. Là encore, l'hébergeur s'en charge le plus souvent.

Il existe trois niveaux de validation : le domaine seul (DV), l'organisation (OV) et la validation étendue (EV), qui vérifie plus en détail l'identité de l'entreprise. Tous chiffrent de la même façon, et les navigateurs ne distinguent plus les certificats EV dans la barre d'adresse depuis 2019. Vérifiez que le certificat couvre toutes les variantes servies : exemple.fr et www.exemple.fr, et les sous-domaines éventuels.

Avant la bascule, remplacez les adresses en http:// par https:// partout où le site les écrit : liens internes des contenus, menus, balises canonical et hreflang, sitemap, données structurées. Les ressources appelées par les pages (images, scripts, feuilles de style, polices) doivent aussi être en HTTPS : sinon le navigateur signale un contenu mixte, et peut bloquer la ressource.

Sur WordPress, mettez à jour l'« Adresse web de WordPress » et l'« Adresse web du site » dans les réglages généraux, puis remplacez les anciennes adresses en base avec un outil de recherche et remplacement qui respecte les données sérialisées (WP-CLI search-replace, par exemple). Revoyez aussi les réglages des extensions qui enregistrent des adresses, et l'adresse du sitemap dans le robots.txt.

Inutile de rediriger les pages une à une : seul le protocole change, une règle placée dans la configuration du serveur suffit pour toutes les URL, chemin compris. C'est une redirection 301, permanente : elle indique à Google de remplacer l'ancienne adresse par la nouvelle dans son index, et elle conduit les visiteurs qui ont gardé un favori en HTTP vers la bonne page. Les règles, avec ou sans www, et leur ordre sont détaillés plus bas.

Une propriété de type « Domaine » couvre déjà toutes les variantes, en HTTP et en HTTPS. Sinon, ajoutez la propriété https:// de votre site (avec ou sans www, celle qui sera canonique), puis envoyez-y le sitemap en HTTPS. Google découvrira les nouvelles adresses plus vite, et vous suivrez leur indexation dans le rapport des pages.

Contrôlez le certificat (valide, sur chaque variante d'hôte), l'absence de contenu mixte, et surtout les redirections : chaque ancienne adresse doit répondre par une seule 301 vers son adresse finale. Suivez ensuite l'indexation et le trafic dans les semaines qui suivent ; en cas de baisse, vérifiez d'abord les redirections et le certificat.

Une même page peut répondre sous quatre adresses : http://exemple.fr, http://www.exemple.fr, https://exemple.fr et https://www.exemple.fr. Choisissez-en une, la version canonique (ici, en HTTPS avec www), et redirigez les trois autres vers elle, en un seul saut et avec le même chemin.

L'erreur la plus courante est d'écrire deux règles qui s'enchaînent : une qui passe en HTTPS, une autre qui ajoute le www. http://exemple.fr/page part alors vers https://exemple.fr/page, puis vers https://www.exemple.fr/page : deux redirections au lieu d'une, plus lentes pour le visiteur et pour Google. Le choix entre www et sans www est détaillé dans notre article sur la redirection www.

Dans le fichier .htaccess à la racine du site, ou dans la configuration du serveur :

RewriteEngine On

# Toute adresse en http, ou sur un autre hôte que www.exemple.fr, part en une redirection vers https://www.exemple.fr, même chemin
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Les deux conditions sont réunies par [OR] : la règle s'applique si la requête arrive en HTTP, ou sur un autre hôte que l'hôte canonique, et elle envoie directement vers l'adresse finale. Derrière un CDN ou un répartiteur de charge qui termine le HTTPS, le serveur reçoit toutes les requêtes en HTTP : %{HTTPS} vaut alors toujours off, et c'est l'en-tête X-Forwarded-Proto qu'il faut tester, sous peine de boucle de redirection.

Un bloc server pour le HTTP, un autre pour le HTTPS sans www, le site lui-même étant servi par le bloc https://www.exemple.fr :

# http, avec ou sans www : vers https://www.exemple.fr, même chemin
server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

# https sans www : vers https://www.exemple.fr (le certificat doit couvrir exemple.fr)
server {
    listen 443 ssl;
    server_name exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

Quand le passage en HTTPS accompagne une refonte, les URL changent aussi : le serveur porte alors deux sortes de règles. Les redirections précises, une par URL, sont le plan de redirection : telle ancienne page vers telle nouvelle page. Les règles génériques s'appliquent à tout un ensemble d'adresses : le passage en HTTPS, l'ajout du www, un répertoire entier déplacé.

Apache lit les règles dans l'ordre et s'arrête à la première qui redirige. Si la règle générique vient en premier, http://exemple.fr/ancienne-page.html part d'abord vers https://www.exemple.fr/ancienne-page.html, puis une seconde requête trouve la redirection précise vers /nouvelle-page : une chaîne de deux redirections, et une étape intermédiaire qui n'existe pas. Placez donc les redirections précises d'abord, avec l'adresse finale complète (protocole et hôte compris), puis les règles par motif, puis les règles génériques :

RewriteEngine On

# 1. Les redirections précises, URL par URL (le plan de redirection), vers l'adresse finale complète
RewriteRule "^/?ancienne-page\.html$" "https://www.exemple.fr/nouvelle-page" [L,R=301,NC,QSD,NE]
RewriteRule "^/?categorie/produit-42$" "https://www.exemple.fr/boutique/produit-42" [L,R=301,NC,QSD,NE]

# 2. Les règles par motif (un répertoire entier)
RewriteRule ^actualites/(.*)$ https://www.exemple.fr/blog/$1 [L,R=301]

# 3. Les règles génériques : http vers https, hôte sans www vers www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Ainsi, l'ancienne adresse en HTTP mène en un seul saut à la nouvelle adresse en HTTPS ; les adresses qui n'ont pas de redirection précise passent par la règle générique. La même logique vaut entre une règle par motif et les exceptions qu'elle couvre : l'exception d'abord.

Avec Nginx, un return écrit directement dans le bloc server s'exécute avant tout bloc location : les redirections précises placées dans des location ne seraient jamais lues pour les requêtes en HTTP. Consultez-les avant la règle générique, par exemple avec un map :

# Dans le contexte http : les redirections précises, chemin par chemin
map $uri $nouvelle_adresse {
    default "";
    /ancienne-page.html /nouvelle-page;
    /categorie/produit-42 /boutique/produit-42;
}

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    # Les redirections précises d'abord, la règle générique ensuite (même test dans le bloc en 443)
    if ($nouvelle_adresse) {
        return 301 https://www.exemple.fr$nouvelle_adresse;
    }
    return 301 https://www.exemple.fr$request_uri;
}

Le fichier .htaccess exporté par Swan ne contient que des redirections précises, une par URL, vers l'adresse complète du domaine de production (ou de test), protocole et hôte compris : placez-les avant vos règles génériques. Il ne contient pas de règle de passage en HTTPS, qui reste à écrire dans la configuration du site. Pour savoir où ranger ces règles, voir où placer son plan de redirection.

Pour vérifier qu'une ancienne adresse mène bien en un seul saut à sa destination, interrogez-la en HTTP : la réponse doit être une 301 dont l'en-tête Location est l'adresse finale en HTTPS.

curl -sI http://exemple.fr/ancienne-page.html

HTTP/1.1 301 Moved Permanently
Location: https://www.exemple.fr/nouvelle-page

Si Location désigne une adresse intermédiaire (la même page en HTTPS, ou l'hôte sans www), une règle générique passe avant la redirection précise. Les risques d'une chaîne de redirections pour le référencement sont détaillés dans notre article sur les risques des redirections pour le référencement.