Image Replacement + Google
May 05, 2008At 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.
(This article has also been translated into Russian.)
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!
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!
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.
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?
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!
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.
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.
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…?
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…
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.
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)?
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. :)
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!
“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.
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
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.
I’m working widht for instance: text-indent: -9000px;
… and it works with Google.
I think Image Replacement for Headlines is okay, because nobody will be able to give a headline a completly diffrent meaning.
uhmm, maybe it’s a n00b question, but why everyone assumes that googlebot is aware that some text is being image-replaced via css?
I mean, that would imply the bot has to parse tons of html and external css files, request image files ecc… and in the end figure out if major browsers could render the page so that some images obscure some other text.
I think it’s feasible but it would be a hell of a overhead.
Abu, Google already does a lot of work parsing massive amounts of HTML, not to mention the work done with that parsed HTML to rank pages effectively according to relevancy. Checking the CSS for common methods that hide content is really not that difficult in comparison to what they’re already doing with the content they’re indexing.
Google can’t really penalise anything based on its analysis of your CSS because it can change after the page loads. For example, you might hide a div with display:none until the user mouses over a particular area of the page.
Thus, Google has to resort to language analysis to detect keyword stuffing, and links to determine a level of trust in the page.
@ Dave:
“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.”
You’re right there. For anyone who needs convincing on Google’s intelligence, take a look at the two articles written by Sergey Brin that I’ve linked to below – they provide an insight into the sheer thought that has gone into Google, as well as how it works “under the hood”.
A quick glimpse at these should convince you not to worry about things like image replacement, the ‘off-left’ technique, or using the odd ‘display: none’ rule to hide a skip link etc.
The Anatomy of a Search Engine
http://tinyurl.com/6zxo7h
What can you do with a Web in your Pocket?
http://tinyurl.com/6dblxl
PS: I’ve converted these rather ugly, long-winded links into “tiny URLs” because I don’t want to be responsible for breaking your layout (I’m good like that!). Also, the documents are only available in Postscript and PDF respectively, so I’ve linked to the HTML versions generated by Google.
I spoke with Google about this about a year ago and it was put to me quite matter-of-factly: They don’t care about legitimate uses of hiding text for design and accessibility, that they check before pulling the plug, and that logic and common-sense is applied.
I was relieved to hear it.
Hey,
google uses image replacement techniques like Ole mentioned above: Have a closer look at Google Reader - the logo is replaced via css. Actually, it’s a h1 which inner text is hidden and replaced by an image.
I think Google does not flag a site for using these techniques without manual review. I use as much text replacement images as it makes sense…
That’s why I hate that ‘innocent’ attitude from Google.
What if then Google comes and says: “Using images to replace text is not a proper technique, is not search engine/bot friendly.”
Then we all have to bow down and obey. BS.
It’s like if Google ‘owns’ the truth now, a truth that we all already know exists WAY before Google existed.
It’s OBVIOUS this technique es proper, it respects human users and search bots/spiders in every sense, and this happens even without Google having to state it in their Webmaster Help Center.
We were lucky, VERY lucky, that Google considered that rule as ‘valid’, otherwise, web designers/SEO consultants would’ve had to kneel and bow.
Google sucks big time, it’s either what they WANT or what they WANT.
Sad reality mates.
@Anson:
“Checking the CSS for common methods that hide content is really not that difficult in comparison to what they’re already doing with the content they’re indexing.”
I’m sure your analysis of the relative complexities is correct. But I routinely list my external CSS files as off-limits to robots via my robots.txt file. (After all, I do want the content of my pages indexed, but why would I want my styling code indexed?)
Which raises the questions that I’ve asked in several SEO forums over time (but never got a conclusive response to): if Google has been told to ignore your CSS files, and assuming that it honours that instruction, how then can it determine when CSS has been used to hide text in the markup? External CSS must, by now, be more prevalent than styles placed in the head of the page after all. Does it simply look for markup that has been known to be used for image replacement? That would be quite a big assumption to make – I’m sure that image replacement is not the only use for an empty span.
Can Google really get past a disallowed external CSS file?
We’ve just begun to use CSS sprites with one client - and I never thought about this particular approach to introducing descriptive text.
Sprites are not very mainstream yet, but they certainly can help download speed by reducing the number of http connections. With google putting more and more emphasis on the end user experience when they click on google search results, all those factors that improve page speed seem to be potentially helpful in ranking.
I use already some image replacement technics and is nice to see that is still evolving. Thanks for the usefull info and the tips.
@Rick
“Can Google really get past a disallowed external CSS file?”
I’m I’m correct, a “no follow” will prevent an engine from indexing a page but they will still read it, nonetheless. They will still see your styles which is how they know if you are using black hat techniques.
An engine will read all code that a browser would load.
There’s a thread on Webmaster Google Groups (http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/928aa76a1226cf89/32b089e3248cef78) about this from last June, where one of the Googlers went and checked with Matt Cutts (head of Google spam) and quotes him.
The basic answer is like you’ve mentioned, it shouldn’t be a problem. However his answer also makes it clear it puts you one step closer to ‘the grey area’. All things considered, if this is the extent of what you’re worried about with regards to Google mis-interpreting, I think you’re very much on the safe side of things :)
ps. is it just me or does the checkbox for Remember me stretch about the same width as these other input fields? Intentional?
Comment on This Article:
HTML is disabled, but URLs will be auto-linked. Your e–mail address won’t be published. Comments will be deleted if commenters leave a keyword instead of a name in the name field, if sites linked in the URL field are commercial in nature and not related to the design/tech industries, or if the comment simply doesn’t add substance to the discussion. No free ride on the PageRank train. (Read about commenter avatars.)