Site WordPress inaccessible : causes, diagnostic et solutions

Un site WordPress inaccessible n’est pas forcément en panne à cause de WordPress. Le nom de domaine, les DNS, le certificat HTTPS, l’hébergement, PHP ou la base de données peuvent bloquer l’affichage bien avant qu’une extension ou le thème entre en jeu. Avant de modifier quoi que ce soit, il faut donc situer la panne : on part de l’extérieur, votre connexion, le domaine, le serveur, et on remonte ensuite vers WordPress. Le tableau ci-dessous donne le premier contrôle à faire selon ce que vous voyez à l’écran.

Diagnostic rapide : du symptôme au premier contrôle

Si l’écran affiche précisément « Il y a eu une erreur critique sur ce site », la cause est une erreur fatale de PHP et la procédure est détaillée dans notre guide sur l’erreur critique WordPress.

Pourquoi un site WordPress peut-il devenir inaccessible ?

Afficher une page WordPress mobilise une chaîne de composants, et chacun peut casser seul. Le nom de domaine est enregistré et payé, les DNS renvoient vers la bonne adresse IP, le serveur web répond avec un certificat HTTPS valide. Viennent ensuite PHP, qui exécute le code, le serveur MySQL ou MariaDB, qui accepte la connexion, et enfin WordPress, qui charge ses extensions et le thème.

Le navigateur ne montre que le bout de la chaîne. Désactiver des extensions quand le domaine a expiré ne changera rien, et chaque manipulation inutile ajoute une variable de plus à démêler. D’où l’ordre de ce guide : de l’extérieur vers l’intérieur.

Première vérification : le site est-il réellement inaccessible ?

Tester depuis une autre connexion

Coupez le Wi-Fi de votre téléphone et ouvrez le site en 4G ou en 5G. Si le site s’affiche en données mobiles et pas sur votre box, le problème est entre vous et le serveur : box, réseau de l’entreprise, DNS de votre fournisseur d’accès, ou votre adresse IP bloquée par le serveur.

Tester en navigation privée

Une fenêtre privée part sans cookies ni session. Si le site s’y affiche normalement, le blocage vient de votre navigateur : cookie de connexion corrompu, ancienne redirection gardée en cache, extension du navigateur. Videz les données du site concerné plutôt que tout l’historique.

Vérifier si seul votre accès est concerné

Un pare-feu applicatif, une extension de sécurité ou le frontal de l’hébergeur peuvent bloquer une seule adresse IP, la vôtre. Le 29 septembre 2026, nous avons envoyé une trentaine de requêtes de contrôle en quelques minutes vers un site WordPress que nous administrons chez o2switch. Cela a suffi : tout le site répondait 403 pour nous, alors que la même requête lancée depuis le serveur répondait 200 (relevé du 29 septembre 2026). Les requêtes refusées n’apparaissaient même pas dans les journaux d’accès du site, parce qu’elles étaient arrêtées avant. Le blocage s’est levé seul au bout d’une vingtaine de minutes. Vu de notre bureau, c’était une panne totale. Il n’y en avait aucune.

Pour trancher, faites tester l’adresse par quelqu’un d’autre ou utilisez un service de test de disponibilité en ligne, qui interroge votre site depuis plusieurs pays.

Vérifier si le domaine répond

Un domaine expiré cesse de pointer vers votre serveur ou affiche une page de parking du registraire. Vérifiez la date d’échéance dans votre espace client chez le registraire, ou dans l’annuaire Whois (celui de l’Afnic pour un .fr). Un changement récent de DNS ou de serveurs de noms explique aussi un site visible chez certains et pas chez d’autres : chaque résolveur garde l’ancienne réponse en cache jusqu’à expiration de sa durée de vie (TTL).

Si vous avez accès à un terminal, deux commandes suffisent pour savoir où en est le domaine :

dig +short NS votre-site.fr     # serveurs de noms déclarés
dig +short A www.votre-site.fr  # adresse IP vers laquelle pointe le site

Comparez l’adresse obtenue avec celle indiquée par votre hébergeur. Si elles diffèrent, le site n’est pas cassé : il est envoyé ailleurs.

Identifier le symptôme avant de chercher la cause

La commande curl, disponible sur macOS, Linux et Windows 10 ou plus récent, donne le symptôme sans aucun cache de navigateur. Voici ce qu’elle renvoie pour trois pannes classiques (relevé du 7 octobre 2026, curl 8) :

$ curl -I https://domaine-inexistant.fr/
curl: (6) Could not resolve host: domaine-inexistant.fr        → DNS ou domaine

$ curl -I https://expired.badssl.com/
curl: (60) SSL certificate problem: certificate has expired    → certificat HTTPS

$ curl -IL --max-redirs 10 https://site-en-boucle.example/
curl: (47) Maximum (10) redirects followed                     → boucle de redirection

Quand le serveur répond, la première ligne donne le code HTTP, par exemple HTTP/2 500 ou HTTP/2 503. Ce code situe la panne bien mieux qu’une capture d’écran.

Le navigateur indique que le serveur est introuvable

Le nom de domaine ne se traduit plus en adresse IP. Les causes possibles se limitent au domaine (expiré, suspendu, mal renouvelé), aux DNS (enregistrement supprimé, serveurs de noms changés) ou, plus rarement, au résolveur DNS de votre propre connexion. WordPress n’est pas en cause : la requête n’arrive même pas jusqu’au serveur.

Le site affiche une erreur HTTP 500

Le code 500 signifie seulement que le serveur n’a pas pu produire la page. C’est un symptôme générique, pas un diagnostic. Derrière, on trouve le plus souvent une erreur fatale de PHP dans une extension ou le thème, une règle invalide dans .htaccess, une version de PHP incompatible ou une limite du serveur. WordPress lui-même renvoie un code 500 quand il ne joint pas la base de données. Le journal d’erreurs est le seul moyen de savoir laquelle de ces causes est la bonne.

Les codes voisins orientent autrement. Un 502 ou un 504 signale qu’un intermédiaire, proxy ou CDN, n’a pas obtenu de réponse de PHP à temps. Un 503 indique un service volontairement indisponible ou saturé. Les codes 520 à 527 sont propres à Cloudflare : le CDN fonctionne, mais il n’arrive pas à joindre correctement votre serveur.

WordPress affiche une page blanche

Une page entièrement vide est presque toujours une erreur PHP que le serveur n’affiche pas, ce qui est normal sur un site en production. C’est l’écran blanc de la mort. Depuis WordPress 5.2, la plupart de ces erreurs produisent plutôt le message d’erreur critique, mais la page blanche subsiste quand l’erreur survient avant que WordPress ait pu l’intercepter. Dans les deux cas, la réponse est dans le journal d’erreurs.

WordPress affiche « Erreur lors de la connexion à la base de données »

Ce message, tiré de la traduction française officielle de WordPress, apparaît quand PHP n’a pas pu ouvrir la connexion au serveur MySQL ou MariaDB. Le code de WordPress envisage lui-même trois explications : identifiant ou mot de passe incorrects, nom d’hôte incorrect, ou serveur de bases de données arrêté. En pratique, la troisième est fréquente sur un hébergement mutualisé : un incident ou une saturation du serveur MySQL touche alors tous les sites du serveur en même temps.

Ne commencez pas par modifier wp-config.php. Si le site fonctionnait la veille et que personne n’a touché à ce fichier, les identifiants n’ont aucune raison d’être faux. Regardez d’abord la page d’état de votre hébergeur et votre accès à phpMyAdmin.

WordPress affiche « Indisponibilité temporaire pour cause de maintenance »

Pendant une mise à jour, WordPress crée un fichier .maintenance à la racine du site et répond aux visiteurs par ce message, avec un code 503. Si la mise à jour est coupée en route (onglet fermé, délai dépassé), le fichier reste. Le code de WordPress l’ignore toutefois au bout de dix minutes après sa création (relevé dans le code de WordPress 7.1.3, fonction wp_is_maintenance_mode). Deux conséquences pratiques :

• dans les dix premières minutes, supprimer le fichier .maintenance par FTP remet le site en ligne, mais la mise à jour interrompue reste à vérifier : relancez-la ou contrôlez la version installée ;
• si le message persiste bien au-delà, ce fichier n’est probablement pas seul en cause : cherchez une extension de mode maintenance, un fichier wp-content/maintenance.php, ou une mise à jour réellement encore en cours.

Ne confondez pas ce blocage avec le mode maintenance WordPress que l’on active volontairement pendant des travaux.

Le site fonctionne mais /wp-admin/ est inaccessible

Le site public s’affiche, donc le domaine, le serveur et la base de données répondent. La panne se situe dans ce qui ne concerne que l’administration :

• Une extension de sécurité qui a déplacé l’adresse de connexion (masquage de la page de connexion) ou bloqué votre IP après plusieurs échecs. /wp-admin/ renvoie alors une 404 ou une 403 sans que rien soit cassé.
• Une boucle de connexion : vous saisissez vos identifiants et la page de connexion revient. C’est souvent un cookie bloqué, ou des adresses du site incohérentes dans les réglages (HTTP et HTTPS, avec et sans www).
• Une erreur PHP propre à l’administration, typique d’une extension dont seule la partie réglages est incompatible.
• Une règle serveur dans .htaccess ou un pare-feu applicatif qui filtre le dossier /wp-admin/.

Le code HTTP renvoyé par /wp-admin/ et /wp-login.php tranche entre ces pistes : 403 pour un blocage, 404 pour une adresse déplacée, 500 pour une erreur PHP, 302 en boucle pour un problème de cookies ou d’adresse.

Le site devient très lent puis inaccessible

Une dégradation progressive signale un serveur à court de ressources plutôt qu’un code cassé. Chaque visite occupe un processus PHP le temps de produire la page. Quand tous les processus sont pris, par un pic de trafic, un robot agressif, une attaque par force brute sur la page de connexion ou une requête lourde en base de données, les visiteurs suivants attendent puis tombent en erreur. Sur les hébergements mutualisés sous CloudLinux, cette saturation se traduit souvent par une erreur 508 « Resource Limit Is Reached ».

Vérifier l’hébergement avant de modifier WordPress

Si le serveur entier est indisponible, aucune modification de WordPress ne remettra le site en ligne. Ce contrôle est rapide et passe avant tous les autres :

• La page d’état de l’hébergeur (status page) et ses comptes sur les réseaux sociaux : un incident en cours y est généralement annoncé.
• Les ressources consommées dans le panneau d’administration : processeur, mémoire, processus, entrées et sorties disque. Une jauge au maximum explique une lenteur suivie d’erreurs.
• Le quota disque : un espace plein empêche d’écrire les sessions, les caches, les journaux et les fichiers temporaires, avec des erreurs qui semblent sans rapport entre elles.
• L’état du compte : une facture impayée ou une suspension pour abus rend le site inaccessible sans aucune panne technique.
• Les autres sites du même compte : s’ils tombent tous en même temps, la cause est commune, donc serveur ou base de données, pas WordPress.

Sur un hébergement mutualisé, vous partagez la machine avec d’autres clients. Un incident peut venir d’un voisin, et seul l’hébergeur peut le confirmer. Ouvrir un ticket avec le code HTTP, l’heure exacte et l’adresse testée fait gagner un échange.

Lire les journaux : la source la plus utile du diagnostic

Le navigateur montre un symptôme. Les journaux montrent, souvent, la cause. Trois familles de journaux se complètent :

• le journal d’erreurs PHP, souvent un fichier error_log à la racine du site ou une rubrique « Erreurs » du panneau cPanel : il enregistre les erreurs fatales avec le fichier et la ligne ;
• le journal d’accès du serveur : il montre chaque requête reçue, son code de réponse et son heure, et permet de repérer un robot qui sature le site ;
• le journal de WordPress, debug.log, quand vous l’activez (voir la section suivante).

L’absence de trace est aussi une information. Si vos tentatives n’apparaissent pas dans le journal d’accès, la requête a été arrêtée avant d’atteindre le site : DNS, pare-feu de l’hébergeur ou CDN. C’est exactement ce que montrait le blocage d’IP décrit plus haut.

Voici les messages les plus fréquents dans un journal d’erreurs PHP, et ce qu’ils indiquent :

Un message oriente, il ne répare pas. Le fichier cité est parfois la victime et non le coupable : une extension peut planter parce qu’une autre lui a retiré une fonction. Lisez toujours la première erreur fatale d’une série, à l’heure où la panne a commencé. Le détail de la lecture d’une ligne d’erreur fatale est dans notre guide de l’erreur critique WordPress.

Activer le journal de débogage de WordPress

Si l’hébergeur ne vous donne pas accès au journal PHP, WordPress peut écrire le sien. Ajoutez ces lignes dans wp-config.php, au-dessus de la ligne « C’est tout, ne touchez pas à ce qui suit ! » :

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

Rechargez la page en panne, puis ouvrez wp-content/debug.log. Cherchez dans l’ordre : le type d’erreur, le chemin (wp-content/plugins/nom-extension/ pour une extension, wp-content/themes/nom-theme/ pour le thème, wp-includes/ pour le cœur), le nom du fichier et le numéro de ligne.

Attention : WP_DEBUG_DISPLAY doit rester à false, sinon les erreurs s’affichent à tous les visiteurs, avec les chemins du serveur. Le fichier debug.log est lui-même placé dans un dossier public et peut contenir des informations sensibles : désactivez le débogage et supprimez le fichier une fois le diagnostic fait. Pour garder un journal actif plus longtemps, donnez à WP_DEBUG_LOG un chemin hors du dossier public plutôt que true.

Vérifier les extensions WordPress

Les extensions sont une cause fréquente, surtout quand la panne suit une mise à jour, mais elles ne sont pas coupables par défaut. Si le journal cite une extension, traitez celle-là seulement.

Depuis l’administration, si elle répond

Désactivez l’extension citée dans le journal, ou celle mise à jour juste avant la panne, puis testez le site en navigation privée.

Par FTP ou SFTP

Renommez le dossier de l’extension suspecte, par exemple wp-content/plugins/nom-extension en nom-extension-off. WordPress ne la trouve plus et ne la charge plus.

Si le journal ne désigne rien, vous pouvez tester toutes les extensions d’un coup en renommant le dossier wp-content/plugins en plugins-off. Ce test demande de respecter un ordre précis, souvent omis :

1. renommez plugins en plugins-off, puis rechargez le site ;
2. si le site revient, connectez-vous et ouvrez la page Extensions : c’est à ce moment seulement que WordPress désactive les extensions introuvables, avec la mention « Le fichier de l’extension n’existe pas » (relevé dans le code de WordPress 7.1.3, fonction validate_active_plugins) ;
3. remettez ensuite le nom plugins : les extensions sont désormais toutes inactives ;
4. réactivez-les une par une en vérifiant le site entre chaque, jusqu’à retrouver la fautive.

Si vous remettez le nom d’origine avant d’avoir ouvert la page Extensions, WordPress les recharge toutes et le site retombe en panne.

Attention : ne supprimez jamais un dossier d’extension pour « tester ». Renommer est réversible, supprimer ne l’est pas, et certaines extensions stockent des fichiers de configuration dans leur dossier. Sur une boutique, désactiver toutes les extensions coupe aussi le paiement et les commandes : préférez un test ciblé, à partir du journal.

Désactiver une extension est un test, pas une réparation. Le site revient, mais la fonction qu’elle assurait (formulaire, paiement, traduction, cache) ne marche plus. Il faut ensuite mettre à jour l’extension, la remplacer ou corriger son code.

Le cas des drop-ins, qui survivent au renommage

Certains fichiers placés directement dans wp-content se chargent même quand le dossier plugins est renommé : advanced-cache.php (cache de page), object-cache.php (cache d’objets, souvent Redis ou Memcached), db.php. Ils sont déposés par une extension de cache ou de performance. Sur ilti.fr même, wp-content contient advanced-cache.php et object-cache.php (relevé du 7 octobre 2026). Si le journal cite l’un de ces fichiers, ou si le site reste en panne alors que toutes les extensions sont désactivées, regardez de ce côté : un object-cache.php qui ne joint plus son serveur Redis peut suffire à rendre le site inaccessible. Renommez le fichier pour le tester, il est recréé par l’extension à sa réactivation.

Vérifier le thème WordPress

Le thème est en cause après une mise à jour du thème ou de son thème parent, après une modification de functions.php (un bout de code collé depuis un tutoriel), ou quand du code personnalisé ancien rencontre une version récente de PHP. Un thème enfant dont le parent a changé peut aussi casser.

Pour tester, activez temporairement un thème par défaut de WordPress, comme Twenty Twenty-Five, s’il est installé. Sans accès à l’administration, la commande WP-CLI wp theme activate twentytwentyfive --skip-themes --skip-plugins le fait en une ligne. Renommer le dossier du thème actif par FTP fonctionne aussi, avec une limite : WordPress ne bascule vers le thème par défaut qu’à l’ouverture de la page Apparence > Thèmes (relevé dans le code de WordPress 7.1.3, fonction validate_current_theme). Tant que personne n’ouvre cette page, le site public peut rester blanc.

Gardez en tête qu’un thème par défaut change l’apparence du site public. C’est acceptable le temps d’un diagnostic, pas comme solution.

Vérifier la version de PHP

Un changement de version de PHP, décidé par vous ou imposé par l’hébergeur, est un déclencheur classique : le site fonctionnait la veille, il plante le lendemain sans que personne ait touché à WordPress. Du code écrit pour une ancienne version utilise des fonctions retirées ou des comportements devenus des erreurs.

La démarche :

1. lire le journal d’erreurs pour identifier le fichier qui plante ;
2. identifier l’extension ou le thème auquel il appartient ;
3. vérifier s’il existe une version compatible ;
4. mettre à jour, remplacer ou faire corriger ce composant.

Revenir à la version précédente de PHP depuis le panneau de l’hébergeur peut remettre le site en ligne le temps de corriger. Ce retour doit rester temporaire : une version de PHP en fin de vie ne reçoit plus de correctifs de sécurité. La fiche compatibilité PHP détaille le mécanisme.

Vérifier la mémoire et les ressources

Le message Allowed memory size exhausted signifie que PHP a atteint sa limite de mémoire. Deux réglages entrent en jeu : memory_limit, fixé par l’hébergeur dans la configuration de PHP, et la constante WP_MEMORY_LIMIT de WordPress, que l’on peut relever dans wp-config.php :

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

Par défaut, WordPress demande 40 Mo pour le site public (64 Mo en multisite) et 256 Mo pour l’administration, sauf si l’hébergeur interdit de modifier la limite (relevé dans le code de WordPress 7.1.3, fichier default-constants.php). La constante ne peut jamais dépasser ce que le serveur autorise.

Augmenter la mémoire n’est pas automatiquement la bonne réparation. Si une extension consomme anormalement, relever la limite repousse seulement la panne au prochain pic. Le journal indique quel fichier a réclamé la mémoire au moment de l’erreur : c’est lui qu’il faut examiner.

Vérifier la base de données WordPress

Les problèmes de base de données prennent plusieurs formes : serveur MySQL indisponible, base inaccessible, droits de l’utilisateur modifiés, table endommagée, ou configuration changée lors d’une migration. Le fichier wp-config.php contient les quatre paramètres de connexion :

• DB_NAME : le nom de la base ;
• DB_USER : l’utilisateur MySQL ;
• DB_PASSWORD : son mot de passe ;
• DB_HOST : l’adresse du serveur, souvent localhost.

Ne modifiez jamais ces valeurs au hasard. Comparez-les avec celles affichées dans le panneau de l’hébergeur, rubrique bases de données. Si elles correspondent et que la connexion échoue quand même, la panne est côté serveur et c’est à l’hébergeur de la traiter.

Une erreur de connexion ne signifie pas que la base est détruite. Dans l’immense majorité des cas, les données sont intactes et le site revient dès que le serveur répond à nouveau. Avant toute opération de réparation de tables, faites un export de la base depuis phpMyAdmin.

Site WordPress inaccessible après une mise à jour

Quand la panne suit une mise à jour, l’enquête est plus simple : le suspect est connu. La méthode reste la même pour les quatre cas : consulter le journal, identifier ce qui a changé, isoler le composant, vérifier sa compatibilité.

Mise à jour d’une extension

Le cas le plus courant. Le journal cite en général un fichier de l’extension mise à jour. Renommez son dossier, vérifiez sur la page de l’extension si une version corrective est sortie, ou réinstallez la version précédente depuis le dépôt officiel de WordPress.org, jamais depuis un site tiers.

Mise à jour du thème

Un thème mis à jour peut écraser des modifications faites directement dans ses fichiers, ou ne plus accepter le code d’un thème enfant. Le journal citera un fichier de wp-content/themes/.

Mise à jour de WordPress

Une mise à jour du cœur interrompue laisse des fichiers incomplets, parfois avec le message de maintenance décrit plus haut. Une mise à jour complète peut aussi révéler une extension ancienne qui utilisait une fonction désormais retirée. La commande wp core verify-checksums contrôle que les fichiers du cœur sont intacts.

Mise à jour de PHP

Traitée plus haut : identifier le composant incompatible plutôt que de rester sur l’ancienne version.

Si l’écran affiche le message d’erreur critique après la mise à jour, suivez la procédure du guide erreur critique WordPress, qui utilise l’e-mail du mode de récupération.

Le certificat HTTPS peut-il rendre WordPress inaccessible ?

Oui, de deux façons. Un certificat expiré ou qui ne correspond pas au nom du domaine déclenche une alerte de sécurité qui bloque la plupart des visiteurs. Le renouvellement automatique des certificats gratuits échoue parfois après un changement de DNS : la vérification du domaine ne trouve plus le serveur.

La seconde est la boucle de redirection, ERR_TOO_MANY_REDIRECTS. Elle survient quand deux couches se renvoient le visiteur. Cas typique : un CDN réglé pour joindre votre serveur en HTTP, alors que WordPress ou le serveur redirige tout le HTTP vers le HTTPS. Avec Cloudflare, c’est le mode SSL « Flexible » qui produit ce schéma ; le mode « Full (strict) », avec un certificat valide sur le serveur, le supprime. Vérifiez aussi que les deux adresses du site dans Réglages > Général commencent bien par https://.

Un plugin de sécurité peut-il bloquer l’accès ?

Oui, et c’est même son rôle, ce qui rend le cas trompeur. Une extension de sécurité ou un pare-feu applicatif peut bloquer votre adresse IP après trop de tentatives de connexion, appliquer une règle trop large qui filtre une partie légitime du site, ou interdire /wp-admin/ depuis certains pays. Le symptôme est généralement un code 403, ou une page de blocage signée par l’extension.

Sans accès à l’administration, renommez le dossier de l’extension de sécurité le temps de vous connecter, puis corrigez la règle et réactivez-la aussitôt. Ne laissez jamais un site sans sa protection pour vous éviter de refaire le réglage. Nos conseils pour sécuriser votre site WordPress détaillent les réglages à vérifier.

Un site WordPress piraté peut-il devenir inaccessible ?

Oui, mais ce n’est pas la cause à supposer par défaut. Un piratage se signale le plus souvent par d’autres indices que la panne elle-même :

• des fichiers PHP inconnus, en particulier dans wp-content/uploads/ ;
• des redirections vers des sites tiers, parfois seulement depuis Google ou sur mobile ;
• un compte administrateur que personne n’a créé ;
• des fichiers du cœur modifiés, signalés par wp core verify-checksums ;
• des pages de spam indexées sous votre domaine ;
• une alerte de l’hébergeur, ou un avertissement du navigateur et de Google Safe Browsing.

Si ces signes sont présents, remettre le site en ligne ne suffit pas. Une porte dérobée laissée en place permet au pirate de revenir, et une sauvegarde récente peut contenir le même code malveillant. Il faut un nettoyage complet, c’est l’objet de notre prestation site WordPress piraté.

Faut-il restaurer une sauvegarde ?

Une restauration est pertinente quand trois conditions sont réunies : le problème est apparu après une modification identifiable, une sauvegarde antérieure et saine existe, et vous savez la restaurer, idéalement pour l’avoir déjà fait une fois sur une copie.

Ce n’est pas un bouton magique. Une sauvegarde ramène le site à son état passé, et tout ce qui s’est produit depuis disparaît. Sur un site WooCommerce, restaurer la sauvegarde de la veille efface les commandes, les comptes clients et les mouvements de stock enregistrés depuis. Sur un site vitrine, vous perdez les articles publiés et les messages reçus par formulaire s’ils sont stockés en base.

Attention : avant toute restauration, sauvegardez l’état actuel, même en panne. Il contient les données récentes et la trace de ce qui s’est passé. Une restauration sans cette précaution est irréversible. La fiche sauvegarde WordPress rappelle ce qu’une sauvegarde complète doit contenir.

Restaurer sans avoir compris la cause reproduit souvent la panne : la même mise à jour automatique repasse et le site retombe.

Ordre recommandé pour diagnostiquer un WordPress inaccessible

1. Tester depuis plusieurs connexions : 4G, autre appareil, navigation privée.
2. Noter le message exact et le code HTTP, avec l’heure.
3. Vérifier le domaine et les DNS si le site est introuvable.
4. Vérifier l’état de l’hébergement : incident, ressources, quota, compte.
5. Lire les journaux PHP et serveur à l’heure de la panne.
6. Lister les dernières modifications : mises à jour, changement de PHP, code ajouté, migration.
7. Isoler l’extension ou le thème cité par le journal, sans rien supprimer.
8. Contrôler la version de PHP et la mémoire.
9. Vérifier la base de données sans toucher aux identifiants au hasard.
10. Envisager une restauration seulement avec une sauvegarde saine et après avoir sauvegardé l’état actuel.

Notez chaque manipulation au fur et à mesure. Si vous devez passer la main, cette liste fera gagner un temps considérable à la personne qui reprend.

Quand faire intervenir un professionnel WordPress ?

Le dépannage autonome d’un site WordPress en panne a ses limites, et il vaut mieux les reconnaître tôt. Faites appel à un spécialiste quand :

• le site génère du chiffre d’affaires et chaque heure de panne coûte ;
• une boutique WooCommerce est touchée, avec des commandes en jeu ;
• il n’existe aucune sauvegarde récente et vérifiée ;
• le journal affiche une erreur que vous ne savez pas interpréter, ou n’affiche rien ;
• la base de données est concernée ;
• vous soupçonnez un piratage ;
• vous ne maîtrisez pas l’accès FTP, SFTP ou le panneau de l’hébergeur ;
• plusieurs tentatives de réparation ont déjà eu lieu ;
• la panne revient régulièrement.

Plus les modifications s’accumulent pendant une panne, plus il devient difficile de retrouver la cause initiale. Arrêter de tester à l’aveugle est souvent la décision qui fait gagner le plus de temps.

Votre site WordPress est toujours inaccessible ?

Nous prenons en charge le diagnostic quand la cause reste introuvable, que /wp-admin/ ne répond plus, que les journaux montrent une erreur technique ou que le site est critique pour votre activité. Nous identifions la couche en panne, remettons le site en service sans perte de données, le sécurisons si nécessaire et vous expliquons ce qui s’est passé. Décrivez la panne et l’heure à laquelle elle a commencé dans le formulaire de contact de la page maintenance ; en cas de soupçon de piratage, passez par le formulaire de diagnostic dédié.

Comment éviter qu’un site WordPress devienne inaccessible ?

Aucune méthode ne garantit qu’un site ne tombera jamais en panne : un hébergeur peut subir un incident, un domaine peut être mal renouvelé. On peut en revanche réduire nettement la fréquence des pannes et surtout leur durée.

• Des sauvegardes externes et testées, stockées hors du serveur, avec une restauration déjà essayée sur une copie.
• Une préproduction pour tester les mises à jour avant de les appliquer au site en ligne.
• Des mises à jour contrôlées, une à la fois, plutôt que dix d’un coup.
• Une surveillance de disponibilité qui alerte dès que le site ne répond plus, avant vos clients.
• Des journaux conservés et consultés pour disposer de l’historique au moment où la panne arrive.
• Un suivi des ressources du serveur, pour voir venir la saturation.
• Des changements de version de PHP préparés, extension par extension.
• Des échéances suivies pour le domaine et le certificat.
• Une protection de sécurité tenue à jour, réglée pour ne pas bloquer les administrateurs.

Une panne WordPress n’est pas toujours évitable. Une maintenance préventive régulière réduit le risque, et elle garantit surtout qu’au moment où quelque chose casse, il existe une sauvegarde récente, un historique des modifications et un accès prêt pour intervenir vite. C’est ce que couvre notre contrat de maintenance WordPress.

Questions fréquentes

Pourquoi mon site WordPress ne s’affiche plus alors que je n’ai rien modifié ?

Parce qu’une partie de la chaîne évolue sans vous : mises à jour automatiques des extensions ou du cœur, changement de version de PHP par l’hébergeur, certificat arrivé à échéance, domaine non renouvelé, incident serveur. « Rien modifié » de votre côté ne veut pas dire que rien n’a changé : le journal d’erreurs et l’historique des mises à jour le montrent.

Mon site s’affiche sur mon téléphone mais pas sur mon ordinateur. Est-il en panne ?

Probablement pas. Un site visible sur un réseau et pas sur un autre indique un problème local : DNS mis en cache, IP de votre box bloquée par un pare-feu, cache du navigateur. Testez en navigation privée sur l’ordinateur, puis depuis une autre connexion, avant de toucher au site.

Comment savoir si une extension fait planter WordPress ?

Le journal d’erreurs le dit : un chemin contenant wp-content/plugins/nom-extension/ désigne l’extension. Sans journal, renommez le dossier de l’extension suspecte et rechargez le site. Si le site revient, vous tenez le coupable, mais il faut encore corriger ou remplacer l’extension.

Combien de temps faut-il attendre après un changement de DNS ?

Le temps que les résolveurs oublient l’ancienne réponse, fixé par la durée de vie (TTL) des enregistrements. Selon les réglages, cela va de quelques minutes à plusieurs heures, davantage pour un changement de serveurs de noms. Pendant cette période, il est normal que certains voient l’ancien site et d’autres le nouveau.

Une panne de quelques heures nuit-elle au référencement ?

Une indisponibilité courte n’a généralement pas d’effet durable. Pour une maintenance prévue, un code 503 indique aux robots que l’arrêt est temporaire, et WordPress l’utilise lui-même pendant ses mises à jour. Une panne qui dure plusieurs jours peut en revanche conduire Google à espacer ses visites puis à retirer des pages de son index : surveillez le rapport « Indexation des pages » de la Search Console après le retour du site.