Comment nettoyer la base de données de son site WordPress pour l’accélérer (transients, révisions, tables orphelines) ?

Un site WordPress qui ralentit alors que le cache est bien configuré et l’hébergement correct : neuf fois sur dix, le coupable se cache dans la base de données. Transients expirés, révisions accumulées, options orphelines chargées à chaque requête. Voici la méthode complète pour nettoyer sans rien casser.

Pourquoi votre base de données grossit sans que vous le voyiez

Chaque plugin installé, chaque article publié, chaque formulaire soumis laisse une trace dans la base de données. C’est normal. Le problème arrive quand ces traces ne sont jamais nettoyées : révisions infinies, transients qui ne s’auto-suppriment pas, tables abandonnées par un plugin désinstallé trois ans plus tôt.

Sur un site de cinq ans avec une trentaine de plugins passés, il n’est pas rare de trouver une base de données de 300 à 800 Mo, dont la moitié est du bruit pur. Chaque requête SQL devient plus lente, chaque sauvegarde plus longue, et le serveur travaille pour rien.

L’autoload wp_options, le vrai responsable

C’est le point que la plupart des tutoriels survolent. La table wp_options stocke les réglages de WordPress et de vos plugins. Chaque ligne porte un attribut autoload : à yes, WordPress charge cette donnée à CHAQUE chargement de page, même si elle ne sert qu’une fois par mois.

Un plugin mal codé qui stocke un cache de 2 Mo en autoload, et c’est 2 Mo chargés en mémoire sur chaque page vue, y compris pour un visiteur qui ne passe que sur votre page d’accueil. C’est souvent plus impactant que les révisions ou les transients réunis.

Pour mesurer le poids réel de l’autoload, exécutez cette requête via phpMyAdmin ou WP-CLI :

Au-dessus de 1 Mo d’autoload total, le site souffre. Au-dessus de 3 Mo, c’est un signal d’alarme. Chaque option suspecte identifiée doit être recherchée par son nom pour retrouver le plugin propriétaire avant toute suppression.

Nettoyer les transients expirés

Les transients sont un cache temporaire natif de WordPress : ils sont censés disparaître seuls à expiration. En pratique, si un utilisateur ne visite jamais la page qui déclenche leur suppression automatique, ils restent en base indéfiniment. Certains plugins de flux RSS, de météo ou de réseaux sociaux en génèrent des centaines.

1. Vérifier l’accès WP-CLISi votre hébergement le propose (LWS, o2switch, WP Engine, etc.), c’est la méthode la plus sûre et la plus rapide.
2. Supprimer les transients expirésCommande wp transient delete --expired. Ne touche qu’aux transients arrivés à échéance, sans risque pour le site.
3. Vider les transients orphelins sans WP-CLISans accès en ligne de commande, un plugin dédié comme WP-Optimize ou Advanced Database Cleaner fait le travail via une interface, en gardant une trace de ce qui a été supprimé.
4. Recontrôler l’autoload après nettoyageRelancez la requête de mesure de l’autoload : un nettoyage de transients efficace fait souvent baisser le poids autoloadé de 20 à 40 %.

Maîtriser les révisions d’articles

Par défaut, WordPress enregistre une révision à chaque sauvegarde automatique ou manuelle d’un article. Sur un article travaillé sur plusieurs jours, cela peut représenter 50 à 100 révisions stockées pour un seul contenu publié. Multipliez par le nombre d’articles du site : la table wp_posts gonfle rapidement.

La bonne pratique n’est pas de tout supprimer une fois, mais de plafonner ce comportement dans la durée. Dans le fichier wp-config.php, ajoutez avant la ligne /* C'est tout, ne touchez pas à ce qui suit ! */ :

define('WP_POST_REVISIONS', 5);

Cette limite conserve les cinq dernières versions d’un article, suffisant pour revenir en arrière en cas d’erreur, sans accumulation infinie. Pour l’existant, WP-CLI supprime les révisions déjà en base avec une boucle ciblée, ou un plugin de nettoyage traite la purge en une passe.

Identifier et supprimer les tables orphelines

Chaque désinstallation de plugin ne nettoie pas forcément ses propres tables. Un plugin de formulaire remplacé il y a deux ans peut laisser trois tables vides ou obsolètes dans votre base. Elles ne ralentissent pas directement le site, mais alourdissent les sauvegardes et compliquent la maintenance.

Pour les repérer, listez les tables via phpMyAdmin et comparez leur préfixe aux plugins réellement actifs. Une table dont le nom ne correspond à aucun plugin installé est une candidate à la suppression, à condition de vérifier au préalable qu’elle n’est pas utilisée par une intégration tierce (CRM, outil marketing).

Méthode pas à pas, sans risque

1. Sauvegarder avant toute interventionBase de données complète, via votre hébergeur ou un plugin comme UpdraftPlus. Sans exception.
2. Mesurer l’état initialPoids de la base, poids de l’autoload, nombre de révisions et de transients. Ces chiffres serviront de référence après nettoyage.
3. Nettoyer par ordre de risque croissantTransients expirés d’abord (sans risque), puis révisions en excès, puis options orphelines identifiées individuellement, enfin tables orphelines confirmées.
4. Vérifier le site après chaque étapeNaviguez sur les pages clés, testez les formulaires, contrôlez le panier si c’est un site e-commerce.
5. Optimiser les tablesUne fois le ménage fait, une commande OPTIMIZE TABLE (ou l’équivalent dans votre plugin de cache) récupère l’espace disque libéré par InnoDB.

Prévenir plutôt que nettoyer tous les six mois

Le nettoyage ponctuel soulage, mais sans discipline en amont, la base regrossit en quelques mois. Trois réflexes limitent durablement l’accumulation : plafonner les révisions dès l’installation du site, désinstaller proprement les plugins abandonnés (et pas seulement les désactiver), et programmer une purge mensuelle automatique des transients expirés via une tâche cron ou l’Action Scheduler de WooCommerce si vous êtes en e-commerce.

Un audit technique complet permet aussi de repérer les plugins responsables d’un autoload excessif avant qu’ils ne deviennent un problème. C’est un des points que je vérifie systématiquement lors d’un audit SEO technique WordPress, au même titre que le cache et la configuration serveur.

En résumé

Une base de données WordPress propre, ce n’est pas un plugin qu’on installe et qu’on oublie. C’est une méthode : mesurer l’autoload, traiter les transients et les révisions dans l’ordre, vérifier avant et après chaque étape, puis verrouiller les réglages pour que le problème ne revienne pas. Combiné à un bon plugin de cache comme WP Rocket ou LiteSpeed Cache, ce nettoyage a un impact direct et mesurable sur le TTFB, donc sur vos Core Web Vitals côté serveur.