# Reprendre un site Elementor construit sans Theme Builder : notre méthode

> Un site où chaque page a été bâtie indépendamment, sans le moindre template partagé. Voici comment restructurer progressivement vers le Theme Builder Pro sans tout casser au passage.

- Auteur : Clément Hadrot
- Publié le : 2024-05-06
- Mis à jour le : 2024-05-06
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/reprendre-site-elementor-sans-theme-builder/

## L’essentiel

- Identifier les blocs répétés avant de créer le premier template
- Migrer une zone à la fois, en commençant par l'en-tête
- Garder l'ancien contenu accessible pendant la transition

Le site d'un cabinet d'expertise comptable nous est arrivé avec vingt-deux pages, chacune contenant sa propre version de l'en-tête, copiée-collée à la main depuis la création du site quatre ans plus tôt. Sept variantes légèrement différentes de ce même en-tête coexistaient, certaines avec un lien cassé vers une page supprimée, d'autres avec un logo dans une résolution obsolète. Le Theme Builder Pro d'Elementor, censé centraliser précisément ce type d'élément, n'avait jamais été utilisé.

Face à ce constat, la tentation est de tout reconstruire d'un bloc, sur un nouvel environnement propre. Cette approche est rarement réaliste sur un site en production qui génère du trafic et des demandes de contact au quotidien : chaque interruption a un coût. Nous avons donc opté pour une restructuration progressive, zone par zone.

## Étape 1 : cartographier avant de toucher à quoi que ce soit

La première étape n'a rien de spectaculaire mais conditionne tout le reste : lister, page par page, les blocs qui se répètent visuellement (en-tête, pied de page, bandeau de contact) et noter précisément leurs différences. Sur ce projet, cette cartographie a révélé que les sept variantes d'en-tête ne différaient en réalité que sur deux points : la présence ou non d'un lien vers une page « Recrutement » supprimée depuis, et une variante de couleur de fond sur les pages du blog.

## Étape 2 : commencer par l'en-tête, le bloc le plus rentable

L'en-tête est presque toujours le meilleur point de départ d'une migration vers le Theme Builder : il apparaît sur toutes les pages, ses variations sont généralement mineures, et sa centralisation offre un gain immédiat et visible pour le client (plus besoin de modifier vingt-deux pages pour changer un numéro de téléphone). Nous avons créé un template d'en-tête unique dans le Theme Builder, avec une condition d'affichage couvrant l'ensemble du site, puis désactivé au cas par cas l'ancien en-tête codé en dur sur chaque page migrée.

### Une migration page par page, jamais en masse

Chaque page a été migrée individuellement, avec vérification visuelle immédiate après bascule. Sur ce projet, la page « Notre équipe » cachait une exception non documentée : un en-tête sans le bandeau de contact téléphonique, choix volontaire d'un ancien rédacteur pour alléger la page. Une migration en masse aurait effacé cette nuance sans que personne ne s'en aperçoive avant plusieurs semaines.

> L'essentiel à retenir : Identifier les blocs répétés avant de créer le premier template ; Migrer une zone à la fois, en commençant par l'en-tête ; Garder l'ancien contenu accessible pendant la transition

## Étape 3 : le pied de page et les blocs secondaires

Une fois l'en-tête stabilisé sur l'ensemble du site, le pied de page a suivi la même logique, avec une difficulté supplémentaire : il contenait des liens vers les mentions légales et la politique de confidentialité, dont les URL différaient légèrement d'une page à l'autre suite à une ancienne restructuration de l'arborescence jamais terminée. La centralisation dans le Theme Builder a d'ailleurs servi de révélateur à ce problème d'URL, invisible tant que chaque pied de page vivait dans son coin.

Les blocs secondaires (bandeau de contact en fin de page, bloc d'avis clients) ont suivi un traitement identique, en dernier, car leur variation d'une page à l'autre restait plus significative et méritait une réflexion éditoriale, pas seulement technique, sur ce qui devait réellement être partagé.

## Ce qui a mal tourné, pour être honnête

- Deux pages produits utilisaient un widget de formulaire légèrement personnalisé en CSS local, qui a cessé de fonctionner correctement une fois l'en-tête centralisé a changé la structure du DOM au-dessus de lui.
- Le rendu mobile de l'ancien en-tête sur la page d'accueil avait une marge personnalisée invisible en desktop, oubliée lors de la recréation du template.
- Un rédacteur a modifié une page en cours de migration, créant une confusion temporaire entre deux versions de l'en-tête sur le même site pendant une demi-journée.

> Un site construit sans templates partagés n'est pas un site à jeter, c'est un site où la connaissance du contenu réel n'a simplement jamais été formalisée. La restructuration progressive fait ce travail de formalisation en même temps que la migration technique.

## En résumé

Reprendre un site Elementor bâti sans Theme Builder demande davantage de patience que de compétence technique pure. La cartographie initiale, souvent négligée par manque de temps, est ce qui évite les mauvaises surprises lors de la centralisation. Sur ce projet, la migration complète a pris trois semaines à temps partiel, avec zéro interruption de service visible pour les visiteurs du site.