Stand Out on Google Search Using Structured Data and Search Analytics (Google I/O ’17)

By | August 10, 2019


[MUSIC PLAYING] ANDRE VALENTE: Good
afternoon, everyone. Welcome to our
session on stand out on Google Search with structured
data and Search Analytics. My name is Andre Valente. I’m a technical program
manager in Search. And this is Duncan Osborn,
a product manager in Search. Thanks for joining us today. So the first thing
I want to do is to give a little
bit of perspective as to how we arrived where we
are by going a little bit back to the evolution of Search. As you know, Google’s
mission is to organize the world’s information and
make it accessible and useful. But how we’re doing this
is changing over time. Users are not satisfied anymore
with us providing a link to a possible answer. They want us to provide the
answers whenever possible or help them navigate through
the space of possible answers or possible alternatives. And in fact, you
can see that many of our products–
including, of course, the Assistants– are now
having this theme of Google providing assistance
to our users. So before– and, in fact,
until now, in many cases– what you have, if you put a
search like “dessert recipes,” is a set of links that you
can explore, you can try out. And you have some
snippets that try to give you an idea of
what is behind those links. But users that land on
your page once they click don’t have enough context and
it’s not clear their intent. So we tried to make this better. And last year, we launched
this idea of rich cards. The idea of rich cards is that
they are visual modules that organized information on what
used to be a blue link in such a way that it’s simpler to
read, more visually appealing, and easier to navigate. These cards were sometimes
organized into carousels, like you see here. So you would be able to
scroll right and left, and see some possible visual
answers to your query. And now, particularly
in the last year or so, we have
evolved even further into this notion of immersives. These are mini
applications you have, where you can explore
the range of answers. So not only you have the visual
components of these rich cards that we had before,
but you also have things like these tap targets. So for instance, you
can refine your query and say, well, not only I
want a strawberry tart recipe, I want one that’s gluten free. And this way, what
happens is that somebody who clicks on this has
a very clear intent of what they want to get. Now, what happens, however,
is that in addition to all the information that
Google has in its knowledge engine, what
happens, we use a lot of third-party structured
data to power this. And what that means is that
there’s an opportunity for you. If you have a site where you
have relevant information, you can try to
organize that site and optimize its
performance in such a way that you can participate
in these features. What we have found is
that the sites that implement structured
data typically see increased click-through
rates and increased engagement. In other words, the users that
come to you are better users. So for example, here is
one use case that we found. Rotten Tomatoes
implemented structured data in more than 100,000
of their pages. That attracted billions
of impressions. But the more interesting part
is that these pages resulted in 25% higher click-through
rate, which is really very hard to achieve with any other
means, compared with the pages they have that didn’t
have structured data. In other words,
you can do these, and they’re good
results for you. Later on, we’re going to
have more case studies that will explain the details. Now, in the remainder
of this talk, we’re going to teach
you how you can use structured data to optimize
your site’s performance. We’re going to tell you how you
could use this to stand out, pick up the right
markup that you’re going to put on
your site, and how to measure the impact
once you implement this. Now next, Duncan’s is going
to talk to you about how structured data appears
on Google Search and give you more details. DUNCAN OSBORN: Thanks, Andre. Hi, there. I’m Duncan Osborn. I’m a product manager on Search. So Andre’s going to get into
how you implement and measure structured data
in just a second. But I thought first we’d go
through some of the features that we’ve built that utilize
structured data so that you can see how it then
appears to users, and then we’ll go through
the implementation later. So we have quite a
broad set of verticals that support features that
have structured data in them. I’ll go through just
a couple of examples. But I guess the key here is
there are a fairly large number of verticals supported
now, and we have a good set of partners in each one. So there’s a good
base to learn from. And we’re constantly
thinking of new verticals to roll out structured
features into. So I chose just a couple queries
to show off structured data. These are just random
from my search history. Let’s get started from recipes. So this is a great example
of a vertical where we’ve invested in
structured data futures at several levels– namely, the page level,
the domain level, and finally, the result level. And so I’ll walk through
one of each of those. And it’s dangerous to show
cookies at snack time, but here we go. This is at page level. So in this case, what we’ve
done is we’ve taken all of the recipe leaf
results, as we call them– which just means a
single recipe result– and we assemble them
into a single carousel at the top of the page,
which makes it easy for users to access all of the recipe
results in one single place, and make their decision,
and finally land on the one that they’ve chosen. You can see here
that we’re featuring several different kinds
of structured data. First, we have the rating,
we have the calorie count, and we have the cook time. All of those are
sourced directly from the markup on
the third-party site. It’s also important to
note that one click away from this experience is another
interface that we’ve even more heavily optimized for browsing
large numbers of recipes, in this case. And here again, we’re using
the same types of markup, but we’ve just
restructured them so that they fit better in the UX
that we’ve chosen in this case. One other thing
that is important is we’ve seen several
visual ramifications of structured data here in terms
of rating and calorie count. But what’s behind
this experience is actually the
markup at the page level, which tells us that it’s
a leaf result, a recipe page. And so that allows us to make
decisions about how we then present them to users. So both kinds are
important– the signal, and finally, how we decorate
that result for users. So that’s at page level. Now we move to domain level. At this point, we’re
assembling all of the results. But they’re results that
are in a single listing page of recipes– which, by definition,
comes from a single domain. So instead of concatenating many
different domains in one place, we now give the site
owner a single property for their content. So once again,
we’ve reflowed all of the content you
see here in terms of ratings, cook time, calories,
just in a smaller card format. So a good example of how
we’re fairly flexible in how we display this data. But the other
interesting point here is that this list of content
is customizable both in content and in order. And that gives you a fairly
visible level of control over how your results appear in
Search, which is pretty cool. That’s domain. And finally, at
the result level. If we have a result that ranks
that has just a single leaf page, we won’t just
leave it as a blue link. We’ll use any data we have to
decorate that result that it looks really good
and also allows users to make decisions directly
on the search results page. And the next one I
wanted to show you– so moving on from cookies to
something to make you even hunger– is “restaurants in
SF,” which is what cool people call San Francisco. So in this case, we again
have the domain-level results. So we’ve taken all of
the restaurants that are in a listing page and
assembled them into a carousel. But what’s interesting
here is in this case, the site owner has only
just provided the title. And we just shrink the card
to adapt to that kind of data. But in this case, the
site owner could also add things like the cuisine
type or the location for the restaurant. So it’s generally
a good idea just to take a look at our
developer guidelines and see what’s possible
for a given data type. And then you can
decide in that case how you want us to
render the cards. For example, they could
have also added ratings, and those would appear
right between the location and the title. And then one other point here. When you’re doing
domain-level markup, you’re only affecting
your results. So we don’t actually switch
to results as a result. So to burn off the
calories, we’re now moving to running shoes. And we’re also switching
to a different product– in this case, image search. So here, instead of
going to web search, I went to the image search tab,
and I searched for “Nike Free RN,” which is a shoe. So in this case, this
is a good example of a query where
you have users that want a fairly visual
exploration to start with. That’s because they’re
exploring options and comparing how they visually look. But at a certain point, they
want to move to the point where they make a purchase. There, you need additional
information as a buyer. And that is where structured
data comes in handy. So here in this case,
we’ve included the price and the rating
directly in that result once I tapped on the shoe
that I wanted to buy. And then of course,
there’s the link at the bottom of the page
that allows me to visit and eventually purchase. Great. Let’s wrap up these examples
with a brand-new feature that we launched just
about a week ago. This is for events. So in this case, I searched
for “concerts in NYC,” where I live. And here, right at
the top of the page, we have a single
box that assembles all of the events for my query. And so again, we’ve
assembled things, but we rely on structured
data to make this look good. So much of the data
that we see here– the date, the time, the
location, and even the image– are provided to us
by the site owner. So this is, once again,
one of these great features that we can provide to
users based on the data that we’re able to
share with publishers. Andre is here to walk you
through how to then implement all of this markup. ANDRE VALENTE:
Thank you, Duncan. DUNCAN OSBORN: Sure. ANDRE VALENTE: So
what I’m going to do is I’m want to walk you through
the journey of implementing this on your site,
on your property. Before I do that, I just wanted
to highlight and piggyback on a couple of elements
that Duncan talked about, about what is structured
data, what does it look like. Most of you are developers,
but just in case. So we see here on the
left side a specific card with the recipe. And on the right side, I’m going
to highlight a few elements so that you can
see how they match. So you see this is a
script tag in JSON-LD. And it specifies that
this is a recipe according to the schema in schema.org. That’s a public specification. And then each of
the properties is going to match components
that can go into the card. So in this case, for
instance, the name, “Your Basic Quesadilla
Recipe”, becomes the title. You see here, as we
continue, more tags. The image gives you
a URL for the image that we’re going to display
on the image on the left. And the description can
give you some elements that we could use, for
instance, in the snippet. On more structured
components, for instance, this is how you would
specify an aggregate rating. And then we then
translate this information into the stars and
the number of reviews that you see on the left. And then finally, you
have here the total time– the cooking time,
the 10 minutes, as well as the
number of calories. And this is how
they’re specified. So the lesson learned here
is each specific markup, each type you have– in
this case, a recipe– is going to have its
own specification. And you can see
how they translate into the elements of the card. Now, this is the overall journey
of the implementation process, and I’m going to walk you
through each element of it. So the first one is you want to
identify the best markup match. So you’re watching this talk
and you’re thinking, great– it’s something I
could try to do. Now, throughout
this journey, I will talk about different tools. And here’s a summary. There’s the Search Gallery, the
Structured Data Testing Tool, and the Search Console. These things, of course,
are available to you. Hope you can take a moment and
try those out after we talk. The first starting point
is the Search Gallery. The Search Gallery
basically allows you to figure out what
are the places where you can add structured data
and the kinds of things that you can do. The first part I want to
highlight on the left top on this list– by the way,
this is a brand-new version of the Search Gallery that’s
being published this week– you see these enhancements. And these are
things that you can do more or less independent
on the kind of information you have. So recipes markup you’re
going to do if you have recipes on your site. But these are things
that can enhance your results in Google Search
independently on what you do. So for instance,
you could improve how the breadcrumbs
are structured, Corporate Contacts, Logos. You’d be surprised how
many people don’t give us a good specification
of what their logo is so we can show it if necessary. Once you look at
these opportunities, they’re all low-hanging fruits. Probably everyone can do that. And then you see
the second part, which are the vertical
content types that Duncan was describing to you. So you have Datasets, Events,
Fact Checks, Music, Podcasts, etc. So this, for instance, is the
documentation for recipes. And you see that there’s
actually several kinds of markup I can have. On the left side, it’s
like a single recipe or a single query. And then on the top, on the
extreme right, we see a list. So Duncan was talking about
how you can make a list page. This is how it would look like. Now, look carefully at
the specification here. This is all on the
Google Dev site. And towards the bottom
of the Content page, we always show you
the Properties. So earlier on, I was
talking about the schema. Well, here we give a summary
of the things that we expect. And take special care to look
at which things are required, because not all
the pages– if you don’t have all the
required elements, they won’t actually
be published. And of course, it’s
a good idea for you to put the recommended
fields as well, because that will increase the quality of a
result, the quality of the card that we could show, and
will make you look better. So for instance, like number
of calories in the recipe. It’s not obligatory. But if you put it,
the information will be added, as
Duncan was describing. Once you identify the kinds of
markup that you want to have, now the next step is to
actually draft some of it and play with it. Well, back to the guide– to the page where
the documentation is. You see there’s these
links with See Markup. And for each of
those, we actually will then give you
a sample of what the markup is for that
kind of structured data. And that will bring
you to the second tool in our three-tool part called
the Structured Data Testing Tool, which we’re going
to get to later as well. The Structured Data
Testing Tool opens with a sample of that
specific kind of page so that you could use
it as a starting point. The idea is that you
can play with it, see what it looks like. Generally, you try to
make it really complete so it has all the components. And you could use this
as a starting point. Now, we recommend to
you that you create a version of a sample page. Take a page of your
site, for instance, that has a recipe or something,
and then add the markup to that, and test it out. So you can actually give
the address of the page, and SDTT will– Structured Data
Testing Tool, SDTT– will go pick up that page,
analyze it, and tell you what happened with it, and
give you whatever errors and warnings that might exist. Now, if your sample
page, for instance, may be in a pre-deployment
environment– you are not ready to publish yet– you can
still cut and paste the markup here. So you can still test it– it’s just a little
bit more cumbersome. Now once your page verifies for
some structured data element, the next step is for you
to see how it looks like. And you have this
Preview function here. Once you click Preview,
you’ll see a sample card. As Duncan said, it
depends a little on the context how much
information we display. But you could see
what your elements will look like in a
realistic card that would be shown in Search. And that helps you also
tweak your content, so maybe you try different
pictures or different images to see what’s the best way to
showcase your structured data. So at this point, we
understand what we want to do. We tested one to see
what it looks like. And now the next step is to
deploy this for some pages or a subset of your site. We generally recommend that you
don’t do this for everything at once. Get a subset of your site and– actually, can you
go one page back? That you use a subset of your
site and use that to try out. So add this to just perhaps–
even manually to a few HTML pages just to get a notion
of what it would look like. Now, I’ll get more technical. So there’s actually
two ways in which you could add the structured data. So one is the same
kind of script that I showed you
earlier in JSON-LD. You put in a script tag and
it would show like this. And it’s actually
the most common way in which people do it. And another one,
you could actually use microdata inside
a div tag, like this. So there’s more additional
documentation on our Dev site, if you want. Now, of course, you can
implement these things manually, but that’s
not a great idea. What you really would like
to do is to use your CMS. I imagine most of you who have
large, or even sizable, or even not large web properties
have a content management system to manage your content. What you really want to
do, and the most common way we have found that
people do it, is that they pick up a suitable
structured data CMS plugin. There’s many CMSes that have
plugins that you could get. You could try a
few different ones. We don’t have any
specific recommendations. But the idea is that you publish
your standard HTML content, but it then publishes the
structured data with it. So you don’t have to
manage things one by one. So once you put this in a
specific subset of your site, it’s time for you
to review the stats and what this would look like. And for that, we get
to our third tool, which is the Search Console. Now, Search Console is similar
to Google Analytics in a way, but it focuses on Google Search. So it tells you how
Search looks at your site, and what elements of that
appear in search results, and how many times
it appears, etc. Now, different from the
Structured Data Testing Tool and the Search Gallery,
which were fundamentally just open, the Search Console
requires a little bit of setup, because you have to sign
up and verify properties. Now, I’m curious. How many of you have
actually verified or used Search Console? Just so I get an idea. Not as many. Maybe a third, a fourth? So we’ll give you a
little bit of detail. And there’s more
to it than that. But the first step for you is to
get associated with an account. Anybody can get an
account on Search Console. That’s straightforward. But then what you have
is a verification process that proves that you
have rights to the site that you want to verify– again, to test or use
on Search Console. Again, much like
Google Analytics– it’s the same process. Commonly you do this by
uploading some special file to your site or perhaps
to a domain, one of the components
of your domain, and your domain name provider. If you have a
larger organization, you might want to check. It’s frequently the
case that somebody else might have used and set it up. And in this case, they
can authorize you. It makes life a little simpler. So once you register
your site or you register the ability to manage your
site through Search Console, the first thing you want
to do is to add sitemaps. And sitemaps are a way
for us to look and see what information you have. Now, of course, we
already look at sitemaps if they’re available. But this helps,
because it helps us understand which is the
sitemap that you prefer to use. So for instance, imagine
you deploy some new stuff and you have a sitemap. And you give us
that sitemap, and we use that to figure out what the
components are of your site. So for instance, you could
this for a section of your site while you figure things out. This is what Search
Console looks like– much like Google Analytics. Also, there’s a
lot of stuff here, so a lot of different reports. And it’s not always
very easy to find. But let me walk you
through some ways in which you can dig into the
data for your implementation. First, you could use
this Rich Cards report. That’s marked on the left. And that monitors which
structured data elements were correctly found on
your pages after a crawl. And the first thing you
want to do, of course, is to look at whatever
issues were found. So like the Structured
Data Testing Tool allowed you to test
one specific markup, this basically looks at what
elements are on your site and what do they look like. Keep in mind, by the way,
that it takes a while to crawl your site. So once you
implement everything, you might want to
give a couple of days until we catch up to this. What you want to
do, of course, is to look at all the
critical issues– remember, those obligatory
or necessary properties. So for instance, you may
want to look at those because those
things may actually prevent us from showing your
structured data into a card. Could also look at
noncritical issues, as I said before, because they
could improve the quality. Now let’s look, for
instance, at the issues that were affecting
the recipe card type. So see below? This specific site implemented
both recipes and local. So if we click on Recipe, then
we get a subset of the report only about recipes. And you can see here
there’s 218 invalid cards. And in the bottom, you see
the problems that were found. So that gives you
a very good idea of what is it that
you need to fix. As you see in this case,
there’s a bunch of opportunities that you might have missed
in terms of adding nutrition. But the most important
one is that there’s 218 pages– in fact,
all of the ones are invalid, and are
invalid because they seem to be missing a
field– in this case, image. If you click on that same
line, you can dig even deeper and find examples. So Search Console can
actually guide you to those specific
pages on your site where that problem was found. And in addition, if you click
on one of those further, you can actually get a dialogue
that will eventually lead you to the Structured Data
Testing Tool with that page and with that markup,
where you can figure out exactly what went wrong. So we try to help you debug this
at a relatively fine-grained level. So for instance, in this case,
you see on the left side, the image that you’re missing
is marked as no_image_here. On the right side,
you see marked in blue in the list of the
schema or the properties that that property was not
filled and it’s obligatory. So we basically tried
to connect the lowest level of the specific page
to the overall implementation of your site. So now we review all of this. We want to fix and launch,
re-crawl, re-index again. Keep in mind, this could
take a couple of days until we actually
get to all of it. And now you’re ready. So you publish the stuff. And the question
for you– of course, the most important
one– is, how do I know my return on investment? How do I know that
this was useful? And how do I know
what the results are in terms of the effort
that I put on doing this? So these are some
of the key stats. These are standard kinds
of things for web pages– clicks, impressions– the number
of times that the information was shown, the card was shown– click-through rate,
the average position in which this was shown when
it came in the search results page. And you could get all of this
through the Search Analytics report. And the Search Analytics
report gives you a lot of different ways
of parsing and filtering information to find out how
each part of your site did. And in fact, it
also can help you do this both with and
without the markup, which is a great way for you to
compare and one of the ways, of course, our partners use
to figure out what happened. So you can view impressions,
clicks, CTR, and position, as we’ve discussed before. And you can filter based on,
for instance, the search feature type. So notice, by the
way, that some pages can appear both as a rich
and non-rich result given a certain query,
depending on the context. And what you want
is you want to try to analyze what are the
pages that have the high CTR. So basically, you could use this
to detect what’s working well, what are the places where your
implementation had the best results. We show a few ways in which
you could filter this. The Search Appearance filter
tells you how pages with markup perform. So in this case, you
can select Rich results, which are results that
have structured data. You can also filter based
on a pattern of URL. Remember earlier, I said
your might implement this on a section of your site? Well, maybe it’s under
a specific folder or a specific URL pattern. You could specify
this here, and then compare how this looks compared
to the rest of the site. You could also look
at date ranges, which can be useful, for instance, if
you implemented this one week, and then the following week, you
can compare before and after. So this is an overview
of the process for implementing structured
data among these verticals. And now Duncan’s going
to tell a little bit more about how the sites that have
implemented structured data– what kind of ROI did they get. DUNCAN OSBORN: Thanks. Final stretch. I want to walk you through,
again, some of these partners that we’ve seen across a few
different verticals, but also across several
different geos, to show the diversity of success
that we’ve seen so far. So let’s start with the one that
you just saw, Rotten Tomatoes. Again, a good adoption
of structured data, which led to a 25% higher
click-through rate for those results. But they weren’t alone. Here, we saw food.com, which
is one of the primary providers of recipes online. They also had good coverage
of structured data, with 80% of their results,
as rendered in Google Search, as rich results. And they saw a 35%
increase in CTR, which is super encouraging. Next, going over
to Europe, but also going over to a different
vertical– so in this case, local restaurant listings. La Fourchette put markup
on 90% of their results. And they saw, again, a
fairly high increase in CTR. Moving back to recipes,
but over to Japan. So here, this is an
interesting case, because not only did they see
an increase in interaction on those results, but
the resulting session, as users landed on those
pages, was of higher quality. So if you’re in one
of those verticals, it depends on the quality of
a user landing on those pages. This is a great sign. And finally, moving
to South America, we saw Nestle Brazil
with 82% higher CTRs. This is, again,
super encouraging. And hopefully we will see some
of you on this list next talk. So we covered three
things in this talk. The first is the opportunity,
which is literally to stand out on Search– one of the rare
opportunities you have to customize your results
visually for Google users. And we have quite a
few verticals for now, and we’re constantly thinking
of new verticals to roll out. So if you’re not on the
list that I showed before, stay tuned. Second, we showed you
the tools that you can use to implement all
of that structured data and to measure the impact. And, of course, the
results, as we’ve seen, can be very promising. So just to wrap up. This as a quick reminder
of the links that can hopefully help
you get started, if you haven’t already. First, the Search Gallery
to see what the options are. It’s good to click through
the types of content that correspond to the content
that you have on your site. Second, once you start to
implement structured data, the Structured Data
Testing Tool is there to diagnose and to
indicate any errors that you have in your markup,
and also just guide you through the correct
practices to make sure it’s working properly. And finally, in Search
Console, once you manage to ship all of
your structured data, you can enjoy the results
with the analytics that are contained therein. And that’s about it. There are Search office
hours for any questions that you may have. Please take advantage of that. And otherwise,
please enjoy the rest of I/O. Thank you very much. [MUSIC PLAYING]

7 thoughts on “Stand Out on Google Search Using Structured Data and Search Analytics (Google I/O ’17)

  1. RoCeb Post author

    me when I saw the talk title:

    "ooh! I remember learning about web schemas ten years ago! I wonder what beautiful system they've replaced that horrible mess with!"

    Reply
  2. Cristian Sepulveda Post author

    Excelentes noticias sobre ecommerce y datos estructurados para recetas.

    Reply
  3. Maria Georgieva Post author

    When the Rich results filter will be available for all users? Currently I don't see this option – http://prntscr.com/feojg5 . The only option is for AMP non-rich results

    Reply
  4. Andrew Martin Post author

    Great video. I can't get enough of schema, and really enjoying seeing this develop our SERPs.

    Reply
  5. Cassie Markovich Post author

    Great video. Interesting how Google could determine the img src was missing (22:25)…any insight into how you were able to do this?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *