is that it would get kind of awkward.


Looking back on 2020 with Search Relations | Search Off the Record

Everyone is in the virtual meeting


and is like, nobody's really speaking.


But none of that happened.


That was pretty cool.


The thing I really enjoyed is all of the interactions there,


being able to hear from a broader group of people


that normally aren't in the other events that I do,


like the office hours, totally different set of people


there from all around the world.


So that was pretty cool.


I think the one aspect that was kind of tricky from my side,


kind of looking at it as a lead of the group,


is the size of the event.


It would have been nice to do something really large.


But at the same time, this is the kind of event


that you can't do really large.


You can't do a video call with 100 people


and expect everyone to be kind of open


and speak about their opinions during one session


because otherwise that session would be super long and kind


of super weird as well.


So who else wants to introduce themselves?


And it's like, oh, number 97, you haven't said anything.


But yeah, I thought that went really well.


MARTIN SPLITTENBERG Thank you.


That's really good to hear.


And that is basically mirrored both by the feedback


we got from the participants as well as from the session leads


and from the teams at Google who were leading sessions


in the event as well.


And yeah, that has been one of the complications this year,


right?


So we had to balance the size of the audience


and the productivity that went there,


like the level of interactions that we


could foster in this event.


But also for the other things, like we


started recording the podcast earlier this year.


And if you remember correctly, our test recording,


which unfortunately didn't make it into an episode yet,


that was in the office.


JOHN MUELLER I thought we published that as a trailer.


I'm not sure.


MARTIN SPLITTENBERG A very, very tiny part of it.


OK.


I think that was really kind of cool


because we've been thinking about doing a podcast for quite


some time now.


And we started on this track, I think,


when everyone was still in the office, which was really,


I don't know, it feels like an eternity ago.


And yeah, it's been really fun doing all of these podcasts.


GARY ILLYES-SELLERS I mean, it was definitely in the office


because I remember that in January when we were writing


down our plans, what should we do this year,


then podcast was one of the items.


And then we started talking to Anna, our producer, about it.


And then it came to be at one point.


But the first episode, the trailer, I don't know,


was recorded in the office because I remember setting up


on the table and we couldn't touch the table


because then Anna was yelling at us for touching the table


because the mics were sensitive and picking that up.


And she was lugging around all this equipment.


I felt sorry for her.


Now we have all of the equipment to lug around ourselves.


MARTIN SPLITT SANDBERG Exactly.


Oh, man.


I think the whole way of recording


has changed quite a bit.


I remember when we shot the first video series I've done,


that was JavaScript SEO.


That was in 2018 in Zurich in a separate location.


And it was awesome.


And then at the end of it, our producer Anna and I


had to lug the equipment back to the office.


So we had this 10-minute walk with all the stuff.


And yeah, that was fun.


And so myth-busting season one was easier.


That was in the studio space in Mountain View


right after Chrome Dev Summit 2018.


And we used the studio space.


And it has been pretty smooth, even


though we had to redub whenever I


said the name of the series because for trademark reasons.


And season two was completely shot in one day in November


2019 in New York.


That was also really, really fun.


We could shoot the whole season in one day


because the studio team really knows what they're doing.


Everything's set up.


It's a soundproofed environment.


It's just really, really nice and easy.


And you do see a change in the later series.


The first Webmaster Conference Lightning Talks


were recorded in a studio setting.


But then corona hit.


And then we had to record the later ones at home.


And some series, like the upcoming series,


Sustainable Monetized Websites from Aurora Morales,


that's entirely home recorded.


It was home recorded from the get-go.


And I think that's really impressive given how tricky


home recording is and how much work goes


into making that possible.


That's really impressive.


And speaking of impressive recording,


how's your recording going, John?


They're very good most of the time.


I think it's something where you also


realize how much work the video team puts


in to do the recordings in the studio, where it's like, oh,


let's change the frame just slightly a little bit.


Or let's make the camera so that it's actually


properly horizontal and not slightly crooked.


It's like all of these small details where you're like,


oh, it's like if you're behind the camera,


you just do it quickly.


But if you have to do it yourself,


it's always back and forth all the time.


It just takes a long time.


And the lighting is something that, at least


for photography, I never really figured it out.


So I basically gave up on trying to do anything with lighting.


And now with all the video recordings,


you kind of have to do something.


And they've been really patient and helped


to get the lighting more or less OK, which is pretty cool.


I think the tricky part with lighting when you're recording


at home is also that there's this big light outside that


sometimes comes and goes.


And at least here where I am in Switzerland,


it's often slightly obscured.


So when it decides to pop out, it changes everything,


which is so annoying.


I wish that someone could just control


that a little bit better.


How's that working on your side, Martin?


MARTIN SPLITTENBERG Oh, god, I know exactly what you mean.


And it's not just the lighting conditions.


I had that where in the middle of the recording,


the cloud in front of the sun went away.


And then everyone's like, hold on, hold on, hold on.


What happened to the light?


I'm like, it's called the weather.


That's what happened to the lighting.


I'm so, so sorry.


It's also the sound.


I mean, I had sheep next to my window earlier this year.


Sheep.


Sheep, like living, breathing, grass-eating sheep.


And they do make noises.


And that has not necessarily been


easy to deal with sometimes.


Bad noise.


Also, I wish that our audience could see Gary in his lair.


It's like a floating hat because he wears a black t-shirt


and then is in front of a black background.


It's amazing.


GARY ILLYES-SELLS-SANTOS I'm so sorry.


JOHN MUELLER So how's the lighting for you, Gary?


GARY ILLYES-SELLS-SANTOS I don't have lighting.


That's the beauty of it.


I don't record videos at all.


So I don't have to care about lighting.


I'm actually working really hard to not have lighting.


JOHN MUELLER Wow, at least you don't have to worry about the sun in that case.


GARY ILLYES-SELLS-SANTOS The sun?


I don't know.


MARTIN SPLITT No such thing in Gary country.


GARY ILLYES-SELLS-SANTOS I don't know what you're talking about.


I haven't seen the sun for a year.


JOHN MUELLER Oh, man.


Yeah, I don't know.


Like being stuck at home is kind of annoying.


GARY ILLYES-SELLS-SANTOS Tell me about it.


JOHN MUELLER I guess we'll have to get used to it at some point.


One of these years, right?


GARY ILLYES-SELLS-SANTOS I mean, I'm already used to it.


I'm just sitting in my chair, sometimes going to the kitchen and cook something and sometimes


recording podcasts.


And occasionally I also do some work because I was told I have to.


But yeah.


MARTIN SPLITT I miss you all.


JOHN MUELLER So how's your blog coming along?


Did you end up getting any of that set up?


GARY ILLYES-SELLS-SANTOS Well, as you by now know, we had a relatively big project, which


was basically consolidating our documentation under one site, essentially.


And I was doing lots of scripting and also programming for that, which meant that I had


to refocus my attention, essentially.


And I had to work on that.


But now that I have more time because, you know, holiday season and we can't launch anything


anyway, now I'm actually doing more stuff around the blog.


Plus, we had another good idea with Lizzie, our tech writer, which we might try.


That would be fun.


But I'm not saying anything about it.


I don't want to jinx it.


JOHN MUELLER You don't want to pre-announce what you have planned?


GARY ILLYES-SELLS-SANTOS Exactly.


JOHN MUELLER Okay.


We're waiting for the Gary update.


GARY ILLYES-SELLS-SANTOS You probably shouldn't have said that.


You definitely shouldn't have said that.


JOHN MUELLER So what was your kind of favorite thing with


all of the changes this year, Gary?


GARY ILLYES-SELLS-SANTOS Nothing.


JOHN MUELLER Nothing?


Come on, there must be something.


What about this podcast?


Is this any good?


GARY ILLYES-SELLS-SANTOS Okay.


So podcasts I actually like.


I really like that you have more flexibility than with videos, for example.


I really don't want to get into setting up lighting and focus and high-end camera for


recording stuff.


And it will not be most likely the quality that you can achieve in a studio, for example.


So I just don't see the point of that.


But with podcasts, you actually don't have to worry about that because you have a high-end


microphone.


You have a properly soundproofed, let's say, room, and then you can just hit record and


do the podcast.


And no one will see your face.


GARY Tears.


GARY What'd you say, Martin?


Again?


MARTIN Nothing.


GARY Are you being mean to me again?


MARTIN Me?


Never.


GARY Was that sarcasm?


MARTIN No, I'm not even able to do sarcasm.


MARTIN No.


Anyway, so yeah, podcasts I actually like doing, and I hope I will do more in the future.


Actually, I'm recording one today, but I will not tell you which one.


Oh, a second.


GARY This one, right?


MARTIN I'm recording two today, including this one.


But I'm not telling you which one.


And I recorded a few throughout the year as well.


Plus, we have this podcast, which I actually kind of like doing.


It's fine, I guess.


GARY Fine.


MARTIN Yeah, I mean, it's okay, right?


GARY How dare you.


MARTIN I mean, we have Martin sometimes, but otherwise, it's fine.


GARY It's fine with all of the people joining.


I really like it.


It's lots of fun.


MARTIN No, no, he's got a point.


Terrible when I'm involved.


GARY No.


MARTIN Wow.


Okay, finally.


And I really hope that we are going to continue with this and we release more and more of


these podcasts and that we will have more guests on the podcast because that always


spices things up a little, at least, and brings in different perspectives.


So yeah, podcasts are really cool.


And we have good feedback for this podcast, I think.


I know that Anna, our producer, is always on Twitter and watching for comments about


the podcast.


And for example, one of the early feedbacks was that we don't have a transcript.


And then Anna made that happen.


And now we have transcripts.


Another funny feedback was that we were hosting the podcast from an HTTP URL.


And that caused a mini meltdown on Twitter.


And awesome.


Yeah, it was awesome.


It was quite fascinating to watch people comment on that.


JOHN But you were one of the people who were promoting


HTTPS as kind of an important thing back in the days, right?


MARTIN Sure.


I mean, it was still funny.


Or it was funny exactly because of that.


I don't know.


It was just fun to watch it.


And then after, I don't even know, weeks, actually, Anna made that happen.


And now we are hosting it from HTTPS.


Another piece of feedback was, why are we not hosting it on YouTube as well?


And then Anna made that happen too.


So yeah, Anna is like our own Santa Claus, essentially.


She just makes things happen.


JOHN So are we hosting on HTTP or HTTPS on YouTube?


MARTIN Yes.


JOHN OK.


I guess that's one way to answer.


MARTIN I mean, YouTube cannot do HTTP, right?


JOHN I don't know.


You made me almost consider trying it out.


But I'll save that for after the recording.


MARTIN I'm fairly certain it has HTML.


So even if you wanted to do it, like force it HTTP, you wouldn't be able to, I think.


Cool.


Yeah, I really enjoyed doing the podcast.


It's been lots of fun.


And I think we've learned a lot over the time that we've been recording them, including


that I should find some soundproofing for my room, which Gary is only now hinting at


that you can actually get this, which is mind blown, which is fantastic.


Another one of the things I really enjoyed this year was working together with a really


global team, working together.


I mean, there are some people here in Zurich, which is, I guess, less global.


But we have someone in Singapore, in California, in Israel.


It's really cool to see people from all different locations kind of come together and work on


one kind of common goal, all around search relations work.


That's been really fun, even though it would be much more fun to actually meet in person.


But whatever, we will get back to that at some point.


The other really cool thing I liked this year was the shift of all of our content to that


one new location that you helped work on there, Gary.


I think that's something that has come up as feedback over the years already.


It's like, where should I go to understand more about search?


And it was like, oh, you can go to all of these five or six different places.


And if you want, maybe you can try some more different places.


And now we've kind of compiled, condensed some of that together, which is pretty cool.


The other neat thing that I thought, like looking back, was kind of the shift to more


virtual events away from the physical events.


I mean, obviously, you can't do physical events, at least where we are at the moment.


So you have to do virtual events.


But it's also something where I've always thought it would be nice to have a little


bit of a virtual component to some of the events so that you don't have to travel all


the time.


But at the same time, I also thought that was like one of the terrible effects of this


year.


It's like, you can't meet people in person anymore.


So annoying.


Oh, well, you have to make do with how it comes and try to make the best of it.


So since this is our last episode for this year, do you guys have any plans for the break?


What break?


Like the holiday break, you know?


It's like after Christmas and before New Year, at least in the way we have the calendar here.


Well, usually I go to some warm place like Indonesia or Zanzibar and I dive there.


But maybe this year that's not going to happen, which means that I will have not dived this


year at all, which sucks.


Why don't you come dive with me?


Because you dive in Fervasdeterse or in Tugersi or whatever, and they are cold and miserable.


And why would I want that for myself?


Lots of fishies.


Fishies!


But didn't you go diving in a frozen lake before?


That must be even colder.


That's different.


There you hike up to 3,000 meters or 9,000 feet and then you dive with glaciers.


Usually it's a one-time thing off the bucket list and be done with it.


So it has to be like, oh, it's like a one-time thing or it has to be extra cold.


It's like just a little cold is not OK.


OK, that was a special event.


Basically we got an agreement with someone I will not name because I don't want to get


off the record on the record.


But we managed to get a helicopter and then we put all our gear and ourselves on the helicopter


and then we geared up in the helicopter and then we jumped in the lake from the helicopter


because helicopters are not allowed to land in the Alps unless they find the helipad.


And then that whole idea made the experience worthwhile.


But basically for me, putting up, I don't know, like almost 100 kilos worth of gear


just to go to dive in a lake where you barely see anything because it's so murky.


Like why?


Why would you do that?


MARTIN SPLITTENBERG You're such a diva.


JOHN MUELLER I think the obvious solution, Martin, is to


pick up Gary with your helicopter and then take him to the Lake Zurich.


MARTIN SPLITTENBERG I guess.


I guess I can do that.


I just need the helicopter first.


But I mean, that's easy.


MARTIN SPLITTENBERG John, can I expense that?


I think we should kind of move away from the diving track.


MARTIN SPLITTENBERG OK, so John, what will you be doing on the


holiday break?


JOHN MUELLER What will I be doing on the holiday break?


I don't know.


I think it depends a little bit on how the numbers are here.


So especially around coronavirus, how bad things are.


As we're recording it, it's like, who knows?


Things go up, things go down, everything stays weird.


If it's kind of OK, maybe we'll go, I don't know, in Switzerland to someplace in the mountains.


Maybe we can go skiing.


Who knows?


We'll see.


If not, I don't know.


No big plans.


I've been messing around with a lot of electronics recently, so maybe I'll just tinker on some


weird electronic circuits so that I have a big mute button or something weird, which


is super useful nowadays.


And of course, of course, I will be active in the Webmaster Help Forum or in the Search


Help Forums, which I conveniently forgot the name of, but I still like to call it the Webmaster


Help Forum.


I don't know.


It's just been tradition that I've posted there on some of the holiday days to kind


of help some of the folks out there that are posting there and asking questions in the


forum as well.


So I plan to do that again.


I think that's always fun.


MARTIN SPLITT


Thanks so much.


I think the one thing that we already announced


is the Core Web Vitals as a ranking factor,


together with a bunch of other factors in the page experience.


I think we call it page experience ranking factor.


And with the Core Web Vitals as a part of that,


I think we'll definitely be doing more around speed, user


experience, those kind of things to help folks to really get


their websites up to speed.


Ha ha.


So sorry.


Not sorry.


Definitely not sorry.


We're definitely still working on Search Console.


It feels like there are always a bunch of features


that people really, really want us to do.


When I look around on Twitter, we


have a bunch of things lined up for launching that we're


working on with the team.


These launches usually take a bit of time.


So it's a long time between when we get the feedback


and when it actually launches sometimes.


But I'm sure you'll see more things happening there.


But I can't go into the details there,


because like I said, we don't tend to pre-announce things.


On the podcast, I think we'll continue


doing more of these podcast episodes.


They're always fun.


And hopefully, they're a little bit more insightful,


depending on the episode.


This one is a bit more nostalgic almost, looking back a bit.


And with the podcast, I hope we'll have more guests as well,


because that's always pretty cool.


Kind of brings in some new perspectives.


And maybe there are always some other parts of Google


that folks haven't been aware of that explicitly.


So that'll be cool.


MARTIN SPLITTENBERG awesome.


Speaking of guests, I also am planning a new video series


next year called SEOs and Devs.


And I have confirmed the first couple of really nice guests.


I'm really looking forward to that one as well.


I'm guessing we are recording other videos as well, huh?


JOHN MUELLER Yeah.


So you said SEOs and developers?


MARTIN SPLITTENBERG Developers.


JOHN MUELLER Developers.


Oh, OK.


Whew.


Are you mucking my accent?


No, never, never.


Cool.


Yeah, I think we'll have a lot more video content


over the course of the year.


Because it's like, if you can't do things in person,


at least you can do some video stuff sometimes.


It's not really a replacement, but it is what it is.


We do what we can.


We do what we can, definitely.


All right, so we've been having fun with these podcast


episodes.


At least I have.


I hope you, the listener, have found them both entertaining


and insightful, too.


And regardless, let us know how you're liking these


and if they're topics that we could be including


in one of the future episodes.


And given that this is the last episode of the year,


I hope you've been having a reasonably great year,


despite everything.


And we're wishing you all a nice and quiet break.


MARTIN SPLITTENBERG Or not quiet, whatever you prefer.


Yeah, or not quiet.


Have a really loud break, if you prefer.


All right, bye everyone.


Happy holidays.


Bonne eva cancet.


Oh, what fun it is to ride in a one-horse open sleigh.


Structured data for web developers | Search Central Lightning Talks

Confused about what structured data is and whether it's worth using on your web pages?


I'm Ryan Levering, a software engineer at Google who works on connecting teams in Google


that need data for search features with data providers on the web.


In this session, I'll discuss what structured data is,


how it's useful for both Google and you,


how to get started using it,


and some best practices if you already do.


The biggest source of data that Google consumes is the web itself.


The web is a very loosely structured collection of documents.


For a lot of our more modern, richer features, we need that data to be more structured.


This enables us to provide visual treatments such as product review stars


or filters for how long it takes to prepare an apple pie.


While we have technology to find that structure in web page text automatically,


those systems are not perfect.


That's where you come in.


When you tell us what's on your web page in a structured way,


we can more accurately interpret the contents.


This means we can create visual treatments


and show the web page in the correct context for searchers.


That in turn can bring more qualified traffic to your website


because your site can be shown in new ways to more people on Google Search.


Looking for practical examples?


We have a number of case studies on our developer site


that showcase some practical gains the websites have seen


for implementing several different structured data types.


The most important thing you can do as a website owner


is to first make sure that Google can crawl your content.


If Google can't crawl your content,


then we can't find the structured data on your page.


Google primarily uses schema.org to describe the content on your page.


Schema.org is a public collaboration between a number of different organizations


to create a shared vocabulary to describe data.


It doesn't fully represent every bit of information in the world,


but it does have a lot of broad vocabulary for many different types of content.


As broad as schema.org is, Google is primarily interested


in certain subsets of the vocabulary that relate to features we build


that connect people to what they're looking for on Google Search.


While we never penalize you for having more accurate structured data on your pages,


it's the best use of your time to focus on the ones we actively use.


That's where our developer docs come in.


In our docs, we showcase all the major uses of structured data in Google Search.


You can use the search gallery to find structured data types


that may be a good fit to the type of content on your website.


There are some features that are very broad and apply to most websites,


like our breadcrumbs feature, and some that are targeted at a certain type of website.


For example, if you are an e-commerce website,


you may be interested in the product or review features.


And actually for e-commerce in particular,


we have a guide of some ways to use structured data types in the link you see.


Once you have some idea of what types of structured data you are interested in,


how you implement it depends on how you manage your website.


If you use a content management system, WordPress or Squarespace for example,


your best bet is to find a plugin that exposes structured data automatically


for the content you already have on the web pages.


For instance, if you have an event calendar on your website,


make sure that the plugin has the capability to produce event structured data


and you have it configured correctly for the documentation.


If you have direct control over the HTML of your website,


there are a couple of different syntaxes that let you express


the schema.org structured data in the HTML.


There are good reasons to use each syntax,


but usually our recommended approach is to use JSON-LD because it's the simplest.


JSON-LD is a separate blocks of JSON-like syntax that you put on the web page


in a script tag alongside the visual content.


A recommended approach would be to add it to several pages manually on your website


and test them with a rich results test in Search Console


to see whether we are interpreting the structured data correctly.


Rich results test will list the structured data items that Google uses


for specific features on a given code snippet or URL


and for each item show its status and any issues.


After you figure out the right way to produce the markup,


you can implement it more broadly in any database templating language you use.


Once you have the structured data implemented on your website


through either approach, you will begin to get reports from Search Console


on the validity of that structured data for use in our features over time.


We will also notify you if there are issues with markup


so that you can continue getting rich results.


These reports and notifications are only possible


if you are signed up with Search Console for your website.


If you want more information on how to do that,


check out Search Console training in the video description links.


Note that any issues just affect the use of that structured data in our features.


Having issues will not negatively affect other aspects of your page in our search index


and the data might still be valid for consumption by other search engines.


Speaking of impact, after you implement the structured data,


you can then use Search Console tools


to verify the impact of the structured data on Google features.


Many of our structured data types offer search appearance reports


on this impression and interaction rate with corresponding search features.


Now let's take a look at several best practices


to keep in mind when adding structured data to your website.


Keep the structured data relevant.


Using structured data that has nothing to do with the contents of the page


is considered abuse and can result in penalties.


But even beyond that, try to focus on describing the core meaning of the page.


For instance, if you have a product page selling a particular product


and you list all the related products in the markup


without differentiating the main product on the page,


that will make it all the harder for us to use that information.


Try to use unique identifiers.


Some of our features recommend or require some sort of unique identifier explicitly.


But in general, giving us a stronger identity signal


helps us disambiguate the names of things in your data


so it shows up for the right queries.


For example, giving the street address for an event location


rather than just the city,


or using an ISBN when describing a book,


or adding a social profile link for an author of an article.


Look for conflicting or redundant structured data.


A very common problem we see is multiple CMS plugins


or separately authored JSON-LD blocks


generating the same data with slightly different information.


This can sometimes appear like several different things on the page,


which can potentially exclude the page from having a visual feature.


Examine Search Console reports to look for these problems.


Structured data can be a valuable resource for your website.


Using it correctly can potentially lead to more


and higher quality visitors coming to your website.


We continue to add more features and recommendations over time


to find new ways to connect searchers with content on the web


and increase our structured understanding of the page.


The information from this video is also available in our developer documentation.


Which has more details on all these topics,


plus detailed guides for the different types of structured data that we recommend.


Thanks for watching this lightning talk.


Feel free to leave comments with the video,


and if you have specific questions,


JavaScript SEO office hours December 23rd, 2020

Hello, and welcome to the pre-Christmas JavaScript SEO


office hours.


My name is Martin Splitt.


I am in the Search Relations team at Google,


and I am really happy to answer any questions about JavaScript


and, well, Google Search.


Today, we have a few questions submitted through YouTube.


We have a few people in the audience live today as well.


We do these roughly fortnightly, so every 14 days, roughly,


I am doing these sessions.


There is a thread in our YouTube channels community section


where you can ask your questions.


Or if you want to join the live recording,


I'm commenting with a YouTube link in there


so that you can ask another YouTube link, the Hangout link


in there, so that you can join the live recording if you wish.


Right, so there are a few questions, very few questions


on JavaScript, actually, but a few questions that


touch roughly on JavaScript.


So I'll happily have a look at those.


Gregory Scott asks, from my understanding,


the speed ranking factor for WebCore vitals,


Core Web Vitals, but roughly, right,


would be based entirely on field data and not lab data.


Is this correct?


Yes.


At the time of this recording, that is absolutely correct.


What that means, if I'm not wrong,


is that the guidance from the lab tests,


like Lighthouse, web.dev, PageSpeed Insights,


may deliver results that are inflated scores,


or deflated, actually.


It might give you very different scores.


That is correct.


Which are pointless.


Ah, I disagree.


They are not pointless.


They are indicative.


So they are not necessarily the accurate values


that you would see in field data,


but they give you a hint on where might be issues.


It does not cover everything, obviously,


while lab data might show everything is fine.


Field data might show, actually, things are not very fine.


That's why it's important to also measure in field data.


But lab data usually is a good cannery in the coal mine.


It gives you a feeling for where you are


and where potential problems lie.


So they are not pointless, but they are not the truth.


It's really, really hard to say what is the truth when


it comes to website performance, because it really


depends on lots of factors.


Then there is a, he gives an example on WordPress,


where changing plugins gave the options


to remove the version string from the files which


inflated performance scores and was practically


useless for field data.


Then you know that that's not useful.


That's gaming the metrics, in that case.


So the main question, does this mean that delay JS function


in some of the more popular caching plugins for WordPress


lately is just that, a trick for the lab data scores that


won't have any practical meaning for the field data.


Measure.


That's not generally, like, delaying JavaScript


to a later point might be useful.


It might not.


You have to measure if that's a problem for people


on your website or not.


I would not trust the lab data 100%.


Again, the lab data gives you a rough guidance.


It gives you a tracer bullet to figure out


where problems might be and debug these problems


relatively interactively, which you really


can't do with field data.


So it has its purpose.


But obviously, there are things that can gain the metrics.


But that's a little pointless, because if the users are still


experiencing the website, that's going to reflect in field data.


So be a little careful with that.


But if your measurements show that the field data does not


benefit from that function, then that's


probably an indicator for that being a metric gaming


rather than an actual improvement for users.


Tobias Merz is asking, hi there.


We have a problem with our commutative layout shift.


We implemented a sticky nav without position sticky,


since it's not supported in all browsers.


Our solution is more like Bootstrap affix.


I don't know what that is.


But I know Bootstrap, but I have no idea what affix is.


So we listen to the scroll event and set the position fix top


0 when the navs leaves the top.


To prevent a jump or layout shift,


we have a wrapper around the menu with explicit height.


Therefore, the wrapper still has the same height even


the nav gets position fixed.


So there is no layout shift.


Everything seems to work fine.


It looks good for the user, but the CLS is coming up every time


and a lot.


Why is that?


So without having a look at the specific example,


that's really hard to say.


I could imagine figuring out a way


to take nav out of the nav flow, like position absolute.


But I was thinking position fixed does that as well.


But I would definitely consider asking on either the JavaScript


sites mailing list, so bit.ly slash js dash sites dash wg


with an example URL to look at, or maybe the Webmaster Forum,


or feel free to go to Stack Overflow as well


with these kind of questions.


And again, provide a clear example.


And you can build a fake example that just shows the behavior.


Because without something to actually investigate or look


at, it's really, really hard to give an answer


to that question.


And there's one more question from Gary Scott


around the Core Web Vitals.


Hold on.


I answered that one.


Oh, right.


It sounds like it's the same question,


but it's not the same question.


It starts with the same introduction,


but then it's like, does it make sense


for an informational site to block all countries out there


except the few bigger ones in order


to get the best average field score for that speed?


I know I can do that.


The question is, if I have, for example, low return


on investment from countries with slow internet


connection with a large population,


does it make sense to cut them from accessing my website


since they have a slow connection that hurts my field


scores?


No.


That's thinking that is laser focused on the Core Web Vitals,


and that's really, really, really risky.


A, because people from these countries,


if they want to access your website,


they will through a proxy or what's


called a VPN, which really is mostly a proxy for most cases.


And then the speed is even slower, so not helping.


The other thing is Core Web Vitals and page experience


is one ranking factor out of hundreds of ranking factors.


So you should not overestimate the power


of this ranking factor.


It is important.


It is not the most important.


And I think if you have useful information


and you can get this information to people and get some ROI,


you should probably do that.


Because again, there's hundreds of ranking factors.


Speed is not the only thing.


Because if speed would be the only thing,


then a blank website would rank really well


because it's really, really fast.


That's not the point.


Fast is an important quality signal,


but there are other quality signals that really,


really matter too.


So I would not do that.


Also, that implies a more complex setup, which usually


invites more problems.


I would not do that.


I don't think that's a reasonable thing to do here.


And then we have a third question from Gregory.


I don't know if you know this, but WordPress


decided to reinvent itself with a new editor called Gutenberg.


Yes, I know that.


They're using web components in there.


With the installation of the plugin,


you can get more current features


that they think don't demand.


It's basically turning the whole page into blocks.


I'm not sure if these blocks are only


happening when you edit the page or if that's also


in the output of the pages.


I would have to look into that as well.


Since one page of 2K words and images


could actually be something to 20 or 30 blocks or more,


as each new paragraph is considered a new block,


what I noticed on the last changelog


is that they would consider splitting styles so that each


block has its own style CSS.


This means that loading one page could result in having


30 or more style CSS files.


I would assume that they don't do that when


they deliver the actual page.


But maybe I'm wrong.


That's a question for the Gutenberg team.


I would ask them.


I would ask them and check what they think,


because I'm pretty sure they're not doing something


for the sake of just doing it.


I'm pretty sure they have some reason behind it.


And I think performance is on their radar.


So the way you describe it sounds like a performance issue


or potential performance issue.


I'm pretty sure they don't do that just for the fun of it.


Ask them.


Everything is on GitHub.


You can ask on the Gutenberg repository


why they are doing that and if they are


or what's offsetting the performance hit from that.


And I'm pretty sure they have something to say to this.


Then we have a question on, hi there, John Miller.


Not quite.


Close enough, though.


Martin here.


Hi.


Hi, Rafael.


I'm from Brazil, so when I run and test


PageSpeed Insights laboratory data generated regarding


my website, it's made for Brazilian users,


but it's hosted in the US with a server and with a CDN.


Is the data from the Brazilian server or on the US server?


I think it matters.


But what matters really is the field data.


Yeah, the field data is actually what matters.


PageSpeed Insights probably generates it from a US server.


If your server is hosted in the US


and PageSpeed is hosted in the US,


then they likely have a better connection


than users coming from Brazil.


Even though Brazil and US shouldn't


be too bad, if the server would be in Australia,


I would be more worried than that.


But yes, the field data is what you should really consider.


Again, the lab data gives you a rough traceable


look for where problems might be, but it might not


show all the problems because, again, the disparity


between the two, field data and lab data.


And then that's it from the no, there's


one more YouTube question from Mustafa, who is also in the call.


I know that.


Regarding Crawl Stats report, what


should I do about a huge drop on the Crawl Stats report?


From 300k requests to 50 to 70k requests,


I check the performance on the searches on clicks


and the sessions on GA both look normal.


Then my answer is that doesn't seem to be a problem.


The amount of crawling that happens


is no indication for quality or ranking or whatever.


The crawling we do is based on lots of things.


And as long as your Crawl Stats report doesn't show anything


scary, as in your server is actually


generating lots of errors or your server


is really slow in responding, as long as that's not the case,


you should be fine.


And thankfully, you gave us a sample URL.


So I can actually take a look.


And I shall do that here.


And as far as I can tell from the coverage,


nothing really has changed.


So it's not that we are not seeing something or that,


like, as you say, the performance hasn't dropped.


So that's not a problem, really.


As far as I can tell, the crawl is going up again


with 200 crawl requests recently, Sunday.


So that's three days ago.


I do see a drop from 300k to 41k-ish.


But that itself is not a problem.


It's just meaning we crawl less, but that


has no meaning on anything.


We don't think it's less quality.


We just decided, oh, most of the pages probably haven't updated.


We don't need to crawl as much.


We only need to crawl a few 10,000 pages, like 40,000,


And now we are probably seeing that we need to adjust again.


So we are upping the crawl budget to 200k.


Maybe it goes further up.


Maybe it goes further down.


It doesn't really matter.


As long as you're not seeing any issues in the performance


or in the coverage, I wouldn't be worried about that.


Also, the increase in crawling could also


come from the fact that we, I think,


we switched the site to mobile-first indexing recently.


So it might be that we are recrawling with Google's


smartphone now.


So that is why the crawling goes up.


And then it will probably go back down again.


If we establish that we don't need to do as much crawling,


that's just it.


Again, as long as the performance is fine,


as long as the coverage is fine, there's


nothing to worry about.


Right.


And with that, we are through with the YouTube questions.


And very happy to take audience questions now.


Now it's your turn, everybody.


Pavel.


AUDIENCE Hi, everybody.


I've got a question.


I hope not a silly one.


So we've got this server-side rendering.


It's a web-side built with Gatsby and React.


And what I noticed is that a web-side was really fast.


For a user, it's a very fast, I mean, the user experience.


From the point of user experience,


it's a really fast web-side.


But when I look into Google tools like Lighthouse,


I just noticed that the site got much slower in Lighthouse


after installing Tag Manager.


And I know that Tag Manager code is performed asynchronously.


Sorry for the English.


Yeah.


Always.


So I just wonder, where does it come from?


I just feel that it's related somehow.


But I can't figure out what's the reason.


And I'm just looking for some kind of explanation, I think.


MARTIN SPLITTENBERG So as I said, the lab data


and the field data are not necessarily the same.


If you have Chrome UX report available for the site,


if it has enough data points in there that it shows,


then I would look into that.


And Search Console has it under the Core Web Vitals report.


So if those look fine, then I wouldn't worry too much.


For Lighthouse and WebPagetest and all of the others,


like PageSpeed Insights, I know that they have a really hard


task, which is to generate a score from a lot


of different metrics.


Now, these metrics are not all what is in Core Web Vitals.


There's more metrics than there are in Core Web Vitals.


Core Web Vails are just a part of what these tools report on.


And to generate a score, they have


to mix these metrics somehow.


The mix, at least for Lighthouse,


the mix is documented somewhere in their documentation.


And you can find out how they weigh the different metrics


to generate the score in the end.


And depending on how that score is generated,


you might see interesting fluctuations.


And if Google Tag Manager does something


that is relatively heavy but does it in the background,


that might not actually affect what users perceive or notice.


And that's great.


But it might affect one of the metrics


that these tools are looking into.


Whatever that metric is, it could


be like total blocking time.


It could be time to dump content loaded.


It could be various different things.


It could be the parse time.


It could be that the Tag Manager detects these tools


and then loads slower or something.


And then that mixes into the scores.


And then that's why we get a lower score.


As long as the real user metrics look good,


you shouldn't be worried too much about that.


Again, the lab data testing tools, Lighthouse,


PageSpeed Insights, WebPagetest, they


give you an indication on where to look.


But then you still have to interpret these metrics.


A Lighthouse score of 100 doesn't mean anything


unless you actually understand that the metrics that you care


for are really looking fine.


A Lighthouse score of 50 might mean something,


might mean, oh, we should look into this,


but might also just be like, oh, yeah, this


is measuring things that we don't really that much worry


or care about.


So that's not a big problem.


Luckily, web.dev has lots of information


on how these metrics work and what they mean so that you


can make a more educated guess on what you should do about


the scores you are seeing.


But when you see these discrepancies,


and I've heard a few offenders like Google Ads,


apparently, is a thing where that can happen.


Google Tag Manager is a thing where that can happen.


Certain YouTube embeds have this issue.


So even Google properties are not excluded from that,


because the testing tools don't care where requests are made


to or coming from.


So you might see differing values between the real user


metrics and the field data.


If you have real user metrics available,


that's what I would look into.


Field data, sorry, lab data is interesting to just debug


things and get a feeling for where you are going.


But I wouldn't worry too much about it


if there is an issue with just the lab data values.


Thank you.


I think it's clear.


Yeah, and this is what you said.


I noticed that the tool shows me some information


about total blocking time.


That might be one of factors.


Generally speaking, if I understand correctly,


so the important thing is how really user


experience the website.


Yes, that is correct.


OK, thank you.


You're welcome.


And this seems to be the theme of today,


because most questions are circling around that.


As a general note, I want to say that measuring user experience


in terms of responsiveness of the site and speed of the site


is ridiculously complicated and has lots of caveats that are


really, really hard to quantify.


And the goal really is to have something


that is a very human interaction,


as in how quickly does the site respond,


how quickly does it show the content of all of these things,


how much of my CPU does it spin, how much of my battery


does it consume.


We try to put all of this into a number,


and that's always a hit and miss.


Oftentimes, it works.


In some edge cases, it doesn't.


In some edge cases, you get reports that don't make sense.


And then someone asked the question,


Tobias asked the question with the CLS, where they're like,


we don't think that that's the case.


I would try to report.


If you see CLS values being very high in Lighthouse,


for instance, I would report that to the Lighthouse team


with a sample URL so that they can take a look at it,


because maybe it's just a glitch in the way


that CLS is calculated.


That is absolutely possible, because it is surprisingly


hard to get these values accurately


and also to find metrics that are.


That's the whole reason with the Core Web Vitals.


It's not like, ooh, we wanted to make something up


so that we are busy.


No.


It has been that we had lots of metrics,


and the web has changed, and the way


that users interact with the web has changed,


and the metrics did no longer fit how people were actually


experiencing the web.


So we had to come up with new metrics that


happened relatively randomly, which pissed off people,


understandably, if you are optimizing for the metrics


that you are given.


And then the metrics changed, and now your optimization work


looks like nothing has happened or actually


has made things worse.


And you're like, what the hell?


So the Core Web Vitals give you a more structured


and time-slotted way, because we are considering updating them


once a year, roughly, and not in random times


throughout the year.


So it gives you a more predictable set of goals


to look into, even though we understand,


and hopefully you understand, these Core Web Vitals aren't


perfect either, because there will


be websites that are really fast for users


but don't look great in Core Web Vitals.


That's why these metrics keep evolving and keep improving.


But getting a perfect score for what people


are experiencing on websites is really, really hard.


All right.


Any further audience questions?


And again, you can use the chat or you can use the microphone.


And you can use the Raise Hands feature.


Dave.


So we're on a bit of a performance bend today.


Is there a massive benefit on streaming response,


particularly something like an SSR,


suicide rendered something, maybe hydrate later,


tends to compile it all, bung it all across?


I can see there's a few frameworks


now trying to push towards streaming


that initial response.


It looks hugely complex in certain parts,


and it seems to have some drawbacks.


But is it really worth something pushing towards,


or do you think it's kind of a case-by-case basis,


or there's no real rule?


I think it's probably on a case-to-case basis.


But generally speaking, it does make sense,


if you think about it.


With server-side rendering, the big challenges,


the real server-side rendering, not like static pre-rendering


or whatever, the request comes in, a program runs,


generates the DOM, or generates the HTML,


and then sends the HTML over the wire in one big block.


So basically what happens is the request comes in,


and from the browser's perspective,


nothing happens for a while.


And then it all comes over.


If we could shorten the amount of nothing


happens for a while from the browser's perspective,


I think that would be good, because then you could start,


or the browser can start to build the DOM


as the data arrives, which has been the case


with static websites.


You have a file on disk.


You have the browser requesting it.


And basically, immediately as the file is opened,


the data is streamed over the network


so it arrives bit by bit in the browser.


Nothing happens for a long while,


and then the entire thing starts streaming in.


But that being said, you already hinted


at this streaming a HTML response that is generated


by any kind of program.


And I'm not even saying JavaScript specifically.


This could be a Java program.


This could be a PHP or Perl program.


Doesn't matter, Python.


C++, if you really want to have the pain of that.


Having that stream the data as it generates it


is probably a lot of complexity.


That usually means where there is complexity,


there are bugs and edge cases that are surprisingly


hard to cover.


So I would not be surprised if that is not worthwhile,


especially if the time that the program runs


is in the subseconds.


If your PHP script or your HTML script or Node.js script


takes 0.5 seconds, then I don't think it's worth the hassle.


If it does run for 10, definitely worthwhile.


Definitely worthwhile sending the data.


And 10 is just like a very extreme number


to just make sure that we are talking very extreme numbers


here.


But the reality is somewhere in the middle,


like subsecond and then everything


that is longer than a second, you can probably see benefits.


Everything that is longer than two seconds,


you very likely see benefits.


But again, then what's the complexity


that you invite into your code?


Is it worth it?


Can we make it so simple that it doesn't generate so much


overhead that, A, the program runs slower,


and B, problems happen that we then need to mitigate


with even more code?


I think that's an interesting venue to explore.


I haven't seen as much exploration in the wild yet.


But I think it's an interesting thing


to try out and see if you can actually gain significantly.


I remember I did that with WebGL.


I was exploring if a certain WebGL format, so basically


like JPEG for 3D graphics GLTF, if that could be streamed


and what you would gain from it.


And the gains we saw were huge.


But the complexity we saw in creating these models in a way


that they would be streamable was so big


that even the huge gains we made,


and we were talking gains of like 20 to 30 seconds on a 3G


connection.


But it would take tens of hours of a 3D artist


with specific tools that are really, really expensive


to actually generate these models.


So we decided it's not worthwhile.


And we might as well run into the situation


like this with streaming for a server-side rendering


framework.


But I think it's worthwhile to try it out.


We should probably try it out as a community.


So I should try it out.


Thanks for the question.


You're welcome.


Oh, to be honest, yes, you can simply


open an issue on github.com slash


googlechrome slash lighthouse.


I think that's their GitHub repository anyway.


And they have an issues tracker.


And if you say like, Lighthouse reports CLS here,


and we don't understand why, then is it Lighthouse?


No, it's not.


Rendertron.


Rendertron is a completely different thing.


Lighthouse.


You can search the issues here.


So either add to an issue that exists,


or you can add a new issue there.


Report it, and you'll get an answer.


Even if the answer is no, that's working as intended.


And that gives you a hint on that it's not the tooling.


That's something that you are not seeing there.


But I would not be surprised if there is a glitch.


All right.


Further questions?


It's funny, because the recording will be sent


in two things.


Like, I'll get a video, and I'll get a text file with it.


Always funny when that happens.


We do not have further audience questions.


I would like to say thank you very, very much to everyone


who submitted a question through YouTube.


Thanks for everyone who joined today.


I hope that you are all safe and healthy,


that you have a fantastic holiday time.


And enjoy and see you in the new year.


Thanks, Martin.


Merry Christmas, everyone.


Bye-bye.


Thanks.


Bye.


Thank you, Martin.


Structured data: What's it all about?

Welcome, everyone, to the next episode of Search Off the Record podcast.


Structured data: What's it all about?

Our plan is to talk a bit about what's happening at Google Search,


Structured data: What's it all about?

how things work behind the scenes, and maybe have some fun along the way.


Structured data: What's it all about?

My name is Lizzie Sassman, a tech writer on the search relations team


Structured data: What's it all about?

here at Google in Switzerland.


Structured data: What's it all about?

And today I'm joined by Martin Split, who is also on the search relations team.


Structured data: What's it all about?

And we're here to chat with Ryan Levering, a software engineer at Google,


Structured data: What's it all about?

about all things structured data.


Structured data: What's it all about?

So let's get into it.


Structured data: What's it all about?

So I wanted to talk to both of you.


Structured data: What's it all about?

Hi, by the way.


Structured data: What's it all about?

Did not give you an entry point to say hello.


Structured data: What's it all about?

But hello, how are you doing?


Structured data: What's it all about?

Pretty good.


Structured data: What's it all about?

How are you?


Structured data: What's it all about?

Good.


Structured data: What's it all about?

It's good to see you.


Structured data: What's it all about?

Are you as excited as I am for the structured data conversation?


Structured data: What's it all about?

I don't know.


Structured data: What's it all about?

Yes, probably.


Structured data: What's it all about?

How are we measuring excitement levels?


Structured data: What's it all about?

Is there structured data for it?


Structured data: What's it all about?

There might be a schema.org for it, yeah.


Structured data: What's it all about?

Is structured data a method of measurement?


Structured data: What's it all about?

But representation of the actual data, yeah.


Structured data: What's it all about?

Yeah, like the review, for instance.


Structured data: What's it all about?

Is it a way of measuring your experience with something?


Structured data: What's it all about?

Like, is it a good thing?


Structured data: What's it all about?

Is it a terrible thing?


Structured data: What's it all about?

So why not measure excitement or describe excitement?


Structured data: What's it all about?

Speaking of types of structured data, I


Structured data: What's it all about?

was wondering if you guys had a favorite type.


Structured data: What's it all about?

I absolutely do, actually.


Structured data: What's it all about?

So my favorite type is the article,


Structured data: What's it all about?

because it's what you need to make a web story.


Structured data: What's it all about?

And I like web stories.


Structured data: What's it all about?

It's a good thing that Gary is not here to hear you say that.


Structured data: What's it all about?

Ryan, do you have a favorite type?


Structured data: What's it all about?

Or is this like picking a favorite child?


Structured data: What's it all about?

What a great question.


Structured data: What's it all about?

Article is a very nice thing, because it's definitely a widely


Structured data: What's it all about?

used type, I would say.


Structured data: What's it all about?

But I would say if I had to pick my favorite type,


Structured data: What's it all about?

it would probably be events.


Structured data: What's it all about?

That was sort of one of the best ecosystems,


Structured data: What's it all about?

I think, where structured data really shined for Google.


Structured data: What's it all about?

Just the way the data is distributed on the web


Structured data: What's it all about?

and the problems that we've had consuming it


Structured data: What's it all about?

make events a really good structured data vertical,


Structured data: What's it all about?

particularly for search.


Structured data: What's it all about?

I think that events was actually my first documentation project


Structured data: What's it all about?

when I joined the Google search team.


Structured data: What's it all about?

And structured data was my first larger project


Structured data: What's it all about?

to work on a structure for the structured data docs.


Structured data: What's it all about?

I'm sorry.


Structured data: What's it all about?

They were all not using a consistent format.


Structured data: What's it all about?

And events was, I think, launching at the time.


Structured data: What's it all about?

So it was a new doc.


Structured data: What's it all about?

And I used that as a way to pilot out


Structured data: What's it all about?

how we would do the ordering of the information


Structured data: What's it all about?

in the structured data docs.


Structured data: What's it all about?

And that's actually how I first heard of structured data.


Structured data: What's it all about?

I did not know it was a thing before working on the docs,


Structured data: What's it all about?

which is sort of a good thing.


Structured data: What's it all about?

Often, as a tech writer, you're first to the scene


Structured data: What's it all about?

for a feature or something.


Structured data: What's it all about?

And you have the eyes as a beginner


Structured data: What's it all about?

to see something for the first time.


Structured data: What's it all about?

But I was wondering what your first introduction


Structured data: What's it all about?

to structured data was.


Structured data: What's it all about?

For me, it was actually microformats.


Structured data: What's it all about?

I don't know if you guys remember Google Now,


Structured data: What's it all about?

this wonderful thing that basically Google Assistant


Structured data: What's it all about?

before it was Google Assistant, where


Structured data: What's it all about?

you could have emails that contain JSON-LD or microdata


Structured data: What's it all about?

with, for instance, event markup.


Structured data: What's it all about?

And then Google would prompt you, like, hey,


Structured data: What's it all about?

you have to leave now to get to this event that


Structured data: What's it all about?

is happening in an hour.


Structured data: What's it all about?

So that was my first touch point.


Structured data: What's it all about?

And Ryan, I think your touch point goes a little bit further


Structured data: What's it all about?

back in time, because you have told me


Structured data: What's it all about?

that you had a thesis paper.


Structured data: What's it all about?

Yeah.


Structured data: What's it all about?

So the thesis paper was not on structured data, per se.


Structured data: What's it all about?

It was on web page classification.


Structured data: What's it all about?

So machine learning and web pages


Structured data: What's it all about?

have been in my background for a while.


Structured data: What's it all about?

But I would say, structured data is a really funny term,


Structured data: What's it all about?

because we use it in strange ways at Google.


Structured data: What's it all about?

I mean, a database is structured data to some degree.


Structured data: What's it all about?

And I think that can be confusing.


Structured data: What's it all about?

Usually when we say structured data,


Structured data: What's it all about?

we are a little bit overlapping with markup as a term.


Structured data: What's it all about?

So structured data that's embedded on web pages


Structured data: What's it all about?

or structured data that's in some standardized form.


Structured data: What's it all about?

Yeah, HTML is structured data.


Structured data: What's it all about?

Yeah, HTML is also structured data.


Structured data: What's it all about?

Markup, too, or schema.


Structured data: What's it all about?

We're using, sometimes I hear structured data markup


Structured data: What's it all about?

or schema markup or all combinations of these words


Structured data: What's it all about?

to refer to this thing.


Structured data: What's it all about?

But they could also be things on themselves.


Structured data: What's it all about?

Anyway.


Structured data: What's it all about?

The terminology is a little bit strange.


Structured data: What's it all about?

But usually we mean it in terms of as comparison


Structured data: What's it all about?

to unstructured web data is usually where it's used.


Structured data: What's it all about?

So unstructured text or other things


Structured data: What's it all about?

that we're not indexing in the same way.


Structured data: What's it all about?

So structured data, usually you can do more interesting things


Structured data: What's it all about?

with it because the data has, you


Structured data: What's it all about?

don't have to worry about parsing it


Structured data: What's it all about?

and understanding its meaning because it's already


Structured data: What's it all about?

semantically there.


Structured data: What's it all about?

Right.


Structured data: What's it all about?

So the way that I think of it, and correct me


Structured data: What's it all about?

if that's right or wrong, I think


Structured data: What's it all about?

like the structured data in terms of markup,


Structured data: What's it all about?

like HTML and whatever is out there in the web,


Structured data: What's it all about?

that's like human readable.


Structured data: What's it all about?

And then we have a machine readable form as well.


Structured data: What's it all about?

And that's what I would classify as structured data,


Structured data: What's it all about?

like something that is addressing the machine,


Structured data: What's it all about?

like the search engine, for instance,


Structured data: What's it all about?

rather than the human going on a website.


Structured data: What's it all about?

Because we're not showing the JSON-LD to people, right?


Structured data: What's it all about?

Correct.


Structured data: What's it all about?

Yeah, that's a good way to think about it, I think.


Structured data: What's it all about?

So my introduction, when I started at Google,


Structured data: What's it all about?

we were working on extraction from web pages.


Structured data: What's it all about?

So like doing it via ML.


Structured data: What's it all about?

So we came in and the first thing I worked on


Structured data: What's it all about?

was the data highlighter product, which is externally.


Structured data: What's it all about?

So we were looking at web pages and pulling structured data


Structured data: What's it all about?

from unstructured text.


Structured data: What's it all about?

And my whole team was very into the actual ML aspects of it.


Structured data: What's it all about?

So how do we extract data, which in academics circles


Structured data: What's it all about?

is often called wrapper induction.


Structured data: What's it all about?

So when you take the, you build a wrapper that can pull


Structured data: What's it all about?

the data out of a template.


Structured data: What's it all about?

So reverse engineer the database.


Structured data: What's it all about?

But after several years of working on it,


Structured data: What's it all about?

there was another project that was sort of a side by side


Structured data: What's it all about?

that was extracting structured data, which became


Structured data: What's it all about?

like the core of what we use now.


Structured data: What's it all about?

And I became convinced after talking to people


Structured data: What's it all about?

for a long period of time that it was much easier


Structured data: What's it all about?

to just ask people to give us their data rather than


Structured data: What's it all about?

to pull it off of the web pages.


Structured data: What's it all about?

It's surprisingly more accurate.


Structured data: What's it all about?

There's other problems that can happen because of that,


Structured data: What's it all about?

but it's generally an easier thing to do.


Structured data: What's it all about?

And it's a lot less work for us and it's a lot better


Structured data: What's it all about?

for the provider.


Structured data: What's it all about?

So I came to it from ML and sort of seeing structured data


Structured data: What's it all about?

as the enemy at first.


Structured data: What's it all about?

And then I sort of was won over as a good mechanism.


Structured data: What's it all about?

Wow, structured data as the enemy.


Structured data: What's it all about?

I don't think I ever imagined that you would say that.


Structured data: What's it all about?

You were like the poster child of structured data.


Structured data: What's it all about?

Probably because I started on the opposite side.


Structured data: What's it all about?

So I became convinced.


Structured data: What's it all about?

I think that makes a more loyal follower.


Structured data: What's it all about?

So we've been talking about how machines use structured data


Structured data: What's it all about?

to understand the content of a web page,


Structured data: What's it all about?

which is oftentimes how we explain the concept


Structured data: What's it all about?

of structured data, like what it is and why


Structured data: What's it all about?

we would need to do this.


Structured data: What's it all about?

What do we mean by understanding?


Structured data: What's it all about?

And how much of it is machine learning versus this other


Structured data: What's it all about?

thing that you've been mentioning?


Structured data: What's it all about?

Like we were moving away from machine learning models


Structured data: What's it all about?

to providers telling us exactly what the data fields are.


Structured data: What's it all about?

It sounds like machine learning to me.


Structured data: What's it all about?

No, so machine learning, I see as sort of like multiple


Structured data: What's it all about?

prongs on our approach for how we get stuff.


Structured data: What's it all about?

So we wanna use machine learning for cases where


Structured data: What's it all about?

either we don't have more information,


Structured data: What's it all about?

where it's not provided for us,


Structured data: What's it all about?

but it's always gonna be easier to just have the data


Structured data: What's it all about?

shown to us, I think.


Structured data: What's it all about?

So we will try, I think it's like a multi-tiered approach


Structured data: What's it all about?

where you have like machine learning for cases


Structured data: What's it all about?

where we don't have that data specifically,


Structured data: What's it all about?

but then providers always have the option of giving us data,


Structured data: What's it all about?

which usually improves accuracy,


Structured data: What's it all about?

which usually gives better benefit for the actual provider.


Structured data: What's it all about?

So I always see them as sort of like working side by side


Structured data: What's it all about?

in an ideal world.


Structured data: What's it all about?

I see, so you still have, well, you don't have to do


Structured data: What's it all about?

anything, but if you want to give us more specific


Structured data: What's it all about?

information, then you would use structured data,


Structured data: What's it all about?

but we're also trying to do it for you,


Structured data: What's it all about?

so you don't have the time or bandwidth to add it


Structured data: What's it all about?

to your site?


Structured data: What's it all about?

Most of our features over time sort of migrate


Structured data: What's it all about?

to that approach where we ingest it.


Structured data: What's it all about?

Maybe we start with one approach where we're just using ML


Structured data: What's it all about?

and then we eventually add markups so people have control,


Structured data: What's it all about?

or it's the opposite way around.


Structured data: What's it all about?

And we start, like we bootstrap with markup


Structured data: What's it all about?

and an ecosystem approach where people are giving us data,


Structured data: What's it all about?

and then we enhance coverage of the feature


Structured data: What's it all about?

by adding ML long run.


Structured data: What's it all about?

So I see them as very compatible,


Structured data: What's it all about?

but it's always good to empower people


Structured data: What's it all about?

who are giving you data to have control over that.


Structured data: What's it all about?

So I think it's really important that structured data


Structured data: What's it all about?

in general is part of the overall strategy


Structured data: What's it all about?

so that people can actually have some control


Structured data: What's it all about?

over the content that we show.


Structured data: What's it all about?

Yeah, also speaking of control, I guess we can never probably


Structured data: What's it all about?

just use one of the tiers because I'm


Structured data: What's it all about?

guessing people will also try to exploit the ability to give us


Structured data: What's it all about?

data, to give us incorrect data, to boost


Structured data: What's it all about?

their sites in a non-valid way or to game the system.


Structured data: What's it all about?

So I guess that's also a challenge


Structured data: What's it all about?

that we are looking at, is it?


Structured data: What's it all about?

Or am I wrong and everyone plays nicely on the internet?


Structured data: What's it all about?

No, no, that's sort of what I alluded to before


Structured data: What's it all about?

as there being other challenges in structured data.


Structured data: What's it all about?

The primary challenge is that we then


Structured data: What's it all about?

have to sort of figure out a way to verify that the structured


Structured data: What's it all about?

data is accurate.


Structured data: What's it all about?

And sometimes this is from actual abuse,


Structured data: What's it all about?

and sometimes this is just because there's


Structured data: What's it all about?

a problem with synchronicity.


Structured data: What's it all about?

So sometimes people generate structured data


Structured data: What's it all about?

for their websites, and it becomes out


Structured data: What's it all about?

of sync with the actual stuff that's being shown visually.


Structured data: What's it all about?

We see a lot of both.


Structured data: What's it all about?

So there needs to be other mechanisms


Structured data: What's it all about?

to figure out some balancing act where


Structured data: What's it all about?

those things are enforced.


Structured data: What's it all about?

So that's the cost of structured data, I guess,


Structured data: What's it all about?

is that extra checking.


Structured data: What's it all about?

OK, so I'm bought in with the fact


Structured data: What's it all about?

that structured data is important to Google,


Structured data: What's it all about?

but there are so many types that are out there.


Structured data: What's it all about?

Google in the documentation, we've


Structured data: What's it all about?

got 25 different features or more in the search gallery.


Structured data: What's it all about?

And then there's also unlimited, almost it seems, on schema.org,


Structured data: What's it all about?

more properties for each of the features,


Structured data: What's it all about?

and then more things than we even talk about.


Structured data: What's it all about?

It seems overwhelming.


Structured data: What's it all about?

Would you have advice for someone


Structured data: What's it all about?

who's starting out with structured data,


Structured data: What's it all about?

I don't have anything on my site, what should I add?


Structured data: What's it all about?

What would be the first place to start,


Structured data: What's it all about?

or maybe the most impactful thing to add to my website?


Structured data: What's it all about?

So most of our features right now,


Structured data: What's it all about?

especially in the documentation, sort of


Structured data: What's it all about?

fall into a category of specific entity type or generic website


Structured data: What's it all about?

structured data.


Structured data: What's it all about?

So several of our features that you see there


Structured data: What's it all about?

are like breadcrumbs, site link search box.


Structured data: What's it all about?

Those are very generic, and they sort of


Structured data: What's it all about?

apply to most websites and web pages.


Structured data: What's it all about?

So checking out those in general,


Structured data: What's it all about?

and then seeing whether or not we


Structured data: What's it all about?

have documentation for a specific type


Structured data: What's it all about?

would probably be the next thing.


Structured data: What's it all about?

So definitely if you're an event site,


Structured data: What's it all about?

you should definitely be looking at the event structured data


Structured data: What's it all about?

page.


Structured data: What's it all about?

If you're a commercial based website, looking at that.


Structured data: What's it all about?

Our review snippets is very popular


Structured data: What's it all about?

with a bunch of different verticals.


Structured data: What's it all about?

So having the possibility of showing up in search


Structured data: What's it all about?

with star ratings are very popular.


Structured data: What's it all about?

So I would browse the documentation


Structured data: What's it all about?

and realize that some are generic features


Structured data: What's it all about?

and some are more specific features.


Structured data: What's it all about?

And what's kind of the difference between the Google


Structured data: What's it all about?

documentation and the schema.org documentation?


Structured data: What's it all about?

Because it does seem like there's overlap,


Structured data: What's it all about?

but also there's more on schema.org.


Structured data: What's it all about?

And why do we have both of them?


Structured data: What's it all about?

When would I look at the Google one versus the schema.org site?


Structured data: What's it all about?

Yeah, it's a very good question.


Structured data: What's it all about?

I think there's a lot of confusion


Structured data: What's it all about?

about the difference between the two things.


Structured data: What's it all about?

Schema.org is a collaboration between multiple companies


Structured data: What's it all about?

to create a common vocabulary.


Structured data: What's it all about?

That vocabulary is not by any means an API.


Structured data: What's it all about?

So it doesn't ever say that things


Structured data: What's it all about?

are required for a particular pipeline or vingestion.


Structured data: What's it all about?

So it's just a way of expressing information.


Structured data: What's it all about?

It doesn't even really express cardinalities.


Structured data: What's it all about?

So you could have multiple booleans


Structured data: What's it all about?

attached to a particular thing, which maybe doesn't even


Structured data: What's it all about?

make sense.


Structured data: What's it all about?

But there's no restriction on that


Structured data: What's it all about?

in the actual schema.org documentation.


Structured data: What's it all about?

So it's very expansive, and it has


Structured data: What's it all about?

to account for all of the different use cases that


Structured data: What's it all about?

could be used for it.


Structured data: What's it all about?

So is it sort of like looking at a dictionary?


Structured data: What's it all about?

These are these things.


Structured data: What's it all about?

They are here.


Structured data: What's it all about?

And the application of those things could be limitless.


Structured data: What's it all about?

Or other people can then use this to then say,


Structured data: What's it all about?

we need this type of information to do this thing.


Structured data: What's it all about?

Or that's the Google aspect, is that it's adding the,


Structured data: What's it all about?

this is what we can do with it if we know this information.


Structured data: What's it all about?

Yes.


Structured data: What's it all about?

So Google sort of imposes a set of restrictions


Structured data: What's it all about?

on top of schema.org to make the data more


Structured data: What's it all about?

usable for our purposes.


Structured data: What's it all about?

So we never want to say that the data is incorrect,


Structured data: What's it all about?

but it may not be viable for a particular feature.


Structured data: What's it all about?

And that's what most of our documentation and our reporting


Structured data: What's it all about?

is trying to convey, is that we can't use this structured data


Structured data: What's it all about?

for this feature.


Structured data: What's it all about?

It does not mean it is incorrect.


Structured data: What's it all about?

It does not mean that we will never find it useful


Structured data: What's it all about?

or that somebody else might find it useful.


Structured data: What's it all about?

It just means that for this given feature,


Structured data: What's it all about?

we can't use it.


Structured data: What's it all about?

Schema.org is very broad, and we're


Structured data: What's it all about?

more specific to the feature.


Structured data: What's it all about?

It's very interesting that you say we might not use it


Structured data: What's it all about?

or it might not be useful.


Structured data: What's it all about?

Because I think one of the things


Structured data: What's it all about?

that I found quite interesting is


Structured data: What's it all about?

that when I look at the Web Almanac Project from HTTP


Structured data: What's it all about?

Archive, that does a yearly crawl of home pages.


Structured data: What's it all about?

Now, home pages do usually have a bit of structured data


Structured data: What's it all about?

as well, but it's very specific.


Structured data: What's it all about?

For instance, the breadcrumbs, the navigation items.


Structured data: What's it all about?

But also, a lot of people add websites,


Structured data: What's it all about?

like the entity website, to their home pages.


Structured data: What's it all about?

And I'm always like, huh, what?


Structured data: What's it all about?

Like, hmm.


Structured data: What's it all about?

It's interesting that people do it.


Structured data: What's it all about?

It makes sense.


Structured data: What's it all about?

Because yes, of course, example.com, that is a website.


Structured data: What's it all about?

And adding the structured data never hurts.


Structured data: What's it all about?

But is structured data useful beyond what


Structured data: What's it all about?

we use for, say, certain search features,


Structured data: What's it all about?

such as rich results?


Structured data: What's it all about?

Yeah, the website is definitely used a lot.


Structured data: What's it all about?

I think SiteLink Search Box currently


Structured data: What's it all about?

uses a website to hang off of.


Structured data: What's it all about?

So there is one feature that actually uses that specifically


Structured data: What's it all about?

for the search actions.


Structured data: What's it all about?

So the answer is sort of a little bit vague.


Structured data: What's it all about?

We can potentially use that for some things at Google.


Structured data: What's it all about?

And I never advise people to not put structured data


Structured data: What's it all about?

on their web page if it makes semantic sense.


Structured data: What's it all about?

Because it also goes into our exploration


Structured data: What's it all about?

of what might be possible in the future.


Structured data: What's it all about?

So if everybody uses a particular data type


Structured data: What's it all about?

and we see it being popular, then that


Structured data: What's it all about?

might actually drive future development.


Structured data: What's it all about?

So one way that putting it on your website


Structured data: What's it all about?

is that it lets us know that there's


Structured data: What's it all about?

a bunch of this stuff out there.


Structured data: What's it all about?

And so we might start consuming it in the future.


Structured data: What's it all about?

So that's one way that it's useful.


Structured data: What's it all about?

We also have some things that we do to sort of generally


Structured data: What's it all about?

understand the topic of the page.


Structured data: What's it all about?

And sometimes, the data you put on that


Structured data: What's it all about?

can go into that.


Structured data: What's it all about?

Now, that's a very ML sort of process,


Structured data: What's it all about?

where we look at all of the text on the page,


Structured data: What's it all about?

and we look at other things that have to do with the page.


Structured data: What's it all about?

So structured data is just one signal


Structured data: What's it all about?

in that overall calculation.


Structured data: What's it all about?

But it can help us with certain disambiguations


Structured data: What's it all about?

in terms of what the actual page is about.


Structured data: What's it all about?

So it is useful, but just in a more implicit sense right now.


Structured data: What's it all about?

Not as obvious to people, since most of the features


Structured data: What's it all about?

that we talk about are very rich result driven, where we say,


Structured data: What's it all about?

if you give us this information, we


Structured data: What's it all about?

could show your site in this type of presentation.


Structured data: What's it all about?

But there are other things that are not necessarily something


Structured data: What's it all about?

that you could see visually.


Structured data: What's it all about?

But it could help us know that this is a recipe page, when


Structured data: What's it all about?

I didn't know based off of other information.


Structured data: What's it all about?

And it's sort of interesting that we still


Structured data: What's it all about?

need that kind of hint.


Structured data: What's it all about?

Yeah, and it's tricky because, like I said,


Structured data: What's it all about?

if you don't put structured data on your page,


Structured data: What's it all about?

you might be getting it fully correct.


Structured data: What's it all about?

So it's hard to convey that in some of our reporting and stuff


Structured data: What's it all about?

that we actually find this useful because it's


Structured data: What's it all about?

a nuanced sort of calculation.


Structured data: What's it all about?

But when there is problems detecting it,


Structured data: What's it all about?

we can use it as an extra signal.


Structured data: What's it all about?

So it's usually on the edge cases


Structured data: What's it all about?

where we find that stuff useful.


Structured data: What's it all about?

That's really, really cool.


Structured data: What's it all about?

And I think it's generally easy to say, like, more data,


Structured data: What's it all about?

as long as it is correct and reflects what's


Structured data: What's it all about?

shown to the user on the page, is never worse.


Structured data: What's it all about?

It's always better to add more data


Structured data: What's it all about?

to clarify what the content on the page is.


Structured data: What's it all about?

Yeah, I mean, that's something that we've


Structured data: What's it all about?

been very cognizant about.


Structured data: What's it all about?

If we do change something in the documentation where it's like,


Structured data: What's it all about?

oh, we no longer need this piece of information,


Structured data: What's it all about?

if we remove it from the recommendations,


Structured data: What's it all about?

then will people think, oh, should I


Structured data: What's it all about?

remove this from my website completely,


Structured data: What's it all about?

like it's no longer useful, which is not necessarily


Structured data: What's it all about?

the case because there could be other tools or systems out


Structured data: What's it all about?

there, like not Google, using the structured data.


Structured data: What's it all about?

And if that's gone from your website,


Structured data: What's it all about?

then there's less information just generally available


Structured data: What's it all about?

on the web.


Structured data: What's it all about?

And it's interesting how sometimes


Structured data: What's it all about?

the implication of that just sort of spirals


Structured data: What's it all about?

into this other realm.


Structured data: What's it all about?

But I have added structured data to a couple of the pages


Structured data: What's it all about?

in our documentation.


Structured data: What's it all about?

So I've done FAQ, and I've done how-to.


Structured data: What's it all about?

And I also did breadcrumb.


Structured data: What's it all about?

But everything's been like a manual approach,


Structured data: What's it all about?

where it's like I take this one page,


Structured data: What's it all about?

and then I'm adding it in microdata line by line.


Structured data: What's it all about?

And I haven't approached it from a massive site.


Structured data: What's it all about?

But I'm assuming that would be something


Structured data: What's it all about?

where SEOs and developers need to collaborate


Structured data: What's it all about?

on reading the requirements and the content that


Structured data: What's it all about?

goes into the fields versus how do you say


Structured data: What's it all about?

where the fields are injected.


Structured data: What's it all about?

And I know Martin and Ryan, you've


Structured data: What's it all about?

both worked together to write documentation


Structured data: What's it all about?

for how you can systematically generate this.


Structured data: What's it all about?

MARTIN SPLITTENBERG Yes, we've done that.


Structured data: What's it all about?

And it's super interesting because a few things


Structured data: What's it all about?

that Ryan said in the podcast right now reminded me


Structured data: What's it all about?

of the discussions we had to write this documentation,


Structured data: What's it all about?

because it is not always easy.


Structured data: What's it all about?

It is not always simple.


Structured data: What's it all about?

And I think that's why lots of people use CMSs, because then


Structured data: What's it all about?

they have solutions that can blanket apply structured data


Structured data: What's it all about?

to a large number of pages and a large number of types


Structured data: What's it all about?

of content.


Structured data: What's it all about?

Then Ryan reminded me, like, yeah,


Structured data: What's it all about?

but how do you ensure that there's


Structured data: What's it all about?

no drift between what is on the page


Structured data: What's it all about?

and what is in the structured data so that they stay in sync?


Structured data: What's it all about?

And I'm like, ah, OK, that's actually not necessarily easy.


Structured data: What's it all about?

Because there's different ways of dealing with that, right?


Structured data: What's it all about?

So your CMS can allow the user to create content and then


Structured data: What's it all about?

actually tag it in a way that is represented as structured data


Structured data: What's it all about?

on the page later on.


Structured data: What's it all about?

For instance, when you have a recipe blog and you have a CMS


Structured data: What's it all about?

and you add a new recipe to it, then there


Structured data: What's it all about?

might be additional fields besides the full text


Structured data: What's it all about?

that you put in that asks you for all the information that


Structured data: What's it all about?

is necessary to express this in structured data as a recipe


Structured data: What's it all about?

as well.


Structured data: What's it all about?

Or you could build something into it that pulls the data.


Structured data: What's it all about?

As Ryan said, the data in the database


Structured data: What's it all about?

that feeds a dynamic website oftentimes already


Structured data: What's it all about?

is structured.


Structured data: What's it all about?

So there might be a database that


Structured data: What's it all about?

has all this information in a structured way,


Structured data: What's it all about?

and we just need to express the structured data not only


Structured data: What's it all about?

in a human-readable form, but also automatically


Structured data: What's it all about?

fill in the JSON-LD markup, for instance.


Structured data: What's it all about?

And that's something that is relatively easy to maintain


Structured data: What's it all about?

and do.


Structured data: What's it all about?

But then there might be people who


Structured data: What's it all about?

don't have as many access to developer resources as others.


Structured data: What's it all about?

And then they might use, for instance,


Structured data: What's it all about?

Google Tag Manager with a custom piece of JavaScript


Structured data: What's it all about?

to pull out the information that is already


Structured data: What's it all about?

human-readable in the page and then create structured data


Structured data: What's it all about?

from it.


Structured data: What's it all about?

And there are a bunch of different solutions.


Structured data: What's it all about?

And we have a wonderful piece of documentation


Structured data: What's it all about?

that explains them all in the potential positive and negative


Structured data: What's it all about?

aspects.


Structured data: What's it all about?

But it is not trivial.


Structured data: What's it all about?

And I remember that.


Structured data: What's it all about?

I think, Ryan, you were mostly worried


Structured data: What's it all about?

about the human-readable side and the machine-readable side


Structured data: What's it all about?

to stay in sync, if that was all.


Structured data: What's it all about?

At least that's in my memory, right?


Structured data: What's it all about?

I do see that as a common question as well.


Structured data: What's it all about?

I'm updating the price on my page.


Structured data: What's it all about?

Is this a problem?


Structured data: What's it all about?

Or how do I keep these things in sync?


Structured data: What's it all about?

And will Google be upset with me if the things are not matched?


Structured data: What's it all about?

Because we also have that in the guidelines


Structured data: What's it all about?

that what you have in the structured data


Structured data: What's it all about?

must match the content on the page


Structured data: What's it all about?

to not be spammy and that kind of thing.


Structured data: What's it all about?

But what if I am just like, oh, I have a technical problem,


Structured data: What's it all about?

or this is a mistake, or something changed,


Structured data: What's it all about?

and I forgot or didn't know I inherited this site


Structured data: What's it all about?

or something breaks in the system?


Structured data: What's it all about?

It seems like this could be a common problem


Structured data: What's it all about?

if you are doing this kind of setup.


Structured data: What's it all about?

How does Google make sure to not penalize sites like this?


Structured data: What's it all about?

I think the key is to make sure that the thing that's


Structured data: What's it all about?

generating, like Martin alluded to,


Structured data: What's it all about?

the thing that's generating your content


Structured data: What's it all about?

is coming from your database directly,


Structured data: What's it all about?

and it's not really manual.


Structured data: What's it all about?

There's approaches that are more likely to stay in sync,


Structured data: What's it all about?

like if you use RDFa or microdata.


Structured data: What's it all about?

Generally, it is wrapping the content,


Structured data: What's it all about?

so it tends to stay more in sync.


Structured data: What's it all about?

Those are sometimes harder formats to actually use,


Structured data: What's it all about?

and it's sometimes easier to inject JSON-LD,


Structured data: What's it all about?

which is why JSON-LD is sort of preferred these days,


Structured data: What's it all about?

is that it's harder to mess up.


Structured data: What's it all about?

But if you're concerned about keeping those things in sync,


Structured data: What's it all about?

I think looking at microdata or RDFa is a good way to go.


Structured data: What's it all about?

What's difficult about the microdata or RDFa?


Structured data: What's it all about?

Is it because it's easier to miss a closing tag or something?


Structured data: What's it all about?

When you say people make mistakes,


Structured data: What's it all about?

what is more difficult about those approaches?


Structured data: What's it all about?

Yeah, it's because you're imposing


Structured data: What's it all about?

a sort of structured data semantics on top of the HTML.


Structured data: What's it all about?

So your HTML is mostly being written for a visual display,


Structured data: What's it all about?

and then you're imposing semantics


Structured data: What's it all about?

on top of that, which sometimes fits very nicely.


Structured data: What's it all about?

But often the data is structured visually in a way


Structured data: What's it all about?

that you would not structure it in a feed or something.


Structured data: What's it all about?

So because of that, it becomes tricky to structure it,


Structured data: What's it all about?

and you have to do fancy things with microdata


Structured data: What's it all about?

that are not intuitive.


Structured data: What's it all about?

I've run into that problem,


Structured data: What's it all about?

where there's some piece of information


Structured data: What's it all about?

that the Google Docs say that I need to provide,


Structured data: What's it all about?

but I don't necessarily have that on the page.


Structured data: What's it all about?

Where do I put it?


Structured data: What's it all about?

And I have to put it in a hidden way,


Structured data: What's it all about?

but is that hidden text,


Structured data: What's it all about?

or is it fine to put it like that,


Structured data: What's it all about?

or some tricky thing,


Structured data: What's it all about?

whereas with JSON-LD, it seems like,


Structured data: What's it all about?

here's just the block of information.


Structured data: What's it all about?

It's at the top, like no weird moving around at the parts


Structured data: What's it all about?

because the whole thing is hidden.


Structured data: What's it all about?

Correct, yeah, yeah.


Structured data: What's it all about?

We try to only do checks on the sort of


Structured data: What's it all about?

the pertinent information


Structured data: What's it all about?

on the structured data you're giving us.