Migration site web sans perdre le référencement : protocole
La dernière migration que j'ai reprise avait été livrée un vendredi soir, sans plan de redirection. Le lundi, le trafic organique du client était à moitié de sa valeur habituelle, et l'agence qui avait piloté le chantier expliquait que Google allait se réhabituer. Il ne s'est rien réhabitué du tout. Trois cents anciennes URL renvoyaient un 404, dont la moitié captait l'essentiel des visites, et il a fallu six semaines pour remonter à un niveau qui restait sous l'ancien. Une migration ne perd pas de référencement par fatalité. Elle en perd quand on saute une des étapes que je vais détailler, et ces étapes tiennent presque toutes avant la bascule.
La cartographie exhaustive des URL est le socle de tout le reste
Avant de toucher au moindre gabarit, je liste toutes les URL que le site expose réellement, pas celles que le plan de site théorique prétend exposer. Une seule source ne suffit jamais. Je croise le sitemap XML, l'export complet des URL indexées depuis la Search Console (rapport de couverture et rapport de performances sur seize mois), un crawl maison qui suit tous les liens internes, et surtout les logs serveur des trois derniers mois, qui révèlent les URL que Googlebot visite et qu'aucun crawl frontal ne trouve, parce qu'elles ne sont plus liées nulle part mais restent indexées.
Ce croisement remonte toujours des surprises. Des vieilles pages de campagne avec des paramètres UTM figés dans l'index, des versions paginées, des URL en majuscules ou avec un slash final incohérent, des PDF téléchargés depuis des sites tiers. Sur un site de taille moyenne j'obtiens facilement quatre à cinq fois plus d'URL uniques que ce que le client imaginait avoir. Chacune est une porte d'entrée potentielle qu'un 404 fermerait. C'est exactement le travail que je décris dans mon audit technique avant refonte, et sur une reprise de site où le prestataire précédent est parti, cette cartographie est souvent la seule mémoire qui reste, comme je le raconte à propos de reprendre un site laissé par un prestataire parti.
Le plan de redirections 301 se construit par correspondance, jamais à la main URL par URL
Une fois la liste consolidée dans un tableur avec une colonne ancienne URL et une colonne nouvelle URL, la tentation est de tout mapper manuellement. Sur trois cents URL c'est jouable, sur cinq mille c'est une source d'erreurs garantie. Je raisonne par motifs. La plupart des migrations suivent des règles régulières : un préfixe qui change, une structure de catégorie qui se réorganise, une extension qui disparaît. Ces règles se traduisent en redirections à base d'expressions, et je ne mappe individuellement que les cas particuliers qui résistent au motif.
Voici à quoi ressemble un extrait de règles côté serveur, ici en syntaxe Apache, la logique étant la même quel que soit le serveur :
# Ancienne structure /produits/ref-123 vers /catalogue/ref-123 |
RedirectMatch 301 ^/produits/(.*)$ /catalogue/$1 |
# Suppression de l'extension .html |
RedirectMatch 301 ^/(.*)\.html$ /$1 |
# Cas particulier qui ne suit aucun motif, mappé à la main |
Redirect 301 /ancienne-page-phare /nouvelle-rubrique/page-phare |
La logique de mapping que j'applique est simple à énoncer et exigeante à tenir. Chaque ancienne URL doit pointer vers la nouvelle page la plus proche par le contenu, pas vers l'accueil. Une redirection massive vers la page d'accueil est traitée par Google comme un soft 404 et ne transmet quasiment aucune autorité. Si la nouvelle version n'a pas d'équivalent pour une ancienne page qui comptait, c'est le signe qu'il manque une page, et la bonne décision est souvent d'en créer une plutôt que de rediriger vers le haut de l'arbre. Une seule redirection par saut, aussi : une 301 vers une URL qui elle-même renvoie une 301 dilue le budget de crawl et ralentit la réattribution. Je réécris toujours les chaînes en saut direct.
La préservation des balises et du contenu se vérifie page à page, pas au jugé
Une refonte change le design, elle ne devrait pas changer le sens que Google a associé à chaque page. Concrètement, pour chaque URL qui compte, je vérifie que la balise title, la meta description, la structure de titres Hn, le contenu textuel principal et les données structurées survivent à la bascule. Le piège classique, c'est le nouveau gabarit plus léger visuellement qui ampute de moitié le corps de texte d'une page qui rankait précisément grâce à ce texte. Le design gagne en respiration, la page perd son positionnement.
Je porte une attention particulière aux balises canoniques, qui pointent souvent encore vers l'ancien domaine après un copier-coller de template, et aux balises hreflang sur les sites multilingues, qui cassent silencieusement dès qu'une URL de la grappe change sans que ses jumelles soient mises à jour. Sur les sites lourds, la migration est aussi le bon moment pour traiter les problèmes de performance qui traînaient, parce qu'un gabarit refait qui reste lent hérite des mêmes plaintes qu'avant, un sujet que je creuse dans pourquoi un WordPress lent plombe le PageSpeed.
Les Core Web Vitals se mesurent avant la bascule, pas en découverte après
La migration déplace le curseur de performance dans les deux sens. Un site refait sur une stack moderne gagne souvent en Largest Contentful Paint et en Cumulative Layout Shift, mais j'ai vu autant de refontes le dégrader, à cause d'un carrousel plein écran en haut de page, de polices web mal chargées, ou d'images servies sans dimensions et sans format moderne. Le bon réflexe, c'est de relever les trois métriques sur la préproduction, page type par page type, et de les comparer à la production actuelle mesurée sur données de terrain dans la Search Console. Une régression détectée en préproduction se corrige en une demi-journée. La même régression découverte trois semaines après la bascule, quand elle a déjà pesé sur le classement, coûte bien plus cher à diagnostiquer.
La recette sur préproduction est la dernière barrière avant les dégâts
Je ne bascule jamais un site sans une préproduction qui reproduit fidèlement la cible, redirections comprises. La préproduction doit être fermée à l'indexation, par une authentification HTTP ou un blocage au niveau du serveur, jamais par un simple noindex qu'on risque d'oublier de retirer et qui, s'il passe en production, désindexe tout le site en quelques jours. Sur cette préproduction je rejoue l'intégralité du plan de redirection avec un script qui prend ma liste d'anciennes URL et vérifie que chacune renvoie bien un code 301 vers la cible attendue, en une seule étape. Ce test automatisé sur la liste complète est le seul moyen de garantir qu'aucune règle n'a été oubliée ou qu'un motif trop large n'a pas capturé des URL qu'il ne devait pas toucher.
Je vérifie aussi que le fichier robots.txt de production n'interdit pas ce qu'il autorisait avant, que le sitemap XML reflète la nouvelle arborescence et pointe vers les nouvelles URL en 200, et que les pages de statut d'erreur renvoient bien les bons codes, un vrai 404 pour une page absente et non un 200 avec un message d'erreur, qui empoisonnerait l'index de pages vides.
La période de surveillance après bascule dure six semaines, pas deux jours
La bascule n'est pas la fin du chantier, c'est le début de la fenêtre où tout se joue. Dès la mise en production, je soumets le nouveau sitemap dans la Search Console pour accélérer le recrawl, et je surveille trois signaux en parallèle. Le premier, les logs serveur, où je filtre les réponses 404 en temps quasi réel pour rattraper toute URL oubliée dans le plan. Une commande aussi simple qu'un filtre sur le code de statut dans le journal d'accès révèle en quelques minutes ce que la Search Console mettra des jours à signaler, et croisée avec le referrer elle indique si le 404 vient d'un lien interne resté cassé ou d'une source externe.
Le deuxième signal, le rapport de couverture de la Search Console, qui montre la bascule des anciennes URL vers redirigée et l'apparition des nouvelles en indexée. Le troisième, la courbe de trafic organique, que je lis en tendance et non au jour le jour, en gardant en tête qu'une baisse de dix à quinze pour cent sur deux à quatre semaines est le comportement normal d'un recrawl, pas un signal d'alarme. Ce que je traque, c'est la courbe qui ne remonte pas passé six semaines, ou le pic de 404 qui trahit un trou dans le plan. Cette surveillance rejoint la logique de maintenance continue d'un site pour une agence : un site vit après sa mise en ligne, et la migration ne fait pas exception.
La refonte où perdre du trafic est le bon résultat
Tout ce protocole vise à ne rien perdre. Il y a pourtant des cas où viser zéro perte est une erreur. Quand un site a accumulé des centaines de pages minces produites à la chaîne, des articles vides écrits pour un mot-clé et jamais relus, des pages de villes dupliquées au copier-coller, chercher à préserver ce trafic revient à traîner un boulet dans la nouvelle version. Rediriger ces URL vers du contenu de qualité ne transfère pas de valeur, ça dilue le nouveau site avec des signaux que Google a déjà appris à ignorer, voire à pénaliser. Dans ces situations j'assume de laisser partir une part du trafic, en 410 pour les pages sans aucun signal et en 301 seulement pour celles qui gardent un backlink ou une intention utile. La courbe baisse sur le volume, la qualité moyenne des pages restantes monte, et le site regagne en quelques mois sur des positions qui tiennent. Distinguer le trafic qu'on protège de celui qu'on assume de perdre est un travail éditorial autant que technique, et c'est typiquement là qu'un binôme entre l'agence qui connaît le fond et moi qui tient la technique fait la différence, dans le cadre d'une sous-traitance de développement web pour agence ou d'un partenariat agence durable.
Une dernière limite honnête : ce protocole réduit fortement le risque, il ne l'annule pas. Google reste une boîte partiellement opaque, et même une migration irréprochable connaît une phase de flottement où les positions oscillent pendant que l'index se recompose. La différence entre une bonne migration et une mauvaise n'est pas l'absence totale de secousse, c'est que dans un cas la courbe redescend puis remonte au-dessus en deux mois, et dans l'autre elle s'effondre et reste au sol faute de plan.