Les trois causes de perte, dans l'ordre

1. Un plan de redirections incomplet ou non testé. 2. Le blocage d'indexation de la préproduction oublié en ligne. 3. Du contenu supprimé au nom de l'épure, alors qu'il portait le positionnement. À elles trois, elles expliquent la quasi-totalité des refontes ratées que j'ai eu à rattraper.

Avant : relever l'existant

C'est l'étape que l'on saute quand le calendrier presse, et c'est celle sans laquelle rien ne peut être rattrapé après coup. On ne peut pas rediriger ce qu'on n'a pas listé.

À releverCommentÀ quoi ça sert
Toutes les adresses du siteUn crawl complet, exportéLa base du plan de redirections
Les pages qui reçoivent du traficSearch Console, 16 mois, onglet PagesSavoir lesquelles ne doivent surtout pas casser
Les requêtes qui rapportentSearch Console, onglet RequêtesVérifier après coup que rien n'a été perdu
Les pages ayant des liens externesUn outil de netlinkingCe sont celles dont la redirection compte le plus
Les positions actuellesUn relevé daté sur vos requêtes principalesLe point de comparaison, sans lequel aucune discussion n'est possible
Les titres et descriptions existantsL'export du crawlNe pas repartir de zéro sur ce qui fonctionnait déjà
Le contenu des pages qui se positionnentUne sauvegarde du texteLa refonte graphique fait souvent disparaître du texte utile

Le relevé qui sauve les discussions. Datez et archivez tout cela avant la bascule. Trois mois plus tard, quand quelqu'un affirmera que le trafic était meilleur avant, ou l'inverse, vous aurez des chiffres au lieu d'impressions. C'est aussi la seule façon de savoir précisément quelles pages ont perdu, et donc quoi corriger.

Le plan de redirections

C'est la pièce maîtresse. Il s'agit d'un simple tableau à deux colonnes, ancienne adresse et nouvelle adresse, mais sa construction obéit à des règles précises.

  1. 1. Une ligne par ancienne adresse indexée

    Sans exception pour celles qui reçoivent du trafic ou des liens. Les pages sans trafic, sans lien et sans équivalent peuvent renvoyer une erreur, à condition que ce soit un choix et non un oubli.

  2. 2. Une correspondance de contenu, pas de convenance

    Chaque adresse pointe vers la page la plus proche en contenu. Jamais vers la page d'accueil par défaut : Google traite une redirection massive vers l'accueil comme une page introuvable, et rien n'est transmis.

  3. 3. Des redirections permanentes

    Une 301, pas une 302. La temporaire indique que l'ancienne adresse reviendra, ce qui n'est pas le cas.

  4. 4. Un seul saut

    Les chaînes de redirections s'accumulent au fil des refontes successives. Si l'ancienne adresse redirigeait déjà, faites pointer directement vers la destination finale.

  5. 5. Un test complet avant la bascule

    Passez la liste entière dans un outil qui suit les redirections et affiche le code final. Traquez trois défauts : les redirections vers une page introuvable, les chaînes, et les boucles. Voir le générateur de redirections.

Le jour de la mise en ligne

Une heure de contrôles, à faire dans cet ordre et immédiatement, pas le lendemain.

ContrôleComment vérifierLe risque
Le blocage de préproduction est retiréOuvrir /robots.txt et chercher les balises meta robots dans le code sourceLe site entier reste invisible pendant des semaines
Les redirections fonctionnentRejouer la liste complète sur l'environnement réelLa configuration du serveur diffère souvent de la préproduction
Une seule version du site est accessibleTester avec et sans www, en http et en httpsQuatre versions du même site, chacune diluant les signaux
Les balises canoniques pointent au bon endroitCode source de dix pagesCanoniques restées sur les adresses de préproduction
Le plan du site est régénéréOuvrir /sitemap.xmlUn plan qui liste encore les anciennes adresses
Les titres et descriptions sont bien làUn crawl rapide du nouveau siteUn gabarit qui écrase tout avec le même titre
La mesure d'audience fonctionneUne visite test, en temps réelBalise perdue : plus aucune donnée, et une fausse chute apparente
Le site s'affiche sur mobileUn vrai téléphone, pas seulement le simulateurUne refonte plus belle et moins utilisable
Refonte

La ligne où l'on peut tout perdre

Sur le devis d'une refonte, le plan de redirections est la ligne la moins chère et la seule dont l'oubli se paie pendant des années. Elle mérite d'être exigée par écrit.

Préparer une refonte

Relevé de l'existant, correspondances, contrôle après bascule.

Après : les quatre premières semaines

QuandCe qu'on regardeCe qui doit inquiéter
Jour 1Erreurs d'exploration dans la Search Console, plan du site soumisUn pic de pages introuvables
Jour 3Les pages principales sont-elles réexploréesAucune activité d'exploration sur le nouveau site
Semaine 1Positions sur les requêtes relevées avantUne baisse concentrée sur quelques pages : cherchez leur redirection
Semaine 2Nombre de pages indexéesIl ne remonte pas, ou il chute
Semaine 4Trafic comparé à la même période de l'année précédenteUn écart qui ne se réduit pas
Mois 3Bilan complet, page par pageToute page qui n'a pas retrouvé son niveau

Un flottement de deux à six semaines est normal, le temps que Google réexplore et réévalue. Une baisse qui persiste au-delà de deux mois n'est pas un délai d'adaptation, c'est un problème non traité. Voir perte de trafic après une refonte.

Ce qui tue vraiment une refonte

Questions fréquentes

Que faut-il faire avant une refonte pour ne rien perdre ?
Relever l'existant, et le relever complètement. Il faut la liste de toutes les adresses du site obtenue par un crawl, l'export des seize mois de la Search Console avec les pages et les requêtes, la liste des pages recevant des liens externes, et une capture des positions actuelles sur vos requêtes principales. Sans ce relevé daté, vous ne pourrez ni construire un plan de redirections complet ni prouver quoi que ce soit après la bascule.
Combien de temps dure la baisse de trafic après une refonte ?
Sur une refonte bien préparée, deux à six semaines de flottement puis un retour au niveau antérieur, souvent au-dessus si le contenu a été amélioré. Une baisse qui persiste au-delà de deux mois n'est pas un délai d'adaptation : c'est un problème non résolu, et neuf fois sur dix il s'agit du plan de redirections. Ne laissez jamais passer trois mois en espérant que cela se tasse.
Faut-il rediriger toutes les anciennes pages ?
Toutes celles qui reçoivent du trafic, des liens externes ou qui figurent dans l'index, ce qui représente presque toujours plus de pages que prévu. Chaque redirection doit pointer vers la page la plus proche en contenu, jamais vers la page d'accueil par défaut : une redirection vers l'accueil est traitée comme une page introuvable et ne transmet rien. Les pages sans trafic, sans lien et sans équivalent peuvent en revanche renvoyer une erreur assumée.
Comment tester un plan de redirections avant la mise en ligne ?
En passant la liste complète des anciennes adresses dans un outil qui suit les redirections et affiche le code de réponse final. Trois défauts à traquer : les redirections vers une page introuvable, les chaînes de plusieurs sauts, et les boucles. Ce test doit se faire sur l'environnement de préproduction avant la bascule, et se refaire dans l'heure qui suit la mise en ligne réelle, car la configuration du serveur diffère souvent.
Faut-il garder les mêmes URL lors d'une refonte ?
Oui chaque fois que c'est possible, et c'est possible bien plus souvent qu'on ne le croit. Conserver les adresses supprime le principal facteur de risque d'une refonte. Les modifier ne se justifie que si la structure actuelle est réellement problématique, et dans ce cas le changement se traite comme une migration à part entière, avec un plan de redirections testé. Changer les URL pour des raisons esthétiques est le meilleur moyen de perdre du trafic sans contrepartie.
Quelle est l'erreur la plus fréquente lors d'une mise en ligne ?
Oublier de retirer le blocage d'indexation de la préproduction. Le site part en ligne avec une directive qui interdit aux moteurs de l'explorer, et personne ne s'en aperçoit avant plusieurs semaines, parce que le site s'affiche parfaitement pour les visiteurs. C'est l'erreur la plus banale et la plus coûteuse : elle se vérifie en trente secondes dans le fichier robots.txt et dans les balises meta robots.

Sources