Nettoyer et optimiser la base de données WordPress proprement

Avec le temps, une base de données WordPress prend du poids. Les révisions s’accumulent, les transients expirent, les commentaires indésirables traînent, les extensions supprimées laissent des options, et certaines tables deviennent plus volumineuses que nécessaire.

Le vieux réflexe consiste à ouvrir phpMyAdmin et à lancer quelques requêtes SQL trouvées sur un blog. Mauvaise idée. Ça peut fonctionner sur un petit site, mais ça peut aussi casser des données légitimes. Aujourd’hui, on nettoie plutôt une base WordPress avec méthode : sauvegarde, audit, WP-CLI, staging, puis optimisation.

Voici une méthode propre pour faire maigrir une base WordPress sans jouer au chirurgien avec des moufles.

Avant de nettoyer : sauvegardez la base de données

Avant toute suppression, exportez la base. Ce n’est pas une précaution décorative. C’est votre bouton “annuler”.

wp db export before-db-cleanup.sqlCode language: JavaScript (javascript)

Si vous administrez le serveur en root, adaptez selon votre environnement :

wp db export before-db-cleanup.sql --allow-rootCode language: JavaScript (javascript)

Ensuite, vérifiez que l’export existe bien :

ls -lh before-db-cleanup.sqlCode language: CSS (css)

Sur un site client, je recommande aussi de tester les suppressions sur un environnement de staging. Une base WordPress contient souvent des données métiers : commandes WooCommerce, abonnements, champs ACF, logs, formulaires, options SEO, traductions, règles de prix, caches applicatifs. Bref, pas seulement des miettes.

Mesurer la taille de la base WordPress

Commencez par identifier les tables les plus lourdes. WP-CLI permet de le faire rapidement :

wp db size --tables --human-readable

Pour afficher les tables WordPress :

wp db tables

Sur beaucoup de sites, les coupables reviennent souvent : wp_options, wp_postmeta, wp_posts, wp_commentmeta, les tables WooCommerce, les tables de statistiques, les logs, ou les anciennes tables de plugins supprimés.

Si votre problème vient surtout des requêtes lentes, ne confondez pas nettoyage et optimisation applicative. Dans ce cas, mesurez aussi les requêtes SQL générées par le thème et les extensions. J’ai détaillé cette approche dans ce guide sur la réduction des requêtes SQL des thèmes WordPress.

Nettoyer les transients expirés

Les transients stockent temporairement des données en cache. WordPress les utilise, mais les extensions aussi. Quand ils expirent, ils peuvent rester dans la base, notamment dans wp_options.

Évitez de supprimer tous les transients à la main avec une requête SQL large. Préférez WP-CLI :

wp transient delete --expiredCode language: JavaScript (javascript)

Sur un multisite, vous pouvez aussi nettoyer les transients réseau :

wp transient delete --expired --networkCode language: JavaScript (javascript)

Supprimer tous les transients peut être utile après une migration, un changement de domaine, ou un problème de cache. Toutefois, cela force WordPress et les plugins à les recréer. Sur un gros site, faites-le hors pic de trafic :

wp transient delete --allCode language: JavaScript (javascript)

Nettoyer les révisions d’articles

WordPress stocke les révisions dans la table wp_posts. C’est pratique pour restaurer une ancienne version, mais les gros sites éditoriaux peuvent accumuler des milliers de révisions.

Pour compter les révisions :

wp post list --post_type=revision --format=countCode language: PHP (php)

Pour supprimer toutes les révisions :

wp post delete $(wp post list --post_type=revision --format=ids) --forceCode language: JavaScript (javascript)

Cette commande est efficace, mais elle ne garde aucune révision. Sur un site éditorial actif, je préfère limiter les révisions futures plutôt que supprimer l’historique en permanence.

Dans wp-config.php, vous pouvez limiter le nombre de révisions conservées par contenu :

define( 'WP_POST_REVISIONS', 10 );Code language: JavaScript (javascript)

Ne désactivez pas totalement les révisions sur un site où plusieurs personnes écrivent. Le jour où quelqu’un écrase un article, vous serez content de ne pas avoir optimisé votre filet de sécurité à la tronçonneuse.

Supprimer les commentaires indésirables et la corbeille

Les commentaires en spam et en corbeille peuvent gonfler wp_comments et wp_commentmeta. WP-CLI permet de les supprimer proprement.

Compter les commentaires indésirables :

wp comment list --status=spam --format=countCode language: PHP (php)

Supprimer les commentaires indésirables :

wp comment delete $(wp comment list --status=spam --format=ids) --forceCode language: JavaScript (javascript)

Supprimer les commentaires déjà dans la corbeille :

wp comment delete $(wp comment list --status=trash --format=ids) --forceCode language: JavaScript (javascript)

Si la commande ne retourne aucun ID, WP-CLI peut afficher une erreur parce qu’il n’a rien à supprimer. Ce n’est pas grave. Cela veut simplement dire que la cave est déjà vide.

Nettoyer les métadonnées orphelines

Les tables wp_postmeta, wp_commentmeta, wp_usermeta et wp_termmeta peuvent contenir des données orphelines. Cela arrive après des suppressions massives, des migrations, ou des extensions mal désinstallées.

Vous pouvez repérer les métadonnées d’articles orphelines avec cette requête :

wp db query "
SELECT COUNT(*) AS orphaned_postmeta
FROM $(wp db prefix)postmeta pm
LEFT JOIN $(wp db prefix)posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
"Code language: PHP (php)

Pour les supprimer :

wp db query "
DELETE pm
FROM $(wp db prefix)postmeta pm
LEFT JOIN $(wp db prefix)posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
"Code language: PHP (php)

Même logique pour wp_commentmeta :

wp db query "
DELETE cm
FROM $(wp db prefix)commentmeta cm
LEFT JOIN $(wp db prefix)comments c ON c.comment_ID = cm.comment_id
WHERE c.comment_ID IS NULL;
"Code language: PHP (php)

Ces requêtes sont plus sûres que les anciennes suppressions basées uniquement sur meta_key. Elles suppriment des lignes sans parent réel, pas des données encore reliées à un contenu.

Faire attention à wp_options et aux options autoloadées

La table wp_options mérite une attention particulière. WordPress charge automatiquement certaines options à chaque requête. Si trop de données sont marquées en autoload, le site peut ralentir avant même d’avoir commencé à travailler.

Pour afficher les plus grosses options autoloadées :

wp db query "
SELECT option_name, LENGTH(option_value) AS size
FROM $(wp db prefix)options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 30;
"Code language: PHP (php)

Ne supprimez pas une option uniquement parce qu’elle est grosse. Identifiez d’abord son origine. Une option peut appartenir au thème, à WooCommerce, à un plugin de cache, à un plugin SEO, à un builder, ou à un système de licence.

Pour trouver les options laissées par une extension supprimée, utilisez plutôt une recherche ciblée. Par exemple :

wp option list --field=option_name | grep -i "nom_du_plugin"Code language: PHP (php)

J’ai détaillé cette logique dans ce guide pour identifier les options de base de données liées aux plugins WordPress.

Supprimer les tables laissées par d’anciens plugins

Certaines extensions créent leurs propres tables. C’est normal pour WooCommerce, les formulaires, les statistiques, les logs, les plugins multilingues ou les systèmes de cache. Le problème arrive quand une extension supprimée laisse ses tables derrière elle.

Listez les tables :

wp db tables

Ensuite, cherchez les préfixes suspects. Par exemple, après une suppression de WPML, Elementor ou Jetpack, il faut souvent vérifier si des options, métadonnées ou tables dédiées restent en base.

J’ai déjà documenté ces cas séparément :

• Désinstaller proprement WPML et nettoyer la base de données avec WP-CLI
• Supprimer Elementor de la base WordPress
• Désinstaller Jetpack proprement avec WP-CLI

Ne supprimez jamais une table inconnue sans vérifier son origine. Sur WooCommerce, par exemple, une table peut contenir des commandes, des journaux, des sessions, des permissions de téléchargement ou des données HPOS.

Optimiser les tables WordPress

Après le nettoyage, vous pouvez optimiser les tables :

wp db optimize

Cette commande utilise les identifiants de base de données définis dans wp-config.php. Elle lance l’équivalent d’une optimisation MySQL via WP-CLI.

Sur des tables InnoDB modernes, l’effet varie selon le moteur, le volume supprimé et l’hébergement. Ne promettez pas des miracles. Mesurez avant et après. Si une table MyISAM traîne encore sur un vieux site, envisagez une conversion propre vers InnoDB. J’ai publié un guide dédié : convertir les tables WordPress de MyISAM à InnoDB avec WP-CLI.

Faut-il utiliser un plugin de nettoyage ?

Oui, si vous préférez une interface graphique. Un plugin de nettoyage peut supprimer les révisions, brouillons automatiques, commentaires indésirables, transients expirés et données orphelines. C’est pratique sur un site sans accès SSH.

Cependant, évitez d’installer cinq extensions “d’optimisation” en même temps. Elles risquent de nettoyer la base, ajouter leurs propres options, charger une interface lourde, programmer des tâches cron et finir par faire ce qu’elles prétendent combattre. Très WordPress, finalement.

Sur un site professionnel, je préfère cette hiérarchie :

1. WP-CLI si vous avez un accès SSH.
2. Un plugin fiable si vous n’avez pas d’accès serveur.
3. Des requêtes SQL manuelles uniquement si vous savez exactement ce que vous supprimez.

Checklist de nettoyage WordPress

• Exporter la base avec wp db export.
• Tester sur un environnement de staging.
• Mesurer la taille des tables avec wp db size --tables --human-readable.
• Nettoyer les transients expirés avec wp transient delete --expired.
• Supprimer les commentaires spam et corbeille.
• Limiter les révisions futures avec WP_POST_REVISIONS.
• Supprimer les métadonnées orphelines seulement après vérification.
• Identifier les options laissées par les plugins supprimés.
• Vérifier les tables personnalisées avant toute suppression.
• Optimiser la base avec wp db optimize.
• Tester le site : front, back-office, formulaires, recherche, panier, paiement, comptes clients.

Commandes WP-CLI utiles pour nettoyer WordPress

# Sauvegarder la base.
wp db export before-db-cleanup.sql

# Voir la taille des tables.
wp db size --tables --human-readable

# Supprimer les transients expirés.
wp transient delete --expired

# Compter les révisions.
wp post list --post_type=revision --format=count

# Supprimer les révisions.
wp post delete $(wp post list --post_type=revision --format=ids) --force

# Supprimer les commentaires spam.
wp comment delete $(wp comment list --status=spam --format=ids) --force

# Supprimer les commentaires en corbeille.
wp comment delete $(wp comment list --status=trash --format=ids) --force

# Optimiser la base.
wp db optimizeCode language: PHP (php)

Ce qu’il ne faut plus faire

Je déconseille désormais les suppressions SQL trop générales du type :

DELETE FROM wp_options WHERE option_name LIKE '_transient_%';Code language: JavaScript (javascript)

Ce genre de requête ne tient pas compte du contexte WordPress, du multisite, du cache objet, ni des extensions qui utilisent les transients pour des données temporaires importantes. Utilisez plutôt WP-CLI ou les fonctions WordPress.

Je déconseille aussi de supprimer massivement des lignes dans wp_postmeta uniquement parce que leur meta_key “semble inutile”. Certaines clés techniques ont l’air moches, mais elles servent vraiment. WordPress n’a jamais promis d’être élégant en base. Juste fonctionnel.

Nettoyage ou performance : ne mélangez pas tout

Nettoyer la base peut améliorer la maintenance, réduire les sauvegardes et accélérer certaines opérations. Mais si votre site est lent, le problème peut venir d’ailleurs : thème mal optimisé, requêtes SQL répétées, absence de cache, hébergement trop limité, extensions trop lourdes, ou appels externes bloquants.

Pour compléter ce nettoyage, lisez aussi ce guide sur le cache WordPress et ce tutoriel sur la réduction des requêtes SQL des thèmes.

FAQ : nettoyage de base de données WordPress

Est-ce dangereux de nettoyer la base WordPress ?

Oui, si vous supprimez des données sans comprendre leur rôle. Sauvegardez la base, testez sur staging, puis utilisez WP-CLI ou un plugin fiable. Les requêtes SQL directes doivent rester ciblées.

Puis-je supprimer toutes les révisions WordPress ?

Techniquement oui, mais ce n’est pas toujours souhaitable. Sur un site éditorial, gardez quelques révisions. Vous pouvez limiter les prochaines révisions avec WP_POST_REVISIONS.

Faut-il supprimer tous les transients ?

Pas en routine. Supprimez d’abord les transients expirés avec wp transient delete --expired. Supprimer tous les transients peut être utile après une migration ou un incident de cache, mais cela peut générer une charge temporaire.

Quelle table WordPress ralentit le plus souvent le site ?

Il n’y a pas de coupable universel. Sur les sites classiques, wp_options et wp_postmeta posent souvent problème. Sur WooCommerce, les tables de commandes, sessions, actions planifiées et métadonnées peuvent aussi devenir lourdes.

Un plugin de nettoyage suffit-il ?

Pour un petit site, souvent oui. Pour un site WooCommerce, multilingue, fortement personnalisé ou très fréquenté, un audit manuel reste préférable. Un plugin ne connaît pas toujours votre logique métier.

Sources

• Documentation WP-CLI : wp db
• Documentation WP-CLI : wp db optimize
• Documentation WP-CLI : wp transient delete
• Documentation WordPress : delete_expired_transients()
• Documentation WordPress : révisions
• Documentation WP-CLI : wp post delete
• Documentation WP-CLI : wp comment delete

Report a typo