• Monday February 18, 2019
    Family Day in Canada and Presidents' Day in the US

    Some forum members and Local Search Experts will be off today. It may take longer to receive answers to your questions.

JSON Schema


JoshuaMackens

Local Search Expert
Joined
Sep 12, 2012
Messages
1,497
Likes
311
For those of you using JSON schema, am I correct in understanding that it outputs in the code and not physically on the website?

If so, how would you mark up an address you have on your website? If you use JSON it looks like you would have the address marked up in the code and then have to mark up the address that renders on the site as well.

Do you mark it up with a schema and have 2 markups? Do you just not mark up the address at all? Or do you just not use JSON?

My schema knowledge isn't that polished so forgive me if I left any details out I shouldn't have.
 
Joined
Oct 25, 2013
Messages
770
Likes
289
So the way schema was originally implemented (as I understand it at least) was with a microdata style approach to adding meta data to content on your site. Makes sense, you have the html you want your users to see, and then you update it with meta data so that search engines can understand more information about what you're sharing with your users. 5~6 years ago, Google, Yahoo and Bing got together to make schema.org to try and wrangle a standard specification that everyone can use on their site. There ended up being 3 specifications you can use, microdata (markup elements directly in your html as needed) RDFa (you can think of this as microdata 2.0 in a lot of ways... it's much more flexible, but still implemented right in the html, along with the content you're marking up) and then there's JSON-LD.

All 3 are basically languages that express similar concepts, they just do it with different syntax and different organizational structures. For example:

Here’s a simple Microdata snippet:
HTML:
<p itemscope itemtype="http://schema.org/Person">
  <span itemprop="name">John Doe</span> is his name.
</p>
Here’s the same snippet using RDFa (Lite):
HTML:
<p typeof="schema:Person">
  <span property="schema:name">John Doe</span> is his name.
</p>
And here's the same thing expressed with JSON-LD:
HTML:
<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "John Doe"
}
Here's the catch, you my have noticed that the JSON-LD snippet doesn't actually contain the part of the document that mentions John Doe. All it's doing is saying there's a guy named John Doe. It's assumed that the document mentions John Doe somewhere, but it's up to the webmaster to make sure the content on the page actually matches the JSON-LD snippet. That's why Google says not to put anything in your JSON-LD code that's not actually contained in the page. As a relevant example, don't include schema for a location on a page that's not actually about that location.

So, if there's 3 different specifications you can use, which should you pick? It doesn't actually matter hugely, though Google recommends JSON-LD, and JSON-LD is way easier to maintain. Since it's all in one block, you don't need to laboriously sift through a bunch of html just to find the relevant pieces to update or add. In other words... use JSON, and stop using microdata entirely.
 

JoshuaMackens

Local Search Expert
Joined
Sep 12, 2012
Messages
1,497
Likes
311
So the way schema was originally implemented (as I understand it at least) was with a microdata style approach to adding meta data to content on your site. Makes sense, you have the html you want your users to see, and then you update it with meta data so that search engines can understand more information about what you're sharing with your users. 5~6 years ago, Google, Yahoo and Bing got together to make schema.org to try and wrangle a standard specification that everyone can use on their site. There ended up being 3 specifications you can use, microdata (markup elements directly in your html as needed) RDFa (you can think of this as microdata 2.0 in a lot of ways... it's much more flexible, but still implemented right in the html, along with the content you're marking up) and then there's JSON-LD.

All 3 are basically languages that express similar concepts, they just do it with different syntax and different organizational structures. For example:

Here’s a simple Microdata snippet:
HTML:
<p itemscope itemtype="http://schema.org/Person">
  <span itemprop="name">John Doe</span> is his name.
</p>
Here’s the same snippet using RDFa (Lite):
HTML:
<p typeof="schema:Person">
  <span property="schema:name">John Doe</span> is his name.
</p>
And here's the same thing expressed with JSON-LD:
HTML:
<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "John Doe"
}
Here's the catch, you my have noticed that the JSON-LD snippet doesn't actually contain the part of the document that mentions John Doe. All it's doing is saying there's a guy named John Doe. It's assumed that the document mentions John Doe somewhere, but it's up to the webmaster to make sure the content on the page actually matches the JSON-LD snippet. That's why Google says not to put anything in your JSON-LD code that's not actually contained in the page. As a relevant example, don't include schema for a location on a page that's not actually about that location.

So, if there's 3 different specifications you can use, which should you pick? It doesn't actually matter hugely, though Google recommends JSON-LD, and JSON-LD is way easier to maintain. Since it's all in one block, you don't need to laboriously sift through a bunch of html just to find the relevant pieces to update or add. In other words... use JSON, and stop using microdata entirely.
Thanks James.

Do then I shouldn't markup the address at all since it's already mentioned in JSON? Google will find it in JSON and then search for it on our page which is effectively "marking it up"?
 
Joined
Oct 3, 2012
Messages
965
Likes
265
mark up everything you can. As an added tip for ease, use Google Tag manager to implement all the code. That way you can mark up new stuff as it comes up, and you don't have to mess with the code. Use Tag Manager's preview tool to test and make sure you implemented it correctly, then you're good to go.

Don't use Microdata to mark up these days. Way too labor intensive.
 

JoshuaMackens

Local Search Expert
Joined
Sep 12, 2012
Messages
1,497
Likes
311
So, just to confirm, I have JSON marketing up NAP in the back of the code. Then, I have our NAP in the footer, unmarked. Google will see our JSON marking up NAP in the back of the code and then search out our unmarked NAP in the footer and all is well, correct?
 
Joined
Oct 3, 2012
Messages
965
Likes
265
Google will see everything you put on the page. So they will see both the raw HTML in the footer and JSON markup.
 

JoshuaMackens

Local Search Expert
Joined
Sep 12, 2012
Messages
1,497
Likes
311
Google will see everything you put on the page. So they will see both the raw HTML in the footer and JSON markup.
I understand that. I'm just making sure the raw NAP html doesn't need to be marked up individually apart from the JSON. The fact that the JSON is marked up is sufficient enough and Google will be able to draw the link between the JSON and the raw NAP html, providing they match up correctly of course.
 
Joined
Oct 3, 2012
Messages
965
Likes
265
Yes, use JSON instead of microdata markup. Use raw HTML so the information renders for users, but JSON is what the search engines will digest.
 

mborgelt

Local Search Expert
Joined
Jul 22, 2012
Messages
471
Likes
150
Thanks for that tip, Eric. We are moving over to Tag Manager and I had no idea it did JSON as well.
 
Joined
Oct 3, 2012
Messages
965
Likes
265
Thanks for that tip, Eric. We are moving over to Tag Manager and I had no idea it did JSON as well.
Someone on another forum told me about that, and it was a game changer for me. I run all schema, analytic, and pixel changes through tag manager now. It's so much easier to test without the need to monkey with the core code of the site each time.

Use the "custom HTML" option in tag manager to add schema markup with JSON.
 

pbarnhart

Forum Member
Joined
Apr 5, 2013
Messages
71
Likes
65
If you are looking for technical assistance in generating JSON-LD via tag manager, here is a good technical approach (I use a similar approach to create JSON-LD Product tags for a client on a legacy platform).
 

pbarnhart

Forum Member
Joined
Apr 5, 2013
Messages
71
Likes
65
Bing (which also powers Yahoo, AOL, and is the search partner used by Amazon's Alexa) represents 10-20% of US search traffic.

Check their local stats: https://advertise.bingads.microsoft.com/en-us/insights/planning-tools/bing-network-audience

I use tracking numbers with Bing, Yelp, etc (paid and website click) etc and for most of our local business clients, organic Bing represents 5%-10% of conversions and Yelp < 2% so I am happy for my clients' competitors to ignore Bing :D
 
Joined
Oct 3, 2012
Messages
965
Likes
265
I agree you shouldn't ignore Bing, but they also don't support JSON markup yet. So Bing is starting to get severely behind the times when it comes to schema markup. If you want to mark up everything in microdata format, that would take forever to implement.

https://www.bing.com/webmaster/help/marking-up-your-site-with-structured-data-3a93e731

https://social.msdn.microsoft.com/F...63b/does-bing-support-jsonld?forum=applinking

Schema can help, but as long as you have other pieces of information Bingbot can parse located on your site then it's probably OK to ignore it. I'd rather do something more meaningful with my time to move the needle with Bing instead of hard-coding microdata.
 

Larry

Forum Member
Joined
Jun 16, 2013
Messages
22
Likes
3
On which pages should the JSON-LD code be installed. I have my NAP and business hours in the html in a footer widget which appears on every page, and the JSON-LD code with NAP and business hours on the main page only.

Should the JSON-LD code be on every page?
 

Similar threads


Local Search Forum


Weekly Digest
Subscribe/Unsubscribe


Google Product Exert

@LocalSearchLink

Join Our Facebook Group

Top