Erreurs Elementor : les pannes les plus fréquentes et leur résolution
Les pannes Elementor (éditeur bloqué, « Preview could not be loaded », écran blanc) viennent presque toujours de quatre causes : mémoire PHP insuffisante, conflit de plugin ou de thème, blocage serveur ou CDN, versions de PHP ou WordPress hors prérequis. On les règle en testant ces causes dans l’ordre, après une sauvegarde.
Ce matin, sur un site sous Elementor, l’éditeur restait sur un écran gris avec un spinner. Le site public fonctionnait très bien, seule l’édition était bloquée. C’est le cas le plus courant : vos visiteurs ne voient rien, mais vous ne pouvez plus modifier vos pages. La panne est gérable, et la plupart des cas se règlent en moins d’une heure.
Avant toute manipulation, faites une sauvegarde complète (fichiers et base de données). Si votre hébergeur propose un site de test (staging), travaillez dessus.
Pourquoi Elementor tombe en panne
Elementor charge dans votre navigateur une interface lourde (l’éditeur) qui affiche votre page dans un cadre (le canvas). Tout ce qui perturbe ce chargement bloque l’éditeur. D’après la documentation Elementor sur l’erreur « Preview could not be loaded », les causes sont les suivantes :
- limite de mémoire PHP trop basse ;
- conflit avec un plugin ou le thème (erreurs JavaScript) ;
- permaliens corrompus ou fichier .htaccess endommagé ;
- pare-feu serveur (mod_security), permissions de fichiers ou répertoire protégé par mot de passe ;
- Rocket Loader activé chez Cloudflare ;
- fichier index.html oublié à la racine, qui passe avant index.php.
S’y ajoutent les versions de PHP et de WordPress trop anciennes, et les add-ons Elementor non mis à jour.
1. Écarter le navigateur (2 minutes)
Videz le cache du navigateur, puis ouvrez l’éditeur en navigation privée ou dans un autre navigateur. Une extension (bloqueur de publicités, gestionnaire de mots de passe) peut bloquer un script de l’éditeur. Si l’édition fonctionne en navigation privée, la panne vient de votre navigateur, pas du site. Désactivez vos extensions une par une.
2. Activer le Safe Mode d’Elementor
Le Safe Mode est un mode de chargement de l’éditeur qui désactive les styles du thème et les scripts des plugins tiers, sans changer ce que voient les visiteurs. La documentation Elementor le place en premier réflexe de diagnostic.
- Dans l’administration, allez dans Elementor > Outils > Général (Elementor > Tools > General en anglais).
- Activez « Safe Mode ».
- Rouvrez la page dans l’éditeur.
Si l’éditeur s’ouvre, la cause est un plugin ou le thème : passez à l’étape 7. S’il reste bloqué, continuez dans l’ordre.
3. Vérifier la mémoire PHP
La directive memory_limit correspond à la quantité maximale de mémoire qu’un script PHP peut consommer. Quand elle est trop basse, l’éditeur affiche un écran blanc, reste sur le spinner ou plante à l’enregistrement. Elementor demande au minimum 256 Mo, recommande 512 Mo et indique 768 Mo pour de meilleures performances source : Elementor, 2026.
Pour connaître la valeur réelle, ouvrez Elementor > System Info : la limite mémoire de WordPress y est affichée, comme le précise la page System Info d’Elementor. Si elle est inférieure à 256M, augmentez-la.
Dans wp-config.php, juste avant la ligne « That’s all, stop editing » :
define( 'WP_MEMORY_LIMIT', '512M' );
Cette ligne ne suffit pas toujours : l’hébergeur peut plafonner la valeur côté serveur. Comparez alors la limite PHP effective et celle de WordPress, puis modifiez memory_limit dans le panel de l’hébergeur (« Version de PHP » ou « Options PHP ») ou dans php.ini. Si vous voyez le message « allowed memory size of X bytes exhausted » dans les logs, la cause est confirmée. Notre guide sur la mémoire PHP épuisée sur WordPress détaille chaque méthode.
Les directives PHP qui touchent Elementor
| Directive | Rôle | Symptôme si trop basse | Valeur de départ |
|---|---|---|---|
| memory_limit | Mémoire maximale par script | Écran blanc, spinner infini | 512M |
| max_execution_time | Durée maximale d’un script (secondes) | Enregistrement qui échoue, erreur 504 | 300 |
| max_input_vars | Nombre maximal de champs envoyés dans une requête | Réglages ou sections qui ne s’enregistrent pas | 3000 |
| post_max_size | Taille maximale des données envoyées | Enregistrement refusé sur les grosses pages | 64M |
| upload_max_filesize | Taille maximale d’un fichier téléversé | Import de modèles ou de médias refusé | 64M |
Ces réglages se modifient dans le panel de l’hébergeur, dans php.ini ou dans .user.ini. Le guide directives PHP WordPress expliquées donne les détails par hébergeur.
4. Contrôler les versions de PHP et de WordPress
Elementor exige WordPress 6.8 ou supérieur. Côté PHP, le minimum est 7.4 et Elementor recommande fortement PHP 8.3 ou plus source : Elementor, 2026. La branche 7.4 n’est plus maintenue : l’atteindre n’est pas une raison de la garder en production.
Dans Outils > Santé du site > Infos, vérifiez la version de PHP. Si elle est ancienne, changez-la depuis le panel de l’hébergeur, après une sauvegarde et un test sur une copie. Faites ensuite les mises à jour d’Elementor, d’Elementor Pro et des add-ons ensemble. Une version de Pro qui ne correspond pas à celle d’Elementor produit des erreurs d’éditeur. La méthode est décrite dans mettre à jour WordPress sans rien casser.
5. Réparer permaliens.htaccess et index.html
Si vous voyez « Preview could not be loaded », faites ces trois vérifications :
- Allez dans Réglages > Permaliens et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress régénère les règles de réécriture.
- Par FTP ou le gestionnaire de fichiers, renommez .htaccess en .htaccess-old, puis réenregistrez les permaliens pour en générer un neuf.
- Cherchez un fichier index.html à la racine du site. S’il existe, renommez-le : il supplante index.php.
Si toutes les pages de votre site renvoient une 404, lisez plutôt erreur 404 sur toutes les pages WordPress.
6. Désactiver Rocket Loader et vérifier le pare-feu
Un CDN est un réseau de serveurs répartis qui sert vos fichiers depuis le point le plus proche du visiteur. Cloudflare en est le plus courant. Rocket Loader est une option Cloudflare qui reporte le chargement des scripts JavaScript, ce qui perturbe l’éditeur. Elementor cite cette option comme cause connue de blocage.
Dans Cloudflare : Vitesse > Optimisation > Rocket Loader, puis désactivez-le. Purgez ensuite le cache Cloudflare et celui de votre plugin de cache.
Si l’éditeur reste bloqué, demandez à l’hébergeur de vérifier si le pare-feu serveur (mod_security) bloque les requêtes d’Elementor, et s’il ne bride pas la mémoire. Il peut lire les logs et lever la règle en quelques minutes.
7. Appliquer la méthode de conflit de plugins
Si le Safe Mode a débloqué l’éditeur, un plugin ou le thème est en cause. La méthode WordPress Learn est la plus fiable :
- Installez le plugin Health Check & Troubleshooting.
- Allez dans Outils > Santé du site > Dépannage et activez le Mode dépannage. Tous les plugins sont désactivés et le thème par défaut est chargé, pour votre session uniquement.
- Gardez Elementor et Elementor Pro actifs, puis réactivez les autres plugins un par un.
- Testez l’éditeur après chaque activation. Le dernier plugin réactivé avant le retour de l’erreur est le coupable.
Si la réactivation du plugin fautif bloque l’accès à l’administration, supprimez ou renommez son dossier dans wp-content/plugins par FTP. La procédure complète est dans notre article sur le conflit de plugins WordPress.
Cas particulier : widgets disparus
Aucune source officielle n’en fait un cas standard, mais ce qui suit vient de l’expérience du terrain. Quand un widget disparaît du panneau ou laisse une zone vide dans une page, les causes habituelles sont :
- un add-on tiers désactivé, supprimé ou incompatible avec la version d’Elementor ;
- Elementor Pro désactivé ou sa licence expirée : les widgets Pro ne se modifient plus ;
- une mise à jour partielle (Elementor à jour, Pro ou add-on resté en retard) ;
- un cache qui sert une ancienne version des scripts de l’éditeur.
Réactivez l’add-on concerné, mettez à jour toutes les extensions Elementor, puis videz les caches. Si le widget venait d’un add-on abandonné par son éditeur, il faudra le remplacer.
Tableau récapitulatif : cause, symptôme, solution
| Symptôme | Cause probable | Solution |
|---|---|---|
| Page grise, spinner infini | Conflit de plugin, cache, extension navigateur | Navigation privée, Safe Mode, méthode de conflit |
| Preview could not be loaded | Permaliens.htaccess, Rocket Loader, mod_security | Réenregistrer les permaliens, désactiver Rocket Loader, contacter l’hébergeur |
| Écran blanc à l’édition | memory_limit trop basse ou erreur fatale | Passer à 512M, lire les logs |
| Réglages non enregistrés | max_input_vars ou max_execution_time trop bas | Augmenter les deux directives |
| Widgets absents | Add-on ou Pro désactivé, mise à jour partielle | Réactiver, tout mettre à jour |
| Erreur après changement de PHP | Version incompatible d’un plugin | Revenir à la version précédente, mettre à jour le plugin |
Pour un écran blanc qui touche aussi le site public, passez par l’écran blanc WordPress ou par le message « Une erreur critique est survenue ».
FAQ
Le Safe Mode d'Elementor modifie-t-il mon site pour les visiteurs ?
Non. Il ne change que le chargement de l’éditeur pour l’administrateur. Les visiteurs ne voient aucune différence sur le site public.
Quelle mémoire PHP faut-il pour Elementor ?
256 Mo est le minimum, 512 Mo est la valeur recommandée, et 768 Mo améliore les performances sur les sites chargés en plugins, selon la documentation d’Elementor.
J'ai mis WP_MEMORY_LIMIT à 512M et rien ne change, pourquoi ?
L’hébergeur plafonne peut-être la mémoire côté serveur. Vérifiez la limite effective dans Elementor > System Info ou dans Outils > Santé du site, puis modifiez memory_limit dans le panel de l’hébergeur ou demandez-lui de le faire.
Dois-je rester en PHP 7.4 parce que c'est le minimum d'Elementor ?
Non. Cette branche n’est plus maintenue. Passez à une version récente (Elementor recommande PHP 8.3 ou plus) après une sauvegarde et un test sur une copie du site.
Quand passer la main à un pro
Faites appel à un professionnel dans ces cas :
- le Safe Mode, la mémoire et la méthode de conflit n’ont rien changé ;
- les logs PHP montrent une erreur fatale que vous ne savez pas lire ;
- l’hébergeur ne répond pas ou refuse de modifier la configuration ;
- le site public est touché, pas seulement l’éditeur.
Ces pannes reviennent surtout sur les sites dont les mises à jour sont faites au hasard. Une maintenance régulière (sauvegardes, mises à jour testées, versions de PHP suivies) évite la plupart des cas décrits ici.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy


