Skip to: Navigation | Content | Sidebar | Footer


Weblog Entry

Image Replacement + Google

May 05, 2008

At An Event Apart in New Orleans a few weeks back, something that Aaron Walter said on stage caught my attention.

During the portion of his talk where he discussed image replacement and its impact on findability, he addressed the white elephant question that has likely occurred to most designers who have used image replacement over the past five years or so: what does Google think of CSS image replacement, anyway? But the part that surprised me is that he actually had an answer: Google’s okay with it, you won’t be penalized for using image replacement properly.

Though I’ve long believed this to be true, I had never heard a conclusive answer. One assumes Google is smart, and their algorithms ought to know the difference between keyword-stuffed text and plain English content written for real people. For example, I’ve often wondered if the potential to abuse image replacement and load invisible text with keywords was akin to, say, the potential to stuff keywords into the alt text of img elements, or even into meta tags. The net result seems similar in all three cases: otherwise-invisible text on a page that could unduly influence Google’s ranking. Presumably whatever algorithms they use to detect keyword-stuffing on the other two elements would equally apply to text hidden with CSS.

Not to mention the more compelling evidence that numerous sites I’ve built using image replacement techniques fare well in Google’s ranking. That fact alone indicates that Google won’t ban a site for simply making use of image replacement techniques (though I’m sure they’ve banned numerous sites using the technique in a sneaky, black hat SEO manner).

But again, I’ve never heard of an official blessing from Google. So I did some searching, and asked him for some follow-up (thanks, Aaron!), and here are the relevant resources that came out of that conversation:

Hidden text and links

The second bullet (“including text behind an image”) accurately describes a few image replacement techniques. It’s mentioned in the context of being a potentially untrustworthy activity, followed by a warning of the consequences of using it incorrectly. However, further down the page, the focus changes to techniques used for the sake of accessibility and why you would want to describe something search engines or users with assistive technology may not be able to access. This is a fairly accurate description of the intent behind image replacement. The article also suggests a handy rule of thumb for judging these techniques on your own: show the Googlebot the same thing your visitors see. Properly-used image replacement passes that test.

Best Uses of Flash

See point #2 in regards to sIFR, an ideologically similar concept to CSS image replacement, which suffers from the same potential abuse vectors. As this is a Google blog, it appears sIFR has an official blessing. Also mentioned in this article is a similar guideline to the previous one: show users and the Googlebot the same content. Sensing a theme here?

Working with Flash, images, and other non-text files

More of the same. Provide text alternatives for non-crawlable content, sIFR’s great, etc.

So it appears that, short of a set of stone tablets carried down from the hills of Mountain View, we do have a fairly clear answer. Using CSS image replacement in a responsible way, where the image truthfully represents the content it’s replacing, is safe to use. The simple act of hiding text from users is not enough to get your site banned from Google’s index.


Reader Comments

Skip to Form

May 05, 15h

Very good news Dave although not really surprising to me; I mean, that’s how things are expectedto work in the modern Web.

In my opinion, generally speaking, when something non-textual has to replace something textual (via CSS, for instance), the textual fallback representation must always be provided: first, because we care about users; second, because we also care about “special” users such as bots and source analyzers like those of Google ;)

Of course it is good to know that Google has “implemented” the right intuition of things!

Mike D. says:
May 05, 15h

Amazing to me that we invented sIFR over four years ago as a band-aid and it’s arguably still the best thing out there for custom typography.

Let’s go browser manufacturers! Take Safari’s CSS3 custom font implementation and adopt it already!

May 05, 16h

Dave, to add to your comment about the SEO success of the site’s you’ve built for your clients using image replacement - Apple.com has one of the highest PageRanks on the Web with a score of 9 out of 10 possible. Their navigation uses the Leahy/Langridge Method and they are certainly not being penalized for it.

In order for a site to be blacklisted as the German BMW site was in 2006 (see http://www.news.com/Google-blacklists-BMW.de/2100-1024_3-6035412.html), people on the webspam team at Google review it in person. This means that if you’re using image replacement legitimately (ie. the text in your image matches the text in the element where the switharoo occurs) the webspam team will not mistake your good deed for a black hat trick.

@Mike - agreed. It’s time for the type issue to be resolved.

May 05, 17h

I was under the impression that the potential for penalties from search engines for hiding content with CSS only applied to inline styling and not to anything contained in external stylesheets. Maybe that notion is out of date? As an added security measure, I’ve always disallowed indexing of my CSS directory with robots.txt.

I think another interesting question to ask relating to the use of images for text is whether an image-replaced piece of content has any more SEO weight than the same image in the HTML (not CSS) with the text contained within the alt attribute?

May 05, 17h

This is such good news! And thank you very much for writing it down, now I can reference it in the future.

We had a client last year who used another firm for SEO that made us change our CSS image replacements because they said that’s why they weren’t getting their search results. Justification finally! Hurrah!

May 05, 21h

To me, Google sees image replacement as a sort of reverse alt tag for text. When used properly, it’s just a way of providing a different interpretation of the same content.

7
TyGos2 says:
May 05, 21h

Thanks for the timely post. Image replacement is really at the heart of the whole X in xhtml logic. A stylesheet can make the images fit where they need to go given the media, even mobile design structure from the same xhtml page.

Ole Hook says:
May 06, 02h

I have a question to you experts:

I use an another technique of image-replacement. So i don’t integrate the image as a background-image, but as a normal image in the code and add an invisible span-tag with the real text in it:

Lorem ipsum dolor sit

The class “invisible” looks like this:

.invisible {
position:absolute;
left:-9999px;
}

I need to integrate the headline image into HTML as an image-tag, because it can have 1 or 2 lines and it is generated automatically via PHP.

So what do you think about this? And what thinks GOOGLE about it…?

Ole Hook says:
May 06, 02h

For better understanding here is a code snippet:

<h1><img src=”headline.gif” alt=”Lorem ipsum dolor sit” width=”300” height=”22”><span class=”invisible”>Lorem ipsum dolor sit</span></h1>


Sorry for double post…

May 06, 03h

This information is sort of a relief for all people working on accessible websites. We long have been insecure about Google handling stuff that was hidden via css to serve visitors with assistive technologies.

May 06, 07h

It is good to get this confirmed, great job Aaron! So basically, all ‘regular’ image replacement techniques are safe, because a penalty will occur after a human inspection (as what happened to the German BMW site)?

May 06, 08h

I’m glad someone finally addressed this issue and backed it up with some reputable sources. Thanks for posting this, Dave.

I’ve had the pleasure of meeting up with Aarron several times since SXSW 07. He is an intelligent, creative and resourceful individual who is passionate about all aspects of this industry. Evaluation of markup strategies like image replacement is just one the aspects of findability that he covers in his book:
http://buildingfindablewebsites.com/

Yes, that was a blatant book plug, but since Aarron didn’t do so in his comment, I figured somebody had to mention his book. :)

13
3D says:
May 06, 08h

I think one of the reasons why Image replacement technique would be considered to be bad idea is that both text and image won’t show up, when user turn off their image display option “off”.

But it is very good to know that google okay with it when it comes to SEO.

Thanks for the info!

May 06, 15h

“I think one of the reasons why Image replacement technique would be considered to be bad idea is that both text and image won’t show up, when user turn off their image display option ‘off’.”

Not necessarily; there are techniques like Gilder-Levin where the text is still visible with images turned off.

May 07, 08h

Ole Hook, I don’t see how your version of image replacement would be any different according to Google. But now that you know Google won’t penalize you for using “display:none” on that span tag, it would make your code shorter and would avoid any possibility of someone who has a browser width of 10,000 pixels ever seeing it… which I know doesn’t exist, but you never know if it ever will exist on a really, really big screen someday. Maybe some little guy with a complex will invent that. :-P

16
Daniel says:
May 10, 06h

I had an argument(as in exchange of ideas) with a collegue a month ago. He *discovered* that I used an image replacement tehnique on an h1 tag - despite the fact that I replaced an image contiaing the same text it displayed; I had used your revised image replacement, however his main concern(being somewhat SEO obssesed) was that this will impact it’s page rank, thus the position in the google page search results. So it was never a question if this is enough to get our client’s website banned.


Comment on This Article:

HTML is disabled, but URLs will be auto-linked. Your e–mail address won’t show up on this page. Quality over quantity — comments that don’t add to the discussion in a substantial manner will likely be deleted. (Read about commenter avatars.)