 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'm a webmaster trans analyst coming all the way from Switzerland to talk to you about search. And I'm John Mueller. I'm also a webmaster trans 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. 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 with search. So this is 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. 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. 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 the 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 directly. 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 send 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. Right. 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 slash jobs, 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 in 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 queue the 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 that it's 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're allowed to access that content. And for that, we will first go, every time we access a site, we'll go to a file called Robust or Text, 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 our 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 can function and serve its clients as usual. And then finally, we'll 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 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 in 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 want 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 pull 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 the 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 slash 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. All right. Thanks, Maria. 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 showcase your own content, or maybe you're doing that for other people to show, 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 putting everything in place so that search can pick up the content properly. So that's really important for us. 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. There are requests 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. 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, 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 Maria 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 rel 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 ranking, so the order that Maria 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 a 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, recipes, of course, which we saw with Rakuten in the beginning. So how do you get all of these rich results? Well, Maria 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 codelab here for IO as well on adding structured data markup. So if you're curious on how to do that, I 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 the 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 a great overview of what you could be testing, what you could be looking at, 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 Maria 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 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 IEO 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. Maria 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 control 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 onClick 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 dialogue? 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 onClick handler and handle things in JavaScript is combine the two. So you have your onClick 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 it 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. Maria, can you tell us more? 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 that 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 Joan 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're 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 2 million users or whatever it is, and then immediately they get access to all kind 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's 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 are 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 the URL and what do they want to do with it? And we worked on this for a few months, and at this point is 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're 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's 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. 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're building a comment plugin and if you've 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 altogether 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 websites. 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 that 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 is 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 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 the site processed by search in order to test it. So here's a blogger site that we use for purposes of this example. We install the theme, and then we use 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 team 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 is many, many different details and links that we've provided. So if you have to remember just four things, pay attention to what John is going to tell you right now. 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, 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. And we have a lot more information in our Developer Center, Developer Guides. We have a Search Console Help Center with a lot of 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.