WordPress n'efface presque jamais rien par lui-même. Chaque modification d'article, chaque notification temporaire mise en cache, chaque commentaire indésirable laisse une trace dans la base de données, qui continue de grossir sans qu'on s'en rende compte. Au bout de plusieurs mois ou années d'utilisation, cette accumulation finit par ralentir les requêtes, même sur un site qui n'a pas gagné beaucoup de contenu réel.
Les révisions d'articles
Par défaut, WordPress enregistre une nouvelle ligne dans la table wp_posts (avec le type revision) à chaque sauvegarde automatique ou manuelle d'un article, sans limite de nombre. Un article édité des dizaines de fois peut ainsi accumuler des dizaines de révisions, chacune stockant une copie complète du contenu. La constante WP_POST_REVISIONS dans wp-config.php permet de limiter ce nombre, et un nettoyage ponctuel des révisions existantes via WP-CLI (wp post delete $(wp post list --post_type=revision --format=ids)) ou un plugin dédié libère souvent un espace surprenant.
Les transients expirés
Les transients sont des données temporaires mises en cache par WordPress ou ses extensions dans la table wp_options, avec une date d'expiration. En théorie, WordPress les supprime automatiquement une fois expirés ; en pratique, de nombreux transients orphelins s'accumulent, surtout quand un plugin est désinstallé sans que ses données temporaires soient nettoyées. La commande wp transient delete --all via WP-CLI, ou un plugin de nettoyage, permet de purger ces entrées périmées sans risque pour le contenu réel du site.
Les éléments mis à la corbeille et les commentaires indésirables
- Les articles et pages à la corbeille restent en base indéfiniment jusqu'à suppression définitive manuelle.
- Les commentaires marqués comme spam ou déplacés en corbeille s'accumulent de la même façon.
- Les brouillons automatiques (auto-draft) générés par l'éditeur lors de chaque nouvelle page ouverte, même jamais publiée, restent eux aussi en base.
Un nettoyage régulier de ces catégories, via l'interface d'administration ou en masse via WP-CLI, évite qu'elles ne représentent une part significative du volume total de la base au fil du temps.
Comment procéder sans risque
- Faites toujours une sauvegarde complète de la base avant tout nettoyage en masse.
- Commencez par les catégories les plus sûres à nettoyer : transients expirés, corbeille, spam.
- Pour les révisions, conservez-en un nombre raisonnable plutôt que de tout supprimer, au cas où vous auriez besoin de revenir à une version antérieure d'un contenu.
- Utilisez l'outil d'optimisation de table intégré à phpMyAdmin (ou wp db optimize via WP-CLI) après le nettoyage, pour que la base récupère réellement l'espace disque libéré.
Le cas particulier d'une boutique WooCommerce
Sur un site e-commerce sous WooCommerce, deux sources de bloat s'ajoutent à celles d'un site WordPress classique :
- La table wp_woocommerce_sessions, qui conserve les paniers de visiteurs non connectés, y compris pour des visiteurs qui ne reviendront jamais finaliser leur achat. Une tâche planifiée de nettoyage des sessions expirées, intégrée à WooCommerce, s'en charge normalement, mais vaut la peine d'être vérifiée si le volume de commandes est important.
- Les métadonnées de commande, stockées dans wp_postmeta, qui s'accumulent proportionnellement au volume de ventes et peuvent devenir volumineuses sur une boutique avec plusieurs années d'historique.
Pour ce type de site, un nettoyage régulier de la base devient encore plus pertinent qu'un simple site vitrine, à mesure que le volume de transactions augmente.
Après un nettoyage en masse de plusieurs milliers de lignes, exécuter l'instruction OPTIMIZE TABLE sur les tables concernées (ou son équivalent via wp db optimize en WP-CLI) reste une étape à ne pas négliger : la suppression de lignes libère de l'espace logique, mais la table ne récupère cet espace disque physiquement que lorsque ce réassemblage interne est exécuté explicitement par le moteur de base de données.
À quelle fréquence faut-il nettoyer la base de données WordPress ?
Il n'existe pas de règle universelle, mais un nettoyage trimestriel ou semestriel suffit généralement pour un site de taille moyenne, sauf activité très intense (forte fréquence de publication, beaucoup de commentaires) qui justifie un nettoyage plus rapproché.
Le nettoyage peut-il casser mon site ?
Un nettoyage mal ciblé (suppression de tables actives par erreur, outil mal configuré) peut effectivement poser problème. C'est pour cela qu'une sauvegarde préalable reste la règle numéro un avant toute opération de maintenance sur la base.
Automatiser ce type de maintenance régulière reste plus fiable qu'y penser manuellement de temps en temps. Les offres d'hébergement WordPress de VSP TECH, combinées à une solution de sauvegarde automatique comme CodeGuard, permettent de nettoyer la base en toute sécurité, avec un point de restauration disponible en cas d'erreur.
