Migrer d’un constructeur de pages à un autre
Elementor, Divi, WPBakery, Gutenberg natif : chacun enregistre sa mise en page dans un format qui lui est propre, et pas toujours au même endroit en base. Passer de l’un à l’autre n’est pas un réglage, c’est un chantier de reconstruction page par page.
Pourquoi changer de constructeur ne se fait pas en un clic
Le mécanisme de stockage diffère selon le constructeur, et aucun des formats n’est interopérable. Gutenberg natif et WPBakery écrivent tous les deux dans le champ post_content de la table wp_posts : le premier avec des commentaires HTML qui délimitent chaque bloc, le second avec des shortcodes imbriqués. Elementor, lui, conserve sa mise en page en JSON dans la métadonnée dédiée _elementor_data, rejouée au chargement de la page. Ces trois formats décrivent la même idée — une page composée de sections — mais aucun des trois ne sait lire le format d’un autre.
Il n’existe pas de convertisseur fiable qui traduise automatiquement une mise en page WPBakery en mise en page Elementor, ou l’inverse. Des plugins annoncent parfois cette conversion, mais dans la pratique le résultat garde des blocs mal positionnés, des styles perdus ou des sections vides sur des mises en page un peu élaborées. La méthode qui fonctionne reste la reconstruction manuelle dans le nouveau constructeur, éventuellement en s’appuyant sur un export du texte et des images pour ne pas retaper le contenu.
La casse ne s’arrête pas à la mise en page : chaque constructeur génère aussi des identifiants d’éléments qui lui sont propres (par exemple des classes du type elementor-element-xxxxx), auxquels du CSS personnalisé ajouté séparément fait souvent référence. Ce CSS sur mesure cesse de s’appliquer dès que la page est reconstruite ailleurs, puisque les nouveaux éléments portent d’autres identifiants : il doit être réécrit, pas seulement copié.
Ce qui apparaît si on désactive le constructeur trop tôt
- Des shortcodes visibles en texte brut sur la page, du type [vc_row][vc_column]…, à la place de la mise en page
- Du JSON affiché comme texte au lieu d’être interprété, sur les pages construites avec Elementor
- Une mise en page qui s’effondre en une colonne unique, sans styles ni espacements
- Des images ou des icônes qui ne s’affichent plus, chargées auparavant par le constructeur désactivé
Comment je conduis ce type de migration
-
Inventaire des pages concernées
Je liste toutes les pages construites avec l’ancien outil et j’évalue leur complexité : nombre de sections, présence d’animations ou de mises en page sur mesure.
-
Priorisation
Je classe les pages selon leur trafic et leur valeur SEO, pour reconstruire d’abord celles qui comptent le plus si le temps est limité.
-
Reconstruction page par page
Chaque page est recréée dans le nouveau constructeur en gardant le texte, les images et la structure de titres, sans copier le balisage de l’ancien outil.
-
Coexistence des deux constructeurs
L’ancien plugin reste actif tant que toutes les pages qui en dépendent n’ont pas été migrées et validées visuellement.
-
Désinstallation finale
Le plugin de l’ancien constructeur n’est désinstallé qu’une fois toutes les pages concernées reconstruites et vérifiées, jamais avant.
Pour aller plus loin
-
Passer à Gutenberg depuis l’éditeur classique
Un cas particulier de migration de constructeur, avec ses propres règles.
-
Créer un thème enfant WordPress
Utile pour isoler les personnalisations avant une reconstruction de pages.
-
Sauvegarder sa boutique avant intervention
La sauvegarde à faire avant de toucher à la structure des pages.
-
Migrer sans perdre son référencement
Ce qu’il faut vérifier côté SEO après une reconstruction de pages.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.