After a WordPress migration, the database may arrive correctly while some original image files or generated sizes do not. A broken image on the page is therefore a clue, not proof that every media record is wrong.
Open the exact image URL requested by the browser and compare its response with the destination uploads folder. That tells you whether to investigate missing files, stored old-domain URLs, HTTPS, permissions or an image-delivery service.
A broken mobile thumbnail, old-domain URL and blocked HTTPS request need different repairs. Test one known example before replacing addresses or regenerating the library.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Follow the exact image URL that failed
| Evidence | Likely investigation | Next check |
|---|---|---|
| 404 at the new image URL | File path or missing size | Exact name, case and uploads folder |
| Original works, smaller size fails | Generated image absent | Supported regeneration with a usable original |
| Image URL uses the old domain | Stored content or builder setting | Scoped migration-aware replacement |
| 403 response | Access or hotlink rule | Host log for the exact request |
| TLS or mixed-content warning | HTTPS delivery | Certificate, scheme and CDN origin |
Find the image the browser actually requested
- Open one page with a broken image.
- Inspect its image request in the browser Network panel.
- Record the page URL, requested image URL and response.
- Compare desktop and mobile if only one layout fails.
- Use the exact requested filename when checking destination files.
A page may reference several image sizes through responsive markup. The browser can select a smaller generated file on mobile and another file on desktop. If one device works and another does not, compare those actual requested addresses.
Open the failed image address or inspect its Network entry. A 404 means that address did not resolve to a resource. A 403 suggests access was refused. A certificate or mixed-content warning points to a different delivery problem.
Keep the page URL, failed image URL, and status. The image visible in the editor may not be the same generated size used on the public page, so the editor alone is not a complete test.
Confirm the uploads were copied
Compare the expected file with the uploads directory on the destination host. WordPress commonly organizes media into dated folders, and a partial transfer can miss older directories while recent images work.
File names and case matter on many servers. An address containing an uppercase character may not match a lower-case file after a move. Check the exact path rather than assuming similar names are interchangeable.
If the original file exists but a generated size does not, use a supported thumbnail-regeneration method after keeping a backup. Regeneration needs a usable original and enough working resources; it cannot recreate an original that was never transferred.
Correct stored addresses carefully
Preview the replacement scope with a supported dry run where available. Keep a database backup and use a tool that understands serialized data. Do not change GUID identifiers as if they were ordinary displayed image links; the official migration instructions distinguish them.
A move to another domain or directory can leave old image addresses in post content, widgets, or builder settings. Correct a small known example first and confirm the result before a broad replacement.
Some settings contain serialized data, which can be damaged by a naive text replacement. Use a migration-aware tool or a developer using the supported WordPress method. Review the replacement scope and a dry run where available, and back up the database.
Check HTTPS and any image delivery service
An HTTPS page should load its media through HTTPS too. Browsers may upgrade some insecure image requests or block them depending on the resource and circumstances. The console helps identify what happened to the specific image.
A CDN or optimization service may still point to the old origin or hold a cached missing-file response. Confirm that the new origin serves the correct file, then refresh the affected CDN resource through the service’s supported controls.
Image conversion plugins may generate WebP or other variants. A reference to a converted file can fail if only the original format was migrated. Compare the actual requested variant and the plugin’s regeneration instructions.
When the file exists but access fails
The host can review ownership, directory access, hotlink rules, and security events for the exact image request. A rule that permits one referrer but blocks the new domain can produce a pattern that resembles missing media.
Do not set the whole installation to broadly writable permissions. Ask the provider to compare a working file and a failing file under the intended serving account. If WordPress loads the wrong origin after the move, confirm domain routing before changing media settings.
Verify a representative set of pages
Check older and newer posts, product images, the header or logo, and both mobile and desktop layouts. This catches missing dated folders and responsive sizes that a single homepage test can miss.
Keep the original migration backup until the media checks are complete. For reference, see WordPress’s migration documentation and search-replace reference, plus MDN’s mixed-content guidance. Our general media troubleshooting guide covers image problems unrelated to a move.
Verify more than the homepage
Check old and new posts, the header, product variants and responsive sizes on mobile and desktop. Confirm that the new origin serves the file before refreshing a CDN’s cached error. Keep migration backups until these representative checks pass.