On pages that have many SVG images, it would be desirable to inline all the svg images since this will reduce the number of HTTP requests and significantly reduce the size of all SVGs combined because when all the SVGs are in a single page, compression is much better than when they are each in their own separate file.

The problem with inlining SVG images is that they would not be indexed because they are not separate files. The obvious solution to this is to have all SVG images avaiable as individual files, and let search engines know the URL of each inlined SVG image, so that it can be indexed.

I found 3 possible ways of doing this:

1) Use a <noscript> element with an <img> element inside, just after the inlined <svg>, which looks like this:

<svg aria-labelledby="svg-title-id" role="img">
  <title id="svg-title-id">Image alt text</title>
  <img src="file-with-same-content-as-inline-svg.svg" alt="Image alt text" >

Note that both the <title> of the inline SVG as well as the <img> alt attribute have the image alt text.

2) Using structured data mark up:

<script type="application/ld+json"> {
  "@context": "http://schema.org",
  "@type": "WebPage",
  "image": [

3) Use an image sitemap:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"

      <image:title>Image alt text</image:title>

      <image:title>Image alt text</image:title>


Which of the above approaches is preferred in order to have inline SVG images indexed?

Or is there a better way?

  • It probably isn't worth your time and effort to get your images indexed in Google Image Search. Most users don't even click through to your site. Of the ones who do, you will find that they don't convert well. I'v found conversion rates to be 20 to 100 times better for desktop web search compared to image search. – Stephen Ostermiller Aug 9 '18 at 18:00
  • @StephenOstermiller, I thought about that, but I've found that Google uses those SVG images when displaying the snippet in SERP on mobile devices. Also, Google displays those images in Answer Boxes. So I think that it does make sense to have them indexed. – cute_ptr Aug 9 '18 at 18:16
  • 1
    Any of those 3 should work -- however, especially for structured data & special search features, double-check that SVGs are actually usable there (often only a set of formats are supported) before spending too much time on this (or alternately, if necessary, serve them as GIF/PNG/etc instead for indexing). – John Mueller Aug 19 '18 at 20:53
  • @JohnMueller thanks for the response. In the end, I decided to use the <noscript><img> approach, mainly because it gives the image more context since the <noscript><img> appears right after the inline <svg> and thus has relevant text around it. – cute_ptr Aug 22 '18 at 14:54
  • I would recommend keeping SVG files separate from the HTML files and instead focus on upgrading to HTTP/2 to avoid the overhead of transferring the SVG images once. Rationale: (1) if the same SVG image is used on multiple pages, referring to the same SVG will reduce the amount of data that needs to be transferred. Make sure to allow caching. (2) HTTP/2 will allow compression over multiple different files so you get the same (or better) compression with multiple files over HTTP/2 as your suggested implementation over HTTP/1.1. – Mikko Rantalainen Dec 4 '18 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.