 All right, welcome, everyone, to today's Google Webmaster Central Office Hours Hangouts. My name is John Mueller. I'm a webmaster trends analyst here at Google in Switzerland. And part of what we do is talk with webmasters and publishers like the ones here in the Hangout today. As always, a bunch of questions were already submitted. And I'll try to run through some of those as well. But if any of you are new to these Hangouts and want to jump in with the first questions, feel free to start now. Good morning, John. Heinz here from Berlin. So I have a question. I work for the domain racuten.de. And we have a subdomain which is called redirect.racuten.de. And the Google Search Console has shown me that this subdomain is infected with malware. And to be honest with you, I don't know where that comes from. And I don't know how to handle the situation. And the situation has been for about six months now. And I really don't know how to change the situation. So maybe if you could give me some insights on how to handle this. Or I don't know, redirecting that subdomain or doing something different. I'm open to any proposal. Thank you. OK. I probably need to look into the site directly to see what is happening there. So I can't tell you exactly what's happening in this specific case. But in general, what's important is that you verify the site in Search Console so that you get a little bit more information so that you can also do the reconsideration flow for malware type things. So usually what happens in Search Console is it takes a few days to update the data there. But you should see information about the individual URLs or some more specific information about the malware that we found there that we flag. If you're not seeing anything in Search Console after having verified the site, after also making sure that you have the right version of the site verified. So the correct subdomain, the HTTP HTTPS part set properly, then I'd recommend posting maybe in the English Webmaster Help Forum where there's a section for malware as well. And there are a bunch of experts that are active there who kind of know their way around the systems on what to do. And that can also escalate that to us should they not be able to figure out what is actually having that. All right, thank you. I have one, though. All right, go for it. It's hard to hear you, but we'll see. OK, it's better now or still a bit, but go ahead. OK, I will try to make it simple. That is a single site, multiple domains. We kind of try to register everything possible, com, org, net, EU, FAD, DA, CoUK. It's about 100 different domains. And I set all of them on the hosting account as part domains, all of them pointing to the main domain. So basically, it's just making sure that no one else is registering our domains and each of them redirects to the main domain. Is that OK or should I do something different? That seems fine to me. So what will happen there is we will index your main domain, the one you're redirecting to. Yeah, we'll form domain. But if people go directly to the other domain names, if they type them in, if they use a bookmarklet or whatever, then they go to your main domain. So that's perfectly fine. OK, thank you. All right, let me go through some of the questions that were submitted. And we can see how far we go. And if you have any questions or comments along the way, feel free to jump on in. And we can take a look at that as well. All right, the first one is a bit of a tricky one, I guess. You effectively own the internet and the fate of many small businesses. And you do a great job. What expectation of consistency, traffic-wise, are you willing to offer? Given that it's understood that we have no real expectation and don't operate like this, when a large site is hit unexpectedly and heavily, that was previously considered quality by you. Do you investigate? Most updates are gentle. Adjustments of plus minus 10% to 30%. And I guess it goes on with what can we do if we think that our site is essentially losing traffic undeservedly? So from our point of view, we do investigate a lot of issues when they come up either publicly or when we notice that in our systems, that something weird is happening with sites. And when we run across technical issues that are essentially on a site themselves, we do try to contact that site. A lot of times, we do that directly automated way through Search Console. Sometimes, we even do that manually, where we reach out to the site's owner or to any contact that we can find at the site and say, hey, you have your rel canonical set up wrong. You have a no index on these pages. Suddenly, these all return 404s. So these are things that you need to fix. Otherwise, you will see strong changes in traffic. So that's kind of what we try to do on our side in that regard, with regards to individual sites when they do run across issues and they post in our forums. That is something that we also look into as well, where we try to figure out how much of this is happening on purpose, essentially normal algorithmic updates, and how much of this is something that we didn't expect. That maybe we need to figure out what our algorithms are doing, that maybe they should be doing differently, or that we could be doing differently in the future. It looks like you're here in the Hangout. Do you want to jump in and kind of provide some more context? I can't hear you. I don't know if you're a microphone. Oh, man. Or maybe you can type into the chat. So he's saying we believe we're high quality. We've worked hard to stay that way for the last 16 years. We had this problem before. And before, we fixed it with Hummingbird. So Google, I guess, fixed it with Hummingbird. It's kind of hard to say with Hummingbird, because that's more of an algorithm that affects the way we understand queries. But you're currently seeing a 60% drop in traffic, I guess. So we're a language forum. So I guess what I would recommend doing in a case like this, I'll see what else you continue typing there. But what I would do in a case like this is post in the Webmaster Help Forum. Maybe send me the URL as well separately so that I can take a look at the thread and that I can kind of double check to see what's happening there with that specific site. So some of that is really sometimes hard to tell. Some of that are just like normal organic changes that happen on the web. You can send me the link. Maybe if you started threading the forum, send me the link on Google Plus directly. And then I can take a look from there. I can't guarantee that I'll have a magic answer for you where I can say, well, this line is wrong on your site, or this is an issue on our side, and we can fix it overnight. Some issues we can fix fairly quickly if it's really a bigger problem. Some issues essentially require that we update our algorithms. And we work on trying to improve things there. But I'm very happy to take a look, especially since it sounds like something that is really frustrating for you in a case like this. Is there a different re-crawl rate for news and e-commerce sites? We have an e-commerce price aggregator for Southeast Asia, a price to stay, but Google re-crawls our pages once in every seven to 10 days. So a lot of the content is essentially obsolete. So what I would look at here is we did a blog post recently on crawl budget, crawl rate, on the Webmaster Central blog. And I take a look at that blog post to kind of see how we look at things like crawl rate. So just because a site is a news site or an e-commerce site or a price aggregator doesn't mean that we will crawl that site more frequently or index the content there more frequently. So that's kind of the general thing here. We do look at things like how fast do we think these pages are changing, but we also look at things like how important is it for us to actually keep up with all of these changes. So some sites, for example, change every day or change every couple of minutes, but they do that because they're aggregating feeds from so many other places. And from our point of view, it's probably more worthwhile to index the original source rather than just this aggregator. So I don't know in your specific case if that kind of falls into that category, but that's something where I double check the blog post and really try to make sure that what you're doing is in line with what we're looking for as well. And if not, maybe figure out a way to make it more in line, I guess, because these things are sometimes really hard to keep up. The other thing to mention here is that we don't crawl every page on a site in the same frequency. So some pages we crawl a lot more often because we recognize that there's information here that changes very frequently. So often that's, for example, the home page, maybe the main category pages. Maybe we'll crawl them every couple of hours or every couple of days at least. And other pages we crawl a lot less frequently. So those are things where we assume that this content will probably stay similar or in the same way for the longer time. So we don't have to re-crawl it that frequently. And some of this is something that you can influence on your side through technical means as well. On the one hand, having a server that's really fast that doesn't return server errors when we try to re-crawl a little bit more. On the other hand, making sure that there are fewer URLs on your site that lead to the same content. Because the more URLs that lead to the same content, the more URLs we have to crawl before we find different content on your website. So especially in a case where you are generating a lot of URLs, which I assume is happening with a price comparison site like this, make sure that you're not additionally duplicating those URLs through weird URL parameters or upper lower case or different paths that lead to the same content. So those are kind of the things I would watch out for there. That's all mentioned on the blog post as well. So if you check out that blog post, I'm sure you'll find some more information on things you could be doing. John, regarding that, so when you have a lot of URLs, especially large commerce websites, they have a lot of filters, and their combination, generates thousands, tens of thousands of URLs. In those cases, we usually prefer using rel canonical to kind of lead to the unfiltered category. Let's say that's category of products, and you have a lot of filters. And every combination of filters leads to the unfiltered category. Is that a good practice? Would Google start crawling those filters less once it sees the canonical tags, or should we just no index or no follow them just to save, crawl, budget, or things like that? So we would generally learn that those parameters are less important, and that's something you'll probably see in Search Console when you look at the URL parameter handling tool, and then we'll recrawl those URLs a little bit less frequently. But at least in the beginning, we have to crawl those URLs to see the rel canonical. So kind of, as a first step, it won't stop crawling, but over time, it'll improve things. OK, but if I have 1,000 categories, but the filters create another 100,000 URLs 100 times more, is canonical still good there, or should I be worried and start no following some things just so Google doesn't get lost? I think a canonical is good there. I would also use the parameter handling tool directly, in a case like that, where you kind of know what you're doing and explicitly say this parameter is irrelevant or provide a sample URL for that. So this parameter doesn't change the content, I think, or something like that. Is that equivalent to a rel canonical tag? It's not equivalent, but it's very similar for us in that we know we can simplify the URLs that we find and just focus on the parts that are actually relevant. But does it play the role of aggregating any signals you have? Oh, yeah. Yeah. I have a follow-up on something you said, too. OK. By the way, I hope I sound less robotic right now. Yes, perfect. OK, great. So all it takes is a rejoin. So my question, you said that you crowd certain pages more frequent and other pages less frequent. Now, I'm asking, you know, that in the site map, you can set that thing where you say, how often it changes? Does Google simply ignore that? That's what I know. It treats it as an indication as a hint, but not as a directive. What it treats it as a directive, how it works. The change frequency, we ignore that completely. So we could, as well, just not add it in the site map. Exactly, yes. But it matters if we add the last changed one. The last check, right? Exactly. The last modification date is what we really focus on. The change frequency is something where if you set that, then we assume the last modification date will still be relevant anyway. So we will focus on the last modification date. Also, the priority is something that we ignore for web search completely. OK, thank you. So you can make site map files a little bit easier. A lot much easier. Perfect. All right, let's see. Here's a question from Jochen. If a site is using tabs and accordions to share the space between multiple content elements, does this have a negative impact on indexing and ranking the content that's not instantly visible, so only visible after selecting another tab? Yes, at the moment, what happens here is we will treat this content as being secondary, as being not a part of the primary content of a page. And you might see that effect in search. You might see that we don't use that as part of a snippet, for example, those kind of things. In the future, when we shift to mobile-first indexing, we'll probably change our stance there in that we realize you can't fit everything on a mobile page. And sometimes you have to do these tricks to try to get that content onto those pages as well. And here we go. With regards to mobile-first indexing, what does Google mean by the site's content? Does it mean navigation and link structure also store only the textual and the markup content? So for the most part, we do focus on the primary content on a page, which is kind of why people go to this page, which is mostly the textual content, the markup on the page, the visible kind of main section of the page. With regards to navigation and link structure, we do need that as well, though, because that's what gives us context of these pages within the website. We understand how these individual pages are connected. We can crawl through the website, through the navigation as well, through the internal linking structure. So that's definitely important for us, too. But essentially, those are kind of the two main aspects that we focus on. So the primary content is what we expect to be equivalent across the mobile and desktop version. And the rest, the navigation, is something that we expect to be kind of usable. It doesn't have to be the same. Usually it's a very different layout, the very different design elements, because users interact with the page very differently on a smartphone than compared to maybe a laptop or a desktop computer. But the primary content, kind of the reason why people go there, that's something we expect to be the same. Similar, if you're making AMP pages for some of these, we do expect the primary content to be the same. So not that you click on the AMP page and it has a teaser paragraph and a button on there saying, click here to see the actual content or click here to see the video. That's where we expect the primary content to be equivalent across these versions. In the nonprofit charity space, there are many organizations that operate in a federation model in different countries under the same brand name. So Red Cross, UNICEF, et cetera. And they offer similar content. In the search results, often organizations from other often larger countries will show up and rank better than the local country organization, causing increased traffic to the non-local organization. This can be problematic for fundraising activities, especially when it comes to donation tax, since it's only valid from the local country organization. Aside from general ranking improvements, steps, hreflang, and being associated with the country and search console, is there something specific that can help improve the local organization over the foreign one? So this is not something where we were making any kind of exceptional handling for these kind of sites, where we try to figure out, oh, this is a charity organization. Therefore, we will do all of our geo-targeting completely differently than we would otherwise. But essentially, all of our normal ranking factors apply to these sites as well. So the best thing here that you can really do is work to try to find a way to implement hreflang across these sites, so that we understand which one of these is relevant in which country, and that we can show them appropriately in the search results. So that's something that's obviously a bit tricky, because these sites tend to, at least as far as I know, they tend to work together. But it's not that they're one organization, so they can't easily say we will add an hreflang to a company that's not really us, but they're doing the same thing, and we want to be good friends on the internet. Sometimes that's tricky. But essentially, that's probably the best solution here of sites that are active in a space like this, that they work together, and that they realize that by working together, they can make sure that the right version of the organization shows up in the right place, and that ultimately helps all of the sites that are active in that federation or in that group of charities. But that's something where I realize that's sometimes tricky, and sometimes if we get the rankings wrong for queries like this, that's something I would definitely give us feedback on. So on the bottom of the search results, you can give us feedback with regards to queries that you think should have been better. You can also send us feedback directly, and we'll look at that as well and see do we need to make any kind of ranking adjustments anyway and say, well, maybe these sites shouldn't be treated like all other kind of international websites, and we should find a better way to handle them on our side. So if you're seeing specific queries where this is really looking bad, then I'd definitely let us know. And even if you realize that you could help out a bit with hreflang, but from a practical point of view, it's just not possible to implement that, then that's something you can definitely let us know about. I converted 90% of my site to have AMP pages, but there's a question I can't find an answer to, how to address rich snippets, so the aggregate rating schema on AMP product and article pages. I'm anxious because I'm showing aggregate rating scores and the star rating on my AMP pages, but on these AMP pages, a user can't actually rate the content because AMP doesn't support that specific functionality via JavaScript. That's a fantastic question. That's not something I've run across before, so I don't have a perfect answer for you here. One thing you could do if you wanted to take that step is to use the AMP iframe element to provide this kind of a widget on those AMP pages anyway so that people can rate that, but it's something where I don't have a perfect answer for you there. So between the AMP iframe and a link to your normal mobile pages so that users can actually rate there, those are the two options that I'd suggest there. As far as I know, the rich snippet team is not going to go out of their way to try to find AMP pages that don't provide the same rating functionality, but I also know as a user, if you go on AMP page and you realize that there's functionality that you're not seeing because you're on the AMP version, then that's really frustrating. So this is something I'll try to find a bit more about internally, but also if you start maybe a thread in the Help Forum, then that could be kind of interesting to get other people's feedback on that as well to see where we could be going or maybe other people have some tricks that can be useful there. I'm looking at images.google.com and the filters that are present after entering a search, how are those filters populated by search volume or image alt tags? I don't actually know. That's an interesting question. Yeah. I assume it's a combination of different things that we look at there with regards to trying to both understand the images that we would show there and with regards to maybe seeing how people actually interact with this, where our algorithms adjust and kind of provide different options depending on that. Image alt tags is usually something where I'd say is grouped into kind of the bigger category of understanding what this image is about, which includes things like the caption below the image, text around the image on a web page. All of that helps us to better understand what these images are about. So if you're thinking about kind of the images themselves and what we know about them, it's more than just the alt tags. Is there any risk for rankings if after a relaunch the navigation of a website isn't visible anymore? So that sounds like a really weird relaunch in that if users go to your web pages and they can't actually navigate within your content, then that might be something you'd want to work on. With regards to isn't visible anymore, of course, if we can still see the internal navigation when we crawl the page, then at least we can still kind of follow the links and go through the rest of the website. So that's something that, from my point of view, definitely still needs to be there, because if we just see the primary content and no links to any of your kind of additional context within your website, your other pages on your website, then chances are we'll start seeing those pages as being kind of islands on their own. And it'll be really hard for us to find the rest of your website and to understand how does this individual page fit into the context of your whole website, your whole kind of scheme that you're putting together there online. So that's something that I would kind of take a look at there. If it's just a matter of kind of a different UI design where maybe you're putting everything into a hamburger menu on the side or on the top somewhere, then usually that's less of an issue. That's, of course, something from a usability point of view you'd want to double check, but at least from a crawling point of view, that's usually less of an issue because we can still pick up those menus when we crawl the HTML page. We have a question about multilingual sites. How do we make sure that Googlebot index a multi-language web that auto-rejecting users based on their browser settings in the right way? So the language site can be reached via domain.com slash en or slash de. Googlebot should be getting the other language versions of the website too, not just the English ones. Is it against the terms of service or cloaking to do that auto-redirection if the request is not from a Googlebot? So you shouldn't be treating Googlebot differently than normal users. So the general theme of auto-redirecting based on browser settings or based on perceived location of the user is usually fine. Provided we and users can access the individual versions as well. So if you have, for example, your root URL on domain.com and it auto-redirects to slash en or slash de based on language or location settings, then that's something Googlebot should see, users should see. But the individual de and en versions should be reachable separately. And what you can do if you recognize that you think the user is accessing the wrong version is maybe show a banner on top and guide the user to the right version and encourage them to go to the other version as well. But you can't redirect them automatically because then Googlebot would also be redirected automatically. And that would result in that language version never being indexed in Google. So that's kind of the problem that we're facing. There's actually a really good blog post out there from our blog maybe two years back. Let me see if I can figure out the title with regards to handling these kind of auto-redirecting home pages. Just a second. All right, here we go. It's called Creating the Right Home Page for Your International Users from 2014. And it kind of goes into the topic of how to set up the hreflang markup, how to make sure that you're redirecting in a way that works for users, and that works for users as well. So that's one thing. I would definitely look into, dig up that blog post, go through that, and make sure that you're following that advice there as well. So it's not that crazy with regards to implementing something like that, but it's very easy to kind of run into a situation where Googlebot never actually sees a local language content. And suddenly, the search results snippets are in English, the titles are in English, even though users could actually go to the German version. I wanted to ask how Googlebot follows the hreflinks on an AngularJS single-page application. Is it following from a user's point of view and just fetches the changed information, or does the bot render every hreflink like it would open it in a new tab? I'm asking because we're not reloading the title and when user clicks on a new page, so the bot might not see the new title. So in a case like this, it's more like we're opening the page separately in a new tab. So when Googlebot crawls, it doesn't provide any sense of context. So it doesn't provide kind of like this session type information. Essentially, it tries to access every URL as if it were a new URL that was typed into a browser. So that's kind of what we're looking for there. So when people navigate within your website and your URL changes through like the HTML5, History API, and you don't update the title tag, then that's less of an issue on our side. As long as when we access the page directly, we do see that updated metadata as well. So that's essentially how we handle that from a Googlebot point of view. With regards to usability, it might make sense to update the title anyway because users could also see that in the title bar of their browser. So that's something where I wouldn't ignore it just because Googlebot does it in a slightly different way. At the bottom of the Knowledge Graph where it shows people also search for, when searching for a business, it shows four related businesses instead of five. Is that normal or not? I don't know how this is actually compiled from a Knowledge Graph, but it's something where if you're seeing four instead of five, then that's usually just a matter of how algorithms have put things together. So that's the thing where, from my point of view, I wouldn't worry about this. This is definitely not something that you can influence. You can't force the Knowledge Graph to point to other related businesses. And a lot of sites, they appreciate not having too many related links there as well because they want people to go to their business, of course. But that's something I wouldn't worry about there. Let's see. I just move a site in November. Most of the site's pages are increasing while the old site's pages are dropping out. However, the home page is not even close to the top 20 search results for brand terms except for the domain name with extension. What could that be? That's really hard to say because there could be lots of different things that kind of come into play there with regards to why a home page might be ranking or might not be ranking. What I would do in a case like that is maybe post in the Webmaster Help Forum and get some advice from other people or some input from other people at least with regards to what might be happening, what might not be happening there. Let's see. Can abandoned domains with penalties harm the SEO of a new website when those old domains are used to build a new website? Is there any way to check whether an old domain had received a penalty? I have a three months old website. It got listed more than 30 queries really fast and started declining in search queries. According to Search Console, currently it only gets listed for eight queries. Could this be due to a penalty received previously by this domain, or do I have to give it more time? So penalties, we call them manual actions. If there's one affecting your domain from before, then you would see that in Search Console. You would see that in the manual action section in Search Console. If there's nothing listed in the manual action section, then there is nothing manually affecting your website from a search point of view, so from our side. That doesn't mean that there's nothing otherwise affecting your website from before. So especially if you're using a domain name that was used before and has a really long and shady history, then that's something that you're kind of building on. And that's something where your website will essentially kind of have to live with that history. And that's something you might need to work on. So in particular, if you realize that the domain name that you picked has a lot of really problematic unnatural backlinks in that the previous owner was doing really crazy link schemes, then that's something that our algorithms might be picking up as well and saying, well, we don't really know how to deal with the links that are pointing to this website. We don't really know if the new links pointing to this website are similarly sneaky, and we kind of need to ignore those as well. So that's something you might want to clean up. But that's really hard to say without knowing more. In the very general situation here where you're saying you have a three months old website, it got listed for a bunch of stuff fairly quickly, but now it's kind of declining, then that could just be the normal way that new websites are handled. So in many cases, we will kind of give a website a benefit of a doubt and say, well, we think this is a new website, and we'll try to see how it performs in the search results. And if we see over time that this is the right place to show it, it's relevant for those queries, we see support from users who are linking to this site based on that, then that's something where we say, well, this was the right place. Or maybe we'll need to adjust the relevance over time based on how we see things kind of settling down. So this kind of change where you have a new website and you see fluctuations in the first couple of months, that's essentially very normal. So that's something where I wouldn't say it's always a sign of something bad that has happened to a website before. But if you're worried about this, I would definitely check out the history of the domain name to make sure that you're kind of covering all of your bases there. May I have a suggestion to you? Sure, not a question, just a suggestion. You said now and you said several times that Google sometimes is able to peak when a domain changes hand and is treated as a new domain pretty much, dropping wall signals. Would you maybe consider someday adding this to the Google console like letting a domain owner say, this is a new domain and my new owner, please drop all my signals, both bad or good, and let me start fresh. It might be useful. That's an interesting suggestion, yeah. So we've heard that a few times. I don't know if we would actually do that. On the one hand, that's something I suspect could be used by spammers as well in a weird way. And I'm pretty certain that site owners who don't really know the way around SEO that well, they might accidentally use this feature and say, oh, I moved to HTTPS, therefore I want Google to drop all of my signals and I want to start fresh on HTTPS and they will just shoot themselves in the foot in a really painful way. So that's something where we kind of have to figure out what we can do there. And if we, for example, gave Webmasters this option and we realized that they might be using it in the wrong way and we need to protect them from using it in the wrong way, then we already need to have algorithms to recognize when is it in a good way, when is it in a bad way. So we might as well just use those algorithms directly. Could we somehow hide them, like what is about tools, somewhere separate, like... Yeah, I don't know. It could be basically disavow all links. Yeah. Pretty much I'll work like that. I think you could do a lot of harm to your website if you don't really know what you're doing. So that always makes me a bit nervous. That's also part of the reason, for example, why we don't support the no index directive in robots text officially, because we realize people copy and paste robots text files and they don't understand what they're doing in the robots text file and suddenly they no index their whole website and everything is gone and they don't know what is happening. So these are things where we try to protect sites from messing up and to some extent, if we already need to interpret what they're doing, then why don't we just do it automatically so that they don't have to make this terrible decision on their side, like should I start completely fresh with my website or can I build on the past and is that more profitable for me in the long run? It's definitely something I'll bring up with the team again, because every now and then we hear issues where we think, well, this would have actually been useful if there was this reset button that the site owner could have used. I've done the same argument, hold true, as he says, for disavowing for site move. You can do a site move and change an entire domain in webmaster tools. Surely that's just as if not more damaging. But you still need to kind of do the redirect as well. So you could do a site move and say, well, I take my whole website and I redirect it all to a home page somewhere else. That's an option where you could kind of shoot yourself on the foot, but that's something where you would see that in a browser as well. So anyone accessing the old URLs would be redirected to the home page and you'd kind of see, well, this is something that's very visible. It's not just for Google kind of in the back. It's something that all users would see as well. But it's an interesting thing to kind of discuss with the team. John. He almost talks about it. It kind of goes to Google's power authority outside of SEO, because you basically ruined a property. You made it Chernobyl basically forever. Or you can't. No one can ever go back to it. But there certainly should be, for marketing purposes, business purposes, the ability to use something. I'm not saying it's your responsibility. You're only doing what you can do. And perhaps Yahoo! Haven't and Bing haven't penalized it forever. So I know you pay your money and take your choice. But I think it's an interesting discussion. Yeah. John, I'm going to jump in and ask a question if you don't mind. All right, go for it. So just the backfill on this. So a news website, it's mobile responsive. They also publish all their news stories to AMP. And they have the proper REL AMP HTML setup under canonicals on their AMP pages. But what they want to do, they want to redirect their mobile users to the AMP versions. So the question is, what will Google do if they see a REL, a link REL, with both AMP HTML and alternate? And they also see that the normal, the regular site, is actually mobile responsive also. OK. Good one, eh? That's an interesting setup. Yeah. I don't know what the best approach there would be. So you can definitely make your whole site. We call it, I think, AMP canonical, where essentially the AMP version is a canonical version. You redirect your users to the AMP version. And that's the version that we would use for indexing as well. There are a handful of sites that I've seen that use this kind of setup. But the setup where you have a normal desktop page and essentially the AMP version is the mobile version of the page, that's something you could. Theoretically do as well, where you could kind of say, treat it as the separate mobile URL kind of mobile version. You link with both REL AMP HTML and REL alternate for the mobile version to the AMP page and from the AMP page with the REL canonical back to the desktop page. So theoretically, you could do that. One thing to kind of keep in mind when you're considering this is as we shift to mobile first indexing, we would be indexing your AMP version as the primary version in a case like that. So if there is like a difference with the content, with the functionality, then we would kind of be using the AMP version as the index version. OK. And is there a conflicting signals if the site is mobile responsive? So Googlebot goes in and they see the desktop site and they see that it's mobile responsive. But at the same time, you're giving a REL alternate with a mobile URL. Is there, can you be clear on what will happen there? Or do you just take your chances? Good question. I don't have a definite answer for you there, mostly because I haven't kind of diagnosed the situation that's set up like that. But in general, if we see the REL alternate for the mobile version, we will assume that that's the mobile version. So we're not going to try to see, well, is this desktop version also kind of usable on mobile? Instead, we'll say, well, there's a REL alternate for the mobile, we'll just use that one. OK, cool. We'll test and see. Yeah, or if you have like a sample section of a site or a handful of pages like that, let me know. And I can double check on our side. OK, cool. Cool, thanks. All right. It's been mentioned that mobile site speed wouldn't be considered a ranking factor after mobile first. Does it mean that desktop site would still affect rankings? We are actually looking into figuring out a way to use the site as something where probably you'll see some changes there over time. At least at the moment where the desktop version is a canonical version, that's the one that we're focusing on with regards to speed. But that can change with the mobile first index. So kind of as suggested with the question here, I think that's something where you should be focusing on speed, regardless of whether or not Google uses that as a ranking factor, because the speed of a website, especially on mobile, has a really strong influence on how people actually engage with that website, how they convert. And there are lots of e-commerce sites that have done studies on this, where they're just introducing maybe 100 milliseconds delay, and they see a measurable impact on the conversion rate. So that's something I would certainly focus on regardless of anything that happens with the ranking factors on our side. Do I have to use the canonical tag? If I operate two websites in parallel with more or less the same content, if I'm using canonical tag, oh, this is between desktop and mobile version, yes. Well, have to is kind of, I don't know, maybe saying too much, but that's the general setup. If you have a mobile version and a desktop version, then you set up the alternate tag from the desktop pages to the mobile version. And on the mobile version, you have a canal set to the desktop version. Idea behind that is that we can focus on the desktop version and use that for indexing. If I'm using canonical tags, does this mean that my mobile websites will no longer be indexed? Yes. So the idea is actually that the mobile version is not indexed, but rather that the desktop version is indexed. But when we recognize when users are searching on a mobile phone, we will show the mobile version, because we understand this content is available in this desktop version and in this mobile version. And if someone is searching on mobile, we will show the mobile URL, and we'll rank it based on the desktop content. So it's not that the mobile URL would never be visible. It's just that we focus on the desktop version for indexing. John, I know this is jumping the gun, but when you move to a mobile-first world in terms of the index, that would imply that a lot of sites are going to have to change their setups. Is that? Our plan is that most sites don't need to do anything. So specifically, the rel canonical, those kind of things, we will see that more as a sign that you're saying these are equivalent. And we understand, well, this is the mobile version. It's the desktop version. We'll use the mobile version. And it's not that we'll require people to change their canonicals or anything crazy like that. The main things I've seen so far where people might need to make changes is, on the one hand, embedded content. If you have videos and images that you don't have on your mobile version, then obviously, we would lose those. The same is structured data. If you don't have structured data on your mobile version, then we would lose that, too. And finally, there's hreflang, where if you don't link the mobile versions as well, then we obviously lose that information, too. But for all of these, we're also looking into ways that maybe we can find a way to combine the desktop and the mobile signals to try to tide people over so that we don't have this one cutoff time, and everyone has to scramble and make their changes. But we'll definitely be providing more information as we get closer to the mobile first launch, or when we start figuring out when we actually have a fixed time plan for launching this. Because at the moment, we're just experimenting with very few URLs to see where do the problems actually lie compared to where the problems might potentially lie. OK. John, may I ask a question regarding Search Console reports? Sure. Well, I've been trying to build a tool that extracts some useful data from Search Console reports. And I'm also trying to do the same in the user interface of Search Console, but I'm getting some weird results for certain queries for certain pages. It's like it appears that there is, for instance, a query for a certain page that appears like 1,000 times a day, and the average position is 360. Is this normal? Could be somebody scraping Google Search results and causing this? I don't know, maybe. So for the most part, we do filter out those kind of queries where we recognize that they're not made by people. But it's hard to say. It sounds kind of weird that someone or so many people would bother going that far down. There's also, I guess, the matter of this being the average top position. So it might be that a lot of people see it very high and a bunch of people see it very low. So that might come into play. It could also be that maybe this is actually an image search and not a web search. And an image search is a lot easier to scroll through hundreds of results and to see an impression on something that's actually very far down in the search results. So that might also be something that you're seeing there. Yeah. Well, I don't know because a colleague told me, I don't remember, maybe it was in the previous version that it would be possible to see somehow the position where the actual clicks are appearing. Because that page, despite the average is 360, it is actually as clicked. So I don't know if it is a robot that is clicking or it is a real person. I don't know if Google is able to filter all those robot things. But for the actual clicks, is it possible somehow, at least in the current version of the search console, user interface to somehow get the position? I've never seen that. My colleague swears it's just appeared there. Yeah. You can't pull it out for individual requests. You can kind of narrow it down by picking a very small timeframe and very kind of specific filter parameters with location and maybe type of search, for example, to try to narrow down exactly what they were searching for. But you can't filter out for individual searches. Yeah. So you are saying that I am not able to get the average position when people click? When people click, I don't think so, no. I think you see the average position when it was shown. And you see, for that average position, how many people clicked, but you don't see filter away all impressions that didn't click and where they actually clicked. OK, thanks. If you kind of infer that, though, can't you, from how many clicks an average position to get, so it's an average position six versus, I mean, you're not going to tell you exactly, but that you're giving enough data to be a guide? It should be pretty close. I was trying to help you there, John, not make it more. Yeah. I guess it's really hard in a situation where you have a ton of impressions and very few clicks and you want to figure out what are people actually clicking on and why is it kind of this discrepancy. But that's, I guess that's the way Search Console is aggregating this data that's making it a little bit tricky for this specific case. Maybe you could show, I don't know, a banner on top of the landing page and ask people what they actually saw and see if some of them reply. I have one more, John. Sure. OK, it's one thing that kind of worries me. It's this new site we're launching. And we planned quite a big campaign to promote it, radio, TV, bloggers, which will presumably give us a lot of links, hopefully. Obviously, it's not a grantee, but we expect a lot of links. And now somebody warned me that this is bad because there seems to be some penalty for new sites that get a lot of backlinks right away. Is there anything like that or no such thing? So it would be OK if a brand new site starts away getting thousands of links or hundreds of links at least every week for its first weeks where it will be seen as something artificial to get the sandbox banner to tell something. For the most part, I think our algorithm should be able to deal with that perfectly. So that's kind of a normal situation where a site does a really big and fancy launch, and a lot of people talk about it. That happens, right? And if you do something really fantastic, you have a new website out, and suddenly all of the new sites are talking about it, then it's completely normal that there's this big rush of traffic and a big rush of links. And we see this big collection of signals grow very quickly. That's perfectly normal. So that's not something that I would shy away from doing a big media campaign just because you're worried about the SEO side. But you said for the most part, what's for? I mean, this is also something that we sometimes see spammy or hacked sites do. So our algorithms do have to try to figure out, is this a spammy site? Is this a hacked site that suddenly all of these links are from other hacked sites? And we have to kind of watch out for that. But for the most part, that's not the case. So presuming the links are quality links, not spammy links, it will be fine. That sounds perfect. If 5% of them are bad, then you will see, wow, this is artificial, we will penalize you. But if links are OK from variative sources, from good sites to popular sites, there should be no problem. Yeah, I mean, if you're a big brand and you do a big campaign for a new product that you're launching and you have a social website for that, it's like something else. I mean, it's completely normal that you work hard to create a big smash when you launch something that you're proud of. And then a lot of people look to it. That's something that we have to deal with. And that's something that I would say would be an error on our side if we didn't show that website fairly quickly in the search results properly. Because people are talking about it. People are linking to it. It's almost a loss if they can't find it in search. OK, thank you. And I will do, Javier, a favor. And he is asking something in the chat. He is asking, I think, for a third time, if it is OK to redirect a 404 page after some seconds. Maybe you answered him too. And I will shut up now. Yes, you can do that. Sure. Sure, Javier. So if we see a 404, then we see a 404 and we don't look at the content. So we don't look to see what is visible on your 404 pages, on your server error pages. We essentially assume that's something that the user can look at and kind of deal with. We don't follow the content on pages that return any of these error result codes. OK, thank you. And I would like to ask you another question. So my site is one site. And the URLs are built with, they are not proper URLs, but they are built with parameters. So question mark, category, whatever. But I went to Google Search Console. And if I click on the center and Fetch and render, I get what the user gets. But if I go just to Fetch as Google, the source code is 100% obligated in all these cases. So if you go to the source code, all the description of all the categories are there. So my question is, am I going to be penalized for this practice? So you're probably using a kind of a JavaScript framework to create those URLs? Yeah, so as long as Fetch and render works, then I think you should be OK. So that's something where I wouldn't really worry about it. The normal Fetch as Google is just the HTML version. So that would be normal, that we would just see the raw HTML without the content. The Fetch and render is what we would actually use for indexing. So that sounds like you're doing the right thing. Also, to kind of keep in mind, in a case like this, if you look at the Cache page after it's indexed in the search results, you'll probably also see the raw HTML. So you won't see the kind of rendered version in the Google Cache. No, no, in the Cache, it's like in the Cache, just caches the home page, so to say. It doesn't give you what the user gets. Exactly. So that's also perfectly normal. That's kind of the way that the cache is designed, which makes it a bit confusing for this specific case. But most people don't look at the Cache page anymore. And should I also add the parameter in these URL parameters in search console? You don't need to do that. OK, great. Thank you. Sure. John, do I still have time for a question regarding how Google is dealing with different languages, probably? Sure. Or not catching some black hat that may be going on. Sometimes I try to help in webmaster forums for Portuguese. And this week, a user reported some sort of, I would say, serious because it's some words that should not be related to porn, but the results are populated like three pages of results of porn sites. And the actual words are like father and daughter. But if I search them in English, no porn appears. If I search in Spanish, porn appears. If I search in French, no porn appears. So is there a reason for this? Maybe Google is not dealing with the languages correctly yet. Could be, well, I hear that Google is using artificial intelligence. The intelligence is better in English, but not in other idioms. What is the justification that you can give if you can? I don't know about the specific case. So it's hard to say. But it's sometimes normal that the search results are different in this way across different languages. Kind of like you mentioned, because our safe search classifiers, they have to understand the query. They have to understand the content. And sometimes there's this subtle mismatch where there's a lot of content like that out there, and we don't realize that probably people aren't searching for this specific kind of content, but rather they're looking for something different. So these are the type of things we're letting us know in the Webmaster Help Forum, escalating that to the guides there so that someone from Google can take a look at that. That's kind of the right approach. Also using the feedback on the bottom of the search results page, that's really useful for us, too, to kind of let us know that, oh, you were really surprised to see these kind of bad search results for a query that's not really that problematic. What actually happened, that there was some news in the local newspapers that Google was, I think, the word was step doctors. And somebody had written an article and well-known newspaper, online newspaper. And after a while, it seems Google sort it out for that specific word. But for father and daughter, it's still there. And actually, I recommended that to use the report forums and hopefully the guide will look at that. My question is more like, could it be that Google is not getting the black hat schemes that, because most of those porn sites, we know that it's terrible. Could be that Google is not yet catching very well those whatever schemes they use to position tens of sites ahead of real search results for those words. I assume it's not so much a matter of like black hat SEO, but more just a matter of us understanding the queries. So I think the general thing to keep in mind is we see tons of queries for the first time every day. So I think it's something like 10% or 15% of the queries are new to us every day. So we can't classify all of the known queries and say, well, for this query, we expect these kind of results. For this query, we expect those kind of results. And it's completely normal that some queries that we have maybe analyzed manually show results that are kind of weird. And those are failures on our side where I'd say our algorithms should be doing a better job of understanding that query, even though nobody has manually ever looked at that. But it's not the case that I would say this is because people are doing black hat SEO and they're getting away with it and they're able to rank for random queries like that. I'd see that more failure on our side with regards to understanding the query, understanding the relevance of this query with regards to what people are actually searching for. You mentioned these report tools. How are they handled? Someone look at every report manually. We have to really 100 or 1,000 people to report the same thing to be checked. It is checked algorithmically, or how it works. It differs. So it's something where obviously if we see a lot of reports for the same issues, then that becomes more visible for us so that we can actually take a look at that. But there are different teams that are handling these reports. And some teams like to take a sample of the reports. Others take a look at the most reported issues. There is a variation between manual and algorithmic ways to kind of look at this. What doesn't happen on our side is that we take all of these reports and say, oh, so many reports for this issue. Therefore, we'll automatically take action on that without anyone taking a look at that. Because we realize that sometimes a lot of people report something, but just because they're all reporting, it doesn't mean that it's actually a problem. So that's kind of the one situation that we kind of try to guard against. But the way that people actually review it on our side, it really differs quite a bit. So basically, it is looked by a human person if enough people report it. When enough people differ from case to case. Most cases, yeah, in most cases. And I think it also depends on where people are reporting and what kind of content people are reporting. So if you're reporting, I don't know, a problematic forum post in one of our help forums, then that's probably handled differently. No, it's just such results. Yeah. Or individual results in, for example, if you go to Image Search and report individual URLs, then that's something that's probably handled differently compared to going to the bottom of the search results page and clicking the generic feed format and saying, I don't like any of these search results. And so that's something where we try to take the right action based on the information we have. And we try to do that in an efficient way in that we're not chasing all of millions of individual reports where people are saying, I don't like this site. I like this site better. Therefore, you should swap the ranking or something like that. So that's a managed report? Oh, there's so many reports. It's crazy. So I've looked into some of those feedback queues. And there's so many people that either don't understand how the feedback feature works in that they assume maybe there's another person that will answer their queries directly or that report all kinds of crazy stuff. It's interesting, an interesting look into human psychology, I think. OK, thank you. Yeah. I have another question, Shuri. So like my site is built now, so domain slash category. But all the subcategories are also like domain slash subcategory 1, subcategory 2. So is that a structure OK? Or would it be better to have all the subcategories within a category folder? That structure should be OK. That sounds perfectly fine. I wouldn't worry about that. The main thing I would do with the URL structure is to find a structure that you can live with in the long run. So find something that you know will definitely work for the next five years, maybe the next 10 years, that you can build on from there. Because every time you have to change your internal URL structure, it's really a kind of hassle on our side in search because we have to understand your website new again. So finding a structure that works for you for the next five years is what I would look at more rather than what structure is currently in vogue along the SEOs. OK, and just last question. So when a product is virus, is it better to just leave the page with a warning message like this product is no longer available? Might take a look at these other products, similar products? Or is it better to redirect it to the category page solution? I would try to provide a 404 page, something like a 404 page for individual products that are no longer available. That could be something specific to that product where you can say, well, here's the existing product information that we have, maybe the manuals or support links as well. And just provide that to the user and that can remain indexed. Or if you say, this product is really gone and I have nothing to show in its place, then I would show a 404 page and maybe list some other products that are similar on that page. By redirecting to the category page, you're kind of confusing the user because they clicked on a link to go to that specific product and then they landed on a category which doesn't list that product. So it's a weird situation. And our algorithms look at that and they think, oh, probably this webmaster just meant a 404. And then we'll treat it as a 404 anyway. OK. And I was also discussing with the guys, like I don't have a CMS now, so we do it like pure HTML code. But we don't have a sitemap. I'm trying to be it. Do you guys have any insight on the tools that I can use to automatize like a satnav? I think we have or had a list of different sitemap tools out there, but sitemaps is such a standard format in the meantime that tons of tools support that. So that's something where I'm pretty sure that there are easy ways to get support for that. Yeah, and even though they also update the URL also They should. Yes. That's kind of what I would expect from a sitemap tool. So especially if you work, if you use a plug-in for CMS, for an e-commerce site, for a blog, then that should update automatically. Because that's what sitemaps are for. To tell us as quickly as possible, this page changed. This one is new, that one is gone. We've finished that since I don't have a CMS. That's the problem. Yeah. OK. I need more manual work for you. OK. Thank you. All right. We've kind of taken a lot of time. So I appreciate all of your questions, all of your comments. And I hope we can set something up for the future again. So I have a little. Something as well. I had a Google alert, but it had a virus in it. So it was picking up something that already had a virus on the page. Should I forward that to you? Sure. Not the virus, but the link. Yeah, I didn't know if there's any way to do that, because it was a PDF, this PDF virus that's been going around. And you picked up Google alert for something. Yeah. All right. I mean, this is also kind of why we have the browser warnings there, so that when something makes it into one of these links and emails somewhere, that at least when you try to click on it, it gets flagged. But I'm happy to take a look and pass it on to the alerts team to see if they can fix that. Thank you for hosting us, John. Thank you for coming. It's been great having you. Always good to see some new faces here as well and some old faces. So I'll definitely be setting up the next round of Hangouts. And maybe we'll see you again in one of those. Thanks again, and have a great weekend, everyone. Thanks, John. Bye. Bye. Thank you.