WordPress import: resolve a missing or invalid WXR version

Recognize file rejection before content import

You select a file in the WordPress importer, then see a missing or invalid WXR version message. Sometimes an initial screen reports a reading error and a retry with another parser. The importer does not recognize the expected structure; this message does not automatically identify insufficient memory or a database fault.

WXR means WordPress eXtended RSS. It is an XML format for exchanging WordPress content. The goal is an identified, complete file recognized by the appropriate tool, followed by a controlled test on a copy. A file ending in .xml may use an entirely different format. Renaming it does not convert it.

On self-hosted sites, you must be able to export from the source and import into the destination. Installing the importer, if necessary, requires corresponding permissions. WordPress.com offers its own route through site tools. In multisite, check source and destination subsites: one subsite’s export does not necessarily represent the whole network.

Keep the original and separate tests from the real destination

Keep the received file unchanged in a private folder. Duplicate it before opening in an editor; record name, size, date and origin. An export may contain drafts, addresses or other private information. Do not upload it to a public validator to find out whether it is readable XML.

Prepare a recent destination copy with a restorable backup. Protect access, including uploaded files, through the host’s staging mechanism: discouraging search engines does not make files private. Disable sending and integrations that could react to content creation. Record some existing content to verify afterward that testing did not change its state. If imports were already attempted, retain messages and stopping points.

An error before author selection normally concerns file preparation, but do not assume every earlier attempt stopped at the same point. Check content lists before retrying. Deactivating the importer does not undo data an attempt already created. Plan rollback at the copy level or for precisely identified items.

Identify the actual format before choosing an importer

Open the file copy in a local text editor without saving. Examine its beginning. Rows of comma- or semicolon-separated columns often indicate CSV. SQL statements belong to a database backup. An HTML login or error page may have downloaded instead of the expected document.

In those cases, stop the WXR route. Return to the producing tool and find its corresponding importer. A component-generated catalog export must follow that component’s documented mechanism. The WordPress entry under Tools, Import expects a WordPress export, not every file usable on a WordPress site.

If the download contains ZIP, inspect it locally. It may group XML files or contain an unrelated full backup. Extract the expected XML when the chosen route requires it without renaming an archive to .xml. This first approach should yield a consistent format/tool pair; if the file is genuinely WXR, continue the following checks.

Recognize WordPress structure without fabricating a false WXR

In a native export, look for rss and channel, namespace declarations and WordPress information. Searching wp:wxr_version in the editor helps find the version indication without modifying it. A namespace gives precise meaning to prefixed tags such as wp:. The word WordPress in a comment, title or link is insufficient to recognize the format.

The importer checks a WXR version indication among other things. Do not randomly add it to an RSS feed or catalog XML. The rest must carry content and metadata in the expected structure. Changing the number until the message disappears proves no correct conversion. A warning about a WXR version newer than supported is another case: examine importer compatibility without artificially lowering the file’s number.

Also do not replace every http occurrence with https in namespace identifiers. Their spelling identifies a vocabulary; it does not necessarily represent a page address to migrate. If you have a recent native export from the same source, compare structure with the rejected file without overwriting the original. Missing essential information first calls for a new export or generator correction.

Identify a file truncated or contaminated during creation

Go to the document’s end in the local editor. A cut in a tag, post or text block suggests an interrupted download. A native export normally ends with closing channel, then rss. Missing endings are a clue; their presence alone does not prove every intermediate entry is intact.

Also look for an error page or warning inserted before or within XML. An XML document must be well formed, with correctly nested tags and consistent encoding. A PHP message added to output may therefore prevent reading. Retain only the excerpt necessary for diagnosis with private data hidden.

Do not try repairing a large file by appending a few closing tags. That would hide truncation without recovering missing content. If the source remains available, regenerate and compare sizes and exported scope. If error output returns on every generation, have it corrected at source before considering the download usable.

Create a new native export from the source site

This second approach fits when you can access the source and the received file is doubtful. Use its native export and keep the new document beside the rejected file for comparison.

Check the browser finished downloading. Open read-only and inspect the beginning, end and some known titles. Different size may reflect scope or recent content; it does not automatically prove improvement. The new export must contain the items you actually intended to move.

This exports content; it does not restore an entire installation with all themes, plugins and settings. Its purpose here is a consistent native structure. If the new file is recognized on the destination copy and the old rejected, retain the comparison and use the new document to prepare next steps. No source content needs deleting for this test. “All content” remains limited to exportable types: some custom content requires its declaring component and its own route.

1. In source-site administration, open Tools, Export and choose All content. Verify the domain and, in multisite, displayed subsite.
2. Click Download Export File. Wait for completion and retain the file under a name identifying source and date.
3. Open its copy locally without saving changes. Search with Ctrl+F for wp:wxr_version, a known title and final closing tags. If still truncated, move to a filtered batch.

Produce a small file through source-provided filters

If full export fails or seems truncated, choose a small set containing a known test title. Native filters avoid manually splitting a document whose structure must remain consistent.

Download this native batch into a new file. Check structure and test reading on the copy. If recognized, gradually expand scope through separate batches without intentional overlap. Keep a record of exported content; a folder of similarly named files does not guarantee complete coverage.

Do not manually divide XML into equal-sized blocks in an editor. Elements depend on a shared wrapper and metadata; arbitrary splitting may create exactly the error you are trying to fix. Native filters produce standalone documents. If even a fresh small batch is rejected, examine importer and environment before multiplying exports.

1. Return to Tools, Export and select Posts to expose filters. Choose a short period; add author or status only if it matches the intended content.
2. Record selected values and download the new file. A Published filter excludes drafts: do not use it when the test item is a draft.
3. Check the test title and file ending, then compare reading on the copy. Organize necessary batches without forgetting other content types instead of assuming the first batch represents the whole site.

Verify the selected file is the one checked

At testing time, compare the selected file’s full name, size and location with your record. Downloads may contain several versions with browser-added suffixes. A copy received through email may also be an archive or an intermediate-page link rather than original XML.

If transferring to another computer or authorized person, preserve the original and verify transfer integrity. Use a private channel appropriate for the data and remove obsolete temporary links. A storage-service preview does not replace actually downloading the file. Do not save that HTML preview under the export’s name.

The expected check is simple: the destination receives the same document whose structure you verified. If it changes during transfer, fix that route before any PHP intervention. If identical and recognized elsewhere in a compatible environment, comparison points toward the destination while avoiding public tools exposing site content.

Check the official importer and declared compatibility

WordPress Importer, published by WordPress.org, reads WXR exports. As of November 3, 2026, the recorded version is 0.9.7; it states minimum WordPress 5.2 and PHP 7.2, tested through WordPress 6.8.12 in the directory. The listing warns about compatibility with recent major versions. This declaration therefore does not guarantee operation on every newer WordPress version.

Under Plugins, Installed Plugins, record the version already on the copy. If old, compare its changelog and requirements before updating on the copy. Do not replace an importer supplied by a managed platform with an archive found elsewhere. If current state is incompatible with your environment, have a supported route validated before importing real data.

No new plugin is needed to identify format or regenerate export. The importer becomes useful for reading WXR in WordPress. It converts neither CSV nor SQL backups. Installing it does not repair truncation; verify the file first instead of adding a tool to a format error.

Test reading before starting content processing

On a compatible self-hosted copy, the first phase uploads the file and prepares options. The steps below observe that phase without launching post creation. Choose only an export from a trusted source and of appropriate size.

Distinguish initial reading from subsequent processing. Reaching author assignment shows that stage recognizes the document; it does not yet prove every content item and attachment will import. You can stop there to compare two files without launching full content creation. This is not write-free, however: WordPress stores the uploaded file as a temporary attachment. On an ordinary installation, private attachment status does not necessarily protect its direct URL. Keep the copy protected; after abandoning, have removal of this precisely identified file checked. WordPress’s planned cleanup depends in part on scheduled tasks running.

On WordPress.com, also start from Tools, Import but choose the WordPress content entry, not full WordPress.com migration. Options differ: without plugins, media import automatically; with plugins, an attachment option appears. Do not assume an absent setting disables downloads.

If continuing a content test on the self-hosted copy, assign authors to an existing authorized test account instead of creating unnecessary accounts. Record attachment-download and URL-rewriting options: they change results, not WXR validity. For text-only testing, leave attachment downloading unchecked and record that limitation. Do not use repeated imports as a repair.

1. Open Tools, Import, then WordPress. Click Run Importer; if Install appears, install only this official entry after checking compatibility.
2. Choose the verified small XML and click the upload-and-import button. Do not restart while it processes.
3. If author assignment appears, record successful initial reading. For this comparison alone, stop before Submit, which launches content processing.
4. If an error appears, retain its text and stopping point. A newer-version warning, missing file and invalid WXR version are different results.

Compare a valid file to isolate the destination

The third approach applies when document format and integrity are confirmed. Take a trusted small native export produced without errors and containing known items. On the same copy with the same importer version, compare only initial reading with the rejected file. Keep other settings constant.

If this control is accepted and the initial file rejected, focus on structural differences or the export generator. If both fail, have compatibility and XML modules of the site’s actual PHP checked. The parser may use several mechanisms according to availability. Missing SimpleXML alone does not prove every WXR import is impossible.

A command-line PHP reading may concern a different engine from the domain’s. Have the hosting administrator check the web context with the exact message and time. Do not add a public PHP diagnostic page or force a parser through a constant copied from an old forum. Controlled comparison provides more useful evidence than successive settings changes.

Recover a document when the source is inaccessible

If the source is closed, look for another original download copy, retained export archive or access enabling temporary private restoration of the source. Do not restore an old site over production that kept receiving data. An isolated restoration may serve solely to recreate a clean export.

When the only available file is damaged, give a copy to someone able to examine XML locally. They must distinguish a misencoded character, damaged tag and genuinely missing data. Document targeted repair and compare it with the original; it does not automatically recreate posts cut off or never exported.

Do not delete every failing block merely to obtain success. That could produce an incomplete import while hiding loss. If partial recovery is the only option, list identifiable and missing items, then verify the result on a fresh copy. Success criteria must state the limited scope instead of presenting the file as a complete export.

Check the result and prepare real rollback

After a complete test import, compare titles, dates, statuses, accented characters and several long pieces of content with the source or available record. Also check items near the file’s end; the first displayed posts do not prove the whole document was processed. Keep errors by stage.

Successful WXR reading does not prove remote media were downloaded or authors assigned as intended. Those checks belong to imported-content validation. If diagnosis now reveals a problem there, stop modifying the WXR version and treat this new cause separately.

To repeat testing on the copy, restore its pre-import state through the planned backup or rebuild an equivalent test destination. Removing a plugin does not remove created content; manually deleting a few posts may leave other data. For an already active real destination, prepare targeted recovery. Global restoration could erase publications or registrations made since backup.

Document the route producing a usable file

Keep origin, generation date, scope and filters with the final file. Add importer version and environment where reading and then import were verified. Clearly distinguish a document merely opened in an editor, WXR recognized by the importer and a completely checked import: these stages provide different evidence.

To report a defect, provide the exact message, stopping point and a small authorized private example. An excerpt must preserve useful structure while removing personal data; preparing it sometimes requires technical help. Do not add secrets or a complete export to a public discussion to save time.

For the next content move, generate batches through official options and retain a coverage record. Check the file before a bulk operation. A .xml filename, added version number and completed progress bar are superficial indicators; structure, recognition by the correct tool and result checking allow confident continuation.

Check XML locally without importing posts

With Python 3 already installed, save this snippet as verifier_wxr.py in a private folder containing a copy of your own export named export.xml. Run python verifier_wxr.py or your usual Python 3 launcher. Reserve this exercise for a reasonably sized trusted export: it is not an unknown-file analysis service.

Truncated XML produces an error with its position. Well-formed XML may nevertheless report an absent version: it may use another format, another WXR namespace or be incomplete. This script explicitly examines namespace 1.2; it certifies neither every export nor importer compatibility. Do not change the namespace to satisfy the script. Return to the generator or small native comparison export. No WordPress data is created; simply remove the script and private copy when examination is finished.

from pathlib import Path
import xml.etree.ElementTree as ET

fichier = Path('export.xml')
if fichier.stat().st_size > 20 * 1024 * 1024:
    raise SystemExit('Exercice limité à 20 Mio : choisissez un petit export natif.')
try:
    racine = ET.parse(fichier).getroot()
except ET.ParseError as erreur:
    raise SystemExit(f'XML mal formé : {erreur}')
canal = racine.find('channel')
version = None if canal is None else canal.find(
    '{http://wordpress.org/export/1.2/}wxr_version'
)
print('Racine :', racine.tag)
print('Version WXR 1.2 déclarée :', None if version is None else version.text)
print('Éléments item :', 0 if canal is None else len(canal.findall('item')))