Some SEOs dispute about differences of using author and publisher properties, another SEOs advice to use only rel="author"... I say: use all you might use simultaneously! (it's needless to say, don't use something, what doesn't fit your context and could be ranked as e.g. rich snippets spam etc ).
Using several kinds of authorship markup
- helps Google to make correct and profitting meaning about the author
- lets Google establish correct relation between the author person, his several publishing sources, the current and preceeded topics and
- prepares current topic to build a advantageous interrelationship of preceeded and following publications and to increase authors authority.
Hey, is the SEO added value already vivid?
Succeeding in better entities chaining makes our content more relevant to our keywords, enhances our trustrank and author's authority.
Persuaded? Then let's talk about the "how".Objective setting
Suppose, we want markup a blog article in the firm blog, where we are working. We want to achieve, that all given entities will stay in relation one to each other:- our firm,
- our firm blog,
- our firm as the blog owner,
- we as a person,
- we as a firm employee,
- we as the blog- and article author.
All of this goals are accomplishable, with the markup of a single article (assumed that all of our articles are exactly so or similar marked up;).
Selecting classes and properties
There are actually not very much kinds of how to tell machine-readable and verifiable about own authorship. The best practice is to use HTML5 and Schema.org's microdata. Then let's select classes and properties we use. Classes are: Person, Organization, BlogPosting. Properties could be author, publisher, copyrightHolder, worksFor, sameAs, url.Building a markup structure
After we reached an amicable settlement about used classes and properties and could begin to code, there remains just one thing to clarify: structure, markup structure of our web document. The markup structure has however a stringent condition: Google doesn't show rich snippets for nested classes, which are nested deeper as the upper (first) level. Rich snippets not showing tells you more details about this issue.Our bearing entity is BlogArticle and we don't want to miss such visibility and CTR pusher like rich snippets are. What we do is to make the whole markup structure so that BlogArticle and the most rich-snippets building classes and properties go to the upper level.
Look at the following code: what we've done with it? We got several kinds of Authorship markup tied to the main author entity. Beside of this we establish semantic relations between the firm, the blog and the author.
<div itemscope itemtype="http://schema.org/BlogPosting"> <div itemprop="author copyrightHolder" itemscope itemtype="http://schema.org/Person"> <a itemprop="url" href="https://www.google.com/+Evgeniy-Orlov?rel=author"> <span itemprop="name">It's me again</span> </a> <link itemprop="sameAs" href="https://www.freebase.com/m/0_xkbvr"> <link itemprop="sameAs" href="http://orcid.org/0000-0003-2218-0324"> <meta itemprop="worksFor" itemref="org-url org-google-places org-same-as" itemscope itemtype="http://schema.org/Organization" content> </div> <div itemprop="provider publisher" itemscope itemtype="http://schema.org/Organization"> <link id="org-url" itemprop="url" href="http://undead-seo.blogspot.de"> <link id="org-google-places" itemprop="sameAs" href="http://url-to-google-places-account"> <link id="org-same-as" itemprop="sameAs" href="https://www.freebase.com/m/0_y3lcl"> </div> </div>
and look at the interpreted code and it's validation through Google's structured data testing tool. Fit this markup to your needs, it is a basis for your correct using of several authorship properties at the same time and for the same content. But make carefully use of it and bring Okham's razor into action! Cause duplicate markup could be (mis)ranked as duplicate content, said Barbara Starr.
There are some details yet, which must be mentioned in this context:
rel="author" vs. ?rel=author
If you are attentive enough, you surely realized the kind of authoring link, which i used for linking to Google+ account, namely not as earlier<a href="https://www.google.com/+Evgeniy-Orlov" rel="author">previous linking art to my G+ account</a>but
<a href="https://www.google.com/+Evgeniy-Orlov?rel=author"> new linking art to G+ account</a>Google pushes this linking syntax, but i think, that such syntax is usable better only for linking to G+. Other addresses link better on previous way, with rel="author" as link parameter.
"Two types approach" or "Multiple Type Entity": chaining of classes and properties - pro & contra
Another thing to mention is so called "two types approach" on using of microdata. This is the way to shorten microdata markup as follow:instead of
<div itemprop="author" itemscope="" itemtype="http://schema.org/Person"> <span itemprop="name">It's me again</span> </div> <div itemprop="copyrightHolder" itemscope="" itemtype="http://schema.org/Person"> <link href="https://www.google.com/+Evgeniy-Orlov" itemprop="sameAs"> </div>use
<div itemprop="author copyrightHolder" itemscope="" itemtype="http://schema.org/Person"> <span itemprop="name">It's me again</span> <link href="https://www.google.com/+Evgeniy-Orlov" itemprop="sameAs"> </div>
What is possible with properties, is possible with classes too, but with some restrictions. The working "two types approached" code applied to classes looks like this (validation here)
<!-- "Two types approached" code --> <div itemscope itemtype="http://schema.org/BlogPosting%20http://schema.org/AggregateRating"> <div itemprop="aggregateRating"> <meta itemprop="ratingValue" content="90%"> <div itemprop="ratingCount">20</div> </div> <div itemprop="author" itemscope itemtype="http://schema.org/Person"> <span itemprop="name">It's me again</span> </div> </div>On using of multiple types entity you can divide types with a normal space or with %20. Deviding with normal space will cause GSDT validation alerts, but the whole code is fully working not dependently of how you devide.
Some validators are not up to date with current stand of vocabulary and syntax development - this is the main cause of sometimes annoying validator's behaviour.
The important argument pro applying of "two types approach" to classes and most profit of using it is the possibility to accomplish some markup variants, which are on the first look not possible. E.g. the architecture of Schema.org doesn't imply any "transition" from CreativeWork to Product through any CreativeWork property. But using of "two types approach" makes possible to markup any CreativeWork with Product's properties. In general "two types approach" is a way to describe an entity with combination of properties belonged to any classes without any dependency.
The most serious restriction is: if using "two types approached" code applied to classes, you loose the visibility of your rich snippets! Compare the "two types approached" and nested code from above and below
<!-- Nested code --> <div itemscope itemtype="http://schema.org/BlogPosting"> <div itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating"> <meta itemprop="ratingValue" content="90%"> <div itemprop="ratingCount">20</div> </div> <div itemprop="author" itemscope itemtype="http://schema.org/Person"> <span itemprop="name">It's me again</span> </div> </div>And then look on the validation of both codes: "two types approached" code from above vs. code from below, You surely become aware of not visible rating rich snippet at "two types approached" code, but the nested code makes rating rich snippet visible.
Credits: many thanks for substantial correction, code editing and advices to Jarno van Driel. Without his knowledge this article would contain some inaccuracy and the code provided by Jarno is much more effective and syntactic correct, then i've done previously.