Redirections 301 et refonte : la partie qu’on oublie

Dans une refonte, on parle du design, des textes, des photos. Les anciennes adresses arrivent en dernier, la veille de la mise en ligne, quand le temps manque. C’est pourtant là que se joue une bonne part de ce que le site a gagné dans Google.

Une adresse ancienne a une histoire : des liens venus d’autres sites, des favoris, des courriels envoyés, une place dans les résultats. Si elle répond par une erreur le jour de la mise en ligne, tout cela s’arrête net. Une redirection permanente fait suivre le visiteur, et le robot, jusqu’à la nouvelle page.

1Ce qu’une redirection transmet

Google traite la redirection permanente faite par le serveur comme un signal fort : il retient la nouvelle adresse comme adresse de référence et la montre dans ses résultats. Il garde aussi la trace des deux pendant un temps. L’ancienne adresse peut encore apparaître dans les résultats, puis elle s’efface d’elle-même ; pour un site de taille moyenne, Google parle de quelques semaines, ou plus.

Une redirection temporaire, 302 ou 307, dit l’inverse : la page reviendra. Google garde alors l’ancienne adresse dans ses résultats. C’est le bon choix pour une maintenance ou une page saisonnière, et le mauvais pour une refonte.

Google recommande la redirection côté serveur chaque fois que c’est possible. Les redirections écrites en JavaScript, ou un simple lien vers la nouvelle page, restent un dernier recours : Google peut les manquer.

2301, 308, 302, 404, 410 : le bon code pour chaque cas

Pour Google, un 404 et un 410 mènent au même résultat : sa documentation traite de la même façon tous les codes en 4xx, sauf le 429, et retire la page de l’index. Nous répondons 410 pour une page retirée exprès, parce qu’il dit clairement l’intention, et nous gardons le 404 pour le reste.

Sur ce site, l’hébergeur répond 308 aux redirections déclarées permanentes. Google le traite comme un 301 : pour la recherche, les deux se valent.

3Le plan de redirections

Le plan est un tableau à deux colonnes : l’ancienne adresse, la nouvelle. Il se construit avant la refonte, sur l’ancien site encore en ligne, et il compte autant que les maquettes.

1. 1Relever toutes les anciennes adressesLe plan du site (le sitemap), les rapports Performances et Liens de Search Console, les journaux du serveur, les exports de l’ancien outil. Google cite lui-même le plan du site, les journaux du serveur et le rapport Liens.
2. 2Donner à chacune sa destinationLa page qui traite du même sujet sur le nouveau site ; à défaut, la plus proche. Une page sans équivalent répond 410.
3. 3Écrire les règles côté serveurDans la configuration de l’hébergeur ou du serveur : une règle par adresse, ou une règle par motif quand toute une rubrique change de chemin.
4. 4Mettre à jour le reste du siteLes liens internes, les adresses canoniques et le plan du site pointent directement vers les nouvelles adresses. Google le demande expressément.

Sur un site hébergé chez Vercel, comme celui-ci, le plan s’écrit dans le fichier de configuration. Une règle déclarée permanente y répond 308.

{
  "trailingSlash": true,
  "redirects": [
    {
      "source": "/[ancienne-page]/",
      "destination": "/[nouvelle-page]/",
      "permanent": true
    },
    {
      "source": "/actualites/:article/",
      "destination": "/observatoire/:article/",
      "permanent": true
    }
  ],
  "rewrites": [
    { "source": "/[page-retiree]/", "destination": "/api/gone" }
  ]
}

La deuxième règle déplace toute une rubrique en gardant le nom de chaque article. La dernière envoie une page retirée vers une petite fonction du serveur, qui répond 410.

Nous avons dressé ce plan pour ce site même, à partir des anciennes adresses de digi-nova.com. Chaque adresse a sa ligne. Les anciennes pages de service mènent à la page qui les remplace ; l’ancienne page sur la rédaction des fiches produits mène à notre note sur les fiches produits ; les articles périmés et les restes de l’ancien WordPress répondent 410. Une partie des anciens articles mène pour l’instant à l’index de L’Observatoire, en attendant la note qui reprendra leur sujet. C’est un compromis, que nous reprendrons ligne par ligne : Google peut lire ce type de redirection comme une page introuvable.

4Les chaînes et les boucles

Une chaîne, c’est une ancienne adresse qui mène à une autre ancienne adresse, qui mène enfin à la bonne. Elle naît souvent d’une refonte précédente : les redirections d’hier pointent vers des pages que la nouvelle refonte déplace à son tour. Google suit jusqu’à dix sauts, mais il recommande de rediriger directement vers la destination finale, et, à défaut, de rester à trois sauts, toujours moins de cinq.

Une boucle, c’est une adresse qui finit par revenir sur elle-même : A mène à B, qui mène à A. Le navigateur abandonne avec un message d’erreur, et Search Console range l’adresse parmi les erreurs de redirection.

Pour les éviter, nous réécrivons les anciennes redirections avec les nouvelles : chaque ligne du plan mène directement à la destination finale, y compris pour les adresses déjà redirigées par le passé. Sur ce site, quand l’adresse prévue pour une page a changé en cours de route, nous avons repris toutes les lignes qui y menaient, pour qu’elles pointent sur la nouvelle. Nous vérifions aussi les variantes d’une même adresse : avec ou sans barre oblique finale, avec ou sans www, en http ou en https. Chacune ajoute un saut si elle est mal réglée.

5Vérifier avant la mise en ligne

Le plan se teste sur une préversion du nouveau site, avant de basculer le domaine. Pour chaque ancienne adresse, nous demandons la réponse du serveur, et nous regardons trois choses : le code, la destination, et le nombre de sauts.

# la réponse de l'ancienne adresse
curl -sI https://[préversion]/ancienne-page/
HTTP/2 308
location: /nouvelle-page/

# le code final, le nombre de sauts, l'adresse d'arrivée
curl -sIL -o /dev/null \
  -w "%{http_code} %{num_redirects} %{url_effective}\n" \
  https://[préversion]/ancienne-page/
200 1 https://[préversion]/nouvelle-page/

Sur toute la liste, le résultat attendu est le même : un saut, puis une page qui répond 200 ; ou un 410 pour les pages retirées. Nous passons la liste entière dans un petit script, qui relève chaque réponse et signale les écarts.

Ce contrôle fait partie de notre méthode : relever le point de départ avant de toucher au site, puis comparer.

6Suivre après la mise en ligne

Le jour de la bascule, nous refaisons le même contrôle sur le vrai domaine. Puis Search Console prend le relais.

Dans le rapport sur l’indexation des pages, les anciennes adresses passent peu à peu dans « Page avec redirection » : c’est l’état attendu. Trois autres lignes demandent une intervention : « Erreur liée à des redirections », pour une chaîne trop longue, une boucle, ou une adresse vide ou trop longue ; « Introuvable (404) », pour une adresse oubliée dans le plan ; « Soft 404 », pour une redirection vers une page sans rapport.

Google prévient que les positions fluctuent pendant un déménagement. Nous suivons donc les clics par groupe de pages, comparés à une période de même durée avant la mise en ligne : une page seule bouge trop pour conclure.

Les redirections restent en place longtemps. Google conseille de les garder le plus longtemps possible, en général au moins un an, et les visiteurs continuent d’arriver par d’anciens liens bien après : nous les gardons sans date de fin. Enfin, l’outil de changement d’adresse de Search Console sert aux changements de domaine ; pour une refonte sur le même domaine, les redirections font le travail.

Si une refonte se prépare, notre audit commence par la liste des adresses qui comptent, et le référencement naturel reprend ensuite sur des bases saines.

Questions fréquentes

Sur le même sujet

SEO technique : le guide, de l’exploration à l’indexation Référencement naturel Technique Lire la note Pages zombies en SEO : les repérer, et décider de leur sort Référencement naturel Pour agir Lire la note Fiche produit SEO : ce que Google lit vraiment Référencement naturel Pour agir Lire la note