Migration Elementor vers Gutenberg : comment convertir un site entier en une journée au lieu de plusieurs semaines

Tous les guides s’accordent sur un point : migrer un site WordPress d’Elementor vers Gutenberg prend plusieurs semaines de reconstruction manuelle. « Il n’existe pas de bouton magique. » « Comptez plusieurs semaines de travail dédié. » « Le site doit essentiellement être reconstruit de zéro. » Ce consensus décourage la plupart des migrations avant même qu’elles ne commencent.

Pourtant, un site client de 114 contenus (94 articles et 20 pages) a été intégralement migré en une seule journée, sans reconstruction manuelle, avec conservation de toutes les URLs. Voici la méthode complète, applicable à tout projet Elementor.

Pourquoi quitter Elementor en 2026

Elementor a eu sa raison d’être. Il y a quelques années, WordPress core était rudimentaire, Gutenberg à peine utilisable. Un constructeur visuel drag-and-drop répondait à un besoin réel pour les équipes qui ne souhaitaient pas toucher au code. Cette époque est révolue.

WordPress a considérablement évolué. Gutenberg est désormais un éditeur de blocs mature. Le Full Site Editing permet de concevoir l’intégralité d’un site sans extension tierce. Les thèmes blocs offrent une flexibilité qui rend les page builders superflus pour la majorité des cas d’usage.

Le coût réel d’Elementor pour une PME ou une agence

Elementor représente aujourd’hui un passif technique :

• Performance dégradée : le plugin ajoute des centaines de kilo-octets de CSS et JavaScript sur chaque page, même lorsque les fonctionnalités ne sont pas utilisées
• Licence récurrente : Elementor Pro impose un abonnement annuel, avec des fonctionnalités qui se retrouvent désormais dans WordPress core
• Verrouillage propriétaire : le contenu est stocké dans un format JSON interne (_elementor_data) illisible en dehors du plugin. Désactivez Elementor et vos pages disparaissent
• Dépendance au thème Hello : ce thème est une coquille vide, 100 % dépendant du plugin. Sans Elementor, il ne produit rien

Pour une agence qui gère plusieurs sites clients, le calcul est simple : chaque site sous Elementor est un site dont le contenu est prisonnier d’une extension payante. Et chaque renouvellement de licence non payé transforme un site fonctionnel en une page blanche.

Quand Elementor reste pertinent

Soyons honnêtes : Elementor conserve un intérêt dans certains cas précis. Une landing page ponctuelle. Un site événementiel temporaire. Un prototype rapide que personne ne maintiendra dans deux ans. Le problème n’est pas le constructeur en lui-même — c’est le verrouillage à long terme sur du contenu que l’entreprise souhaite conserver.

La méthode classique vs. l’approche automatisée

Ce que préconisent les guides existants

La méthode conventionnelle de migration Elementor vers Gutenberg suit un protocole en plusieurs étapes :

1. Créer un environnement de staging
2. Effectuer une sauvegarde complète
3. Installer un plugin de conversion partielle (type « Elementor to Blocks »)
4. Reconstruire manuellement chaque page où le plugin échoue
5. Nettoyer les classes CSS résiduelles d’Elementor
6. Tester l’ensemble du site (QA)
7. Pousser en production

Durée estimée : plusieurs semaines en temps calendaire. Pour un site de 114 contenus, c’est un projet que personne ne veut financer — ni le client, ni l’agence.

L’approche par l’API REST WordPress

Toute la méthode repose sur un mécanisme natif de WordPress que peu de professionnels exploitent pour les migrations : les Application Passwords.

La configuration tient en 30 secondes :

1. Ouvrir wp-admin sur le site cible
2. Aller dans Utilisateurs > Profil > Mots de passe d’application
3. Saisir un nom, cliquer sur Ajouter
4. Copier le mot de passe généré

Ce mot de passe d’application est un jeton d’accès avec les mêmes permissions que l’utilisateur qui l’a généré. Combiné à l’URL du site, il permet de lire et écrire via l’API REST tout ce qu’elle expose : articles, pages, médias, utilisateurs, réglages.

Pas de flux OAuth, pas de webhook, pas de plugin à installer, pas d’environnement de staging.

À partir de là, un agent IA (dans notre cas Claude Code) reçoit l’URL et le mot de passe d’application, explore l’API par lui-même, identifie la stack (version WordPress, thème actif, liste des plugins, types de contenus), sauvegarde l’intégralité des contenus en JSON local, puis écrit ses propres scripts de conversion.

Comment fonctionne la conversion technique

Pourquoi ne pas parser le JSON Elementor

Premier choix technique — et c’est celui qui rend l’ensemble viable. L’agent n’a pas parsé _elementor_data, le JSON brut qu’Elementor stocke dans les métadonnées des articles.

Ce JSON est profondément imbriqué, sa structure varie entre les versions d’Elementor, les noms de widgets changent d’une release à l’autre. Le parser serait une cible mouvante.

L’agent a travaillé à partir du HTML rendu. L’API REST expose content.rendered pour chaque article — c’est le HTML final après le traitement par Elementor. Plus simple, plus stable, portable entre versions. Si le HTML s’affiche correctement en frontend, le parseur a une base solide.

Le principe de conversion

Le script de conversion repose sur un parcours récursif de l’arbre DOM :

1. Identifier les wrappers Elementor : une douzaine de classes CSS (elementor-section, elementor-container, elementor-column, elementor-widget-wrap, e-con, e-con-inner, etc.)
2. Supprimer les wrappers : quand le parseur rencontre un wrapper Elementor, il le supprime et continue à parcourir les éléments enfants
3. Convertir les widgets : quand il atteint un widget réel (heading, image, text-editor), il le transforme en bloc Gutenberg natif

Exemples concrets de conversion

Un titre Elementor dans le HTML rendu :

<div class="elementor-widget elementor-widget-heading" data-id="a1b2c3">
  <div class="elementor-widget-container">
    <h2 class="elementor-heading-title elementor-size-default">
      <span style="color: #333">Notre approche</span>
    </h2>
  </div>
</div>

Après conversion en bloc Gutenberg :

<!-- wp:heading -->
<h2>Notre approche</h2>
<!-- /wp:heading -->

Les spans inline avec styles, les classes Elementor, les divs wrapper, les attributs data — tout est supprimé. Le résultat est un bloc Gutenberg propre, compatible avec n’importe quel thème.

Une image Elementor suit le même principe. Le constructeur encapsule chaque <img> dans deux ou trois divs avec des classes comme elementor-widget-image. Gutenberg attend une figure avec la classe wp-block-image :

<!-- wp:image -->
<figure class="wp-block-image">
  <img src="..." alt="..."/>
</figure>
<!-- /wp:image -->

L’écriture dans WordPress via l’API

Une fois le contenu converti, le script pousse les blocs Gutenberg dans WordPress via l’API REST. Le contenu converti remplace le contenu Elementor directement dans chaque article et chaque page.

Point d’attention pour les hébergements derrière Cloudflare : dans le cas de cette migration, Cloudflare bloquait les requêtes HTTP émises depuis les librairies Python standard (requests, urllib, httpx). L’agent a contourné le problème en utilisant curl en sous-processus — le user-agent curl passe sans déclencher les protections. Ce contournement est spécifique à cette configuration ; sur un hébergement sans CDN agressif, les librairies HTTP classiques fonctionnent sans difficulté.

Les problèmes rencontrés et leurs corrections

Après la première passe de conversion, le site fonctionnait : chaque page se chargeait, pas d’erreur 500, pas d’écran blanc. Mais le contenu présentait trois catégories de problèmes, apparus dans cet ordre.

Problème 1 : les espaceurs fantômes

Elementor utilise des paragraphes vides avec des marges CSS comme séparateurs visuels. Lors du parsing naïf du HTML, ces paragraphes vides se transforment en blocs wp:spacer empilés les uns sur les autres — créant des trous verticaux absurdes dans le contenu.

Correction : un second script re-télécharge chaque article, supprime les blocs spacer par expression régulière, et les remplace par des retours à la ligne appropriés. 47 contenus nettoyés en un seul lot.

Problème 2 : les blocs invalides

Gutenberg valide strictement le balisage des blocs. Un bloc wp:image dont la figure ne porte pas la classe wp-block-image déclenche l’erreur « Ce bloc contient un contenu inattendu ou invalide ». Le bloc s’affiche mais l’éditeur refuse de le modifier — ce qui est pire qu’un bug visuel pour un client qui souhaite éditer ses propres pages.

Correction : un troisième script re-parse chaque bloc, reconstruit le HTML interne au format exact attendu par Gutenberg, et repousse le contenu. 81 contenus corrigés, répartis en 4 lots parallèles pour accélérer le traitement.

Problème 3 : les fonctionnalités sans équivalent natif

C’est la limite réelle de toute migration, et c’est là que l’expertise humaine devient indispensable. Elementor — et surtout Elementor Pro — propose des widgets et des fonctionnalités qui n’ont aucun équivalent direct dans Gutenberg :

• Formulaires de contact : les formulaires Elementor Pro doivent être remplacés par un plugin dédié (WPForms, Contact Form 7, Fluent Forms, Gravity Forms…). Chaque option a ses compromis en termes de fonctionnalités, de prix et de compatibilité avec le reste de la stack
• Sliders et carrousels : WordPress core ne propose pas de bloc slider. Il faut évaluer si un slider est réellement nécessaire ou si une section statique bien conçue ne serait pas plus performante (en termes de vitesse et de conversion)
• Popups et opt-in : les popups Elementor Pro doivent être remplacées par des solutions alternatives — plugin dédié, intégration native du service d’emailing, ou repensées entièrement
• Widgets visuels spécifiques : compteurs animés, témoignages carrousel, galeries avancées, onglets, accordéons Pro — chacun nécessite soit un plugin de remplacement, soit une reconstruction avec les blocs natifs disponibles
• Intégrations tierces : certains sites connectent Elementor directement à un CRM, un outil d’emailing ou un système de paiement. Ces intégrations doivent être recâblées avec les plugins appropriés

La conversion automatisée récupère le contenu textuel et structurel. Mais le choix des plugins de remplacement, la configuration des intégrations et l’arbitrage entre les alternatives — c’est un travail de conseil qui exige une connaissance de l’écosystème WordPress et une compréhension des besoins métier du client.

La boucle de correction autonome

Point important : les deux premiers problèmes ont été résolus de manière entièrement autonome par l’agent. Trois scripts au total, chacun écrit pour corriger les défauts créés par le précédent. Boucle de feedback autonome, même session, sans redémarrage. L’opérateur pointe un symptôme, l’agent écrit le diagnostic, écrit le correctif, l’exécute, et vérifie le résultat.

Ce qui reste après la conversion automatisée

La conversion des contenus est la partie visible de la migration. Mais un site WordPress ne se résume pas à ses articles et ses pages. C’est un assemblage de plugins, d’intégrations, de réglages et de logiques métier que la conversion automatisée ne peut pas deviner.

Le remplacement de l’écosystème Elementor

Un site sous Elementor Pro s’appuie rarement sur Elementor seul. Il utilise souvent un ensemble d’extensions complémentaires — addons, widgets tiers, intégrations — qui forment un écosystème complet. Migrer vers Gutenberg, c’est reconstruire cet écosystème avec des briques différentes :

• Thème : le thème Hello Elementor est inutilisable sans le plugin. Il faut choisir un thème bloc (Twenty Twenty-Five, Astra, Kadence, GeneratePress…) adapté au positionnement visuel du site et le configurer
• Formulaires : évaluer et configurer un plugin de formulaire, reprendre les champs, les règles de validation, les destinataires des notifications, les éventuelles intégrations CRM
• Emailing et capture de leads : recâbler les formulaires d’inscription newsletter, les popups d’opt-in, les connexions avec le service d’emailing (Mailchimp, Brevo, HubSpot…)
• SEO : vérifier que les métadonnées (Rank Math, Yoast) n’ont pas régressé sur les pages stratégiques — title, meta description, données structurées, images OG
• Médias et mise en page : certaines images contiennent du texte incrusté, des overlays ou des effets visuels qui dépendaient d’Elementor. Elles doivent être redesignées
• Performance : profiter de la migration pour auditer les Core Web Vitals et configurer un cache approprié — le gain de performance post-Elementor est significatif mais ne s’obtient pas automatiquement

Le nettoyage technique

Le site ne sera réellement libéré d’Elementor qu’après un nettoyage en profondeur :

• Suppression des milliers de lignes _elementor_* dans la table postmeta (les résidus du JSON propriétaire alourdissent la base de données)
• Désinstallation propre d’Elementor et de ses addons
• Suppression du thème Hello Elementor
• Audit des shortcodes orphelins qui pourraient s’afficher en clair dans le contenu
• Vérification des redirections et des liens internes

Ces opérations nécessitent un accès SSH ou WP-CLI — l’API REST ne suffit pas. Et une erreur sur la base de données en production peut casser le site.

Pourquoi c’est un travail d’expert

Chaque site Elementor est unique. Le nombre de pages ne détermine pas à lui seul la complexité : un site de 30 pages avec des formulaires connectés à un CRM, un système de prise de rendez-vous et des landing pages avec tracking publicitaire sera plus complexe à migrer qu’un blog de 200 articles.

L’automatisation accélère considérablement la conversion des contenus — c’est ce qui fait passer le projet de plusieurs semaines à quelques jours. Mais la réussite de la migration repose sur la capacité à auditer l’existant, choisir les bons plugins de remplacement, reconfigurer les intégrations, et livrer un site qui fonctionne exactement comme avant (ou mieux) sans Elementor.

Les limites de l’API REST WordPress

Avant de lancer un agent sur un site de production, il est essentiel de définir précisément ce que l’API REST permet et ne permet pas :

Pour tout ce qui dépasse la surface de l’API, il faut un accès SSH ou wp-admin. Définissez le périmètre avant de lancer la migration.

Chronologie réelle de la migration

114 contenus. Trois scripts. Une journée. Toutes les URLs préservées. La cliente édite désormais ses propres pages sans faire appel à un prestataire.

Ce que cela signifie pour les agences et les PME

Pour les agences WordPress

La migration Elementor vers Gutenberg devient un service productisable. Au lieu de facturer plusieurs semaines de reconstruction manuelle (que peu de clients acceptent de financer), une agence peut proposer une migration en une à deux journées. Le ratio temps investi / valeur livrée change radicalement.

Pour les PME

Le frein principal à la migration disparaît. Le coût d’une journée de prestation est compatible avec le budget d’une PME. Et le retour sur investissement est immédiat : suppression de la licence Elementor Pro, pages plus rapides, contenu éditable sans dépendance à un prestataire technique.

Les prérequis

• Un accès administrateur au site WordPress
• L’API REST activée (c’est le cas par défaut)
• Un agent IA capable d’interagir avec des APIs REST (Claude Code ou équivalent)
• Une compréhension claire du périmètre : ce que l’agent peut toucher, ce qu’il doit escalader

Questions fréquentes

La migration Elementor vers Gutenberg fait-elle perdre le référencement ?

Non, à condition de conserver les URLs identiques — ce qui est le cas avec cette méthode puisque les articles et pages sont modifiés en place, sans changement de slug ni de structure. Les métadonnées SEO (Rank Math, Yoast) sont stockées séparément dans postmeta et ne sont pas affectées par la conversion du contenu.

Peut-on migrer un site Elementor sans compétences techniques ?

La méthode décrite ici nécessite un agent IA capable d’écrire et d’exécuter des scripts. Ce n’est pas un plugin à installer. En revanche, une agence peut l’utiliser comme prestation packagée pour ses clients sans qu’ils n’aient à intervenir techniquement.

Quels widgets Elementor ne sont pas convertibles ?

Tous les widgets propriétaires d’Elementor Pro sans équivalent natif : sliders, popups, formulaires Pro, compteurs animés, témoignages carrousel. Le contenu textuel est généralement récupérable, mais la mise en forme spécifique est perdue. Ces éléments doivent être remplacés par des alternatives Gutenberg ou des plugins dédiés.

Cette méthode fonctionne-t-elle avec d’autres page builders (Divi, Beaver Builder, WPBakery) ?

Le principe est identique — travailler à partir du HTML rendu plutôt que du format propriétaire — mais les wrappers CSS et la structure DOM varient selon le constructeur. Le script de conversion doit être adapté à chaque page builder, ce que l’agent gère en analysant la structure spécifique du site.

Faut-il un environnement de staging ?

La méthode fonctionne directement en production grâce à la sauvegarde JSON préalable de tous les contenus. En cas de problème, le contenu original peut être restauré via l’API. Pour les sites à fort trafic ou les environnements critiques, un staging reste recommandé par précaution.

Vous souhaitez migrer votre site Elementor vers Gutenberg ?

Nous réalisons la migration complète de votre site WordPress : conversion de tous vos contenus, conservation des URLs, nettoyage de la base de données et vérification SEO. Tarif indicatif à partir de 850 € HT selon le volume de contenus et la complexité du site.

👉 Contactez-nous pour obtenir un devis personnalisé