Pour nettoyer la base de données WordPress, commencez par une sauvegarde récupérable, identifiez les données devenues inutiles, puis supprimez une catégorie à la fois sur une copie de test. La corbeille et les commentaires indésirables ne demandent pas la même décision que les révisions, les réglages d’une extension ou les commandes d’une boutique. Une donnée ancienne n’est pas forcément une donnée à effacer.
Le bon ordre avant toute suppression
- ProtégerCopie récente et reprise possible
- TrierComprendre chaque catégorie
- VérifierSupprimer par lot, puis tester
Quand le nettoyage de la base est-il utile ?
La base évolue avec le site : publications, modifications, commentaires, réglages et données des extensions. Un nettoyage peut être pertinent lorsqu’un inventaire révèle des contenus à supprimer définitivement, un historique devenu excessif ou des données abandonnées clairement identifiées. Il peut aussi faciliter la maîtrise des sauvegardes et de l’espace disponible.
- Le site reçoit beaucoup de commentaires : examiner le spam et la corbeille.
- Les pages sont régulièrement retravaillées : définir l’historique de révisions à conserver.
- Plusieurs outils ont été remplacés : vérifier ce que leur désinstallation a laissé et pourquoi.
- La base grossit anormalement : identifier la table et le mécanisme responsables avant de vider quoi que ce soit.
En revanche, une base volumineuse ne prouve pas qu’elle ralentit le site. Une boutique active peut stocker beaucoup de données légitimes. Si votre objectif est la vitesse, commencez par identifier ce qui rend WordPress lent : serveur, requêtes, images et scripts ne se corrigent pas de la même façon.
Que contient la base de données WordPress ?
La base conserve des informations organisées en tables : textes des pages, paramètres, utilisateurs et données métier notamment. Les fichiers du site constituent une autre partie de l’installation. Nettoyer la base ne revient donc pas à réduire le poids des images.
Deux éléments complémentaires
Textes, réglages, comptes, commandes et références des médias.
WordPress, thème, extensions et fichiers téléversés, dont les images.
Une pièce jointe possède des informations dans la base, mais son fichier est généralement stocké dans les téléversements. Supprimer uniquement une référence peut casser une relation ; supprimer une image depuis la médiathèque peut aussi supprimer son fichier. Le nettoyage des médias relève d’un autre contrôle.
Ne déduisez pas l’usage d’une table de son nom
Le préfixe des tables n’est pas obligatoirement wp_. Des extensions créent leurs propres tables ; d’autres utilisent celles de WordPress. Une table absente d’une liste « standard » n’est donc pas automatiquement inutile.
Sur une boutique, des commandes peuvent utiliser des tables dédiées selon la configuration. Sur un réseau multisite, les données sont réparties entre plusieurs sites. Dans ces situations, identifiez le périmètre exact avant toute intervention.
Que préparer avant de nettoyer ?
Avant la première suppression, vous devez pouvoir retrouver un état cohérent du site. Le guide pour sauvegarder et restaurer WordPress détaille les copies à prévoir. Une archive présente sur le serveur ne suffit pas si vous ne savez pas la récupérer ou la restaurer.
- Créer une sauvegarde récente : base et fichiers, conservés dans un emplacement accessible si le site tombe.
- Vérifier la restauration : procédure connue et, idéalement, restauration contrôlée sur un environnement isolé.
- Créer une copie de test : sans envoi de vrais e-mails ni paiement réel ; protéger les données qu’elle contient.
- Relever l’état initial : taille de la base, tables principales, catégories et volumes proposés au nettoyage.
- Définir les données à garder : historique éditorial, comptes, commandes, formulaires et réglages indispensables.
Pour un site qui reçoit des commandes ou des demandes pendant l’intervention, prévoyez aussi comment conserver ces nouvelles données. Restaurer toute la base d’hier peut faire disparaître les opérations enregistrées depuis. La copie de test ne dispense pas de préparer l’intervention finale en production.
Quelles données supprimer et lesquelles conserver ?
La bonne décision dépend de l’usage de la donnée et de votre besoin de retour arrière, pas seulement du nombre de lignes. Ce tableau sert à préparer la sélection ; il ne vaut pas autorisation de suppression automatique.
| La catégorie | La décision | Le contrôle utile |
|---|---|---|
| Spam et corbeille | Supprimer après revue | Vérifier qu’aucun commentaire ou contenu à récupérer n’y figure. |
| Révisions | Conserver un historique choisi | Identifier les versions utiles avant d’effacer les plus anciennes. |
| Transients expirés | Nettoyer de façon ciblée | Distinguer les éléments expirés de tous les caches temporaires. |
| Anciennes tables d’extensions | Vérifier avant décision | Identifier leur propriétaire, les dépendances et les données à récupérer. |
| Options et métadonnées inconnues | Conserver tant que non identifiées | Contrôler leur usage avec la documentation ou le développeur concerné. |
| Commandes, comptes, demandes | Préserver les données utiles | Traiter leur conservation dans une procédure métier distincte. |
Exemple pédagogique : vous avez remplacé une extension de réservation. Ses anciennes tables peuvent encore contenir des rendez-vous ou un historique nécessaire. Avant de les supprimer, vérifiez les exports, la reprise des données et l’absence de dépendance avec le système actuel. Le nom de l’ancienne extension n’est pas une preuve suffisante.
Révisions : garder une possibilité de revenir
Les révisions permettent de comparer et restaurer des états antérieurs d’un contenu. Tout effacer retire aussi cette possibilité. La documentation WordPress sur les révisions explique leur rôle et les options de conservation.
Choisissez une règle adaptée à votre travail : conserver les versions récentes et celles encore utiles au projet. Limiter les révisions futures et supprimer l’historique existant sont deux décisions différentes. La sauvegarde automatique d’un brouillon n’est pas non plus une sauvegarde complète du site.
Les transients sont des valeurs temporaires utilisées comme cache. Ils peuvent être recréés par les composants qui les utilisent, et ne sont pas toujours stockés dans la base lorsqu’un cache objet externe est actif. Effacer tous les transients peut provoquer leur reconstruction : ne confondez pas « expirés » et « tous ». Le fonctionnement est décrit dans l’API officielle des transients.
Comment nettoyer la base de données WordPress pas à pas ?
Commencez par les écrans natifs pour les données que vous pouvez relire. Si un outil spécialisé devient nécessaire, utilisez-le pour exécuter une sélection comprise, pas pour décider à votre place. Les étapes suivantes s’effectuent d’abord sur la copie préparée.
1. Relire les corbeilles et les commentaires
Dans Articles ou Pages → Corbeille, examinez les éléments avant de les supprimer définitivement. Dans Commentaires, contrôlez les indésirables et la corbeille. Un commentaire en attente n’est pas automatiquement du spam.
Ne supprimez pas un contenu public uniquement pour alléger la base : sa disparition peut aussi toucher les liens et les visiteurs. Cette décision demande un contrôle éditorial distinct.
Pour les révisions et certains nettoyages techniques, WordPress ne propose pas le même écran de gestion. Un outil comme WP-Optimize peut regrouper ces catégories ; vérifiez les fonctions de la version utilisée avant de l’installer et évitez de multiplier les extensions qui font le même travail.
Du réglage au contrôle : exemple pédagogique
2. Examiner les catégories proposées par l’outil
Ouvrez WP-Optimize → Database (Base de données) → Optimizations (Optimisations). Examinez les catégories et les éléments détectés, selon le pas-à-pas officiel de WP-Optimize. Ne lancez pas toutes les actions présélectionnées.
- Décochez les opérations non retenues : révisions à préserver, suppressions non comprises ou catégories trop larges.
- Choisissez un premier lot limité : par exemple le spam déjà relu, sans toucher aux tables d’extensions.
- Notez ce qui sera effacé : catégorie, volume affiché et date de la sauvegarde disponible.
Ne lancez pas en même temps le cache, la compression d’images et le nettoyage. Vous devez pouvoir relier un problème à une action précise. Une optimisation de structure de table est également différente d’une suppression de données et peut mobiliser le serveur : elle ne se coche pas par réflexe.
3. Exécuter un lot, puis contrôler
Après avoir vérifié que seul le lot voulu reste coché, utilisez le bouton « Run all selected optimizations » (exécuter les optimisations sélectionnées). Relisez le bilan affiché sous les opérations : catégorie traitée et nombre d’éléments signalés, sans l’interpréter comme un gain de vitesse.
Vérifiez ensuite les contenus et fonctions concernés. Si le résultat est cohérent, passez au lot suivant ; sinon, arrêtez et examinez l’écart. Une fois le test validé, préparez l’intervention en production avec une sauvegarde fraîche et un créneau adapté.
Les requêtes SQL trouvées dans un tutoriel ne connaissent ni vos préfixes ni vos extensions. Elles peuvent contourner les mécanismes de suppression et toucher plus de données que prévu. Si une intervention dans phpMyAdmin paraît nécessaire, faites identifier le périmètre par une personne compétente plutôt que de copier une commande DELETE ou DROP TABLE.
Comment traiter les données laissées par une extension ?
Désactiver et désinstaller une extension ne sont pas équivalents. La désactivation peut conserver les réglages pour une réactivation. La désinstallation peut prévoir une suppression, mais son comportement dépend de l’extension et de ses options. Le manuel officiel de désinstallation distingue ces mécanismes.
- Retrouver le propriétaire : extension, thème ou code personnalisé qui a créé la donnée.
- Vérifier l’usage actuel : autre composant, ancien formulaire, archive ou réseau multisite.
- Consulter la procédure de l’éditeur : option de suppression complète, export ou précaution particulière.
- Tester la suppression prévue : sur la copie, en conservant une possibilité de restauration.
Le mot « orphelin » affiché par un outil est une piste à vérifier, pas une preuve universelle d’inutilité. Si l’usage d’une table ou d’une option reste inconnu, conservez-la et faites définir le périmètre d’une assistance WordPress ciblée. Réinstaller une ancienne extension pour déclencher sa désinstallation peut aussi modifier le site : ce n’est pas un raccourci sans risque.
Comment vérifier le résultat après le nettoyage ?
Le premier résultat attendu est un site fonctionnel et des données utiles intactes. La diminution de la base vient ensuite. Reprenez les mêmes contrôles avant et après pour ne pas confondre un chiffre plus petit et une amélioration réelle.
Votre fiche de contrôle, sans gain supposé
Vérifiez la connexion, l’édition d’une page, les formulaires jusqu’à la réception des messages et les fonctions propres au site. Sur une boutique, contrôlez les données de commande et le parcours avec un mode de test adapté, sans paiement réel involontaire.
Une donnée manque ? Ne poursuivez pas le nettoyage. Conservez le compte rendu, comparez avec la copie et préparez une reprise ciblée en protégeant les données reçues depuis l’intervention.
Si vous mesurez une évolution de vitesse, gardez les mêmes pages et des conditions comparables. Une taille identique après suppression n’implique pas nécessairement un échec : l’espace peut rester alloué par le moteur de stockage. Ne lancez pas une opération plus intrusive uniquement pour faire baisser le compteur.
À quelle fréquence entretenir la base ?
Il n’existe pas de fréquence universelle. Un site vitrine peu modifié et une boutique qui enregistre des commandes n’ont pas le même rythme. Commencez par observer les catégories qui s’accumulent et le temps nécessaire pour les vérifier.
- Après le remplacement d’un outil : vérifier les données conservées et leur usage.
- Lors d’une croissance inhabituelle : rechercher la cause plutôt que répéter le nettoyage.
- Dans le suivi régulier : revoir corbeilles, sauvegardes et règle d’historique selon l’activité.
Une automatisation ne se justifie qu’après avoir validé les catégories, les exclusions et la reprise. Pour organiser cet entretien avec les mises à jour et les sauvegardes, consultez ma maintenance WordPress.
Questions fréquentes sur le nettoyage de la base
Peut-on nettoyer sans installer d’extension ?
Oui, pour relire et vider les corbeilles ou gérer les commentaires depuis WordPress. Cela ne couvre pas toutes les données techniques. L’absence d’extension ne rend pas une suppression directe dans la base plus sûre : identifiez d’abord ce qui manque aux outils natifs.
Faut-il supprimer toutes les données autoload ?
Non. Ce mécanisme peut charger des réglages nécessaires au site. Un volume important mérite une analyse de ses propriétaires et de ses usages ; il ne justifie ni l’effacement de toutes les options ni un changement massif de leurs réglages.
Nettoyer la base suffit-il après un piratage ?
Non. Le nettoyage d’entretien ne remplace pas la recherche d’une infection, de ses accès et des fichiers concernés. Si le site est compromis, suivez une procédure de prise en charge d’un site WordPress piraté plutôt que de supprimer seulement les données qui paraissent suspectes.
Pourquoi certaines données temporaires reviennent-elles ?
Une extension ou WordPress peut recréer son cache lorsqu’il en a besoin. Ce retour peut être normal. Si la croissance est excessive, recherchez le composant et son comportement au lieu de programmer des suppressions toujours plus fréquentes.
Sources et documentation
Les mécanismes décrits s’appuient sur les documentations suivantes. Pour les clics et les options, vérifiez toujours la version de l’outil utilisée.
