Un site WordPress en panne peut prendre plusieurs formes : erreur 500, écran blanc, page « erreur critique », administration inaccessible, boutique WooCommerce bloquée ou redirections suspectes. La priorité n’est pas de modifier des fichiers au hasard, mais de qualifier la panne, de préserver les données puis d’isoler la cause. Ce diagnostic technique permet de rétablir le service sans aggraver une mise à jour ratée, un conflit d’extension ou un incident d’hébergement.
Si la panne exige une intervention technique, notre service de dépannage WordPress permet d’en organiser le diagnostic. Pour le message précis « Une erreur critique est survenue », consultez aussi le guide dédié à l’erreur critique WordPress.
Qualifier la panne avant toute intervention
Commencez par tester le site depuis une fenêtre de navigation privée et, si possible, depuis un autre réseau. Un cache local, une session expirée ou une restriction d’adresse IP peut donner l’impression que le site est indisponible.
- Le site et /wp-admin sont inaccessibles : vérifiez d’abord le domaine, le certificat SSL, l’état de l’hébergement et les erreurs serveur.
- Le site public fonctionne, mais /wp-admin échoue : suspectez une extension de sécurité, un conflit de plugin, les cookies ou une règle de pare-feu.
- Une seule page est en erreur : contrôlez son modèle, son shortcode, son constructeur de page et les données affichées.
- La panne est apparue après une action précise : notez l’heure et l’action réalisée : mise à jour, ajout d’extension, changement PHP, import, modification DNS ou renouvellement de certificat.
- Des redirections ou contenus inconnus apparaissent : traitez le cas comme un incident de sécurité et évitez de restaurer ou mettre à jour sans analyse.
Relevez le message exact, l’URL concernée et une capture d’écran. Une erreur « 502 Bad Gateway » ne se traite pas comme une erreur WordPress PHP ; elle indique généralement que le serveur web ne reçoit pas une réponse valide du processus PHP ou d’un service en amont.
Sécuriser l’intervention et conserver un point de retour
Avant de corriger, créez une sauvegarde complète des fichiers et de la base de données, même si le site est déjà défaillant. Depuis le panneau d’hébergement, téléchargez l’archive des fichiers du site et exportez la base MySQL/MariaDB via phpMyAdmin ou l’outil fourni. Vérifiez que l’archive contient bien wp-content/uploads et que l’export SQL n’est pas vide.
Évitez les actions irréversibles : ne supprimez pas une extension, ne réinstallez pas WordPress et ne videz pas la base de données pour « tester ». Renommer temporairement un dossier permet au contraire un retour arrière immédiat. Si une sauvegarde antérieure doit être restaurée, faites-le idéalement sur un environnement de préproduction ou dans un dossier de test : elle peut contenir des commandes, formulaires ou contenus plus anciens.
Lire les bons signaux : serveur, WordPress et base de données
Consulter les journaux d’erreurs
Dans le panneau d’hébergement, recherchez les logs PHP et les logs d’erreurs du domaine. Une ligne contenant Allowed memory size exhausted oriente vers une limite mémoire ou une boucle de traitement. Une erreur PHP Fatal error mentionne souvent le fichier et l’extension impliqués. Une erreur de type Call to undefined function après un changement de version PHP révèle fréquemment une incompatibilité de thème ou de plugin.
Pour produire un journal WordPress sans afficher d’informations techniques aux visiteurs, ajoutez temporairement ces constantes dans wp-config.php, avant la ligne indiquant d’arrêter les modifications :
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/chemin/prive/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Adaptez le chemin à un répertoire privé hors de la racine web, accessible en écriture à PHP. Ne dupliquez pas des constantes déjà définies. Consultez le journal privé et limitez sa conservation. Désactivez ce mode après le diagnostic : un fichier de log peut contenir des chemins internes ou des messages utiles à un attaquant.
Vérifier l’espace disque et la base
Un disque saturé empêche WordPress d’écrire dans les caches, les sessions, les mises à jour et parfois les téléchargements. Contrôlez aussi la taille des sauvegardes locales, des fichiers de log et des dossiers de cache. Face au message « Error establishing a database connection », vérifiez d’abord que le service de base de données fonctionne chez l’hébergeur, puis comparez les constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST de wp-config.php avec les identifiants réellement configurés. Ne modifiez pas ces valeurs sans validation.
Isoler un conflit d’extension ou de thème sans supprimer de données
Les extensions sont une cause fréquente de panne après une mise à jour, mais il faut les tester méthodiquement. Si l’administration est accessible, désactivez l’extension modifiée en dernier, videz les caches et retestez. Si elle ne l’est pas, utilisez SFTP ou le gestionnaire de fichiers pour renommer le dossier concerné dans /wp-content/plugins/, par exemple woocommerce en woocommerce-off. WordPress considérera l’extension comme inactive.
Si la cause reste inconnue, réalisez les tests d’isolement sur une préproduction. Une désactivation globale peut interrompre les paiements, la sécurité et des fonctions métier. Si le dossier plugins doit être renommé temporairement en plugins-off, conservez ses fichiers actuels, restaurez son nom d’origine avant la réactivation contrôlée des extensions et testez après chaque étape. Ne remplacez pas ces fichiers par une ancienne sauvegarde sans vérifier les versions et leur compatibilité.
Pour tester le thème, activez un thème WordPress standard installé, tel qu’un thème Twenty récent. Si l’accès à l’administration est impossible, renommez le dossier du thème actif dans /wp-content/themes/ afin que WordPress bascule vers un thème standard disponible. Un thème enfant peut aussi tomber en panne si son thème parent a été supprimé ou mis à jour de façon incomplète.
Corriger les erreurs WordPress les plus courantes
Erreur 500 ou erreur critique
Une erreur 500 est un statut serveur, pas un diagnostic. Consultez le log à l’heure de l’incident. Les causes courantes sont une extension incompatible, une directive invalide dans .htaccess, une version PHP non compatible ou une mémoire insuffisante. Sur Apache, faites une copie de .htaccess et recherchez la directive signalée par les journaux avec l’hébergeur. Testez une correction ciblée sur une préproduction : retirer le fichier entier peut désactiver des règles de sécurité ou de redirection utiles. Conservez les règles nécessaires ; sur Nginx, cette configuration se traite au niveau du serveur.
Page blanche ou affichage incomplet
Une page blanche correspond souvent à une erreur fatale masquée. Activez le journal de debug, puis ciblez le fichier cité dans le log. Ne corrigez pas le cœur de WordPress : mettez à jour, remplacez ou désactivez l’extension ou le thème responsable. Vérifiez également la compatibilité de la version PHP choisie avec WordPress, le thème et les extensions. Un changement de PHP doit être testé sur une copie du site lorsqu’elle est disponible.
Erreur 404 sur les pages internes
Si la page d’accueil fonctionne mais que les articles et pages retournent une 404, enregistrez les permaliens et vérifiez que le fichier .htaccess est accessible en écriture lorsque le serveur Apache l’utilise. Sur Nginx, les règles de réécriture sont généralement définies dans la configuration serveur : régénérer .htaccess ne résoudra pas une règle Nginx absente.
Cas urgent : boutique, formulaire ou suspicion de piratage
Sur WooCommerce, testez le tunnel avec un produit simple, sans créer de commande réelle si possible. Vérifiez séparément la fiche produit, le panier, la validation de commande, les e-mails transactionnels et le moyen de paiement. Un cache de page appliqué au panier ou à la commande peut provoquer des comportements incohérents ; ces URL doivent en général être exclues du cache.
En cas de redirections vers un domaine inconnu, de comptes administrateurs non reconnus, de fichiers PHP dans /uploads ou d’alertes de sécurité, limitez l’accès public si nécessaire, effectuez une sauvegarde de preuve et changez les mots de passe de l’hébergement, SFTP, base de données et comptes administrateurs depuis un appareil fiable. Contrôlez les utilisateurs WordPress, les tâches planifiées, les extensions et les fichiers modifiés. Une simple restauration peut remettre en ligne une version vulnérable : il faut aussi identifier le point d’entrée, supprimer les fichiers malveillants et appliquer les mises à jour nécessaires.
Quand confier le dépannage à un spécialiste WordPress
Une intervention technique est recommandée lorsque la panne concerne la base de données, une erreur serveur persistante, une migration, WooCommerce, un piratage ou une perte d’accès à l’hébergement. Pour accélérer le diagnostic, transmettez l’URL, l’heure de début de panne, les dernières modifications, les messages d’erreur, la version PHP, les accès temporaires nécessaires et l’existence d’une sauvegarde. ProxiDesign peut alors analyser les logs, isoler la cause, valider la correction et contrôler le fonctionnement des pages, formulaires et parcours essentiels après remise en ligne.
Que faire si je n’ai plus accès à wp-admin mais que le site reste visible ?
Testez d’abord en navigation privée, puis désactivez temporairement l’extension modifiée en dernier via SFTP ou le gestionnaire de fichiers. Contrôlez aussi les règles de sécurité, les cookies du navigateur et les logs PHP. Évitez de réinitialiser des mots de passe ou de modifier la base de données sans avoir identifié l’erreur.
Peut-on désactiver une extension WordPress sans accéder à l’administration ?
Oui. Renommez le dossier de l’extension dans /wp-content/plugins/ avec SFTP ou depuis le panneau d’hébergement. WordPress la détectera comme inactive. Renommez le dossier à son nom initial après le test, puis réactivez l’extension uniquement si le diagnostic le justifie.
Pourquoi mon site WordPress affiche-t-il une erreur après une mise à jour PHP ?
Le thème, une extension ou du code personnalisé peut utiliser une fonction supprimée ou un comportement devenu incompatible avec la nouvelle version de PHP. Consultez le journal d’erreurs pour identifier le fichier concerné, restaurez temporairement une version PHP compatible si l’hébergeur le permet, puis mettez à jour ou remplacez le composant en cause.
Faut-il vider le cache quand un site WordPress est en panne ?
Oui, mais après avoir relevé le message d’erreur et confirmé la panne en navigation privée. Purgez le cache de l’extension, du serveur et du CDN si vous en utilisez un. Le cache ne corrigera pas une erreur fatale PHP, une base indisponible ou un problème DNS, mais il peut masquer une correction déjà appliquée.
Quelles informations fournir pour un dépannage WordPress rapide ?
Indiquez l’URL affectée, l’heure approximative du début de panne, les dernières opérations réalisées, les captures ou messages d’erreur, l’hébergeur, la version PHP et la disponibilité d’une sauvegarde. Des accès temporaires à l’hébergement et à WordPress peuvent être nécessaires selon la cause.
Diagnostic technique ou gestion de l’urgence ?
Ce guide sert à identifier la cause. Pour prioriser les actions, préserver les données et organiser la prise en charge avant le diagnostic, consultez les premiers réflexes en cas de panne urgente.