Problème WordPress : les 25 pannes les plus fréquentes et comment les corriger

« Mon site WordPress ne marche plus » recouvre des situations très différentes : un serveur muet, une page blanche, un tableau de bord inaccessible, une boutique qui refuse les commandes. Le code affiché par le navigateur ne dit pas d'où vient le problème, seulement qui a renoncé en premier. Cette page rassemble les vingt-cinq pannes que notre équipe rencontre le plus depuis 2016 : symptôme, cause fréquente, correction.

Trouver la cause en dix minutes

Une panne se diagnostique en éliminant, pas en devinant. L'ordre ci-dessous vaut pour presque tous les symptômes, y compris sans accès à l'administration.

Répondre à trois questions avant de toucher au site

Qu'est-ce qui a changé ? Une mise à jour du cœur, d'un thème ou d'une extension dans les heures précédentes explique la majorité des pannes que nous voyons. Quand ? Notez l'heure du premier symptôme : elle servira à retrouver la bonne ligne dans le journal du serveur. Pour qui ? Testez le site en navigation privée et depuis un mobile en 4G : une panne visible seulement chez vous vient d'un cache local. Avant toute manipulation, faites une sauvegarde complète des fichiers et de la base.

Lire le journal des erreurs et activer WP_DEBUG

Le journal d'erreurs PHP de l'hébergement, souvent un error_log à la racine ou un onglet « Journaux » du panneau, nomme le fichier fautif et sa ligne. S'il est vide, ajoutez ces lignes dans wp-config.php, avant « That's all, stop editing! » :

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

Les messages partent alors dans wp-content/debug.log sans s'afficher aux visiteurs. Retirez-les une fois le problème réglé : un journal accessible renseigne aussi les curieux. Voir notre guide sur l'affichage des erreurs WordPress.

Le mode de récupération et le courriel d'erreur critique

Depuis WordPress 5.2, une erreur fatale dans un thème ou une extension déclenche une protection : le visiteur voit un message neutre et un courriel part vers l'adresse d'administration avec un lien secret. Ce lien ouvre le mode de récupération, met en pause l'extension fautive et vous rend l'accès. Vérifiez la boîte de l'adresse enregistrée dans Réglages, Général, indésirables compris : le fichier coupable y est nommé. Voir aussi le mode sans échec de WordPress.

Désactiver toutes les extensions sans accès à l'administration

WordPress.org documente deux méthodes. Par FTP : renommez wp-content/plugins en plugins.hold, connectez-vous, remettez le nom d'origine ; les extensions restent désactivées. Par phpMyAdmin : dans wp_options, ligne active_plugins, remplacez la valeur par a:0:{}. En SSH, wp plugin deactivate --all suffit. Réactivez ensuite une extension à la fois. Nos pas à pas : par FTP, depuis phpMyAdmin, et résoudre un conflit d'extensions.

Basculer sur un thème par défaut et réenregistrer les permaliens

Si le site reste cassé toutes extensions désactivées, le thème est en cause : renommez son dossier dans wp-content/themes pour forcer le thème par défaut, ou lancez wp theme activate twentytwentyfive. Dernier réflexe universel : ouvrez Réglages, Permaliens et cliquez sur Enregistrer sans rien changer. Cela reconstruit les règles de réécriture et corrige une part des erreurs 404 qui touchent toutes les pages sauf l'accueil.

Le site est inaccessible : les erreurs du serveur

Ces codes viennent du serveur web, pas de WordPress. Leur définition normative indique déjà quel maillon de la chaîne a abandonné.

Erreur 500, erreur interne du serveur

Le serveur a rencontré une condition inattendue et n'a rien de plus précis à dire. Les causes fréquentes sont un .htaccess corrompu, une erreur PHP fatale, la mémoire épuisée ou des permissions incorrectes. La documentation recommande dans l'ordre : renommer .htaccess en .htaccess_old puis réenregistrer les permaliens, désactiver les extensions, activer un thème par défaut, augmenter la mémoire, enfin remplacer wp-admin et wp-includes par ceux d'une archive propre. Voir l'erreur 500 sur WordPress.

Erreur 502 Bad Gateway

Un serveur frontal, nginx ou un service de cache, a reçu une réponse invalide du serveur qui exécute PHP. Le plus souvent, le pool PHP-FPM est saturé, vient de redémarrer, ou un processus trop gourmand a été tué. Le 502 est souvent transitoire : rechargez, videz le cache du CDN, demandez les journaux à l'hébergeur. S'il revient chaque jour à la même heure, cherchez une tâche lourde. Voir corriger une erreur 502.

Erreur 503 Service Unavailable

Le serveur est temporairement incapable de traiter la requête, pour surcharge ou maintenance planifiée, et devrait joindre un en-tête Retry-After. Sur WordPress : pic de trafic, tâche planifiée qui boucle, extension qui interroge une API lente, ou maintenance de l'hébergeur. Ne confondez pas ce 503 avec les codes 520 à 524 renvoyés par un service intermédiaire. Notre tutoriel : corriger l'erreur 503.

Erreur 504 Gateway Timeout

Le frontal n'a pas reçu de réponse de l'amont dans le délai imparti. La cause est presque toujours un script PHP trop long : import de produits, sauvegarde, recalcul de boutique, requête externe sans réponse, table verrouillée. Identifiez le script, relevez le temps d'exécution maximal (30 secondes par défaut en PHP) et déplacez les traitements longs vers la ligne de commande. Voir l'erreur 504 Gateway Timeout.

Erreur 429, trop de requêtes

Défini par la RFC 6585, le code 429 signale que le client a envoyé trop de requêtes dans un laps de temps donné ; un en-tête Retry-After indique quand réessayer. Sur WordPress, il vient d'une limitation de l'hébergeur, d'un pare-feu, ou d'une attaque en force brute sur wp-login.php et xmlrpc.php. Une extension qui appelle une API en boucle fait le même effet. Lisez les journaux avant de lever la limite. Voir HTTP Error 429.

ERR_CONNECTION_REFUSED, ERR_TIMED_OUT et ERR_NAME_NOT_RESOLVED

Ces messages viennent du navigateur : la requête n'a jamais abouti. ERR_NAME_NOT_RESOLVED pointe le DNS, donc un domaine expiré, une zone modifiée ou une propagation en cours. ERR_CONNECTION_REFUSED signifie que rien n'écoute sur le port, souvent après un changement d'IP. ERR_TIMED_OUT traduit un serveur saturé ou un pare-feu qui ignore les paquets. Vérifiez l'expiration du domaine, la résolution DNS depuis un autre réseau et l'état de l'hébergeur. Voir les erreurs ERR_ de Chrome et ERR_NAME_NOT_RESOLVED.

Les erreurs propres à WordPress

Ici le serveur répond : c'est WordPress ou PHP qui s'arrête. Le journal de débogage nomme presque toujours le fichier en cause.

« Il y a eu une erreur critique sur ce site »

C'est le message de la protection contre les erreurs fatales : une extension ou un thème a produit une erreur PHP que WordPress a interceptée pour ne pas en montrer le détail. La cause la plus fréquente est une mise à jour incompatible avec la version de PHP du serveur, ou deux extensions qui déclarent la même fonction. Ouvrez le courriel de récupération, ou lisez la dernière ligne de debug.log. Notre guide : erreur critique sur ce site.

L'écran blanc de la mort

La page est entièrement vide, sans message ni code d'erreur : une erreur fatale est survenue avant que le gestionnaire d'erreurs ne s'exécute, ou l'affichage des erreurs est coupé sur le serveur. Traitement identique : désactivez les extensions, activez un thème par défaut, puis activez WP_DEBUG pour obtenir un message. Si seule l'administration est blanche, cherchez une extension d'administration ou un cache d'objet corrompu. Voir réparer la page blanche.

« Erreur lors de l'établissement d'une connexion à la base de données »

WordPress ne joint plus MySQL ou MariaDB. Vérifiez les quatre valeurs de wp-config.php : base, utilisateur, mot de passe, hôte. Si elles sont bonnes, le serveur de base est arrêté, le quota dépassé, ou une table corrompue. Dans ce cas ajoutez define( 'WP_ALLOW_REPAIR', true );, ouvrez /wp-admin/maint/repair.php, puis retirez la ligne ; en SSH, wp db repair lance REPAIR TABLE. Voir erreur de base de données WordPress.

Le site reste bloqué en mode maintenance

Les visiteurs lisent « Briefly unavailable for scheduled maintenance » ou sa traduction. Pendant une mise à jour, WordPress dépose un fichier .maintenance à la racine et le supprime à la fin ; si la mise à jour s'interrompt, le fichier reste. Supprimez .maintenance par FTP, puis relancez la mise à jour, qui avait sans doute échoué. Pas à pas : rétablir un site bloqué en maintenance.

Boucle de redirection : ERR_TOO_MANY_REDIRECTS

Le navigateur abandonne parce que deux règles se renvoient la balle. Causes classiques : les champs siteurl et home de wp_options qui ne correspondent pas à l'adresse réelle, une redirection HTTPS écrite à la fois dans .htaccess et dans une extension, un service intermédiaire réglé en mode « Flexible » alors que le serveur redirige déjà, une extension de redirection mal réglée. Corrigez d'abord les deux options en base. Voir corriger err_too_many_redirects.

Mémoire PHP épuisée ou temps d'exécution dépassé

« Allowed memory size exhausted » et « Maximum execution time exceeded » désignent deux limites de PHP atteintes par un script. WordPress tente par défaut de porter la mémoire à 40 Mo pour un site simple et 64 Mo pour un multisite, loin des besoins d'un constructeur de pages. Relevez WP_MEMORY_LIMIT dans wp-config.php, et si l'hébergeur le permet memory_limit et max_execution_time. Nos guides : l'erreur de limite de mémoire et augmenter la limite de mémoire PHP.

Connexion et accès au tableau de bord

Le site public fonctionne, mais vous ne pouvez plus administrer. Première question : problème technique, ou quelqu'un d'autre a-t-il pris la main ?

wp-admin inaccessible ou qui renvoie sans cesse à la connexion

Vous saisissez vos identifiants, la page se recharge, et le formulaire revient. La cause la plus fréquente est un problème de cookies : adresse incohérente entre siteurl et home, écran de connexion mis en cache, ou extension de sécurité qui a déplacé l'URL d'administration. Videz les cookies du domaine, coupez le cache, puis les extensions. Voir retrouver l'adresse du back-office et notre page back-office perdu.

Mot de passe perdu et courriel de réinitialisation qui n'arrive jamais

WordPress annonce l'envoi du lien, mais rien n'arrive. C'est le comportement attendu quand le serveur n'a pas de service de messagerie : WordPress utilise la fonction mail() de PHP, et l'expéditeur par défaut wordpress@votredomaine est souvent rejeté ou classé en indésirable. Passez par phpMyAdmin, ou par wp user update en SSH, puis réglez l'envoi en SMTP. Voir récupérer un mot de passe WordPress.

Erreur 403 : « Désolé, vous n'avez pas l'autorisation d'accéder à cette page »

Deux erreurs très différentes portent le même code. Celle du serveur vient des permissions, d'une règle .htaccess, d'un module comme mod_security ou d'une IP bloquée. Celle de WordPress, avec la phrase ci-dessus, vient des rôles : capacités perdues, préfixe de tables modifié après une migration, extension de sécurité trop stricte. Distinguez les deux avant de corriger. Voir l'erreur 403 sur WordPress, les 403 dus à mod_security et notre page correction d'erreur 403.

« Cookies are blocked due to unexpected output »

Ce message à la connexion signifie qu'un fichier a envoyé du texte avant que WordPress ne pose son cookie de test. Deux causes documentées : une extension ou un functions.php qui affiche un avertissement PHP, et un fichier enregistré en UTF-8 avec BOM, typiquement wp-config.php. Cherchez la mention « headers already sent » dans le journal : elle nomme le fichier et la ligne. Voir le guide d'affichage des erreurs.

Le site s'affiche mal

La mise en page est perdue, les images manquent ou l'éditeur refuse de s'ouvrir. Ces pannes viennent des ressources statiques : chemins, cache, permissions, protocole.

Le CSS ne se charge plus : site ou back-office déformé

La page apparaît en texte brut empilé, sans couleurs ni colonnes. Sur le site public, c'est en général un cache ou un minificateur qui a produit un fichier vide, ou une adresse restée sur l'ancien domaine. Dans l'administration, la cause classique est une extension de concaténation ou une erreur JavaScript. Videz les caches, puis coupez l'optimisation. Voir back-office CSS cassé et CSS non chargé dans l'administration.

Contenu mixte : le cadenas disparaît après le passage en HTTPS

Le site est en HTTPS mais des ressources sont encore appelées en HTTP. Les navigateurs basculent automatiquement en HTTPS les images, l'audio et la vidéo appelés par leur attribut src, et bloquent tout le reste : scripts, feuilles de style, polices, requêtes réseau. Un site peut donc perdre sa mise en page sans erreur visible. Corrigez les adresses en base par un remplacement contrôlé. Voir migrer de HTTP à HTTPS, forcer HTTPS et HSTS et ERR_SSL_PROTOCOL_ERROR.

Images cassées ou médiathèque vide

Les vignettes sont remplacées par un cadre vide, ou la médiathèque n'affiche rien alors que les fichiers sont sur le serveur. Trois causes couvrent presque tous les cas : des permissions incorrectes sur wp-content/uploads après une restauration, un chemin d'upload resté sur l'ancien domaine dans wp_options, une règle anti-hotlink du .htaccess. Ouvrez une image par son URL directe pour trancher. Voir les permissions de fichiers et le fichier .htaccess.

Elementor ou l'éditeur de blocs refuse de s'ouvrir

Le constructeur tourne indéfiniment, ou le panneau de widgets reste vide. Elementor demande au minimum 256 Mo de mémoire WordPress, 512 Mo recommandés : sous ce seuil, l'éditeur s'arrête sans message. Autres causes : un max_input_vars trop bas pour une page longue, une règle de pare-feu qui bloque l'enregistrement, un conflit d'extension, un cache qui sert d'anciens scripts. Voir vider le cache WordPress et relever la limite de mémoire.

Lenteur, courriels, tâches planifiées et boutique

Ces pannes ne bloquent pas le site, elles l'abîment : un visiteur qui attend, une commande qui ne se confirme pas, une sauvegarde qui ne part plus. Elles passent inaperçues des semaines.

Le site est devenu lent

Cherchez d'abord ce qui a changé : une extension ajoutée, un import massif, un thème mis à jour, une base gonflée par les révisions et les tables d'anciennes extensions. WordPress recommande dans cet ordre la mise en cache des pages, un cache d'objet persistant, un PHP récent et l'optimisation des images. Mesurez avant et après chaque changement. Notre page site WordPress lent détaille le diagnostic, et un audit complet permet de trancher.

WordPress n'envoie plus de courriels

Formulaires sans réponse, commandes non confirmées, réinitialisations perdues : WordPress s'appuie sur la fonction mail() de PHP, sans authentification. Les serveurs destinataires rejettent ou classent en indésirable les messages qui échouent aux contrôles SPF et DKIM. La correction durable : envoyer par SMTP authentifié, avec un expéditeur de votre domaine, puis publier des enregistrements SPF, DKIM et DMARC. Voir DMARC, SPF et DKIM et éviter le classement en spam.

Les publications planifiées et les tâches automatiques ne partent plus

WP-Cron n'est pas une tâche système : il vérifie la liste des tâches à chaque chargement de page. La documentation le dit clairement, une tâche prévue à 14 heures ne partira qu'au premier chargement suivant. Sur un site peu visité, publications planifiées, sauvegardes et mises à jour automatiques prennent du retard. La solution : désactiver WP-Cron dans wp-config.php et appeler wp-cron.php depuis une vraie tâche planifiée du serveur. Voir remplacer le cron natif.

Une mise à jour a échoué ou reste bloquée

Une coupure réseau ou des permissions insuffisantes interrompent la mise à jour : le site reste en maintenance, ou l'écran affiche « Une autre mise à jour est actuellement en cours ». Supprimez le fichier .maintenance, puis la ligne core_updater.lock de wp_options si elle existe, et relancez. Si l'échec persiste, faites la mise à jour à la main depuis l'archive officielle. Voir problème de mise à jour, mettre à jour WordPress et mettre à jour les extensions.

WooCommerce : panier, commande ou paiement bloqués

Le panier se vide, la commande reste « en attente de paiement », ou la page de règlement tourne dans le vide. Causes propres à une boutique : des pages mises en cache alors qu'elles ne doivent pas l'être, une passerelle dont les clés ou l'URL de retour ont changé, une tâche planifiée arrêtée, des ressources insuffisantes. WooCommerce demande PHP 8.3 ou supérieur et 256 Mo de mémoire WordPress. Commencez par l'écran État. Voir notre guide WooCommerce.

Quand ce n'est pas une panne mais un piratage

Certains symptômes ne se réparent pas, ils se nettoient : un site qui redirige les visiteurs venus de Google, des pages que vous n'avez jamais écrites indexées à votre nom, un administrateur inconnu, un compte suspendu pour envoi de spam. Réinstaller le thème ne changera rien tant que la porte dérobée est en place.

Le rapport « State of WordPress Security in 2026 » de Patchstack, mis à jour le 25 février 2026, recense pour 2025 11 334 nouvelles vulnérabilités dans l'écosystème WordPress, dont 91 % dans des extensions et 9 % dans des thèmes, contre 6 dans le cœur : la porte d'entrée est presque toujours une extension oubliée. Si vous reconnaissez ces symptômes, suivez que faire dans la première heure puis le guide de nettoyage complet. Cas particuliers : les redirections vers un site de spam et l'administrateur inconnu.

Quand appeler un professionnel

Le bricolage a une limite économique. Passez la main quand le site est hors ligne et que le chiffre d'affaires s'arrête, quand vous n'avez ni sauvegarde ni accès FTP, quand la même panne revient après chaque correction, ou quand des données personnelles ont pu fuiter. Deux heures d'essais coûtent souvent plus cher que l'intervention, et une manipulation de trop rend parfois la récupération impossible.

Notre équipe répare et sécurise des sites WordPress depuis 2016. Le diagnostic est gratuit et rendu sous 12 heures : nous vous disons ce qui casse le site et si nous pouvons le corriger. La réparation est ensuite à prix fixe, 350 euros annoncés avant l'intervention et remboursés si elle échoue ; l'Assurance et maintenance à 50 euros par mois couvre mises à jour, surveillance et corrections. Voir réparation de site WordPress, dépannage en urgence et mon site WordPress bug. Pour tenter la réparation vous-même, notre guide réparer un site WordPress cassé reprend les manipulations une par une ; sinon, écrivez-nous par le formulaire de contact.

Sources

• WordPress.org, « Common WordPress Errors » : developer.wordpress.org
• WordPress.org, « FAQ Troubleshooting » (mis à jour le 3 juillet 2026) : wordpress.org
• WordPress.org, « Debugging in WordPress » : developer.wordpress.org
• WordPress.org, « Editing wp-config.php » : developer.wordpress.org
• WordPress.org, « Fatal Error Recovery Mode in 5.2 » (16 avril 2019) : make.wordpress.org
• WordPress.org, « Requirements » : wordpress.org
• WordPress.org, « WordPress Optimization » : developer.wordpress.org
• WordPress.org, « WP-Cron » : developer.wordpress.org
• WP-CLI, index des commandes et wp core update (verrou core_updater.lock) : index, core update
• IETF, RFC 9110 « HTTP Semantics » : rfc-editor.org
• MDN Web Docs, « 429 Too Many Requests » : developer.mozilla.org
• MDN Web Docs, « Mixed content » : developer.mozilla.org
• PHP, « Description of core php.ini directives » : php.net
• Elementor, « System Requirements » : elementor.com
• WooCommerce, « Server Requirements » : woocommerce.com
• Patchstack, « State of WordPress Security in 2026 » (données au 25 février 2026) : patchstack.com