Refonte de site sans perte de classement : planification, redirections et suivi

Imaginons une entreprise de services dont le site date d'il y a huit ans. Depuis, trois personnes ont ajouté des contenus, un blog a été lancé puis délaissé, et certaines pages de prestations ont été copiées et légèrement modifiées. Le site paraît daté, se charge lentement et est pénible à utiliser sur smartphone. La refonte est décidée.

Ce qui manque le plus souvent, c'est une image de ce que l'ancien site apporte réellement. Tout le monde connaît la page d'accueil. Mais parmi les quatre cents adresses, lesquelles amènent des visiteurs, lesquelles sont citées par d'autres sites, lesquelles figurent depuis des années dans l'index sans que personne ne les voie ? Sans cette réponse, toute décision sur la nouvelle structure est un pari.

La crainte de pertes est fondée. Pour les moteurs de recherche, une refonte n'est pas une mise à jour esthétique, mais une reprise en sous-œuvre : les adresses changent, les textes sont raccourcis, la navigation et le maillage interne sont recréés. Après la mise en ligne, Google évalue en principe un nouveau site, censé prolonger l'historique de l'ancien.

Les causes sont rarement exotiques. Le plus souvent, les redirections manquent : le nouveau site a d'autres adresses, et les anciennes ne mènent nulle part ou aboutissent en bloc à la page d'accueil. Google n'y voit pas un déménagement, mais la disparition de pages. Les signaux attachés à ces adresses s'évaporent, de même que les liens d'autres sites qui y pointaient.

Presque aussi fréquents sont les contenus « nettoyés » lors de la refonte. Un texte qui figurait depuis des années en première page pour une requête précise est raccourci parce qu'il paraît trop long dans la nouvelle mise en page. Les titres sont reformulés sur un ton plus publicitaire, et le mot-clé que les gens recherchent réellement disparaît.

S'y ajoutent des erreurs techniques qu'on ne remarque qu'après la mise en ligne : un blocage d'indexation de l'environnement de staging qui a été déplacé avec le reste, un robots.txt qui exclut tout, des balises canonical absentes, des données structurées perdues, un sitemap contenant d'anciennes adresses. Aucune de ces erreurs n'est difficile à éviter. Elles surviennent quand personne ne tient de liste.

Avant de redessiner quoi que ce soit, il faut un inventaire fiable. Il combine trois sources, car chacune a ses angles morts. Un crawl, par exemple avec Screaming Frog, fournit toutes les adresses accessibles avec leur code de statut, titre, intertitres, canonical et maillage interne. Il montre ce qu'est le site sur le plan technique.

La Search Console montre ce que Google en fait : quelles pages obtiennent des impressions et des clics, pour quelles requêtes, à quelle position. On y constate souvent que quelques pages portent l'essentiel de la visibilité et que des sous-pages en apparence sans importance apportent discrètement des demandes. Une période d'au moins douze mois lisse les variations saisonnières.

La troisième source est le profil de backlinks. Vers quelles adresses d'autres sites, annuaires ou pages de presse pointent-ils ? Une page avec peu de trafic mais plusieurs liens de qualité mérite plus de soin que son trafic ne le laisse penser. Les rapports de la Search Console suffisent pour cela, complétés par l'outil de backlinks de votre choix.

Le résultat est un tableau dans lequel chaque URL connue figure avec son code de statut, ses clics, ses impressions, ses liens entrants et sa requête principale. C'est le document de travail pour tout le reste.

Du tableau d'inventaire naît l'inventaire des contenus. Chaque page reçoit l'une de quatre décisions. Conserver : la page fonctionne, l'adresse et le contenu restent. Retravailler : le sujet est porteur, mais le texte ou la structure sont faibles. Fusionner : plusieurs pages similaires se concurrencent sur la même requête et deviennent une seule page plus forte. Supprimer : la page n'a plus d'utilité.

Supprimer ne signifie pas effacer sans laisser de trace. Pour les pages qui disparaissent aussi, on cherche une destination pertinente, en général la page la plus proche sur le plan thématique. S'il n'y en a pas et que l'adresse n'a ni trafic ni liens, un code de statut 410 ou 404 propre est une réponse plus honnête qu'une redirection vers une page inadaptée. L'expérience montre que Google traite une redirection vers un contenu sans rapport comme un soft 404.

Sur la question de savoir s'il faut vraiment modifier la structure des adresses, la retenue s'impose. Une nouvelle navigation ou un nouveau design n'exigent pas de nouvelles URL. Chaque adresse qui peut rester est un risque en moins. Ne changez les adresses que si le système de gestion de contenu l'impose ou si la structure actuelle cause des problèmes avérés.

Le mapping d'URL est le tableau qui associe chaque ancienne adresse à une seule nouvelle. Cela ressemble à un travail de fourmi, et c'en est un, mais c'est ici que se décide le transfert des signaux. Chaque ligne contient l'ancienne URL, l'URL cible, le code de statut souhaité et une note justificative. Lorsque plusieurs anciennes pages ont été fusionnées, plusieurs lignes pointent vers la même cible.

La cible doit traiter le même sujet, pas une vague parenté thématique. Une ancienne page sur l'« entretien de chauffage » doit aller vers la nouvelle page d'entretien, pas vers un aperçu général des prestations. On vérifie en outre que l'URL cible répond elle-même avec le statut 200 et ne redirige pas à son tour.

C'est là que réside le danger des chaînes. Si une refonte antérieure a redirigé l'adresse A vers B et que le nouveau B mène à C, on obtient A, B, C. Chaque étape intermédiaire coûte du temps de chargement et augmente le risque que quelque chose se rompe. La règle : chaque ancienne URL redirige en une seule étape directement vers la cible finale. Pour cela, l'héritage des redirections antérieures doit lui aussi entrer dans le tableau.

Le standard pour les déménagements permanents est le code de statut 301 (ou 308). Google a confirmé qu'un 302 finit lui aussi par transmettre les signaux au bout d'un moment, mais un déménagement permanent devrait aussi être signalé comme permanent.

On construit sur un environnement de staging qui doit être invisible pour les moteurs de recherche. La solution la plus fiable est une protection d'accès par mot de passe ou restriction d'IP. Une directive noindex est la seconde sécurité, mais un robots.txt avec Disallow seul ne suffit pas, car des adresses bloquées peuvent tout de même apparaître dans l'index si elles sont liées. De plus, Google ne peut pas lire un noindex s'il n'a pas le droit de récupérer la page.

Sur le staging, on ne fait pas que dessiner : on compare. Titres, méta-descriptions, titres principaux, canonical, hreflang (si le site est multilingue) et données structurées issus du crawl de l'ancien site sont confrontés à ceux du nouveau. Un rapport de différences montre chaque écart. Tous ne sont pas des erreurs, mais chacun devrait être une décision consciente.

Pour la structure des titres, une règle simple s'applique : une page a exactement un H1 qui porte le sujet, avec en dessous un plan compréhensible. Les nouveaux templates utilisent souvent les titres comme outil de mise en forme et détruisent ainsi la structure. Les liens internes doivent eux aussi pointer, dans le nouveau système, vers les nouvelles adresses, pas vers les anciennes qui ne sont corrigées que par redirection.

Les données structurées, comme Organization, LocalBusiness, FAQPage ou Article selon schema.org, migrent rarement toutes seules. Elles sont générées à nouveau dans le nouveau template et vérifiées avec le test des résultats enrichis.

La mise en ligne est un déroulement avec des points de contrôle fixes, pas un clic sur un bouton. La veille, le tableau de mapping est prêt sous forme de règles de redirection dans le serveur ou le système et a été testé sur le staging contre chaque ancienne URL. Le jour même, le nouveau site est d'abord mis en ligne, puis le blocage d'indexation est retiré, puis on vérifie. L'ordre est important, car aucune étape ne remplace le contrôle de la précédente.

Le blocage est particulièrement critique. La protection par mot de passe, la balise meta noindex et l'en-tête X-Robots-Tag doivent disparaître, et le robots.txt ne doit exclure rien de ce qui doit être indexé. Ne le vérifiez pas dans le back-office, mais à l'adresse réelle : code source de la page d'accueil, en-têtes de réponse, robots.txt, inspection d'URL dans la Search Console.

Ensuite, le nouveau sitemap XML avec les adresses définitives est soumis, pas l'ancien. Des échantillons issus du mapping confirment que les redirections mènent en une étape vers une cible en 200. Les pages les plus importantes sont soumises une à une à l'indexation dans la Search Console.

Si le domaine reste le même, la refonte est une rénovation dans la même maison. S'il change, par exemple à la suite d'un changement de nom, c'est un déménagement dans une autre maison, et le risque est nettement plus élevé. Outre le mapping d'URL, il faut alors des redirections de l'ancien domaine vers le nouveau, y compris pour la variante avec et sans www ainsi que pour http et https.

Dans la Search Console, les deux domaines sont créés comme propriétés et l'outil de changement d'adresse est utilisé pour l'ancien domaine. Les redirections devraient rester en place au moins un an, mieux plus longtemps, tant que des liens ou des utilisateurs accèdent encore à l'ancienne adresse. Celui qui désactive tôt l'ancien domaine coupe des signaux qui sont encore en route.

Parmi les autres cas particuliers figurent les sites multilingues avec hreflang, où chaque version linguistique doit renvoyer correctement vers les autres, les URL à paramètres et les pages de filtres, les médias et fichiers PDF liés depuis l'extérieur, ainsi que les sous-domaines. Il faut aussi vérifier les services intégrés et les formulaires, car une source de demandes importante peut dépendre d'une adresse à laquelle personne ne pensait.

Autre écueil : le changement de système lui-même. Les nouveaux systèmes de gestion de contenu génèrent souvent leurs propres schémas d'adresses, ajoutent ou suppriment des barres obliques finales, convertissent les adresses en minuscules ou servent la même page sous plusieurs chemins. Cela crée des doublons que Google doit fusionner laborieusement. Définissez au préalable quelle graphie fait foi et imposez-la par des redirections et la balise canonical.

Les contenus qui ne sont générés que dans le navigateur par JavaScript méritent eux aussi un examen. Si le nouveau système n'affiche textes et liens que côté client, un robot d'exploration risque de voir très peu de choses lors de la première requête. Comparer le code source avec le résultat rendu, par exemple avec l'inspection d'URL de la Search Console, montre vite si l'essentiel du contenu arrive de façon fiable.

Une recommandation honnête : dans la mesure du possible, ne combinez pas changement de domaine, changement de système et refonte complète du contenu en une seule étape. Moins il y a de variables qui changent en même temps, plus il est facile d'attribuer les fluctuations par la suite.

Il n'y a pas de garanties ici, et celui qui en promet en promet trop. Google doit explorer à nouveau la nouvelle structure, suivre les redirections et réévaluer les pages. L'expérience montre que, dans les premiers jours et les premières semaines, des fluctuations apparaissent dans les positions et les clics, même avec une mise en œuvre propre. C'est normal et ce n'est pas une raison de paniquer.

L'essentiel est de replacer le mouvement dans son contexte. Un léger va-et-vient sur certaines requêtes est tout autre chose que l'effondrement de groupes entiers de pages. Ce dernier signale un problème précis que l'on peut trouver dans les données : une zone qui n'est pas indexée, un motif d'erreurs 404, une règle de redirection défectueuse.

La mesure s'appuie sur les rapports de la Search Console : état de l'indexation, statistiques d'exploration, erreurs 404, clics et impressions par rapport à la période précédant la refonte. Les journaux du serveur montrent en complément si Googlebot demande les nouvelles adresses. Prévoyez de plusieurs semaines à quelques mois avant d'obtenir une image stable.

De meilleurs temps de chargement, une structure propre et des contenus plus clairs peuvent conduire à une meilleure visibilité après la refonte. Il n'est pas possible de s'engager sérieusement à ce sujet, car la concurrence et les algorithmes y jouent un rôle.

Le principe le plus important : une refonte est un projet de migration avec une part de design, et non l'inverse. Celui qui n'intègre le SEO qu'avant la mise en ligne ne peut plus que sauver les meubles. Celui qui l'intègre dès le début peut décider de ce qui est conservé et aligner la structure des pages sur ce que les visiteurs trouvent déjà.

Deuxièmement : conserver est une stratégie légitime. Toutes les adresses, tous les titres et tous les textes n'ont pas à être nouveaux. Ce qui fonctionne bien dans Google reste d'abord intact. Vous pourrez améliorer plus tard, par petites étapes, avec une comparaison avant-après propre.

Troisièmement : la documentation protège. Le tableau de correspondances, l'exploration de l'ancien état et la liste de contrôle de mise en ligne ne sont pas de la bureaucratie, mais les archives qui permettront d'expliquer dans trois mois pourquoi une page est différente d'avant. Les erreurs se circonscrivent ainsi rapidement, au lieu de chercher dans un brouillard de suppositions.

La crainte de perdre des positions est fondée, mais maîtrisable. La plupart des pertes ne viennent pas de ce qui est nouveau, mais de ce qui se perd sans être remarqué : des adresses sans redirection, des contenus supprimés, des blocages restés en place. Il existe pour cela une méthode composée d'un inventaire, d'une table de correspondances, d'une comparaison avec la préproduction, d'une liste de contrôle et d'un suivi.

C'est pourquoi nous commencerions une telle refonte par l'état des lieux, avant même qu'une maquette existe. Le résultat est une base de décision sobre : quelles pages portent le site et lesquelles non, où une nouvelle structure se justifie et où une nouvelle présentation suffit. Ensuite, on peut dire honnêtement quel est le niveau de risque.

Une prochaine étape judicieuse est un court contrôle de votre site actuel : exploration, analyse de la Search Console et évaluation des pages qui méritent une protection particulière. On en déduit si une refonte est nécessaire, dans quelle ampleur et avec quel effort.