WPBakery Page Builder (anciennement Visual Composer) est l’un des constructeurs de pages les plus utilisés dans l’écosystème WordPress. Il permet de créer des mises en page complexes sans coder, en glisser-déposer. Cependant, sous ses apparences accessibles, cet outil cache plusieurs limites en matière de référencement naturel.
Dans un contexte où la performance technique, la structure HTML et l’expérience utilisateur sont des piliers du SEO, l’usage de WPBakery peut rapidement freiner une stratégie de visibilité efficace.
1. Un code HTML surchargé et peu lisible
1.1 Injections massives de divs et de shortcodes
WPBakery génère un HTML très dense, truffé de balises <div>, d’identifiants CSS et de classes inutiles. Cette structure :
- Rend le code moins lisible pour les robots de Google.
- Crée une profondeur DOM excessive, ralentissant le rendu du contenu.
- Introduit des shortcodes dans l’éditeur natif WordPress, ce qui complique la maintenance ou la migration.
1.2 Difficulté de hiérarchisation sémantique
Il est plus complexe avec WPBakery de structurer correctement le contenu avec des balises <h2>, <h3>, <section>, etc. Cela nuit à :
- La compréhension thématique par les moteurs.
- La cohérence SEO on-page (titres secondaires, entités, cocon sémantique).
2. Performances web impactées
2.1 Temps de chargement allongé
WPBakery charge de nombreux scripts, feuilles de styles et fichiers inutiles même lorsque les modules associés ne sont pas utilisés. Cela alourdit :
- Le poids des pages.
- Le Time To Interactive (TTI) et le First Contentful Paint (FCP), pénalisés dans les Core Web Vitals.
2.2 Mauvaise gestion du critical CSS et du lazy loading
Contrairement à d’autres builders modernes comme Oxygen ou Bricks, WPBakery ne propose pas nativement :
- De chargement différé des images.
- D’optimisation automatique des polices, icônes, et animations CSS.
Résultat : un score faible dans Google PageSpeed Insights.
3. Accessibilité compromise
Les pages conçues avec WPBakery sont rarement accessibles :
- Pas de support natif des balises ARIA.
- Navigation clavier mal prise en compte.
- Problèmes pour les lecteurs d’écran.
Cela ne concerne pas uniquement l’UX : Google pénalise les contenus difficilement accessibles, en particulier dans les résultats mobiles.
4. Indexabilité des contenus réduite
4.1 Contenu encapsulé dans des shortcodes
Le contenu inséré via WPBakery peut être encapsulé dans des shortcodes. Si le plugin est désactivé ou mal interprété :
- Le contenu devient illisible pour les moteurs.
- Des blocs entiers peuvent être absents du rendu HTML, donc non indexés.
4.2 Risques de duplication structurelle
L’utilisation de modèles préfabriqués et de blocs réutilisés peut générer des structures répétitives d’une page à l’autre, nuisant :
- À la singularité des pages.
- À l’optimisation du crawl budget de Googlebot.
5. Fragilité en cas de refonte ou migration SEO
5.1 Risque de perte de contenu
Lors d’une refonte sans WPBakery, les shortcodes deviennent du texte illisible. Sans anticipation, cela entraîne :
- Une perte brutale du contenu textuel.
- Des erreurs d’indexation (pages vides ou corrompues).
5.2 Complexité de reprise du balisage SEO
- Les balises
<title>,<meta>, les attributsaltsur les images sont parfois enfouis dans les modules, difficiles à éditer en masse. - Les données structurées doivent être ajoutées à la main ou via plugins tiers, car WPBakery n’offre pas d’outil natif pour cela.
6. Alternatives recommandées pour préserver le SEO
6.1 Oxygen Builder, Bricks, ou Gutenberg
Ces solutions privilégient :
- Un code propre, léger et sémantique.
- Une meilleure intégration des Core Web Vitals.
- Un contrôle SEO natif plus granulaire.
6.2 Utilisation de WPBakery encadrée par un expert SEO
Si WPBakery est déjà en place :
- Nettoyer le DOM avec du code personnalisé.
- Auditer les shortcodes et les optimiser.
- Ajouter des plugins spécialisés (ex : Asset CleanUp, Perfmatters).
7. Bonnes pratiques si WPBakery reste indispensable
- Ne pas abuser des modules graphiques sans valeur SEO.
- Préférer les balises classiques HTML aux widgets visuels.
- Ajouter manuellement des balises structurantes : titres, listes, sections.
- Coupler WPBakery à un plugin SEO performant (comme RankMath, SEOPRESS ou Yoast).
- Optimiser les performances avec un cache serveur (Redis, Varnish) et un CDN.
- Utiliser une extension de cache de type WP ROCKET
8. Cas concret : impact d’un nettoyage WPBakery sur le SEO
Avant :
- Page d’accueil avec 122 requêtes réseau.
- DOM de 2800 lignes.
- Score mobile PageSpeed : 48/100.
Après refonte manuelle sous Gutenberg :
- DOM réduit à 900 lignes.
- Temps de chargement divisé par deux.
- Score mobile PageSpeed : 91/100.
- +38 % de trafic SEO en 3 mois.
9. Comparatif entre WPBakery, Elementor et Full Site Editing (FSE)
À l’heure où WordPress évolue vers une logique de composition complète du site via le Full Site Editing (FSE), il devient essentiel de comparer WPBakery avec deux autres approches répandues : Elementor (page builder visuel concurrent) et FSE (solution native désormais intégrée à WordPress).
| Critères | WPBakery | Elementor | Full Site Editing (FSE) |
|---|---|---|---|
| Provenance | Plugin tiers | Plugin tiers | Intégré nativement à WordPress |
| Code généré | Très dense et peu sémantique | Plus optimisé mais encore lourd | Léger, balisage HTML natif |
| Sémantique HTML | Mauvaise gestion | Moyenne | Excellente (selon le thème utilisé) |
| Performance (Core Web Vitals) | Mauvaise | Moyenne à correcte (optimisable) | Excellente |
| Accessibilité | Très limitée | Moyenne | Native et améliorée progressivement |
| Temps de chargement | Long | Correct avec optimisation | Très rapide |
| Shortcodes | Oui, fortement utilisés | Non | Non |
| Support SEO natif | Faible | Bon via extensions | Excellent avec peu de dépendances |
| Adapté aux thèmes modernes | Non | Oui | Oui |
| Dépendance à un plugin | Totale | Totale | Aucune |
| Courbe d’apprentissage | Moyenne | Facile | Variable selon l’utilisateur |
| Contrôle total du design | Partiel | Avancé | Complet (via blocs et modèles) |
| Maintenance à long terme | Risquée (dépendance plugin) | Correcte | Pérenne (dans le core WordPress) |
| Migrations futures | Complexes | Moyennement flexibles | Très faciles |
9.1 Ce qu’il faut retenir pour le SEO
- WPBakery reste très limité : structure lourde, HTML non sémantique, ralentissements fréquents.
- Elementor est plus souple, mais nécessite des ajustements manuels pour être réellement SEO-friendly.
- FSE est la solution la plus saine à long terme, tant en SEO qu’en accessibilité, surtout si l’on utilise un thème bien conçu (comme Twenty Twenty-Four ou Blocksy FSE).
9.2 Recommandation d’expert
Pour un site à fort enjeu de visibilité, privilégiez :
- Elementor si vous avez besoin d’une interface intuitive et visuelle sans trop de code.
- FSE si vous souhaitez optimiser la performance, le SEO, et la maintenance à long terme.
Dans tous les cas, évitez WPBakery pour les projets nouveaux. Pour les projets existants, envisagez une migration encadrée.
Souhaitez-vous un audit comparatif détaillé de votre site actuel ou un tableau de décision pour conseiller vos clients dans le choix du bon builder ?
Demander à ChatGPT
WPBakery, un outil à manier avec précaution
WPBakery n’est pas incompatible avec le SEO, mais il nécessite une supervision technique constante. Les sites mal conçus sous WPBakery souffrent souvent d’un code lourd, de lenteurs, et d’une indexabilité limitée, autant d’éléments pénalisants dans un environnement concurrentiel.
Pour les projets exigeants en visibilité, il est préférable de s’orienter vers un builder plus moderne ou de solliciter une agence SEO experte, capable de cadrer techniquement les limitations de WPBakery.
Et si nous échangions sur les performances et l’optimisation de votre site WordPress ?
N’hésitez pas à nous contacter pour un pré-audit de votre site internet et un échange avec un expert wordpress depuis le formulaire ci-dessous :
