Les 10 erreurs WordPress les plus courantes et comment les résoudre (2026)

Votre site WordPress affiche un écran blanc. Ou une erreur 500. Ou pire : il ne charge plus du tout. Pas de panique — c’est probablement l’une des dix erreurs que je vais détailler ici, et j’ai résolu chacune d’elles des dizaines de fois en 13 ans de support WordPress.

Ce guide existait depuis 2013. À l’époque, il couvrait six erreurs en 1700 mots, avec des titres en majuscules et des solutions parfois dépassées. La version 2026 couvre les dix erreurs les plus fréquentes que je rencontre sur les sites de mes clients et stagiaires, avec des solutions testées en production.

Avant d’entrer dans le détail : installez le plugin Health Check & Troubleshooting (gratuit, maintenu par la communauté WordPress). Il permet de désactiver les plugins et changer de thème sans affecter les visiteurs. Un outil de diagnostic indispensable qu’on verra en fin d’article. Pensez aussi a consulter l’outil natif Sante du site de WordPress pour un diagnostic complet de votre configuration.

Réflexe n°1 : activer le mode debug

Quel que soit le problème, la première chose à faire est d’activer le mode debug de WordPress. Sans ça, vous travaillez à l’aveugle. Ouvrez votre fichier wp-config.php par FTP ou via le gestionnaire de fichiers de votre hébergeur, et modifiez ces lignes :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Les erreurs seront enregistrées dans wp-content/debug.log. Ce fichier est votre meilleur allié — il contient le nom exact du plugin ou du thème qui pose problème, le fichier concerné et la ligne de code fautive. Pensez à remettre WP_DEBUG à false une fois le problème résolu.

Les 10 erreurs WordPress les plus fréquentes

1. L’écran blanc de la mort (WSOD)

Symptômes : Page entièrement blanche, aucun message d’erreur. Le front-end ne répond plus, parfois le back-end non plus.

Causes les plus fréquentes : un plugin incompatible après une mise à jour, un thème buggé, ou un dépassement de la limite mémoire PHP. En 2026, c’est souvent une incompatibilité avec PHP 8.2 ou 8.3 — des plugins qui tournaient bien en PHP 7.4 mais utilisent des fonctions dépréciées.

Solution pas à pas :

• Activez WP_DEBUG (voir ci-dessus) et consultez wp-content/debug.log
• Si le back-end est inaccessible : renommez le dossier wp-content/plugins/ en plugins-disabled/ par FTP. Si le site revient, réactivez les plugins un par un
• Si c’est le thème : renommez le dossier de votre thème actif. WordPress basculera sur un thème par défaut
• Augmentez la mémoire PHP (voir erreur n°5)

2. Erreur 500 Internal Server Error

Symptômes : Message "500 Internal Server Error" ou "There has been a critical error on this website". L’erreur la plus vague qui soit — elle signifie que le serveur a planté sans savoir expliquer pourquoi.

Causes les plus fréquentes : fichier .htaccess corrompu, limite mémoire PHP atteinte, plugin mal codé, mise à jour WordPress interrompue, ou droits de fichiers incorrects.

Solution pas à pas :

• Renommez .htaccess en .htaccess-backup par FTP. Rendez-vous dans Réglages → Permaliens et cliquez "Enregistrer". WordPress regénère un .htaccess propre
• Consultez le fichier error_log à la racine de votre site (ou wp-content/debug.log si WP_DEBUG est actif)
• Augmentez la mémoire PHP dans wp-config.php
• Vérifiez les droits : dossiers en 755, fichiers en 644. Un chmod par FTP ou SSH règle ça en deux minutes
• Si l’erreur persiste, désactivez tous les plugins par FTP (méthode du WSOD)

J’ai vu des erreurs 500 causées par un simple espace en trop dans .htaccess après une modification manuelle. Résultat : site down pendant 3 heures le temps que le client me contacte. Le fichier .htaccess, on le touche avec des pincettes — ou pas du tout.

3. Erreur de connexion à la base de données

Symptômes : Message "Error establishing a database connection" sur toutes les pages, front-end et back-end.

Causes les plus fréquentes : identifiants BDD incorrects dans wp-config.php, serveur MySQL en panne, base de données corrompue, ou dépassement du quota de connexions simultanées.

Solution pas à pas :

• Vérifiez les 4 constantes dans wp-config.php : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST (souvent localhost sur un mutualisé)
• Testez la connexion MySQL depuis phpMyAdmin dans le cPanel de votre hébergeur
• Si phpMyAdmin fonctionne mais pas WordPress : le mot de passe BDD a probablement été changé côté hébergeur sans mise à jour dans wp-config.php
• Si la base est corrompue, ajoutez dans wp-config.php :

  define('WP_ALLOW_REPAIR', true);

  puis allez sur votresite.com/wp-admin/maint/repair.php. Retirez la ligne après réparation

4. Erreur 404 sur toutes les pages

Symptômes : La page d’accueil fonctionne, mais toutes les autres pages et articles renvoient une erreur 404.

Causes les plus fréquentes : fichier .htaccess manquant ou corrompu, problème de réécriture d’URL sur le serveur (module mod_rewrite désactivé), ou changement de structure de permaliens non enregistré.

Solution pas à pas :

• Rendez-vous dans Réglages → Permaliens, ne changez rien, et cliquez "Enregistrer". Dans 70% des cas, ça suffit
• Si le problème persiste : vérifiez que mod_rewrite est activé (contactez votre hébergeur)
• Sur un serveur Nginx : les règles de réécriture se gèrent différemment, dans la configuration du vhost. Pas de .htaccess avec Nginx
• Vérifiez que le fichier .htaccess contient bien les règles WordPress standard

Le contenu standard du .htaccess WordPress :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

J’ai un fichier texte avec ce contenu sur mon bureau. Je le copie-colle plusieurs fois par mois quand un client ou un stagiaire me signale des 404 sur tout son site après avoir "nettoyé" le .htaccess. Gardez-le aussi.

5. Erreur de mémoire PHP (Fatal error: Allowed memory size)

Symptômes : Message "Fatal error: Allowed memory size of 67108864 bytes exhausted". Traduction : WordPress a besoin de plus de mémoire que ce que PHP autorise.

Causes les plus fréquentes : limite mémoire PHP trop basse (64 MB par défaut sur certains hébergeurs), plugin gourmand (WooCommerce, page builders), import de fichier volumineux, ou thème mal optimisé qui charge tout en mémoire.

Solution pas à pas :

Ajoutez dans wp-config.php, avant la ligne /* That's all, stop editing! */ :

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Si ça ne suffit pas, modifiez aussi php.ini ou .user.ini :

memory_limit = 256M

• Sur o2switch et la plupart des mutualisés : la modification via .user.ini fonctionne
• Sur un VPS : modifiez directement php.ini et redémarrez PHP-FPM
• Si le problème revient malgré 256 MB, le vrai souci est un plugin qui fuit de la mémoire. Utilisez Query Monitor pour identifier le coupable

6. Maximum execution time exceeded

Symptômes : Message "Fatal error: Maximum execution time of 30 seconds exceeded". Le script PHP tourne trop longtemps et le serveur l’arrête.

Causes les plus fréquentes : import volumineux (WooCommerce, migration), plugin qui effectue des requêtes API lentes, mise à jour d’un plugin avec beaucoup de données à traiter, ou requêtes BDD mal optimisées.

Solution :

Augmentez le timeout dans .user.ini ou php.ini :

max_execution_time = 300

Ou dans wp-config.php :

set_time_limit(300);

300 secondes (5 minutes) est généralement suffisant pour les imports lourds. Remettez à 60 secondes une fois l’opération terminée — un timeout élevé en permanence masque les problèmes de performance et peut exposer votre serveur à des abus.

7. Erreur de mise à jour (cURL error, update failed)

Symptômes : Message "cURL error 28: Connection timed out" lors des mises à jour, ou "An automated WordPress update has failed to complete". Parfois, le site reste en mode maintenance après une MAJ interrompue.

Causes les plus fréquentes : timeout réseau entre votre serveur et les serveurs WordPress.org/api.wordpress.org, hébergeur qui bloque les connexions sortantes, conflit pendant une mise à jour automatique, ou espace disque insuffisant.

Solution pas à pas :

• Si le site est bloqué en mode maintenance : supprimez le fichier .maintenance à la racine par FTP. Le site revient immédiatement
• Pour les erreurs cURL : vérifiez que votre hébergeur n’a pas de firewall qui bloque les connexions sortantes vers api.wordpress.org
• Mettez à jour manuellement : téléchargez le fichier ZIP depuis wordpress.org, décompressez, uploadez via FTP en écrasant les fichiers existants (sauf wp-content et wp-config.php)
• Espace disque : vérifiez qu’il vous reste au moins 200 MB libres. Les mises à jour WordPress téléchargent, décompressent et copient — ça prend de la place temporaire

8. Sidebar en dessous du contenu

Symptômes : La barre latérale (sidebar) s’affiche sous le contenu principal au lieu d’être à côté. Le layout est cassé.

Causes les plus fréquentes : une balise HTML non fermée dans un article ou un widget, du CSS qui force une largeur trop grande, ou un plugin qui injecte du HTML mal formé avant la sidebar.

Solution pas à pas :

• Inspectez le HTML avec les DevTools du navigateur (F12). Cherchez les balises <div> non fermées — elles décalent toute la structure
• Vérifiez le dernier article modifié : si vous avez collé du contenu depuis Word ou un autre éditeur, il y a probablement des balises parasites
• Testez en désactivant les widgets un par un dans Apparence → Widgets
• Regardez si un plugin injecte du contenu avec un filtre the_content qui casse le HTML

Ce bug est moins fréquent avec les thèmes basés sur les blocs (FSE), mais reste courant sur les thèmes classiques. Sur le thème Astra que j’utilise, la sidebar est gérée proprement — mais j’ai vu des thèmes gratuits du répertoire WordPress.org où une simple balise </div> manquante suffisait à tout casser.

9. "Briefly unavailable for scheduled maintenance"

Symptômes : Le message "Briefly unavailable for scheduled maintenance. Check back in a minute." s’affiche sur toutes les pages et ne disparaît pas.

Cause : WordPress crée un fichier .maintenance à la racine pendant les mises à jour. Normalement, il le supprime après. Si la mise à jour échoue ou est interrompue (fermeture du navigateur, timeout serveur), le fichier reste et le site reste bloqué.

Solution :

Supprimez le fichier .maintenance à la racine de votre installation WordPress via FTP. C’est tout. Le site revient instantanément.

define( 'AUTOMATIC_UPDATER_DISABLED', true );

10. ERR_TOO_MANY_REDIRECTS

Symptômes : Le navigateur affiche "ERR_TOO_MANY_REDIRECTS" ou "La page n’est pas redirigée correctement". Le site est inaccessible.

Causes les plus fréquentes : conflit entre l’URL en HTTP et HTTPS (WordPress redirige en boucle), mauvaise configuration de WP_HOME et WP_SITEURL, plugin de redirection mal configuré, ou CDN/Cloudflare avec une configuration SSL partielle.

Solution pas à pas :

• Videz les cookies de votre navigateur pour le domaine concerné
• Vérifiez dans wp-config.php que WP_HOME et WP_SITEURL pointent vers la bonne URL (HTTP ou HTTPS, pas un mélange des deux)
• Si vous utilisez Cloudflare : passez le mode SSL en "Full (strict)" au lieu de "Flexible". Le mode Flexible cause des boucles de redirection quand votre serveur a déjà un certificat SSL
• Désactivez temporairement les plugins de redirection (Redirection, Yoast) par FTP pour isoler le conflit
• Vérifiez le .htaccess : s’il contient plusieurs règles de redirection HTTP→HTTPS, elles peuvent se contredire

// Forcer HTTPS dans wp-config.php
define( 'WP_HOME', 'https://votresite.com' );
define( 'WP_SITEURL', 'https://votresite.com' );
define( 'FORCE_SSL_ADMIN', true );

J’ai eu ce problème sur wpformation.com lors de la migration vers l’architecture headless. Le serveur o2switch renvoyait du HTTPS, mais le reverse proxy Next.js attendait du HTTP en entrée. Résultat : boucle infinie. La solution était de forcer les constantes dans wp-config.php et de gérer le SSL uniquement côté Vercel.

Outils de diagnostic WordPress

Au-delà du mode debug, quatre outils vous feront gagner un temps considérable pour diagnostiquer les problèmes WordPress.

WP_DEBUG et le fichier debug.log

On en a parlé en début d’article. Avec WP_DEBUG_LOG activé, chaque erreur PHP est enregistrée dans wp-content/debug.log. Ce fichier vous dit précisément quel plugin, quel fichier et quelle ligne provoque l’erreur. Sans ça, vous devinez. Avec, vous savez.

Query Monitor

Query Monitor est le couteau suisse du debug WordPress. Il affiche en temps réel les requêtes SQL, les hooks exécutés, la consommation mémoire de chaque composant, les erreurs PHP, les requêtes HTTP et les fichiers de template chargés. Si un plugin ralentit votre site, Query Monitor vous le montre noir sur blanc.

Le fichier error_log du serveur

Indépendamment de WordPress, votre serveur web maintient son propre journal d’erreurs. Sur Apache, il se trouve souvent dans /var/log/apache2/error.log ou à la racine de votre hébergement. Sur o2switch, vous pouvez le consulter via cPanel → Erreurs. Ce fichier capture les erreurs que WordPress lui-même ne voit pas : problèmes de permissions, modules manquants, configurations serveur incorrectes.

Health Check & Troubleshooting

Ce plugin officiel permet de basculer WordPress dans un mode de dépannage sans affecter les visiteurs. Vous seul voyez le thème par défaut et les plugins désactivés. Les visiteurs continuent de voir le site normal. C’est l’outil idéal pour diagnostiquer un conflit sans mettre le site hors ligne.

Combinés, ces quatre outils couvrent 95% des diagnostics WordPress. Pour le reste, il y a les logs du serveur, phpinfo() et un café bien serré.

Tableau récapitulatif

Pour retrouver rapidement la solution adaptée à votre erreur :

Questions fréquentes

define( 'WP_DEBUG', false );

define( 'WP_DEBUG_LOG', true );

define('WP_HOME','https://votresite.com');

define('WP_SITEURL','https://votresite.com');

Ces dix erreurs couvrent la grande majorité des plantages WordPress que vous rencontrerez. La méthode est toujours la même : activer WP_DEBUG, lire le message d’erreur réel, isoler la cause (plugin, thème, serveur), et appliquer la solution ciblée. Pas de panique, pas de réinstallation sauvage. Du diagnostic méthodique.

Pour aller plus loin dans la maintenance de votre site, consultez notre guide SEO WordPress, les rappels de sécurité WordPress, et si vous partez de zéro, le guide complet pour installer WordPress. Besoin d’un hébergement fiable ? Notre comparatif des hébergements WordPress est mis à jour régulièrement.