Note : Cet article a été publié à l’origine en 2013. Certaines étapes, commandes ou versions de logiciels ont pu changer. Consultez la documentation actuelle de WordPress pour les informations les plus récentes.

Migrating content between WordPress installations is a routine task, whether you are consolidating multiple sites, moving to a new host, or restoring from a backup. The built-in WordPress Import tool (based on the WordPress Importer plugin) handles this through XML export files in the WXR (WordPress eXtended RSS) format. However, the import process frequently hangs, times out, or stops without completing — especially on larger sites. This guide explains every common cause and provides multiple solutions, from quick PHP configuration fixes to alternative import methods that bypass the web interface entirely.

How the WordPress Import Process Works

Understanding the import pipeline helps diagnose where failures occur:

  1. You export content from the source site using Tools > Export, which generates a WXR XML file containing posts, pages, custom post types, comments, categories, tags, and media attachment references.
  2. On the destination site, you install the WordPress Importer plugin (via Tools > Import > WordPress).
  3. You upload the WXR file through the web interface.
  4. The importer parses the XML, creates database records for each content item, and optionally downloads media files from the source site’s URLs.

Each of these steps has potential failure points, and the import runs within the constraints of your web server’s PHP configuration.

Common Causes of Import Failure

1. PHP max_execution_time Exceeded

This is the single most common cause. PHP’s max_execution_time directive controls how long a script can run before the server kills it. The default is typically 30 seconds. A large import with thousands of posts and media downloads can easily take 10 to 30 minutes.

When the time limit is reached, the PHP process is terminated silently. The browser may show a blank white page, a partial completion message, or simply spin indefinitely.

2. PHP memory_limit Too Low

Each post, taxonomy term, and media attachment the importer processes consumes memory. A memory_limit of 64MB or 128MB may be insufficient for large imports. When PHP runs out of memory, it produces a fatal error and the import stops.

3. Upload File Size Restrictions

The WXR export file must be uploaded through the browser. Two PHP directives control the maximum upload size:

  • upload_max_filesize — the maximum size of a single uploaded file.
  • post_max_size — the maximum size of the entire POST request body (must be larger than upload_max_filesize).

If your export file exceeds these limits, the upload itself will fail before the import even begins.

4. Media Download Timeouts

When “Download and import file attachments” is checked, the importer attempts to download each media file from the source site. If the source site is slow, down, or behind a CDN with rate limiting, individual downloads may time out and cause the entire import to stall.

5. Plugin and Theme Conflicts

Active plugins on the destination site can interfere with the import. Common culprits include:

  • Sécurité plugins that block the XML parsing or flag the import as suspicious activity.
  • Caching plugins that interfere with long-running PHP processes.
  • SEO plugins that hook into post creation and add significant processing overhead for each imported post.
  • Custom post type plugins where the post types in the export do not match the registered types on the destination.

6. Database Connection Limits

On shared hosting, database connection pools may be limited. A long-running import that holds a persistent database connection can be terminated by the hosting provider’s connection timeout settings.

Solution 1: Increase PHP Limits

Via wp-config.php

Add the following line to your wp-config.php file, before the /* That's all, stop editing! */ comment:

// Increase PHP memory limit for WordPress
define('WP_MEMORY_LIMIT', '512M');

This tells WordPress to request more memory, but it only works if the server allows PHP to allocate that much.

Via .htaccess (Apache)

If your server runs Apache with mod_php, add these directives to the .htaccess file in your WordPress root directory:

# Increase PHP limits for WordPress import
php_value max_execution_time 600
php_value memory_limit 512M
php_value upload_max_filesize 256M
php_value post_max_size 300M
php_value max_input_time 600

Via php.ini or .user.ini

Some hosting environments allow a local php.ini or .user.ini file in the WordPress root:

; php.ini or .user.ini overrides for import
max_execution_time = 600
memory_limit = 512M
upload_max_filesize = 256M
post_max_size = 300M
max_input_time = 600

Verify the Changes

After making changes, confirm they took effect by checking the WordPress Site Health screen (Tools > Site Health > Info > Server) or by creating a temporary PHP info file:

<?php
// Create as info.php in your WordPress root, then delete after checking
phpinfo();
?>

Load the file in your browser and search for max_execution_time, memory_limit, and upload_max_filesize to confirm the new values.

Solution 2: Split the Export File

If you cannot increase PHP limits (common on shared hosting), split the WXR XML file into smaller parts. Each part can be imported individually within the time limits.

Using the WordPress WXR File Splitter

Several tools exist for splitting WXR files:

  • WXR File Splitter (online tool) — upload your file and choose how many posts per chunk.
  • Manual splitting — open the XML in a text editor and divide the <item> elements across multiple files, keeping the XML header and footer intact in each.

A safe target is 50 to 100 posts per file for most hosting environments.

Manual XML Split Structure

Each split file must maintain valid WXR structure:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0"
    xmlns:excerpt="http://wordpress.org/export/1.2/excerpt/"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:wp="http://wordpress.org/export/1.2/"
>
<channel>
    <!-- Keep the channel metadata from the original file -->
    <title>Your Site Title</title>
    <link>https://yoursite.com</link>
    <wp:wxr_version>1.2</wp:wxr_version>

    <!-- Include a subset of <item> elements here -->
    <item>
        <!-- post data -->
    </item>
    <!-- ... more items ... -->

</channel>
</rss>

Solution 3: Use WP-CLI for Import

WP-CLI is the command-line interface for WordPress. It runs PHP scripts directly from the server’s command line, bypassing web server timeouts entirely. This is the most reliable method for large imports.

Installing WP-CLI

If WP-CLI is not already installed on your server:

# Download WP-CLI
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

# Verify it works
php wp-cli.phar --info

# Make it executable and move to PATH
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

Running the Import

# Navigate to your WordPress installation directory
cd /var/www/html

# Install the WordPress Importer plugin if not already installed
wp plugin install wordpress-importer --activate

# Run the import
wp import /path/to/export-file.xml --authors=create

# Alternative: map authors from the export to existing users
wp import /path/to/export-file.xml --authors=mapping.csv

The --authors flag controls how imported authors are handled:

  • create — creates new user accounts for each author in the export.
  • mapping.csv — uses a CSV file to map export authors to existing users. Format: old_author_login,new_author_login.
  • skip — assigns all imported content to the current user.

Import with Increased PHP Limits via CLI

Even on the command line, you may need to increase PHP limits for very large imports:

# Run with increased memory and no time limit
php -d memory_limit=1G -d max_execution_time=0 $(which wp) import /path/to/export-file.xml --authors=create

Solution 4: Direct Database Import

For advanced users migrating between sites on the same server or with direct database access, you can export and import at the MySQL level. This is fastest but requires careful handling of table prefixes and site URLs.

Export Specific Tables

# Export content tables from the source database
mysqldump -u username -p source_db wp_posts wp_postmeta wp_terms wp_term_taxonomy wp_term_relationships wp_comments wp_commentmeta > content_export.sql

Adjust Table Prefixes

If the destination site uses a different table prefix, update the SQL file:

# Replace source prefix with destination prefix
sed -i 's/wp_posts/wp2_posts/g' content_export.sql
sed -i 's/wp_postmeta/wp2_postmeta/g' content_export.sql
# ... repeat for each table

Import Into the Destination Database

mysql -u username -p destination_db < content_export.sql

Update URLs with WP-CLI

After importing, update all references to the old site URL:

wp search-replace 'https://old-site.com' 'https://new-site.com' --all-tables --precise

Avertissement : Direct database import does not handle media file downloads, author mapping, or taxonomy reconciliation. Use this method only when you understand the database schema and can manually handle these tasks.

Solution 5: Resolve Plugin Conflicts

If increasing limits and splitting files does not help, test for plugin conflicts:

# Deactivate all plugins via WP-CLI
wp plugin deactivate --all

# Run the import
wp import /path/to/export-file.xml --authors=create

# Reactivate plugins
wp plugin activate --all

If the import succeeds with all plugins deactivated, reactivate them one at a time to identify the conflicting plugin.

Through the web interface, you can do the same by navigating to Plugins > Installed Plugins, selecting all, and choosing Deactivate from the bulk actions menu.

Preventing Import Problems

  1. Export in smaller batches when possible. Use the WordPress Export tool’s date range and content type filters to create multiple smaller export files.
  2. Test on a staging environment first before importing into production.
  3. Keep a backup of the destination site’s database before starting the import.
  4. Check disk space — media downloads during import can consume significant storage.
  5. Verify the export file is valid XML before importing. Open it in a browser; if the browser displays it as a structured tree, the XML is well-formed.

Articles Connexes