Exporter Webflow en HTML, CSS et JavaScript.

Exporter un site Webflow peut vouloir dire deux choses différentes. La première consiste à télécharger le code produit par le builder. La seconde consiste à obtenir une version réellement autonome, avec toutes les routes et toutes les ressources nécessaires. Pour un petit site statique, les deux résultats peuvent se ressembler. Dès que le projet utilise le CMS, des formulaires, l’e-commerce ou des pages localisées, l’écart devient important.

Votre objectif doit être défini avant de commencer : archiver le design, déplacer l’hébergement, reprendre le code à la main ou intégrer le front dans une autre application. Le niveau de vérification n’est pas le même, mais une règle reste valable dans tous les cas : gardez la version publiée en ligne jusqu’à ce que la copie ait passé les tests.

1. Choisir entre l’export natif et une copie autonome

Webflow propose un export de code sur certains plans Workspace payants. Sa documentation précise aussi que le contenu CMS, les fonctionnalités e-commerce, le traitement des formulaires, la recherche et les pages localisées ne sont pas inclus comme fonctionnalités actives dans le code exporté. Consultez toujours la documentation officielle de l’export Webflow avant de choisir votre méthode.

Une capture à partir du site publié peut compléter ce qui manque, mais elle doit respecter vos droits sur le site et ses contenus. XportFrame sert à analyser une URL que vous êtes autorisé à traiter, à préparer une copie consultable et à comparer visuellement son rendu avant téléchargement.

2. Inventorier les routes avant de récupérer le code

Commencez par lister les URLs qui comptent. Incluez les pages présentes dans la navigation, les pages CMS, les landing pages qui reçoivent du trafic publicitaire, la page 404, les pages légales et les anciennes URLs qui bénéficient encore de liens externes. Les pages orphelines sont souvent celles que l’on perd pendant une migration.

3. Préserver les interactions Webflow

Les classes Webflow ne doivent pas être renommées pendant la récupération. Les interactions reposent souvent sur une combinaison de classes, d’attributs et de scripts chargés dans un ordre précis. Une “optimisation” agressive du HTML peut donc rendre un menu immobile, laisser un élément à zéro d’opacité ou casser un carrousel.

Testez les comportements dans leur contexte réel : chargement initial, apparition dans le viewport, hover, clic, glisser-déposer, redimensionnement et retour arrière. Pour un élément révélé au scroll, vérifiez aussi son état sans JavaScript et avec la préférence système de réduction des animations.

• Le menu desktop et le menu mobile s’ouvrent, se ferment et restituent le focus.
• Les accordéons affichent leur réponse et ferment correctement l’élément précédent.
• Les sliders fonctionnent à la souris, au tactile et au clavier lorsque prévu.
• Les éléments animés restent visibles si le script tarde à démarrer.
• Aucun badge de plateforme ou script inutile ne reste dans la version livrée.

4. Transformer le CMS, les formulaires et la recherche

Un contenu CMS peut être converti en pages HTML statiques si les données changent peu. Chaque entrée devient alors une route et un fichier. Cette solution est rapide à servir et simple à héberger, mais toute mise à jour nécessite une nouvelle génération. Pour un catalogue fréquemment modifié, il est préférable de connecter le front à un CMS indépendant.

Les formulaires demandent un backend ou un service de réception. Après la migration, contrôlez la validation des champs, le message de succès, les erreurs réseau, l’anti-spam et l’adresse qui reçoit les données. Une interface identique ne garantit pas que l’envoi fonctionne.

5. Récupérer les images, polices et vidéos

Le HTML exporté ne doit pas seulement contenir les bonnes balises : tous les chemins doivent mener vers des fichiers disponibles. Téléchargez les images dans leur résolution utile, conservez les variantes responsives et évitez de convertir aveuglément les SVG ou les images déjà optimisées. Pour les polices, vérifiez les licences et déclarez uniquement les graisses réellement utilisées.

Ouvrez ensuite la copie avec le réseau coupé. Cette vérification révèle immédiatement les médias encore chargés depuis un domaine tiers. Les vidéos hébergées sur une plateforme externe peuvent rester distantes si ce choix est volontaire et documenté.

6. Conserver les URLs et les signaux SEO

Gardez les mêmes slugs dès que possible. Pour chaque URL modifiée, créez une redirection permanente vers la page équivalente. Reprenez le titre, la description, le H1, les liens canoniques, les balises sociales, les données structurées et les textes alternatifs pertinents. Un nouveau design identique peut perdre sa visibilité si cette couche disparaît.

Comparez aussi les liens internes. Ils doivent fonctionner depuis la page d’accueil comme depuis une page profonde. Générez un sitemap avec les URLs canoniques et vérifiez que les pages privées, les aperçus et les endpoints techniques restent exclus de l’index.

7. Valider la copie avant de changer le domaine

Comparez la source et la copie aux mêmes dimensions d’écran. Regardez la hauteur totale, les décalages de sections, les polices, les images et les états animés. Un score visuel aide à repérer un gros écart, mais il doit être complété par un parcours manuel des interactions.

• Chaque URL importante répond avec un statut correct.
• Le rendu desktop, tablette et mobile correspond à la référence.
• Les formulaires et liens externes ont reçu un test réel.
• Les métadonnées et redirections sont prêtes avant la bascule DNS.
• Une sauvegarde de l’ancien site reste disponible pendant la transition.