Microdata vs JSON-LD: Which Structured Data Format Wins?

WEBVTT
00:00:00.360 --> 00:00:08.255
Hey Dominik, oh Steffen, what's the better structure, data format, microdata or JSON-LD?
00:00:08.255 --> 00:00:11.942
What do you?
00:00:11.962 --> 00:00:12.163
think.
00:00:13.760 --> 00:00:14.704
I don't know.
00:00:14.704 --> 00:00:18.533
And what about this other thing, RFD?
00:00:18.914 --> 00:00:19.442
A RDFA.
00:00:21.262 --> 00:00:23.675
Why is that one out of the question?
00:00:24.399 --> 00:00:24.660
already.
00:00:24.660 --> 00:00:37.192
Well, I guess, because it's really similar to Microdata and it has basically the same advantages and disadvantages unless you go really into depth, probably, and there might be reasons why to use the one over the other.
00:00:37.192 --> 00:00:43.841
But you know the answer, stefan, because it depends, right.
00:00:44.161 --> 00:01:07.474
So it always depends on what you want to do, and I mean Microdata and JSON-LD are both forms of integrating structured data or like schemaorg specifically that's what we usually talk about data into an existing website, right, so that search engines and other programmatic tools can use the information that you provide on your website in a better way.
00:01:07.719 --> 00:01:16.340
On the one hand, it's important for normal Google, but there are other search engines or like content aggregators, kind of like also Google Maps.
00:01:16.340 --> 00:01:31.375
If you specify like properties and availabilities and prices inside of your markup, this will actually be picked up without any additional work from your site by Google Maps or like other aggregators to display it on their site.
00:01:31.375 --> 00:01:40.668
And this is like really awesome, right, because you don't have to take care of managing content on multiple platforms and so on, but you can just use the integration.
00:01:40.668 --> 00:01:43.388
But what is now better than the other?
00:01:43.388 --> 00:01:45.484
And I would say it always depends.
00:01:45.484 --> 00:01:47.811
Usually I would prefer JSON-LD.
00:01:47.811 --> 00:02:01.516
The reason why that is you have like one blob of JSON at some point in your markup and you can easily debug that, because you can just read that out and see what kind of content you've provided there.
00:02:01.780 --> 00:02:15.074
But this usually is also harder to implement, and it's especially like where it is easy to implement is on pages or for things like events or for entities that are predefined, that have a fixed structure.
00:02:15.074 --> 00:02:26.120
Then you usually know when you render a page or when you, when you render a page for this content, you have the entire, like all of the information already gathered at one place.
00:02:26.120 --> 00:02:35.406
You can say, okay, this is my event, and then you can just say, okay, eventstart date or whatever is, and I will just render this out into a JSON object.
00:02:35.406 --> 00:02:54.114
Then only the data that I actually want to display I will render in the markup like as a real HTML attributes or HTML elements and attributes, and thus you can like keep the markup really clean and separate the actual structure data from the markup.
00:02:54.114 --> 00:03:09.319
So this is why I would usually go that way, but in some situations it is a lot better, or easier at least as well, to have HTML attributes as structured data right or to define your structured data there.
00:03:09.319 --> 00:03:30.931
You can use micro data or RDFA, and it just is a difference of the naming of the attributes right and the URLs where the schemas are located, and a typical examples for that are like accordions, for example, because at the beginning you don't really know what kind of content, how many items there will be, and so on, right.
00:03:30.931 --> 00:03:43.073
So it's usually a lot easier and them might be a lot of content, like a lot of text, and then you would duplicate a lot of characters, like in your markup and then in JSON LD.
00:03:43.073 --> 00:03:53.875
So instead of extracting that and putting it into a JSON object, I would just add these attributes to the, to the HTML elements directly.
00:03:53.875 --> 00:04:01.270
Other examples are sliders or galleries, right, where you have multiple like elements, where you don't know how many there are.
00:04:01.939 --> 00:04:10.449
It's also important to know that you can have also multiple JSON LD script tags on your website, like it doesn't only have to be one.
00:04:10.449 --> 00:04:37.610
So, for example, if you have an overview with events, let's say, I would probably put one script tag with, like the JSON LD data inside of each of the containers where you render the event and then I don't know maybe combine that with if the event, for example, has multiple images, you could think about OK, if you want to add this to this structured data, to the JSON LD, or combine that with micro data.
00:04:37.610 --> 00:04:47.386
However, now that I say that, I am not 100% sure if you can combine, like if this data gets merged right, I think it's one or the other.
00:04:47.386 --> 00:05:01.105
But you can have multiple things, like you can, for example, have an event on one like as a JSON LD, and then FAQ as like micro data on the same side, and this will be picked up.
00:05:01.105 --> 00:05:07.132
But I don't know if you can mix, for one event, data inside of JSON LD and micro data.
00:05:07.132 --> 00:05:09.384
So I'm this.
00:05:09.384 --> 00:05:10.807
I think I haven't tried.
00:05:12.060 --> 00:05:36.523
OK, but so you basically say, like for data structures that are very predictable kind of, you would recommend actually like maybe that actually the micro data, when it's when the markup is predictable, let's say, like that, right, with an accordion, likely there's not much that will change in terms of the markup and the layout, so you don't have to pay a lot of attention.
00:05:36.523 --> 00:05:55.136
It's always the title kind of, and the content relationship is very clear, whereas when the representation is more complex then you might accidentally like mess with the markup and it gets much more complicated to make that work and keep track of that within the markup.
00:05:55.136 --> 00:06:05.870
And then it's better if you use JSON, because there you have a very structured format and you can prepare it, but at the same time you're kind of duplicating the content.
00:06:05.870 --> 00:06:15.228
Yes, it really depends there again, but what you said about the sliders, why is it that you don't like that to use?
00:06:15.228 --> 00:06:24.033
Then JSON objects when they're like multiple elements, couldn't you just like run a loop and generate that JSON in a loop?
00:06:25.576 --> 00:06:28.343
Yes, yeah, you totally could like in.
00:06:28.343 --> 00:06:30.648
It's just like a preference, I guess.
00:06:30.648 --> 00:06:40.925
So I think, if it's, if it's something that again is part of a more structured data entity, I would probably put it in an array and just read it out.
00:06:40.925 --> 00:06:46.627
But if it's like a manual thing, right, if you have a manual slide and you can just fill it with images.
00:06:46.627 --> 00:06:51.644
Yeah, I think your explanation was actually quite good before.
00:06:51.925 --> 00:07:12.249
When you have just simple, really simple structures, like in a, in an accordion, it's just like if you have a template, right, an accordion is always like consists of two things like the headline and the content, so you can easily just add this to the markup, to the, to the template, these attributes for slider, it's usually the same.
00:07:12.795 --> 00:07:15.983
You have an alt text and you have like the URL of the image.
00:07:16.444 --> 00:07:28.321
I guess and this is also quite easy to do I'm always like trying to balance the ease of implementation and then the correctness or like the quality in the end.
00:07:28.615 --> 00:08:09.704
So in general, if it was really easy to implement all of that, I would probably say just always go with Jason, because this is usually like the cleaner way to do things and, again, easier to debug, but sometimes it's just a lot harder for, like if you are in a page builder and in Flint we are always like using kind of our own page builder with like ACF, flexible content right, and in order to get all the data you would have to loop through the entire content, like figure out, like what is the structure data, and there it's just a lot easier to go into a component and in this component just say what the structure data fields are and add this to the markup.
00:08:09.704 --> 00:08:20.846
You could, of course, use like some filter or like an additional component or like a module or feature to collect this data from every component that has been rendered and so on.
00:08:20.846 --> 00:08:24.045
But again, this just makes things more complicated.
00:08:24.045 --> 00:08:29.389
And then I find it's easier if in these components you see immediately what is used as what.
00:08:29.651 --> 00:08:40.845
Ah, okay, see, like I thought until now that maybe it's more about the predictability of data, but actually I think it's rather about the nesting of data.
00:08:40.845 --> 00:08:43.301
Right, because the example that you gave was an event.
00:08:43.301 --> 00:08:46.504
You have all the event data available on a global level.
00:08:46.504 --> 00:09:13.527
You have that there right away, right, when you query the object, the field group, whatever it is, then you have that data and you can just directly put it out into a JSON object, whereas a slider, which might have nested additional fields like text on top and icons and options, yeah, you would need to do the rendering process of that actually twice, once for the markup, once for the JSON and then you have a lot more code and so on that you create.
00:09:13.527 --> 00:09:30.658
Yeah, it actually increases the complexity there, and then it's might be preferred to just shift that complexity to the markup or the slide complexity and then just use the typical schemaorg or Google validators to see if you got things right there with the markup.
00:09:30.658 --> 00:09:31.962
Yeah, Okay.
00:09:33.274 --> 00:09:35.000
So that's the great that we found that out for ourselves.
00:09:35.000 --> 00:09:44.724
I hope anyone else will learn from this and let us know if you agree with that or if you have a different opinion or use different methods.
00:09:45.274 --> 00:09:47.836
Yeah, would be really interesting to hear about that.
00:09:47.836 --> 00:09:48.676
Bye, bye.
00:09:49.375 --> 00:09:56.198
Bye, bye, bye, bye, bye, bye, bye, bye, bye, bye, bye, bye, bye.