How to Export WordPress Posts With Images Intact

Exporting WordPress posts with their images intact takes four sources rather than one, because no single export contains both the writing and the pictures. The XML file gives you post text and references to images. The uploads folder gives you the files. A crawl of the live site gives you what the pages actually render, including anything a plugin generates. And a search of post content for hard-coded addresses gives you the instances that will break the moment your domain or path changes. WPBuildAI runs all four on every migration, for one reason: the fourth is the one that breaks archives quietly, weeks after everyone has stopped watching. Here is what each route brings and what it leaves behind.

What does the XML export actually contain?

Post content, metadata, users, comments, and pointers to images. Not the images themselves.

The export tool is honest about its scope. It produces a file describing your content, and for each attached image it records which post it belongs to and the address it lived at. The picture stays on the server.

That distinction matters because of when it bites. Import that XML into another WordPress while the old site is still online and the importer can fetch each image over the network, so it appears to have worked. Import the same file after the old site is gone and every image reference points at nothing.

So the export is a genuine, useful artifact for the writing, and it is a promissory note for the pictures. Treat it that way and the rest of the process follows.

Which route gets you which part?

Use all four, because each one reaches something the others cannot.

The second row is time-critical in a way the others are not. Files live on a server somebody is paying for, and when that account closes they go with it. Download the uploads folder early, before any other step, because it is the only irreplaceable part.

Why do images break even after a careful export?

Because of how they were inserted, not because of how they were exported.

When an editor adds an image, WordPress often writes the full address into the post content: protocol, domain, uploads path, filename. That absolute reference works perfectly while all four parts stay the same, and breaks the instant any of them changes.

Move to a new domain and every one of those references points at the old one. Change the uploads structure and they point at a path that no longer exists. Move from http to https and browsers start refusing to load them as mixed content.

The failure is total and simultaneous rather than gradual, which is what makes it feel catastrophic. It is also entirely findable in advance: search your post content for your own domain, and every hit is an instance that needs repointing. That single search is the difference between a migration where images survive and one where an archive full of empty boxes surfaces in week three.

How do you keep the image URLs themselves working?

Preserve the paths wherever you can, then map what you cannot.

An unchanged file path needs no redirect and cannot break, which is the same logic that makes preserving page URLs the cheaper strategy. If the new site can serve images from the same uploads structure, do that and an entire category of risk disappears at no cost.

Where paths must change, generate one permanent redirect per file rather than a pattern rule. Redirects work for files exactly as they do for pages, and pattern rules fail silently when a new platform generates its own filenames, which most do.

This matters more than people expect because image URLs earn traffic independently. Google’s image guidance treats the file address as the thing that ranks, and image search positions reset when a file moves without a redirect. The recovery is the slowest of any part of a migration, often eight to twelve weeks, and only happens if the redirects exist. The full treatment is in how to migrate WordPress images and media without broken links.

What should you check before you switch anything off?

Six things, and every one of them is unrecoverable once the old hosting ends.

The fourth row catches what every other method misses. A supplier linking to your price list PDF, or a partner hotlinking a logo, are addresses on your domain that nothing on your site points at, so no crawl finds them and no export lists them.

How do you verify the images survived?

By requesting them rather than by looking at pages, because a page renders fine while an image loads through a redirect that a future deploy will drop.

Take the full list of image addresses from the crawl and request every one, recording the status and the final destination. Each should return 200 directly, or a single redirect to something that does. Anything returning a chain is a slow leak, and anything returning not found is already broken.

Then compare alt text counts per page against the crawl of the old site. Alt text lives in post content and in the media library, and a move that carries the pictures without their descriptions removes them from image search and from screen readers in one stroke, with nothing visibly wrong on the page.

Then load ten posts from across the archive, including the oldest, in a browser with the cache disabled. The oldest posts are where hard-coded absolute URLs cluster, because they were written when different editors and different habits were in use.

Rerun the image request pass a week after launch and after any deployment that touches routing. Redirect rules disappear quietly, and images are where that shows up last and hurts longest.

One more check is worth the two minutes: request a handful of image addresses with the www and non www forms of your domain, and over both http and https. Old posts frequently reference images using whichever form was canonical at the time they were written, and a site that answers on only one form turns every one of those into a broken picture.

Which tools make this faster?

Three, and each replaces an hour of clicking with a command.

WP-CLI exports content and lists media from the command line, which matters most when the admin is slow or the site is large enough that the browser export times out.

The REST API returns posts and media as structured records you can filter, which is the cleanest route when the destination is not another WordPress and you want data rather than an import file.

A desktop crawler produces the rendered inventory: every page, every image tag, every alt attribute, as visitors receive them. This is the one that catches plugin-generated images and galleries that appear in no export at all.

None is required. On a small site the admin screens and an FTP client do the same job more slowly, and the method matters far less than doing all four passes rather than one. The wider export routes are compared in how to export WordPress content without plugins.

When is a full image migration not worth it?

When the images are being replaced anyway. A rebuild that swaps stock photography for new product shots is publishing different pictures rather than migrating the old ones, and mapping the old paths to new files would be misleading rather than helpful.

It is also not worth it for decorative assets: background textures, icons, and theme furniture that nothing links to and that image search has no reason to index. Those can be regenerated freely.

And it is not worth it for files that should never have been public. Old drafts, superseded price lists, and documents uploaded by mistake are better returned as gone than carefully preserved at a new address.

The test is whether anything outside your control depends on the address. If an external site, a search engine, or a printed document points at it, keep it working. If nothing does, you are free to start clean.

Key takeaways: getting posts out with their pictures

The XML export carries post text and references to images, not the files. It works while the old site is online and becomes a list of broken pointers once it is not.

Download the uploads folder first, before any other step. It is the only genuinely irreplaceable part, and it disappears when the hosting account closes.

Search your post content for your own domain. Absolute image URLs pasted into posts break all at once when the domain, path, or protocol changes, and that single search finds every instance in advance.

Preserve the uploads path if you can, and map one redirect per file where you cannot. Image search recovery is the slowest part of any migration, and it only happens for files whose addresses still resolve.

Questions we get on this

How do I export WordPress posts with images? Use four sources together: the XML export for post text, a direct download of the uploads folder for the files themselves, a crawl of the live site for what pages actually render, and a search of post content for hard-coded absolute URLs. WPBuildAI runs all four, because the fourth is the one that silently breaks archives after a move.

Does the WordPress export include images? It includes references to images, not the files. The XML records which attachment belongs to which post and where it lived, and the pictures themselves stay in the uploads folder on the server. An import into another WordPress can fetch them while the old site is still online, and once it is gone, so are they.

Why do images break after moving posts? Because many are referenced by full URL rather than by relative path. An editor pastes an image and the markup records the complete address including the domain, so the moment the domain, the protocol, or the uploads path changes, every instance points at something that no longer exists, all at once and silently.

How do I keep image URLs working after the move? Preserve the uploads path if you can, since an unchanged file path needs no redirect and cannot break. Where paths must change, generate one permanent redirect per file rather than a pattern rule, and repoint in-post references at the final address so internal links do not travel through a hop that a future deploy might drop.

Is it not easier to just re-upload the images? Easier on a small site and expensive on any site with history. Re-uploading changes every filename and path, which resets image search positions and breaks every external link to those files. On twenty posts it is a reasonable afternoon. On four hundred it discards traffic that took years to earn.