How to use V2.0’s mainEntityOfPage property

by Jarno van Driel on May 15, 2015

in Search Engines, Semantic Web

How to use V2.0’s mainEntityOfPage property

With the release of 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.


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 as it goes on to describe its intended use and where it stands in relation to properties like, http://schema/org/sameAs and Properties to which mainEntityOfPage is very closely related and which are part of’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="" itemid="#thecafe">
    <a itemprop="mainEntityOfPage" href=""><h1 itemprop="name">Cath's Cafe</h1></a>
        Open: <time itemprop="openingHours" datetime="Mo,Tu,We,Th,Fr,Sa,Su 11:00-20:00">Daily from 11:00am till 8pm</time>
        Phone: <span itemprop="telephone" content="+155501003344">555-0100-3344</span>
        View <a itemprop="menu" href="/menu">our menu</a>.

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 basics first. 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 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="">
    <a itemprop="url" href="">
        <span itemprop="name">Explosive tennis balls</span>

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

If you visit 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 (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:

        <article itemscope itemtype="">
            <h1 itemprop="name">Explosive tennis balls</h1>

as if you had specified:

<body itemscope itemtype="">
        <article itemscope itemtype="">
            <h1 itemprop="name">Explosive tennis balls</h1>

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="">
        <article itemscope itemtype="">
            <h1 itemprop="name">Explosive tennis balls</h1>

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. and - 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 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 markup:

<body itemscope itemtype="">
        <section itemscope itemtype="">
            <h2 itemprop="name">Acme Product Launch</h2>
        <article itemscope itemtype="">
            <h1 itemprop="name">Explosive tennis balls</h1>

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 is nested within an < aside > search engines will understand this markup should be considered secondary content and that the 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:, and - 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 rich snippet where you were hoping for a 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 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:

        <link rel="canonical" href="">
    <body itemscope itemtype="">
            <section itemscope itemtype="">
                <h2 itemprop="name">Acme Product Launch</h2>
            <article itemscope itemtype="">
                <h1 itemprop="name">Explosive tennis balls</h1>
                <link itemprop="mainEntityOfPage" href="">

Which from a graph point of view looks like this:

a that's the mainEntityOfPage of a, which also contains a top level

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'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:">

        <link rel="canonical" href="">
    <body itemscope itemtype="">
            <article itemprop="mainEntity" itemscope itemtype="">
                <h1 itemprop="name">Explosive tennis balls</h1>
            <section itemscope itemtype="">
                <h2 itemprop="name">Acme Product Launch</h2>

Which looks like this in a graph:

a which's mainEntity is a but which also contains a top level

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 v2.0 incompasses than make sure to read the article my partner in semantic crime Aaron Bradley wrote.

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. 🙂

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

I second that sentiment David. 🙂

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

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 (S) – Let’s say a – has to be a direct child of the (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, 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.

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!

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.

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 puzzle. 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; foaf had its equivalents long before did: 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 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.

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: is the main page for the product core i5 4690. So, all details for the 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.

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.

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.

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.

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.

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


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 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?

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).

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?

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

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

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!

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.

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

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

I recently collaborated with TheNextWeb, their pages should be helpfull to you, eg

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)


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’.

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

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

‘mainContentOfPage’ is a property that’s being discussed over at for about 3 years already. Reason being is that it’s part of 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 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.

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:

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?

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 – – it’s better suited for this type of conversation.

27 Zohrap August 23, 2016 at 2:35 pm

i use microdata “” 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 “”
he is part of main service – offer1 , but how to make relation ?

need solution same as schema WebPage/CollectionPage/ItemPage

2) child make as “”

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

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 (, together with some example url’s as that platform is better suited to discuss your case than the comments on this article.

29 Craig Foley October 27, 2016 at 6:34 pm

Google say that this is the canonical URL, at least when using Articles.

Also, how would you associate an element when using JSON-LD? Doesn’t seem possible.

30 Jarno van Driel November 8, 2016 at 3:30 pm

“Google say that this is the canonical URL”

Exactly the url I used in my example so I’m not sure what you’re trying to point out with your remark. Can you elaborate?

“Also, how would you associate an element when using JSON-LD?”

What do you mean with “an element”?

31 Prashant March 1, 2017 at 1:29 am

I have a website with health information for general public. There seem to be many schema types that each page could use : article/blog/blogposting/ medicalcondition/medical procedure/medicalspeciality,etc.
My question is this :
1. It’s the ” article” type good enough for most pages or is it better to be more specific. I ask this question because Google definitely supports article markup but I’m not sure about the others.
2. Suppose information about a medical condition also includes information about a medical procedure, can both markups be used on say a single blog post?

Thanks in advance.

32 Aaron Bradley March 9, 2017 at 8:04 am

1. Yes, Article is probably sufficient for your purposes.
2. Yes, the two can be combined. However, because you’re declaring the entire page as an Article, you’re probably best off introducing what medical procedures the piece is talking about by using the about property of Article.

33 Prashant April 5, 2017 at 9:35 am

Thanks for the answer.

34 Tony McCreath March 24, 2017 at 7:14 pm

AMP page validation requires you to mark up an Article as the mainEntityOfPage. So what do you do if the true main entity is something else, like a Product or Event?

Use different markup for the AMP pages?

Have two mainEntityOfPage entities. I presume that’s silly, but I’ve seen it around.

I’m currently testing the idea of marking up an entity as two types and having that as the mainEntityOfPage. I’m sure it’s going to end in tears:

I’m seeing rich snippets and AMP validates, but that’s not proof it’s the right thing to do!

35 Jarno van Driel March 28, 2017 at 1:22 pm

So what do you do if the true main entity is something else, like a Product or Event?

Alas at this moment in time there’s nothing you can do. The only type Google currently supports is – and that’s it. Of course you can do what Ebay does/did (don’t know what the current state of that project is) and experiment with AMP for ecommerce (and add markup yourself) but be aware that’d be a learning experiment at best as there’s no support for it (yet).

Have two mainEntityOfPage entities. I presume that’s silly, but I’ve seen it around.

That’s exactly what one shouldn’t do with mainEntityOfPage. This property is meant to indicate the single entity that represents the main topic of the page. Specifying multiple instances of it not only goes against its definition but also goes against the reason why the property exists (as I explained in the article above).

I’m currently testing the idea of marking up an entity as two types and having that as the mainEntityOfPage.

Defining a, for example, “@type”:[“Product”,”Article”] might get you the article snippet (until Google closes the loophole) but it would be counter productive as the meaning of such an Multi-Type Entity would be a specific type of Product, namely an Article. Which would be fine if you’re offering articles for sale but if you’re offering anything else than that it only creates confusion for search engines. Confusion that could for example lead to Google discarding the markup all together because it’s of low-quality.

I’m seeing rich snippets and AMP validates, but that’s not proof it’s the right thing to do!

Exactly, and not only that, nobody’s served by Google showing Products as Article snippets – it’s nice Product snippets folks (will) want. Unfortunately we’ll have to wait for that option until the day Google’s confident AMP for ecommerce will be a success.

36 Rodrigo Perera May 2, 2017 at 9:57 pm

Hi Jarno,

I have read your article more than 10 times over last few months while trying to solve our SEO nightmare where Google index text from article snippets (below the main article) as part of the current blog post.

This is an example page

If you run this page on structured data tool, you can see that we mark up the main article page as type “BlogPosting”. We also markup the blog post snippets as an “ItemList”. Each item in this “ItemList” contains a “mainEntityOfPage” property which identify the URL in which this snippet is the main entity.


So I am not sure why google still think these text excerpts from blog post snippets are part of the current page. Can you please point me in the right direction?

Thank you so much.

37 Jarno van Driel May 8, 2017 at 8:41 am

I see several things that are ‘wrong’ with the page you mention. First and foremost, the page doesn’t contain a BlogPosting but shows a list of images. Most probably the reason why Google is using text excerpts from blog snippets (some of these contain more content than the main content itself).

Secondly, the fact you marked up the content as a BlogPosting – which it isn’t! – In it’s current state the best you can make of it is an ItemList with ImageObjects.

Sorry to say but if you want Google to use excerpts from the actual BlogPosting make sure to give them something they can use! Markup isn’t the solution here.

38 Rodrigo Perera May 12, 2017 at 1:52 pm

Hi Jarno,

Thank you so much for the reply. This is the classic problem with User Generated Content (UGC). Even though we provide free blogs, I can not control what people put in them. So in this specific example, a user choose to only add photos to his blog post.

So, as you said, we have a content problem rather than a markup problem.

To address that, I plan to remove these text excerpts from snippets. This way at least I can save the good posts. Because Google will no longer assume we are duplicating the content from good posts in many of our pages.

If you have a minute I would like to hear your opinion about that.

Thanks again for pointing out the underlying issues with the SEO on our site.

Have a nice day.

39 Milos September 29, 2017 at 8:47 am


How would you apply this in JSON-LD format.

Previous post:

Next post: