Images missing after a WordPress restore usually mean the database and file delivery path do not match. An attachment in the Media Library is not proof that its original file, resized variants, or external storage object was restored. Diagnose one failed image before reimporting the whole library.
Keep the recovered site private while investigating. Do not overwrite the only remaining archive or production uploads. If the live store has received new orders since the backup, restoring its database again can lose unrelated business records.
Pick One Image and Record the Actual Request
Open an affected page and inspect the image request in the browser Network panel. Record the final URL, HTTP status, response type, and whether the browser selected a resized source. Compare a new image with an older one and an original with a thumbnail.
An HTML response at an image URL is not a successful image load even if its status is 200. A 403 suggests an access problem; a 404 suggests a missing path, but confirm the storage and routing before deciding the file is gone.
Match Database, Archive, and Storage
The WordPress backup handbook distinguishes files from database content. A SQL export restores attachment records, not the actual media bytes.
Look for the exact relative file path in the backup inventory and restored uploads directory. Check archive exclusions and backup timestamps. A backup taken before the upload cannot contain that file. A partial restore may have selected the database and plugins but omitted uploads.
For offloaded media, identify the bucket or external storage account and the plugin that maps attachments to it. Confirm the object exists and that the restored environment has the intended access. Do not make an entire private bucket public to repair a few broken images.
Verification record for WordPress Images Missing After a Backup Restore: Find the Missing Layer. Fill in your own evidence.
Choose the Fix From the Evidence
| Observation |
Next action |
| Original absent from disk and backup |
Look for another recovery point or storage copy |
| Original exists, thumbnail absent |
Test generating that attachment's sizes |
| URL still points to old domain |
Review migration URL handling with a dry run |
| Object exists but returns access denied |
Repair the scoped delivery configuration |
| Browser requests a nonexistent generated size |
Inspect responsive image metadata and theme size requirements |
Regenerating thumbnails cannot recover an original that no longer exists. Test one attachment before processing thousands; large batches can consume CPU and disk space. Confirm the correct plugin handles offloaded originals during generation.
Do not run a raw text replacement across serialized database data. Use a migration-aware tool, back up the current state, and review its dry-run scope. Exclude identifiers or historical values that should not change merely because they contain the old hostname.
Validate More Than the Media Library
Test a public page, an archive, a product gallery if applicable, and a mobile viewport that selects a different responsive image. Verify the actual file response and the image dimensions. Clear only the delivery cache that still holds a known stale result.
Document what the archive did and did not include. Add external media access and a representative restore check to your backup strategy, including a separate plan for credentials and encryption keys.
If the archive inventory and attachment paths disagree, HandL WP can investigate the restore gap. Provide a redacted example path and backup timestamp first. A full database export should never be posted publicly as troubleshooting evidence.
References checked September 29, 2026. Diagrams and examples are explanatory, not measured customer results.