Site WordPress en panne : être alerté tout de suite et savoir quoi faire

Pourquoi un site WordPress tombe sans prévenir

WordPress est solide, mais un site WordPress, c'est rarement WordPress seul. C'est un thème, une quinzaine d'extensions écrites par autant d'auteurs différents, une base de données, un hébergement mutualisé partagé avec d'autres sites, et souvent un cache par-dessus. Chaque pièce peut casser l'ensemble, et la plupart des pannes suivent un changement :

• Une mise à jour d'extension ou de thème, automatique ou non, incompatible avec le reste du site ou avec la version de PHP.
• Un changement de version de PHP fait par l'hébergeur, qui casse une vieille extension.
• Une base de données saturée ou arrêtée, fréquent sur les hébergements mutualisés aux heures de pointe.
• Une mise à jour interrompue, qui laisse le site bloqué en mode maintenance.
• Un quota dépassé : espace disque plein, limite de mémoire PHP atteinte.
• Un certificat HTTPS ou un nom de domaine expiré, parce que le renouvellement automatique a échoué ou que la carte bancaire enregistrée a expiré.

Dans tous ces cas, le serveur de l'hébergeur va très bien. Personne ne te préviendra, sauf un visiteur, s'il prend la peine de le faire.

Les solutions installées dans WordPress ne suffisent pas

Le premier réflexe, quand on utilise WordPress, est de chercher une extension. Il en existe, et WordPress a même son propre système d'alerte. Mais tous ont la même faiblesse : ils tournent dans le site qu'ils sont censés surveiller.

L'email « Votre site rencontre un problème technique »

Depuis la version 5.2, quand une extension ou un thème provoque une erreur fatale, WordPress affiche un message d'erreur aux visiteurs et envoie un email à l'adresse d'administration du site, avec un lien pour se connecter en « mode de récupération ». C'est utile, mais limité :

• Il ne couvre que les erreurs fatales en PHP. Une base de données arrêtée, un serveur qui ne répond plus, un certificat expiré, un nom de domaine perdu : pas d'email.
• L'email est envoyé par le site lui-même, donc par le serveur qui vient de planter. Sur beaucoup d'hébergements, ces emails arrivent en spam, ou n'arrivent pas.
• Il part à l'adresse d'administration réglée dans WordPress, souvent une vieille adresse ou celle de l'agence qui a créé le site il y a cinq ans.
• WordPress limite ces envois : au plus un email par jour, même si une autre extension plante entre-temps.

Les extensions de surveillance

Une extension qui vérifie la disponibilité depuis l'intérieur du site a un problème de fond : quand le site tombe, elle tombe avec lui. Elle ne peut pas te dire que la base de données ne répond plus, puisqu'elle a besoin de la base de données pour fonctionner.

Les extensions qui marchent vraiment, comme le module de surveillance de Jetpack, ne font en réalité que connecter ton site à un service externe : ce sont les serveurs de ce service qui vérifient ton site, pas l'extension. C'est une option valable si tu utilises déjà Jetpack. Mais l'extension elle-même n'est qu'un raccourci d'installation : ce qui compte, c'est la vérification externe.

Le piège du cache : un site « en ligne » qui ne marche plus

C'est la particularité de WordPress qui trompe le plus de monde. La plupart des sites utilisent une extension de cache (WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache…) ou un cache chez l'hébergeur. Le principe : au lieu de reconstruire chaque page avec PHP et la base de données, le serveur garde une copie toute prête et la sert directement.

Conséquence : si la base de données tombe, la page d'accueil en cache continue de s'afficher normalement, avec un code 200. Une surveillance qui ne regarde que la page d'accueil reste au vert. Pendant ce temps, tout ce qui a besoin de PHP est cassé : le formulaire de contact, la connexion, le panier, les pages qui ne sont pas encore en cache.

La parade : surveiller aussi une page qui ne passe jamais par le cache, et qui oblige WordPress à se charger entièrement, base de données comprise. Deux bons candidats :

• La page de connexion, https://www.monsite.fr/wp-login.php. Les extensions de cache ne la mettent pas en cache, et elle renvoie une erreur si PHP ou la base de données ne répondent plus. Si tu as caché cette page avec une extension de sécurité (WPS Hide Login, par exemple), elle renvoie une erreur 404 : surveille alors ta nouvelle adresse de connexion à la place.
• La page panier d'une boutique WooCommerce (/panier/), que les extensions de cache excluent en général d'elles-mêmes. C'est aussi la page qui compte le plus pour une boutique.

Garde quand même une surveillance sur la page d'accueil : c'est elle qui tombe en cas de problème de serveur, de certificat ou de nom de domaine, et c'est celle que voient tes visiteurs.

Ce que la surveillance voit selon la panne

Chaque panne WordPress se traduit par un code de réponse HTTP différent. C'est ce code, ou son absence, que la surveillance détecte, et c'est lui qui t'indique où chercher.

Réparer selon le message affiché

Avant tout : confirme la panne depuis un autre réseau (ton téléphone en 4G, Wi-Fi coupé, ou l'outil gratuit Site en panne ?), et regarde la page de statut de ton hébergeur. Si la panne vient de chez lui, tu n'as rien à réparer, seulement à attendre et à informer. Ensuite, selon le message :

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

Une extension ou un thème provoque une erreur fatale. Si tu as reçu l'email de WordPress, il contient le nom de l'extension en cause et un lien vers le mode de récupération : connecte-toi avec ce lien et désactive l'extension. Sans l'email :

1. Connecte-toi en FTP ou avec le gestionnaire de fichiers de ton hébergeur.
2. Dans wp-content/plugins/, renomme le dossier de la dernière extension mise à jour (par exemple woocommerce en woocommerce-off). WordPress la désactive automatiquement.
3. Recharge le site. S'il revient, tu as trouvé le coupable. Sinon, remets le nom d'origine et essaie avec l'extension suivante.

Si tu ne sais pas quelle extension a changé, active le journal d'erreurs. Dans wp-config.php, remplace la ligne define( 'WP_DEBUG', false ); par ces trois lignes (la définir une seconde fois plus bas ne marcherait pas : c'est la première qui compte) :

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

Recharge la page en erreur, puis ouvre wp-content/debug.log : la dernière erreur « Fatal error » indique le fichier en cause, donc l'extension. Pense à remettre WP_DEBUG à false une fois le problème réglé.

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

WordPress n'arrive pas à joindre sa base de données. Trois causes possibles, de la plus fréquente à la plus rare :

• Le serveur de base de données est surchargé ou arrêté. C'est souvent temporaire sur un hébergement mutualisé. Regarde la page de statut de ton hébergeur ; si rien n'y est signalé et que ça dure, contacte son support.
• Les identifiants ont changé, par exemple après un changement de mot de passe de la base dans l'espace client de l'hébergeur. Compare DB_NAME, DB_USER, DB_PASSWORD et DB_HOST dans wp-config.php avec les informations de ton espace client.
• La base est abîmée. Plus rare. L'hébergeur propose en général un outil de réparation, et WordPress en a un aussi (à activer temporairement dans wp-config.php avec define( 'WP_ALLOW_REPAIR', true );, puis à ouvrir à l'adresse /wp-admin/maint/repair.php). Retire la ligne juste après : tant qu'elle est en place, n'importe qui peut ouvrir cette page sans se connecter.

« Brièvement indisponible pour cause de maintenance planifiée »

Pendant une mise à jour, WordPress crée un fichier .maintenance à la racine du site et affiche ce message. Normalement, il le supprime à la fin. Si la mise à jour a été interrompue (délai dépassé, onglet fermé, serveur trop lent), le fichier reste, et le site aussi.

La solution : supprime le fichier .maintenance à la racine du site, par FTP ou avec le gestionnaire de fichiers (c'est un fichier caché, active l'affichage des fichiers cachés si tu ne le vois pas). Puis relance la mise à jour qui avait échoué, depuis le tableau de bord.

« Internal Server Error » (erreur 500 sans message WordPress)

Deux suspects habituels :

• Le fichier .htaccess, modifié par une extension. Renomme-le en .htaccess-old et recharge le site. S'il revient, va dans Réglages → Permaliens et clique sur Enregistrer les modifications sans rien changer : WordPress recrée un fichier propre.
• La limite de mémoire PHP (le site peut alors afficher aussi le message d'erreur critique). Le journal d'erreurs (voir plus haut) contient « Allowed memory size exhausted ». Augmente la limite dans l'espace client de ton hébergeur, ou ajoute define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php, dans la limite de ce que ton hébergement autorise.

Erreur 502 ou 504

Le serveur web n'a pas obtenu de réponse de PHP à temps. Si c'est ponctuel, c'est souvent un pic de trafic ou une tâche lourde (sauvegarde, import). Si ça se répète, cherche une extension qui fait des traitements lourds à chaque visite, ou demande à ton hébergeur si ton site atteint les limites de son offre.

Redirection en boucle

Souvent après un passage en HTTPS ou l'ajout d'un service comme Cloudflare. Vérifie dans Réglages → Général que l'adresse de WordPress et l'adresse du site sont identiques et commencent par https://. Si tu utilises Cloudflare, le mode SSL « Flexible » provoque souvent cette boucle : passe-le en « Full » si ton hébergement a un certificat.

Certificat expiré, nom de domaine expiré

Les certificats gratuits (Let's Encrypt) se renouvellent normalement tout seuls chez l'hébergeur. Quand ça échoue, c'est souvent à cause d'un changement DNS. Relance l'émission du certificat depuis l'espace client de ton hébergeur. Pour le nom de domaine, renouvelle-le chez ton registrar, active le renouvellement automatique, et vérifie la carte bancaire enregistrée. C'est une panne bête et pourtant fréquente.

Surveiller ton site WordPress avec Pinguro, pas à pas

Voici une mise en place adaptée à WordPress avec le plan gratuit de Pinguro. Il n'y a rien à installer sur ton site. Compte cinq minutes.

1. Crée ton compte

Sur pinguro.app/dashboard, ouvre l'onglet Inscription, saisis ton email et un mot de passe (8 caractères minimum), puis clique sur Créer mon compte. Confirme ton adresse avec le lien reçu par email, puis connecte-toi. Pas de carte bancaire.

2. Surveille la page d'accueil

Dans Monitors, clique sur + Ajouter un monitor. Le type HTTP / HTTPS est sélectionné par défaut. Donne-lui un nom clair (« Site, accueil »), colle l'adresse complète de ton site avec https://, laisse l'intervalle de 15 minutes et clique sur Ajouter. La première vérification part dans la minute qui suit.

Chaque vérification suit jusqu'à 5 redirections et attend un code 2xx sur la page finale. Si le site ne répond pas en 10 secondes, ou en cas d'erreur réseau, un nouvel essai est fait 2 secondes plus tard avant de déclarer la panne. Un certificat HTTPS expiré ou invalide fait aussi passer le monitor en panne.

3. Surveille une page qui contourne le cache

Ajoute un deuxième monitor sur https://www.monsite.fr/wp-login.php (ou ta page de connexion personnalisée, ou la page panier de ta boutique), comme expliqué plus haut. C'est lui qui détectera une base de données en panne même quand la page d'accueil reste servie par le cache. L'adresse surveillée n'apparaît pas sur ta page de statut : seul le nom du monitor y est affiché.

4. Vérifie que l'alerte arrive

À l'inscription, un canal email vers l'adresse de ton compte est créé automatiquement. Dans Alertes, le bouton Tester t'envoie un email d'essai : vérifie qu'il arrive bien, et pas dans les spams. Si c'est un prestataire qui s'occupe du site, ajoute son adresse : il devra la confirmer avant de recevoir les alertes.

En cas de panne, l'email indique la raison (par exemple « Code HTTP 500 (attendu 200–299) »), ce qui te renvoie directement au bon paragraphe de la section précédente. Un second email te prévient quand le site revient.

5. Déclare tes mises à jour comme maintenances

Pendant une grosse mise à jour, ton site affiche le message de maintenance de WordPress (code 503) pendant quelques secondes ou quelques minutes. Pour éviter une alerte inutile, déclare une fenêtre dans Maintenance avant de lancer les mises à jour. Pendant cette fenêtre, Pinguro continue de vérifier ton site mais n'envoie pas d'alerte, et ces vérifications ne comptent pas dans ta disponibilité. Si le site est toujours en panne à la fin de la fenêtre (la mise à jour a cassé quelque chose, ou le fichier .maintenance est resté), l'alerte part à la vérification suivante.

6. Publie ta page de statut (facultatif)

Dans Page de statut, choisis un identifiant puis clique sur Créer la page. Pendant une panne, tes clients y voient que le problème est connu, au lieu de t'écrire. Pour savoir quoi y afficher et comment rédiger un message d'incident, voir le guide Status page publique : ce que tes clients attendent vraiment.

Ce que le plan gratuit ne fait pas

• Vérification toutes les 15 minutes au plus court : une panne peut mettre jusqu'à un quart d'heure à être détectée.
• Pas de vérification de contenu (mot-clé attendu ou interdit dans la page). C'est pour ça que ce guide passe par une page qui contourne le cache plutôt que par la recherche d'un message d'erreur.
• Pas d'alerte avant l'expiration du certificat : la panne est détectée quand le certificat a expiré, pas avant.
• Alertes par email uniquement : Slack, Discord, Telegram et webhook sont prévus avec les plans payants, qui ne sont pas encore ouverts. Pour les brancher sans être noyé de messages, voir Alerte Slack, Discord ou Telegram quand ton site tombe.

Les 3 monitors permettent par exemple de surveiller la page d'accueil, la page de connexion, et une sauvegarde automatique avec un monitor Heartbeat / Cron (voir Monitorer un cron job). Pour une vue d'ensemble des offres gratuites, y compris celles d'autres services, voir Surveiller son site web gratuitement.

Réduire le risque de panne

La surveillance te prévient vite. Quelques habitudes évitent d'en avoir besoin :

• Mets à jour les extensions une par une, et regarde le site après chacune. Si ça casse, tu sais tout de suite laquelle.
• Évite de tout mettre à jour le vendredi soir, ou juste avant de partir en congés.
• Garde une sauvegarde récente, stockée ailleurs que chez ton hébergeur, et vérifie au moins une fois qu'elle se restaure.
• Supprime les extensions inutilisées : moins d'extensions, moins de risques de conflit (et de failles de sécurité).
• Sur un site important, teste les mises à jour sur une copie (beaucoup d'hébergeurs proposent un site de préproduction en un clic).
• Vérifie la version de PHP annoncée par ton hébergeur avant un changement, et la compatibilité de tes extensions.

Questions fréquentes

Faut-il installer une extension pour surveiller WordPress ?

Non. Une surveillance externe ouvre ton site comme un visiteur, depuis un autre serveur. Il n'y a rien à installer, et elle continue de fonctionner quand WordPress est complètement en panne, ce qu'une extension ne peut pas faire.

Comment savoir si mon site WordPress est en panne pour tout le monde ?

Ouvre-le depuis un autre réseau, par exemple ton téléphone avec le Wi-Fi coupé, et en navigation privée pour éviter ton propre cache. Pense aussi que tu es peut-être connecté à l'administration : certaines extensions de cache servent une page différente aux administrateurs. Un service de surveillance externe règle la question : il vérifie depuis ailleurs, et garde la trace de ce qu'il a vu.

Mon site est hébergé chez un spécialiste WordPress, ai-je besoin d'une surveillance ?

Les hébergeurs spécialisés surveillent leurs serveurs, souvent très bien. Mais une extension en erreur, un nom de domaine expiré ou une mauvaise manipulation DNS ne sont pas des pannes de serveur, et ce sont justement les plus fréquentes. Une surveillance externe voit ce que voient tes visiteurs, quelle qu'en soit la cause.

La surveillance ralentit-elle mon site ?

Non. Une vérification toutes les 15 minutes, c'est l'équivalent d'un visiteur qui charge une page de temps en temps. C'est négligeable, même sur un petit hébergement mutualisé.

Ça marche avec WooCommerce, Elementor, Divi ou un site multisite ?

Oui. La surveillance ne dépend ni du thème ni des extensions : elle regarde la réponse de ton site. Pour une boutique WooCommerce, la page panier est un très bon choix de deuxième monitor. Pour un multisite, surveille chaque site important séparément.

Conclusion

Un site WordPress tombe presque toujours après un changement : une mise à jour, un réglage, un renouvellement oublié. Ces pannes se réparent en général en quelques minutes, à condition de les connaître. Ce qui coûte cher, ce sont les heures pendant lesquelles personne ne sait.

Une surveillance externe sur la page d'accueil, une deuxième sur une page qui contourne le cache, une adresse email que tu lis vraiment, et ce guide sous la main : c'est suffisant pour ne plus apprendre une panne par un client.