 All right, welcome, everyone, to today's Webmaster Central Office Hours Hangout. My name is John Mueller. I'm a Webmaster Trends Analyst here at Google in Switzerland. And part of what we do are these Office Hour Hangouts, where people can join and ask their questions around their website and around web search. And we can try to help with, hopefully, some answers. Sometimes there are no answers, but we try to at least explain the thoughts behind it. A bunch of stuff was submitted already on YouTube, which is great. That's always useful. But is there anything on your minds that you need to get an answer to right away? Yes, John. I'm Sanjit. Sure. Yes, John. I'm Sanjit. I'm from Bangalore, India. Yes, I have a question, actually. So I have a website, and part of the website in AMP, and some of the pages we serve dynamic serving to show the content in mobile. And it's in mobile first indexing from May 2018. But now I see in the primary color setting, it's showing at stick store. So it not moved to smartphone. So could you please help me on that? Where are you seeing the primary crawler? It's showing the stick store in such console tool, in coverage sections in such console tool. OK. So usually when we move aside to mobile first indexing, then we shift that, too. But what also happens with mobile first indexing is we will still crawl some pages or some parts of the crawl with the desktop crawler. So it's not that you would shift completely over to just mobile crawling. It would still have some things there. And in general, it's nothing that you need to worry about. If your pages are ready, if things are working well on mobile for you, then that's fine. It's not any disadvantage to be crawled with the desktop crawler. OK, thank you. Thank you so much. Sure. Hey, John. Hi. Yeah, so I have a question regarding, so I see I have a website with the mobile version and the desktop version. So I'm wondering how I can use the parameter. You had the parameter, so I have it. The URL parameter handling. OK. So that doesn't really change with regards to desktop or mobile version. If you have parameters within your website that you feel are making it harder to crawl your website properly, things like sorting or filtering parameters, then you can specify those in the parameter handling tool. If you're not sure, and if you think crawling is working fairly well, then I would just skip the parameter handling tool. Then you should be awesome. Yes. Yeah, so another way of doing it, we use canonical tag to the main URL, right? So in the mobile version of URL, what canonical should I give? Should I give to the desktop version or the mobile version your main URL only? So with the canonical, you should have the link between the mobile and the desktop version. So the desktop version will have a link rel alternate to the mobile version, and the mobile version will have the link rel canonical to the desktop version. Yeah, so sorry to interrupt. So that part I understood. So actually the thing is if I have original version without the parameter one, right? So we'll do the same thing which you told. But in case of parameter, so ideally canonical should, in that case, canonical should go to the desktop version or the mobile version of the main URL. I would just do it to the desktop version of the main URL. I don't think it matters because we fold those URLs together. But the desktop version seems like a good choice as any. It's maybe also another chance to suggest that if you can move away from the separate mobile URL setup, it would make things much easier. You don't have to worry about that. But I know moving away is sometimes a lot of work. Yes. So yeah, I had talked to product team regarding it. And they are not ready to do that, basically. So I have to walk with the mobile and desktop version separately. So that's the thing right now with me. Yeah, yeah. I know it's not easy. Yeah. Cool. I remember I felt that way back. And now I'm looking back at it and I'm like, oh my god. I remember telling you that there's sites, a lot of sites that I knew that were m.dot, whatever, and having a website as a whole, yeah. Yeah, I think it was a reasonable choice at the time when making responsive sites was a lot harder. And sometimes you had completely different teams working on a mobile site. But it does make things much, much trickier when it comes. And now it's on your phone. So to addition to that, John, another point I had. So basically it's a dynamic site, so a big e-commerce site. So there is a crawling problem happening, because we started our mobile site indexing recently in a month back, basically. So ideally the sitemap is something like we submit for the desktop and the URL has given to the mobile version, right? So I'm wondering can we submit a separate sitemap for the mobile version, only having the mobile URL in it to make crawling faster? It wouldn't make crawling faster. So we need to kind of see the map between the two versions. So I would continue with the main desktop version with the sitemap file. Got it. Thanks for your answers, John. Sure. Hi, John. I have a question for you. Sure. Yeah, we have been implementing the structured data from February last year. But unexpectedly, due to accidentally, the structured data has been removed on last July. And we buy some developers when they are doing. And again, in the month of August, we have noticed it and we have added it back. But till from that time, we are not able to see the results of the rich snippets. We are able to see the results of AMP and FAQs and videos and everything. But only for rich results, we are totally vanished right now. So is there a way we can do a resubmission kind of thing for the desk? So the way that we decide when to show rich results is based on three things. So it's not something that you need to do manually. Well, not something that you need to resubmit manually. That someone has to look at it. Unless there is a manual action already. Like if the web spam team says it's not OK, then you need to fix that. But we need to have technically the correct structured data. So with the testing tool, that sounds like maybe you're doing correctly. It needs to be logically correct. So it needs to be the right type of structured data for the right situation. So if it's a product, it shouldn't use the recipe for structured data. It should match what you're showing. And the third thing is kind of tricky is that we need to be sure that the website is of high enough quality so that we can really trust the website. We know that the structured data that you're providing is something that is relevant to be shown in the search results. So that's kind of usually the part where people get stuck in the sense that technically implementing things correctly is testable. But determining how high quality your website is is something it's very hard to do. So if you're not seeing rich results, one thing you can do is do a site query for your website. So just search site colon and then your domain name. And if you see the rich results there, then technically we understand the markup on your pages. And it's usually more a matter of us just not being sure about the quality of the website overall. So that's something where I would say, if you see it in a site query, then definitely focus on improving the quality of your website significantly, not just fixing things a little bit, but really getting a lot further. Sorry to interview. So continuation, we have checked there are no any manual action report is not there. And we have been checking all the structured data as per the tool, like structure data, test tool, and it's been passed. For some queries, when I'm doing it with a brand ID keyword, I'm able to see the rich snippet, like future snippet in Google. But the data is not being showing in Google search console. That's what we are worried because we are lost a lot of impressions because in July, month, we are seeing that's where the rankings. And will there be an impact of Google page speed on the structure data as well? Because I have checked my site with Google Lighthouse tool and it's showing a COO score as 98. And web performance, it's in 50 to something like that. Because that's around 10, 4 years old site and it's in Trupal. And they're not able to increase the speed. That's one more thing is worrying me. And it's very getting very difficult for me to convince my client that this speed is the only matter. This is one of the top three priorities. That's how I'm telling. I just want to, if you can throw some light on it, it will be good. Yeah. So whether or not we show rich results wouldn't affect the rankings. So if you're seeing a drop in rankings that's completely separate from rich results, that's maybe one thing. The other thing is with speed, it sounds like you're in a reasonable range. It doesn't sound that terrible. So that's probably OK. But just from what you're saying, I would really recommend focusing a lot more on the quality of the website overall. OK. Thank you. Thank you. Sure. OK. Let me run through some of the submitted questions and we'll have more time for questions from you all towards the end. I have this room a little bit longer so we can go a little bit longer maybe go off the record so that the recording doesn't go too long. Let's see. Regarding the indexing API, I'd like to know if it can be used in e-commerce shopping sites. At the moment, no. So the indexing API is a way of submitting URLs directly to Google and it's currently limited to live streaming and jobs content. So any other kind of website content will not be processed with the indexing API. I don't know about the future plans. Personally, I would much more recommend using sitemap files for any kind of general website where you're making changes. Make sure that you're submitting good sitemap files that are focused on the primary content and that you specify the last modification date and time of that primary content. So that's kind of what I would recommend doing there instead of trying to go this workaround through the indexing API. Another one that kind of, I guess, similar to e-commerce, product markup only really works well for standalone one off stores like mom-and-pop t-shirts stores who directly retail. I would argue that's not the case, but OK. When will it be extended to suit the case for global enterprise brands who may have many product pages but don't directly sell to the public? For example, a bunch of car dealers or car manufacturers, like how do you mark up a page for a specific car model? When there's no real price there, probably because of all the variations, it really makes it harder for the enterprise SEOs. So I think this is an interesting question, but I think it's worth looking at it from the other point of view in the sense that what makes sense for a lot of these rich result types is that you're aiming for a specific way of that content being shown in search. It's not that you're marking things up and saying, well, I have this magical bonus just because I marked things up, but rather you're trying to be present in a particular way in the search results so that users better understand what it is that you're offering and how your website is the most relevant one for what they're looking for. So that's kind of the direction I would look at this from. And when we look at the general products that we show in the search results, it's like you're searching for a specific type of device or a specific item, and then we can show the different prices and kind of the related items and reviews for those items because it's very much tied to one specific thing. When it comes to different car types, for example, there's so many different variations, and reviews kind of match different variations, and the prices are all over the place. How would that be suitable to be shown in this kind of generic product display that we have in the search results? I don't know. It feels a little bit stretched to me. So from my point of view, it's not that these kind of sites that are selling cars or that are manufacturing cars are in any kind of disadvantage because, well, you can't fit a car into kind of this one small thumbnail image with a price and a review and say, well, this is all there is to it for this specific item. So until or unless there's some other way of showing this kind of content in the search results, and I really don't know if anything around that is planned, then that's something where I wouldn't try to shoehorn kind of the generic product markup and structured data into the use case of something so, I don't know, different like a car, for example, where you have all of these different variants and variations and reviews and all of these things that are quite different between the different types and models. But that doesn't mean that you can't use structured data on these pages. We do use structured data to better understand pages and to better understand when a page is relevant to be shown to users. So I would double check the schema.org list where we have all of the different structured data types and think about ways that maybe there is something on the items that you're selling, on the items on your website that is not being picked up properly in the search results where maybe people are searching for something similar, but they're not really finding your pages. And think about if there's a way that you can specify that clear to search engines that your page is actually about this specific type of item. I don't know what exactly would match there for cars in this particular case, but you don't need to just focus on the car aspect here. Maybe there are other aspects on your website where you already kind of have this situation where it's harder for people to recognize what that page is about. Because I imagine for car models, people search for these models directly, and we can probably already show those fairly well in the search results. When we add FAQ schema to a page, does that show every time in the search results? No, it's never guaranteed to be shown in the search results. So it wouldn't be the case that we would show it all the time. I think we had that before with the other case with rich results where there are different things that we need to look at before we do show it. And even when everything aligns, then we try to limit ourselves to a certain amount of rich result types in the search results page, because otherwise it just looks too overloaded with all of these different variations. The European data protection regulation requires consent requests for cookies. The forum usually overlays the content as a layer. And then there's some examples. How can Google handle this? Can Google differentiate it from advertising layers? What is to be considered? So I looked at your examples, and at least here in Switzerland, I don't see those overlays. So that's kind of hard for me to say exactly what is happening there. I generally assume that people put Switzerland into the same bucket as the rest of Europe, despite us being so unique and a little bit weird, but so I don't see those there. I'm not sure exactly what the overlay looks like there. So that kind of leads me to two aspects here. On the one hand, Google generally crawls from the US. So if we don't see those overlays in the US, then we would not see those overlays for search. So that's kind of the first one. The other one is we generally try to recognize these kinds of legal interstitials in legal banners and differentiate those from advertising banners. So that's something that we have quite a bit of practice with and in the past, I thought we would need to create a special markup so that you can specify, oh, this is a legal interstitial, not an advertising interstitial. But it turns out that we actually figure that out fairly well. So for the most part, that's not a problem. The one case where it is a problem, and it's really, really rare that I run into cases like that, is when the interstitial replaces the actual content on the page. So when you load that page, instead of the actual content also being loaded at the same time, you either get redirected to an interstitial page or the server only delivers the interstitial without any of the content at all. In a case like that, Googlebot would not know that it would need to do whatever it needs to do to kind of go through the interstitial and load the actual content. So that's something where from a technical point of view, we just don't have any capability to actually get to the content itself. Sometimes I see that with age interstitials, where you have to enter an age, and then it redirects you back with a cookie to the actual content, and then it actually loads the content. Usually that's something where or people are aware of that or they notice it fairly well because all of their content would be essentially gone from search. We would just only have that interstitial page. So it's usually a pretty obvious thing if you look at the search results for your site and you see that none of my content is indexed, it's not ranking for any of my terms and the snippet just shows like please click here to confirm. Then that's a pretty obvious sign. Yeah, those are kind of the things that I would look at there. How does Google treat templated content like on real estate and e-commerce sites where there are hundreds and thousands of pages being generated? So we don't do anything special with this kind of templated content. It's not that we would say this is a real estate site, they're allowed to do this and other sites are not allowed to do this, but rather we treat this content as we would other content elsewhere. That means if the whole page is duplicated across a website, then maybe we would treat that as a duplicate page and say, well, we'll just index one of these, we don't have to index both of them. If just a part of the page is duplicated, we'll try to recognize that as well. We'll generally still index that page and we'll try to show, when someone is searching for that specific piece of content, we'll know that this piece of content is on multiple pages and we'll try to show the most appropriate one for that user. So that's something where we try to figure out among all of these copies that we have, which is the best one to show in this particular case. And usually what we try to do is filter out the duplicates in those search results pages. So you'll often see if you go to, I don't know, page three or four of the search results page, it'll say, like, there are some pages filtered out, click here to see them all. And that essentially means that within the snippet that we would otherwise show, it would essentially show the same thing multiple times, which is not very useful for users, so we would filter those out. So again, it's not that we would treat these kind of sites in any way different, it's essentially just, we recognize it or those elements as duplicate content, we try to deal with that. And there's no penalty for this kind of duplicate content. So it's not that your site would be seen as less valuable, just because you have the same product listings as other sites, it's just, we know that it's the same thing as on other sites. So when people search, we try to pick the right one to show. Can you talk about Google Discover and put more light on Google Discover versus Google News? So, I don't know what there is really to say about Google Discover, it's something where we try to recognize when content is relevant to users and we surf it to them directly in the feed. So from a website point of view, the tricky part is there's no keyword associated with it. There is no ranking associated with it because you're somewhere in this feed. So that makes the little bit trickier to kind of focus on because essentially you have to create relevant content that is useful for users that makes sense to be shown to users at that time. The one thing I would kind of think about when it comes to Discover is that visual content tends to perform a little bit better in that it draws people's attention. So things like large images, if you can mark up a large image on your page, that makes it a little bit more interesting for people. If you use AMP, then it automatically uses the wider image. If you use the, what is it, the max image preview robots meta tag, you can also specify a larger image to be used in Discover. I think that makes it a little bit interesting for users when they're in their feed. It doesn't mean that we would be more likely to show your pages, but it makes it probably more that people would click through and say, well, this is actually a pretty interesting topic. You don't need to be in Google News to be in Discover. Discover is based on the, essentially the normal web search content. We do have a set of guidelines and policies for Discover. So if you're really curious about Discover, I would double check our Help Center on that. Then a few other questions. How can we use the next back button safely? I'm not quite sure what you mean there, so don't really have an answer. How can we integrate affiliate marketing with news websites? I know Google hates this, but I see big brands doing it. So I don't know. I'm not aware of Google hating affiliate marketing, so that's something maybe you're just worth saying. The one thing that we do tend to see with affiliate sites is that there's often a tendency to just put minimal work into them and to just say, well, I have this feed of 100,000 products, I will just create pages for 100,000 products automatically. And if you're creating this kind of low value content, then of course Google search is going to say, this is low value content, because that's what it is. On the other hand, if you're creating really good content and you have affiliate links in there, then go for it. It's like, that's fantastic way to monetize your pages, fantastic way to get a reward for the work that you're putting into these things, go for it. There's nothing on Google's side that would say, using affiliate links within your normal content is a bad thing. The thing that we do say is creating low quality content is a bad thing. So it's not the affiliate links, but rather the quality overall that I would focus on. I've been charged by my company with reviewing our backlinks, reading through old documents, the company engaged in some unnatural building schemes a decade ago. I also discovered that the company made use of one of those JavaScripts that placed automatic attribution links with fragment links on copy and pasted content. My question concerns the later practice. Does Google consider these automatic attribution links natural? So I really don't know how those links look like. I'm not aware of the older JavaScript, things there. It feels offhand, it feels like something that's probably not an issue, but I really don't know how that specifically looks like for your website. In particular, in the past, JavaScript would be one of those things that we would recommend. If you don't want search engines to actually find something on your pages, you can use JavaScript to put a link on this page, for example, and search engines won't use that. In the last couple of years, of course, search engines are capable of processing JavaScript, so all of that is suddenly visible. So my feeling is offhand that if this is something that took place a decade ago, then on the one hand, probably the intent behind those links is not to manipulate page rank, so it's probably less of a thing. On the other hand, it sounds like maybe it's still worth looking at that to see how would those JavaScript links be looked at nowadays. Is that something that would have an effect that maybe you should care about and should clean up, or is that something that continues to essentially not have an effect at all? The amount of not provided data in my analytics account is steadily increasing. How are we supposed to improve our SEO when Google doesn't deliver the search keywords? So I guess, first of all, I don't see the not provided part going away in any time soon. This has been the case since, I think before I joined Google, that the refer no longer shows any keyword information. So that's something where I would not focus on the refer data that you're seeing in analytics or that you're seeing in general when you're kind of tracking the refer data for keywords. I would really focus on things like search console, where we do aggregate all of these keyword data, and we do show it in a way that makes it kind of easier to use. So that's kind of the direction I would have there. I honestly do not see that trend changing back. It's been like this for a really long time. It's something where probably the amount of traffic that you're seeing with a refer is very minimal because we still have some hold back experiments to kind of double check that things are working as expected. And it might be that some kinds of browsers don't fall into the category that where we can kind of strip the refer out. So those are probably the few things where you would still be seeing that kind of traffic, but I honestly don't think that's something that will be going away or that I'd recommend kind of focusing on to try to get back. The Google BERT update affected two of my websites and traffic dropped by 40%. The only thing I'm doing is following Google's guidelines. I haven't built a single link and I focused on creating content, user experience. The site ranked in the top three and traffic was getting better day by day. But after BERT, the site moved to the fourth and fifth page with main keywords and long tail keywords remaining unchanged. My site is the best user experience and average user stays are five minutes. So a lot bigger than my competitors. What's happening here? So I think maybe first of all, this would not be from BERT. So the BERT changes are particularly around understanding queries better and around being able to understand text better in general. So it's not that we would say that suddenly your page is less relevant, but rather with BERT we would try to understand does this question that someone is asking us, does that match this website best? And usually that's for more complicated questions. So if someone is searching for, I don't know, cheap smartphone, for example, then that's a pretty obvious query. We kind of know what to do there. But if someone is asking for like, where can I buy a cheap smartphone when I'm not in India, then suddenly that becomes a lot trickier because of all of these extra elements within the questions like, well, India is mentioned, but you explicitly don't want pages that mention India. So those are the kind of things where I would expect a site might see changes in long tail traffic, kind of these more longer queries where people are searching for something a little bit more complicated. And there I would expect to see more relevant results going to those appropriate sites. So some might see a little bit more, some might see a little bit less. But it wouldn't be the case that overall, your website would drop in rankings or be less visible because of this kind of change because we're really just trying to understand things better and to find which of these pages are more relevant. The thing to keep in mind is that we make changes all the time. We've made several core algorithm changes as well over the, I don't know, last months or so, which kind of overlap with the role of BERT as well. So that's something where my guess is that these changes here are totally unrelated to the BERT change, but more just regards to the general algorithm changes where we try to figure out which pages are more relevant, which of these pages are better, higher quality, how can we show the more relevant pages in the search results. So my recommendation here would be to not focus on BERT, not focus on purely technical aspects. So you mentioned user experience, you mentioned speed. It's something where I would really focus on the site overall and the kind of improving things overall. For the core algorithm updates, we have a blog post that has a lot of details on different things that you could be focusing on. So I recommend checking that out rather than worrying too much about BERT and machine learning and all of these crazy things. Sitespeed concerns, let's see. I think we talked about something similar like this. So like Search Console doesn't show any data. In PageSpeed Insights, there's like different results for desktop and mobile. I understand speed is an important metric. So how can I get the right data to be shown for my site? I feel like I'm simplifying things to run through a little bit. Sorry if I got your question wrong. So maybe the first thing here is that Search Console as well as parts of PageSpeed Insights are based on Chrome user experience report data, which is real-world data that is aggregated from users as they see your site. And for smaller sites or sites that don't have a lot of traffic, we might not have enough data to make a meaningful judgment call here. And that's completely normal. That's not a sign that we're ignoring your website. It's just a sign we don't have enough data to meaningfully make a decision here. So that's maybe the first thing to say here. That's also very visible for larger sites as well, where if you look in Search Console, it'll say you have, I don't know, 10,000 pages indexed and the speed report says here 200, which is, well, I have more than 200. Why don't you show me more? And that's mostly just based on we don't have a lot of data for those pages. The good part there is that this is based on people who are viewing your website. So it's not an artificial test of speed, but actually of what people have seen on their devices in real-world conditions under all of the flakiness of the real world. The kind of the lab tests that are available in PageSpeed Insights where we test your pages and see how they perform, that's something that is based more on a theoretical calculation on how the speed would perform in a browser. And that's something that you can test on the one hand in your own browser. In Chrome, you can run the same PageSpeed Insights test. You can also run the PageSpeed Insights test from our side. So both of those give you some meaningful data as well. And if you're seeing bad scores there, then I would try to focus on the low-hanging fruit. Usually there are small things that you can do that have a fairly big effect on speed. So I would definitely double-check those things. I realize it's sometimes tricky with smaller sites, sometimes tricky if you're focusing on a specific region of the world and you know Google's data center isn't nearby, but there are almost always things that you can do to significantly improve the speed. Related to schema, Google says Jason LD is the preferred format, but Jason LD is JavaScript and JavaScript is bad or takes longer to be processed. I'm paraphrasing, sorry. So, yes, Jason LD is JavaScript, but it's essentially provided directly on the page itself. So that's something that we can process right away that all scripts can just extract from the HTML directly. So it doesn't need to be rendered to be viewed. It works right away. So there's definitely no disadvantage to using Jason LD compared to using microdata or some of the more HTML-based formats that are out there. We recommend Jason LD because it's easier to implement because it doesn't have to be interwoven within your HTML. It can be one big chunk that you put on the top or the bottom of your page and we can extract that and we can use that in one place rather than having to parse the whole HTML DOM of a page. Product structure data descriptions and H1 tags, it's my understanding that meta descriptions and product markup descriptions are two things. For a product markup description, is there a best practice in number of characters, description? As long as a product markup description matches a product appropriately, is there a need to worry about the length? I'm not aware of any restrictions regarding the length of the description in the product structure data, but I would kind of look at it more from the perspective of how will this be shown in search and think about how much text it actually makes sense to show there. So if you have like a two-page article about your product and maybe that's a bit too long. If you have just like five words, maybe that's a bit too short. Finding that sweet spot in the middle is something that you kind of need to look at on your own. And I don't think there will be one optimal length that works for all products. So I'd kind of focus it on that. With regards to the description meta tag, that's similar. We don't have any guidelines regarding the optimal length of a description meta tag. So that can be longer, it can be shorter depending on your pages. We don't use the description meta tag for ranking, so there's no need to stuff keywords in there. It's really something where I would try to describe what your page is about. And like you mentioned, it doesn't need to map one-to-one to the product market, product data as well. For H1 tags, if a site has over 70% duplicate H1 tags across the site, does that harm SEO? Should H1 tags be diversified across the site? So H1 tags are headings, usually the primary headings of a piece of content on a page. Usually I would recommend matching those headings to the actual content. So it's clearer for us, this piece of content can be simplified or kind of titled with this specific heading that you have there. We use H1 headings for the content itself, for the text on the pages there. We also use it for images. So if you have images that are within this chunk of HTML that's below a heading, then it's easier for us to say, well, this heading definitely applies to those images because they're a visible part of this page. So with that in mind, using the same heading across the site and larger parts of a site is kind of, I don't know, wasting signals that you could be using to give search engines more information about the actual content on your pages. Where if you're just using the same thing over and over again, then we say, well, we've seen this heading before. It doesn't help us to differentiate which page on your website is the most suitable for this question that a user is currently having. So it's not so much a matter of harming your SEO, but you're not taking full advantage of all of the signals that you could be sending search engines. Multi-language websites and URL structure. I took a look at this one beforehand, so I'll simplify it as well. Basically, you have some English URLs, like slash about us, and then you have some French URLs, which would be slash fr slash contacte nu, which would be kind of like the French words for about us or contact us in this case. It does Google have a harder time figuring that out, or is that okay? So from our point of view, that's totally fine. If you use hreflang annotations between these URLs, that's perfectly fine. Having a clear language or country code in the URL structure makes it easier for us to understand the language or the country versions if you're not telling us about it with hreflang, but if you're already telling us about this with hreflang, then we would already figure that out. So that's kind of the main thing there. With regards to the language itself, usually that's also less of a problem because we try to understand the language of a page based on the content of the page. So if you give us a French URL, a French page, and the URL is just one, two, three, four, we will still understand that that's a French page. And similarly, if you give us an English page and the URL is three, four, five, six, we'll still understand that's an English page even if the URL doesn't have a clear identifier telling us this is in English or this is like an English keyword associated with that page. So the URL itself is not something that I would use as a critical signal to say this page is in that language. If you're using hreflang, then I would not worry about this at all. If you're not using hreflang, then having a clear language or country ID in the URL makes it a little bit easier for us to guess, but probably we'll figure it out anyway. Wow, lots of questions left. Let me see. We have 10 minutes left. So maybe I'll just open it up for questions from your side. And if nothing comes, then I'll continue down the line. Yeah, I wanted to know like young very long URLs. I mean, how long should a URL be according to your data? How long should the URL be? So you can pretty much make it as long as you want. I think some of our systems are like for web search, I think we can pretty much deal with everything. I think in Search Console, it's limited to something like 2000 characters per URL. So that's a pretty long URL. So I don't know, I'd focus on shorter URLs. I think it's easier to diagnose and to troubleshoot and to monitor all of that. If you have short URLs with a nice structure in them, but sometimes you have crazy parameters with IDs in them and they get a little bit longer, but 2000 characters is a lot of room. So those tools that show, hey, don't exceed 140 or whatever, just you can ignore that? I think those are good practices, but it's not that there's a critical limit, definitely not at 140, it's more like around 2000. Okay, thanks. Okay, so quiet today. Hello, John. Hi. Hi, how are you? Pretty good, how are you? Fine, thank you. So I have two questions. We have a 200 e-commerce site and we used to have a category pages and product pages are the same depth, crawl depth. So that led us thinking that those URLs might be competing with each other. So we took the 10 category pages and raised them up a level. Is this something that would take a while to process? It definitely takes a bit to process, to re-understand that structure, but I think it's a good idea to do that. The main reason why I think it's a good idea is that in general, with most sites, the closer things are linked from the homepage, the more frequently we crawl them. So especially with the category pages, that's one place where new products, for example, would show up fairly quickly. So it makes sense for us to crawl those category pages a little bit more often so that we don't miss any new product that you put on your site. That doesn't mean that the category pages will have more weight in search, but more that we can find those new products a little bit faster. And if people are searching for those new products, we can show them a little bit earlier. So that's generally why I would recommend this kind of structure where you have kind of the homepage and then maybe the category pages or something in between, and then that leading off to the individual product pages. Okay, so the other one is, looking at our internal linking report in the search console, I see some long ago dropped URLs from index in the part that says your page is linked to this page section in each top link page. In each top link page. So does this mean that Google is still taking this into consideration for working purposes? That means we still have it in our database, essentially, but if it's a really old page, then we would keep that in there until we can reprocess that old page and drop it out. So if we haven't reprocessed that page in a really long time, then there's minimal value in that page from our point of view, in that link especially. So usually that's a sign that we've seen this, we know it used to exist, maybe it exists now, maybe it doesn't, we don't really know for sure. But we haven't had a chance to look at this page in a really long time because we don't think it's that critical to check that free one. So for the most part, you can ignore that. It's essentially just, we found it, we want to tell you about it. It might be something that's older that you don't really need to worry about. Okay, thanks. So I took a look at, like in Search Console, basically when you submit a sitemap, it's not like the old school, I don't see you for some reason. It's not like the old school Search Console where you would submit the sitemap, you would see something right away, but now you have to wait. Is that correct? With the sitemap stuff, because there's a delay in sitemap for some reason. Like the last week called November 6th, I'm just trying to kind of troubleshoot the thing as I'm talking to you in Search Console for that particular site. But it's saying last crawl was November 6th, and then even though you submit it, you know, like... Yeah, I don't think there's the resubmit button that used to be in the old Search Console. Yeah, so what you could do is do an HTTP ping for that URL. So there's a special URL that you can construct and you just open that URL up in a browser and it has like a text that just says thank you for submission. And that essentially reprocesses the sitemap file. The link for that should be in the help center somewhere. Yeah, I would try that. Okay. All right. But anyways, right? Sorry? You'll take a look at it, I guess, when you get a chance. Yeah, yeah. In the chat, let's see, there's some things around security alerts with injected content. I'd probably need to have some examples there. So if you... I can give one about content injection. Okay, so we had a security issue for content injections but it's block pages that haven't been re-indexed for three months. So how do we get those pages re-indexed? Submitting a sitemap file would probably be a good idea. If it's just individual URLs, you can use inspect URL and submit those there. So if you just want to double check that it's actually okay, then I would use inspect URL for that. One thing I've seen on and off is that hackers, when they inject content in your pages, they also add some cloaking to those pages so that when you look at it in a browser, it looks okay, but when Googlebot looks at it, it still has the hacked content. And with inspect URL, you can double check to see what content Googlebot would actually see as well. So that... The other thing that we're using is looking at the... Using code command, using different user agents and then comparing the content. Yeah. Everything is good. It's just about re-indexing those pages again. Yeah. If it's just a handful, I would just use inspect URL and do it manually. I believe there's also someone that created a script that does a little bit more automated, but there's some limits with inspect URL. So if you really have a lot of URLs that you need to submit, I would just use a sitemap file. Let's see. Reviews on Google business, a ranking factor, not for web search. I don't know how that's handled within Google My Business. I could imagine that maybe they do use them, but for web search, we don't use them. Will the next webmaster conference be in German or English? So we have one in Zurich that's lined up. I think we'll have the... So the plan is to have the registrations all sent out today. We're a little bit behind there, but we said we would do it by today, so we'll manage to get that out today. It'll be in English, so the content will be kind of available to everyone. It's a little bit bigger. We have people from external as well who are presenting something. So I think it'll be cool. We also have one lined up in Tel Aviv. So if you're closer to that, I'd be an option too. We have some old low volume pages with mobility issues in Search Console, but they haven't been re-indexed in three months. How can we force re-indexing to get the error to go away? So if it's flagged as a coverage issue in Search Console, then you can request verification through Search Console, which will speed up crawling a little bit of those pages so that we can get through those a little bit faster. But otherwise I would focus just on sitemap files kind of like before. Yeah, let's see. There's another question about BERT. How would BERT affect Chinese search queries? I think at the moment it doesn't affect it at all. So in the blog post we explicitly said it was for English content. Some of these kind of natural language understanding models are very language dependent and we need to figure out how things work well in one language first before we can generalize them to all other languages. So sometimes that takes a little bit of time. I could imagine, especially with languages like Chinese where lots of variations and where it's a lot harder to kind of extract the meaning from a sentence that might be a little bit harder, but I'm pretty sure there are people working on that too. Okay. I'll just continue going down the list until any of you step in with questions from your side. Does Google ever strip off parameter values for managed parameters when crawling URLs? A client is seeing empty applied parameter values in their log files, but not in their internal linking. Could these be legacy URLs that Googlebot has seen in the past? They could be legacy URLs. They could be things from the parameter handling tool where we're just dropping the parameter values because the parameter handling tool says like the value is irrelevant. We do try to figure that out algorithmically as well. So the parameter handling tool is your way of telling us about this, but a lot of people don't use that tool, which is fine. So we try to figure that out as well. The really common use case, or it used to be really common, is session IDs in URLs where every time you access a page, it would use a different session ID as a parameter. And that's something that we also try to understand automatically so that we don't overload your server crawling all of these session IDs. So that's kind of a really simple example, but that applies to a lot of other parameter values as well. The more we can optimize our crawling for your website by limiting the parameters that we use, the more we can crawl more efficiently, which means the more frequently we can crawl your important pages. So that's kind of a win-win for everyone. If I have another question about if there's time. All right. Go for it. Life questions are great. So I know that you talk about taking low-hanging fruits, but I would like to know what Google use for ranking. Are they using the score, the performance score? Are they using the speed index for first content with pain? Which one are they using for the rankings? Everything. Well, probably not everything. But we use a mix of lab data and real-world data. So it's not that we focus on any specific score or that we would say that we use any specific score, but we try to use a mix that matches what we think is representative of speed for that website. So on the one hand, it makes it a little bit trickier because you can't see exactly what score Google is focusing on. On the other hand, that makes it a little bit easier for us because over time, when new kinds of metrics come up, which we can better understand the speed for, we can use those rather than being tied to some old school score or test that's happening. So that's kind of the mix that we try to apply there. So if you want to do SEO just for speed, then I would focus on speed in general and focus on the areas where your site is being seen as slow rather than trying to just take one metric and try to get 100 on that. So we used to see this a lot with PageSpeed Insights where people would say, I'm going to optimize my site until it has 100 there. And you can optimize a site to have 100 there without it actually being a fast website. So there are tricks you can use to make it look like it's really fast to a specific testing tool, but it's actually still pretty slow for users. So instead of doing that, I would recommend making sure that across the board, your site is pretty fast. All right, let me take a break here to pause the recording. If you want, you're welcome to stay on, and we can chat a little bit more. But anyway, it's been great having all of you here. Thank you for submitting so many questions and bringing questions into discussion as well. I hope you found this useful. And maybe we'll see each other again one of the future Hangouts. Thanks a lot, everyone. Thank you.