[MUSIC PLAYING] MARIYA MOEVA: All right. Let's get started. Hi, everybody. I'm really glad to
see all of you here. You skipped lunch to
come here about Search. No pressure. So my name is Maria, and I
am a webmaster trends analyst coming all the way
from Switzerland to talk to you about Search. JOHN MUELLER: And
I'm John Mueller. I'm also a webmaster
trends analyst. We're both from
Google Switzerland. Our role at Google is to
help the web ecosystem to be more successful
in Google Search. So we hope we can bring some
of this across here as well. MARIYA MOEVA: Right. So I want to start us off with
an example of how this actually works so you can get an idea
of what you as a developer can do to be more
successful at Search. So this is a Japanese
website, Rakuten Recipes, and they wanted
to get more users. They also have a ton
of delicious recipes on their site. So they were
wondering what can we do to get more people
to notice us in Search? And what they decided to do is
they changed their CMS in order to be able to mark
up every recipe that is added to the site with
structured data markup. And what this does is it
lets the search engine know that there are
different entities, so things like cooking time,
different ingredients, a picture, and lets us display
the result in a much more attractive way in
the search results. And the site itself
was in Japanese. So we decided to
switch off the markup, for those of you who
don't speak Japanese, to something more legible. So instead of dumplings, you
have here a party coffee cake, but it works the same
way for dumplings. And this is how
this ends up looking like in the search results. So you can see that in addition
to the regular elements of the search page, so they
have a title, they have the URL, and then they have
the description, they also have a really
nice picture of dumplings. And then they have the
cooking time as well. So this worked out
for them pretty well. In fact, kind of spectacularly. So they got 2.7 times
more traffic from Search. JOHN MUELLER: Yeah. And we thought
developers usually don't get as much
advice around Search, and they might not
even know about all of the pitfalls
and possibilities. Shouldn't we share
some of that knowledge with them, so with
you all as well? So we hope we can show how
Search can make your projects a little bit more successful. So today, we'll look into
various types of public web presences and give you a broad
overview of specific details that you as a developer can
watch out for and implement. And these details can help
make your projects more successful on Search, making
it easier for search engines to send users to your
projects directory. So you might be
thinking as a developer I don't really care how or if
my stuff appears in Search, but probably your customers,
your users, the people that you're building these
projects for, they do care. And since you control how your
content appears in Search, you can have a huge impact here. Think back about Rakuten
Recipes and what they did there. Globally, Google
Search and Google News sent billions of visitors each
month to websites for free. And it's not just
about websites. We're going to be
looking into various ways that Search can work depending
on what you're working on. A website is just the
most common format. You could also be
building a web app, which is kind of similar, but
slightly different as well. Or you could be contributing
to a content management system, a so-called CMS,
which enables others to build websites of their own, or as
a part of that, maybe you're working on plugins or themes
or extensions for these content management systems. We'll take a brief look
at these as well as detailed recommendations
for each of them. And as I mentioned
before, search brings billions of visitors
to websites every month. That's a lot of visitors. We serve trillions of searches
each year, and out of those-- this is quite surprising for
me every time I look at it-- about 15% of the
queries every day are completely new ones,
things we've never seen before. So maybe they're looking
for one of your projects. And regardless of
what you're building, if search engines
understand your content, you could get a
lot more visitors and potential
customers with Search. So you as a developer, you can
control that through the way that you set up your
website or content platform. So to understand these better,
let's take a quick look at how Search works. MARIYA MOEVA: Great. So in order to be successful
as a developer in Search, you need to know at least
the basics of how it works. And I'm going to
take you through the super, super high-level
picture of how it works. If you're interested in the
details, Google.com/jobs, you're welcome to apply, and
then we can go into a lot more detail. But let's get started with
the super high-level picture. So we generally talk
about three things-- first, crawling and
discovery, then indexing, and finally ranking and serving. So I'm going to show
you very briefly what each of these things is about. So of course, in order for us
to be able to show anything in the search
results, first we need to be aware that it exists. So we have a series of
systems that are going around following links on the web
and downloading web pages, HTML files, all the
different resources that come into making a website,
like JavaScript files, CSS, images, what have you. And those systems
collectively are crawlers, and we call them Googlebot. So the goal for us is to find
everything that is fresh, new, interesting, relevant,
and important and to do that in
an efficient way. And in order to know which URLs
to crawl and in which order, we have another set of systems
which are known as Schedulers. So they cue to URLs for the
crawlers to go and fetch. And all of this
gets then stored. So you might think that this
is a pretty simple process. But if you start
thinking that we have to do this 20
billion times per day, then you kind of get an idea
its a little bit trickier than it seems at first sight. In fact, in 2016, we
saw 130 trillion pages. And every new link that
we see, usually there's two more links that
we've never seen before. So there's constantly
new stuff, and we have to decide
what to crawl, how to update, and to do this in
the most efficient manner. So once we find the content, we
have a series of other tasks. First, we have to
make sure that we are allowed to access that content. And for that, every
time we access a site, we'll go to a file
called robots.txt, which is a pretty simple
file containing instructions to search engines
and other crawlers. And it tells you this is OK
to fetch, and this is not OK, and we obey this very strictly. So that's the first thing that
we'll try to find on a website. The other thing
that we'll try to do is to get as much content as
possible without troubling the normal work of the server
so that website function and serve its clients as usual. And then finally, we will try
to handle errors gracefully. So as a developer, you
have two tasks here. The first, if you remember again
that we do fetches 20 billion times a day and we see
trillions of pages every year, is that your content should
be really easy to discover. So ways to do that, and John
will go into a little bit more detail later,
is to for example submit to us a list of URLs
that you have, like a sitemap. Or also check that
all the resources that are necessary for your
site to be rendered are accessible to our crawlers. So once we've fetched everything
that we were able to fetch, we go to the next stage,
and that is indexing. So here we're going to parse
the content, and into this comes things like what
language is this page, are there any images,
is there a title, is there a description, and
other different elements on the page. So to do that, we also
try to render the page. And as a developer,
especially if you're building a lot of really
cutting-edge fancy things, you have to keep in mind
that currently the search systems are using Chrome
41 to render pages. So not all of the
different functionalities that you might be
thinking about could be supported by the
search rendering systems. And if you want
to find out more, I would suggest that you
have a look at the talk that John did earlier
today in the morning, in case you didn't wake
up at 8:30 to see it. It will be available
on YouTube, and you'll be able to see a lot more
about what we support in Search and how to render
things properly. So of course, given the huge
amount of pages on the web, we also don't want to index more
than one of each unique thing. So we have a lot of systems in
place to eliminate duplicates and to keep only one
copy of each thing. And then finally, we
don't one error pages, and we also don't want any spam. So we will kick all of that
out, and everything else that we want to keep,
we put in the index, and we process it so that it's
ready to serve to users when they search. So for you as a
developer here, I guess, it's important to remember
that key elements like titles and descriptions are
available in each page that your users are
creating and then also to check how it's rendered. But John will go into a
lot more detail here later. And then finally, once we have
everything in the index, when users start searching, we're
going to pool a set of pages that we think are
relevant results. We're going to add a
bunch of information that we've already
accumulated to them, like how important they are and how
they relate to user's query. And then we're going to show
them in some specific order that we think is most
relevant for this user. So this is mostly
on our side, and you don't need to worry
about anything here if your content is already
accessible and easy to render. But if you're really interested
in ranking and search quality, again, google.com/jobs. There's plenty of interesting
problems to solve. So now that you know
how Search works, let's have a summary
of the two things that you need to remember. First, you have to help
us find the content and, second, you have to
help us evaluate the content. So if you're able to
do these two things, you're pretty much
set as a developer. Now, this is super,
super high level. So what we're going
to do next is show you how you can apply this
for each specific thing that you need to build. So we're going to
start with websites. And John is going to share with
you some very specific advice about what to do and what
not to do when you're building a website for someone. JOHN MUELLER: All right. Thanks Mariya. That was a great
introduction into Search. So like you said, let's
start with websites. You can build and
maintain one for yourself to kind of showcase
your own content or maybe you're doing
that for other people to let them create
websites on their own. You might be thinking
that showing up in Search isn't really your
job as a developer, but like we mentioned
before, as a developer you play a really big role
in kind of putting everything in place so that Search can
pick up the content properly. So that's really
important for us. Now, when it comes
to websites, I think it's worth taking a
really big step back and looking at the absolute basics. So for us, that's a URL. That's essentially
the address that's used to address a single
piece of content on the web. Perhaps surprisingly,
URLs are the cause of and solution to a lot
of web search problems. Traditionally, URLs on the
web started out quite simple. They're a request that's
sent to the server, and the server responds
with unique HTML per URL, fragments within the URL. So everything after
the hash sign here. They essentially just
lead to a different part of the same page. JavaScript changed that a little
bit, and suddenly a single URL could do a little bit more and
show different kinds of content and provide extra functionality. To keep state, some
JavaScript sites use fragments since these were
easy to set with JavaScript. However, Google generally
doesn't support this. And as far as I know,
no search engine supports addressing
unique content with individual fragments. So nowadays, we recommend
using JavaScript's history API to use normal
traditional-looking URLs. So, in short, with URLs stick
to something more traditional. Another really important thing
that comes into play with URLs is that often you have
many different URLs that lead to the same content. As a developer, that's
usually no big deal, and you can look at that,
and you think, well, index HTML, that's
obviously the home page. I mean that's, like, every
developer knows that. But for search engines,
that's not so obvious. It could be something
completely different. Sometimes you also just
track, add tracking parameters to URLs, and all of
these different URLs are essentially, for search
engines, separate pages that we could look at and
say, well, there might be something different here. And you can imagine at
20 billion times a day, that could lead to a lot
of inefficient crawling. So we prefer to have a single
URL per piece of content. And there are two ways
that you can do that. The first is to consistently
use the same URLs across your whole website. So if you have internal
navigation linked to the same pages,
if you have a sitemap file, like Mariya mentioned,
use the same URLs there. If you use anything to guide
people to your websites, make sure you use the
same URLs there instead of having these
different patterns that all lead to the same thing. And secondly, one element
that you can also use is the rel canonical
link element, which is something you can
place in the head of a page that tells us, well, search
engines or Google, if you look at this page, this is
actually the URL that I prefer you look at. This is the one that
I want you to index. And together, this makes it a
little bit easier for search engines to pick the right URL. So we have URLs covered. What else is there? Let's take a look at a
typical search results page. So we have on top the title,
in this case, the Google I/O schedule page. Then we have the URL,
which is right below it. In this case, it's
a breadcrumb URL. We'll look at that briefly
a bit later as well. And then you have
the description. So these are three elements
on a search results page that are immediately
visible to everyone who's searching for something, and
they come from your pages directly. So it's something
that, as a developer, it's really easy to place. When you look at an
HTML page, they're very visible and easy to find. So we have the title on top. This is really easy
to put in here. We have the canonical tag, the
route canonical link element, which is also really
easy to place here. And we have the description--
meta description. So while these elements don't
directly affect the rankings, so the order that
Mariya talked about, they do affect how we show a
page in the search results. And with that, they do affect
how people actually come and visit your pages or not. So we've seen a few
of the basic elements here like the metadata,
the titles, the URLs, and the descriptions. What could you as a
developer do to make that a little bit easier? Especially if you
have various people who are using your website, your
project, to put content online, we recommend making
it as easy as possible for them to do the right thing. So not just for
you as a developer to put titles, descriptions,
and all of that into your pages, but also for those
who are creating pages on your platform to
put that in there. So here, you see
a user interface from Blogger with
a really easy way to just add a description
to individual pages. And we feel the easier
it is for people making your pages to actually
put this content in there, the more likely they'll
actually do that. So when we looked at
the search results, we saw this kind of
breadcrumb there as well. And a breadcrumb is, for us,
something that is something that you can provide
on your pages to make it easier to understand
where this page belongs within your website. We call this a type
of a rich result, because it's not just
the pure text result. And there are different
kinds of rich results that you can also use. For example, you could
add markup for articles if you have articles on a page. You could tell us
about podcasts, which is really cool because
there's a podcast player built into the search results. So if you have a
podcast, if you have a project that
includes audio content, then suddenly that
content is immediately available in the search
results without anyone needing to install an extra
app, which is really cool. And then finally, recipe's
of course, which we saw with Rakuten in the beginning. So how do you get all
of these rich results? Well, Mariya mentioned
that briefly. Essentially, it's just a
bunch of JSON-LD markup that you can add to
the top of your pages that gives us a lot
more information. So this is something that you
can just add to the pages here. It's really easy to add. We have a bunch of
different types of markup that you can add here. There's a code lab
here for I/O as well on adding structured
data markup. So if you're curious
on how to do that, I'd definitely take a
look at the Codelab. I have a link here. And the Codelab
includes information on finding the right types of
markup to add, how to add it, and how to test it. So that's a great
thing to check out. Another element when it comes to
web pages, if you're working on just a general web
page project, is speed. For us, speed is a
ranking factor at Google. So it helps us to
determine which pages we should show in the
order in the search results. But generally, we've
also found that speed makes a big difference even
outside of search engines. And there are various
tools to test speed. We have a link
here that gives you an overview of the different
testing tools that we have. One of the tools is
PageSpeed Insights, which I showed here, that gives
you great overview of what you could be testing, what
you could be looking at, and what you could be improving. And then, one other
really important tool when it comes to Search
is Search Console, kind of what the name says. So within Search
Console, you get a lot of information
about this whole pipeline that Mariya showed,
everything from discovery to crawling to indexing
and to serving, so how we show your pages
in the search results. You can find information
about this in Search Console. Additionally, we'll also
alert you of critical issues as they arise. So we strongly recommend that
everyone checks this out, if you're making a public web
presence, anything that you want to have indexed in Search. And it looks like
a lot of you do. So the first step when it
comes to Search Console is to verify ownership. We don't show the data in
Search Console to just everyone. You have to kind of prove
to us that this is actually your website. One thing that I
find really important here is if you're making
a project for others online, make it as
easy as possible for them to verify ownership. So make it possible
for them to add any of these verification
tokens so that they don't always have to go back to the
development team and say, hey, I need this special
file that has this content and put that on the page. So we talked about
websites quite a bit, but web app is another
really important topic, which I imagine a lot of you
have seen in different ways here at I/O already. For us, a web app is kind
of like a normal website, but it provides a lot more
interactive functionality, interaction, maybe a logged-in
view, personalization. Maybe it has parts
that don't actually need to be indexed as well. For example, a
travel business might have information about
timetables and general pricing but also have
detailed information about specific connection plans
for individual connections or personalized pricing as well. Or in this case,
for Search Console, we have a lot of general
informational pages as well as a lot of content
that's kind of unique and where you have to be logged
in to actually gain access to that. So for these types
of sites, you kind of have to balance between what
you want to have indexed and what you don't really
want to have indexed. And for web apps in
general, I'd also take a look at the
JavaScript site session from earlier today. So there are a
few things that we found that are kind of unique
when it comes to web apps that generally don't play such a big
role on websites in general, especially if you're
making normal HTML pages. The first one is how to
actually find URLs on your site. So we talked about URLs briefly. Mariya mentioned how important
they are for discovering pages. And within web apps, we've
seen that people sometimes don't use traditional anchor
tags to let us know about URLs. So in particular, we love
finding things like this, where we have an A tag,
we have a link to a page. We can crawl that. It's really easy to find. It's a lot trickier when you
have something like a span that essentially just calls
a JavaScript function with an on-click handler. Then search engines, when they
look at that, they're like, I don't know. What do we need to do here? Does this show a dialog? Does this show a new page? Does this go somewhere? We don't know. So we can't crawl
this kind of a link. So what you can do, if you want
to have an on-click handler and handle things in
JavaScript, is combine the two. So you have your
on-click handler and you have your
href attribute to let us know about the other page
that we can go off and crawl. Another extreme when
it comes to web apps is that we often
run into situations where we see tons of different
URLs, which makes it, again, quite inefficient to
actually crawl through. So there are different
things that you can do here to let us know about this. The first is
obviously to avoid us actually going off and crawling
all of these different URLs. So if these don't provide
unique functionality that you need to have
indexed separately, maybe you can use
other ways of linking to them other than A element. Another thing that you can
do is within Search Console tell us about individual
parameters within the URL that you don't care about. So this is a really
neat tool, but it's also very strong
functionality in that if you set this up
incorrectly, then of course, we won't go off
and crawl all of these URLs. And if this is something
that you care about, then suddenly we won't be
able to index that. So I'd watch out
for this, but this is a great way of handling
this kind of duplication within a website. Again, like we talked about
before, a lot of web apps use JavaScript frameworks. And for JavaScript
frameworks, you have to watch out for
some specific details as well so that we can
actually render the content, that we can crawl and index the
content in an efficient way. For that, I'd really refer back
to the JavaScript site session that we had this morning. A really quick way,
if you just want to have a short view of whether
or not your JavaScript site, your web app works
for Search, is to use a mobile-friendly
test, which is shown here, which shows the mobile view as
Mobile Googlebot would show. This is really important
for us, because we're switching to
mobile-first indexing, where Googlebot is actually
using a mobile device to crawl pages rather
than a desktop device. So definitely makes
sense to check this out. And we also have a
bunch of best practices and general guidelines
that apply more to web apps that you can check out in
the other session as well. So what do you do
if you're not just building one application
or one website but rather a whole platform? I don't know. Mariya, can you tell us more? MARIYA MOEVA: I have some ideas. All right. So you could be building
an individual site or a web app for someone or for yourself
or you could be contributing to an entire content
management system or another hosting platform. And here, what I mean by
this is any type of platform where other people can create
their own online presence. So it can come in
different flavors. For example, it could be
something like WordPress where you could download it
and host it on your own server or it could be a fully hosted
system plus your own domain like Squarespace, for example. Or it could be
something where you just get a URL on their own domain
and also it's hosted by them, like Tumblr. So there are all these
different flavors. And you could be
working for a system like this, which in its own
turn has a bunch of users. So what you do affects
all of these people. And that is a lot of power
and a lot of responsibility. So we're going to talk
about what can you do to make all these
people successful in Search by making some changes
to the platform itself. And this is a really
important topic for us right now, because more than
50% and growing of the web is currently built
on various CMSs. So more than half of
the content on the web is affected by the
systems, and if you're working on one of
them or planning to do so in the future,
it's really great if you're able to make those
people successful in Search as well, because that's
why they came on the web. They wanted to connect
to others, maybe find some customers
and so forth. So we've been thinking
a lot about this, and we've built a set of
APIs to help you integrate search functionality
directly into the interface of those systems. And I want to show you some APIs
and how they've been integrated already, maybe to give you
some inspiration and some ideas about what you can do. So as John was
mentioning before, the first thing that
we need in order to show any type of search
information or search functionality is to have
proof that you are indeed the owner of the site. And he mentioned how this
works for individual sites. So you can have an HTML file. You can use a DNS
entry and so forth. But for those users, especially
for the less savvy CMS users, wouldn't it be great
if you could actually simplify it to one click? And it is possible
with the verification API and three-legged OAuth. So we've built this API
so that you can use it, and if the user
authorizes you, you could verify their
site, which is hosted on your platform
on their behalf. They just need to
click one button, and they immediately have access
to all the search information. So the experience for
them is really smooth. And you can do this for 1,000
users or for two million users or whatever it is, and
then immediately they get access to all kinds
of interesting stats. Which brings me to
the next API, which is the Search Console API. And that provides access to
aggregated stats per site so you can see things like
clicks, impressions, crawlers. You can submit a
sitemap through there. And you can slice and dice
this in many different ways. So for example, you can look
per country, per time period, or per device. And you can build very
interesting interfaces with that. And here on the
slide is an example of a request where you
just pulled the top 10 queries per clicks for a
specific period of time. And then as a
result, you would get a table with the query
clicks, impressions, position, and so forth. Now, a table in itself
might be informative, but it's not really exciting. So let me show you some ways
in which existing CMSs have actually integrated this. We've been working with WIX, and
they created this Achievements sidebar for their users. So they're using the
Search Analytics data to give these little
badges every time something happens that
they think the user will be happy to hear about. So their users are super excited
about this gamified approach. And they're constantly
looking there in order to see, OK, what did I get now? What did I get now? So here is clicks
and impressions built in an Achievement
sidebar like this. We've also been working
with Squarespace. And actually, just this Monday
they announced this new report that they integrated into the
interface of their own CMS. So what you see here is
the one-click verification. When the user click connects
to Google, in the back-end their site gets verified,
and then this report gets populated with information
from Search Console. So here the user can see clicks,
impressions, and the time series over the last month. Squarespace has a bunch
of other analytics reports inside their CMS so people
can compare and build the full picture of how
they're doing in Search. And at this point,
they don't even know that Search
Console exists, but they have everything that they
need to know how they're doing and to accomplish the
correct tasks right there in their Squarespace Dashboard. So we're pretty excited about
this kind of functionality. And we want to build up on it. And we would be looking
forward to work with other CMSs if you're representing one
and you're interested in this. Another thing that we really
wanted to help users with is get their content as fast as
possible on the search results. And so we've been
looking into ways to use the indexing API that
we have in order to get content submitted super quickly and
then also be able to share the indexing decisions. So what did our search
systems think about this URL, and what did they
want to do with it? And we worked on this
for a few months. And at this point,
it's in a place where this can happen within seconds. So again with WIX, we built
a pretty cool integration where when a user
submits a page, and it matches a certain
quality criteria, basically they can click a
button within the WIX interface and then the page gets submitted
through the indexing API, and then after that,
they immediately get a response if their page got
on the search results or not. So for the WIX users, this
is a pretty cool experience, because they can see their
page in the search results immediately after
they've created it. There's no waiting. There's no wondering,
am I on Search or not? Within seconds,
they're on Google. So we are interested in
working with other CMSs, and if you represent some
kind of content management system or a platform which lets
users create their own presence online, and especially if
your users are less savvy and they don't really know
what to do with Search, we are really interested
in talking to you to see if it might be a good
fit to participate in the CMS Partnership Program. So there is a link on the slide
which will take you to a forum, and there you can tell
us a little bit more about who you represent and how
you would like to work with us. So looking forward to hearing
from some of you hopefully. Now, you could be contributing,
not just to the core product of the CMS, but to a
bunch of other things which people install in order
to enhance the functionality of their site. And one of those
things are plugins. Now plugin here is defined
as any kind of add-on that people would
add to their site. So for example, things like a
shopping cart or maybe a way to add reviews or a comment
plugin, things like that. So while it can enhance the
functionality of the site, it can also significantly
alter the functionality of the site in terms of
performance and other factors. So I wanted to give you
a few tips on what to do if you're building plugins. First of all, make sure
that it doesn't slow down the performance of the site. So in order to do this, have a
test site, install the plugin, and then use our speed
tools to make sure that the site with the
plugin is doing just as well as the site
without the plugin. This is webpagetest.org, which
is one of the performance tools that we have. And the neat part about it
is that it will give you a super-detailed
breakdown of what loaded and when so you can see how
your plugin is affecting the performance of the site. So test that out. Then, if you are
building a common plugin, and if you have been on
the internet in general, you will know that there are
a lot of comments out there which are maybe
a little bit less valuable than other comments. And especially in some cases,
they're all together spammy or they're bots which are
going around and posting auto-generated stuff in
order to create links that they're hoping
search engines will follow to some spammy web sites. So this is not
pleasant for any user, and you can actually help
them out a little bit if you're building
a plugin like this by adding a specific
type of annotation to those links by default
so that search engines know not to trust them. This is a link attribute
that we call nofollow. And basically what it
does is it will just tell the search engines
don't follow this link. Don't trust it. So if you're building
a comment plugin, definitely consider adding this
to the links in the comments. Finally, and kind of
most unfortunately, we've noticed that one of the main
vectors for attack on websites, and attacks on websites
are increasing, is hacks through plugins. So a lot of hackers and
other malicious people will get access to a site
through an old plugin. And if you're building
plugins, there's a few things you can do to make
sure that your users are not affected by this. First of all, make
sure that every time you add an update, everybody
who has this plugin automatically receives it. Then make sure to follow
coding best practices so that there's no back doors
that the hackers can exploit. And finally, if you get
tired of this plugin and decide not to support
it anymore, make sure it's clear to people
that this is not supported so they don't
go ahead and install something that is
actually making their site more vulnerable. Themes are another thing
that are very closely related to CMSs,
and a lot of people install them in order to improve
the appearance of their site and make it look cooler or
give it a specific, like, feel. So they can change
how the site looks and how users perceive it, but
they can also really affect performance, and they can also
affect mobile friendliness. So again here, test your theme,
make sure that it's responsive. You can do this with
the mobile-friendly test that John was showing earlier. And for performance
specifically, we recommend again having a test
site and then with the theme and with another theme, having
a look at how it performs. Lighthouse is one
of our speed tools, which is really
useful in this case, because it's in the browser. You don't need to have had
the same processed by Search in order to test it. So here is a
blogger site that we use for the purposes
of this example. We installed a
theme, and then we used Lighthouse to do
the performance testing. So you see how long
it takes actually until what they call the
first meaningful paint, which is when all the elements
appear to the user. So the overall score for this
theme was not super great. And also the specific user
metrics were not great either. But then we went ahead and
we switched to another theme. So you can see here it's
much, much faster to load, and the user can interact
with it much faster as well. And consequently, the
score is also great. So if you're building
themes, definitely make sure that it's
performant and also that it's responsive by using
the free tools that we provide. So there's a lot of stuff
that we covered today. And hopefully for
any of these things that we've told you that
you might be building, you now have enough
tools and equipment to go ahead and make
improvements and make your users happy and more
successful in Search. We know that there's many, many
different details and links that we provided. So if you have to
remember just four things, pay attention to what John is
going to tell you right now. JOHN MUELLER: All right. Thanks. Wow. That was a lot. OK. Looking back at
these things, there are a few common
elements that we covered that came up again and again. So first, is
remember the basics-- URLs, titles, and descriptions. They do matter. They do play a big role
when it comes to Search. They play a big role in how
people come to your site through Search. Secondly, remember to take
advantage of structured data, like the Rakuten example
in the beginning. Obviously, they saw a
big change in the traffic from Search, even
without ranking changes, just by making their
search results look a lot more visually appealing. And then take advantage of
all of the tools and APIs that we have available. So use the Search
Console, understand how Search Console works. Use the APIs from
Search Console to make it better for your
users, people who are using your products, to
really create fantastic web presences. And then finally, especially
if you're making something for other people to
create web presences in, make it as easy as
possible for them to do the right thing as well. So make it easy for them
to put the right fields in, to add data about titles
and descriptions on pages, make it easy for them to really
create high-performance web pages. So these are only some
general tips, I think, to get started with. There are obviously a
lot of different aspects that come into play with Search. But we think these are
aspects that are really critical to start with. We have a lot more information
in our Developer Center, Developer Guides. We have a Search
Console Help Center with a lot more information
about Search in general and specifically
about Search Console. If you have any more
questions today, we'll be in the Web and Payments
Sandbox area later today. So feel free to come
by there as well. And finally, there are
of course other ways to reach out to
us online as well. So you can find us on Twitter. We do live office hours
Hangouts where you can join us with a YouTube Live Hangout. We're available in the
Webmaster Help Forum if you have any questions. So don't let questions
kind of stick around. Make sure you get answers to
them from us if you need them. We hope you found
this introduction into Search interesting. Thank you all for coming. We wish you and your
projects more success online through Google Search. Thank you. [MUSIC PLAYING]
