I’ve talked before about how much we’ve enjoyed working with Reevoo over the months. It’s great working with an agile and motivated development team who can get things done.
Along the way, we have worked on quite a wide range of challenges - many of them focussed on the public website at reevoo.com. Recently, we have taken on a new challenge - to help them add as much SEO benefit as possible to their B2B offering. The B2B offering underpins the whole Reevoo service - it’s the source of their reviews and ratings and brings them their relationships with retailers, manufacturers and publishers.
We’ve faced some of the harder technical challenges we’ve faced on any recent project and learnt a lot - which is why we wanted to share it here. We’ve written up some of the high level output into a whitepaper we have published together with Reevoo. For this forum, I wanted to delve a bit further into some of the details.
When focussing on reviews to appear on partner sites, I doubt it will be a surprise to many of our readers that a whole heap of SEO requirements quickly reduced to two simple ones:
- indexability - uniqueness
Essentially, we want each review to appear in only one place in a form that the search engines can crawl and index.
This is complicated by some features of the platform - particularly:
The underlying philosophy (in which luckily Reevoo and Distilled found ourselves in total agreement) included:
- Transparency for the consumer - there should be no obfuscation of scores or reviews nor selection of reviews based on criteria that introduce systematic bias - Simplicity for Google - while we probably could define a system where reviews were crawlable in one place one week and another later and maintain “temporal” uniqueness (i.e. only appearing in one place at once). We felt that any possible flexibility upsides were outweighed by the confusion that could arise for Google in seeing content move around the place and the embargo we’d have to place in between moves to prevent indexing overlaps
So. A simple system. One review, one page. That sounds simple, right? Wrong.
Remember the transparency point? How can we display “all reviews” to users while only allowing a subset to be indexed on the page without obfuscating the output or confusing Google? We thought about displaying some in iframes or with ajax, but without a weird sort order, they’d have to be mixed in with the indexable reviews and they’d all load at different rates, display strangely and create cumbersome client code.
The solution we have settled on displays a “sample” of reviews inline and indexable on a given page. The sample depends on an allocation algorithm that ensures retailers, who provide the bulk of the reviews, get rewarded with the broadest allocation of reviews across all products. The link to “all reviews” can then either bring up a lightbox / iframe or pull more in via ajax in a non-spiderable way to ensure the uniqueness across the network.
After having thought about this so long and hard, the most general lessons are based on ideas we discounted - for one reason or another, we decided against:
- Any kind of mix of indexable and non-indexable content in the page - iFrames mixed in with on-page content would be hard to lay out with varying length reviews and would load at different speeds, ajax content would either delay the page load or load at different speeds - Moving content around - this could create problems even if at any snapshot moment in time it only appeared in one place. Pages being crawled and indexed at different times could easily lead to a similar problem experienced by paginated sites whereby Google sees the content in multiple places simultaneously - Moving content with an embargo in between - this could work in some situations (e.g. publishing in one place, removing for 30 days before it appears elsewhere) but is hard to explain to users and misses the transparency goals we were working so hard to achieve.
It’s ironic that it takes so much thinking to create a system whose main goal is actually transparency and external simplicity. If you’d like to read more about the benefits of the system we’ve been working on together, I’d encourage you to have a read of the whitepaper or read what others have to say.