Contexte
Un site WordPress d’un indépendant à Nyon est passé en erreur 500 après une mise à jour d’extensions. L’admin n’était plus accessible et la page d’accueil renvoyait un écran blanc selon les navigateurs. L’objectif prioritaire était de remettre le site en ligne rapidement, puis de corriger la cause et de stabiliser l’exploitation.
Objectifs
- Rétablir l’accès au site et à l’administration sans perte de contenu.
- Identifier la cause (conflit d’extensions, thème, version PHP, mémoire).
- Mettre en place une base d’exploitation: sauvegardes vérifiables, monitoring, mises à jour cadrées.
- Contrôler l’impact SEO et la mesure (Search Console, GA4).
Diagnostic
- Symptôme : erreur 500 côté serveur, admin inaccessible.
- Hypothèses prioritaires : conflit d’extensions, incompatibilité PHP, mémoire insuffisante, erreur fatale dans le thème.
- Vérifications : logs PHP, santé WordPress, test de désactivation sélective des extensions, contrôle du thème actif.
Intervention
La remise en ligne a été faite en deux temps: d’abord restaurer un accès stable, ensuite isoler la cause exacte et appliquer un correctif durable. Les actions ont été testées sur les pages critiques (accueil, services, contact) et sur l’envoi de formulaire.
1) Récupération rapide (accès et visibilité)
- Activation du mode debug contrôlé pour identifier l’erreur fatale.
- Désactivation ciblée d’extensions suspectes jusqu’au retour du front et de l’admin.
- Vérification des permissions fichiers et de la version PHP active.
2) Correction de la cause
- Isolation du conflit (une extension et un module de cache entraient en collision après mise à jour).
- Remplacement par une configuration plus sobre, puis tests de compatibilité.
- Nettoyage des charges inutiles sur les pages non concernées.
3) Stabilisation et exploitation
- Mise en place de sauvegardes planifiées et test de restauration sur copie.
- Monitoring de disponibilité (uptime) et alertes en cas d’incident.
- Routine de mises à jour: fenêtre, sauvegarde préalable, contrôle post-déploiement.
4) Contrôles SEO et mesure
- Contrôle Search Console: erreurs d’exploration, pages affectées, statut d’indexation.
- Vérification GA4: continuité du tracking et événements clés (clic téléphone, formulaire).
- Analyse rapide des pages les plus visitées pour prioriser les optimisations.
Exemple technique : désactiver toutes les extensions via WP-CLI (récupération)
Utile quand l’admin est inaccessible. À exécuter à la racine WordPress, sur le bon environnement.
wp plugin deactivate --all
wp theme list
wp plugin list --status=active
Exemple technique : réactiver progressivement et trouver l’extension fautive
Approche pragmatique: réactiver par lots, puis affiner.
wp plugin activate plugin-a plugin-b plugin-c
wp plugin activate plugin-d
wp plugin deactivate plugin-d
Exemple technique : mu-plugin de secours pour bloquer une extension précise
Alternative propre si WP-CLI n’est pas disponible. Créer un fichier dans wp-content/mu-plugins/ (ex. cc-safe-mode.php).
<?php
/**
* MU-plugin: bloque une extension précise en cas de conflit.
* Adapter la valeur $blocked au slug exact du plugin.
*/
add_filter('option_active_plugins', function ($plugins) {
$blocked = 'plugin-problematique/plugin-problematique.php';
if (!is_array($plugins)) {
return $plugins;
}
return array_values(array_filter($plugins, function ($p) use ($blocked) {
return $p !== $blocked;
}));
});
Résultats observés
- Remise en ligne rapide du site et récupération de l’accès admin.
- Cause identifiée et corrigée, avec une configuration plus stable.
- Réduction du risque de récidive grâce aux sauvegardes, au monitoring et à une routine de mises à jour.
- Contrôle post-incident côté SEO et analytics, avec continuité de la mesure.
Points clés à retenir
- En cas d’erreur 500, la priorité est de rétablir un accès, puis d’isoler la cause méthodiquement.
- WP-CLI et un mu-plugin de secours sont deux leviers très efficaces pour récupérer un site.
- Une exploitation cadrée (sauvegardes testées, monitoring, mises à jour contrôlées) évite la majorité des incidents.