Refondre son site sans perdre son référencement

Le scénario se reconnaît au téléphone. Le nouveau site est en ligne depuis trois semaines, tout le monde le trouve superbe, et le trafic organique a fondu de moitié. Personne ne comprend, parce que personne n'a rien cassé. C'est justement le problème : la refonte a été traitée comme un projet de design, alors que le référencement vit dans la plomberie. C'est la partie qu'on prend en charge dans un abonnement, et celle qu'on récupère le plus souvent après coup.

Google n'indexe pas votre design, il indexe des adresses. Chaque URL de votre site actuel porte un historique : des liens externes, un classement, des données accumulées. Changez l'adresse sans dire à Google où la page est partie, et cet historique reste attaché à une porte qui ne s'ouvre plus.

Cet article est le compagnon technique de notre texte sur quand et comment refondre un site, dans l'ordre réel des opérations : ce qu'il faut noter avant de commencer, pourquoi la meilleure redirection est celle qu'on évite, ce qu'on vérifie le jour du lancement, et quelle baisse est normale ensuite.

La réponse courte, pour les pressés

Une refonte fait rarement perdre du référencement à cause du nouveau design. Elle en fait perdre parce que les adresses des pages changent et que personne n'a noté, avant de commencer, quelles pages rapportaient. La séquence qui protège le trafic tient en quatre temps. D'abord, exportez de la Search Console les pages et les requêtes qui génèrent vos clics : Google ne conserve que seize mois de données, et vous ne pourrez pas remonter le temps après coup. Ensuite, conservez les adresses existantes chaque fois que c'est possible, parce qu'une redirection évitée est une redirection qui ne peut pas mal tourner. Pour les adresses qui changent vraiment, écrivez une correspondance page par page et servez des redirections permanentes 301 côté serveur, à garder au moins un an. Enfin, vérifiez au lancement que le noindex du site de préproduction n'a pas été publié en production. Google prévoit quelques semaines de fluctuation.

L'inventaire, avant de toucher à quoi que ce soit

C'est l'étape que tout le monde saute, et la seule qui est irrécupérable. La Search Console conserve seize mois de données, pas davantage, c'est écrit dans la documentation de Google. Une fois la refonte lancée, vous ne pourrez pas reconstruire ce que vous aviez.

Exportez trois listes avant le premier coup de pioche. Les pages qui reçoivent des clics organiques, triées par clics sur douze mois. Les requêtes qui les amènent. Et les adresses réellement indexées, que le rapport d'indexation présente sous forme de listes d'exemples plafonnées à 1 000 URL ; au-delà, l'API Search Analytics accepte jusqu'à 25 000 lignes par requête, contre 1 000 par défaut.

Cet inventaire sert deux fois. Il dit quelles pages doivent survivre à la refonte, et la réponse surprend presque toujours : ce sont rarement celles dont on parle en réunion. Un billet de blogue de 2019 sur une question précise de votre métier rapporte souvent plus de demandes que la page « À propos ». Et il donne, trois mois plus tard, la seule référence honnête pour savoir si vous avez perdu quelque chose.

La meilleure redirection est celle qu'on n'a pas eu à faire

Une redirection est une réparation. Elle fonctionne bien, mais elle n'est jamais gratuite : elle ajoute un aller-retour pour l'utilisateur, elle peut être mal écrite, et elle finit par disparaître le jour où quelqu'un nettoie un fichier de configuration.

Google est explicite dans sa documentation de l'outil de changement d'adresse : conserver la même architecture au nouvel emplacement aide à transmettre les signaux plus directement, et combiner un déménagement avec une refonte du contenu et de la structure des adresses fera probablement perdre du trafic, parce que Google doit réapprendre et réévaluer les pages une à une. La même documentation recommande de ne changer qu'une chose à la fois.

La conséquence pratique est peu spectaculaire : refaites le design, gardez les adresses. Si le nouveau système de gestion impose ses propres formats d'URL, la question est budgétaire avant d'être technique. Ou bien on le configure pour reproduire les adresses existantes, ou bien on paie une migration complète, avec sa carte de redirections et sa surveillance. Le pire des deux mondes reste de découvrir cette contrainte la semaine du lancement.

Une carte page par page, jamais « tout vers l'accueil »

Pour les adresses qui changent malgré tout, chaque ancienne URL doit pointer vers la page qui remplace vraiment son contenu.

La faute classique est de tout rediriger vers la page d'accueil, parce que c'est une seule ligne de configuration. Google écarte explicitement cette méthode : ne redirigez pas beaucoup d'anciennes adresses vers une seule destination sans rapport, comme l'accueil du nouveau site, parce que ça désoriente les visiteurs et que ça peut être interprété comme une erreur « soft 404 ». En revanche, si vous avez fusionné plusieurs pages en une seule, rediriger les anciennes vers la page consolidée est correct.

Trois règles suffisent pour le reste. Utilisez des redirections permanentes côté serveur, 301 ou 308 : Google les traite comme un signal fort que la nouvelle adresse est la bonne, alors qu'une 302 ou une 307 est un signal faible qui laisse l'ancienne adresse dans les résultats. Redirigez directement vers la destination finale : Googlebot suit jusqu'à dix sauts, mais la recommandation officielle est de rester sous trois et de ne jamais dépasser cinq. Et gardez ces redirections au moins un an, le temps que Google transfère les signaux et que les sites qui pointent vers vous mettent leurs liens à jour.

Assumez enfin les vraies suppressions. Une page sans équivalent doit répondre 404 ou 410 plutôt que d'être redirigée n'importe où : Google retire alors l'adresse de son index, ce qui est le comportement souhaité.

La refonte qui supprime discrètement ce qui fonctionnait

L'autre moitié du problème est dans le contenu. Un site de quarante pages devient huit pages magnifiques, et les trente-deux pages disparues emportaient l'essentiel du trafic de recherche. Techniquement, tout est propre. Commercialement, vous venez d'éteindre votre principal canal d'acquisition.

C'est là que l'inventaire redevient utile. Avant de valider l'arborescence du nouveau site, passez la liste des pages qui reçoivent des clics et posez une question par page : où va ce contenu ? Trois réponses sont acceptables : il reste tel quel, il est fusionné dans une page plus complète, ou il est supprimé en connaissance de cause.

La perte est souvent plus subtile qu'une suppression. Le texte qui expliquait votre service en six paragraphes devient une bannière de trois mots. Le contenu passe dans un carrousel qui n'affiche qu'une diapositive à la fois. Les titres de page, écrits un par un pendant des années, sont régénérés par le nouveau système sous la forme « Accueil - Nom de l'entreprise ». Chacun de ces gestes se défend en design, et chacun retire à Google une partie de ce qui vous faisait trouver.

Le jour du lancement

Un seul point cause à lui seul plus de dégâts que tous les autres réunis. Le site de préproduction est presque toujours protégé par une règle noindex ou un blocage robots.txt. Publier le nouveau site sans retirer cette protection est la première erreur listée par Google dans sa page de dépannage des migrations, et elle est invisible : le site s'affiche parfaitement pour les visiteurs pendant que Google le retire de son index. Deux pièges vont avec : Google ne prend pas en charge la directive noindex écrite dans robots.txt, et un blocage robots.txt empêche Googlebot de voir la balise noindex posée dans la page.

Le reste se vérifie en une heure. Chaque nouvelle page porte une balise canonique qui pointe vers elle-même. Sur un site bilingue, les annotations hreflang utilisent les nouvelles adresses. Le nouveau plan de site est soumis dans la Search Console. Les liens internes pointent vers les nouvelles adresses plutôt que de transiter par les redirections. Et si le domaine change vraiment, l'outil de changement d'adresse transmet les signaux de l'ancien site vers le nouveau pendant 180 jours ; il ne sert ni pour un passage de HTTP à HTTPS, ni pour un www vers non-www, ni pour un déplacement de chemins dans le même domaine. Profitez-en pour mesurer la vitesse du nouveau site, pendant que les corrections restent bon marché.

Ce qui est normal, ce qui est une urgence

Google le dit sans détour : attendez-vous à des fluctuations temporaires de classement, et comptez quelques semaines pour qu'un site de taille petite à moyenne finisse de bouger dans l'index. Voir l'ancienne adresse réapparaître de temps en temps dans les résultats est normal aussi, Google gardant les deux versions un moment. Notre article sur le temps que prend le SEO donne les mêmes ordres de grandeur.

Quatre choses, en revanche, se corrigent le jour même. Un noindex en production. Un blocage robots.txt oublié. Une explosion d'erreurs « introuvable » dans la Search Console, en général parce que les redirections pointent vers des adresses inexistantes sur le nouveau site, l'autre erreur fréquente relevée par Google. Et des pages de votre inventaire qui ne reçoivent plus aucune impression après trois semaines. Si un site de préproduction s'est retrouvé indexé, l'outil de suppression le masque environ six mois sans empêcher l'exploration : pansement utile, la correction reste le 404 ou le noindex.

Gardez enfin les deux plans de site : le nombre de pages indexées de l'ancien doit descendre vers zéro pendant que celui du nouveau monte, et les avertissements sur les URL qui redirigent sont attendus. Prévoyez aussi de la capacité serveur, parce que Google explore le nouveau site plus intensément qu'à l'habitude après une migration.

Rien de tout cela ne se décide pendant la refonte. Tout se décide avant, à partir d'une liste que la plupart des entreprises n'ont jamais faite. C'est exactement ce qu'on produit dans un audit : l'état des lieux de ce qui fonctionne aujourd'hui, avant qu'il devienne impossible de le savoir.

→ Demandez un audit avant votre refonte