Samstag, 22. März 2014

Authorship markup: how to combine correctly several kinds of it?

Yes, exactly, how to correctly combine them? More: why is it useful and needful to use several authorship markup and whether it produces any SEO-profit?

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.

In general the primary function of using of several kinds of authorship markup at once is to produce as more as possible direct relations between publications, publication sources and author's entities. On this way you gain extremely the chainig ability of all of your web assets and properties.
Hey, is the SEO added value already vivid?

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.

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

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

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.