Are SVGs really indexed as text or images?

Why does Google make this distinction between inline and external SVGs?

The answer lies in the technical nature of the SVG format. Unlike PNGs or JPEGs, which are opaque binary files, SVG is a readable XML language. When you directly integrate it into HTML using a <svg> tag, the browser and the bot consider everything inside as part of the DOM.

Google parses this content just as it would parse text within a <div> or a <span>. The title, desc, or even text tags within the SVG are read and indexed. Conversely, when you link an external SVG using <img src="icon.svg">, the engine does not open the file to read the XML: it behaves like it would for any image, relying on the alt attribute, page context, and filename.

How does this change the indexing of my graphic content?

The difference is significant if you use SVGs to convey information (charts, diagrams, infographics, annotated icons). An inline SVG can carry invisible indexable text for the user but exploitable by Google. Imagine a technical diagram with <text> describing each step: that is rich content for SEO.

In external cases, this potential disappears. Google will only understand that it is an image, will try to deduce its subject via adjacent text and alt, but will never read the internal XML. If your external SVG contains <title> or <desc> tags, they remain invisible to the engine.

Is the text in an inline SVG really treated like standard text?

Yes, Google indexes it just like a paragraph of HTML. This means that if you stuff an SVG with invisible keywords or hidden text to deceive the engine, you risk a penalty for cloaking. The reverse is also true: a well-structured SVG with semantic tags can enhance the thematic relevance of a page.

Be cautious, however: just because it is indexable doesn’t mean it is considered with the same weight. Google may apply a different weighting factor to SVG content than to standard visible text—the official documentation does not specify anything about this, so be careful with extreme interpretations.

• Inline SVG = HTML content: internal XML is parsed and indexed as text.
• External SVG = standard image: only the surrounding context (alt, caption, adjacent text) is utilized.
• Exploitable semantic tags: <title>, <desc>, <text> in inline are read by Google.
• Cloaking risk: do not abuse hidden text in inline SVGs to stuff keywords.
• No XML reading externally: even an alt in the SVG file will not be considered if the SVG is loaded via <img>.

Does this statement align with field observations?

Overall yes, but with significant gray areas. Several tests conducted by SEOs confirm that text in an inline SVG appears in Google snippets if the query matches that text. However, there is a lack of precise data on the true weighting of this content relative to standard HTML text.

Google does not say whether a word in a <text> SVG has the same weight as a word in a <h2> or a <p>. It’s likely not, especially if the text is visually small or hidden. Mueller's statement remains intentionally vague on this matter. [To be checked]

What nuances should be added to this rule?

The first nuance: not all inline SVGs are equal. A dynamically generated SVG with client-side JavaScript, injected into the DOM after the first paint, can evade initial crawling if Google does not re-execute the JS. Always check the rendered version in Google’s cache or via the URL inspection tool.

The second nuance: the use of ARIA tags and role attributes. If you mark your SVG with role="img" and aria-label, Google may prioritize the aria-label over the internal textual content. In this case, indexing could resemble that of an external image. Nothing is officially documented, so be cautious.

In which cases does this rule not fully apply?

If you use SVG sprites with <use> to reuse symbols, the content of the <symbol> defined in an external file is unlikely to be indexed, even if the <svg> is inline. Google does not follow external references as it would for text content.

Another edge case: compressed or minified SVGs without spaces or line breaks. Technically indexable, but if the textual content is buried in thousands of path coordinates, Google may ignore or underweight that block. Code readability matters, even for a bot.

What should be done to optimize inline SVGs?

Start by auditing all SVGs on your site: identify which are inline and which are external. For strategic inline SVGs (logos, diagrams, infographics), always add a <title> and <desc> tag with a clear and concise description. These tags are read by screen readers AND by Google.

If your SVG contains visible text (labels, captions), ensure it is in <text> tags and not rendered as a path. Text vectorized in a path is invisible to Google. Also, avoid white text on a white background or hidden via CSS: this is outright cloaking.

What mistakes should be avoided with external SVGs?

Never rely on internal XML content of an external SVG for SEO. Even if you carefully filled in the <title> and <desc> tags inside the .svg file, Google will not read them. The alt attribute on the <img> tag then becomes critical: it must be descriptive, unique, and contextual.

Another common mistake: using external SVGs for decorative icons without empty alt. If the icon does not provide any information (decorative arrow, separator), set alt="" so that screen readers and Google ignore it. Otherwise, you pollute the index with noise.

How can I check if my SVGs are correctly indexed?

Use the URL inspection tool in the Search Console and check the rendered HTML version. Ensure the textual content of your inline SVGs clearly appears in the source code captured by Google. If it does not, there is probably a JS or deferred loading issue.

You can also perform a Google search with site:yourwebsite.com "exact SVG text". If the text appears in the results or snippets, it is indexed. Otherwise, investigate: the SVG may be external, or the text may be in path, or it may be hidden by a display:none.

• Audit all SVGs on the site (inline vs external)
• Add <title> and <desc> in strategic inline SVGs
• Check that visible text is indeed in <text> tags and not in paths
• Fill in the alt attribute for all external SVGs (or alt="" if decorative)
• Test indexing via the URL inspection tool and site searches:
• Never hide SVG text to stuff keywords (risk of cloaking)