La migration de contenus depuis WPBakery (Visual Composer) vers Gutenberg sans altération du rendu visuel est réalisable, mais elle ne repose pas sur un simple export/import.

Chez TYTAE, nous avons mis en place une méthode permettant d’obtenir un rendu très fidèle à l’existant, en reconstituant l’environnement technique utilisé par WPBakery.

Cette approche implique toutefois :

• une mise en œuvre technique avancée
• une éditabilité réduite des contenus une fois migrés

Elle reste néanmoins particulièrement pertinente pour préserver l’existant, notamment dans un contexte SEO.

Pourquoi WPBakery complique les migrations

WPBakery ne génère pas un HTML standard exploitable directement.

Le constructeur repose sur :

• des shortcodes imbriqués ([vc_row], [vc_column], etc.)
• des styles stockés en métadonnées
• des dépendances JavaScript et CSS dynamiques
• une bibliothèque d’assets externe

Conséquence :

• un export WordPress classique ne suffit pas
• Gutenberg ne peut pas interpréter ces contenus nativement

Étape 1 : Export des articles WordPress

La première étape consiste à utiliser l’outil natif :

Outils → Exporter → Articles

Le fichier XML obtenu contient :

• le contenu des articles (avec shortcodes WPBakery)
• les médias associés (partiellement)
• les métadonnées (dont celles utilisées par WPBakery)

Ce fichier constitue une base exploitable, mais nécessite des transformations.

Étape 2 : Transformation du contenu

Il s’agit de l’étape la plus structurante.

Problématiques rencontrées

• présence de shortcodes non interprétables par Gutenberg
• dépendances implicites au système WPBakery
• URLs et structures spécifiques

Traitements réalisés

• parsing du fichier XML
• transformation des shortcodes en HTML
• correction des URLs internes
• nettoyage des dépendances inutiles

L’objectif est d’obtenir un contenu HTML stable, indépendant de WPBakery.

Étape 3 : Gestion des images

Les images référencées dans WPBakery ne sont pas toujours correctement associées lors de l’export.

Méthodologie

• extraction des URLs d’images dans le contenu
• téléchargement des fichiers
• réimport dans la médiathèque
• remplacement des URLs dans les contenus

Cette étape est essentielle pour :

• éviter les erreurs 404
• garantir l’autonomie du site
• préserver les performances SEO

Étape 4 : Récupération du CSS spécifique

WPBakery stocke des styles personnalisés dans des métadonnées (ex : _wpb_shortcodes_custom_css).

Sans leur récupération :

• le rendu visuel est altéré

Solution mise en œuvre

• extraction du CSS par article
• génération de fichiers CSS dédiés
• injection côté front (inline ou fichier externe selon le cas)

Cette étape permet de conserver l’apparence initiale.

Étape 5 : Chargement des assets externes

WPBakery s’appuie sur une bibliothèque d’assets qui n’est pas entièrement incluse dans le plugin.

Problème

Sans ces fichiers :

• certains éléments ne s’affichent pas correctement
• des styles ou animations sont manquants

Approche adoptée

• identification des assets nécessaires
• téléchargement automatique
• hébergement local
• chargement conditionnel

Étape 6 : Chargement ciblé des scripts et styles

Il n’est ni nécessaire ni souhaitable de charger l’intégralité de WPBakery.

Méthodologie

• audit des dépendances réellement utilisées
• chargement uniquement des ressources utiles
• désactivation des éléments superflus

Cela permet de maintenir de bonnes performances et une structure propre.

Résultat

La méthode permet d’obtenir :

• des articles migrés
• un rendu visuel très proche de l’original
• une indépendance vis-à-vis de WPBakery côté édition
• une continuité SEO

Limites

Cette approche présente néanmoins certaines contraintes :

• absence de conversion vers des blocs Gutenberg natifs
• complexité de maintenance accrue
• modification des contenus moins intuitive

Besoin d’accompagnement

Ce type de migration nécessite une méthodologie rigoureuse pour éviter toute perte de contenu ou dégradation SEO.

TYTAE propose un accompagnement dédié pour sécuriser ce type de projet.