Nettoyer une base WordPress après des années d’extensions

Ce que contient réellement une base après des années d’usage

Un site WordPress de plusieurs années, passé par de nombreuses extensions installées puis désinstallées, accumule dans sa base des éléments que personne n’a jamais nettoyés. Les extensions bien conçues suppriment leurs propres tables à la désinstallation ; beaucoup ne le font pas, et laissent des tables orphelines qui continuent d’exister sans qu’aucun code actif ne les lise. La table wp_posts accumule aussi les révisions de contenu : chaque enregistrement automatique ou sauvegarde manuelle d’un article crée une nouvelle ligne, jamais purgée par défaut. Les transients, un mécanisme de cache temporaire stocké dans wp_options, expirent logiquement mais restent souvent en base bien après leur expiration si rien ne les purge.

Les métadonnées orphelines suivent la même logique : quand un article, un produit ou un client est supprimé, les lignes correspondantes de wp_postmeta ou wp_usermeta ne le sont pas toujours en même temps, surtout si la suppression est passée par une requête directe en base plutôt que par l’interface WordPress. Ces lignes orphelines n’affichent jamais rien, mais elles gonflent la base sans raison.

Le point le plus coûteux en performance est souvent le moins visible : les options marquées autoload dans wp_options. Ce sont des réglages que WordPress charge intégralement en mémoire à chaque chargement de page, quel que soit le besoin réel de cette page. Sur un site ancien, cette table peut atteindre plusieurs mégaoctets d’options autoload, chargés à chaque requête même sur une simple page produit qui n’en a besoin d’aucune.