WordPress images broke after a domain change? Read the URL

An illustrative request such as oldsite.co.uk/wp-content/uploads/2023/09/project-background.jpg tells you more than a blank section ever will. The page may now load perfectly at newsite.ae, but that background image is still being requested from the previous hostname.

It is an irritatingly common migration finish line. The homepage looks respectable, the new domain resolves, somebody signs it off, then a portfolio page opens with an empty hero panel and half the visual evidence has gone missing. For Dubai, UAE, UK and Liverpool businesses, that can leave service, product and project pages looking thin just when a referral is checking whether the business looks credible.

Find the broken reference before replacing the image. Reuploading a file might hide the symptom on one page, but it does not explain why WordPress, a builder, a stylesheet or a cached generated file was still asking the old domain for it.

The failed request is the useful bit

Open the affected public page in a browser, inspect the failed image or background request, then record the full requested URL and its response. Do not start by editing the page builder, clearing every cache or reuploading media. They are popular first moves because they feel active. They also muddy the evidence.

A 404 response from the old hostname points in a different direction from a 404 response on the new hostname. A request that redirects to the new host but still fails has another route again. If the URL is correct but the file cannot be found, you are dealing with file availability or a deployment omission. If the URL contains the old host, the file may be sitting safely in uploads while the page is simply asking the wrong address.

WordPress’s own migration guidance warns that old URLs can remain in the database and themes after a move. That is why each failed media request should be treated as evidence, rather than proof that the image itself has vanished.

Is the image missing, or is the page asking the wrong domain?

When WordPress images are broken after a domain change, inspect the failed asset URL, its HTTP response and whether the same file exists under the current uploads path. Old-domain requests usually indicate a stale stored reference. A current-domain 404 may indicate a missing file, incomplete deployment, incorrect uploads path or a case-sensitive filename mismatch. The page HTML loading successfully does not confirm that every media reference migrated with it.

This distinction matters. A project manager can spend an afternoon reuploading images that were never missing, while the original stale reference remains inside a page-builder field or generated CSS file. Bit of a waste of everybody’s Tuesday.

Trace the ownership of the reference

Once you have the exact failed URL, work backwards from where it appears. An ordinary image in WordPress content may be stored in the post content. A background image is more often held in builder data, theme settings, custom CSS, template data or generated files. The same visual may exist in several places, which is why a database-wide replacement without a backup is not a repair plan.

• Page content: inspect the page or post source and the relevant editor fields.
• Builder data: check the section, column, module or template that owns the background image.
• Theme and custom CSS: search for the old hostname in child theme files, customiser CSS and site-specific settings.
• Generated assets: compare generated CSS or builder asset files with the current page configuration.
• Uploads storage: confirm the expected file exists at the new domain’s actual uploads location before changing references.

A boring but useful detail: background images often do not appear as visible image blocks in the editor. They can be saved as a URL inside a responsive background setting, then written into generated CSS. Editing the image library will not touch that reference.

A portfolio page with an old background request

Take a portfolio page that works on its new domain except for the full-width project image behind the opening section. The page source requests oldsite.co.uk/wp-content/uploads/2023/09/warehouse-fitout.jpg and receives a 404. The same filename exists at newsite.ae/wp-content/uploads/2023/09/warehouse-fitout.jpg.

The sensible correction is to identify the builder template or generated asset holding the old hostname, update that one reference or apply a scoped replacement where appropriate, then regenerate only the affected builder assets. Replacing the image manually may make the section look right, but it can leave another old-host reference behind in the template, mobile layout or cached stylesheet.

If requests are already reaching the new hostname but returning 404, do not assume a stale URL search will solve it. Check the actual file path, deployment records, uploads directory and filename casing first. If whole routes rather than individual media files are failing after the move, the issue may sit elsewhere in the migration path, such as the rewrite setup covered in this guide to WordPress 404 errors after a migration.

Make one scoped correction, then test public pages

Before editing data, take a current backup and note the old hostname, replacement hostname and affected asset types. Search narrowly where possible. A careless global find-and-replace can alter URLs that were intentionally different, including staging references, external assets or old documentation.

Then verify the repair from the public side:

1. Open the affected page in a private browser window.
2. Confirm the failed image request now uses the current domain.
3. Check desktop and mobile variants where a builder stores separate backgrounds.
4. Inspect related templates, such as portfolio archives and project pages.
5. Regenerate only the relevant generated assets if the builder requires it, then retest.

This is the point where wider website repair support in Dubai can be useful, particularly when a migration has left a mixture of media, templates and generated files pointing in different directions. The fix should match the evidence, not the level of annoyance.

Keep the migration correction tied to the commercial pages

Start with pages that help somebody decide to enquire: key services, portfolio work, location pages, case material and contact routes. Broken imagery on a forgotten blog post is still worth sorting, but a missing project background or clinic treatment image can strip context from the page that does the selling.

For a broader move, it is also worth planning the migration around visible conversion routes rather than treating it as a server-only job. Our notes on website migration without losing enquiries cover the adjacent problem of keeping useful visitor paths intact while the site changes underneath them.

Send an affected page and a failed image URL so the remaining migration references can be traced.