Structured data provides search engines with additional context about your website and content.
Yet, I don't see many SEOs even remotely use schema markup to its full potential.
There's so much more to it than basic FAQ and Review schema.
In fact, more than any guide could cover.
This is why I'll focus on how to inject Machine-Readable Entity IDs (MREIDs) and entities into your existing schema setup for additional topical relevance.
What Are MREIDs & Why Should I Use Them?
MREIDs are basically standardized IDs of entities.
This makes it possible to clearly distinguish between, say, the company Apple and the fruit.
Google is perfectly able to figure out if your content is about the company or the fruit by looking at the content on the page itself.
But if you could explicitly tell search engines right off the bat that it's about the company and a specific product and provide additional references other than outbound external links, that would make things even more precise, right?
That's what MREIDs are for, and that's why you should use them.
How To Find MREIDs?
First, go to Google Trends.
Then, type the name of the entity you're looking for.
This triggers auto suggestions where you'll likely see different items with the same name.
Ignore everything that's tagged as "Search term" and focus on the other items.
Select the one that represents the entity your page is about.
Now copy & paste the part after the ?q= from your address bar into a text editor.
For example, if the URL in your address bar after selecting the correct entity is https://trends.google.com/trends/explore?q=%2Fm%2F0k8z you would copy & paste %2Fm%2F0k8z
Next, replace both occurrences of %2F with a forward slash.
%2Fm%2F0k8z would become /m/0k8z
Congrats, that's the MREID!
They always either start with /m/ or with /g/.
How To Inject MREIDs Into Schema Markup?
All you have to do now is to prepend a Google Search URL and query with the MREID and kponly (to only show the knowledge graph) attached and add those URLs as sameAs properties to your schema.
To stick to the Apple example, the sameAs URL would be: https://www.google.com/search?q=Apple&kponly&kgmid=/m/0k8z
White spaces within the search term after the ?q= would need to be replaced with + signs.
How To Apply This In Practice
For this example, I'm going to assume we have an affiliate site with a review of the MacBook Air M1.
Note: ALWAYS verify your structured data before you apply it to a production site.
1. Generate Product Review Schema
I've built a tool to generate product review schema, which we can enrich with MREIDs.
Click here to use the tool and generate your JSON-LD script.
2. Find Relevant MREIDs
For this step, you need Google Trends and your brain.
You'll want to find entities that are tightly related to the product and the brand, ideally the product and the brand themselves.
The first one is Apple the company, which we already selected in the example above.
The second one is MacBook Air, which seems to have its own entity as well. Nice!
If there's no entity for your specific product, the product category will do as well.
If there hadn't been an entity for MacBook Air or MacBook, I would have selected "Laptop" as topic entity.
3. Inject MREIDs Into Product Review Schema
To add the two MREIDs we found into our product review schema, we have to extend the brand and product parts.
I already covered above how you turn the MREIDs into Google Search URLs.
So let's add these to our JSON-LD script.
The parts that differ from the output of my product review schema generator are highlighted.
<script type="application/ld+json">
{
"@context":"https://schema.org/",
"@type":"Product",
"brand":{
"@type":"Brand",
"name":"Apple",
"sameAs":[ "https://www.apple.com/", "https://www.google.com/search?q=Apple&kponly&kgmid=/m/0k8z" ],
},
"name":"MacBook Air M1",
"sku":"macbook-air-m1",
"gtin8":"macbook-air-m1",
"image":"https://myaffiliatesite.com/images/macbook-air-m1.jpg",
"url":"https://myaffiliatesite.com/macbook-air-m1-review/",
"description":"This MacBook Air M1 review puts Apple's latest MacBook to the test.",
"sameAs":[
"https://www.apple.com/macbook-air/", "https://www.google.com/search?q=MacBook+Air&kponly&kgmid=/m/03hl5pv"
],
"review":{
"@type":"Review",
"datePublished":"2021-05-26",
"url":"https://myaffiliatesite.com/macbook-air-m1-review/",
"inLanguage":"en-US",
"description":"This MacBook Air M1 review puts Apple's latest MacBook to the test.",
"publisher":{
"@type":"Organization",
"name":"MyAffiliateSite",
"url":"https://myaffiliatesite.com/",
"logo":{
"@type":"ImageObject",
"url":"https://myaffiliatesite.com/images/logo.png"
}
},
"reviewRating":{
"@type":"Rating",
"ratingValue":"4.5",
"bestRating":"5",
"worstRating":"0"
},
"author":{
"@type":"Person",
"name":"Joe Doe",
"sameAs":"https://myaffiliatesite.com/author/joe-doe/"
}
}
}
</script>In addition to the official website URL, brand and product name, and product page URL, we now also have MREID-based references to the specific brand and product entities.
But why stop there?
Injecting Even More Entities
We know that a large part of Google's Knowledge Graph is based on data from Wikipedia.
So why not add Wikipedia pages as additional references?
We just have to find the Wikipedia pages for Apple and the MacBook Air and add these as well.
Our JSON-LD script would then look like this:
<script type="application/ld+json">
{
"@context":"https://schema.org/",
"@type":"Product",
"brand":{
"@type":"Brand",
"name":"Apple",
"sameAs":[ "https://www.apple.com/", "https://www.google.com/search?q=Apple&kponly&kgmid=/m/0k8z", "https://en.wikipedia.org/wiki/Apple_Inc." ],
},
"name":"MacBook Air M1",
"sku":"macbook-air-m1",
"gtin8":"macbook-air-m1",
"image":"https://myaffiliatesite.com/images/macbook-air-m1.jpg",
"url":"https://myaffiliatesite.com/macbook-air-m1-review/",
"description":"This MacBook Air M1 review puts Apple's latest MacBook to the test.",
"sameAs":[
"https://www.apple.com/macbook-air/", "https://www.google.com/search?q=MacBook+Air&kponly&kgmid=/m/03hl5pv", "https://en.wikipedia.org/wiki/MacBook_Air"
],
"review":{
"@type":"Review",
"datePublished":"2021-05-26",
"url":"https://myaffiliatesite.com/macbook-air-m1-review/",
"inLanguage":"en-US",
"description":"This MacBook Air M1 review puts Apple's latest MacBook to the test.",
"publisher":{
"@type":"Organization",
"name":"MyAffiliateSite",
"url":"https://myaffiliatesite.com/",
"logo":{
"@type":"ImageObject",
"url":"https://myaffiliatesite.com/images/logo.png"
}
},
"reviewRating":{
"@type":"Rating",
"ratingValue":"4.5",
"bestRating":"5",
"worstRating":"0"
},
"author":{
"@type":"Person",
"name":"Joe Doe",
"sameAs":"https://myaffiliatesite.com/author/joe-doe/"
}
}
}
</script>You can just use Wikipedia pages or other authoritative resources about the specific entity if it doesn't have an MREID.
Or, of course, in addition to MREIDs like in the example above.
Applying This To Other Schema Types
I only used the product review schema as an example because I mainly deal with affiliate sites.
Most people who'll read this are likely to be in the same boat.
But this strategy can be applied to pretty much any schema type.
For example, you could use this to enrich local service schema with entities that represent the service type, the service area, etc.
Or you could use it as part of your organization schema to describe the exact industry and type of business if there's no specific organization sub-type available that's relevant enough.
Impact On Rankings
My tests have shown a slightly positive impact on rankings in about 70% of cases after adding this kind of advanced product review schema with entity references to pages that didn't have it.
My theory is it has a more profound impact on pages where the content itself doesn't mention enough related NLP entities (or not clearly enough). In contrast, it might have a lesser effect on pages that are highly optimized for NLP.
But that's just a theory, and I don't have enough data to conclude that this is actually the case.
In any case, it's better to have this than not to.
Final Thoughts
The possibilities with structured data are endless.
I only touched the surface of one particular way you can use structured data for SEO.
The opportunity to directly communicate to search engines what a site or page is about and how it relates to known entities and external web pages is something every SEO should be exited about.
You should really dig through schema.org and see if there are relevant schema types you can add to your pages and then work on implementing them.
The types that search engines like Google use in their algorithm and SERPs change all the time.
But it's safe to assume that only more and more schema types will be part of the game in the future.
So why not future-proof your sites today and tell search engines what they're about EXACTLY?