Leveraging Machine-Readable Entity IDs for SEO

Once upon a time, I had a boss who would often describe my ideas as “bleeding edge”. I never much liked the description, because — frankly — it sounded disgusting. However, the term is meant to describe something a step beyond the cutting edge. An idea or strategy “so new and untested as to be potentially unreliable and carry a higher risk-to-reward ratio.” I’m not sure that applied to much of what I was doing back then in 2014 (well, there were a few things) but it certainly applies to this.

You’ll want to apply “potentially” and “theoretically” qualifiers to pretty much everything in this post. I think it’s worth taking action on this, but the benefits are as yet unproven. Note that, contrary to the definition of “bleeding edge” above, I think the risk here is almost non-existent while the potential upside is high.

Without further ado…

Let’s talk about machine-readable entity IDs in search and how to use them to your great advantage. Read on for more on the why and the how, and to get your free bookmarklet, too!

What is a Machine-Readable Entity ID?

In the world of semantic SEO, we talk a lot about entities. But there’s a significant distinction between plural “entities” and a single “named entity”. The former refers to people, places, or things more generally and the latter refers to one specific entity (like a single person or place or landmark).

The best way of referring to a named entity is to use a machine-readable ID. A machine-readable entity ID is, in essence, a string of characters used to exclusively refer to a single entity. These have predominantly been alphanumeric (numbers and letters) but don’t have to be.

Freebase/Metaweb, which Google acquired in 2010, was the first notable site to assign machine-readable IDs to entities.

But why is this significant?

With named entities, minimizing ambiguity is extremely important. What would happen if our names for “named entities” weren’t unique? It doesn’t take a stretch of the imagination to see how this is problematic. There are countless examples of companies sharing the same name (there are a few UpBuilds, BTW). And what about names of people? Yeesh.

If someone says “Mike Arnesen” to you — wonderful reader of the UpBuild blog that you are — you might immediately think of “Mike Arnesen, the SEO”. However, go ahead and mention “Mike Arnesen” to someone walking the streets of Dover, New Hampshire and they’d be more likely to think “Mike Arnesen, the chef who used to own Rebel Chef cafe”. We’re clearly two different people, but if we were only described as a “named entity” in human language, there would be a conflict. Ambiguity would arise!

::boo hiss::

In case it’s not obvious by this point, a machine-readable entity allows an entity to be named without any risk of confusion. People speak is flawed, so it’s best to get away from it. It would be much safer to use a system that uses 100% unique identifiers expressed as an alphanumeric string. So that’s what we have. Machine-readable entity IDs, like:

/m/0qs4dyq

Machine-Readable IDs in Google Search

As of the time of writing, Google seems to be issuing two variants of MREIDs. Thanks to Aaron Bradley for his help in clarify the differences between the two.

1. MREIDs for Freebase Entities: This class of entity IDs is reserved for named entities that were discovered and registered in the era of Freebase.

Format: /m/[a-z0-9]+
Example: /m/02nt25s for Bill Slawski
Example: /m/0qs4dyq for Mike Arnesen
Example: /m/01d3qq for the Kookabura bird

2. MREIDs for New (Post-Freebase) Entities: This class of MREIDs is used with entities that Google has picked up since Freebase went read-only. You’ll see new notable entities use the /g/ format, as well as entities that may not be truly notable (per something like Wikipedia’s standards), but are still entities that Google wants to track (e.g., Google My Business listings).

Format: /g/[a-z0-9]+
Example: /g/11dymg249k for Virtuous Pie (Pizza place in PDX)
Example: /g/1tfkqg96

Note: What if an older entity also has Google My Business page. For example, a notable local business like the Javits Center in New York? The freebase-era Entity ID is given precedence, i.e., /m/ is used rather than /g/.

As an interesting aside, Google is also creating a machine-readable entity ID for specific events. Note that it only seems to do this when they’ve been able to extract structured data from a site pertaining to that event and bring that into the Knowledge Graph (/g/11f55bxvp_ for SearchLove Boston and /g/11f55c40b3 for MozCon).

According to Bill Slawski — and thanks to his tireless work analyzing Google Patents, plus, generally paying more attention than anyone else — we know that Google is using MREID across many services like Google Trends, Google Lens, and Google Reverse Image Search (to keep track of entities within images).

Does that blow your mind? It should!

That means that this unassuming ID, /m/01d3qq, is being used to refer to the same entity across the entire Google universe! It identifies the Kookaburra bird in the Knowledge Graph, Google Trends, Google Image Search, and everywhere. That’s incredibly powerful.

Associating Yourself With an MREID

Back in 2013, Google introduced something called “invisible sameAs”. HT to Barbara Starr for pointing this out in relation to semantic SEO (she actually pointed it out to Bill Slawski, who pointed it out to me and spawned the idea for this post).

The “invisible sameAs” gives you the ability to include the microdata for itemprop=”sameAs” in your HTML as a element. The element is not displayed on the rendered page, making it effectively invisible.

When you consider the technical mechanics of it, it seems rather trivial, but it’s a powerful part of the semantic web. You can, and should, be using this to link to yourself (or your clients) as represented on other trusted websites. If the term “sameAs” sounds familiar, it might be because that’s the property that Google recommends you use to link your website to its corresponding social media profiles, i.e., the same entity represented on a trusted site.

But why?

The same reason that we try so many other things in SEO. To minimize ambiguity and provide engines with deeper and more relevant information for our mutual benefit.

I can’t tell you that this will generate a measurable ROI. I’m writing about this and testing it in the same week, so I just don’t know yet. My theory is that, in cases of uncertainty, it will help Google straighten things and, in all cases, strengthen the semantic connection between websites/content (i.e., strings) to the entities (i.e., things) that they discuss and represent.

Take as much or as little of this as you like, but it’s my belief that we’re going to be ahead of the game here. We’re setting our sights on where Google is going, not necessarily where they are today or have been in the past (which sometimes seems to be the majority of “SEO Best Practices” that get discussed).

At this point, I’m going to assume you’re onboard for trying this out. Let me walk you through two ways to do it.

How to Get Your MREID

Step one is to get your MREID from Google. As an integral part (you could say the integral part) of how Google is tracking entities across their whole universe, you’d be correct in thinking you can find this in a few places. Here are just a couple.

Google Trends: Bill Slawski told me about getting an entities MREID this way. Head to Google Trends and search for an entity. Make sure that the result you get is not a “Search Term” — a search term isn’t really an entity. There has to be a topic or type shown (like “Musical Instrument” below). Once you have that, you’ll be able to see a “q” parameter in the URL. The “%2F”s that you see are encoded forward slashes, so the MREID here is /m/03f5mt.

Wikidata: You can also head over to Wikidata and search for your entity there. If the entity was recognized in the era of Freebase, you should be able to find a Freebase ID on the page.

Here’s the Keytar example.

Google’s Knowledge Panel: This is not only my favorite way to get the MREID for an entity, but I think it’s representative of the importance of this whole discussion. Get this: Anytime that a recognized entity appears in the Knowledge Panel on Google SERP, its MREID appears with it in the markup for that panel!

The easiest way to get at it is by inspecting the “Feedback” option on a Knowledge Panel card. It manifests as the “card_id”. It seems telling that when you provide feedback on the Keytar Knowledge Panel, Google could care less about the query. The information that they ensure is passed along is the MREID!

Free Bookmarklet

All of those options take a bit of work to do, so I’ve done my best to try to simplify my life and yours. The link below is for a Bookmarklet that I wrote that will pull the MREID off of any Google SERP with a named entity on it.

~~Get The MREID~~ Note: This free bookmarklet has been deprecated

Drag this link up into your bookmarks bar (Chrome works best) and click on it next time you’re on a Google SERP.

You can also take the raw JS code (below) and drop it in the console on a SERP. The bookmarklet is much more satisfying to click.

See the Pen vrXvEo by Mike Arnesen (@mike_arnesen) on CodePen.

If there is a named entity represented on that SERP, the bookmarklet will output the associated MREID to the page along with a link for you to verify using Google Trends.

The bookmarklet will also output the same MREID to the console. You’ll see either this:

Or this:

Pretty neat, huh? I certainly think so.

Adding MREID to Your JSON-LD Structured Data

Adding an MREID to your JSON-LD data array is pretty easy. Just find your existing JSON-LD script tag and add an attribute-value pair.

[code language=”javascript”]
“sameAs” : “https://www.google.com/search?q=knowledge+graph+search+api&amp;kponly&amp;kgmid=/m/01d3qq”
[/code]

If you already have sameAs information in your JSON-LD tag, just turn the sameAs into an object with square brackets. In fact, if you also have a Wikipedia entry, I’d recommend doing this so you can link up with both your MREID and your Wikipedia representation.

[code language=”javascript”]
“sameAs” : [
“https://www.google.com/search?q=knowledge+graph+search+api&amp;kponly&amp;kgmid=/m/01d3qq”,
“https://en.wikipedia.org/wiki/Kookaburra”
]
[/code]

“But Mike, what if I don’t have JSON-LD on my site yet?”, I hear some of you saying. No problem. We’ve got you covered. Use this GTM tutorial to get yourself up to speed and then come back here to add in your MREID data.

On the topic of GTM, if you’re going that route you might want to store your MREID as a Google Tag Manager variable rather than putting straight in your tag. It’s a good habit to get into.

Adding an MREID to Your Inline Markup with entityLink.js

This piece is a bit more involved but still fairly straightforward.

I should note that advocating for inline markup seems to contradict UpBuild’s previously published stance, saying that we weren’t going to do inline markup anymore. Well, our opinion hasn’t changed. Writing inline semantic markup is still a righteous pain when you’re an outside consultant and JSON-LD is usually the path of least resistance. Why go through that much pain and suffering if the payoff is minimal?

Well, there’s a way to do this with (you guessed it; I’m predictable) Google Tag Manager that is both easy to roll out and extremely scalable.

Warning: This method and script require that your site is running jQuery. If your site isn’t, A) get on my level or B) let me know that it’s bumming you out and I can work on writing a version of this in pure JS.

Note: If you were so inclined or just aren’t using GTM, you could host entityLink.js on your site as a regular JavaScript file and just call it in the source code as you would any other script. Just be sure to call it after you call jQuery. Doing it this way isn’t my recommendation, but it can be done.

All it takes to get this setup for you to create one new tag in Google Tag Manager. You’ll be copying and pasting code from a script I wrote called entityLink.js and dropping that into a “Custom HTML” tag. Note: you’ll have to wrap the whole thing in script tags.

Here is entityLink.js in all its geeky glory.

See the Pen entityLink.js | MREIDs in GTM by Mike Arnesen (@mike_arnesen) on CodePen.

Before putting it to work for you, you’ll need to make a few slight changes.

Update the “entityName” variable to be the name of your company or client.
If needed, this could be rewritten as a Regular Expression that would match multiple name variations.
Update the “machineID” variable as well. This will be the MREID that you get using the MREID bookmarklet (see “How to Get Your MREID” above).
Update the “wikipedia” variable. If you have a page, put it there. If not, just leave the variable blank. If this variable is blank, the Javascript function that does the work will just omit anything having to do with Wikipedia.

Once you’ve made those slight modifications, you can put this in your Custom HTML tag and set up Triggering. You’ll want to set this tag to fire on every page using the Window Loaded event. The “All pages” tag that you’ll likely have in your Google Tag Manager container tag uses the Page View event, which causes your tag to fire before A) all your page content has loaded and B) before jQuery is available.

Save, Preview, and Deploy when ready.

What does it do though?

Good question. I’m glad you asked. Without trying to teach everyone JavaScript, here’s what entityLink.js does on your site.

Runs through all of the text within paragraph tags on the page.
Gets all the mentions of the brand name.
Replaces each instance of the brand name with the HTML below.

[code language=”html”]
<span itemscope itemtype=’http://schema.org/Organization’>
Brand Name
<link itemprop=’sameAs’ href=’https://www.google.com/search?q=knowledge+graph+search+api&kponly&kgmid=yourMREID’>
<link itemprop=’sameAs’ href=’yourWikipediaEntry’>
</span>
[/code]

Once you have entityLink.js deployed on your site, run it through the Structured Data Testing Tool and watch it validate!

What Comes Next?

UpBuild will be rolling this out on a handful of sites this month. You can bet that we’ll be watching to see what the impact is and if it’s successful in clearing up problems with entity confusion where they exist. If this discussion resonates with you or if you have an interesting use case for this concept, let me know in the comments.

Until next time. Happy optimizing!