Image Alt

The SEO Design Story – Part 2


The SEO Design Story – Part 2

This is the second post in a series of articles which will explore web-design’s influences on SEO (find the first post here – which focused on specific Google ranking algorithm updates)

Through this story we will examine partially design-oriented Google updates which impacted SEO, how SEO-friendly site-builds have shifted, SEO-design best practices and more

First Post Learnings Recap

An excerpt which closed the first post in this series:

From 2009 onwards, Google was on a crusade to unify their ranking algorithm(s) with their vision of great content. Content is more than just text, it’s anything which a web-user can digest online (web-page layouts, images, videos etc). Because ‘winning content’ has design aspects, web-design became intrinsically intertwined with SEO best practices

Further to this, Google’s consumption of data became more complex. Content facets such as schema (and ‘under-the-hood’ structured data, disconnected from traditional Meta data) became more important. The fundamental build of websites which could better satisfy Google, shifted as a paradigm

Next time we’ll explore this in more detail. Which structured data and content facets should a site support in order to stay relevant on Google? Why are open-source CMS platforms like WordPress ahead of the curve for SEO?

Structured Data Review Snippets Example

The changing face of SEO schema implementation, is a story which shows that design factors can and do influence SEO results. Most of us know about schema, an often-hidden subset of data embedded within a web-page (not to be confused with <meta> tag Meta data, which is separate). Web-schema is a collaboration (with community elements) led by, with the aim of creating a unified schema of structured data for the web: is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond” – homepage description

Schema can invisibly provide Google with context for certain pieces of information embedded on (or highly relevant to) a web page. For example, if you’re looking for a drinking fountain for your cat (because he doesn’t like drinking still water):

… you may find this search result listed on Google, which contains an aggregate product star rating. This star rating may impact search rankings, though primarily it serves to make the SERP (Search Engine Ranking Position) more attractive (in the hopes of drawing more clicks)

If you click on this Google ranking result, you will see the embedded star rating on the resulting web page from ALDI:

Using Google’s Structured Data Testing Tool, we can verify that this visible star rating is invisibly marked up with schema, which gives Google the opportunity to apply a star-rating on the actual SERP (though this is just a directive, it doesn’t mean that Google have to apply the star rating if they don’t trust the web-page!)

You can read more about aggregateRating schema here on Not all schema from is adopted by Google, though Google does seem to pick up and document most of it on their own “Search for Developers” URLs:

It should also be noted that sometimes, we see search experiments (run by Google) where Google utilise schema (from despite the fact that Google has not added that schema to their own documentation (so there’s always an argument for SEO experimentation, regardless of Google’s documentation)

You can see how Google is attempting to unify the invisible worlds of data and coding, with the visible world of design. Rendered star-ratings for a product on a site (a design element) are marked up with invisible coding which then alters Google’s search results (if they decide to apply the embedded schema). A great example of design and SEO fusion in action

When Google allowed webmasters to begin marking up pages in this way (which had a good chance of rendering star-ratings on Google’s search results, visible to Google’s users, against listed sites); some webmasters decided to wilfully apply such schema(s) too broadly in order to gain false star ratings, or to gain star ratings on pages which didn’t need them. Whenever Google hands out a code-controlled element, which can influence Google’s SERPs – creative attempts to manipulate such releases are sure to follow

Rich Snippet Spam Penalties

When the snippets of text which Google uses to list a website gain additional features such as a glossy star rating, those snippets become ‘rich snippets’ (rich because they are in some way ‘enriched’ with images or additional information)

As webmasters began to abuse schema to gain more clicks from Google (by making all of their web pages look more attractive in Google’s results, even if they didn’t deserve a great star rating); Google began to clamp down on ‘rich snippet spam’. Discussion about this continues and was relatively prevalent in 2015. As far as I am aware, news that Google were making such penalisations began in 2014

Google’s official guidance can be found here:

So why is this important to the SEO Design Story? Largely this comes down to a tangled web of communications from Google in terms of how to implement schema and structured data

Originally Google pushed the implementation of schema through Microdata, before later shifting to push JSON-LD instead. Some issues were caused during this transition (which in reality, I am pretty sure was an internal conflict between Google’s data and anti-spam teams). Essentially the JSON-LD implementation is technically superior and faster. That being said; the Microdata implementation is less prone to falsification and tampering. With Microdata, it’s harder (not impossible, but harder) to send false schema to Google for elements that fundamentally don’t exist on a web-page

This means that when Google moved away from Microdata (in their documentation and public-facing rhetoric) and towards JSON-LD, they weakened the link between SEO and design. So, what’s the difference -and what impact did it have on the SEO industry?

Structured Data: Microdata vs JSON-LD

This is a typical Microdata implementation for reviewRating:

In a small blue box, you can see the actual book review rating of “5”. This resides within a <span> which exists within the source-code of the web page. The review rating itself (the number “5”) is already built into the ‘brick-and-mortar’ of the web page, the schema is simply wrapped around the rating to give Google some extra context. The visible rating (which already existed) was encased in schema

Obviously, this is less easy to game in terms of rich-snippet spam. The item has to physically exist on the page before the schema can be wrapped around it. I’m not saying this schema deployment is impossible to ‘game’, but it certainly does make developers think twice before they act in terms of deploying schema (this helping to avoid potentially costly rich-snippet spam penalties from Google)

This is a typical JSON-LD implementation:

This data is fired to Google through an entirely separate script. Certainly it gets the information to Google faster and more efficiently, however it’s disconnected from the ‘brick-and-mortar’ coding (HTML) and therefore design of the website. Theoretically you could fire review ratings to Google for non-existent products. If Google weren’t keeping a firm eye on the corresponding on-page content, you might even win some beneficial fake Google star ratings for certain pages on your site

This would however, be black-hat SEO, which would be likely to garner rich-snippet spam penalties from Google. This is why I found it surprising when Google began talking more about JSON-LD and less about Microdata. This is why posts like this one (2019) surprise me. SEO plugin experts like Yoast began pushing JSON-LD back as early as 2016

In 2014 Google began penalising sites for rich-snippet spam, back when most sites were still using the Microdata implementation which is trickier (though not impossible) to ‘game’. Around that time, Google (and other SEO experts) also began pushing a schema delivery method which was easier to mess with (a mistake in my opinion, though it should be noted – I don’t have all of Google’s internal decision-making context)

The Ramifications of the Move from Microdata to JSON-LD

We have evaluated that JSON-LD is easier to set up and more efficient for Google, in terms of Google imbibing schema directives. That being said; JSON-LD separates schema from on-page design aspects more aggressively than Microdata does

Severing the connection between design / on-page elements and the SEO data delivery, may not have been wise. It makes it easier for web developers to make mistakes, as there’s no ‘rope’ to pull them back to this question – “fundamentally what is ‘on’ each web page? That is all I should be marking up with schema

Are users still experiencing rich-snippet related ranking drops across 2019 / 2020? (2019)

Markup on some pages on this site appears to use techniques such as marketing up content that is invisible to users” – a clear comment from Google referencing a concern which I have, regarding the shift from Microdata to JSON-LD implementation. Without looking into this guy’s site in too much detail… it’s possible that he made an honest mistake with JSON-LD and was penalised for it

If you want to browse more examples of users having similar issues, check out this Google search which I created:

Most of these posts were created in Google’s help forum(s) as recently as 2019. Clearly the web has seen issues as Google moved us away from Microdata and suggested that JSON-LD was superior. Superior for data transfer, maybe. But superior in terms of, getting Google’s schema guidance correct? Absolutely not

What this Schema Story Tells Us About the SEO Design Story

In many instances, Google has been seeking to unify their view of well-designed content with their ranking algorithm(s). Better content should rank better on Google and design features are an aspect of content (in this context, web pages)

In this instance though, Google moved away from this general trend. Google did something which divided SEO and Web Design, which separated them more

For some, the results of this were nothing short of disastrous. Design and SEO go hand in hand. When they are brought closer together, the whole web benefits. When missteps are taken which separate design and SEO, often problems arise

Written by

SEO & digital marketing specialist of nearly 10 years. A master of Google Data Studio, XPath and more. Applied data-driven analysis, to increase revenue and on-site conversions. Architecting information, to bring you closer to your online audience!

Post a Comment