Skip to Main Content (press enter)



We are finding an increase in the use of font replacement techniques, such as sIFR (scalable Inman Flash Replacement), being implemented by our clients’ web agencies and internal developers. sIFR is implemented as a behaviour layer (i.e. laid over normal mark-up and styling), and allows a website to display fonts – via cleverly-sized Flash movies – that it could not normally use.

sIFR has been created with accessibility (and therefore search-engine friendliness) in mind. sIFR is designed so that if either Javascript or Flash are not present, it simply doesn’t present the Flash content. This is intended to ensure that search engines, and assistive technologies such as screen readers (used by vision-impaired users to read web pages out loud), are only provided with plain HTML content. Google certainly processes Flash, much as it processes PDFs, by examining the files and drawing out the text content. It does not rate such text as highly as it rates plain HTML, as there is little semantic information contained within such files at present, certainly far less than is provided by HTML text.

(Note there appear to be security issues with sIFR2 and 3)

There are several key questions:

  1. Does use of sIFR prevent Google from indexing the replaced content?
    No. This has been confirmed by Google engineers.
  2. Does use of sIFR trigger a negative signal to Google’s cloaking detection algorithm?
    Yes, we believe so, albeit not one large enough to cause big problems on its own.

    Google engineer Mark Berghausen comments: “If you do have a reason to believe that your rankings in Google Search are being lowered because of your use of sIFR, I’d definitely encourage you to file a Reconsideration Request at Google Webmaster Central…”.

    Mark’s comment implies that although sIFR will not prevent the replaced content from being indexed, there is a risk there.

  3. Does use of sIFR to replace a heading decrease the value Google gives that heading?
    Unclear. The risk is, we believe, low. The hazard, however, is great. Headings are extremely important content on any page and their devaluation through use of flash replacement techniques would be problematic, to say the least. Google could reasonably devalue any content referenced in a script for replacement until it’s sure of what it is… maybe Google will make this assessment, but the only sure result will be a big flag for hidden content. Such content runs the risk of simply being ignored. Google refers, in the Webmaster Blog link post in point 1., to their hard and fast rule that the content in the HTML and the replacement must be identical; to check this algorithmically is challenging so they are likely to err against the hidden content until it is confirmed.

In the end, it is a question of a balancing the aesthetic benefit versus the risk of a depressed ranking. If you decide to take the risk, you may wish to consider launching your content with the replacement in place, and allow Google performance to stabilise. Then remove it, and see if Google performance improves.

As a final note, because of the potential use of such object-replacement techniques for spamming, it is something that will always need to be monitored. Should Google performance deteriorate, sIFR, and any other replacement techniques, would always be candidates for the investigation. We won’t be using any such techniques on our sites, nor will we encourage our clients to do so.

Update July 2009 – Including CSS3 @font-face method

We recognise that our recommendations regarding sIFR probably result in arguments with your web designer, in the end, however, you must balance the undoubted aesthetic value with the effect that the aesthetic will have on sales, and the low risk of reduced relevancy value of those headings affected.
Your designer may wish to consider instead using the entirely google-friendly CSS3 @font-face method to embed the font for newer browsers, such as Safari and Firefox; no IE support yet.

Subjects: , , , , , , , , , , , , ,
Filed in Blog, August 10th, 2007. Leave a comment, or trackback from your own site. Follow comments via RSS

Leave a comment