Why Aren’t My Images Showing in Google Images?

A photograph can look perfectly normal on your website and still be difficult for Google to find or download. Or Google may have indexed it without showing it for the words you tried. These situations need different responses.

Use the checks below on one important image before changing your whole image library. You will need its page address and its direct image address. If you do not manage the website's technical settings, collect the evidence and send it to your developer or hosting provider.

No access to Search Console? Start with the image's public address, then check crawl and indexing rules and how the page displays the image. These browser checks do not require a Search Console account. Send the site owner both addresses, the date and any failed check, then ask them to inspect the page in Search Console.

1. Establish what is actually missing

Think of the process in four stages: Google discovers an image address, downloads the file, decides whether to index it, then selects results for a particular search. The checks below help you work out which stage needs attention.

Start by asking whether the image has never appeared, disappeared after a change, or simply does not appear for a competitive phrase. Also distinguish a missing result in the Images tab from a missing thumbnail beside a normal web result. This guide focuses on Google Images; Google chooses web-result thumbnails separately.

In Search Console's Performance → Search results report, select the Image search type and filter by the relevant page. Look at impressions as well as clicks, and compare dates before and after any change. Google's Performance report documentation explains these filters.

Image-search impressions show that results associated with the page were displayed. They do not identify every photograph on a page with several images. A lack of impressions in the selected period does not prove that indexing has failed: there may have been little demand or visibility.

For a quick search check, try site:example.com in Google Images. For a particular file, use src:https://example.com/images/blue-mug.jpg, replacing the example with its full public address. The src: operator finds pages referencing that image URL. Neither search shows every indexed image, so empty results alone do not prove that Google has not indexed it. See Google's explanation of site: search limitations.

2. Inspect the page that contains the image

In Search Console, enter the page URL into URL Inspection. Start with the product page, article or service page visitors would open, rather than the address ending in .jpg or .webp.

1. Read the indexed result. Expand Page indexing and note the reason if the page is not indexed. Use the table below to choose the next action.
2. Check the canonical in that result. This is the preferred version of a page. Compare User-declared canonical with Google-selected canonical. If Google chose another URL, open it and check whether it is the intended version.
3. Choose Test live URL. This tests the current page, while the indexed result describes Google's previously processed version. Differences can be expected after a repair.
4. Open View tested page when available. In the HTML tab, search for the image filename or delivery URL. Under More info, review resource failures and JavaScript errors. If the test cannot reach the page, investigate the reported access failure first.

These findings describe the page’s status, not the indexing status of each image. Google's Page indexing report guide explains the statuses. If the page is indexed, continue with the image checks below.

The live test checks current access and rendering; it does not decide Google's canonical choice or confirm indexing. Its test crawler can also receive a different response from the crawler used for normal search. Use the URL Inspection guide to interpret the indexed and live results together.

3. Check the exact image file and its response

On the published page, right-click the picture and choose an option such as Open image in new tab. Copy that address. If the page uses several sizes, the browser's Network panel can help identify the requested version. Our responsive images guide explains why mobile and desktop may request different files.

Open the direct image address in a private window without logging in. If it fails there, investigate access before changing alt text. If it works, you have checked anonymous browser access; this alone does not prove Googlebot receives the same response.

For a closer check, open browser developer tools and select Network. Reload the page, filter by Img and choose the request for the affected picture. Under Headers, check the status and response headers; use Preview to confirm the picture. Labels vary slightly by browser. A fresh successful download should contain the actual image, with a matching Content-Type such as image/jpeg or image/webp. An HTML login or security challenge is not the image, even if its address ends in .jpg.

Fix a missing or inaccessible file before continuing to indexing settings. Google's HTTP status documentation explains how these responses affect crawling.

If only Google's requests appear to fail, ask the host to inspect relevant server or CDN logs. A CDN is the delivery service that may host your images separately from your website. Request the affected URL, response status and matching security rule. Avoid disabling the site's protection wholesale or trusting a request solely because it calls itself Googlebot; Google documents how to verify its crawlers.

4. Check crawl blocks and image indexing rules

Open /robots.txt at the root of the host serving the image. For a picture at https://images.example.com/uploads/mug.jpg, check https://images.example.com/robots.txt. The rules at www.example.com do not govern a separate image host.

For example, this rule blocks Googlebot-Image from the /uploads/ path on that host:

User-agent: Googlebot-Image
Disallow: /uploads/

This is a possible block to investigate, not a rule to add. Google uses the group with the most specific matching user agent. A matching bot-specific group is not combined with the general User-agent: * group; multiple groups for the same matching agent are combined. Ask the maintainer to check which group and path rules actually apply before changing anything. See Google's robots.txt matching rules.

Find indexing instructions in the page and image response

On the public page, use View page source and search for robots, googlebot and noindex. Look for an actual <meta> tag in the page's <head>, not just a mention in its content. If JavaScript changes the page, inspect its <head> in the browser's Elements panel too. An image-specific block in the page can look like this:

<meta name="robots" content="noimageindex">

Then select the image request in Network and look under Headers → Response Headers for X-Robots-Tag. This is a server response header, not an HTML tag:

X-Robots-Tag: noindex

Both examples show restrictions to investigate. Their effects differ:

• Page-level noimageindex: prevents images from being indexed through that page. The same file may still be indexed through another page.
• X-Robots-Tag: noindex on the image response: directly tells Google not to index that image.
• Page-level noindex: excludes the page itself. Investigate it when the public landing page should be searchable.

For the page's own indexing status, check its HTML and response headers: noindex can be supplied through either. If a restriction is unintended, change the setting that generates it and verify the public response afterward. Keep intentional restrictions in place.

Crawl blocks and indexing instructions are different. Google must be able to fetch a resource to read its indexing header. Removing one restriction does not remove another. Google's image removal guidance describes image-specific controls, and its robots directive reference explains page and HTTP-header rules.

5. Check whether the page exposes a real image source

A picture visible to a visitor is not necessarily an ordinary HTML image. In the page editor, check whether it was added as an image, a background or a custom gallery component.

For content you want people to find in Google Images, use an <img> with a real src. A <picture> element should include that image fallback. Google explicitly says it does not index CSS images. See its image SEO guidance.

<img src="/images/blue-ceramic-mug.webp"
     alt="Blue ceramic mug with a curved handle">

The description here is an example for a product photograph. Use words that match your own picture and its purpose. If the image is only decoration, keeping it as a background can be appropriate; it does not need an image-search result.

JavaScript is not automatically the problem

Google renders JavaScript, so a script-generated image is not automatically excluded. A failed script, blocked dependency or missing data request can still leave the rendered page without the picture. Compare the browser's result with the tested page in Search Console instead of assuming the two are identical. Google's JavaScript SEO guide explains rendering and common limitations.

Look closely at lazy loading and galleries

A placeholder with the real address stored only in data-src needs working code to turn it into an image source. A gallery that loads pictures only after a click also deserves inspection: Google does not interact with the page like a visitor.

Use a tested implementation that exposes the image URLs without requiring interaction. Native loading="lazy" is different from a script that withholds the source until someone acts. Check the rendered HTML, not just whether the gallery works when you click it. See Google's lazy-loaded content guidance and our lazy loading guide before changing settings across the site.

6. Review recent image URL and format changes

If visibility dropped after a migration, CDN change or optimization plugin update, compare an old image URL with the current one. Include generated thumbnails and mobile versions, not just the original media-library file.

Suppose /uploads/blue-mug.jpg was replaced with /images/blue-mug.webp. Check that published pages reference the new file, the new address works and the old address has an appropriate permanent redirect if the new image replaces it. Redirect to the corresponding picture, rather than sending every missing image to the homepage. Google's URL migration guidance includes image resources.

WebP and AVIF are supported by Google Search. A format change alone does not explain a missing result. More useful questions are whether the file address changed, whether access rules changed and whether the page still exposes the right image. Our WebP vs JPG guide covers choosing the format itself.

Also check for temporary delivery links that expire or change with every visit. A signed URL that works today may fail when fetched later. For a public website image, ask the delivery provider for a persistent public address. Do not remove an authorization token from a URL blindly; that may simply break the link.

7. Check discovery through an image sitemap

Once the page and file work, inspect the sitemap your website already produces. An image sitemap can help Google discover image addresses. You can add image entries to an existing sitemap or use a separate one; a second file is not inherently better.

In an image sitemap, the page's <loc> identifies the containing page, while <image:loc> identifies the image file. Check that the listed pictures are current, public and attached to the intended page. Google's image sitemap documentation includes the XML structure and CDN support.

If your publishing system already creates these entries, check its output before adding another plugin. A sitemap cannot repair a broken image response, remove an indexing restriction or make Google include every submitted picture. Treat it as a discovery aid.

8. If the technical checks pass, review the page's usefulness

At this point, avoid repeatedly converting or renaming the file without evidence of a problem. Review the image in context: does it explain the product, demonstrate the work or illustrate the article? Is there useful text beside it that helps a visitor understand what it shows?

Imagine a renovation photo on a page titled only “Gallery,” with no explanation of the project. A more useful page could identify the type of work, describe the visible result and explain relevant details. This gives the visitor a reason to open the page after finding the photograph.

Write relevant alt text and a clear filename without stuffing either with keywords. Neither replaces access and discovery checks. Use the alt text and filename guide for examples, rather than giving every image the same search phrase.

Check clarity and loading too. If excessive dimensions are part of the problem, resize a copy of the image while keeping important details readable. The slow-loading images guide helps distinguish file size from other loading delays.

9. Verify the change and give Google time to revisit

Keep a short record: page URL, image URL, the problem you found, the change and the date. Recheck the published page and direct image response after deployment. This prevents a local edit or editor preview from being mistaken for a live repair.

After fixing a problem on a page you manage, use URL Inspection's live test and request indexing when appropriate. If the page is simply marked Crawled – currently not indexed and nothing has changed, do not keep resubmitting it. For changes across many pages, keep the sitemap current. Google's recrawl guidance says crawling can take days to weeks, repeated requests do not speed it up, and inclusion is not guaranteed.

Follow the page's crawl information and compare image-search performance after Google revisits. These crawl times are not a deadline for an individual image. If the original failure persists, return to that check. If it is resolved but visibility stays low, review the image's relevance and the searches it might reasonably serve.

Example: a gallery lost visibility after a redesign

Imagine a furniture business whose project gallery loses image-search impressions after a redesign. The project page is still indexed and the photograph's URL returns the correct picture. Comparing the old and new templates reveals that an ordinary image was replaced with a CSS background:

<div class="project-photo"
     style="background-image: url('/images/oak-table.jpg')">
</div>

The photograph is meaningful project content, so the developer restores an image element:

<img class="project-photo"
     src="/images/oak-table.jpg"
     alt="Oak dining table with tapered legs in a finished kitchen">

The image address stays the same. The developer checks the layout on desktop and mobile, then confirms that the published page and Search Console's rendered HTML contain this <img> and its src. The developer then monitors image-search performance after Google revisits. Recompressing the JPG would not have repaired the template.

Frequently asked questions

My page is indexed. Why is its image still missing?

That status applies to the page. Continue with the image response, image-specific rules and the image source in the rendered page. These checks narrow down what happens to the picture itself.

Do I need to upload the picture directly to Google?

For an ordinary website image, publish it on an accessible page and make its source discoverable. Requesting a page recrawl or submitting a sitemap is not the same as uploading a picture into Google Images.

Will adding alt text make the image appear?

Alt text describes the image for people who cannot see it and helps explain its subject. Write it to match the picture's role on the page. For a missing image, check access and implementation before treating its description as the cause.

Should I convert WebP images back to JPG?

Not simply because they are absent from your searches. Check the implementation first. Changing formats again can introduce more addresses and replacements without resolving the underlying problem.

Can Pixilo fix image indexing?

Pixilo can help prepare suitable image files. Website access rules, page markup, sitemaps and Search Console checks need to be handled in your website or hosting setup.

Summarize withChatGPT (opens in a new tab)Grok (opens in a new tab)Google (opens in a new tab)Perplexity (opens in a new tab)Claude (opens in a new tab)