I’m trying to move blog posts along with their thumbnail images between two WordPress sites.
Here’s what I did:
Created an XML export file from the source site
Started the import process on the destination site
The first phase (importing users) completed successfully
But now I’m getting a 404 not found error when it tries to go to the second phase
The error happens when WordPress tries to load the import page for step 2. Both sites are running the most recent WordPress version.
For the export, I used a plugin called “Export media with selected content” to make sure the featured images come along with the posts.
Has anyone run into this problem before? What could be causing the second step to fail with a page not found error? Any suggestions on how to get past this issue?
WordPress imports suck, especially with media files. I’ve hit this same problem tons of times migrating client sites.
The built-in importer is garbage - breaks constantly at random stages. I stopped fighting with XML exports ages ago and just automate everything now.
Here’s what works: Connect to both WordPress sites through their REST APIs. Pull posts from the source, download featured images to temp storage, then push everything to the destination in small batches. Way better error handling and you can pick up where you left off if it crashes.
Bonus - it handles duplicates and automatically maps old image URLs to new ones. No more crossing fingers and praying the importer doesn’t die.
I use Latenode for these workflows since it handles API calls and file transfers without headaches. Takes 15 minutes to set up, saves hours of debugging import failures.
I’ve hit this exact problem tons of times during site migrations. That 404 in step 2? It’s usually session handling issues, not server limits. WordPress temporarily stores import session data, and when it gets corrupted or times out, the second phase can’t find the import context. Clear your browser cache completely and start over. Also check if your destination site has security plugins or .htaccess rules blocking the import URLs. I’ve seen ModSecurity rules kill imports halfway through. If the standard importer keeps crapping out, use WP-CLI instead. It runs server-side without browser session dependencies and gives way better error reporting. SSH into your server and run ‘wp import your-file.xml --authors=create’ - bypasses the web interface completely. Way more reliable for large imports with media files.
WordPress imports with media files can be tricky, especially when the importer struggles with URL mappings during migration. I faced a similar issue while migrating a photography site last month. The 404 error in step 2 often occurs because the destination site cannot correctly map the media URLs from your XML export. If the plugin you used exported absolute URLs pointing to the old site, WordPress will create broken references when importing. To resolve this, open your XML file and replace all occurrences of your source URL with the destination URL before starting the import again. Additionally, ensure that your uploads directory has the appropriate write permissions, as the importer needs to create new folders for the imported media and permission issues can lead to failures appearing as routing errors.
Sounds like a memory or timeout problem - super common with WordPress imports. That 404 in step 2 usually means your server can’t handle the load and times out. First, bump up your PHP limits. Go into wp-config.php or your hosting panel and increase max_execution_time and memory_limit. If your XML file is huge (lots of posts with images), try splitting it into smaller pieces. Media attachments eat up resources like crazy. Got access to server logs? Check those - they’ll show you what’s actually causing the 404.
Upload the XML file straight to your server through FTP - skip the web interface completely. Large files with media attachments mess with routing and break step 2. This fixed it for me when everything else failed.