Dans l’administration de WordPress, le bouton « Télécharger le fichier d’export » est rassurant. Quelques secondes plus tard, un fichier XML se trouve sur l’ordinateur. Il porte le nom du site, une date et parfois plusieurs mégaoctets. On pourrait croire que le blog est désormais à l’abri.
Ce fichier est utile, mais ce n’est pas une copie autonome de l’installation. Il transporte surtout des contenus et leurs relations. Il ne recrée pas à lui seul le thème, les extensions, la configuration du serveur, la base complète ni tous les fichiers de la médiathèque.
Je préfère donc lui donner un rôle précis : le WXR sert à déplacer, archiver ou contrôler le patrimoine éditorial. La sauvegarde complète sert à reconstruire le site. Les deux se complètent ; les confondre crée une fausse sécurité.
La réponse courte
L’outil Outils → Exporter produit un fichier XML au format WXR, pour WordPress eXtended RSS. Selon la sélection, il décrit les articles, pages, commentaires, champs personnalisés, catégories, étiquettes, menus et autres types de contenu.
Il ne contient pas automatiquement :
- les fichiers PHP du cœur, du thème et des extensions ;
wp-config.php,.htaccesset la configuration du serveur ;- une copie binaire autonome de chaque image ou document ;
- les tables complètes de la base de données ;
- les données conservées par des services externes ;
- la preuve qu’un import aboutira sans erreur.
Pour pouvoir restaurer un WordPress classique, la documentation d’administration de WordPress distingue deux éléments : les fichiers du site et la base de données. Le WXR constitue une troisième pièce utile pour la portabilité éditoriale, pas un remplacement de ces deux éléments.
Trois objets, trois usages
| Objet | Ce qu’il protège principalement | Usage normal | Limite essentielle |
|---|---|---|---|
| WXR XML | contenus et relations éditoriales | transfert, archive lisible, import sélectif | ne reconstruit pas l’installation |
| export SQL | tables de la base | restauration ou migration de la base | ne contient pas les fichiers |
| copie des fichiers | code, configuration, thèmes, extensions, médias | reconstruction du système de fichiers | ne contient généralement pas la base |
Une sauvegarde complète associe donc une copie de la base et une copie des fichiers créées à des instants proches. Un export WXR ajouté au même ensemble facilite les contrôles et les migrations de contenu, mais il ne dispense pas de conserver le reste.
Ce que WordPress place dans le WXR
La documentation officielle de l’écran Exporter énumère notamment les articles, pages, types de contenu personnalisés, commentaires, champs personnalisés, catégories, étiquettes, taxonomies et auteurs.
L’option « Tout le contenu » inclut également les termes et les menus de navigation. Les filtres permettent de limiter l’export aux articles ou aux pages, à un auteur, une période, un statut ou une catégorie.
Cette structure est précieuse pour plusieurs raisons :
- le titre, le corps et l’extrait restent associés au contenu ;
- les dates, statuts et relations de taxonomie peuvent être transportés ;
- les commentaires et certaines métadonnées suivent les publications ;
- le fichier reste inspectable comme du texte structuré ;
- un lot éditorial peut être exporté sans copier toute l’installation.
Mais « inclus dans le XML » ne signifie pas « reproduit exactement par n’importe quel site cible ». Un champ personnalisé n’a de sens que si le thème ou l’extension qui l’utilise existe encore et sait l’interpréter.
Les médias : références avant d’être des copies
Le WXR peut contenir des entrées de pièces jointes et leurs URL. L’extension officielle WordPress Importer sait importer des pièces jointes depuis wp:attachment_url lorsque l’option correspondante est autorisée.
Cela suppose toutefois que le fichier distant soit encore accessible au moment de l’import. Si le site source a disparu, si une protection bloque les requêtes ou si une URL a changé, le XML ne peut pas fabriquer l’image manquante.
Avant une fermeture ou une migration, je conserve donc séparément :
- le WXR ;
- le répertoire des téléversements, généralement sous
wp-content/uploads; - un inventaire de quelques médias représentatifs ;
- le rapport d’un import d’essai.
Le contrôle doit porter sur une image récente, une ancienne, un PDF, une image mise en avant et un fichier dont le nom contient des espaces ou des caractères accentués. Une seule miniature réussie ne prouve pas que toute la médiathèque a suivi.
Ce que le WXR ne sait pas reconstruire
Un site WordPress est le résultat d’un assemblage. Le contenu compte, mais son rendu et son fonctionnement dépendent aussi du code et de la configuration.
Le fichier d’export ne suffit pas à retrouver :
- la version exacte du thème et ses fichiers personnalisés ;
- les extensions, leurs dépendances et leurs licences ;
- les règles de cache, de redirection ou de sécurité du serveur ;
- les tâches planifiées au niveau système ;
- les certificats, secrets et variables d’environnement ;
- les journaux utiles au diagnostic ;
- les données stockées uniquement chez un prestataire externe ;
- certaines tables créées par des extensions.
Même des éléments visibles peuvent dépendre d’une extension absente : bloc propriétaire, formulaire, galerie, constructeur de page, code court ou champ SEO. Le texte est bien importé, mais la page peut rester incomplète.
Construire une fiche avant d’exporter
Un export sans contexte vieillit mal. Dans six mois, son nom ne dira plus quelle version du site il représente ni pourquoi il a été créé.
J’ajoute un petit fichier texte au même dossier :
| Champ | Exemple de valeur à noter |
|---|---|
| date et heure | avec fuseau horaire |
| URL source | domaine canonique au moment de l’export |
| version WordPress | valeur affichée dans Santé du site |
| périmètre WXR | tout le contenu, articles ou pages filtrés |
| fichier SQL associé | nom et date du dump |
| copie de fichiers associée | archive ou instantané correspondant |
| site cible de test | environnement isolé utilisé |
| résultat | import complet, erreurs, médias manquants |
Cette fiche transforme trois fichiers anonymes en un ensemble compréhensible. Elle évite aussi d’importer par erreur une archive partielle à la place de la sauvegarde attendue.
Exporter tout ou découper le contenu
Pour un petit site, « Tout le contenu » est le point de départ le plus simple. Pour un catalogue ancien ou très volumineux, plusieurs exports par type, date ou statut peuvent rendre l’import plus contrôlable.
Le découpage apporte cependant un nouveau risque : oublier une tranche ou l’importer deux fois. Je conserve alors un tableau avec le filtre, la période, le nom du fichier et sa taille.
Une variation de taille n’est pas automatiquement une erreur. Un article modifié, un commentaire ajouté ou une métadonnée peut changer le XML. En revanche, un fichier vide, anormalement petit ou interrompu doit être considéré comme suspect jusqu’à son ouverture et son test.
Pour les environnements administrés en ligne de commande, la commande officielle wp db export produit un export SQL de la base. Elle ne doit pas être confondue avec l’export WXR : le format, le périmètre et la procédure de restauration sont différents.
Vérifier le fichier sans le modifier
Une première vérification locale reste volontairement simple :
- le fichier existe et sa taille n’est pas nulle ;
- son extension est
.xml; - il s’ouvre dans un éditeur de texte capable de gérer sa taille ;
- le début identifie un document XML et un export WordPress ;
- quelques titres récents et anciens sont retrouvés par recherche ;
- les URL du domaine source sont cohérentes ;
- le fichier est copié vers un stockage distinct.
Je ne corrige pas manuellement le XML original. Si une adaptation d’URL est nécessaire pour un test, je travaille sur une copie et je note la transformation appliquée. L’archive brute reste intacte.
Une somme de contrôle peut également montrer qu’un fichier n’a pas changé pendant un transfert. Elle prouve l’identité des octets entre deux copies, pas la capacité de WordPress à les importer.
Tester l’import dans un site isolé
Le contrôle réellement utile se déroule sur un WordPress de test, jamais sur la production. La documentation Importer décrit l’import WordPress et l’option de téléchargement des pièces jointes.
Avant l’essai, je note :
- la version de WordPress du site cible ;
- les extensions et le thème volontairement installés ;
- la limite de taille des fichiers envoyés ;
- les auteurs existants ;
- l’état initial du nombre d’articles, pages, commentaires et médias.
Après l’import, je compare :
- un article publié et un brouillon ;
- une page avec une hiérarchie ;
- un contenu contenant une image mise en avant ;
- des catégories et étiquettes ;
- un commentaire ;
- un menu ;
- un bloc ou code court dépendant d’une extension ;
- les erreurs consignées par l’importateur.
Le but n’est pas d’obtenir une copie visuelle parfaite avec le WXR seul. Il est de mesurer ce que le fichier transporte réellement et ce qui exige les autres éléments de sauvegarde.
Quand le WXR est le bon outil
Le WXR est particulièrement adapté pour :
- déplacer une sélection d’articles vers une nouvelle installation ;
- archiver le texte et les métadonnées éditoriales dans un format structuré ;
- séparer un site en plusieurs projets ;
- contrôler qu’un export contient bien un ensemble de publications ;
- préparer un environnement de test sans cloner immédiatement toute la production.
Il est insuffisant comme unique filet de sécurité avant une mise à jour, une migration de serveur, un changement de thème ou une intervention sur la base.
Le guide BlackFury Sauvegarder WordPress ne suffit pas : tester une restauration complète ce point. Pour replacer cette sauvegarde dans l’ensemble de la maintenance, mon retour sur l’auto-hébergement de BlackFury en 2026 détaille aussi les responsabilités conservées côté serveur.
Les erreurs qui donnent une fausse confiance
- appeler « sauvegarde complète » un XML jamais importé ;
- supprimer le site source avant d’avoir copié les médias ;
- oublier les brouillons et contenus privés en appliquant un filtre ;
- supposer que les champs d’une extension seront compris sans cette extension ;
- modifier l’unique exemplaire du WXR ;
- conserver l’export sur le même serveur que le site ;
- tester uniquement le titre des articles sans ouvrir les images et les liens ;
- considérer un import sans message fatal comme une validation complète.
Le verdict BlackFury
L’export WordPress est excellent lorsqu’on lui demande de transporter du contenu. Il devient dangereux lorsqu’on lui attribue le rôle d’une sauvegarde complète qu’il n’a jamais eu.
Je garde donc trois preuves : le WXR pour le patrimoine éditorial, le SQL pour la base et les fichiers pour l’installation. Puis je teste sur un environnement isolé. Une sauvegarde fiable n’est pas celle qui affiche un joli nom dans un dossier ; c’est celle dont le périmètre, la date et la restauration sont compris.
Sources officielles consultées
- WordPress.org — écran Outils → Exporter
- WordPress.org — écran Outils → Importer
- WordPress Developer Resources — sauvegardes WordPress
- WordPress Developer Resources — importer du contenu
- WordPress.org — extension WordPress Importer
- WordPress Developer Resources — wp db export
