SVG, Icons and Background Images: What Google Can Index

Many business owners believe that "Google can see every picture on my site." It sounds reasonable. The pictures are right there on the screen. But if you search Google Images for your own products, you may find only a few blog photos, while your big hero banners, crisp SVG diagrams and neat icon set are nowhere to be seen.

This is a very common surprise. Most business owners think an image is an image. But to Google, how a picture is added to a page matters as much as what is in it. A photo in an <img> tag, the same photo set as a CSS background, an SVG pasted straight into the HTML, and an icon drawn by a font are four very different things to a search engine.

Let me explain, in plain words, which of these Google can index, which it simply ignores, and how you can check your own pages in a few minutes. I will also help you decide which images are actually worth the trouble. Not every icon needs to rank.

The image formats Google says it can index

Let me start with the easy part. Google publishes a list of the file formats it supports for images in Search. According to its Google Images SEO best practices page (accessed October 2026), Google can index images in these formats: BMP, GIF, JPEG, PNG, WebP, SVG and AVIF.

So the format itself is rarely the problem. A modern AVIF or WebP file is just as indexable as an old JPEG. If you are switching formats for speed, my guide to WebP and AVIF next-gen image formats covers the trade-offs. And if you are brand new to this topic, our beginner lesson on alt text, file names and image speed is the right place to start before you read on.

The real question is not "what format?" It is "how is the image placed on the page?" Here is a quick map I use when I review a site.

How the image is added	Can Google index it as an image?	What Google gets from it
<img src="..."> in the HTML	Yes	The file, the alt text, the surrounding text and the page context
<picture> with <source> and an <img> fallback	Yes, through the <img> fallback	Same as above
SVG file referenced in <img src="logo.svg">	Yes	A standalone image URL that can show in Google Images
Inline <svg> code inside the HTML	Not as a separate image file	Any text inside it, plus a <title> description
CSS background-image	No	Nothing as an image
Icon font (a glyph drawn by a font)	No	At most a stray character in the text
Image injected by JavaScript	Only if it ends up in the rendered HTML as an <img>	Depends on rendering

Keep this table in mind. The rest of the article explains each row and what to do about it.

Why the img tag is still the front door for image search

Google is very clear on this point. Its image guidelines say Google can find images in the src attribute of the <img> element. That simple tag is the main way Google discovers a picture, ties it to a page and understands what it shows.

The same page also explains the role of alt text. In Google's words:

“The most important attribute when it comes to providing more metadata for an image is the alt text”

— Google Search Central, Google Images SEO best practices

Notice what that means. Only an image in an <img> tag can carry an alt attribute. A CSS background or an icon font has no alt text at all. So even before we talk about indexing, these other methods throw away Google's most useful clue.

What about the picture element?

Many modern sites use the <picture> element to serve different files to different browsers or screen sizes. That is fine. Google's page describes <picture> as a container that groups different <source> versions of the same image. But it adds one rule: always include an <img> element with a src attribute as the fallback.

If your developer builds a <picture> block with only <source> tags and no <img>, you are taking a risk. I suggest you check this in your theme, because I see it in custom builds from time to time. For the details of serving the right size to each device, see my guide on responsive images with srcset and sizes.

SVG files vs inline SVG code: two very different things

SVG stands for Scalable Vector Graphics. Instead of storing pixels, an SVG stores shapes as code: "draw a circle here, a line there." That is why SVG logos and diagrams stay sharp at any size. Ahrefs' older but still useful image SEO guide shows how small these files can get. In its example, an 8.54KB SVG dropped to 3.56KB after minifying and gzipping.

There are two ways to put an SVG on a page, and Google treats them differently.

SVG as a file

Here the SVG lives at its own URL, like /images/pricing-diagram.svg, and the page shows it with a normal tag:

<img src="/images/pricing-diagram.svg"
     alt="Diagram of the three pricing tiers and what each includes"
     width="800" height="450">

This works like any other image. It has a URL, it has alt text, and Google lists SVG as a supported format. If you want an SVG diagram or illustration to show in Google Images, this is the method to use.

Inline SVG

Here the SVG code is pasted straight into the HTML of the page:

<svg viewBox="0 0 24 24" role="img" aria-labelledby="phoneTitle">
  <title id="phoneTitle">Call us</title>
  <path d="M6.6 10.8 ..."/>
</svg>

Inline SVG has no URL of its own. So there is no image file for Google Images to show and no address to link to. It is part of the page, not a separate asset. Developers love it for icons because it saves a request and can be styled with CSS.

Google's image guide does give inline SVG one hook: for inline <svg> elements, you can use the <title> element to describe the graphic. Think of it as the inline version of alt text. MDN, the standard reference for web developers, explains how browsers treat it:

“Text in a <title> element is not rendered as part of the graphic, but browsers usually display it as a tooltip.”

— MDN Web Docs, <title> SVG element

MDN also notes that the <title> should be the first child of its parent element for backward compatibility. Small detail, but worth passing on to your developer.

Which one should you choose?

In brief, here is how I would decide:

• Decorative icons (arrows, ticks, social icons, a phone symbol): inline SVG is fine. They don't need to rank.
• Your logo: use an SVG or PNG file in an <img> tag with alt text of your brand name. This also helps if you want to mark up your logo with structured data, which needs a crawlable image URL.
• Diagrams, charts, maps and illustrations that explain something: use a file in an <img> tag, with a descriptive alt and a nearby caption. These are the SVGs that can actually earn image traffic.

One more note. If a diagram has important text in it, like labels on a process chart, don't rely on Google reading that text from inside the graphic. Repeat the key point in the page copy or a caption. That helps readers on small screens too.

Does Google index CSS background images?

No. This is the row of the table that surprises people most. Google's own documentation is short and direct:

“Google doesn't index CSS images.”

— Google Search Central, Google Images SEO best practices

A CSS background image is set in the style sheet, not in the HTML content. It looks like this:

.hero {
  background-image: url("/images/team-at-work.jpg");
}

Visitors see a lovely photo. Google sees a div with some text on top. The photo is treated as decoration, and in many cases, that is exactly right.

When a background image is the right choice

Backgrounds are perfect for textures, gradients, subtle patterns and big mood photos that sit behind a headline. If the picture adds atmosphere but no information, it doesn't need to be indexed. Leaving it in CSS is fine.

When it is a mistake

It becomes a problem when a meaningful image is set as a background. I see this often with:

• Product photos on ecommerce category tiles built by a page builder.
• Before-and-after photos on service pages, such as a roofer's or a dentist's work.
• Team photos that support trust on an About page.
• Infographics uploaded as a section background by a designer.

Each of these is a picture that a searcher might look for, and that helps Google understand the page. If yours are backgrounds, ask your developer to switch them to <img> tags. With CSS such as object-fit: cover, an <img> can look exactly like a background, so the design doesn't need to change.

Example: a hypothetical bakery homepage

Let me give you a simple example. Say a bakery homepage has 14 visual elements. When we list them, we find:

• 1 logo (SVG file in an <img> tag)
• 1 hero photo of a cake counter (CSS background)
• 6 product photos of cakes (CSS backgrounds on clickable tiles)
• 6 small icons for "delivery," "gluten-free" and so on (an icon font)

Of 14 visuals, only 1 is indexable as an image: the logo. The six cake photos are exactly what people search for in Google Images ("chocolate drip birthday cake"), yet none can appear. Switching those six tiles to <img> tags with descriptive alt text takes a developer an hour or two. The hero and the icons can stay as they are. This is the kind of small, focused fix I suggest, rather than rebuilding everything.

Icon fonts and CSS sprites: invisible to image search by design

Two older techniques still show up on many sites, especially those built on older themes.

Icon fonts

An icon font is a font file where each "letter" is actually a little picture: a cart, a star, a phone. The browser draws the icon the same way it draws text. To Google, there is no image here at all. There may be an empty element, or a strange character in a private part of the font, but nothing that resembles a picture.

That is fine for decoration. But there are two real issues to watch:

1. Icons used as the only link content. If a link contains only an icon-font glyph, it has no readable text. Google's link best practices say that when a link is empty, Google can fall back to the title attribute, and that for image links it uses the image's alt text. An icon font gives it neither. Add visible text or an aria-label plus a title, or switch to an SVG with a title.
2. Page speed. A full icon font can be large, and it often loads a whole set when the page uses five icons. For the font side of speed, see my guide on web font optimization.

CSS sprites

A sprite is one big image file that holds many small icons side by side. CSS then shows a small window of it in each spot. Sprites were a speed trick from the days when every request was expensive. Because sprites are CSS backgrounds, they fall under the same rule: not indexed. Again, for icons that is fine. Just don't put a meaningful product photo in a sprite.

Images loaded by JavaScript and lazy loading

Many sites now add images with JavaScript. Sliders, galleries, "load more" buttons, and lazy loading scripts all do this. Can Google index these images? Yes, if the final result is a normal <img> tag in the rendered HTML, and if Google doesn't have to click or scroll to trigger it.

The key point comes from Google's guide to fixing lazy-loaded content:

“Google Search does not interact with your page.”

— Google Search Central, Fix lazy-loaded website content

Googlebot doesn't click "Next" on your slider. It doesn't press "Load more." So any image that only appears after a click is likely to stay hidden from Google. The same page says your lazy loading should load content when it becomes visible in the viewport, and it lists browser built-in lazy loading and the IntersectionObserver API as methods that work. It also asks you to check that image URLs appear in the src attribute of the <img> element in the rendered HTML.

Here is a quick comparison of common patterns:

Pattern	Likely outcome for indexing	Safer alternative
<img loading="lazy" src="photo.jpg">	Fine. The real URL is in src.	Keep it, but don't lazy load the main image above the fold
Script that swaps data-src into src when in view	Usually fine if it uses IntersectionObserver	Test it in URL Inspection
Script that waits for a scroll event	Risky. Google may never fire it.	Use native lazy loading or IntersectionObserver
Gallery images that appear only after a click	Hidden from Google	Put the images in the HTML; use the click only to enlarge
Images set via JavaScript as CSS backgrounds	Not indexed (still CSS)	Render an <img> instead

Google also warns against lazy loading content that is likely to be visible right away when the page opens. That is a speed point as much as an SEO point, because it delays your main image. I cover the speed side in more depth in my article on lazy loading and SEO, and the wider rendering picture in JavaScript SEO for search-friendly sites.

Where image sitemaps help

If some images can only be found through JavaScript, an image sitemap is a useful safety net. Google's image sitemaps documentation explains that they help Google find images it might otherwise miss, such as those loaded with JavaScript. A few facts worth knowing from that page:

• Only two tags are needed: <image:image> and <image:loc>.
• Each <url> entry can hold up to 1,000 images.
• Google removed the caption, title, geo_location and license tags from its documentation, so you don't need to fill them in.
• Images on a CDN on another domain are fine, as long as you verify both domains in Search Console.

Remember: a sitemap helps Google find an image URL. It doesn't turn a CSS background into an indexable image on the page.

Deciding which images on your site deserve to be indexed

Here is the part most guides skip. You don't need every image indexed. Some images have search value. Others are simply part of the design. Trying to "optimize" everything wastes time and fills your HTML with useless alt text.

I sort images into three groups:

Group	Examples	Best method	Alt text
Search-worthy	Product photos, original diagrams, recipe photos, before-and-after work, location photos, charts with original data	File in <img>, crawlable, in rendered HTML	Specific and descriptive
Supporting	Team photos, logo, screenshots that explain a step	<img> tag	Short and accurate
Decorative	Textures, dividers, background gradients, arrow and tick icons	CSS background, inline SVG or icon font is fine	Empty alt="" if it is an <img>, or none

A simple test I use: "Would a real person ever search for this picture, or need it described to understand the page?" If yes, it belongs in the first or second group. If no, leave it decorative and move on.

Also, be careful not to stuff alt text with keywords. Google's image guide says plainly to avoid filling alt attributes with keywords. I see this a lot on local business sites, where every photo gets "best plumber in Dallas TX" as its alt. That is the image version of the problem I describe in my guide to city-name stuffing on local pages. And when an image is used as a link, its alt text becomes the anchor text, so the same care applies as in an internal anchor text audit.

One more point. Original images are part of what makes a page worth ranking. A custom diagram that explains a process can cover a subtopic better than three extra paragraphs, which ties into my method for covering the subtopics a query expects. And no "content score" tool will tell you that your best diagram is invisible because it is a background, which is one reason I am cautious about content optimization scores.

How to test what Google sees with URL Inspection

You don't need to guess. Google Search Console's URL Inspection tool shows you the page as Google renders it. Google's JavaScript troubleshooting guide recommends exactly this: use the URL Inspection tool or the Rich Results Test to check that the rendered HTML has all the content you expect.

Here is how I would do it, step by step:

1. Open Search Console and paste the page URL into the inspection bar at the top.
2. Click Test live URL. This fetches the current version of the page, not an old copy.
3. Click View tested page, then open the HTML tab. This is the rendered HTML, after JavaScript has run.
4. Use your browser's find function (Ctrl+F or Cmd+F) to search for the file name of an image you care about, for example chocolate-drip-cake.
5. Check where it appears. If you find it inside <img src="...">, good. If you only find it in a style attribute or a CSS file, it is a background. If you don't find it at all, JavaScript didn't load it for Google.
6. Open the Screenshot tab to see whether the image shows in Google's render. A blank space where a slider should be is a clear warning sign.
7. Check More info > Page resources for images or scripts that couldn't be loaded. A blocked script can stop images from appearing.
8. After fixes go live, test again and request indexing for the page.

Checking whether images actually get image traffic

Once your important images are in proper tags, watch the results. In Search Console, open the Performance report and change the search type to Image. This shows clicks and impressions from Google Images by page and by query. If your product pages start getting image impressions a few weeks after a fix, you know the change worked. If not, look at alt text, file names and page context next.

For a site-wide view, a crawler can help. Most SEO crawlers can list every <img> they find, with alt text, and many can render JavaScript. Compare that list with what you see on screen. Any important picture missing from the crawl is probably a background, a font icon or a click-to-load image.

Questions people ask about SVGs, icons and background images

Will Google show my SVG logo in Google Images?

It can, if the logo is an SVG file referenced in an <img> tag. SVG is on Google's list of supported formats. An inline SVG logo has no file URL, so it can't appear as an image result.

Is it bad for SEO to use CSS background images?

Not for decoration. Google simply doesn't index them, which is fine for textures and mood photos. It only hurts when a meaningful image, like a product photo, is set as a background and so can never appear in image search.

Do I need alt text on decorative icons?

No. If a decorative image is in an <img> tag, give it an empty alt="" so screen readers skip it. Icon fonts and CSS backgrounds don't take alt text. Only icons that carry meaning, like a lone "search" icon in a button, need a text label.

Does Google read text inside an SVG?

Text inside inline SVG code is part of the page's HTML, and the <title> element can describe the graphic. But I wouldn't rely on it for anything important. Put key information in normal page text or a caption as well.

Are WebP and AVIF images indexed like JPEGs?

Yes. Google lists both WebP and AVIF as supported formats. If you serve them through a <picture> element, include an <img> fallback with a src, as Google recommends.

Can an image sitemap fix images that are CSS backgrounds?

It can help Google discover the image file, but it won't make the image part of the page's content the way an <img> tag does. The proper fix is to change the markup.

A 30-minute image indexing check for your key pages

Let me wrap this up with a short plan you can follow this week. Pick your five most important pages: your homepage, your top two service or product pages, and two pages where pictures really matter to buyers. For each one:

• List the images that a buyer would actually care about.
• Run the URL Inspection steps above and check that each one is in an <img> tag in the rendered HTML.
• Flag any that are CSS backgrounds, icon fonts, sprites or click-to-load.
• Give your developer a short list: "switch these six to <img> tags, keep the rest."

That is usually all it takes. You don't need to rebuild your design, and you don't need to optimize every arrow icon. You just need the pictures that matter to be visible to Google.

If you would like a second pair of eyes, our team can review your images as part of a wider technical check through our SEO services, or tackle the speed side with page speed optimization. For a deeper dive into alt text and file names, read my full guide to image SEO. And if you want to talk about your site, get in touch for a free quote.

Further reading on svg background images seo

• Should URLs Include Dates or Categories?
• The Viewport Meta Tag and Mobile SEO
• Subtopic Coverage: Making a Page Complete Without Padding

Sources for this image indexing guide

1. Google Search Central: Google Images SEO best practices
2. Google Search Central: Fix lazy-loaded website content
3. Google Search Central: Image sitemaps
4. Google Search Central: Fix Search-related JavaScript problems
5. Google Search Central: Link best practices for Google
6. MDN Web Docs: <title> SVG element
7. Ahrefs: Image SEO guide