Lorsqu'un site WordPress n'est soudainement plus accessible, WordPress lui-même n'est pas nécessairement la cause. Entre la saisie d'un domaine dans le navigateur et la page WordPress affichée, il existe plusieurs niveaux techniques : le domaine et le DNS, le réseau, le serveur web, SSL/TLS, PHP, la base de données et enfin WordPress avec ses extensions et ses thèmes.
C'est pourquoi un diagnostic systématique est beaucoup plus judicieux qu'une désactivation aléatoire de plugins ou une modification de paramètres.
En bref : Vérifiez d'abord si vous êtes le seul concerné ou si d'autres visiteurs le sont également. Faites ensuite attention au message d'erreur ou de navigateur exact. Les erreurs DNS, les problèmes SSL, HTTP 500, HTTP 404, les erreurs de base de données et les erreurs WordPress critiques ont des causes différentes et nécessitent des solutions différentes.
„ Site Web inaccessible “ peut signifier beaucoup de choses #
L'affirmation „ Mon site Web WordPress ne fonctionne pas “ ne suffit pas encore pour un diagnostic technique.
Dans le navigateur, des symptômes très différents peuvent par exemple apparaître :
- Le domaine est introuvable
- Délai de connexion dépassé
- La connexion a été refusée
- Avertissement SSL ou de certificat
- Trop de redirections
- Erreur 500
- Erreur 404
- page blanche
- erreur critique WordPress
- Erreur de connexion à la base de données
- Mode maintenance
- seules certaines pages ne fonctionnent pas
- L'interface utilisateur fonctionne, mais la zone d'administration ne fonctionne pas.
Ces différences sont cruciales pour la recherche d'erreurs.
1. Noter le message d'erreur exact #
Avant de modifier quoi que ce soit sur WordPress, notez le message exact du navigateur ou du site Web.
Une capture d'écran peut également être utile.
Des formulations telles que „ ne fonctionne pas “ ou „ est hors ligne “ contiennent peu d'informations techniques. Un message concret tel que :
500 Erreur interne du serveur
en revanche, limite clairement les causes possibles.
Conseil pratique : Copiez un message d'erreur le plus précisément possible. Même un code d'état HTTP, un nom de domaine ou quelques mots d'un message technique peuvent être déterminants pour le diagnostic.
2. Vérifier si l'ensemble du site web est réellement concerné #
Ne te contente pas d'ouvrir la page d'accueil.
Testez par exemple :
une sous-page bien connue :
et l'espace d'administration WordPress :
Cela fournit déjà des indications importantes.
Exemples :
- Tout est injoignable : Un domaine, le DNS, un serveur, le SSL ou une erreur de site Web fondamentale entrent en ligne de compte.
- La page d'accueil fonctionne, les sous-pages affichent une erreur 404 : Les permaliens ou les règles de réécriture sont suspects.
- L'interface fonctionne, mais pas la connexion : Le problème se situe probablement plus spécifiquement au niveau de la connexion ou de la zone d'administration.
- Un seul côté est défectueux : Un problème avec exactement ce contenu, ce modèle, ce code court ou ce plugin est plus probable.
3. Vérifier si le problème concerne uniquement votre appareil #
Si un site web est inaccessible sur votre ordinateur, cela ne signifie pas automatiquement qu'il est en panne pour tous les visiteurs.
Testez le site web si possible :
- dans un autre navigateur
- dans une fenêtre de navigation privée ou incognito
- sur un autre appareil
- via une autre connexion Internet
Un smartphone utilisant le réseau mobile constitue par exemple une vérification judicieuse si ton ordinateur est connecté en Wi-Fi ou via une autre connexion Internet.
4. Exclure le cache du navigateur comme cause locale #
Les navigateurs enregistrent certains contenus localement. Dans certaines situations, un état obsolète ou erroné peut donc s'afficher.
Une fenêtre de navigation privée ou un autre navigateur peut aider à exclure les données de navigation locales comme cause potentielle.
Cela ne doit cependant pas être confondu avec une résolution générale des problèmes.
Important : Un cache de navigateur ne provoque pas de panne DNS et ne répare pas d'erreur fatale PHP. Vider le cache n'est donc pas une première étape universelle pour chaque problème WordPress.
5. Vérifier le domaine comme cause #
Avant que WordPress ne puisse être chargé, le domaine utilisé doit fonctionner.
En cas de problèmes de domaine, il convient entre autres de vérifier :
- Le domaine est-il toujours enregistré ?
- Est-elle expirée ?
- pointe-t-elle vers les serveurs de noms désignés ?
- les enregistrements DNS nécessaires sont-ils présents ?
- Les paramètres DNS ont-ils été modifiés récemment ?
Si un domaine ne peut pas être résolu correctement, la requête risque de ne pas atteindre du tout le serveur Web. Dans ce cas, WordPress lui-même peut être parfaitement intact.
6. Comprendre le DNS : comment le domaine trouve-t-il le serveur ? #
Le DNS traduit un nom de domaine en informations techniques nécessaires pour atteindre le service correspondant.
Pour un site Web, des éléments tels que jouent souvent A et AAAA ou selon la configuration également CNAME un rôle.
Si ces enregistrements sont mal configurés, le domaine peut par exemple :
- pointer vers un mauvais serveur
- pointer vers une adresse IP inutilisée
- utiliser des destinations différentes pour IPv4 et IPv6
- ne fournir aucune adresse correspondante
WordPress ne peut pas résoudre lui-même une telle erreur DNS, car la requête n'arrive éventuellement même pas encore jusqu'à WordPress.
7. Les paramètres DNS ont-ils été modifiés récemment ? #
Si le site Web n'est plus accessible immédiatement après une modification des serveurs de noms ou des enregistrements DNS, cette modification doit d'abord être vérifiée.
Les informations DNS sont mises en cache par différents systèmes. C'est pourquoi les modifications ne sont pas nécessairement visibles pour tous les utilisateurs exactement au même moment.
Pendant une transition, il peut arriver temporairement que différents utilisateurs accèdent encore à des systèmes cibles différents.
Conseil pratique : Si un site web tombe en panne après une modification DNS, ne modifiez pas WordPress, les extensions et PHP en même temps. Vérifiez d'abord si le domaine pointe bien vers l'hébergement prévu.
8. Tester www et le domaine sans www séparément #
Un site Web peut par exemple être consulté sous les variantes suivantes :
et
Les deux variantes doivent être techniquement configurées correctement pour pouvoir être utilisées.
Si une variante fonctionne et pas l'autre, cela peut indiquer une configuration erronée du DNS, du SSL ou de la redirection.
9. Détecter les problèmes SSL et HTTPS #
Si le domaine est accessible, mais que le navigateur affiche un avertissement de sécurité ou de certificat, le problème vient probablement de SSL/TLS.
Les causes possibles sont par exemple :
- aucun certificat valide pour le domaine
- Le certificat a expiré
- Le certificat ne couvre pas une variante de domaine utilisée
- Le domaine pointe vers le mauvais serveur
- HTTPS a été mal configuré
- Les redirections entre HTTP et HTTPS sont incorrectes
Une alerte SSL ne doit pas être „ résolue “ en demandant aux visiteurs d'ignorer durablement l'avertissement du navigateur.
10. Traiter HTTP et HTTPS séparément #
Si un site web ne fonctionne plus après une modification SSL, une comparaison entre HTTP et HTTPS peut fournir des indices.
Par exemple :
http://deine-domain.ch/
et
Les sites web modernes devraient fonctionner régulièrement via HTTPS. La comparaison sert ici uniquement de diagnostic technique.
Si HTTP fonctionne mais que HTTPS génère une erreur de certificat ou de connexion, le soupçon pèse davantage sur la configuration SSL/HTTPS que sur WordPress lui-même.
11. Trop de redirections #
Les navigateurs peuvent interrompre le chargement lorsqu'un site Web se trouve dans une boucle de redirection.
Les constellations typiques concernent par exemple :
- HTTP → HTTPS
- HTTPS → HTTP
- www → sans www
- sans www → avec www
- Paramètres d'URL WordPress
- Extensions de redirection
- Règles du serveur
- Configurations de proxy ou de CDN
Lorsque deux systèmes imposent des redirections contradictoires, une boucle infinie peut se produire.
Par conséquent, en cas d'erreur de trop nombreuses redirections, vous devez vérifier quelles composantes gèrent les redirections.
12. Tenir compte du code d'état HTTP #
Lorsque le serveur web répond, il renvoie un code d'état HTTP.
Certains codes sont particulièrement pertinents pour le débogage de WordPress :
- 200: La demande a été traitée avec succès dans l'ensemble.
- 301/302: Redirection
- 403: Accès refusé
- 404: Ressource demandée introuvable
- 500: Erreur interne du serveur
- 502: réponse erronée d'un service amont ou aval
- 503: Service momentanément indisponible
- 504: Délai d'attente dépassé entre les systèmes concernés
Le code d'état n'est pas un diagnostic complet, mais il restreint considérablement la zone d'erreur.
13. L'erreur 500 n'est pas la même chose que „ site Web inaccessible “ #
Lors d'un 500 Erreur interne du serveur le serveur a bien reçu la requête, mais n'a pas pu la traiter avec succès en raison d'une erreur interne.
Sous WordPress, il y a entre autres des erreurs PHP, des extensions, des thèmes, .htaccess, les limites de stockage et d'autres problèmes côté serveur en question.
Tu trouveras le dépannage détaillé sous Corriger l'erreur 500 dans WordPress.
14. Bien interpréter l'erreur 404 #
Une erreur HTTP 404 signifie fondamentalement que la ressource demandée n'a pas été trouvée à l'adresse utilisée.
Si la page d'accueil de WordPress fonctionne, mais que soudainement de nombreux articles ou sous-pages affichent une erreur 404, les règles de permaliens ou de réécriture peuvent en être une cause possible.
Nous traitons le diagnostic ciblé sous Corriger l'erreur 404 dans WordPress et réparer les permaliens.
15. Erreur 403 : Accès refusé #
Un statut HTTP 403 signifie que le serveur comprend la demande, mais refuse de l'autoriser.
Les causes possibles peuvent par exemple inclure, selon l'environnement :
- Autorisations de fichiers ou de répertoires
- Règles de sécurité
- Configuration du serveur web
- Plugin de sécurité
- Blocage basé sur IP
- règles erronées dans les fichiers de configuration
Par conséquent, une erreur 403 ne doit pas entraîner une réinstallation automatique de WordPress.
16. Erreur 502, 503 ou 504 #
Ces erreurs diffèrent d'une erreur 404 WordPress classique et ne doivent pas toutes être traitées de la même manière.
Selon l'architecture du serveur, des serveurs Web en amont, des processus PHP, des systèmes de proxy ou d'autres services peuvent être impliqués.
Un 503 Service indisponible peut signifier, par exemple, qu'un service requis est temporairement indisponible ou que l'environnement ne peut pas traiter une requête pour le moment.
Un Délai d'attente de la passerelle 504 indique qu'un système impliqué n'a pas reçu à temps une réponse requise.
En cas d'erreurs 502, 503 ou 504 répétées, l'heure, l'URL concernée et la fréquence sont particulièrement importantes pour l'analyse technique.
La connexion expire #
Lorsque le navigateur attend longtemps et finit par signaler un délai d'attente, cela diffère d'une page d'erreur WordPress affichée immédiatement.
Les causes possibles incluent par exemple :
- Connexion réseau
- Accessibilité du serveur
- Pare-feu
- processus surchargés ou bloqués
- services externes dont la réponse est attendue
- de très longs processus PHP
L'erreur exacte et les journaux du serveur sont également plus importants ici que des modifications basées sur des suppositions.
18. „ Erreur lors de l'établissement d'une connexion à la base de données “ #
WordPress a besoin de sa base de données pour le contenu, les paramètres, les utilisateurs et de nombreuses autres informations.
Si WordPress ne peut pas se connecter à la base de données, un message d'erreur correspondant apparaît généralement.
Parmi les causes possibles, on peut citer notamment :
- nom de base de données incorrect
- mauvais utilisateur de base de données
- mauvais mot de passe de base de données
- mauvais hôte de base de données
- Service de base de données non disponible
- configuration endommagée ou modifiée manuellement
Les informations de connexion à la base de données WordPress se trouvent généralement dans :
wp-config.php
configuré.
Attention : Modifier les identifiants de base de données dans
wp-config.phppas au pif. Si les valeurs ont fonctionné jusqu'à présent et que personne n'a modifié la configuration de la base de données, il faut d'abord comprendre pourquoi la connexion échoue soudainement.
19. Erreur critique WordPress ou page blanche #
Si le domaine et le serveur Web sont globalement accessibles, mais que WordPress affiche un message d'erreur critique ou simplement une page blanche, l'accent de la diagnostic doit être mis davantage sur PHP et WordPress eux-mêmes.
Les causes fréquentes sont les extensions, les thèmes, le code PHP personnalisé, la compatibilité PHP ou les problèmes de mémoire.
Dans ce cas, suivez notre guide WordPress affiche une page blanche ou une erreur critique : que faire ? continuer.
20. La connexion WordPress ne fonctionne pas #
Si le frontal public fonctionne normalement, mais que vous ne pouvez plus vous connecter à l'espace d'administration WordPress, le site Web n'est pas fondamentalement hors ligne.
Le diagnostic devrait alors se concentrer sur la connexion.
Les causes possibles vont des problèmes de mots de passe et de cookies aux plugins de sécurité, en passant par les redirections.
Nous traitons ce cas spécifiquement sous La connexion WordPress ne fonctionne pas : causes et solutions.
21. Mode maintenance après une mise à jour #
Pendant les mises à jour, WordPress peut passer temporairement en mode maintenance.
Normalement, cet état prend fin automatiquement après la fin de la mise à jour.
Cependant, si une mise à jour est interrompue, le site Web peut rester bloqué en mode maintenance.
Une remarque telle que :
Temporairement indisponible en raison de travaux de maintenance planifiés.
est par conséquent différent d'une erreur DNS, SSL ou HTTP 500.
Dans ce cas, vérifiez si une mise à jour de WordPress, d'une extension ou d'un thème a été effectuée immédiatement avant.
22. Extension comme cause #
Si le site web tombe en panne immédiatement après l'installation, l'activation ou la mise à jour d'un plugin, ce plugin constitue un point de départ évident.
Si la zone d'administration est toujours accessible, le plugin concerné peut d'abord y être désactivé.
Si la zone d'administration est inaccessible, un diagnostic manuel via le répertoire des plugins peut s'avérer nécessaire selon l'erreur.
Si la cause n'est pas évidente, tu devrais examiner les extensions de manière systématique au lieu de supprimer plusieurs extensions au hasard.
La procédure détaillée suit dans Détecter et résoudre les conflits de plugins ou de thèmes dans WordPress.
23. Le thème comme cause #
Un thème peut également faire en sorte qu'un site Web WordPress ne s'affiche plus correctement.
C'est particulièrement suspect lorsque l'erreur survient immédiatement après :
- une mise à jour de thème
- un changement de thème
- d'une modification d'un thème enfant
- à une modification de
fonctions.php
performance.
Il convient également de vérifier d'abord le contexte temporel ici.
Vérifier la version de PHP comme cause #
Si la version de PHP a été modifiée juste avant la panne, il convient de vérifier la compatibilité de WordPress, des extensions et du thème.
Une version plus récente de PHP peut par exemple rendre visible du code obsolète qui fonctionnait auparavant.
À l'inverse, une version PHP très ancienne peut être incompatible avec un logiciel WordPress moderne.
Il ne faut donc pas changer de version de PHP de manière aléatoire.
La manière de procéder systématiquement sera abordée sous Modifier la version PHP pour WordPress et vérifier la compatibilité.
25. Limite de mémoire PHP #
Si PHP a besoin de plus de mémoire que autorisé pendant son exécution, une requête peut s'interrompre.
Une entrée de journal correspondante peut par exemple contenir le texte :
Taille de mémoire autorisée ... épuisée
contenir.
Dans ce cas, la cause est beaucoup plus concrète que la déclaration générale „ site Web inaccessible “.
Nous expliquons comment les limites de mémoire de WordPress et de PHP sont liées et pourquoi une augmentation n'est pas toujours la véritable solution sur Limite de mémoire PHP dans WordPress : identifier et corriger l'erreur.
Utilisation des journaux d'erreurs #
Si le serveur est accessible, mais que le traitement de WordPress ou de PHP échoue, les journaux d'erreurs constituent souvent l'une des sources d'information les plus précieuses.
Un journal des erreurs peut contenir, par exemple, des indications sur :
- Erreurs fatales PHP
- Problèmes de stockage
- plugins défectueux
- Fichiers de thème
- fichiers manquants
- Erreur de syntaxe
- Problèmes avec les fonctions PHP
Porte une attention particulière aux entrées dont l'horodatage correspond à l'apparition du problème.
27. Utiliser le mode débogage de WordPress #
Si l'on suspecte un problème WordPress ou PHP et que les informations disponibles ne suffisent pas, les fonctions de débogage de WordPress peuvent aider au diagnostic.
Cela comprend, entre autres :
WP_DEBUG
WP_DEBUG_LOG
WP_DEBUG_DISPLAY
Sur les sites web de production, les messages d'erreur détaillés ne doivent pas être affichés inutilement au public.
Un guide détaillé suivra sous Activer le débogage WordPress et utiliser les journaux d'erreurs.
28. .htaccess comme source d'erreur potentielle #
Avec certaines configurations de serveurs web, WordPress utilise le fichier :
.htaccess
notamment pour les règles de réécriture.
Des règles incorrectes ou incompatibles peuvent causer divers problèmes.
La date est particulièrement pertinente pour :
- d'erreurs HTTP 500
- Problèmes de permaliens
- Redirections
- certaines règles de sécurité
Cependant, le fichier ne doit pas simplement être supprimé ou remplacé par n'importe quelle version trouvée sur Internet sans sauvegarder la configuration existante.
29. Fichiers du cœur de WordPress endommagés ou incomplets #
Dans de rares cas, les fichiers du cœur de WordPress peuvent être manquants ou endommagés, par exemple après une mise à jour interrompue ou un transfert de fichiers manuel défectueux.
Avant de remplacer les fichiers principaux, il convient toutefois de vérifier si le problème indique effectivement cela.
Dossiers tels que :
wp-content/
en revanche, tes thèmes, extensions et autres contenus de site Web sont inclus et ne doivent pas être écrasés ou supprimés sans réflexion lors d'une réparation du noyau.
Ne pas modifier les autorisations de fichiers de manière aléatoire #
Des autorisations de fichiers ou de répertoires incorrectes peuvent causer des problèmes d'accès.
Ce n'est cependant pas une bonne stratégie de dépannage que d'attribuer systématiquement à l'ensemble des fichiers et des répertoires des droits aussi étendus que possible.
Des autorisations trop généreuses peuvent présenter un risque pour la sécurité et masquer la cause profonde.
Attention : N'utilisez jamais aveuglément des autorisations de fichiers trop larges dans le seul but de corriger „ d'une manière ou d'une autre “ une erreur. Les autorisations doivent être définies de manière ciblée et adaptée à l'environnement du serveur.
31. Le site web est-il peut-être tout simplement très lent ? #
Du point de vue d'un visiteur, un site Web extrêmement lent peut donner l'impression d'une panne.
Si la page finit par s'afficher après une longue attente, il ne faut donc pas chercher exclusivement une panne complète du serveur.
Les causes possibles peuvent être, par exemple :
- traitement PHP lent
- extensions gourmandes en ressources
- requêtes de base de données lentes
- services externes
- Tâches WP-Cron
- mise en cache manquante ou inappropriée
- très grandes images ou ressources
- ressources d'hébergement atteintes
Pour ce cas, l'article propre suit WordPress est lent : trouver les causes et améliorer le temps de chargement.
32. Les ressources d'hébergement comme cause possible #
Un site Web WordPress nécessite entre autres du temps processeur, de la mémoire vive, des processus PHP et d'autres ressources serveur.
Si un site web nécessite un nombre exceptionnel de ressources ou atteint des limites techniques, les requêtes peuvent ralentir ou échouer.
Cependant, cela ne signifie pas automatiquement que chaque atteinte d'une limite doit être expliquée par un „ hébergement trop petit “.
Une consommation anormale de ressources peut également être due à :
- plugins défectueux
- processus mal optimisés
- Bots
- un nombre inhabituel de demandes
- Processus d'importation ou de sauvegarde
- tâches cron bloquées
indiquer.
Important : Les limites de ressources sont une mesure et non automatiquement la cause. Ce qui est décisif, c'est de savoir pourquoi le site web a besoin de la ressource en question.
33. Prendre en compte le pare-feu et les mécanismes de sécurité #
Les pare-feu et autres mécanismes de sécurité peuvent bloquer les accès si les requêtes sont considérées comme indésirables ou suspectes.
Si seule une adresse IP spécifique, un réseau spécifique ou une action spécifique est concernée, ce niveau doit également être pris en compte.
Ne désactivez toutefois pas les mécanismes de sécurité de manière générale sur un site web de production uniquement pour effectuer un test.
34. CDN ou proxy comme couche supplémentaire #
Si le domaine passe par un CDN, un proxy inverse ou un service amont comparable, il y a un niveau technique supplémentaire entre le visiteur et le serveur Web réel.
Une erreur peut alors, par exemple :
- au service en amont
- lors de sa configuration DNS
- avec SSL entre les systèmes
- sur le serveur d'origine
- lors de la connexion entre le proxy et le serveur d'origine
mentir.
La page d'erreur visible ne doit donc pas nécessairement provenir directement de WordPress ou du serveur d'hébergement proprement dit.
35. Les services externes peuvent ralentir WordPress #
Les plugins et les thèmes peuvent contacter des systèmes externes pendant une requête.
Si une API externe est lente ou inaccessible et que le logiciel utilisé la gère mal, cela peut retarder le traitement de la requête WordPress.
C'est une raison supplémentaire pour analyser les journaux d'erreurs et le comportement des plugins en cas de délais d'attente et de temps de réponse inhabituellement longs.
36. Problèmes de base de données malgré un site Web fondamentalement accessible #
Tous les problèmes de base de données ne génèrent pas un message complet concernant une perte de connexion.
Des requêtes lentes, des tables corrompues ou des volumes de données exceptionnellement importants peuvent également causer des problèmes.
Cependant, les modifications directes de la base de données ne doivent être effectuées qu'en cas d'indices concrets d'un problème de base de données.
Une base de données n'est pas un endroit pour des „ travaux de nettoyage “ arbitraires lors d'un incident critique.
Qu'est-ce qui a été modifié immédiatement avant la panne ? #
Comme pour de nombreux problèmes techniques, la corrélation temporelle est particulièrement précieuse.
Demande-toi :
- Est-ce que WordPress a été mis à jour ?
- un plugin a-t-il été mis à jour ?
- un thème a-t-il été mis à jour ?
- Un plugin a-t-il été installé ou activé ?
- Est-ce que PHP a changé ?
- Les enregistrements DNS ont-ils été modifiés ?
- Le domaine a-t-il été transféré ?
- SSL a-t-il été modifié ?
- a été
.htaccesstraité ? - du code PHP personnalisé a-t-il été inséré ?
Une perturbation qui commence immédiatement après un changement concret doit d'abord être examinée en lien avec ce changement précis.
38. Ne pas changer cinq choses en même temps #
Le dépannage systématique consiste à tester les hypothèses une par une.
Si vous en même temps :
- PHP change
- désactives les plugins
.htaccessremplace- Vider le cache
- modifier le DNS
et que le site Web fonctionne ensuite, vous avez peut-être éliminé le symptôme, mais vous n'avez presque rien appris sur la cause réelle.
Cela rend également plus difficile la prévention d'une nouvelle panne.
Ne pas restaurer automatiquement la sauvegarde comme première étape #
Une sauvegarde récente est très importante. Néanmoins, une restauration complète n'est pas la meilleure première réaction face à chaque erreur.
Une erreur DNS ne se répare pas, par exemple, en restaurant une base de données WordPress.
Sur un site web dynamique, une restauration peut également écraser des contenus ou des transactions plus récents.
Déterminez par conséquent d'abord, si possible, à quel niveau technique se situe le problème.
40. Diagnostic systématique selon l'image de défaut #
À titre indicatif, vous pouvez utiliser l'ordre suivant :
- Noter le message d'erreur précis.
- Tester séparément la page d'accueil, la sous-page et la zone d'administration.
- Tester un autre navigateur ou un autre appareil.
- Utiliser une autre connexion Internet si nécessaire.
- Vérifier le statut du domaine.
- Vérifier la résolution DNS et les modifications DNS récentes.
- Vérifier les erreurs SSL/HTTPS.
- Déterminer le code d'état HTTP.
- En cas d'erreur 404, examiner les permaliens et les règles de réécriture.
- À 500, examinez les erreurs et les journaux côté serveur.
- Diagnostiquer une erreur critique WordPress/PHP.
- En cas d'erreur de base de données, vérifier la connexion à la base de données.
- Prendre en compte les modifications récentes apportées aux plugins, au thème ou à PHP.
- Analyser les journaux d'erreurs.
- Remédier spécifiquement à la cause.
- Ensuite, tester complètement le site web.
41. Le site Web est à nouveau accessible – et maintenant ? #
Si le site web refonctionne, le diagnostic ne doit pas se terminer automatiquement.
Vérifier :
- La cause réelle a-t-elle été identifiée ?
- La panne a-t-elle été ponctuelle ou reproductible ?
- Y a-t-il encore des messages d'erreur dans le journal ?
- Est-ce que le frontend et la zone d'administration fonctionnent ?
- Est-ce que les formulaires et autres fonctions importantes fonctionnent ?
- Faut-il annuler les modifications temporaires ?
Il est important, en particulier en cas de pannes récurrentes, de ne pas se limiter à éliminer le symptôme visible.
42. Quelles informations aident le support de CURIAWEB ? #
Si un site Web WordPress n'est pas accessible chez CURIAWEB, des informations techniques concrètes aident à en cerner la cause.
Veuillez partager si possible :
- domaine concerné
- message d'erreur précis
- moment approximatif de la première apparition
- si le problème se produit de manière permanente ou seulement temporaire
- si le frontend et la zone d'administration sont concernés
- si le site Web est accessible via une autre connexion Internet
- quel changement a été effectué immédiatement avant le problème
- que ce soit le DNS, PHP, des extensions ou un thème qui a été récemment modifié
Une capture d'écran du message d'erreur peut également s'avérer utile.
N'envoyez pas de mots de passe non sollicités.
Résumé #
Lorsqu'un site Web WordPress est inaccessible, il ne faut pas automatiquement supposer que WordPress lui-même en est la cause. Le domaine, le DNS, le SSL, le serveur Web, PHP, la base de données, WordPress, les extensions (plugins) et les thèmes constituent différentes couches techniques.
Commencez donc par le message d'erreur exact, puis vérifiez si le domaine atteint le bon serveur et quelle erreur HTTP ou de connexion est réellement présente.
Une erreur 404 nécessite un diagnostic différent d'une erreur HTTP 500, d'un problème SSL, d'une erreur de base de données ou d'une erreur critique WordPress. Ce n'est qu'une fois le niveau défectueux cerné que des modifications doivent être apportées.
Le contexte temporel des modifications précédentes ainsi que les journaux d'erreurs du serveur et de WordPress sont particulièrement utiles. Un diagnostic systématique évite que des modifications aléatoires ne créent des problèmes supplémentaires ou ne masquent la cause réelle.
