A missing image can interrupt a page, hide a product or make a button difficult to understand. The right correction depends on the requested file and the response it receives. This guide helps you gather useful evidence before changing your website, whether it uses WordPress or another application.
1. Define the problem
Choose one specific page and image. Note whether the problem affects one image, a particular size or the entire site, then compare desktop and mobile views and test while signed out of your administration area. Record recent changes: a migration, new domain, theme change, plugin or media optimization.
Keep a backup before replacing files or changing configuration. Test one correction at a time, preferably on a staging copy when changes affect several pages. An improvement after several simultaneous changes does not establish which change was necessary.
2. Identify the image actually requested
In WordPress, open Media > Library, select the file and inspect its URL. The Media Library documentation distinguishes the file URL from its attachment page. Compare that address with the one used on the affected page.
For more detail, open your browser’s developer tools, select Network and reload the page. Select the image request to inspect its address, status, preview and any redirects. The Chrome Network guide explains these checks.
A browser may request a thumbnail or a different variant depending on the screen, including through srcset or picture. A background image may come from CSS. A working original in the Media Library therefore does not prove that the file requested by the page exists.
3. Interpret the result
- 404 or 410: the file is unavailable at that address or has been removed. Check the path, filename, capitalization, extension and files transferred during a migration. An old domain or missing thumbnail deserves investigation.
- 403: access is denied. File permissions, an access rule, hotlink protection or a security control may be involved. This status alone does not identify which setting should change.
- Redirect: inspect the final destination. An image redirected to a login or error page will not provide the expected file.
- 500, 502, 503 or 504: a server or gateway error requires investigation. Record the time and affected address to help locate relevant log entries.
- 200 but no visible image: check the preview and content type. The response may contain HTML instead of an image, or the file may be damaged. If the image arrives correctly, next examine how the theme, CSS and lazy loading display it.
The HTTP status reference explains these response groups. A DNS error, certificate problem or browser block can also prevent a usable HTTP response.
4. Correct the affected address or media file
If the link is wrong, correct it in the page, block, theme or setting that generates it. Compare the exact filename, including capitalization: Logo.jpg and logo.jpg are not necessarily interchangeable. After a migration, also confirm that the media files were actually copied.
If only one format or size is missing, identify the tool that produces that variant before regenerating it. Preserve originals and avoid bulk database replacements or deleting media without a backup. For an image hosted by a third party, confirm that you are allowed to use it and embed it on your website.
5. Check HTTPS and access rules
On an HTTPS page, an HTTP image address may be automatically upgraded to HTTPS or blocked, depending on its use. Correct the source to use a working HTTPS address with a valid certificate. Check console messages and the mixed content guide without disabling browser protections.
If cPanel Hotlink Protection is available and enabled, check the permitted domains, including your own subdomains. Opening an image on its own and embedding it in a page are not always equivalent tests: rules can treat direct requests differently.
An image CSP policy can also restrict permitted sources. Have the relevant rule confirmed before making a targeted adjustment. Do not make files writable by everyone or globally disable the firewall, ownership checks or server protections.
6. Check caches and optimizations
After correcting the cause, refresh the affected page or file cache in the tools actually in use: browser, plugin and, if applicable, CDN. A cache may still reference an old address. Repeatedly purging everything does not repair a missing file.
If you use LiteSpeed Cache for WordPress, inspect media features according to the symptoms: a missing WebP or AVIF variant, image replacement or lazy loading. The media troubleshooting documentation provides relevant checks. Test a targeted exclusion on a copy of the site when lazy loading is suspected, then restore the setting if the test does not confirm a cause.
7. Validate and get help
Repeat the original scenario, including on mobile and while signed out of WordPress. Check several pages using the same media and the affected variants.
If the issue persists, open a request in your Nuagerie Client Area with the affected page, image address, observed status, time and recent changes. Remove personal data, cookies, tokens and private access parameters from screenshots or addresses you share. Our team can help direct the investigation toward hosting, media delivery or the application. If a theme correction or broader repair is needed, we can assess its scope with you. To discuss a project, use our contact form.
