 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 are these Webmaster Office Hours Hangouts, where we chat with webmasters and publishers to try to answer any questions that they might have around search. As always, if there are any newer people here or who haven't been in this Hangout regularly that want to start off with a question, feel free to jump on it now. Or if not, then you can. OK, I can ask a question. All right, go for it. So some time ago, when I think it was in Brighton when Gary went to the conference, I had submitted the question for Jenny and about the move of HTTP to HTTPS and how Google sees this move. I ask this because in the past, I'm not sure if it was you who posted that Google doesn't see this really as a site move, like a domain move. It's not that heavy. But this is just at the protocol level. It would be something lighter. And I would like to clear that up because to my understanding, it's part of the URL. So in one sense, would it be as heavy as a structural move, like a site move or a domain move, or it's something much lighter that doesn't have so much weight? So I guess, whoa, robots are somewhere. So in general, a move just to HTTPS is a lot easier for us to process because it's the same domain and same URLs and everything. So if we can recognize that it's just shifting over to HTTPS, it's a lot easier for us to just say, well, OK, this looks good. We can move forward fairly quickly with that. Whereas if you restructure a website and you change all of the internal linking, if you change a domain name, then all of that kind of means we have to think about a lot more than just switching to HTTPS. So it makes it a little bit easier, but it's still a pretty big change on a website. If you're changing a bigger website to new URLs, so it's not something where I'd say it's just like a switch you can flip and then everything is OK, it does take a bit of time to be processed. So most of the ones that I've seen recently, they're pretty much instantly, so within a day or so, that we switch over. But sometimes it can run into a situation where things are a bit more complicated. All right, thank you. All right, Tiago, let me just mute you, but feel free to unmute if you have a question in between. There's a bit of noise in the background. All right, anyone want to start off with a question? Otherwise, I will. Yeah. John, I got a couple about URL parameters. So first question is, does Google parse the parameters for any context about a page, be it language or country or product name or size or anything? Or is it just a matter of defining how it affects the page and then Google will parse the content and see what it's about? We do try to pick up some words from the URL if we can find anything useful there. But that's a fairly small thing for us compared to things like the content on the page itself. The one thing we do sometimes pick up from a URL is if there are country or language codes that we think are relevant. So especially if we can tell that, oh, this one has EN and the other one has DE, then maybe this is like the German version and this is the English version of that page. But that's something that you can also control normally with normal hreflang markup. Great, so if there would be a conflict between, let's say, the parameter and the content or the hreflang does hreflang take precedence over everything? Or how does that work? Yeah, so it's kind of tricky in that we don't have kind of an order of precedence for these type of things. And in a lot of cases, it's not the situation that we have any conflicting information there. So I don't remember any case where we'd have a URL that has slash DE and a comparative one that has slash EN in it where German and English are switched. So that's something where I don't recall any situation where we've seen kind of this conflict of signaling. But I believe hreflang would take over if we see something else from the URL. OK, so to be clear, is that also applied to query strings and parameters? Or is it just the directory structure? That can be directory structure or query parameters. OK, sorry, one last thing here. If a parameter is only applied to a specific site section, should we define it for just that site section or the website overall? So let's say directory A, the parameter does nothing and directory B, it specifies or it translates. Should we define it for the site overall or should we break that down? That's kind of up to you. So personally, I try to keep it at a site level if possible. It just makes it easier for maintenance. The tricky part is if you have conflicting information on a site level where you have one section where you say this parameter is irrelevant, the other in the same parameter is actually very important, then for that case, you'd want to split it up into separate sections in Search Console. But as much as possible, I try to just keep things simple and make it so that you can maintain it easier going forward. So for example, if you move to a different domain name, will you remember to check all of those separate sections that you have verified to see if you have individual settings there that you don't have on a site level? That's something that easily gets lost. Fantastic. Thank you very much. All right. Let's see what we have here. My question is the following. How to properly handle unavailable duplicate content? No, we're just talking about duplicate content. I'm talking about job posting content or job descriptions. Lots of employers have multiple vacancies in different locations. The vacancies themselves have identical descriptions. So effectively, they'll be identified as duplicate content. So what's the best way to avoid that, essentially? So that's a good question. I think we have in different variations all the time. For example, if you have products, you might have the same kind of product in different variations where you say, I need to have separate pages for this content. And then a big part of the description will be the same across these individual detail pages. And for us, that's essentially fine. That's something we can deal with. We've learned to deal with this kind of duplicate content on the web for a really long time. What will generally happen from a practical point of view here is not that we would penalize these websites, but rather we pick up that these pages are actually unique pages. We'd index them all separately. And if someone is searching for a piece of the content that's duplicated across these pages, we'll pick one of these pages and try to show it in the search results. Whereas if someone is searching in a way that we think that maybe they're looking for part of this duplicated content and something unique that's kind of relevant to that page, then we try to pick the more specific version that we can pick up. So in your case, if you have jobs in different locations and you see someone, I don't know, searching for, I don't know, PHP programmer, and you have multiple PHP programmer jobs that you have available, then we might pick one of those and show that in the search results. Whereas if someone is saying, I'm looking for a job as a PHP programmer in Boston, then we might say, well, here's this page generally about PHP programmers and it's located in Boston. So that will be a good match for that specific query. So from that point of view, it's not something you need to hide from Google in a technical way or anything. That's completely normal to have this kind of duplicate content out there. The thing that I would avoid is to have multiple pages for the exact same thing. So if you're looking for five PHP programmers in Boston, then putting five listings for that same role probably doesn't make sense because we just start crawling and indexing all of those variations and we'd be kind of confused which one should we actually be showing. So for that, I just have one page for PHP programmers in Boston. And if you have PHP programmers in different locations with the same role description, that's perfectly fine. According to the SEMrush data for our website, justanswer.com was presented as a featured snippet for thousands of keywords. But at some point, they all disappeared. We still rank for these keywords the same. Our domain authority did not decrease. No changes were made on our end either. What's up with that? So featured snippets, like most elements in search, are completely algorithmic search elements that we use to show some sites in the search results. And it's not the case that there's a meta tag that you have to put on your page to prevent these from showing up or to force these to show up. And it's not the case that if we show one site there, that we'll always show the site there. So this is something that algorithmically changes all the time. Let me just correct one thing there. There is one meta tag that you can use to prevent your page from showing up there that would be the no snippet tag. But that's kind of a big hammer and probably the opposite of what you're trying to do there. So from that point of view, this is something where it can be completely normal that a site is shown with featured snippets at some point and isn't shown for featured snippets at a point in the future. I think someone else did a study a while back saying these featured snippets tend to change fairly quickly. So perhaps that's something that's happening there as well. Some mini AMP questions. We have five desktop pages, each on their own URL with a matching canonical. They have content about different areas of one product, for example, overview, specifications, accessories. They kind of look like tabs. If we were to create an AMP page that merges all five desktop pages into one AMP page, what would the canonical link be? So I think first of all, the thing to keep in mind here is that the AMP page should be equivalent to the desktop page. So if you're merging five desktop pages into one AMP page, then that's not the situation where you kind of have this equivalent, one desktop page, one AMP page. You essentially have multiple desktop pages and one AMP page. And similarly, if you take one long desktop page and split that up into multiple AMP pages, that also wouldn't be equivalent. Or if you take one long desktop page and you just provide a teaser in the AMP page, then that also wouldn't be equivalent. So those are all situations where kind of that link, one desktop page, one AMP page, doesn't actually make sense. And you might want to reconsider how else you can provide this in a way where you can have a clean mapping of one desktop page to one AMP page, or perhaps even where you can say, well, I can put all of this on an AMP version and show that on desktop just as well. Maybe I should make my AMP page the canonical version instead of having a separate desktop page for that kind of content. So that said, kind of going through your questions, I assume a lot of these will be, no, let's see. What would the canonical and the AMP HTML links be, like I mentioned in this case, that wouldn't actually be the proper use of an AMP page for a desktop page? Would each tab have its own canonical if they were on separate URLs? Yes. So if you had separate AMP pages for like five separate AMP pages for those five separate desktop pages, each of those would have a one-to-one link between the AMP and the canonical desktop page, kind of having the equivalents there. Would this count as content mismatch? Yes. Theoretically, that would be a content mismatch if you have five desktop pages combined into one AMP or the other way around. Or kind of the teaser setup, which is more common actually, that would be content mismatch type situation. We had that in the past with apps, for example, as well. So with app indexing, if your app content didn't match the web page content, then we would also flag that as a content mismatch. I think it was a bit trickier with apps because they tend to have very different UIs. But with AMP, essentially, the primary content, if that's equivalent or not, that's kind of expected, I think, from a user point of view. Can Googlebot see AMP-tabbed AMP content? So if this content is on the AMP page, then that's something we would see there. Is there a way to bulk validate AMP pages? I believe there is a validator that you can run from the command line. So you could use that to kind of automate your testing of your AMP pages within whatever pipeline or setup that you have to publish your content. So lots of kind of unique questions. But I think that the general theme is really the AMP page should have a clear equivalent desktop page. And the functionality and the content should really be equivalent there. And the same applies for separate mobile URLs as well. So if you have a separate mobile URL and a desktop URL for that, then that should also be equivalent. It should be the same content, same functionality, from desktop to mobile. That's even more important as we switch over to mobile-first indexing, where we actually use a mobile version for indexing. So if your mobile version has less content than your desktop version, then we'd index less content, which might not be what you want. John, what's that happening, the mobile-first index? Any update? When's that happening? We're working on it. We don't have any date to know. I've been testing it in the wild or not yet. We've been testing lots of things, yeah. So this is yes, of course. I mean, internet is pretty wild. But it's one of those things where we have to make sure that the changes we make actually work out well. And we're creating some classifiers internally to make sure that the mobile page is actually equivalent to the desktop page, and that sites don't see any negative effects from that switch. And those are things we need to test with real content. We can't just make up pages and say, well, this is kind of like a normal web page. We really have to see what happens when you run it with real content. So those tests, we won't be able to see live, right? I mean, those are like behind the blinds back in. I don't know if people would see that live. I think at some point, there might be aspects that are more visible. But like with a lot of search experiments, these are things that, for the most part, people don't notice. Because in an ideal world, it should just kind of work out the same. OK. In terms of the rollout, can you describe what you're planning? It looks like, so you're adding this signal to define these pages are equivalent, like these mobile pages are equivalent to their counter desktop pages. And you're kind of tagging these pages across the web to say, all right, this batch of pages will probably be good to go live on the first rollout. And then you're maybe saying, these are somewhat similar, maybe 80% similar, or is that what you're kind of doing? Yeah. So that's kind of what we're looking at there is to do this more in a step-by-step way, rather than to just switch it on and everything breaks. But to kind of do this gradually. And the idea behind this classifier is also so that we can recognize common problems, that we can do some blog posts around those common problems so that people are aware of what they should be watching out for, what they should be fixing, what kind of issues they should be looking at. Some of the sites that we see that are particularly problematic, we might contact them directly. Some of them we might send Search Console messages out to, it really kind of depends a bit on what all we see there. And for that, it's something we have to take a look at the live web to figure that out. Right. So I suspect if I, based on the history of Google, when they do these types of rollouts, that you probably will be hopefully categorizing certain sites and pages and saying, here's a Search Console notification saying, you guys need to do X, Y, and Z to get ready for it. And you have potentially X time, X amount of months weeks or whatever to do that. So that's what you probably plan on doing without announcing anything. Yeah. That's currently what we're looking at. And it's sometimes I realize these changes are not easy to make. So we want to have sufficient time where we can say, well, we don't want to force everyone to kind of revamp their website within like a couple of weeks that wouldn't be reasonable. Wouldn't help anyone to kind of push it along like that. So we want to make sure that we have sufficient time to actually do this and that people are notified ahead of time so that they can make any changes that they would need to make for that. OK, cool. I'm actually looking to, I'm keeping some sites in m.format, some sites in dynamic serve format, and some sites in response format just to see what happens. All right. Good. No, I mean, it'll be interesting to see what becomes more visible for us. So we'll see. All right. A question about URL parameters. I think we looked at this before. If a site is a comparison search engine for health services covering thousands of treatments times thousands of destinations, our search results are typically content rich, multiple clinics with descriptions, some smaller, less popular destinations however, have no more than one or two listed clinics per page. Here's an extreme example. Can having a few thousands of pages of this type actually harm a site's overall rankings? Or is it only when a warning is received in Search Console that an action should be taken? So I don't know what specifically is on this page. But I think, in general, you should kind of keep in mind that the content that you publish and make available for indexing is the content that we think your website is about. So if the majority of your website's content is kind of thin, lower quality, auto-generated, where it's just names and addresses from a database, then that's probably not so high quality overall. On the other hand, if this is a rare kind of occasional situation that you run across where you have these type of pages, then that's probably less of an issue. But I think the fact that you're already asking about this means you're watching out for this and trying to avoid the situation where this gains the overhand. So that's something where I think you're probably on the right step there. The one thing I recommend watching out for is empty search results pages. That's something that we've seen in the past is really frustrating for users in that they go to a page where they think, oh, this is specific type of doctor in this specific location. And actually, the page that's on your site says, oh, we couldn't find any entries in our database. And that's really frustrating. So that's the type of page I just make sure you have a no index on. And anything else is kind of up to your discretion with regards to what you want to have indexed, what you don't want to have indexed, how you want to kind of treat that. I know some bigger sites that have these kind of databases behind them, they watch their analytics, for example, and see which type of pages get no clicks, which is kind of a signal that this is probably not such an interesting or important page. And I've seen some sites have success by no indexing those kind of pages or by looking at those kind of pages and thinking about how could you roll that up into maybe a next higher category. So if you're doing this on a per city basis and you have one entry, maybe it makes sense to do it on a regional basis for that kind of area. So those are all options that are kind of available to you. And I think you're probably already on the right track if you're looking at this from that point of view. All right. Our e-commerce client is interested in creating AMP experience for speedier pages. However, they've been reading more into progressive web apps lately. Naturally, they're left with options from your opinion, which deserves the most consideration or is the best to strike a balance, given that AMP doesn't handle money transactions too well. I don't know. I don't know what I could say is the right approach. I think it really depends a bit on the website and what elements that you need at the moment. And there might be kind of a combined approach that you can do as well. I know some of the people here have been working on a setup called PWAMP, where you combine a PWA with AMP content and you kind of have the best of both worlds. So that might be an option to look into. Another idea might be to say, well, we'll use AMP for the type of pages that we know we can make really well on AMP at the moment and then use the traditional setup for the other types of pages that you need to do in a different way. So if for transactions specifically, you can't do that on AMP at the moment, or if it's not easy to do on AMP at the moment with the setup that you otherwise have, then maybe it makes sense to keep those in your normal setup and maybe you can move your blog or your news articles or your category pages or something else to AMP where you actually do see some gains as well. So if you see people searching for this content, landing on the AMP pages, and then going to the rest of your website, then that's a gain as well. So there's no situation where I'd say you always need to do PWA or you always need to do AMP. You really kind of have to look at your specific setup and the resources you have available, what your developers are comfortable with, where you think things are headed with your website, with your business in general, and act based on that. Product page content, duplicate across sites, some ranking some not. What would you suggest? Not ranking websites because we tried unique-like reviews, but they really help us rank for duplicate content related queries. Not really sure how you mean that there. I think you're here in the Hangout as well, right? Or you were? I don't know. So in general, if you have product pages and you're duplicating them across different websites, what I would recommend doing there is if it's really exactly the same product, I would pick one of these websites as the canonical for that specific type of product and set the rel canonical to that specific page. So for example, if you have a website for garden furniture and you have one website for, I don't know, outdoor furniture and you have a chair that clearly fits more into one or the other categories, then I would put that as a canonical on that specific website. But what happened then is we'll index that page and try to index it as that chosen canonical. And you can still have it on both of your web pages. So if someone goes to the other website and searches within that website for that specific item, they'll still be able to find it. It's just in search, we'd be able to focus on one version of that. So that's end doing there. Then you also don't run into a situation where it kind of looks like a doorway site where you're copying the same content across a whole bunch of different sites. Hello. Hi. Yeah, John. I am here. Actually, this question was regarding one website or one product page where all our competitors have the same content. So in such case, because that product is about everything that we are adding and everybody can add, so in such case, how to ensure that for important queries related to this page we should focus on or we should be working on? You can't force your site to show up, number one, for those kind of queries if you have the same content as other sites do. So in practice, what would happen there is we would pick one of these sites and show it for generic queries around that product. If it's really the same thing across those sites. So one thing that a lot of people do is they say, well, I don't mind if it's duplicate where you can say, well, I have to use the same description or for practical reasons I have to use the same description. And then your site will rank for things that are more specific. So for instance, if someone is searching for a chair and location and your website is for furniture from that location, then that might be a good match. The other approach that people do is that they just write their own unique descriptions and make sure that the content on their pages is actually not the same as everyone else has. So those are kind of the two approaches that people tend to take. Since we're in the content area, does grammar affect SEO? I don't remember from like 300 Hangouts here that anyone asked that. Not really. So it's more a matter of how it's received from a user point of view. If you're a banking website and you have terrible English on it, then I assume users will kind of lose their trust in your website because the website doesn't know how to spell. So it's like, what can I do there? But for other things, it's something the way the web just comes. So especially user-generated content, you can't fix their grammar or you probably could, but it's kind of impractical to do that. So that's kind of what it comes. It's majorly it's an issue. But if it's soft to very minor, then it's not an issue, right? Like a couple or something? I don't know of any of our algorithms that specifically look for the grammar and say this website uses English in a bad way, we will demote it. I don't know of anyone. I mean, it's possible. But it feels really kind of niche. And the type of situation where we say, well, maybe we pick up lower quality content in other ways rather than just looking to check the grammar. Because also, obviously, something like grammar is really hard to do across the internet where there's so many different languages and so many different variations of languages, we can't possibly check Swiss German websites for grammar. It's usually too weird. But for instance, if a bank had a very important page and they just wanted to go images on that actual page, and then maybe in terms of content, maybe 25 words. So that page is definitely low quality content. Those are pages that you don't want to see. I don't know if it's low quality content, just because it doesn't have a lot of words on it. It can be just as high quality even if it doesn't have a lot of words on it. So I definitely avoid the situation where you're just counting words for the sake of counting words. But rather, think about what is the goal of this page and does this page currently fulfill that goal? Is that something that matches the user's expectations when they search for something where you'd like to have this page shown? Yeah, if it's a user or a friend, yeah. If it's something that. OK. So for example, a login page. It's basically like I want to log into my online savings account and it's like bank name, username, password. And that's about it. But that's the page you want. You don't want some random blog that has 500 words about your bank's login page. Right, right. Jug, I follow up on a question from a couple of weeks ago regarding what Google will index first when it comes to the mobile first indexing. So if you have an AMP page, a responsive page, which will Google index? An AMP page and a responsive page. So you mean the situation where you have a normal responsive website and an AMP page associated to that? Let me just double check. So Google indexes the AMP version of the mobile page with no regular mobile page. OK, so you said, don't worry you don't have a desktop site, but if you don't have a mobile site, you don't have a mobile page. But you have an AMP version. Will Google index the AMP version or the desktop version? We'll index the desktop version, because unless you're setting it up with AMP as both real AMP HTML and real alternate for the mobile setup, kind of like you can theoretically set it up with the AMP version as the separate mobile URL version of the desktop page. Right. But otherwise, if you don't have that set up, if you just have the real AMP HTML, then we would take the normal desktop page, because that's the canonical page, essentially. And that's how it will happen with the mobile first index. You guys decided. OK, thank you. I think it's a kind of a theoretical situation, because you don't actually have anything available on mobile yet. I'm trying to find new stuff to write about. So I've got to go theoretical right now. Oh, come on. Oh, no. What did I get myself into this time? Drats, should have said no comment. But you did say, one hangout, you said that if this whole thing doesn't work out, you guys will switch back to desktop and mobile. Oh, I mean, that's like always the case. When we're experimenting, if we see that the experiment doesn't work out, we will figure out a different way to move forward. So it's not the case that we're looking for things to go wrong and hope we can roll it back and take everything back to 1999. It's more the case that we're kind of always experimenting and trying new things out. And some of those will work out. Some of those will stick around. And some of those will notice don't make that much sense, and we have to move on. Sometimes moving on is something that people don't really notice. So if we do UI tests, then a lot of times we will tweak some pixels, and everyone will go crazy for a while. And then they'll get used to it. And then we notice, oh, it doesn't actually make sense like this. And we'll tweak the pixels back or in a different way. And that's less visible. But sometimes it's also more visible, like if we decide to turn off some kind of structured data or the authorship stuff, where I'm sure everyone still has open wounds about. But these things happen. At some point, you have to make a decision and cut things off and say, it didn't work out the way we expected, or maybe it worked for a while and things have moved on on the web. We have to make changes again. I think that's an important part of being online, where you can make these changes immediately. You don't have to wait for new marketing material to be printed for you to change your logo color. You can test that out quickly online with a small portion of users. And if it works out, go down that direction. If it doesn't work out, try something else. Wow. So yeah, let's wait and see again. We'll see. I'm pretty confident that this kind of works out. So it's more a matter of how we tweak the actual specifics. All right, another question here. All the pages like H1, page URL, title, anchor text, alt attribute that give reference to pages content are included in ranking factors. Can we expect to optimize them for better ranking if some are optimized but others are not? So these are all essentially part of your on-page SEO, as you could call it. This is content that you're providing to users and content that search engines see as well. So these are all things you can definitely look at and see what makes sense to optimize with regards to both ranking, usability, and kind of also how people see your site in the search results. So if you change your title, for example, that's something people might notice in the search results. And even if it doesn't change anything from your ranking, it might be that more users click on it because they think, oh, this page is actually about what I was looking for. And it's clear because it says so in the title. Therefore, maybe I'll go to this page, even though it's like halfway down on the search results. So it doesn't necessarily have to change your ranking in order for you to have an advantage out of that. Are ranking factors different for different category queries? For example, for e-commerce and flight and some others, I'd say ranking factors are different for all kinds of things. So it's not just that we'd say e-commerce or not, but essentially this is very dynamic, which is why we don't have that top three ranking factors list because it really depends on a lot of different things. And sometimes this is more important. Sometimes that is more important. Depends on the time, the queries, the users, personalization, location. All of that kind of flows into figuring out which of these factors are more important than others. Are you guys ever going to confirm any algorithm updates in the future back in the days, like MacCons used to be like, yeah, we did an update. It affected 1.3% of search queries. MacCons retired, you guys stopped doing that. Yeah, we should just keep asking Matt. Maybe he knows. No, I'm not saying that. I mean, obviously, Matt said, you guys are being over it. I suspect we will. I think there are some algorithms that definitely make sense to highlight to webmasters. There are a lot of things, at least recently, where when I look at what has actually been happening on our side, we're basically just trying to improve the quality and the relevance of the search results. And there's not really anything specific that a website should be doing to change that. But especially when it comes to algorithmic changes where there is something that a webmaster can do to help improve their site, then that's something we definitely want to highlight. So I expect us to at least have some algorithms that we know. I think because we make so many algorithmic changes all the time, it's hard for us to announce all of them. But some of them we will definitely try to announce. And I think that also helps webmasters to figure out what they could be doing differently. Do you see that happening at any time soon, or probably you have no idea? It really depends on what's changing. So the mobile first indexing stuff is definitely something we want to talk about when we get closer. Similar changes where, I don't know, if we had something that affected speed, we would love to talk about that because that's something you can actually work on on your website. And if you improve things in that regard, that could help your ranking and that could help your users as well. So that's kind of like everyone wins out of talking about that. What about the spam side or the quality side? From the quality side, I think it might depend. I don't know. The spammy side is probably almost easier because that's something where we can actually say, well, this is kind of an abusive thing that we've seen in the past, which is kind of problematic. And if you've been doing it or if your previous SEO has been doing it for your website, then that's something you might want to clean up. And here's how to do that. I think that's kind of a natural match there. In my niche, earning natural links is really hard. So how can you do that? I think the good thing here is we do use so many different factors in our crawling indexing and ranking algorithms that sometimes you can do really well without a lot of links. So Gary was recently, I think, in Norway. And he mentioned there were some sites that were ranking for really competitive terms with essentially no links at all or maybe one or two links. So it's not the case that you have to work to get the same amount of links as something like Amazon would have in order to be competitive in your niche. Sometimes even small things can help there. So if you're a small business, things like getting listed in your local Chamber of Commerce can be really useful. On the one hand, it's a link to your website that we might be able to pick up. On the other hand, it's something where users will be able to find your website as well. And the other thing to keep in mind is if in your niche it's really hard to get links, then it's the same for everyone else who's active in your niche. It's not the case that other people are saying, oh, well, I can get tons of links. And other people working on the same kind of niche, the same kind of audience say, I can't get any links because you're kind of in the same area, right? So it's not the case that you have to compete with someone really gigantic in a completely different niche. In your niche, it might be very different. And I was going to say something else, but I totally forgot what it was. But it's something, in general, I'd say you can do a lot of things as well in other ways. So like I mentioned in the beginning, we have so many different factors when it comes to crawling indexing and ranking that you don't have to do exactly the same thing as your competitors do as well. So even if your competitors have found a way to get some links and you can't get any links at all, then maybe there are other things that you can do to kind of average that out. So it's not the case that we'd say everyone has to get this amount of links in order to rank here, it might be that this site has some links and this site has some other great stuff and this site has some really good content. And all of these things, we have to compare somehow and show them in the search results. And especially in smaller niches, sometimes just having really good content does make a big difference. Let's see. There's some, I think, comments. What things are you looking forward to determine if mobile first indexing works or is successful? So in general, one of the things as a bigger kind of theme that we're looking for is that we don't miss much information or any information. So if we can get the same content from the mobile version of the page, the same metadata, images, structured data, all of that, then that's kind of a good thing. One surprising thing, for example, that we noticed is that it's actually a lot easier for us to get videos for indexing from mobile pages because they tend to be in a clean HTML5 format compared to some kind of complicated desktop-based web player that uses weird scripts and a kind of a complicated setup to actually deliver the content. So some of these things are actually a little bit easier on mobile. Let's see. Can you share specific metrics that Google is looking at to assess page speed, time to first fight, DOM interactive, download, time to last fight? I don't know if we're using any of that at the moment. So for us at the moment, we're mostly looking at the desktop page and comparing the overall loading time of the page and seeing if that's kind of within a reasonable range and trying to split off pages that are really way outliers with regards to speed. So if you're tweaking things like time to first fight and you're able to get that down by a couple hundred milliseconds, then I think that's fantastic. But it's probably not something that we would pick up for ranking, at least not at the moment. I think that's something where you'd probably see a much stronger secondary effect with regards to what users actually do on your website. So if they go to your site and your site is really snappy and fast, then they're probably more likely to browse around on your site, probably more likely to convert to whatever it is that you're providing to them. And that's a really big factor as well. So it's not just ranking that's important. It's actually that once people are on your website, that they're actually able to convert. Because without conversion, all ranking is kind of useless. It doesn't matter if you rank number one, or if you can't get people to actually buy what you're trying to sell. Is there some way to report sites directly to someone which follow blockhead methods to influence the rankings, tried reporting some of them in the webmaster tools, but things aren't changing. It's been almost more than a month. You're welcome to pass these on to me. Maybe send me a note on Google+. I can take a look at that as well. For a lot of the ones that I've seen recently, the main thing that has kind of come across there from my point of view is that we do actually ignore a lot of the kind of blackout methods on a lot of these pages. But there's actually surprising, or maybe not surprising, a lot of good stuff on those pages as well. So for example, what we sometimes see are small business pages that have a lot of hidden text on them. And they probably set this up at some point. Maybe when it worked or set up from some SEO who was following some SEO blog at the time that said, putting hidden text on your pages is a good thing. Google will think it's more relevant. And just because you have this kind of hidden text on the page, which from our point of view would be against the webmaster guidelines, probably doesn't make sense to throw that side out completely just because they're following this kind of old advice. So what our algorithms usually do in a case like that is they try to recognize that and say, well, there's hidden text on here. But I can ignore the hidden part and focus on the visible part of the page. So similarly, if there are other kind of spammy aspects where our algorithms can tell that this is kind of spammy this part of the site or this part of the page, then if we can ignore that and focus on the rest of the content, which might be actually kind of reasonable, I think that's kind of a good approach to take. So that's something where if you report a lot of things to us where you're saying, well, my competitor is doing this spammy thing. And I look at it and see that actually that spammy thing is being ignored and they're ranking for other reasons, then there's nothing really that I'd need to do there. It's already being handled properly by the algorithms themselves. Let's see. There's some question. I'm not clear if to make my AMP page discoverable, I need to put in the AMP HTML tag, the origin URL of the AMP page of this ADN AMP UI. If not, how shall we use the CDN for AMP pages as they're not crawlable? This probably refers to something else that you submitted. Let me double check. OK, I saw Google release an AMP cache, so it's possible to link AMP content directly. When we have a desktop version of a page and with the rel AMP HTML, should it link to the AMP page hosted on your website or the AMP cache? So with the rel AMP HTML, you would link to your local AMP version. So if you host your AMP pages on like a slash AMP sub-directory or with a parameter question mark AMP or any other kind of URL on your side, that's the URL that you should specify as the rel AMP HTML. And that's the one we will take. And when we recognize this connection between your desktop page and the AMP page that you're hosting, then we'll take that AMP page and host it on the CDN for AMP so that we can serve it quickly. So that's something where you theoretically don't really need to worry about the CDN at all. You host the AMP page on your site normally. We'll try to pick that up with that connection between the desktop page and put that on the CDN automatically. I can a new site with exact copied content from another site to rank to the top because I've seen some ranking in the top three positions with exactly the same content. I don't know, theoretically. This could happen. So sometimes, I guess a lot of times we are able to pick up things that are duplicate content and recognize that appropriately. And treat that appropriately in the search results, which means, for the most part, we will index both of these versions. And if someone is searching for something generic that's on both of these pages, and we can recognize that text is actually the same, we'll pick one of those and show that in the search results. And sometimes, if we have exactly the same content on both of these pages, we might pick one version or we might pick the other version. This is particularly common for newspaper sites that have a lot of syndication, where maybe you have local newspapers and regional newspapers and some of the local newspapers share the same news articles, then it's completely normal for the same content to be on multiple websites. And we have to kind of deal with that and pick one of these versions to show. And if you don't tell us which one to show, we might pick any one of these, which might be the one that you want or might be a different one. And you can tell us, obviously, with the normal canonicalization methods like the rel canonical is a really good signal to let us know which one of these versions that you want to have. How does Google handle the registered symbol, like the R in the circle, and the trademark TM symbols and search listings? Are they ignored like most punctuations? As far as I know, yes, they're essentially ignored. So we treat them as a symbol. It might be that you can search for them in the meantime. I know we've enabled search for some emoji characters as well. So maybe you can specifically search for them. I don't think you'd get any kind of useful content just by searching for symbols alone, but it might be kind of a curious thing to search for. But in general, we treat them like any other symbols in the search results. We don't apply any semantic meaning to them. So just because you're using some word and then the TM symbol next to it doesn't mean that we should treat that word in any special way. All right, a couple minutes left. What else is on your mind? Hey, do you want to name the Google update from last week? Go. The Google update from last week. I have no idea which Google update from last week you mean, partially because I don't know which of the changes that we made recently was actually launched last week. Let's go. No, I'm not going to give any names. OK, I have to try. Sorry. But yeah, I mean, we make changes all the time. So it's really hard to say. So what I'm noticing is that you make the changes and then it kind of like you revert it back, right? Because if you're monitoring 100 sites for like six years and I notice that engineering is testing. I don't know if we revert it back all the time. I think there are different aspects that might make it look like that. For example, if you're looking at different data centers or if you're in multiple experiments and sometimes you're in one experiment and sometimes you're in another experiment, then it might be that it looks like things are like this way and then the next week they're reverted back. But maybe you're just in a temporary experiment where we're trying things out. No geolocation thing. Could be location thing. I don't know what specifically they're using for the experiments. But that's something where I'd say this is kind of normal from our point of view. We always have to kind of stay on top of things. And the best way to do that is to try things out and see what actually works and what doesn't work so well. We understand. You can't say everything. OK. No, it's really kind of the A-B testing stuff that everyone should be doing. Yeah, go ahead, Mihae. Hey, just managed to get in right now again. Just a quick two questions. One is whether are you still crawling from other countries as well, especially for somebody who might block their content from US-based IPs? Would that be a problem? Are you still crawling from other countries? I think we're still crawling from other countries, but it's a very limited number of countries and kind of crawling that we're doing there. So it's not the case that we crawl from all countries. I think it's just a handful of individual countries at the moment. And it kind of depends on the website. So if we can tell that your website is based in the US, then it doesn't really make sense for us to see what does a user in some random other country see. It's more that we say, well, we crawl from the US anyway. And for the most part, it is from the US. So if you're in focusing on Europe and you block the US for legal reasons or whatever reasons, then probably you're blocking Googlebot as well. You can test with the Fetch and Render tool, or you can probably see it very quickly in your search logs. Right, but the Fetch and Render tool always tests from the US, even though you might be crawling, right? So or is that not the case? I don't know. I thought we would use a normal Googlebot set up there. I don't know. You can block the US and just add the Googlebot. You can just add your IP in there. I don't think that works. No, I don't think that works. Yeah, yeah. It's really something that is kind of tricky, I know, for some European sites and some kind of businesses where you say, well, this content isn't available in the US for policy reasons or legal reasons or whatever else. And since we do crawl primarily from the US, you kind of have to deal with that. So the thing I usually recommend is just having some content that is accessible from the US and having that at least as a backup so that users from the US can go there, meaning Googlebot from the US can go there as well. So if you, I don't know, have a website where you're selling something that's illegal in the US, then maybe have a landing page that's like talking more about what you're selling rather than actually doing the selling, I don't know how you would do this from a policy or legal point of view. So you probably have to figure that out yourself. But having something that is available in the US makes it so that we can actually index it from the US. OK, so that was just related to a forum thread for somebody asking that. And I just wanted to get a bit more context. I just linked it in the chat. The second question was regarding and search console and pages crawl per day. Does that only include HTML pages? Or does that include PDFs and images and everything else? That includes pretty much everything, yeah. OK, OK. That also includes, I believe, the ad spot request, which also go through Googlebot IP addresses, I think. OK, I didn't know that. Cool, thanks. Sure. All right, we're slightly over time. Maybe one last question. Very. Would you say, John, that Google increases the crawl rate limit for our website when there are changes in the structure? Yes. Thank you. When we can recognize that, we'll try to do that. Of course, up to the limit that we think your server can take. Yeah. So we don't try to kill your server. What do you do about cheap hostings, like people that can't afford expensive hosting since you want the three seconds and you have the three-second stat that a person usually needs to go on? I know you can't do much about that, but what do you do about people that can't afford expensive hosting to what happens if it becomes an algo where speed becomes a ranking factor? What do you do about that? I think we can't really do much about that. So if at some point speed were to become a stronger factor, then that's something those sites will have to take a look at. And usually what happens there is that if you're in a situation where your business can't really afford a bigger web hosting setup, then probably the other businesses in your niche have the same problem. And you're all kind of stuck at the same level. So it would be rare to be in a situation where you're saying, well, I can afford my $2 per month server. And my competitor has a $20,000 a month data center that they have access to. That's usually not the type of situation you're in. But of course, if you are in that kind of situation, then sometimes it makes sense to say, well, I don't have the financial means to do it, but I'm creative. And I can find ways to kind of work around those speed aspects. So maybe things like looking at AMP, maybe things like looking for cheap or free CDNs that cash and serve the content very quickly. There are lots of kind of really cheap things that you can do that have a significant effect on your speed. So that's something where maybe you can kind of be more creative and work around the financial aspect like that. Sounds good. All right. OK, so let's take a break here. I have been the next Hangout for Friday setup. There's also a German one coming up. And I believe a Japanese one as well. So if you have more questions, feel free to drop them into those Hangouts. Or as always, feel free to drop by the Webmaster Help forums, where lots of smart and motivated people can help you to figure out what you could be doing a bit differently. All right, thanks for joining. And hope to see you all again in one of the future Hangouts. Bye, everyone.