Plan de redirection Webflow : construire et vérifier le mapping

Un plan de redirection sert à décider du devenir de chaque URL

Un plan de redirection Webflow relie une ancienne URL à une décision explicite : la conserver, l’envoyer vers une destination pertinente ou traiter sa disparition. Il donne ensuite à l’équipe les informations nécessaires pour configurer les règles et vérifier leur résultat.

Le document ne se limite pas à deux colonnes « ancienne URL / nouvelle URL ». Il doit expliquer pourquoi la destination convient, identifier les règles déjà présentes, traiter les exceptions et attribuer les contrôles. Sans ces informations, un import techniquement accepté peut envoyer les visiteurs vers une page inadaptée ou supprimer des redirections encore utiles.

Ce guide porte sur ce livrable précis. Pour préparer les contenus, les formulaires, les accès et les autres étapes de la bascule, il faut aussi contrôler l'ensemble des risques de migration. Les huit cas ci-dessous sont pédagogiques : ils décrivent une entreprise fictive et des résultats à vérifier, sans constituer des règles prêtes à importer.

Réunir les anciennes URL et définir les destinations

Croiser les sources et garder leur origine

Réunissez les URL du CMS, du sitemap, de la navigation et des exports de mesure auxquels vous avez accès. Ajoutez les anciennes adresses encore utilisées dans des campagnes, des documents ou des liens connus. Exportez séparément les redirections déjà configurées. Aucune de ces sources, prise seule, ne garantit un inventaire complet.

Conservez chaque export d’origine avec sa date, son périmètre et sa source. Travaillez dans une copie où vous rapprochez les adresses sans effacer leurs variantes utiles : un chemin traduit ou un paramètre qui change le contenu peut nécessiter un traitement distinct. Notez les lacunes de l’inventaire au lieu de les combler avec des URL supposées.

Décider du contenu avant d’écrire une règle

Une page qui garde la même adresse et le même rôle n’a pas besoin d’être redirigée. Lorsqu’elle change d’adresse, recherchez son équivalent réel. Une fusion peut justifier plusieurs anciennes URL vers une nouvelle page si celle-ci reprend effectivement les réponses attendues.

Si aucun contenu ne remplace la page, faites arbitrer sa suppression. Google recommande une réponse HTTP 404 ou 410 pour un contenu retiré sans remplacement et déconseille les redirections en masse vers un accueil sans rapport. Sa documentation des déplacements de site distingue cette situation d’une consolidation pertinente. Le mode de mise en œuvre dépend ensuite de l’environnement technique.

Avant le mapping, faites valider les pages qui doivent exister et leur rôle. Vous pouvez définir l'arborescence cible, puis rattacher chaque ancienne adresse à cette organisation. Un nom de page ressemblant ne suffit pas : ouvrez la destination et vérifiez la réponse qu’elle apporte.

Construire une matrice de décision exploitable

Votre document de travail peut prendre la forme d’un tableau dans votre outil habituel. Une ligne doit contenir : l’ancienne adresse exacte, son rôle, sa langue, la décision, la destination finale ou son absence, la justification, le traitement technique envisagé, le responsable de validation, les tests attendus, l’environnement, la preuve et le statut.

Séparez trois validations : la décision de contenu, la configuration technique et le résultat observé. Une ligne peut être approuvée sur le fond alors que sa règle reste à préparer. Si une destination manque ou si une exception n’est pas résolue, marquez la ligne « à arbitrer » ; ne lui attribuez pas une redirection par défaut.

Les huit fiches suivantes constituent une matrice remplie en format lisible. Les chemins sont entièrement fictifs, sur un même site d’exemple ; les responsables désignent des rôles. Aucun test n’a été réalisé. Pour chaque fiche, la date, l’environnement réellement utilisé et la preuve seront à renseigner lors de la recette.

Cas 1 — Conserver une URL qui reste pertinente

Ancienne URL et rôle : /services/accompagnement, page française présentant une offre toujours disponible.

Décision et destination : conserver /services/accompagnement. La refonte change la présentation, sans modifier l’adresse ni le besoin couvert. Aucune règle de redirection n’est demandée pour ce chemin.

Responsable : responsable de l’offre pour le contenu, intégrateur pour le contrôle. Attendu : accès direct à la page cible, réponse HTTP 200 et offre correcte, sans redirection vers elle-même.

Tests à réaliser : ouvrir l’adresse après la bascule ; vérifier le code, le contenu et les liens de contact. Examiner séparément les éventuelles variantes de domaine ou de protocole. Preuve et statut : URL finale, relevé HTTP et capture à joindre ; recette non réalisée.

Cas 2 — Renommer une page sans changer son intention

Ancienne URL et rôle : /services/audit-contenu, page française d’une offre dont l’intitulé évolue.

Décision et destination : redirection permanente vers /services/diagnostic-editorial, après confirmation que la nouvelle page reprend bien la prestation et les informations utiles. Le changement de nom ne doit pas masquer une offre différente.

Responsable : responsable de l’offre valide l’équivalence ; intégrateur prépare la règle. Attendu : l’ancienne adresse redirige en 301 vers la nouvelle, qui répond en 200 et reste accessible directement.

Tests à réaliser : partir de l’ancienne URL, relever la destination finale et contrôler l’offre ; ouvrir ensuite la nouvelle adresse seule pour détecter une boucle. Preuve et statut : parcours HTTP et validation de contenu à joindre ; recette non réalisée.

Cas 3 — Réunir deux contenus dans une réponse réellement complète

Anciennes URL et rôle : /ressources/preparer-interview et /ressources/conduire-interview, deux guides français complémentaires.

Décision et destination : les deux anciennes pages renvoient vers /ressources/guide-interview. Cette destination doit contenir les étapes de préparation et de conduite, avec une navigation qui permet de retrouver les deux réponses.

Responsable : responsable éditorial pour la couverture des sujets ; intégrateur pour les deux règles. Attendu : chaque ancienne adresse redirige en 301 vers le guide commun, accessible en 200. Un simple résumé ne validerait pas la consolidation.

Tests à réaliser : tester chacune des deux entrées et relire la partie correspondante du guide ; vérifier que les liens internes pointent désormais vers la destination finale. Preuve et statut : deux parcours HTTP et contrôle des sections à joindre ; recette non réalisée.

Cas 4 — Retirer une page sans équivalent

Ancienne URL et rôle : /evenements/atelier-archives, page française d’un événement clos dont le contenu ne sera pas conservé.

Décision et destination : suppression approuvée, sans destination de redirection. L’accueil ne répond pas à la recherche de cet événement. L’équipe technique doit définir la réponse de disparition adaptée, 404 ou 410, selon les possibilités de l’environnement.

Responsable : propriétaire du contenu pour la suppression ; responsable technique pour la réponse. Attendu : réponse de disparition conforme à la décision, avec une page d’erreur utile au visiteur ; pas de faux contenu en 200 ni d’envoi automatique vers l’accueil.

Tests à réaliser : relever le code réel de l’ancienne adresse, vérifier le message et retirer les liens internes qui la présentent encore comme une page active. Preuve et statut : décision de suppression et relevé HTTP à joindre ; recette non réalisée.

Cas 5 — Traiter une locale secondaire explicitement

Ancienne URL et rôle : /en/services/content-audit, version anglaise d’une offre.

Décision et destination : redirection permanente vers /en/services/editorial-review. L’équivalence anglaise est validée indépendamment de la page française du cas 2. La règle française ne constitue pas une preuve de couverture de ce chemin.

Responsable : référent de la version anglaise, puis intégrateur. Attendu : l’ancienne page anglaise conduit en 301 à la nouvelle page anglaise en 200, avec le bon contenu et des liens de langue cohérents.

Tests à réaliser : entrer directement l’ancienne URL anglaise ; contrôler la langue finale et le sélecteur de langue. Tester aussi l’adresse française pour vérifier qu’elle garde son propre traitement. Preuve et statut : relevés des deux parcours et contrôle de langue à joindre ; recette non réalisée.

Cas 6 — Préserver une règle historique encore utile

Ancienne URL et rôle : /ancienne-offre, déjà redirigée vers /services/accompagnement avant la refonte.

Décision et destination : conserver cette relation historique dans le jeu de règles final. Le cas 1 maintient sa destination : la règle reste pertinente. Si cette destination changeait à son tour, il faudrait revoir la ligne pour viser le bon point d’arrivée.

Responsable : intégrateur, avec validation du responsable de l’offre. Attendu : l’entrée historique continue de conduire en 301 à /services/accompagnement en 200, sans détour ajouté.

Tests à réaliser : retrouver la règle dans l’export de sauvegarde et dans la version finale, puis tester l’ancienne adresse après la bascule. Preuve et statut : référence de la règle sauvegardée, comparaison et relevé HTTP à joindre ; recette non réalisée.

Cas 7 — Protéger une exception avant une règle de dossier

Ancienne URL et rôle : /conseils/demarrer, un guide français particulier, au milieu d’un dossier dont les autres contenus sont déplacés.

Décision et destination : cette page va vers /ressources/premiers-pas. Les autres pages conservées du dossier suivent leur mapping propre vers /ressources/. Une règle large ne doit pas envoyer l’exception vers un chemin calculé incorrect.

Responsable : responsable éditorial pour l’exception ; intégrateur pour l’ordre et la portée des règles. Attendu : l’exception atteint /ressources/premiers-pas en 200 après sa redirection ; les autres pages rejoignent leurs destinations validées.

Tests à réaliser : tester l’exception, une page ordinaire du dossier et une page extérieure au dossier qui doit rester inchangée. Vérifier l’ordre réellement appliqué, pas seulement la présence des règles. Preuve et statut : trois parcours et ordre des règles à joindre ; recette non réalisée. Aucune expression de capture prête à copier n’est fournie ici.

Cas 8 — Distinguer le chemin et le paramètre qui change la réponse

Ancienne URL et rôle : /documentation?theme=contenu, entrée française vers une rubrique documentaire. Dans cet exemple, le paramètre sélectionne une réponse distincte ; ce n’est pas un simple marqueur de campagne.

Décision et destination : envoyer cette entrée vers /ressources/contenu. Le chemin /documentation sans paramètre et l’entrée /documentation?theme=design gardent leurs décisions propres. L’intégrateur doit traduire ce besoin dans la syntaxe actuellement attendue par Webflow.

Responsable : responsable documentaire pour le sens du paramètre ; intégrateur pour la correspondance. Attendu : l’entrée « contenu » rejoint la bonne rubrique ; les autres entrées ne sont pas capturées par erreur.

Tests à réaliser : vérifier l’URL exacte, sa variante /documentation/?theme=contenu, l’adresse sans paramètre et le paramètre « design ». Ajouter les variantes réellement connues dans l’inventaire. Preuve et statut : relevé de chaque entrée, destination et justification à joindre ; recette non réalisée. Cette fiche n’est pas une règle technique importable.

Traduire les décisions dans les règles Webflow

Exporter avant de préparer un import

Selon la documentation d’import et d’export des redirections Webflow, un nouvel import CSV remplace toutes les redirections existantes. Ajouter uniquement les nouvelles lignes peut donc effacer des règles historiques utiles.

Exportez le jeu actuel et conservez cette sauvegarde. Préparez une copie réunissant les règles à maintenir et les nouvelles décisions validées ; contrôlez les doublons, contradictions et destinations. Le fichier technique utilise deux colonnes, ancien chemin et destination. La matrice de décision reste un document distinct : ses justifications et réserves ne doivent pas disparaître lors de cette conversion.

Contrôler l’ordre, les locales et la syntaxe

Webflow indique que les règles les plus anciennes sont essayées d’abord : les exceptions spécifiques doivent précéder les règles plus larges. Une règle à la racine ne couvre pas automatiquement les chemins localisés. Faites vérifier l’ordre effectif et chaque langue par l’intégrateur.

Les caractères spéciaux des anciens chemins demandent une syntaxe d’échappement propre à Webflow. Le service retire aussi le slash situé juste avant une chaîne de paramètres avant d’évaluer les règles. Le cas 8 impose donc plusieurs essais ; recopier visuellement l’adresse ne suffit pas. La documentation de configuration des redirections est la référence pour écrire les règles.

Vérifiez également qu’une page encore active n’occupe pas le chemin à rediriger. La configuration des anciennes pages et la prise d’effet des règles doivent être coordonnées avec la publication. Enregistrer une règle dans l’administration ne démontre pas son fonctionnement public.

Faire une recette sur les bons environnements

Une vérification en préproduction permet de contrôler les contenus et certaines règles, mais ne prouve pas à elle seule le comportement du domaine public ou de l’ancien hébergement. Pour chaque résultat, indiquez le domaine, la version testée, la date et le contexte. Lors d’un changement de domaine, identifiez aussi où l’ancienne adresse reçoit ses requêtes.

Pour chaque ligne, ouvrez l’ancienne URL et relevez le parcours HTTP jusqu’à l’adresse finale. Vérifiez la réponse attendue, l’absence de boucle et les détours inutiles. Ouvrez ensuite la destination directement : bon contenu, bonne langue, liens utilisables et indexabilité conforme à la décision du projet. Un 301 correct vers une page vide ne valide pas le plan.

Ajoutez les tests négatifs : une adresse extérieure à une règle large, une autre locale et un paramètre qui ne doit pas être capturé. Pour une suppression, vérifiez le véritable code de réponse. Une page affichant « introuvable » avec une réponse 200 ne constitue pas le résultat attendu.

Conservez un relevé par cas et un responsable de correction. Les statuts utiles sont « à arbitrer », « prêt pour recette », « anomalie à corriger » et « vérifié », avec la preuve correspondante. Seul un contrôle effectivement réalisé peut faire passer une ligne à « vérifié ».

Valider la remise et préparer le suivi

Le responsable de contenu valide les destinations ; l’intégrateur valide les règles et leurs dépendances ; le responsable du projet autorise la bascule dans son périmètre. Faites consigner les réserves avant l’intervention. Une décision manquante ne doit pas être absorbée silencieusement par une règle générale.

Préparez aussi un état de départ pour les pages importantes : visibilité, visites et demandes si ces données sont disponibles et fiables. Vous pouvez fixer les indicateurs de départ avec leur source, leur période et leur périmètre. Ces données aideront à enquêter après la migration, sans faire de chaque fluctuation une preuve de problème de redirection.

La remise est complète lorsque l’équipe dispose de ces éléments :

• les inventaires d’origine et leurs limites documentées ;
• la matrice de décisions versionnée, avec responsables et réserves ;
• la sauvegarde des règles existantes et le jeu final préparé séparément ;
• les destinations et exceptions validées, y compris les langues et paramètres utiles ;
• les tests attendus, leurs environnements et les preuves déjà obtenues ;
• la procédure de bascule et de retour à une version de règles connue ;
• le responsable du suivi et le traitement prévu des anomalies.

Après la mise en production, refaites les contrôles sur les adresses publiques, puis examinez les erreurs et les pages concernées au fil des données disponibles. Corrigez d’abord les mauvaises destinations, boucles ou règles manquantes observées. Une migration n’offre pas de garantie de maintien des positions, et un seul jour de variation ne suffit pas à évaluer son résultat SEO.

Si le mapping accompagne une transformation plus large des contenus et du site, vous pouvez cadrer une refonte Webflow avec migration. Apportez les exports, les décisions encore ouvertes et les contraintes de bascule : ils permettent de définir une intervention précise.