Migration de site web : ne pas perdre son référencement
Une migration de site web conserve son référencement quand chaque ancienne URL pointe vers son équivalent exact par une redirection permanente, sans intermédiaire. Le reste tient à trois gestes : cartographier l’existant, tester le mapping avant la bascule, surveiller l’indexation pendant six semaines. Les pertes viennent presque toujours d’un plan de redirections incomplet.
Ce qui se perd réellement quand les URL changent
Un préjugé tenace veut qu’une redirection dilue le « jus » transmis par un lien. Gary Illyes, ingénieur chez Google, a démenti ce point publiquement en juillet 2016 : les redirections 3xx ne font plus perdre de PageRank. La perte se joue ailleurs, et elle est presque toujours humaine.
La documentation Google Search Central distingue deux familles de codes. Les codes 301 et 308 signalent un déplacement permanent : le robot suit la redirection et le système d’indexation retient la destination comme URL canonique. Les codes 302, 303 et 307 sont suivis eux aussi, sans transmettre ce signal de canonisation. Choisir le mauvais code revient à demander à Google de garder l’ancienne adresse dans son index.
Ce qui disparaît vraiment lors d’une refonte tient en quatre lignes :
- Les URL oubliées dans le mapping, qui renvoient une erreur alors qu’elles recevaient du trafic
- Le maillage interne recomposé, quand les nouveaux gabarits suppriment des liens contextuels
- Les contenus raccourcis ou fusionnés, qui ne répondent plus à la même intention de recherche
- Les redirections empilées, qui allongent le chemin du robot sans contrepartie
Un site qui change d’adresse sans toucher à ses textes retrouve ses positions. Un site qui change d’adresse et réécrit la moitié de ses pages au passage mélange deux chantiers, puis se révèle incapable d’expliquer la baisse constatée. Séparez les deux opérations : migrez d’abord, éditez ensuite, à quelques semaines d’écart.
Cartographier l’existant avant de toucher au moindre fichier
Aucune source ne connaît à elle seule la totalité de vos URL. Un inventaire fiable naît du croisement d’au moins quatre exports, fusionnés dans un tableur unique qui devient la référence du projet jusqu’à sa clôture.
| Source | Ce qu’elle apporte | Sa limite |
|---|---|---|
| Crawl complet du site | La structure telle qu’un robot la parcourt | Ignore les pages orphelines, non liées |
| Fichier sitemap.xml | Les URL que le site déclare officiellement | Souvent périmé ou partiel |
| Search Console | Les pages qui reçoivent réellement des impressions | Historique limité à seize mois |
| Journaux du serveur | Tout ce que robots et visiteurs demandent | Volume brut, à filtrer |
| Profil de liens entrants | Les pages qui portent l’autorité du domaine | Dépend de l’index de l’outil retenu |
Le tableau final porte une colonne par décision : adresse d’origine, adresse de destination, code de réponse attendu, priorité. Les pages qui concentrent le trafic et les backlinks de qualité passent en tête de liste, parce qu’une erreur sur ces adresses coûte immédiatement, avant même le premier recrawl.
Un geste évite beaucoup de dégâts : le gel du contenu. À partir du jour où la cartographie démarre, plus aucune publication ni suppression sur l’ancien site. Une page créée entre l’export et la bascule échappe au mapping et devient une erreur 404 le jour J, sans que personne ne sache d’où elle sort.
Le plan de redirections, pièce maîtresse du chantier
Choisir le bon code de réponse
Les codes de statut HTTP sont normalisés par l’IETF, la RFC 9110 publiée en juin 2022 ayant consolidé la sémantique du protocole. Le code 308 avait été introduit plus tôt, par la RFC 7538 de 2015, pour combler une faiblesse du 301 : il préserve la méthode de la requête, là où le 301 tolère historiquement la transformation d’un POST en GET.
| Code | Signification | Emploi en migration |
|---|---|---|
| 301 | Déplacement permanent | Le choix par défaut d’un changement d’adresse |
| 308 | Déplacement permanent strict | Identique, méthode HTTP conservée |
| 302 et 307 | Déplacement temporaire | Test A/B, maintenance, jamais une refonte |
| 410 | Contenu supprimé volontairement | Page morte sans équivalent |
Une précision utile : Google traite de la même façon toutes les erreurs 4xx, à l’exception du 429. Le 410 Gone n’accélère donc pas la désindexation par rapport à un 404 classique, contrairement à une croyance répandue. Sa valeur reste documentaire, puisqu’il signale à vos propres équipes que la disparition est délibérée.
Une seule redirection, jamais une chaîne
Les robots de Google suivent par défaut jusqu’à dix sauts de redirection, selon la documentation officielle consacrée aux erreurs HTTP et réseau. Cette tolérance ne justifie rien. Chaque saut supplémentaire ajoute une requête, un délai, et un risque de rupture le jour où un maillon disparaît.
La règle tient en une phrase : une seule redirection entre l’ancienne adresse et sa destination finale. Les migrations successives fabriquent des chaînes silencieuses, un site passé de HTTP à HTTPS puis d’une arborescence à une autre accumulant trois sauts sans que personne ne le remarque. Recrawlez votre propre mapping après déploiement, puis aplatissez tout ce qui dépasse un saut.
Les pages qui ne méritent aucune redirection
Rediriger en masse vers la page d’accueil est la faute la plus répandue. Une fiche produit supprimée renvoyée vers l’accueil crée une redirection jugée non pertinente, et le visiteur atterrit sur un contenu sans rapport avec sa recherche. Trois cas justifient une erreur assumée : le contenu supprimé sans successeur, les pages de test oubliées en ligne, les adresses générées par des paramètres devenus obsolètes.
La recette avant la bascule
La préproduction se protège par une authentification serveur, pas par une balise noindex. Un noindex oublié lors de la mise en production désindexe un site entier en quelques jours, et le scénario revient assez souvent pour figurer en tête des post-mortem de refonte.
Le contrôle avant bascule couvre six points :
- Titres, descriptions, balises canoniques et attributs hreflang reportés page par page
- Données structurées présentes sur les gabarits qui en portaient déjà
- Fichier robots.txt du nouveau site vérifié ligne par ligne
- Sitemap des nouvelles adresses généré, validé, prêt à soumettre
- Attributs alt et noms de fichiers d’images conservés à l’identique
- Temps de chargement mesuré avant et après avec les mêmes outils d’analyse de performance
Testez le mapping sur un échantillon avant de le déployer en entier : les cent adresses qui apportent le plus de trafic, les cent qui portent le plus de liens entrants. Un script qui interroge chaque ancienne URL, puis compare le code obtenu et la destination finale à ce qui était prévu, repère en quelques minutes ce qu’une relecture humaine laisse passer.
Avant toute manipulation, une copie restaurable de l’ancien site et de sa base de données doit exister ailleurs que sur le serveur concerné, selon les mêmes principes qu’une sauvegarde bien conçue : plusieurs copies, deux supports distincts, une copie hors site.
Le jour J, dans l’ordre
L’ordre des opérations compte autant que leur contenu. Une séquence qui tient la route :
- Abaisser la durée de vie des enregistrements DNS quarante-huit heures avant, pour propager vite en cas de retour arrière
- Choisir un créneau creux, mesuré sur vos propres statistiques, jamais la veille d’un pic commercial
- Retirer la protection de la préproduction et publier
- Activer les redirections dans la foulée, avant toute communication externe
- Soumettre le nouveau sitemap, en laissant l’ancien accessible pour accélérer la découverte des adresses à traiter
- Déclarer le déménagement aux moteurs de recherche
L’outil de changement d’adresse de la Search Console transmet ce signal pendant 180 jours à compter de la demande. Il exige que les deux propriétés soient vérifiées sur le même compte et que les redirections soient déjà en place. Ses limites méritent d’être connues : il ne couvre ni le passage de HTTP à HTTPS, ni le basculement entre www et sans www à l’intérieur d’un même domaine, et chaque sous-domaine déclaré séparément réclame sa propre demande.
Bing propose un équivalent, l’outil Site Move présenté sur le blog Bing Webmaster en décembre 2020, qui accepte un périmètre domaine, sous-domaine ou répertoire. Une contrainte à noter dans le calendrier : une nouvelle demande de déplacement ne peut pas être soumise avant six mois.
Gardez enfin l’ancien nom de domaine payé et actif. Un domaine expiré racheté par un tiers casse toutes les redirections d’un coup, et le nouveau propriétaire hérite au passage de vos liens entrants.
Les six semaines qui suivent la migration
La documentation Google prévient que la visibilité fluctue temporairement pendant un déménagement, et que les positions se stabilisent avec le temps. Elle indique aussi qu’un site de taille moyenne demande quelques semaines pour que la majorité de ses pages basculent dans l’index, davantage pour un site volumineux. Cette fenêtre n’est pas un échec, c’est le régime normal d’une bascule.
Le suivi hebdomadaire porte sur cinq indicateurs : les erreurs 404 remontées par la Search Console, la part des anciennes adresses encore explorées dans les journaux serveur, le nombre de pages indexées sur le nouveau périmètre, les positions des requêtes stratégiques, le trafic organique comparé à la même période de l’année précédente.
Deux gestes se pratiquent pendant cette période. Remplacez les liens internes qui pointent encore vers les anciennes adresses par des liens directs vers les URL finales, car une redirection interne fonctionne mais gaspille du budget d’exploration. Traitez chaque 404 remonté comme une adresse oubliée dans la cartographie, jamais comme une fatalité.
Combien de temps conserver les redirections ? La documentation Google Search Central consacrée aux déménagements recommande de les garder aussi longtemps que possible, au moins un an. Le signal du changement d’adresse s’éteint, lui, après cent quatre-vingts jours : passé ce délai, un ancien site resté accessible et explorable est traité comme un site sans relation avec le nouveau.
Les fautes qui plombent une refonte
Six écueils reviennent dans presque tous les post-mortem :
- Migrer et refondre les contenus dans le même mouvement, ce qui rend tout diagnostic impossible
- Rediriger en masse vers la page d’accueil au lieu de mapper adresse par adresse
- Employer un code 302 pour un changement pourtant définitif
- Oublier les images, les fichiers PDF et les flux RSS dans la cartographie
- Laisser la préproduction indexable, ou publier le nouveau site avec son noindex
- Couper l’ancien domaine trop tôt, avant l’extinction du trafic résiduel
Un septième écueil, plus discret : lancer le chantier sans avoir relu les fondamentaux du référencement avec l’équipe technique. Un développeur qui ignore ce qu’est une balise canonique la supprimera de bonne foi en nettoyant un gabarit, et personne ne s’en apercevra avant le rapport d’indexation du mois suivant.
Le premier geste tient en une heure : exportez vos adresses depuis la Search Console et depuis un crawl complet, fusionnez les deux listes, comptez celles qui n’apparaissent que dans l’une des deux. Ce nombre mesure le risque réel de votre projet, avant même d’avoir fixé une date de bascule. Si le chantier part en externe, ce même tableau devient la pièce à faire chiffrer par une agence web, ligne par ligne.