Redirections 301 et refonte de site : préserver le référencement

Refondre un site, c’est souvent changer sa structure d’URL. Sans plan de redirections, chaque adresse qui disparaît emporte avec elle le référencement accumulé et renvoie les visiteurs vers une page d’erreur. Le sujet n’est pas cosmétique : une redirection mal posée se traduit en trafic perdu dès les premiers passages du robot d’exploration. Ce guide couvre le choix des codes HTTP, la construction du plan, la canonicalisation, la mise en œuvre côté serveur et le contrôle après la mise en ligne.

#Ce qu’une redirection transmet, et ce qu’une erreur détruit

Une redirection permanente indique au navigateur et au moteur de recherche que le contenu a définitivement changé d’adresse. Le moteur transfère alors l’essentiel du signal de référencement de l’ancienne URL vers la nouvelle et met son index à jour. À l’inverse, une URL supprimée sans redirection renvoie un code 404 : les liens externes qui pointaient vers elle deviennent des impasses, et le signal qu’ils apportaient disparaît. Une refonte réussie conserve la correspondance entre chaque ancienne adresse utile et sa destination.

Le transfert n’est pas instantané. Le moteur doit repasser sur l’ancienne URL, constater la redirection, puis réévaluer la destination. Ce délai, de quelques jours à quelques semaines selon la fréquence d’exploration, explique pourquoi une baisse de trafic temporaire après une bascule n’a rien d’anormal — à condition que les redirections soient correctes.

#301, 302, 307, 308 : choisir le bon code

Le code HTTP n’est pas un détail. Il dit au moteur si le changement est permanent et s’il doit transférer le signal. Se tromper de code, c’est soit conserver l’ancienne URL dans l’index, soit perdre le transfert.

Pour une refonte, la règle est simple : 301 pour les pages, 308 quand la méthode HTTP doit être préservée. Le 302 se réserve aux situations réellement temporaires, car il n’invite pas le moteur à mettre son index à jour.

#Construire le plan de redirection avant la bascule

Le plan se prépare pendant la refonte, jamais après. Il consiste en une table de correspondance entre chaque ancienne URL et sa destination, établie à partir de trois sources croisées : l’export des URL indexées depuis la Search Console, la liste des pages les plus visitées, et les liens entrants connus. Chaque ancienne URL à valeur reçoit une destination sur une page équivalente — pas systématiquement la page d’accueil, qui dilue le signal.

Rediriger toutes les anciennes pages vers l’accueil n’est pas un plan de redirection : c’est une perte de signal déguisée en solution.

Certains cas méritent une attention particulière. Les URL à paramètres (filtres, tri, suivi de campagne) ne se redirigent pas une à une : mieux vaut une règle sur le chemin et la conservation ou non des paramètres selon leur rôle. Les pages de pagination, les archives et les URL d’images changent aussi lors d’une refonte et doivent figurer au plan. La continuité éditoriale compte enfin autant que la continuité technique : une page qui portait des données structurées doit retrouver un balisage équivalent sur sa destination, sinon les enrichissements affichés dans les résultats disparaissent le temps que le moteur réévalue la nouvelle page.

#Canonicalisation : forcer une seule version de chaque URL

Une refonte est le bon moment pour consolider les points d’entrée en double. Tant que http:// et https://, la version avec et sans www, ou les variantes avec et sans slash final répondent toutes en 200, le moteur voit plusieurs URL pour un même contenu et doit trancher lui-même laquelle indexer. Le choix se force par une redirection permanente vers une forme unique, dite canonique. Sous nginx, la pratique idiomatique passe par des blocs de redirection dédiés plutôt que par des tests conditionnels :

# HTTP vers HTTPS : tout le trafic en clair part vers la version sécurisée
server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

# Version sans www vers la version canonique avec www
server {
    listen 443 ssl;
    server_name exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

Le principe reste le même pour le slash final : choisir une convention, la même partout, et rediriger l’autre forme en 301. L’important est la cohérence, pas le choix lui-même.

#Mettre en œuvre côté serveur

La redirection se pose au niveau du serveur web, en amont de l’application, pour rester rapide et indépendante du code. Sous nginx, une correspondance exacte se déclare avec return 301, un motif complet avec rewrite :

server {
    listen 443 ssl;
    server_name www.exemple.fr;

    # Redirection exacte, ancienne page vers nouvelle
    location = /ancienne-rubrique/article {
        return 301 /nouvelle-rubrique/article/;
    }

    # Redirection d'un motif complet vers une nouvelle arborescence
    location /blog/ {
        rewrite ^/blog/(.*)$ /articles/$1 permanent;
    }
}

Le résultat se vérifie à la réponse HTTP : le code doit être 301 et l’en-tête Location doit pointer vers l’URL finale, en une seule étape.

GET /ancienne-rubrique/article HTTP/1.1
Host: www.exemple.fr

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

Un contrôle en ligne de commande suffit à confirmer le comportement sans passer par un navigateur :

curl -sI https://www.exemple.fr/ancienne-rubrique/article \
  | grep -i -E '^(HTTP|location)'

Cette logique vaut quel que soit l’hébergement, y compris sur une pile auto-hébergée où le serveur web est directement accessible.

#Éviter les chaînes et les boucles

#Contrôler après la mise en ligne

La bascule n’est pas la fin du travail. Dans les jours qui suivent, trois vérifications s’imposent : soumettre le nouveau plan du site à la Search Console et surveiller la couverture d’indexation, suivre l’évolution du trafic pour repérer une page qui décroche, et lire les journaux du serveur à la recherche des 404 encore servies. Le tableau de bord de pilotage qui croise analytique et Search Console rend ces signaux lisibles en un coup d’œil. Un pic de 404 dans les journaux signale presque toujours une ancienne URL oubliée dans le plan ; il se corrige en ajoutant la redirection manquante, sans attendre que le moteur constate l’erreur.

#Ce qu’il faut retenir

Une refonte préserve son référencement quand le plan de redirection est préparé avant la bascule, appuyé sur des données réelles d’indexation et de trafic, posé en 301 directes côté serveur, puis contrôlé après la mise en ligne. Le code HTTP se choisit selon la nature du changement, les points d’entrée en double sont consolidés vers une URL canonique, les destinations restent pertinentes page à page, et les chaînes comme les boucles sont éliminées en amont. Rien de spectaculaire : de la méthode, appliquée au bon moment.

Pour aller plus loin : la documentation de Google Search Central sur les redirections et leur effet sur l’exploration et l’indexation.