Un site WordPress inaccessible peut bloquer les demandes de devis, les ventes et l’accès à votre administration. Le bon réflexe n’est pas de modifier des fichiers au hasard : il faut d’abord qualifier l’erreur, préserver les éléments utiles au diagnostic et intervenir dans un ordre qui limite les risques. Cette méthode de maintenance site WordPress permet d’isoler rapidement un problème d’hébergement, de DNS, de base de données, d’extension, de thème ou de sécurité.
Commencez par identifier la nature exacte de la panne
Copiez le message affiché par le navigateur et notez l’heure de début présumée de l’incident. Testez ensuite l’URL depuis une connexion mobile, une fenêtre de navigation privée et un outil de contrôle HTTP. Une panne visible seulement depuis votre poste peut provenir d’un cache local, d’un fichier hosts, d’une adresse IP bloquée ou d’une extension de navigateur. À l’inverse, une erreur identique depuis plusieurs réseaux confirme que le problème se situe côté site, domaine ou hébergement.
-
Erreur 500, 502, 503 ou 504 : erreur PHP, saturation des ressources, délai dépassé ou incident chez l’hébergeur.
-
Erreur 404 sur toutes les pages sauf l’accueil : règles de réécriture ou permaliens à régénérer.
-
« Erreur lors de l’établissement d’une connexion à la base de données » : identifiants, serveur MySQL/MariaDB, table corrompue ou quota atteint.
-
« DNS_PROBE_FINISHED_NXDOMAIN » ou domaine introuvable : zone DNS, expiration du domaine ou serveurs de noms mal configurés.
-
Écran blanc, erreur critique WordPress ou boucle de redirection : le plus souvent extension, thème, cache, PHP ou configuration HTTPS.
Conservez une capture d’écran, le code HTTP, l’URL concernée et les dernières actions réalisées : mise à jour, changement de version PHP, migration, ajout d’extension ou modification DNS. Ces informations réduisent nettement le temps de diagnostic.
Vérifiez l’hébergement, le domaine et les ressources avant WordPress
Connectez-vous au panneau d’hébergement. Contrôlez les éventuels avis d’incident, la date d’expiration du domaine, l’état du certificat SSL, l’espace disque disponible et les limites de ressources. Un disque plein peut empêcher WordPress d’écrire dans wp-content/uploads, de créer des fichiers de cache ou de lancer des tâches PHP.
Dans le gestionnaire de fichiers ou par SFTP, vérifiez que les fichiers WordPress sont présents et que le répertoire racine correspond bien au domaine. Consultez également les journaux d’erreurs PHP et du serveur disponibles chez l’hébergeur. Une ligne indiquant une mémoire PHP épuisée, un fichier manquant ou une erreur fatale donne une piste plus fiable qu’un simple message affiché au visiteur.
Contrôlez la résolution DNS sans effectuer de changement précipité
Comparez l’adresse IP renvoyée pour votre domaine avec celle attendue par votre hébergeur. Vérifiez les enregistrements A ou AAAA pour le domaine, ainsi que le CNAME éventuel de www. Si un changement DNS vient d’être fait, évitez de multiplier les modifications : elles peuvent prolonger la confusion entre les différentes configurations. Une erreur de DNS n’est pas réparée par une réinstallation de WordPress.
Préservez une sauvegarde et activez des traces exploitables
Avant de désactiver des extensions ou de restaurer une sauvegarde, téléchargez si possible une copie des fichiers et exportez la base de données. Même un site en erreur peut contenir des contenus ou données récentes absents de la dernière sauvegarde. Ne restaurez pas aveuglément une ancienne copie sans vérifier sa date et son périmètre : vous pourriez effacer des commandes, formulaires ou publications récentes.
Pour afficher les erreurs dans un journal sans les montrer aux visiteurs, ajoutez temporairement dans wp-config.php, avant la ligne indiquant d’arrêter les modifications, les constantes suivantes : WP_DEBUG à true, WP_DEBUG_LOG à true et WP_DEBUG_DISPLAY à false. WordPress écrit alors les erreurs dans wp-content/debug.log lorsqu’il en a les droits. Désactivez ensuite le débogage après intervention : un journal laissé accessible ou trop volumineux n’est pas souhaitable en production.
Isolez une extension ou un thème défaillant
Les extensions et thèmes sont des causes fréquentes après une mise à jour. Si l’administration reste accessible, désactivez d’abord l’extension mise à jour ou installée juste avant la panne. Testez le site dans une fenêtre privée, car un cache de navigateur ou de plugin peut masquer le résultat.
Si wp-admin est inaccessible, renommez par SFTP le dossier wp-content/plugins en plugins-desactive. WordPress ne retrouvera plus les extensions et les désactivera. Si le site revient, remettez le nom plugins, puis désactivez ou renommez les dossiers d’extensions un par un pour identifier le responsable. Ne supprimez pas l’extension avant d’avoir vérifié si elle stocke des données nécessaires dans la base.
Pour tester le thème, renommez uniquement le dossier du thème actif dans wp-content/themes. WordPress basculera vers un thème par défaut installé et compatible. Si aucun thème par défaut n’est disponible, installez-en un via SFTP avant le test. Une erreur liée au thème peut aussi venir d’un thème enfant, d’un fichier functions.php modifié ou d’une incompatibilité avec la version de PHP.
Traitez les erreurs de base de données avec méthode
Vérifiez dans wp-config.php les valeurs DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Elles doivent correspondre exactement aux identifiants configurés chez l’hébergeur. Ne copiez jamais ces informations dans un ticket public ou un échange non sécurisé. Dans phpMyAdmin ou l’outil de base de données de l’hébergeur, vérifiez que la base existe, que l’utilisateur dispose des privilèges nécessaires et que le serveur répond.
La constante de réparation de WordPress peut aider en cas de tables signalées comme corrompues, mais elle doit rester temporaire. Ajoutez WP_ALLOW_REPAIR à true dans wp-config.php, ouvrez la page de réparation prévue par WordPress, puis retirez immédiatement cette constante. Cette page n’exige pas de connexion administrateur : la laisser active constitue un risque. Pour une base volumineuse, des erreurs répétées ou une suspicion de disque défaillant, sollicitez l’hébergeur avant toute réparation.
Réparez les redirections, le cache et les permaliens
Une boucle « trop de redirections » apparaît souvent lorsqu’une extension force HTTPS alors que le proxy ou le certificat est mal déclaré, ou lorsque les URL WordPress et site ne correspondent pas. Contrôlez les valeurs de l’adresse WordPress et de l’adresse du site dans Réglages, puis les éventuelles constantes WP_HOME et WP_SITEURL dans wp-config.php. Elles doivent utiliser le même protocole et le bon nom de domaine.
Videz successivement le cache du navigateur, le cache de l’extension, le cache serveur et le CDN si vous en utilisez un. Pour des 404 généralisées, allez dans Réglages puis Permaliens et enregistrez sans changer la structure afin de régénérer les règles. Si l’administration est inaccessible, renommez temporairement le fichier .htaccess : WordPress peut fonctionner avec ses permaliens désactivés, ce qui confirme ou écarte cette piste. Recréez ensuite un fichier .htaccess standard depuis les permaliens, plutôt que de conserver un fichier inconnu.
Réagissez différemment en cas de piratage ou de fichier suspect
Des redirections vers un autre site, des comptes administrateurs inconnus, des fichiers PHP inattendus dans uploads ou des alertes de l’hébergeur justifient une réponse de sécurité. Mettez le site en maintenance si nécessaire, changez les mots de passe WordPress, SFTP, hébergement, base de données et comptes associés depuis un poste sain. Révoquez les accès inutiles et examinez les comptes administrateurs.
Ne vous contentez pas de supprimer le fichier qui semble suspect : une compromission peut inclure une porte dérobée, une tâche planifiée, une extension modifiée ou un compte ajouté. Comparez les fichiers du cœur WordPress avec une version officielle, mettez à jour le cœur, les extensions et les thèmes après nettoyage, puis contrôlez les journaux. Une maintenance site WordPress régulière, avec sauvegardes testées, mises à jour contrôlées, surveillance des erreurs et accès limités, réduit fortement la durée d’une future indisponibilité.
Quand confier le dépannage WordPress à un professionnel
Une intervention technique est recommandée si la panne concerne les paiements, un site e-commerce, la base de données, un piratage, une migration incomplète ou des erreurs serveur persistantes. Préparez l’accès au panneau d’hébergement, au registrar du domaine, à WordPress et à la dernière sauvegarde connue. Chez ProxiDesign, le diagnostic peut alors cibler les logs, la configuration et les changements récents sans multiplier les manipulations risquées sur le site en production.
Combien de temps faut-il pour rétablir un site WordPress inaccessible ?
La durée dépend de la cause et de la qualité des accès disponibles. Un conflit d’extension ou un cache bloqué peut être isolé rapidement. Une compromission, une restauration de sauvegarde ou une panne de base de données demande davantage de contrôles pour éviter une remise en ligne incomplète ou non sécurisée.
Puis-je désactiver toutes les extensions sans perdre mon contenu ?
La désactivation des extensions ne supprime normalement ni les articles ni les pages. En revanche, certaines fonctionnalités deviennent indisponibles temporairement, comme les formulaires, le cache ou les paiements. Évitez de supprimer une extension avant d’avoir identifié son rôle et sauvegardé le site.
Pourquoi mon site fonctionne-t-il en administration mais pas pour les visiteurs ?
Cette situation peut être liée au cache, à un CDN, à une règle de sécurité, au thème actif côté public ou à une extension qui ne s’exécute que sur le front-end. Testez en navigation privée, videz les caches concernés et consultez les erreurs PHP pendant l’ouverture d’une page publique.
Faut-il mettre WordPress à jour pendant une panne ?
Pas systématiquement. Si la panne a commencé après une mise à jour, identifiez d’abord le composant en cause. En cas de faille connue ou de piratage, les mises à jour font partie de la correction, mais elles doivent intervenir après une sauvegarde et avec un contrôle de compatibilité lorsque cela est possible.
Quelle sauvegarde faut-il conserver pour un dépannage WordPress ?
Une sauvegarde utile comprend les fichiers du site et la base de données, avec une date identifiable. Elle doit idéalement être stockée hors de l’hébergement et testée sur un environnement de préproduction. Une simple copie des fichiers sans export de la base ne permet pas de restaurer correctement WordPress.