BOOTING NEURAL FEED…
NEWSBOX v0.2 · NEON SPONSOR ↗
← WSZYSTKIE NEWSY
Tech & Dev 75% CONFIDENCE Dev.to Top 14 czerwca 2026 23:04

Site WordPress en panne ou piraté, la procédure que je suis pour diagnostiquer

AUTHOR · Lyode freelance

Votre site WordPress ne répond plus. Écran blanc, message d'erreur, ou pire : des liens vers des pharmacies en ligne qui apparaissent dans Google à votre place. La première réaction est de paniquer et de cliquer partout. C'est exactement ce qu'il ne faut pas faire. Je suis Sébastien, développeur WordPress freelance à Lyon. J'interviens régulièrement sur des sites cassés ou compromis, et dans 90 % des cas, le problème se règle avec une procédure méthodique. Voici celle que je suis, étape par étape. Deux scénarios très différents se cachent derrière "mon site ne marche plus" : La panne technique

Votre site WordPress ne répond plus. Écran blanc, message d'erreur, ou pire : des liens vers des pharmacies en ligne qui apparaissent dans Google à votre place. La première réaction est de paniquer et de cliquer partout. C'est exactement ce qu'il ne faut pas faire. Je suis Sébastien, développeur WordPress freelance à Lyon. J'interviens régulièrement sur des sites cassés ou compromis, et dans 90 % des cas, le problème se règle avec une procédure méthodique. Voici celle que je suis, étape par étape. Deux scénarios très différents se cachent derrière "mon site ne marche plus" : La panne technique : le site affiche une erreur mais personne n'est entré. Souvent une mise à jour, une extension, un fichier corrompu. Le piratage : quelqu'un a injecté du code, créé des pages, ou pris la main. Là, ce n'est plus du dépannage, c'est de la sécurité. On va traiter les deux. Mais d'abord, une règle commune. Avant tout : ne supprimez rien Le réflexe de tout effacer pour "repartir propre" est la pire idée. Vous détruisez les preuves, et si c'est un piratage, vous risquez de garder la faille tout en perdant les traces qui permettent de la trouver. Première action, toujours : faites une sauvegarde de l'état actuel , même cassé. Fichiers et base de données. Via votre hébergeur, FTP, ou en ligne de commande si vous y avez accès : # Sauvegarde de la base de données mysqldump -u UTILISATEUR -p NOM_DE_LA_BASE > backup-avant-intervention.sql # Archive des fichiers tar -czf backup-fichiers.tar.gz /chemin/vers/votre/site Maintenant, on diagnostique. Cas 1 : le site est en panne 1. Est-ce votre site, ou tout l'hébergement ? Avant de plonger dans WordPress, éliminez le plus simple. Si c'est l'hébergeur qui est down, vous allez chercher un bug pour rien. Testez un autre site hébergé au même endroit, s'il y en a un. Vérifiez la page de statut de votre hébergeur (la plupart en ont une). Tapez votre nom de domaine dans un outil comme downforeveryoneorjustme.com pour voir si c'est vous ou tout le monde. Si tout l'hébergement est par terre, contactez le support et passez votre tour. Sinon, on continue. 2. Identifiez le symptôme exact Le message d'erreur est votre meilleur ami. Notez précisément ce que vous voyez : Symptôme Piste la plus probable Écran totalement blanc Erreur PHP fatale, conflit d'extension ou mémoire Erreur 500 Fichier .htaccess , PHP, ou extension qui plante "Erreur de connexion à la base de données" Identifiants DB, serveur MySQL, table corrompue Erreur 403 Permissions de fichiers ou règle de sécurité Site bloqué en "maintenance" Fichier .maintenance laissé après une mise à jour ratée Ce dernier cas est le plus rapide à régler : connectez-vous en FTP, supprimez le fichier .maintenance à la racine du site, et c'est réglé. 3. Activez le mode debug Par défaut, WordPress masque les erreurs aux visiteurs. Pour voir ce qui se passe réellement, ouvrez le fichier wp-config.php (à la racine, via FTP) et ajoutez ces lignes avant la ligne /* That's all, stop editing! */ : define ( 'WP_DEBUG' , true ); define ( 'WP_DEBUG_LOG' , true ); // écrit les erreurs dans un fichier define ( 'WP_DEBUG_DISPLAY' , false ); // ne les affiche pas aux visiteurs Rechargez le site. Les erreurs s'écrivent maintenant dans wp-content/debug.log . Ouvrez-le : la dernière ligne pointe presque toujours vers le fichier ou l'extension fautive. Pensez à remettre WP_DEBUG sur false une fois le problème réglé. On ne laisse jamais le debug actif en production. 4. Désactivez les extensions sans accès à l'admin Si l'admin est inaccessible, vous ne pouvez pas désactiver les extensions depuis le tableau de bord. Passez par le FTP. Renommez le dossier complet des extensions : wp-content/plugins → wp-content/plugins-off Votre site se recharge sans aucune extension. S'il revient à la vie, c'est une extension le coupable. Renommez le dossier à l'identique ( plugins ), puis réactivez les extensions une par une dans l'admin jusqu'à retrouver celle qui casse tout. 5. Repassez sur un thème par

CZYTAJ ŹRÓDŁOWY ARTYKUŁ → WIĘCEJ Z TECH & DEV