Broken images after a WordPress migration usually point to incorrect URLs, missing upload files, permissions, mixed HTTP/HTTPS references or cached pages. Re-uploading every image should not be your first move.
Check whether the image file exists
Open a broken image in a new tab and inspect its URL. If it returns 404, compare the path with wp-content/uploads on the new server.
Check the old domain in image URLs
If HTML still references the previous domain or temporary migration URL, the database may need a safe search-and-replace. Back up the database first and use a WordPress-aware method that preserves serialised data.
Check HTTPS and mixed content
If the page is HTTPS but images are requested over HTTP, update the site URLs and old references rather than disabling browser security.
Check permissions and ownership
If files exist but return 403, review file/folder permissions and hosting security. Hostinger maintains an official website troubleshooting collection covering missing images and 403 errors.
Purge caches after correcting URLs
Old HTML can continue referencing the broken path until plugin, server and CDN caches are refreshed.
Migration image checklist
Use the symptom to choose the next check instead of changing several settings at once. Make one change, retest the exact URL, and keep a note of what changed.
| Symptom | What it suggests | Next check |
|---|---|---|
| Broken URL | Image points to old domain | Replace old URLs safely |
| 404 image | File path does not exist | Confirm uploads were migrated |
| 403 image | File exists but access is denied | Check permissions/security rules |
| Mixed content | HTTPS page calls HTTP image | Update image URLs to HTTPS |
Before you make a risky change
Take a current backup or restore point before editing configuration files, permissions, PHP settings or database URLs. Avoid deleting unrelated DNS, email, security or rewrite rules simply to see whether the problem disappears.
How to confirm the fix
Retest the exact public URL in a private browser window and, where relevant, on a second device or network. A fix is only confirmed when the original symptom is gone without creating a new error elsewhere on the site.
