S for Semantic: part 3 of the HASCH the OnPage SEO framework

The third part of my OnPage framework is dedicated to semantic of a webpage. With this article i will give an overview of benefits and usage areas of semantic markup. Use this article like a kind of cheatsheet for OnPage audits of existing website, SEO strategy for website under construction, or website preparation for semantic search before relaunch.

Why semantic?

• Search engines use semantic to improve the search results (semantic search).
• Using semantic OnPage makes texts better machine-readable (exacter understanding and distinguishing).
• All fresh kinds of search results output, like rich snippets, Knowledge Graph, the OneBox are based on and populated with semantically rehashed informations.
• Google accomplished a paradigm transition "from strings to things". The "thing" here is the main object of (web) semantic, an entity. An entity means in our context just a keyword, or keyword phrase, but more or lesser interrelated and explicitly verifiable by other sources,
• It's already proven, that semantic markup is a ranking factor: 0,3% of all sites make use of semantic markup, but 36% of sites at SERP encounter it.

Semantic website revamp is the key to being understood by machines. Quite enough reasons to scrutinize the subject! Lets go:
We will have to do with:

1. semantic markup of the source code and
2. semantic preparation of the content.

Semantic publishing means content publishing using semantic markup. There are 2 areas, where semantic markup can be used: head and body.

Semantic markup in the head

The head is the place for all metadata. What kind of metadata to use for page semantic? Well, i recommend 4 types:

• The general metadata, available by the W3C HTML5 standard,
• Dublin Core,
• Open Graph
• Twitter Cards.

To get more details about using metadata in the head read my previous article.

Semantic markup in the body

Here the things become more interesting. Cause our body-area is THE place, wherefrom search engines take the main informations - the metadata in the head-area are just associating and verifying stuff.

Semantic page architecture

Before we come to the page content, i must make a note about the semantic architecture. The note will be not long, but it has a substantial meaning: HTML5 offers some new tags, which make possible to signal, which part of the page contains what:

• header for logo and slogan,
• nav for navigation elements,
• aside for addendum like links or news teaser,
• footer for contact or copyright informations,
• section and article for the page content.

Making a mental note of "most important comes first" you will be on a right way with semantic page architecture. Get the full page-wide architecture tutorial as a part of an article on the site architecture.

Semantic content

To markup a content on semantic way there are different methods available:

• RDFa
• Microformats
• Microdata (Schema.org)

I strictly prefer and recommend to use Schema.org markup, just cause using of it is recommended by Google, Bing, Yahoo and Yandex. Other methods i mentioned, are understandable, but not visibly / definitely preferred from search engines.

On this place it is useful to remember again, why we want to achieve with semantic markup? We want ensure, that search engines exactly understand some things:

• What is the topic?
• Who is the audience?
• What is the main message / purpose / point?
• What is the intended action, we want our readers force to?
• Who is the author?

After we were clear with our content's objectives, let's look which methods of semantic description are in our disposal.

Schema.org: types and properties

Using of Schema.org 's semantic markup has two goals:

• defining of an article's meaning with methods understandable by search engines.
• making search engines possible to distinguish meanings.

A search engine can't distinguish e.g. what means a "$"-character: a product price in dollars or a variable in a source code listing. That's why using of standardized Schema.org's property priceCurrency (3-letter ISO 4217 format) isn't waste of time, but the only way to tell search engines "this is about a price".

Assumed a website article as the CreativeWork type following properties (at least) are available for passing the article meaning: name, description, headline, alternativeHeadline, author, citation, audience, genre, about, mentions, keyword, text. But things aren't explained enough through only using of Schema.org's markup.

Explain things with inherited types

Some of properties listed above are able to inherit types. I strongly recommend to expand such properties with types: the more accurately defined meanings you pass to search engines, the exacter your content will be understood and ranked.

Explain things using sameAs

You can pass an explanation through using of sameAs-property. To do so you must

• find a description or explanation of the property in any trusted source like Wikipedia, Freebase, DBpedia, linked data vocabulary
• implement (link) it using sameAs-property

In following example are both explanation methods illustrated: look at using of properties mentions and sameAs:

Example 1

<div itemscope itemtype="http://schema.org/CreativeWork">
 <span itemprop="name">Faust</span>
  <link itemprop="sameAs" href="http://en.wikipedia.org/wiki/Goethe%27s_Faust"/> 
 by <span itemprop="author">Johann Wolfgang von Goethe</span>,
  <link itemprop="sameAs" href="http://en.wikipedia.org/wiki/Johann_Wolfgang_von_Goethe"/>
 <span itemprop="mentions" itemscope itemtype="http://schema.org/Person">
  <span itemprop="name">Mephistopheles</span>
  <link itemprop="sameAs" href="http://en.wikipedia.org/wiki/Mephistopheles"/>
 </span> 
</div>

Note 
There are many sources, which could act as sameAs, beside of links they could be different ID-numbers, SKU's, ISBN etc (but in most cases they are links). If you are in situation, where you really want use such proof, but haven't found any, create an entity for your subject at Freebase and use it like sameAs-link.

For description of products, offers and the like you should use other properties, it is possible however to tie two types in one for using properties of both types:

Example 2

<div itemscope="" itemtype="http://schema.org/Product%20http://schema.org/Product">

Note
There are 2 cases, where your semantic markup will not generate visible rich snippets:
a. on using nested types, as in example 1, and
b. on using of multiple types at once, as in example 2. This issue affects ONLY the visibility of rich snippets! Semantic markup at its own is still clearly understood.

Keywords: preparation and markup

Schema.org defines keywords as a plain text property - it isn't able to inherit any type. But it is nevertheless a substantially important task to signal what are article keywords and what they mean. That is why the thoughts about how to proper use semantic markup in an article must arise till early preparation stage, namely while looking for keywords for the article.

To create a semantically correctly arranged article go this way:

• Research your keywords
• Research the keyword environments - search for synonyms and LSI-keywords
• Research URIs (uniform resource identifiers - sameAs links or other unique properties like ISBN) for located keywords
• In case of no such URI (and you desperately want one): create an entity at Freebase or, if you prefer images, create an entity at Wikimedia Commons and use links to these entities as your URIs
• Prove the more the better keywords and their synonyms with sameAs-URIs.
• Use them, even if they aren't URI-prove, but markup them with h1-6, strong or italic,
• Use them as anchors in outgoing links,
• And, of course, don't markup your article's keywords with keywords-property! Use mentions instead, cause it's allowed to extend mentions with any type, but not keywords.

Note
Turning "plain" keywords to entities with methods from above is crucially significant for the topical relevance of your webpage.

Semantic markup to tie them all

To tie a website and its subject, product or service to location and / or author is semantic markup absolutely essential. Using location and authorship data on each page (not only on imprint) is the key to correct relation of website to location and author.

With location data i mean at least state, city and zip-code, with authorship i mean an article's markup as CreativeWork including information about an author like extension of the author-property with Person-type.

Example 3

<div itemscope itemtype="http://schema.org/CreativeWork">
...
 <span itemprop="author" itemscope itemtype="http://schema.org/Person">Evgeniy Orlov
  <link itemprop="sameAs" href="https://google.com/+Evgeniy-Orlov"/>
  <link itemprop="sameAs" href="https://www.linkedin.com/in/evgeniyorlov"/>
 </span>

<span itemprop="publisher" itemscope itemtype="http://schema.org/Organization">Undead SEO
 <span itemprop="location" itemscope itemtype="http://schema.org/PostalAddress">
  <span itemprop="addressCountry">DE</span>
  <span itemprop="addressLocality">Berlin</span>
  <span itemprop="postalCode">10437</span>
  <span itemprop="streetAddress">Lychener Str.</span>
  <span itemprop="url">http://undead-seo.blogspot.com</span>
  <span itemprop="sameAs">URL to your GoogleMyBusiness Account</span>
 </span>
</span>
</div>

The address markup could be not mandatory placed inside of article's markup. But if you want your site will be exactly related to location, i strongly recommend to use address markup on ANY page.

Conclusion / tl;dr

Semantic is the key to being understood by modern search algorithms. The webpage semantic is carried forward by 3 components:

1. Semantic metadata (broad vocabulary to pass machine-readable metadata from even non-textual content types)
2. Semantic content markup (defines machine-readable answers to material questions on content)
3. URI-verifying of articles keywords (makes matching by entity search algorithm possible).

PS: Don't hesitate to look into previous parts of the HASCH, my OnPage SEO framework:

• H for Header
• A for Architecture