La structure de la base de données WordPress

WordPress et presque tous les Plugins stockent leurs réglages dans un emplacement unique sur ton serveur appelé la « base de données ». Les données stockées dans la base de données sont organisées dans ce qu’on appelle des « tables ». Cet article explique en détail la signification de tous les champs disponibles dans la structure par défaut de la base de données WordPress.

TL;DR : WordPress stocke la plupart des données du site dans une base de données MySQL ou MariaDB. Une installation WordPress standard sur un seul site utilise actuellement 12 tables par défaut avec un préfixe configurable, généralement wp_. Ces tables stockent les articles, pages, utilisateurs, réglages, commentaires, termes de taxonomie et métadonnées, tandis que les Plugins, Themes, WooCommerce et les installations multisite peuvent ajouter des tables supplémentaires.

Remarque : Pour inspecter ta base de données WordPress en toute sécurité, sauvegarde ton site ou crée un environnement de staging avec WP STAGING. Utilise ensuite un outil de gestion de base de données, comme phpMyAdmin ou Adminer, pour accéder et modifier la base de données sans impacter ton site en production.

Les tables de la base de données WordPress en un coup d’œil

Une installation WordPress standard sur un seul site utilise actuellement 12 tables de base de données par défaut. Le tableau ci-dessous résume ce que chaque table stocke, comment WordPress l’utilise, et ce qui peut se casser si la table est manquante ou corrompue.

Table	Stocke	Utilisée pour	Ce qui se casse si manquante ou corrompue
wp_options	URL du site, Plugins actifs, réglages du Theme, transients, règles de réécriture, données cron	Bootstrap WordPress, réglages des Plugins, configuration du site	Redirections vers une mauvaise URL, réglages manquants, échecs de Plugins, cron cassé, options autoloadées lentes
wp_posts	Articles, pages, pièces jointes, révisions, menus, types de contenu personnalisés	Contenu, médiathèque, menus de navigation, nombreux types de données de Plugins	Pages/articles/médias manquants, menus cassés, entrées de types de contenu personnalisés manquantes
wp_postmeta	Métadonnées pour les articles, pages, pièces jointes, produits, constructeurs de pages, Plugins SEO	Images à la une, données produits, champs SEO, mises en page de constructeurs	Images manquantes, mises en page cassées, données produits manquantes, métadonnées SEO incomplètes
wp_users	Comptes utilisateurs, identifiants, hachages de mots de passe, emails, noms d’affichage	Authentification et paternité	Les utilisateurs ne peuvent pas se connecter, les auteurs disparaissent
wp_usermeta	Rôles utilisateurs, capacités, champs de profil, réglages utilisateurs des Plugins	Permissions et réglages spécifiques aux utilisateurs	L’administrateur perd ses permissions, les rôles disparaissent, les réglages utilisateurs se cassent
wp_comments	Commentaires, pingbacks, trackbacks, avis	Systèmes de commentaires et d’avis	Les commentaires ou avis disparaissent
wp_commentmeta	Métadonnées pour les commentaires et avis	Statut spam, notes, données de commentaires des Plugins	Métadonnées d’avis, données spam ou données de commentaires de Plugins perdues
wp_terms	Noms et slugs des termes	Catégories, étiquettes, catégories de liens, termes de taxonomie personnalisés	Les noms des catégories et étiquettes disparaissent
wp_termmeta	Métadonnées pour les termes de taxonomie	Images de termes, métadonnées SEO, champs de termes personnalisés	Les métadonnées catégorie/étiquette disparaissent
wp_term_taxonomy	Type de taxonomie, relation parent, compteurs de termes	Distingue catégorie, étiquette et taxonomie personnalisée	Les catégories/étiquettes se mappent incorrectement ou perdent leur hiérarchie
wp_term_relationships	Relations entre le contenu et les termes de taxonomie	Assigne les articles/produits/pages aux catégories et étiquettes	Les articles perdent leurs catégories/étiquettes, les menus et relations de taxonomie se cassent
wp_links	Données héritées du gestionnaire de blogroll/liens	Fonctionnalité de gestionnaire de liens dépréciée et anciens Plugins	Généralement rien sur les sites modernes, sauf si un vieux Plugin l’utilise encore

À quoi ressemblent les tables de la base de données ?

Imagine une feuille Excel avec une ligne d’en-tête et des valeurs dans la ligne en dessous.

Par exemple, tu peux voir ici une petite section de la table wp_options :

Parlons de ces tables plus en profondeur pour comprendre pourquoi il est essentiel de savoir quelle table est responsable du contenu d’un site WordPress.

Comprendre la structure des tables t’aidera à savoir quelle table tu dois inclure ou exclure si tu prévois de synchroniser ou de déplacer des données d’un site de staging vers le site en production (ou inversement) avec WP STAGING. C’est aussi utile si tu prévois de mettre à jour le site de staging.

Cela devient encore plus important avec WordPress 7.0 et les versions ultérieures. La table wp_collaboration prévue stocke des données de collaboration en temps réel dans l’éditeur, qui sont généralement temporaires et spécifiques à l’environnement. Lors du push d’un site de staging vers la production, évite d’écraser l’état actif de collaboration du site en production, sauf si tu veux intentionnellement remplacer toute la base de données.

Liste des tables WordPress core

Le tableau ci-dessus donne un aperçu rapide. La section suivante explique les tables WordPress core plus en détail pour les développeurs, propriétaires de sites et toute personne déboguant des migrations, Backups ou problèmes de base de données.

• wp_options
• wp_users,
• wp_usermeta
• wp_posts
• wp_postmeta
• wp_terms
• wp_term_relationships
• wp_term_taxonomy
• wp_termmeta
• wp_comments
• wp_commentmeta
• wp_links

WordPress peut ajouter de nouvelles tables core lors des versions majeures. Par exemple, WordPress 7.0 est prévu pour introduire `wp_collaboration` pour les données de collaboration en temps réel dans l’éditeur.

Les autres tables de ta base de données sont créées par des Plugins ou des Themes et ne sont pas toujours nécessaires au bon fonctionnement du site.

wp_options

La table wp_options est l’une des tables de base de données WordPress les plus essentielles et stocke tous les réglages d’un site WordPress, comme l’URL, le titre, les Plugins installés, etc. La plupart des Plugins y stockent également leurs réglages.

Tous les réglages du tableau de bord WordPress sont stockés dans cette table.

wp_users,
wp_usermeta

wp_users stocke tous les utilisateurs enregistrés sur un site WordPress. Elle contient des informations de base sur un utilisateur, comme un nom d’utilisateur et mot de passe chiffré, email, heure d’inscription, nom d’affichage, statut et quelques autres champs.

wp_usermeta stocke les métadonnées (« données supplémentaires ») des utilisateurs. Elle étend la table wp_users avec plus de données. Par exemple, le prénom d’un utilisateur est stocké dans la table wp_usermeta et non dans la table wp_users.

Il y a deux champs nécessaires dans cette table. Les Plugins peuvent stocker des données personnalisées dans wp_usermeta en ajoutant simplement une nouvelle valeur dans le champ meta_key.

wp_posts,
wp_postmeta

La table wp_posts stocke toutes les données liées au contenu d’un site WordPress. Tous les articles, pages et leurs révisions sont disponibles dans la table wp_posts. Cela peut ne pas être évident, mais WordPress y stocke bien plus encore.

Cette table contient également les éléments de menu de navigation, les fichiers médias, les pièces jointes comme les images et les données de contenu utilisées par les Plugins.

Dans wp_posts, il y a une colonne post_type qui segmente ces différents types de données afin qu’une requête de base de données puisse demander des types de données spécifiques. post_type est la colonne la plus importante de cette table.

Dans les images ci-dessous, tu peux voir deux post_types différents, revision et attachment, stockés dans la même table wp_posts :

La table wp_postmeta, tout comme la table wp_usermeta, étend la table wp_posts avec plus de données, qui peuvent également être utilisées par d’autres Plugins.

Par exemple, le populaire Plugin Yoast SEO stocke des balises Open Graph personnalisées, des articles et des données d’URL dans cette table.

wp_terms,
wp_term_relationships,
wp_term_taxonomy,
wp_termmeta

La table wp_terms stocke les catégories et étiquettes des articles, pages et liens.

L’une des colonnes de cette table est « slug ». Un slug est un terme qui reflète une étiquette d’un article particulier. Dans WordPress, tu peux utiliser des étiquettes pour relier des articles, pages et liens.

wp_term_relationships est la jonction qui relie ces étiquettes aux articles, pages et liens. C’est comme une carte entre les objets de termes et les termes.

wp_term_taxonomy étend la table wp_terms avec plus de données. C’est comme des métadonnées pour la table wp_terms, à la différence que les Plugins ne peuvent pas y ajouter de données personnalisées. Cette table contient également une relation entre les menus et les éléments de menu.

La table wp_termmeta stocke les métadonnées pour les termes de taxonomie. Elle fonctionne de manière similaire à wp_postmeta, wp_usermeta et wp_commentmeta, mais pour les catégories, étiquettes et termes de taxonomie personnalisés.

Les Plugins et Themes peuvent utiliser cette table pour stocker des données supplémentaires pour les termes, comme des images de catégories, des métadonnées SEO, des couleurs personnalisées, des réglages d’affichage ou d’autres champs spécifiques à la taxonomie.

Si cette table est manquante ou incomplète après une migration, les catégories et étiquettes peuvent encore exister, mais leurs métadonnées supplémentaires peuvent être perdues.

wp_comments,
wp_commentmeta

wp_comments stocke les commentaires sur les articles et pages. Cette table contient également les commentaires non approuvés et les informations sur les auteurs, ainsi que la hiérarchie des commentaires. La table wp_commentmeta contient d’autres métadonnées sur les commentaires.

wp_links

Cette table contient des informations sur les liens personnalisés ajoutés à ton site. Elle est dépréciée et n’est plus utilisée. Quelques vieux Plugins l’utilisent encore, mais c’est généralement une table vide.

Table WordPress 7.0 à venir : wp_collaboration

`wp_collaboration` est une nouvelle table de base de données WordPress core prévue pour WordPress 7.0. Elle fait partie de la fonctionnalité de collaboration en temps réel dans l’éditeur de blocs, qui permet à plusieurs utilisateurs de modifier le même article ou la même page en même temps.

Les premières versions bêta de WordPress 7.0 stockaient les données de synchronisation liées à la collaboration dans le stockage des articles et post meta. Cela créait des problèmes de performance car l’activité en temps réel de l’éditeur peut écrire des données très fréquemment. Chaque mise à jour de post meta peut invalider les caches d’objets liés aux articles, ce qui peut réduire l’efficacité du cache d’objets persistant pendant qu’une session d’édition est ouverte.

La nouvelle table `wp_collaboration` sépare les données de collaboration à haute fréquence des tables de contenu régulières comme `wp_posts` et `wp_postmeta`. Son but est de stocker les données de synchronisation temporaires utilisées par l’éditeur, telles que les mises à jour d’édition collaborative, les identifiants de clients/sessions, les informations de salles et les horodatages utilisés pour le nettoyage.

Cette table ne **remplace pas** `wp_posts`, `wp_postmeta` ou le système de révisions de WordPress. Les articles, pages, pièces jointes, types de contenu personnalisés et révisions sont toujours stockés dans `wp_posts` ; les métadonnées spécifiques aux articles restent dans `wp_postmeta`.

Pour les Backups et migrations, traite `wp_collaboration` différemment des tables de contenu permanent. Un Backup complet de la base de données doit l’inclure, mais lors du push d’un site de staging vers la production, cette table n’a généralement pas besoin d’écraser le site en production car elle stocke des données de collaboration/session éphémères plutôt que du contenu de site canonique. WordPress peut recréer l’état de collaboration au fur et à mesure que les utilisateurs éditent le contenu.

Important : bien que les données soient temporaires, elles peuvent toujours contenir des charges utiles de synchronisation d’éditeur liées à du contenu en cours. Ne les traite pas comme publiques ou jetables du point de vue de la confidentialité et de la sécurité.

Remarque : le schéma final peut encore changer avant la sortie de WordPress 7.0. Lors du développement, les propositions publiques pour `wp_collaboration` ont inclus des champs comme un ID auto-incrémenté, un identifiant de salle, des identifiants client/utilisateur, une charge utile de données et un horodatage GMT. Les tests récents explorent également le stockage des données de présence/conscience dans une table séparée `wp_presence`. Vérifie le schéma de base de données final de WordPress 7.0 avant de publier la liste exacte des colonnes.

Structure graphique de la base de données WordPress

Ce diagramme montre comment les tables WordPress sont connectées :

Ouvrir l’image en pleine résolution : Clic droit → Ouvrir l’image dans un nouvel onglet

Problèmes courants de base de données WordPress et les tables concernées

Problème	Table(s) la(les) plus pertinente(s)	Quoi vérifier
Le site redirige vers le mauvais domaine après migration	wp_options	Vérifier siteurl, home et les options sérialisées des Plugins
L’utilisateur administrateur existe mais n’a pas les droits admin	wp_usermeta	Vérifier la clé des capacités, surtout après avoir changé le préfixe de table
Les articles existent mais les catégories ou étiquettes sont manquantes	wp_terms, wp_term_taxonomy, wp_term_relationships	Vérifier si toutes les tables de taxonomie ont été migrées ensemble
Les entrées de la médiathèque existent mais les images sont cassées	wp_posts, wp_postmeta, dossier uploads	Les pièces jointes sont stockées dans wp_posts ; les chemins de fichiers sont souvent stockés dans _wp_attached_file dans wp_postmeta
Les menus disparaissent après migration	wp_posts, wp_terms, wp_term_relationships, wp_postmeta	Les menus de navigation sont stockés dans plusieurs tables
Les réglages de Plugins disparaissent	wp_options, parfois des tables spécifiques au Plugin	Vérifier si le Plugin stocke ses réglages dans wp_options ou dans des tables personnalisées
Le site devient lent après migration	wp_options, wp_postmeta	Vérifier les options autoloadées et les grandes tables de métadonnées
Les commentaires ou avis disparaissent	wp_comments, wp_commentmeta	Migrer les deux tables ensemble
WordPress indique qu’une table n’existe pas	wp-config.php, toutes les tables préfixées	Vérifier $table_prefix et si toutes les tables utilisent le même préfixe

Articles connexes

• Les données sérialisées, qu’est-ce que c’est et pourquoi c’est si important ?
• Comment fusionner le site de staging avec la production en conservant les articles et le contenu généré par les utilisateurs
• Actions et filtres
• Comment sauvegarder ton Theme WordPress en toute sécurité
• Où WooCommerce stocke-t-il les produits dans la base de données ?
• Augmenter la taille max_allowed_packet