Une refonte de site change les URLs presque par réflexe : nouvelle arborescence, nouveaux slugs, nouveau nom de domaine parfois. Le problème, c'est que Google et les visiteurs qui arrivent depuis un ancien lien ne le savent pas — et chaque URL abandonnée sans redirection est un peu d'autorité SEO qui part à la poubelle.
Nous l'avons revérifié récemment sur l'un de nos propres projets en croisant les données Search Console : plusieurs URLs d'une version précédente du site recevaient encore des impressions et quelques clics, des mois après la refonte. L'une d'entre elles se positionnait même en page 1 sur une requête de marque. Toutes renvoyaient un statut 200 avec le contenu de la page d'accueil — ce qu'on appelle un soft-404, et c'est presque pire qu'un vrai 404.
Pourquoi une ancienne URL a de la valeur
Une URL qui a existé plusieurs mois ou plusieurs années a eu le temps d'accumuler ce que Google appelle du "signal" : des liens entrants, un historique de clics, une position acquise sur certaines requêtes. Ce signal est attaché à l'URL exacte, pas au contenu qu'elle affichait. Le supprimer sans redirection revient à jeter ce capital, même si le nouveau contenu est objectivement meilleur.
Comment repérer les URLs orphelines après une refonte
- Dans Search Console, le rapport Pages (menu Indexation) liste les URLs explorées par Google, y compris celles qui n'existent plus sur le site actuel. Filtrez sur les statuts "Explorée, actuellement non indexée" et "Détectée, actuellement non indexée" : c'est souvent là que se cachent les pages orphelines.
- Dans le rapport Performances, triez les pages par impressions pour repérer celles qui reçoivent encore du trafic potentiel malgré leur absence du site actuel.
- Un test manuel sur un échantillon d'anciennes URLs (avec un outil qui n'auto-suit pas les redirections) permet de confirmer si elles renvoient un vrai 404, un soft-404, ou déjà une redirection.
Soft-404 vs vraie redirection 301 : la différence qui compte
Un soft-404 survient quand une URL qui n'existe plus renvoie quand même un statut HTTP 200, généralement parce qu'une application côté client affiche une page générique (souvent la page d'accueil) sans jamais informer le serveur que la ressource demandée n'existe pas. Pour un visiteur, la différence est invisible. Pour Google, elle est déterminante :
| Réponse serveur | Ce que comprend Google | Effet sur le SEO |
|---|---|---|
| 200 avec contenu de l'accueil (soft-404) | La page existe et son contenu est celui de l'accueil | Signal de quasi-duplication, dilution progressive |
| 404 / 410 sans redirection | La page n'existe plus, sans indication d'un remplaçant | Perte du signal accumulé sur cette URL |
| 301 vers la nouvelle page | La page a déménagé de façon permanente | Transfert du signal accumulé vers la nouvelle URL |
Seule la redirection 301 transfère l'autorité accumulée. C'est la seule des trois options qui transforme une perte en simple mise à jour d'adresse aux yeux de Google.
Construire une table de correspondance, une par une
La tentation, face à une dizaine ou une centaine d'anciennes URLs, est de toutes les rediriger vers la page d'accueil pour "faire propre". C'est une erreur : cela recrée artificiellement le problème du soft-404 (des dizaines d'URLs qui pointent toutes vers le même contenu générique) et dilue le signal au lieu de le transférer.
La bonne méthode consiste à associer chaque ancienne URL à son équivalent le plus proche sur le nouveau site, un par un :
- Une ancienne page produit ou étude de cas redirige vers son équivalent exact si le contenu existe toujours.
- Une ancienne page de service redirige vers la page de service la plus proche thématiquement.
- Une ancienne page sans aucun équivalent raisonnable redirige vers la page de catégorie la plus proche (jamais vers l'accueil par défaut), ou renvoie un vrai 404 si aucune correspondance de contenu n'existe — un 404 propre est préférable à une redirection trompeuse.
Ce qu'il ne faut jamais faire
- Chaîner les redirections (ancienne URL → URL intermédiaire → URL finale) : chaque maillon dilue un peu plus le signal, et certains moteurs cessent de suivre la chaîne après quelques sauts.
- Rediriger vers un domaine externe ou une URL non maîtrisée : la plupart des systèmes de redirection l'ignorent silencieusement par sécurité, ce qui laisse le problème initial intact sans message d'erreur visible.
- Oublier les variantes : avec et sans slash final, avec et sans "www.", HTTP et HTTPS. Une redirection qui ne couvre qu'une seule variante d'URL laisse les autres orphelines.
En résumé
Une refonte de site ne devrait jamais se conclure sans un croisement systématique entre les anciennes URLs (Search Console, ancien sitemap, logs serveur si disponibles) et une table de correspondance vers le nouveau site. C'est une étape peu spectaculaire, mais c'est souvent ce qui différencie une refonte qui maintient le trafic organique acquis d'une refonte qui repart de zéro sans le savoir.
