Ce guide concerne les sites WordPress auto-hébergés. Toute intervention nécessite les droits adaptés et un retour arrière fiable. Sans expérience des fichiers, bases de données et hébergements, coordonnez le diagnostic avec votre hébergeur ou prestataire.
Consigner les observations
Notez l’URL, le message exact, le premier horaire observé avec fuseau et la dernière modification. Comparez accueil, autre page et connexion. Consignez les essais : un seul chargement échoué ne prouve pas une panne générale.
Sauvegarde et retour arrière
Avant intervention, préservez fichiers et base de données si possible, ainsi que les sauvegardes antérieures. Vérifiez dates et restauration. Une copie défectueuse ou infectée peut servir à l’enquête : protégez-la séparément et ne la considérez pas comme saine.
Modifiez un seul élément et retestez la même action. Préférez une copie de test pour les essais de thèmes, extensions et configurations. Désactiver ne signifie pas supprimer ; boutique, formulaires et sécurité peuvent être affectés. Documentez l’état initial et le retour arrière.
Diagnostic ciblé
01
Isoler la requête
Comparez accueil, autre page, connexion et action exacte : enregistrement, envoi ou téléversement. Avant de répéter un formulaire ou une commande, vérifiez si le traitement a déjà eu lieu.
02
Lire le bon journal
Le code 500 ne donne pas la cause. Transmettez URL, heure, fuseau et éventuel identifiant de requête. Fichier PHP, mémoire et directive serveur indiquent des pistes différentes. Vérifiez journal et service intermédiaire en l’absence d’entrée.
03
Vérifier extensions, thème et PHP
Comparez le début avec mises à jour, code personnalisé et changements PHP. Testez le composant suspect sur une copie. Augmenter la mémoire n’explique pas une consommation croissante ; vérifiez cause et limites.
04
Préserver les règles serveur
Une directive .htaccess invalide peut affecter Apache ; Nginx seul ne lit pas ce fichier. Le remplacer aveuglément peut supprimer protections et redirections. Faites contrôler la règle précise avec l’hébergeur.
05
Examiner droits et ressources
Propriétaires de fichiers, permissions, espace et traitement PHP doivent correspondre à l’hébergement. Une autorisation générale 777 n’est pas une réparation. Retestez la requête puis les autres fonctions après correction.
Évaluer la restauration
Une sauvegarde ne remplace pas l’analyse de la cause. Vérifiez-la d’abord en environnement isolé si possible. Restaurer peut effacer des commandes, demandes et contenus récents. Convenez du périmètre ; après piratage, ne réimportez pas de fichiers actuels sans contrôle.
Tester après correction
Contrôlez l’URL initiale, l’accueil, les autres pages et la connexion. Testez formulaires et boutique en environnement adapté, sans commandes réelles involontaires. Videz uniquement les caches concernés après correction. Consignez cause et résultat.
Quand demander de l’aide
Arrêtez les modifications si la cause reste inconnue, si le retour arrière est incertain ou si des fonctions critiques sont touchées. Les indices malveillants exigent une enquête de sécurité. Ne publiez ni journaux complets, ni accès, clés ou liens de récupération.
Convenir du périmètre et du coût →Maintenance après réparation
Le cœur WordPress, les extensions et les thèmes sont mis à jour chaque semaine, sans laisser les tâches courantes repousser les mises à jour essentielles. Mensuelles, quotidiennes ou horaires : les sauvegardes dépendent de l’offre et sont stockées sur des serveurs dans l’UE.
Les réparations et le nettoyage de sites déjà piratés sont des prestations distinctes. Les licences payantes ne sont pas incluses.