Do iFrames and Share Bars Help Retain Curation Traffic?

Many content marketers contemplating curation fear that linking to third-party content will drive visitors away from their branded properties to be never seen again.  One tactic employed by some marketers is to use a share bar or iFrame which hovers over the third-party article displaying branding and a link back to the site which curated the content.  

Share bars must be used with caution. While they may help decrease attrition from a curation site, they also can annoy readers, visitors, and even search engines if they are not used with caution.  Let’s review some aspects to consider when deciding to use a share bar from marketing, reader, publisher and search engine optimization perspectives.  

What is it?

Before we go further, let’s clearly define what a share bar is.  You have likely encountered them in the past, but may not know them as a share bar.  Here are a few examples of share bars:

  1. SharedByCo’s Engagement Bar.  Formerly known as Visibli.
  2. HootSuite’s Owly Bar.
  3. The former Digg Bar.

Common Misconceptions about Share Bars & iFrames

Some people who are unfamiliar with iFrames mistake the use of a share bar with the scraping of content.  Here’s an excerpt of a humorous Facebook conversation between some confused marketers who don’t understand what an iFrame is.  There are accusations of being “slimy”, “ripping off” content and “scraping”.

Here’s the truth about common misconceptions about Share Bars and iFrames:

  • They do not scrape content. Wrapping someone else’s content in an iFrame is not scraping.  You are not making a copy of the third party content onto your server. You are simply displaying the third-party article in a smaller portion of the original web browser screen.  
  • They do not taking away traffic from the original content source. Share Bars actually drive additional traffic back to the original content source.  All these page views will also get recorded under the original content source’s analytics despite being wrapped in an iFrame.

Next, let’s take a deep dive into why, where and when you should consider using or not using a Share Bar.

Marketing Considerations

From a marketer’s perspective, using a share bar helps in a few ways:

  • Additional branding exposure. Share bars let you display your logo providing you with an extra branding impression even as people read off-site third party content. Furthermore, when using a share bar, the browser address bar domain can stay as yours instead of displaying the link to the third party site.
  • Increased retention and lower bounce rates. If implemented properly, share bars can help significantly decrease bounce rates, and increase the number of pages per visit.  For example, a share bar can display content recommendations related to the third party content at hand, enticing the reader to continue to reading more content and staying engaged without leaving the site.
  • Capture Social Media Shares. Some share bars also include social sharing buttons, enabling readers to quickly the share content they are consuming to their social media channels.  The links shared from such buttons can be configured to share a link not just to the third party article, but instead can be set to the share bar page, or perhaps a landing page on your site that contains an abstract of the original article.
  • Keep conversation on your site. You can also configure some share bars to allow visitors to comment on third party content.  However, rather than having them comment on the third party article, with a share bar, you can let them comment while viewing the original article, but capture the comment as a comment on your site.

While many of the advantages of using a share bar help marketers, they can inadvertently annoy readers and publishers alike if the are not implemented properly.  In the next few sections, we will talk about some things to consider when implementing a share bar from reader and publisher perspectives.

Reader Considerations

Similar to advertisements and interstitial popups that appear on sites asking you to sign up on site, share bars are a feature that most readers detest, but marketers love.  

Readers may get annoyed with share bars for any of the following reasons:

  • Intrudes on reading experience. A share bar will hover over and cover part of the original article, or reduce the useable reading area, leading to a sub-optimal reading experience.
  • Breaks mobile optimization. If the underlying third party page is a mobile-optimized, share bars can often disrupt the underlying sites ability to render in a mobile format.  As a result, readers are left with reading the original third party article in a desktop rendering solely because of the share bar which requires a lot of pinching and zooming.

At the same time, there is one big reason why readers may appreciate the share bar:

  • Get content recommendations. The only strong reason why readers would appreciate a share bar would be if they are receiving relevant and interesting recommendations to other content they may want to consume.  

Publisher Considerations

Next, we will take a look at what publishers, the third party in third-party content, generally think of share bars.  Basically publishers do not like share bars for almost all the exactly the same reasons that marketers like them.  Here’s why:

  • Take away from branding exposure. If you have had your content wrapped in an iFrame or share-barred, you have probably felt annoyed that another brand has plastered their logo and URL on top of your content. 
  • Steal social media shares and back links. With a share bar, the original article URL is not displayed in a web browser address bar.  As a result, many bloggers who want to cite the original content, may accidentally end up linking to the share bar URL not residing on the original content domain.  This can ultimately reward the curator of the content in search engine rankings rather than the original content source.
  • Loss of metrics referrer. Share bar’s can mask away some HTTP headers such as referrer URLs.  As a result, they may interfere with visitor tracking analytics.  For example, in Google Analytics, content that has been wrapped in a share bar would report traffic coming from the share bar instead of the page that lead people to the share barr’ed content.

Search Engine Optimization (SEO) Considerations

Sajeet Nair of Convonix ran a comprehensive test of how different search engines treat iFramed content.  His conclusions were as follows:

  • Yahoo and Bing do not crawl the iFramed original content source, but Google does.

  • Google fairly attributes the content of iFrame to the publisher and not to the site that iFramed the content.

How to Bust Out

If you find that your content is being wrapped in a share bar or iFrame, and don’t want this, there are two ways to bust out.

The easiest and most practical way is to simply put a small piece of JavaScript code on every page of your site.


if (top != self) { top.location.replace(self.location.href); }


This basically tells the browser that if your page is not in the address bar, then reload the page without any iFrame wrappers.  This should work 99% of the time, but it is possible to circumvent this iFrame buster.

A better fail-safe way is to use a newer HTTP header called X-Frame-Options.  This will require IT help.  Furthermore, X-Frame-Options don’t really bust you out of iFrames, they just instruct the browser not to render your page if it detects it is being iFrame’d.

Best Practices

In summary, as a marketer, here are a few best practices to follow with regards to share bars and iFrames.

As a content publisher:

  • Bust out. It generally never helps you to have your original content to be iFramed by someone else.  Place the one line of JavaScript on every page of your site to bust out.

As a curator, if you decide to use share bars, to make sure you don’t annoy publishers or readers, here are a few things to do:

  • Give an option to close. Provide a button or option to readers to close the iFrame and display the original article if they want.  While there’s no rule that you have to, it’s courteous to both your readers and the third-party publisher.
  • Give option to hide permanently. To go a step further, you should also add an option for readers to hide the share bar permanently and take readers to the original third-party articles always without the share bar.  You can implement this option by cookie-ing each visitor who decides to hide these permanently.
  • Don’t make it too big. Don’t be obnoxious with a share bar.  Keep the size of the bar minimal so it does not overly intrude and obscure the content behind it.

  • Detect mobile. If possible detect when a mobile device is being used.  If you detect a mobile device is being used, redirect to the underlying page behind it so the underlying page can render itself with mobile optimizations.
  • Add value such as recommendations. Share bars should not just be about branding.  They should have add genuine value to your reader’s experience.  For example, you can do so by recommending other relevant articles to the reader.

This may seem overwhelming, and even overly technical.  If you find them daunting, and want to just get up and running with curation, without thinking twice about these best practices and considerations, get a demo of Curata.

  • Oliver Kody

    I have a specific question concerning integrating WIKI content. I would like to incorporate curated content from in a website for a very specific topic which adds value to my audience. To do this I used an with an embeded link to the WIKI page I chose to feature. (again very specific to my audience). I do not try to hide my information source, rather use a tag to indicate the information provided is from wiki.

    Q1: Is this an acceptable curated use of Wiki content?

    Q2: Is there any added benefit (or detraction) from an SEO standpoint in featuring this content. note: Wiki page contains many embedded Wiki links within the top level page. Does this HELP or HURT my web SEO?

    • CurataMarketing

      Hi Oliver,

      Q1: Whether or not it’s an acceptable use of Wiki content is not really a hard yes or no, but if you are prominently attributing and driving traffic back to the original source I think it should probably be acceptable.

      Q2: It shouldn’t really affect the SEO since the links are on a page that is iframed. The text of the iframed page won’t help you though.

      Good luck!