How to use schema.org V2.0’s mainEntityOfPage property

by Jarno van Driel on May 15, 2015

in Search Engines, Semantic Web

How to use schema.org V2.0’s mainEntityOfPage property

With the release of schema.org v2.0 (the too large to fully describe in a single post edition) came a new property I think deserves to be in the spotlight as it resolves some long outstanding issues.

mainEntityOfPage

Indicates a page (or other CreativeWork) for which this thing is the main entity being described.

Now I recommend you read the property’s full description on http://schema.org/mainEntityOfPage as it goes on to describe its intended use and where it stands in relation to properties like http://schema.org/about, http://schema/org/sameAs and http://schema.org/url. Properties to which mainEntityOfPage is very closely related and which are part of schema.org’s fundamental building blocks.

Unfortunately though the reason why one should use this property is only is described by:

“Many (but not all) pages have a fairly clear primary topic, some entity or thing that the page describes. For example a restaurant's home page might be primarily about that Restaurant, or an event listing page might represent a single event. The mainEntity and mainEntityOfPage properties allow you to explicitly express the relationship between the page and the primary entity.”

Which is illustrated via the following markup example further down the page (also available in RDFa and JSON-LD):

<div itemscope itemtype="http://schema.org/Restaurant" itemid="#thecafe">
    <a itemprop="mainEntityOfPage" href="http://cathscafe.example.com/"><h1 itemprop="name">Cath's Cafe</h1></a>
    <p>
        Open: <time itemprop="openingHours" datetime="Mo,Tu,We,Th,Fr,Sa,Su 11:00-20:00">Daily from 11:00am till 8pm</time>
    </p>
    <p>
        Phone: <span itemprop="telephone" content="+155501003344">555-0100-3344</span>
    </p>
    <p>
        View <a itemprop="menu" href="/menu">our menu</a>.
    </p>
</div>

But which I think is an odd example as it doesn’t illustrate the property’s true value by mentioning how it can help webmasters deal with some very nasty and hard to resolve situations.

Before going ahead and explaining this to you though, let me point out some schema.org basics first.

Schema.org 101

Let’s say you’re a producer of goods (ACME Corporation) and you’re selling your products on your website. One day you decided to lay down some http://schema.org/Product markup on your product listing pages, and because of this each of the products listed on those pages probably contains some markup along these lines:

<li itemscope itemtype="http://schema.org/Product">
    <a itemprop="url" href="http://example.com/explosive-tennis-balls/">
        <span itemprop="name">Explosive tennis balls</span>
    </a>
    ...
</li>

But were you aware that by specifying the Product urls you were not only telling the search engines where the products can be found but that you also told them they can be found on a http://schema.org/WebPage?

If you visit http://schema.org/WebPage you can read a description that says (emphasis mine):

Every web page is implicitly assumed to be declared to be of type WebPage, so the various properties about that webpage, such as breadcrumb may be used. We recommend explicit declaration if these properties are specified, but if they are found outside of an itemscope, they will be assumed to be about the page.”

Meaning that even if you, for example, didn’t specify an individual product page is of the type http://schema.org/WebPage (or any of its sub types like for example ItemPage) than the search engines will assume you did so for you by treating markup like:

<body>
    <main>
        <article itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Explosive tennis balls</h1>
            ...
        </article>
    </main>
</body>

as if you had specified:

<body itemscope itemtype="http://schema.org/WebPage">
    <main>
        <article itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Explosive tennis balls</h1>
            ...
        </article>
    </main>
</body>

and you should know you can be even more specific by informing the search engines about the type of page they’re dealing with:

<body itemscope itemtype="http://schema.org/ItemPage">
    <main>
        <article itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Explosive tennis balls</h1>
            ...
        </article>
    </main>
</body>

Now you might think “What’s so special about that?” but are you than also aware the rules for HTML don’t apply to structured data and that parsers threat them both very differently?

An important difference between HTML and structured data

In HTML an < article > nested within the < main > nested within the < body > form hierarchical statements. Yet from a structured data point of view no statement about the relation between the specified entities has been made. Meaning what you’ve accomplished, from a graph point of view, is creating 2 top level entities that have no relation to each other, namely a WebPage and a Product.

schema.org/WebPage and schema.org/Product - Two unrelated entities

Now search engines deal with this by treating the Product as if it’s the main entity of the page by default, and only in those cases where no second top level entity has been specified will they treat the http://schema.org/WebPage itself as the actual subject.

A method that works flawlessly and which doesn’t seem to justify the act of adding a new property like mainEntityOfPage – And so the question is, why did they come up with this new property?

Having multiple top level entities can cause trouble

Throughout the years I've encountered plenty of situations where having multiple top level entities was causing some serious headaches as they [a] resulted in the wrong type of rich snippet being shown in Google’s search results and/or [b] were causing pages to rank for the wrong types of search queries – a situation that can lead to a negative impact on, for example, an ecommerce site’s CTR in search results (and thus the income such a site generates).

An example of a real-life problem

Imagine all individual product pages on ACME Corporation’s site have a sidebar that, amongst others, contains an event widget, and that the event contained within that widget has some http://schema.org/Event markup:

<body itemscope itemtype="http://schema.org/WebPage">
    <aside>
        <section itemscope itemtype="http://schema.org/Event">
            <h2 itemprop="name">Acme Product Launch</h2>
            ...
        </section>
    </aside>
    <main>
        <article itemscope itemtype="http://schema.org/Product">
            <h1 itemprop="name">Explosive tennis balls</h1>
            ...
        </article>
    </main>
</body>

Now since it isn't common knowledge that the types of HTML elements used, the order they are in and the way they are nested doesn’t necesarily matter for structured data, folks make the understandable mistake of assuming that because the http://schema.org/Event is nested within an < aside > search engines will understand this markup should be considered secondary content and that the http://schema.org/Product should be considered the page's main content because it’s nested within the < main > element.

However, what actually got created, from a graph point of view, were 3 top level entities which have no relation to each other. The only thing they have in common is the fact they all can be found at the same url:

schema.org/WebPage, schema.org/Event and schema.org/Product - Three unrelated entities

And it’s exactly this type of situation that can lead to the opposite result of what you probably set out to accomplish – marking up additional information so the search engines have a better understanding of what the content on your page is about. Yet for which the ‘reward’ turned out to be that search engines now show a http://schema.org/Event rich snippet where you were hoping for a http://schema.org/Product rich snippet.

And if you’re really out of luck than you’ll also discover your Product pages all of a sudden only rank for event related queries.

Oh, and than there’s also the case where destiny really tries to have some fun at your expense if it turns out this behavior is different (and inconsistent) for different search engines.

#@!&***%_! What happened?

Well at least this part is easy enough to explain – each individual search engine simply has its own rules (heuristics) for dealing with multiple top level entities (or any other form of structured data for that matter) and they’ll be damned before they'll decide to conform their methods for treating structured data as that’s how they can differentiate themselves and is part of how they compete for market share.

Although if you’re the victim of such a situation you might be inclined to be less understanding – I know I wasn’t that understanding the first couple of times I ran into this and it took me like what seems forever to figure out what was happening.

And so I decided to take some of my issues over to the schema.org mailing list, where, over a period of 1.5 – 2 years, during several discussions it not only became clear that individual search engine heuristics were causing these issues but that this was an unwanted sitation that should be resolved.

mainEntityOfPage – a solution for a real life problem

A solution was found by introducing the mainEntityOfPage property – which works because “every web page is implicitly assumed to be declared to be of type WebPage”.

And thus by simply adding a < link > element within the element you want to specify as being the main entity of the page, and having it’s @href value be the page’s url, you now can tell the search engines which entity they should consider to be the primary topic of the page:

<html>
    <head>
        <link rel="canonical" href="http://example.com/explosive-tennis-balls/">
    </head>
    <body itemscope itemtype="http://schema.org/WebPage">
        <aside>
            <section itemscope itemtype="http://schema.org/Event">
                <h2 itemprop="name">Acme Product Launch</h2>
                ...
            </section>
        </aside>
        <main>
            <article itemscope itemtype="http://schema.org/Product">
                <h1 itemprop="name">Explosive tennis balls</h1>
                <link itemprop="mainEntityOfPage" href="http://example.com/explosive-tennis-balls/">
                ...
            </article>
        </main>
    </body>
</html>

Which from a graph point of view looks like this:

a schema.org/Product that's the mainEntityOfPage of a schema.org/WebPage, which also contains a top level schema.org/Event

Being able to specify the relation in both directions

In the original discussions about this topic the first property to get proposed actually was the opposite of what I’ve mentioned so far, namely mainEntity. And only late January this year did schema.org's Dan Brickley suggest it might be a good idea to add a property in the opposite direction as well, which lead to the addition of mainEntityOfPage.

Which means there’s another property I haven’t highlighted yet, because so far I’ve only illustrated what can happen if a secondary entity (Event in this case) has been specified before the primary entity (Product).

Now before I continue, be aware that the same issues I mentioned earlier also can occur when the main entity has been specified first (eg, because the HTML was written in a different order). Which, again, is due to the heuristics of each individual search engine and has little to do with the order of the DOM.

The reason for being able to specify this relation in both directions is to prevent that it can't be specified because the order of the HTML or programmatic issues prohibit a one direction relation being made. And therefore one also has the possibillity to specify the relation in the opposite direction by using mainEntityOfPage's inverse: http://schema.org/mainEntity">

<html>
    <head>
        <link rel="canonical" href="http://example.com/explosive-tennis-balls/">
    </head>
    <body itemscope itemtype="http://schema.org/WebPage">
        <main>
            <article itemprop="mainEntity" itemscope itemtype="http://schema.org/Product">
                <h1 itemprop="name">Explosive tennis balls</h1>
                ...
            </article>
        </main>
        <aside>
            <section itemscope itemtype="http://schema.org/Event">
                <h2 itemprop="name">Acme Product Launch</h2>
                ...
            </section>
        </aside>
    </body>
</html>

Which looks like this in a graph:

a schema.org/WebPage which's mainEntity is a schema.org/Product but which also contains a top level schema.org/Event

Let me finish by saying that everything I just demonstrated also can be achieved by using RDFa or JSON-LD, and that the reason why I chose to use microdata is because it’s still the most commonly used syntax out there right now.

I hope you enjoyed the read and that you'll start using the mainEntityOfPage and mainEntity properties for resolving any multiple top level entities disambiguity out there. And if you're interested in knowing more about what schema.org v2.0 incompasses than make sure to read the article my partner in semantic crime Aaron Bradley wrote.


{ 28 comments… read them below or add one }

1 David Deering May 15, 2015 at 8:04 am

Nice article, Jarno. Thanks for explaining that. And it’s nice to finally see you put your structured data knowledge on Internet paper. 🙂

Reply

2 Aaron Bradley May 15, 2015 at 9:39 am

I second that sentiment David. 🙂

Reply

3 Nico May 18, 2015 at 1:49 am

Hi Jarno,
thanks for the good explanations on this new property. Though I still don’t understand the difference of mainEntity and mainEntityOfPage…Why having both? What difference does the direction make? Maybe a real world comparison would help me better understand the usage.

Can’t you just attach the mainEntity to my main topic element, regardless if it is listed first or second in the source code?

Thanks in advance
Nico

Reply

4 Jarno van Driel June 24, 2015 at 3:11 pm

First off, sorry for responding so late. You caught me being a publishing noob (note to self: When you publish an article regularly check the comments)

As for a real life problem – Let me try.

To be able to make a ‘mainEntity’ relation a schema.org/Thing (S) – Let’s say a schema.org/Article – has to be a direct child of the schema.org/WebPage (O) to be able to express:

(O) WebPage > (p) mainEntity > (S) Article

But in real life it often happens that (S) is nested within another thing (O), let’s say a schema.org/LocalBusiness, due to the order of the HTML. In this situation:

Without the ‘mainEntity’ specified this would result in 3 top level entities:
(O) WebPage
(O) LocalBusiness
(O) Article

Yet with ‘mainEntity’, due to the Article being nested in the LocalBusiness, you would get:
(O) WebPage
(O) LocalBusiness > (p) mainEntity > (S) Article

And it’s for, amongst other, these types of situations we also have ‘mainEntityOfPage’ so we can express:
(O) LocalBusiness
(O) Article > (p) mainEntityOfPage > (S) WebPage

Without having to have to fall back on more advanced methods by having to introduce additional elements and @itemid (microdata) or @resource (RDFa) attributes.

The 2-direction method lowers the adoption threshold so that folks that don’t have a deeper understanding of the syntax still can specify these relations.

Reply

5 Emeka Okoye May 21, 2015 at 6:52 am

Excellent post. In summary, mainEntityOfPage sameAs primaryTopic. Also I learnt how serious problems HTML5 tags could pose to structuring data and its resolutions. Nice one. Bookmarked!

Reply

6 Tim Bradley May 25, 2015 at 12:29 pm

A good read and funny. Thank you, Jarno.

I am a code-newbie trying to build my first site for my business, and these properties were really doing my head in. They seem/feel … illogical?

From your explanation, however, it would not surprise me at all if the properties were actually a “bandaid” attempt to make up for the flawed heuristics of one of the Big 3 in the Search-Engine-Cirlce.

In fact, that explanation kind of makes more sense when you consider that Google’s structured data testing tool didn’t recognise either mainEntity or mainEntityOf Page for WebPage: “The property mainEntity is not recognised by Google for an object of type WebPage”.

Perhaps this is because they are new properties and the tool hasn’t been updated, but I am kind of hoping it is because the king has his heuristics in order and these properties are just learning aids for his special friend.

Can you shed any light on why the tool doesn’t recognise them? Or is that another mystery for the great unknown? Or was I just doing something dumb … again.

Anyway, I am going to avoid them for now. There seems plenty of other (more simple and logical) ways to form connections between items.

But it was a great article – good informative content and humourous. I will keep an eye out for more posts from you.

Reply

7 Jarno van Driel June 24, 2015 at 3:51 pm

It’s not so much an issue of “flawed heuristics” but more the case of a missing piece in the schema.org puzzle.

Schema.org is a ‘living’ vocabulary in a sense that it constantly evolves as the need arrises. Which is quite unlike how many vocabularies/schemas/ontologies are created (which can take a decade due to trying to come up all with all variables before launching it).

And in this particular case ‘mainEntity’ and ‘mainEntityOfPage’ aren’t even unique for schema.org; foaf had its equivalents long before schema.org did:
http://www.eclipse.org/higgins/ontologies/2008/6/higgins-doc/foaf_primaryTopic.html
http://www.eclipse.org/higgins/ontologies/2008/6/higgins-doc/foaf_isPrimaryTopicOf.html

Schema.org just waited to add them until the need arose. Which took some years as for the first years of its existence its sponsors were trying to keep structured data simple by trying to convince the world to mark up 1 entity on a page = low effort = bigger chance on higher adoption rate.

4 years later, with adoption rate in the bag, the need arose to be able to handle more extensive markup and prevent problems, like I layed out in my article, and comment higher up on the page. ‘The world’ is publishing more and more extensive markup now that folks are starting to get experienced with it – and thus it was time to add this missing piece.

“Perhaps this is because they are new properties and the tool hasn’t been updated”

You’re right on the money with this remark. There’s always a delay between when schema.org updates and when any of the sponsors updates its tooling/algo’s. Common sense tells me that’s simply because they need time to adjust their programming at more levels than you and I would like to know.

And if that wasn’t enough, imagine having to come up with all the safeguards new features need before anybody is actually using the new features. Even their engineers need use case to test their updates on. And if nobody’s using the new features it’s extremely difficult for them to develop the proper support.

Thanks for the appreciation.

Reply

8 Ethan Collins October 8, 2015 at 1:04 pm

Thanks for the writeup — this page became my final stop for understanding mainEntityOfPage.

I have a few queries though, to better my understanding:
#1 With an eg: http://www.newegg.com/Product/Product.aspx?Item=N82E16819116989 is the main page for the product core i5 4690. So, all details for the schema.org/Product for core i5 4690 can be detailed here, with necessary mainEntityOfPage. But this same product can be displayed as a suggestion/recommendation on some other product’s main page. Now, on that recommendation instance, is it ok to just define the name and mainEntityOfPage or more information for the core i5 4690 is required there as well? (with mainEntityOfPage goals, I understand that will not be required)

#2 On the same recommendation instance on a separate page, as mentioned above, what is more appropriate: mainEntityOfPage or url?

#3 Continuing from above, in the recommendation instance, is the name even required? Shouldn’t usage of mainEntityOfPage take care of pointing to the product’s actual page where from all info for the page can be retrieved?

Thanks in advance.

Reply

9 Jarno van Driel October 12, 2015 at 6:46 am

#1 “Now, on that recommendation instance, is it ok to just define the name and mainEntityOfPage”

Defining just the ‘name’ is fine, though I wouldn’t specify ‘mainEntityOfPage’ on the recommendations but ‘url’.

#2 On the same recommendation instance on a separate page

Same answer as for #1

#3 ” is the name even required?”

The ‘name’ isn’t required at all as the search engine are able to fetch that information from the actual product page itself.

Reply

10 Ryan Rodden November 29, 2015 at 7:19 pm

I have a quick question about how to use “LocalBusiness,” or one of the more specific types such as “RealEstateAgent.”

How do they factor in here? I know I myself and many others markup the address of a company in their footer, which of course appears on every page. Does this “entity” need to have a relationship to anything else on the page, considering it is somewhat of an afterthought on a page by page basis, but quite important for local search?

I guess my question would be, how does “LocalBusiness” factor into the “Entity” structure of any given site, considering many websites are also local businesses.

Thanks – hopefully I was clear enough there.

Reply

11 Aaron Bradley November 30, 2015 at 12:17 pm

Thanks for your comment Ryan. From my perspective the most important principle your question highlights is that the entity information you most want to provide the search engines with is information concerning the entities most important to your business. In your example, that’s definitely information about the LocalBusiness in question, rather than the web page, website or other resource that describes that.

So from this perspective, yes, the entity you’re describing does need to have a relationship with information about it that’s contained in a page to which you’re making reference.

With the specific example you use, however, be aware that in providing data about an LocalBusiness you need not repetitively declare the same piece of data. If a 20-page site for a real estate company has the address of that real estate company in the footer of every page, there’s no benefit to providing that information to Google 20 times. Rather, what you’d want to do is provide that information once on a page where it makes the most sense to do so, like the home page or contact page.

Reply

12 Ryan Rodden December 9, 2015 at 8:03 am

I see – is there any negative to doing it in the footer, where it would appear multiple times over and over? I have applied this as such to a few clients now, but would be able to switch it to the contact page if need be…

Appreciate the response. You’ve gained a new follower.

Reply

13 Lance Fries February 8, 2016 at 9:31 am

Hello

My question is which I can’t seem to find an answer to anywhere is: I own a General Contractor Business as such we provide many different services. I would like to provide the NAP for my business on my website. Due to the fact that I offer many different services and have different pages for each service (hence would like each page found in different searches) would I be able to put different schema.org tags on each page.

For example my index (Home) page I would just like to be listed as local business, with the Address and Phone Number) because it describes many of the different services I offer. Landscaping, Decks, Fences, Lawn Care, Snow Removal, Etc Etc

But the next page is for Decks (For instance) is specific to Deck Builers! Can I then list that page as

Then for the next page which would be for Landscaping, can I then list that page as

Therefore telling search engines to list each page in the different categories that they relate to. Would you be able to do this or does the code have to be the same on every page?

Reply

14 Aaron Bradley March 22, 2016 at 4:25 pm

Thanks for your comment Lance, and sorry I didn’t see your question sooner.

There’s a number of approaches that would work here I think. Certainly for the base local business information you’d like to declare on your home page, employing Organization (of which LocalBusiness is a more specific type, so it – or a more specific type of LocalBusiness – can be used) markup as specified by Google is the most straightforward solution (and this certainly need only appear on the home page of your site).

For the rest there’s nothing in particular preventing you from declaring, on each of those subpages, the Product being offered (I’d probably use this, rather than Service, as Product is “[any] offered product or service”).

Alternately, if you’re using JSON-LD to make those NAP declarations about your business, you could extend the markup by using the hasOfferCatalog property, and then declare the individual services there (see the JSON-LD example under OfferCatalog).

Reply

15 Kevan Pewitt April 2, 2016 at 9:31 am

I got more out of this article than the 10 others I have read on Schema. My website is for a Real Estate Agency. I have my home page set to Local Business. On my website, I use the GeoDirectory Plugin to list schools, services providers, and places to visit in directories. What schema would you recommend for the directory listings? I am not sure if it would be schools, local businesses, and places as the mainContentOfPage for each listing or if it they all should be labeled as articles or blog posts about them. What do you recommend?

Reply

16 Jarno van Driel May 2, 2016 at 3:51 am

For listing pages I would use a schema.org/ItemList that contains the local businesses / schools / etc as their main entity.

Reply

17 Théo Trautvetter Carranza July 8, 2016 at 2:45 pm

Hello there, love your site, always find useful information here. I have a question for you, and here it goes: Suppose I have a web page in which I want to serve articles. Every article, ideally, should be treated by search engines as a separate page, for the purpose of indexing. Now, if I use the @type WebSite on the root (say, the landing page), should I use the same information on the articles, or should I ommit the @type WebSite from them, and use only the @type Article ?

Thanks in advance, and keep skeptic!

Reply

18 Aaron Bradley July 18, 2016 at 9:10 am

Thanks for your kind words and your question Théo.

Regarding that question, you would only declare your article pages to be @type Article, and not WebSite. Google derives no additional value from knowing that your articles reside on a website.

Reply

19 ColinK August 4, 2016 at 6:33 am

It would be very helpful to see some live URL’s that correctly implement mainEntityOfPage, to be able to see it in the Google Schema Validator

Thanks ColinK

Reply

20 Jarno van Driel August 4, 2016 at 9:57 am

I recently collaborated with TheNextWeb, their pages should be helpfull to you, eg https://goo.gl/ceZc6R

Reply

21 ColinK August 4, 2016 at 6:37 am

Follow up Q
If a page only features a ‘Residence’ and a realEstateAgent does mainEntityOfPage mean we have to select one of these – probably the Residence (property for sale)

ColinK

Reply

22 Jarno van Driel August 4, 2016 at 9:55 am

Going by the way you describe the page it seems best to specify the ‘Residence’ as the ‘mainEntityOfPage’.

Reply

23 ColinK August 8, 2016 at 5:26 am

Thanks for this article and to @jarno van Driel for answers to my specific questions.

How does mainContentOfPage differ from mainEntityOfPage? – it looks like I could identify the Residence as the main Entity of page and include 1 or 2 WebPageElements under mainContentOfPage to describe eg the Residence Image and the RealEstateAgents Image – then nest the Person or Organisation in the about section of that element.

Any comments appreciated

Reply

24 Jarno van Driel August 8, 2016 at 10:39 am

‘mainContentOfPage’ is a property that’s being discussed over at schema.org for about 3 years already. Reason being is that it’s part of schema.org/WebPageElement. A type that never really got support nor did it develop properly and which now is subject of a discussion whether or not it should be deprecated.

Main reason why deprecating WebPageElement is being discussed is beause it describes syntactical elements of a webpage as opposed to real-life entities – and in the end schema.org is about describing real-life entities and not parts of the HTML syntax.

So if I were you I’d forget about ‘mainContentOfPage’ as the likelihood of it ever being supported by the search engines is close to zero.

Reply

25 ColinK August 9, 2016 at 8:37 am

Thanks again Jarno

If you or someone else is willing to give more advice:

Is mainEntityOfPage still usable and (Assuming the page focuses on one specific property and I want to rank the page for that address)

Is it redundant (or bad for SEO) to give the property address in all of the following:
About
Name
mainEntityOfPage

or should one or more of these be omitted or used to give other descriptions eg North Dallas Condo

And is one of these more suitable than the others to branch off to @Residence or one of the sub types?

Reply

26 Jarno van Driel August 16, 2016 at 6:32 am

I’m afraid you’ve completely lost me with your question ColinK. Therefor I suggest you take them to the Google+ community Aaron and I moderate – http://bit.ly/1fb2ZOD – it’s better suited for this type of conversation.

Reply

27 Zohrap August 23, 2016 at 2:35 pm

i use microdata “http://schema.org/TaxiService” in homepage.

In child pages i have offers from main service in different directions

for example
main service name – Taxi in Moscow

hasOfferCatalog :
Taxi to airport from Moscow , (child1)
Long-distance taxi from Moscow, (child2)
………………………………………………..

child1 url: homepage/taxi-aeroport

1) child make as “https://schema.org/Offer”
he is part of main service – offer1 , but how to make relation ?

need solution same as schema WebPage/CollectionPage/ItemPage
https://www.w3.org/wiki/WebSchemas/ChainingLayoutElements

2) child make as “http://schema.org/TaxiService”

if i use same schema from main page (TaxiService) – the robot will understand that I have a lot of separate taxi services are not related to each other

3) use mainEntityOfPage form integrate multiple schema

in such a way, all the child pages are linked from the main page and have breadcrumb and other feature of the hierarchical structure of the pages, but only linked pages, not the service structure. and of course it is difficult to integrate multiple schemas, there are a lot of problems – in this case all the properties of taxi services must necessarily be in the mainEntityOfPage.

How to make a single scheme of microdata for all child pages as part of service

Reply

28 Jarno van Driel September 28, 2016 at 10:58 am

I’m not what to make of your questions without live examples of the pages you mention Zohrap. I suggest you post your question over at Semantic Search Marketing (http://bit.ly/1fb2ZOD), together with some example url’s as that platform is better suited to discuss your case than the comments on this article.

Reply

Leave a Comment

Previous post:

Next post: