Migrer un site sans perdre son SEO : la méthode

Pourquoi une refonte fait perdre du trafic

Une refonte ne fait pas perdre de positions parce que le site est neuf. Elle en fait perdre parce que des adresses changent sans que personne ne s’en rende compte : un slash final qui apparaît, une extension .html qui se glisse dans les liens, une ancienne page qu’on oublie de rediriger, une redirection qui en appelle une autre. Chacune de ces erreurs est invisible à l’œil nu, et chacune casse le lien entre l’historique d’une page et sa nouvelle version.

La bonne nouvelle, c’est que ces erreurs se contrôlent par programme. Tout ce que nous décrivons ici est automatisable, et c’est la seule façon de le faire sérieusement sur plusieurs centaines d’adresses.

Le cas : un Drupal 7 de 233 adresses et 17 ans d’historique

Nous menons en ce moment la migration du site d’une agence digitale d’une vingtaine de personnes. Point de départ : un site sous Drupal 7, dont le support officiel est terminé, avec 233 adresses déclarées dans son sitemap et dix-sept ans d’historique de recherche. Destination : un site statique construit avec Astro, servi depuis le même hébergeur, avec les mêmes adresses.

La bascule n’est pas encore faite au moment où nous écrivons. Nous décrivons donc la méthode et les contrôles, et ce qu’ils ont trouvé en route. Les mesures avant/après seront publiées après la mise en ligne, pas avant.

Étape 1 : recenser les pages qui existent vraiment

La première surprise d’une migration, c’est qu’on ne sait pas combien de pages on migre. Sur ce projet, les documents de départ citaient 233, 243, 253, 258 ou 279 « pages » selon ce qu’ils comptaient. Aucun n’était faux, chacun comptait autre chose.

Nous avons donc recrawlé le site en production, en suivant tous les liens internes depuis le sitemap et la page d’accueil, puis en normalisant les chemins. Résultat :

• 233 adresses déclarées dans le sitemap ;
• 506 chemins distincts qui répondent 200 ;
• 239 adresses canoniques distinctes, le chiffre de référence, ce que Google indexe ;
• 263 alias, c’est-à-dire des chemins qui répondent 200 alors que leur canonique est une autre adresse (anciennes adresses Drupal en /node/123, articles publiés deux fois, anciennes adresses de services).

Ces 263 alias sont le cœur du sujet. Ils fonctionnent aujourd’hui parce que Drupal les sert. Le jour où Drupal s’éteint, chacun devient une 404 s’il n’est pas redirigé. Ils sont donc tous entrés dans le plan de redirections, un par un. Ce recensement est aussi la première étape d’un audit SEO technique, qui le complète par ce que le serveur sert réellement aux robots.

En parallèle, nous avons croisé le recensement avec seize mois de données Search Console pour isoler les 50 adresses qui portent l’essentiel des clics. Elles forment une liste gelée, « les pages à ne pas casser », qui sert de référence au contrôle d’après bascule. Une seule de ces adresses en 404 serait du trafic détruit, et c’est sur elles que la recette commence.

Étape 2 : garder les mêmes adresses, par défaut

La règle la plus rentable d’une migration est aussi la plus simple : une adresse ne change que s’il y a une raison éditoriale de la changer, et alors elle passe par le plan de redirections, page par page. Par défaut, rien ne bouge.

Cela paraît évident, mais la technique s’y oppose souvent. Le site d’origine sert ses pages sans extension et sans slash final (/blog/un-article). Un générateur statique, lui, produit des fichiers : sans réglage, il crée des adresses avec slash ou avec .html. Nous avons donc fixé le contrat dans la configuration d’Astro (pas de slash final, un fichier .html par page servi sans son extension) et écrit une seule fonction qui calcule la canonique de chaque page. Pourquoi une fonction dédiée : au build, Astro expose le chemin de la page avec son extension. Une canonique écrite naïvement aurait porté le .html, et c’est précisément le défaut qui avait fait échouer une première tentative de migration du même site, avec des milliers de liens internes en .html.

Le template fait aussi un travail de garde-fou : une page sans meta description, ou un article sans rattachement à un cocon, ne se construit pas. Le build échoue, et la page incomplète ne peut pas partir en ligne par inadvertance.

Étape 3 : rediriger en un seul saut

Google suit les chaînes de redirections, mais recommande de rediriger directement vers la destination finale, et de garder les redirections le plus longtemps possible, en général au moins un an (documentation Google sur les déménagements de site avec changement d’URL). Les redirections doivent être permanentes, en 301 ou 308.

Le plan de redirections vit dans un fichier de données, et le fichier de configuration du serveur (.htaccess) est écrit à partir de lui à chaque construction. Sur ce projet, cela a révélé un piège que nous n’avions pas vu venir. Le plan disait deux choses vraies : une ancienne adresse Drupal mène à un article, et cet article a été renommé lors d’une réécriture. Résultat, deux anciennes adresses faisaient deux sauts au lieu d’un, dont l’une menait vers l’article le plus visité du site.

La correction a consisté à suivre les chaînes au moment de la construction : chaque ancienne adresse est résolue jusqu’à sa destination finale, et une boucle ou une adresse redirigée deux fois arrête la construction. Le plan garde son histoire, le serveur ne fait qu’un saut. Preuve rejouée en HTTP : 265 anciennes adresses déclinées sous quatre formes (sans rien, avec .html, avec slash final, avec un paramètre de suivi), soit 1 060 cas. Avant la correction, 1 052 aboutissaient en un saut ; après, les 1 060.

Le même banc a trouvé une autre faille, plus discrète. Onze adresses du site sont à la fois une page et un dossier (/blog, /services, plusieurs pages de services avec des sous-pages). Une première version des règles du serveur les excluait de la redirection du slash final : /services/ n’aurait été ni redirigée ni servie. Parmi elles figuraient les deux pages de services qui recevaient le plus d’impressions. Corrigé avant toute mise en ligne, parce qu’un test l’a vu.

Étape 4 : des contrôles automatiques avant chaque commit

Le cœur de la méthode, c’est qu’aucune vérification ne repose sur la mémoire de quelqu’un. Six contrôles tournent sur le site construit avant chaque commit :

1. Le contrat d’adresses : chaque page construite est comparée aux adresses canoniques de référence, la canonique et l’og:url doivent être exactes, aucun lien interne ne doit porter .html ou un slash final, et chaque ancienne adresse du plan doit mener en un saut vers une page construite.
2. La matrice de comportements : un petit serveur local rejoue les règles exactes du serveur cible, et 26 cas sont testés (extension, slash final, index, dossiers réels, paramètres conservés à la redirection, 404).
3. La fidélité du contenu : les passages de texte de chaque page sont comparés à la source, pour qu’aucun paragraphe ne disparaisse à la conversion.
4. Les ressources : aucune page ne doit charger un fichier depuis l’ancien site ou un domaine tiers non autorisé.
5. Le SEO de base : un seul H1, title et description présents et uniques, données structurées valides.
6. Le rendu : chaque page est ouverte dans un navigateur sans interface, et la couleur de chaque texte est mesurée contre son fond.

Ce sixième contrôle est né d’une capture d’écran : un titre bleu foncé sur une bannière marine, illisible. Le contrôle a ouvert les 243 pages construites, mesuré près de 30 000 textes en une vingtaine de secondes, et trouvé 54 titres dans le même cas, répartis sur trois composants. La cause était une seule règle de style globale. Corrigée à la racine, le contrôle repasse à zéro erreur, sur ordinateur comme sur mobile. Aucun des cinq autres contrôles ne pouvait le voir, parce qu’ils lisent le HTML, pas la page affichée.

Étape 5 : préproduction privée, puis bascule surveillée

Avant la mise en ligne, le site construit tourne sur une adresse de prévisualisation protégée par mot de passe, avec un en-tête noindex et un robots.txt fermé. Le client valide à l’écran, et rien n’entre dans un index par erreur.

La bascule elle-même suit un ordre précis :

• la matrice de comportements est rejouée contre la préproduction, puis contre la production, en changeant seulement l’adresse de base ;
• le sitemap ne déclare que les adresses canoniques, et il est soumis dans la Search Console ;
• le relevé Search Console d’avant est rejoué après, page par page, en commençant par les 50 pages à ne pas casser ;
• les mesures de performance sont rejouées avec le même outil, sur la même machine, pour que la comparaison tienne ;
• la chaîne de publication garde chaque version, et un retour arrière se fait en une commande.

À noter : certaines redirections sont attendues et saines. Sur le site d’origine, une adresse avec et sans slash final répondaient toutes les deux 200, ce qui créait du contenu en double. Après la bascule, la variante avec slash redirige vers la canonique. Au relevé d’après, ces 301 ne sont pas des pertes, ce sont des consolidations.

Ce que nous en retenons

• Les erreurs de migration les plus coûteuses sont celles qu’on ne voit pas à l’écran. Il faut un banc de test, pas une relecture.
• Le recensement vient avant tout le reste. Tant qu’on ne sait pas combien d’adresses le site sert réellement, on ne sait pas ce qu’on doit rediriger.
• Chaque défaut trouvé devient un contrôle. C’est ce qui empêche le même problème de revenir trois semaines plus tard sur une autre page.

C’est la méthode de notre migration vers un site statique, et quand l’historique de trafic est important, nous commençons par un audit SEO qui établit la liste des pages à protéger. Pour situer la migration dans une stratégie de visibilité plus large, voyez ce qu’une agence SEO IA doit vraiment livrer.

Questions fréquentes

Sources

1. Documentation Google sur les déménagements de site avec changement d’URL (nouvel onglet)developers.google.com