Comprendre WordPress. Choisir ses outils. Faire avancer son site.Notre méthode éditoriale ↗

Sauvegardes, restauration et import · Intermédiaire

Import WordPress : résoudre une version WXR absente ou invalide

WordPress refuse votre fichier avec une version WXR absente ou invalide ? Vérifiez son format, recréez l’export et contrôlez l’importateur sur copie.

Reconnaître un rejet de fichier avant l’import de contenu

Vous choisissez un fichier dans l’importateur WordPress, puis le message indique une version WXR absente ou invalide. Parfois un premier écran annonce une erreur de lecture et un nouvel essai avec un autre analyseur. L’importateur ne reconnaît pas la structure attendue ; ce message ne désigne pas automatiquement un manque de mémoire ou un défaut de la base de données.

WXR signifie WordPress eXtended RSS. C’est un format XML d’échange de contenu WordPress. Le résultat recherché est un fichier identifié, complet et reconnu par l’outil adapté, puis un essai contrôlé sur une copie. Un fichier qui porte l’extension .xml peut appartenir à un tout autre format. Le renommer ne le convertit pas.

Sur un site auto-hébergé, il faut pouvoir exporter depuis la source et importer sur la destination. L’installation éventuelle de l’importateur demande les droits correspondants. WordPress.com propose son propre parcours depuis les outils du site. Dans un réseau multisite, vérifiez le sous-site de départ et celui d’arrivée : un export d’un sous-site ne représente pas nécessairement tout le réseau.

Conserver l’original et séparer les essais de la destination réelle

Gardez le fichier reçu sans modification dans un dossier privé. Dupliquez-le avant de l’ouvrir dans un éditeur ; notez son nom, sa taille, sa date et sa provenance. Un export peut contenir des brouillons, des adresses ou d’autres informations privées. Ne l’envoyez pas à un validateur public pour savoir s’il s’agit d’un XML lisible.

Préparez une copie récente de la destination avec une sauvegarde restaurable. Faites protéger son accès, fichiers téléversés compris, par le mécanisme de préproduction de l’hébergeur : décourager les moteurs de recherche ne rend pas les fichiers privés. Neutralisez les envois et les intégrations qui pourraient réagir à la création de contenu. Relevez quelques contenus déjà présents pour vérifier ensuite qu’un essai n’a pas modifié leur état. Si des imports ont déjà été tentés, conservez leurs messages et leur point d’arrêt.

L’erreur affichée avant le choix des auteurs concerne normalement la préparation du fichier, mais ne présumez pas que tous les essais précédents se sont arrêtés au même endroit. Vérifiez la liste des contenus avant de relancer. Une désactivation de l’importateur n’annule pas les données qu’un essai aurait déjà créées. Le retour arrière doit être prévu au niveau de la copie ou des éléments précisément identifiés.

Identifier le vrai format avant de choisir un importateur

Ouvrez la copie du fichier dans un éditeur de texte local, sans l’enregistrer. Examinez son début. Des lignes de colonnes séparées par des virgules ou des points-virgules correspondent souvent à un CSV. Des instructions SQL appartiennent à une sauvegarde de base. Une page HTML de connexion ou d’erreur peut avoir été téléchargée à la place du document attendu.

Dans ces cas, arrêtez le parcours WXR. Revenez à l’outil qui a produit le fichier et recherchez son importateur correspondant. Un export de catalogue généré par un composant doit suivre le mécanisme documenté par ce composant. L’entrée WordPress d’Outils, Importer attend un export WordPress, pas tous les fichiers utilisables sur un site WordPress.

Si le téléchargement contient une archive ZIP, examinez son contenu localement. Elle peut regrouper des XML, mais aussi une sauvegarde complète sans rapport avec l’import de contenu. Extrayez le XML attendu lorsque le parcours choisi le demande, sans renommer une archive en .xml. Le résultat de cette première approche est un couple format et outil cohérent ; si le fichier est réellement WXR, poursuivez les contrôles suivants.

Repérer la structure WordPress sans fabriquer un faux WXR

Dans un export natif, cherchez les éléments rss et channel, des déclarations de namespaces et des informations WordPress. Une recherche de wp:wxr_version dans l’éditeur aide à repérer l’indication de version, sans la modifier. Un namespace donne un sens précis à des balises préfixées comme wp:. La présence du mot WordPress dans un commentaire, dans un titre ou dans un lien ne suffit pas à reconnaître le format.

L’importateur vérifie notamment une indication de version WXR. Il ne faut pas ajouter cette indication au hasard dans un flux RSS ou dans un XML de catalogue. Le reste du document doit porter les contenus et métadonnées selon la structure attendue. Changer le numéro jusqu’à faire disparaître le message ne démontre aucune conversion correcte. Un avertissement signalant une version WXR plus récente que celle prise en charge est un autre cas : examinez la compatibilité de l’importateur, sans abaisser artificiellement le numéro dans le fichier.

Ne remplacez pas non plus toutes les occurrences de http par https dans les identifiants de namespaces. Leur écriture identifie un vocabulaire ; elle ne représente pas nécessairement une adresse de page à migrer. Si vous disposez d’un export natif récent de la même source, comparez sa structure avec le fichier refusé sans écraser l’original. L’absence d’informations essentielles demande d’abord un nouvel export ou une correction du générateur.

Repérer un fichier tronqué ou pollué pendant sa création

Descendez à la fin du document dans l’éditeur local. Une coupure au milieu d’une balise, d’un article ou d’un bloc de texte rend plausible un téléchargement interrompu. Un export natif se termine normalement par la fermeture de channel puis de rss. L’absence de cette fin est un indice ; la présence des dernières balises ne prouve pas à elle seule que toutes les entrées intermédiaires sont intactes.

Cherchez aussi une page d’erreur ou un avertissement inséré avant ou au milieu du XML. Un document XML doit respecter une structure bien formée, avec des balises correctement imbriquées et un encodage cohérent. Un message PHP ajouté à la sortie peut donc empêcher sa lecture. Conservez seulement l’extrait nécessaire au diagnostic, avec les données privées masquées.

N’essayez pas de réparer un gros fichier en collant quelques balises fermantes à sa fin. Vous masqueriez la coupure sans récupérer les contenus absents. Si la source reste disponible, régénérez le document et comparez les tailles ainsi que le périmètre exporté. Si une sortie d’erreur revient à chaque génération, faites corriger cette erreur à la source avant de considérer le téléchargement comme exploitable.

Créer un nouvel export natif depuis le site source

Cette deuxième approche convient lorsque vous avez accès à la source et que le fichier reçu est douteux. Utilisez son export natif, puis gardez le nouveau document à côté du fichier refusé pour pouvoir les comparer.

Vérifiez que le navigateur a terminé le téléchargement. Ouvrez le fichier en lecture seule et contrôlez son début, sa fin et quelques titres connus. Une taille différente peut s’expliquer par le périmètre ou par des contenus récents ; elle ne prouve pas automatiquement une amélioration. Le nouvel export doit contenir les éléments que vous cherchiez effectivement à déplacer.

Cette opération exporte des contenus ; elle ne restaure pas une installation entière avec tous ses thèmes, extensions et réglages. Son intérêt ici est de produire une structure native cohérente. Si le fichier neuf est reconnu sur la copie de destination alors que l’ancien est refusé, conservez cette comparaison et utilisez le document neuf pour préparer la suite. Aucun contenu source n’a besoin d’être supprimé pour réaliser cet essai. « Tout le contenu » reste limité aux types exportables : certains contenus personnalisés exigent le composant qui les déclare et son propre parcours.

  1. Dans l’administration du site source, ouvrez Outils, Exporter et choisissez Tout le contenu. Vérifiez le domaine et, en multisite, le sous-site affiché.
  2. Cliquez sur Télécharger le fichier d’export. Attendez la fin du téléchargement et conservez le fichier sous un nom qui indique sa source et sa date.
  3. Ouvrez sa copie dans l’éditeur local sans enregistrer de modification. Recherchez avec Ctrl+F wp:wxr_version, un titre connu et les fermetures finales. Si le fichier reste coupé, passez à un lot filtré.

Produire un petit fichier par les filtres prévus à la source

Si l’export complet échoue ou semble se couper, choisissez un petit ensemble contenant un titre témoin connu. Les filtres natifs évitent de découper vous-même un document dont la structure doit rester cohérente.

Téléchargez ce lot natif dans un nouveau fichier. Contrôlez sa structure et essayez sa lecture sur la copie. S’il est reconnu, augmentez progressivement le périmètre par des lots distincts, sans chevauchement volontaire. Gardez un relevé de ce qui est exporté ; un dossier de fichiers aux noms similaires ne garantit pas que tous les contenus ont été couverts.

Ne découpez pas manuellement le XML en blocs de même poids dans un éditeur. Les éléments dépendent d’une enveloppe et de métadonnées communes ; une coupure arbitraire peut créer précisément l’erreur que vous tentez de corriger. Les filtres natifs produisent des documents autonomes. Si même un lot réduit neuf est refusé, examinez l’importateur et l’environnement avant de multiplier les exports.

  1. Retournez dans Outils, Exporter et sélectionnez Articles pour afficher ses filtres. Choisissez une période courte ; ajoutez un auteur ou un état seulement si ce filtre correspond au contenu recherché.
  2. Notez les valeurs choisies et téléchargez ce nouveau fichier. Un filtre « Publié » exclut les brouillons : ne l’utilisez pas si le témoin est un brouillon.
  3. Vérifiez le titre témoin et la fin du fichier, puis comparez sa lecture sur la copie. Organisez ensuite les lots nécessaires sans oublier les autres types de contenu, au lieu de supposer que le premier lot représente tout le site.

Vérifier que le fichier choisi est bien celui contrôlé

Au moment de l’essai, comparez le nom complet, la taille et l’emplacement du fichier sélectionné avec votre relevé. Le dossier Téléchargements peut contenir plusieurs versions portant un suffixe ajouté automatiquement par le navigateur. Une copie reçue par messagerie peut également être une archive ou un lien vers une page intermédiaire, plutôt que le XML original.

Si vous transférez le document à un autre poste ou à un intervenant autorisé, conservez l’original et vérifiez l’intégrité du transfert. Utilisez un canal privé adapté aux données et retirez les liens temporaires devenus inutiles. Un aperçu affiché par un service de stockage ne remplace pas le téléchargement réel du fichier. N’enregistrez pas cet aperçu HTML sous le nom de l’export.

Le contrôle attendu est simple : la destination reçoit le même document que celui dont vous avez vérifié la structure. S’il change pendant le transfert, corrigez ce trajet avant toute intervention PHP. Si le fichier est identique et reconnu ailleurs dans un environnement compatible, cette comparaison oriente vers la destination, tout en évitant d’exposer les contenus du site à des outils publics.

Vérifier l’importateur officiel et sa compatibilité déclarée

WordPress Importer, publié par WordPress.org, lit les exports WXR. Au 3 novembre 2026, la version relevée est 0.9.7 ; elle annonce WordPress 5.2 et PHP 7.2 au minimum, testé jusqu’à WordPress 6.8.12 dans le répertoire. La fiche affiche un avertissement de compatibilité avec les dernières versions majeures. Cette déclaration ne garantit donc pas le fonctionnement sur toute version WordPress plus récente.

Dans Extensions, Extensions installées, relevez la version déjà présente sur la copie. Si elle est ancienne, comparez son journal de changements et les prérequis avant une mise à jour sur copie. Ne remplacez pas un importateur fourni par une plateforme gérée avec une archive trouvée ailleurs. Si l’état actuel n’est pas compatible avec votre environnement, faites valider un parcours pris en charge avant d’importer des données réelles.

Aucune extension nouvelle n’est nécessaire pour identifier le format ou régénérer l’export. L’importateur devient utile pour lire le WXR dans WordPress. Il ne transforme ni CSV ni sauvegarde SQL. Son installation ne répare pas un document tronqué ; vérifiez d’abord le fichier pour ne pas ajouter un outil à une erreur de format.

Tester la lecture avant de lancer le traitement des contenus

Sur la copie auto-hébergée compatible, la première phase envoie le fichier et prépare ses options. Les étapes ci-dessous permettent d’observer cette phase sans lancer la création des articles. Choisissez uniquement un export provenant d’une source de confiance et de taille adaptée.

Distinguez l’écran de lecture initiale de la suite du traitement. L’arrivée à l’affectation des auteurs montre que cette étape reconnaît le document ; elle ne prouve pas encore que tous les contenus et toutes les pièces jointes seront importés. Vous pouvez vous arrêter à ce point pour comparer deux fichiers sans lancer la création complète des contenus. Ce n’est toutefois pas une opération sans écriture : WordPress enregistre le fichier envoyé comme pièce jointe temporaire. Sur une installation ordinaire, le statut privé de cette pièce jointe ne protège pas nécessairement son URL directe. Gardez la copie protégée ; après abandon, faites contrôler le retrait de ce fichier précisément identifié. Le nettoyage prévu par WordPress dépend notamment de l’exécution de ses tâches planifiées.

Sur WordPress.com, partez aussi d’Outils, Importer, mais choisissez l’entrée WordPress destinée au contenu, pas la migration complète WordPress.com. Les options diffèrent : sans extensions, les médias sont importés automatiquement ; avec extensions, une option de pièces jointes est proposée. Ne supposez donc pas qu’un réglage absent désactive les téléchargements.

Si vous poursuivez un essai de contenu sur la copie auto-hébergée, affectez les auteurs à un compte de test existant autorisé plutôt que créer des comptes inutiles. Relevez les options de téléchargement des pièces jointes et de réécriture des URL : elles modifient le résultat, pas la validité WXR. Pour un essai limité au texte, laissez le téléchargement des pièces jointes décoché et consignez cette limite. N’utilisez pas la répétition de l’import comme réparation.

  1. Ouvrez Outils, Importer, puis WordPress. Cliquez sur Lancer l’importateur ; si Installer apparaît, n’installez que cette entrée officielle après le contrôle de compatibilité.
  2. Choisissez le petit XML vérifié, puis cliquez sur le bouton d’envoi et d’import du fichier. Ne relancez pas pendant son traitement.
  3. Si l’écran d’affectation des auteurs apparaît, notez que la lecture initiale a abouti. Pour cette seule comparaison, arrêtez-vous avant le bouton Envoyer ou Submit qui lance le traitement des contenus.
  4. Si un message d’erreur apparaît, conservez son texte et le point d’arrêt. Un avertissement concernant une version plus récente, un fichier absent et une version WXR invalide ne constituent pas le même résultat.

Comparer un fichier valide pour isoler la destination

La troisième approche s’adresse au cas où le format et l’intégrité du document sont confirmés. Prenez un petit export natif de confiance, produit sans erreur et contenant quelques éléments connus. Sur la même copie, avec la même version d’importateur, comparez seulement sa lecture initiale à celle du fichier refusé. Gardez constants les autres réglages.

Si ce témoin est accepté et le fichier initial refusé, concentrez l’examen sur leur différence de structure ou sur le générateur de l’export. Si les deux échouent, faites vérifier la compatibilité et les modules XML du PHP réellement utilisé par le site. Le parseur peut employer plusieurs mécanismes selon ce qui est disponible. L’absence de SimpleXML ne démontre pas à elle seule que tout import WXR est impossible.

Un relevé PHP en ligne de commande peut concerner un autre moteur que celui du domaine. Faites contrôler le contexte web par le responsable de l’hébergement, avec le message et l’heure exacts. N’ajoutez pas une page publique de diagnostic PHP et ne forcez pas un analyseur par une constante copiée d’un ancien forum. Une comparaison maîtrisée apporte une preuve plus utile qu’une succession de réglages.

Récupérer un document lorsque la source n’est plus accessible

Si la source est fermée, cherchez une autre copie du téléchargement d’origine, une archive d’export conservée ou un accès permettant de restaurer temporairement la source en privé. Ne restaurez pas un ancien site par-dessus une production qui a continué à recevoir des données. Une restauration isolée peut servir uniquement à recréer un export propre.

Lorsque le seul fichier disponible est endommagé, confiez sa copie à un intervenant capable d’examiner le XML localement. Il doit distinguer un caractère mal encodé, une balise abîmée et des données réellement absentes. Une réparation ciblée doit être documentée et comparée à l’original ; elle ne reconstitue pas automatiquement les articles coupés ou jamais exportés.

Ne supprimez pas tous les blocs en erreur pour obtenir un message de réussite. Cela pourrait produire un import incomplet sans rendre la perte visible. Si une récupération partielle est la seule option, dressez la liste des éléments identifiables et de ceux manquants, puis vérifiez le résultat sur une copie vierge. Le critère de réussite doit alors annoncer cette portée limitée, sans présenter le fichier comme un export complet.

Contrôler le résultat et préparer le véritable retour arrière

Après un import d’essai complet, comparez les titres, les dates, les statuts, les caractères accentués et quelques contenus longs avec la source ou le relevé disponible. Vérifiez aussi des éléments situés vers la fin du fichier ; les premiers articles affichés ne suffisent pas à démontrer que tout le document a été traité. Conservez les erreurs par étape.

Une lecture WXR réussie ne prouve pas que les médias distants ont été rapatriés ni que les auteurs ont été affectés comme prévu. Ces contrôles appartiennent à la validation du contenu importé. Si le diagnostic révèle maintenant un problème à ce niveau, arrêtez de modifier la version WXR et traitez cette nouvelle cause séparément.

Pour reprendre un essai sur la copie, restaurez son état d’avant import par la sauvegarde prévue ou reconstruisez une destination d’essai équivalente. Supprimer une extension ne retire pas les contenus créés ; supprimer quelques articles à la main peut laisser d’autres données. Pour une destination réelle déjà active, faites préparer une récupération ciblée. Une restauration globale pourrait effacer des publications ou des inscriptions intervenues depuis la sauvegarde.

Documenter le parcours qui produit un fichier exploitable

Gardez avec le fichier final sa provenance, la date de génération, le périmètre et les filtres utilisés. Ajoutez la version d’importateur et l’environnement sur lesquels la lecture puis l’import ont été vérifiés. Distinguez bien un document simplement ouvert dans un éditeur, un WXR reconnu par l’importateur et un import complet contrôlé : ces étapes ne fournissent pas la même preuve.

Pour signaler un défaut, transmettez le message exact, le point d’arrêt et un petit exemple privé autorisé. Un extrait doit conserver la structure utile tout en retirant les données personnelles ; sa préparation demande parfois l’aide du responsable technique. N’ajoutez pas de secrets ou un export intégral à une discussion publique pour gagner du temps.

Lors du prochain déplacement de contenu, générez les lots depuis les options officielles et conservez un relevé de couverture. Vérifiez le fichier avant de lancer une opération de masse. Un nom terminé par .xml, un nombre de version ajouté et une barre de progression terminée sont des indices d’apparence ; seuls la structure, la reconnaissance par le bon outil et le contrôle du résultat permettent de poursuivre avec confiance.

Notre méthode éditoriale

Ces guides peuvent aussi vous aider