Why You Should Host Images on Your Own Domain
This notice flags images served from a domain other than your own, commonly called hotlinking, rather than from your own domain or CDN. You don't control an external host's uptime, caching, or whether they block hotlinking outright, and image search tends to favor images actually hosted on the page's domain. The fix is downloading and re-serving important images from your own server, CDN, or CMS media library.
What this means
This check compares the domain of every image's src against your site's own domain. Any image whose URL points at a different host gets flagged as external_image, a notice, the lowest severity level, because a single external image rarely breaks anything on its own. The pattern matters more than any one instance.
The most common cause is hotlinking: pasting an image URL from another website directly into your page instead of uploading a copy of that image to your own server. It also shows up when content gets copy-pasted from another CMS without re-uploading its images, or when an old blog post links to an image on a service that's since changed its URLs or shut down.
One honest limitation worth flagging: this check compares hostnames literally. If your images are served from a subdomain of your own CDN, say cdn.yoursite.com, or an asset host on a different domain you actually control, this check has no way to know you own that infrastructure and will flag it as external anyway. That's a false-positive-prone edge case, not a sign that using a CDN is a mistake; a huge share of well-run sites intentionally serve images from a separate CDN domain. Read this notice as "verify these images are actually hosted somewhere you control," not as "every flagged image is a problem."
Where it's a genuine problem is the classic hotlink case: an image sitting on someone else's server, that you don't own, don't pay for, and don't control, embedded directly into your page as if it were yours.
Why it matters
The core risk is availability you don't control. The site hosting that image can delete it, rename the file, redesign and break the path, rate-limit or block hotlinking outright, or simply go offline, and your page silently ends up with a broken image the next time anyone loads it. You won't get a warning when that happens; you'll just have a broken <img> tag until someone notices.
Hotlinking also means you don't control caching, compression, or format. An image server optimized for someone else's traffic patterns has no reason to serve you a fast, well-compressed, modern-format file, and some hosts deliberately serve hotlinked requests slower or replace the image with a placeholder or warning graphic once they detect the hotlink. Either way, your page's load time is now dependent on a server you have no relationship with.
There's a real image-SEO angle too. Image search generally attributes and indexes an image to the page and domain it's actually served from. An image hotlinked from elsewhere is still associated with the original host, not yours, so it does little to nothing for your own image-search visibility even if it displays correctly on your page.
Be fair about severity here: this is a notice, not a critical error, for good reason. A hotlinked image that happens to load fine costs you little today. The risk is entirely about tomorrow: the day the external host changes something and you find out via a broken page instead of a warning.
How to fix it
- 1
Find every externally hosted image
Re-run this audit or check your external_image issues list to see which images are flagged and on which pages. For a manual check, view page source and look at each <img src> for a domain that isn't yours. Prioritize images on high-traffic pages and anything load-bearing, like product photos or hero images, since those are the ones a broken link actually costs you traffic on.
- 2
Confirm which flags are real problems
Check each flagged image against your own infrastructure first. If the domain is a CDN, asset host, or subdomain you actually control and pay for, this is a false positive you can safely ignore; note it and move on. If the domain belongs to someone else entirely, a stock photo site, another company's blog, a service you don't have an account with, that's genuine hotlinking and worth fixing.
- 3
Download and re-upload the image to your own host
Save a full-resolution copy of the image, then upload it to your own CMS media library, your own server, or your own CDN, and update the src to point at your new copy. Check image licensing before doing this; hotlinking someone else's copyrighted image without permission is a separate legal problem that self-hosting a copy doesn't fix. If you don't have rights to the image, replace it with one you do have rights to, rather than just relocating it.
- 4
Optimize the image now that you own the copy
Since you're re-uploading anyway, take the opportunity to compress it, resize it to the dimensions it actually displays at, and convert it to a modern format like WebP or AVIF if your platform supports it. This is the same optimization work covered in fixing oversized images generally, and doing it while you're already touching the file is more efficient than a separate pass later.
- 5
Update the reference and verify
Point the src at your new self-hosted URL, confirm the image loads correctly, and check it's not still falling back to the old external URL anywhere (some CMSs cache image references separately from the visible content). Re-run the audit to confirm the notice clears for that image, and repeat for the rest of your prioritized list.
Example
<!-- Before: hotlinked from a third-party domain you don't control -->
<img src="https://someotherblog.com/uploads/2023/product-photo.jpg" alt="Product photo">
<!-- After: self-hosted on your own domain or CDN -->
<img src="https://yoursite.com/images/product-photo.jpg" alt="Product photo" width="800" height="600">
<!-- Also fine: your own CDN subdomain, even though a naive hostname
check may still flag it -->
<img src="https://cdn.yoursite.com/images/product-photo.jpg" alt="Product photo">Self-hosting means the image lives on infrastructure you control, whether that's your main domain or your own CDN subdomain.
Platform-specific steps
Use Media > Add New to upload a local copy of the image, then update the post or page to reference the new Media Library URL instead of the external one. If external images were pulled in via an RSS import or content-scraping plugin, check that plugin's settings for an 'import images locally' option so future content doesn't reintroduce the problem.
Upload the image under Content > Files or directly within the product or page editor's image picker, then swap any theme or content block pointing at an external URL to reference the uploaded file instead. This is most common on pages built with raw HTML in a Custom Liquid section, where an external URL was pasted in directly.
Upload the image to the platform's native Media Manager (Wix) or the built-in image block (Squarespace), then replace any embed or code block that references an external image URL with the platform's own image element. Both platforms automatically serve uploaded images from their own optimized CDN once uploaded.
Save the image into your project's /public directory or your own object storage (S3, Cloudflare R2, your own CDN) and reference it with a relative or your-domain URL. In Next.js, import local images directly or use next/image with your own domain configured, rather than pointing the src at a third-party URL.
Frequently asked
Yes. Serving images from your own CDN or asset subdomain, embedding a third party's own widget (a map tile, a payment badge, a verified review platform's image) that's meant to be loaded from their servers, or intentionally linking to external content are all normal and not the problem this notice is about. It's specifically about hotlinking someone else's hosted image as if it were your own content.
This check compares hostnames directly, so an image served from cdn.yoursite.com while your site is www.yoursite.com gets flagged even though you own and pay for that CDN. That's a known limitation, a false positive, not a real hotlinking problem. Confirm you actually control the flagged domain before spending time fixing it.
Not as a direct penalty, which is why this is a low-severity notice. The damage is indirect: broken images when the external host changes something, slower loads since you don't control the other server's performance, and weaker image-search visibility since image search tends to attribute an image to the domain actually serving it, not yours.
Yes, and many do. A common defense against hotlinking is checking the request's referrer and serving a broken image, a placeholder, or an explicit 'hotlinking not allowed' graphic instead of the real file to any request coming from a different domain. If a hotlinked image on your site suddenly turns into a warning graphic, that's what happened; the fix is the same either way, host your own copy.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.