Hi. 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 Hours Hangouts. It looks like we have some new faces here, which is fantastic. So if there's anything on your mind that you've been meaning to ask, feel free to jump on in now. John, I have a question. Some of our clients, they resale the product of some other companies. So now they want to add, they want to actually want to copy product description from manufacturer website. So is it all right if we copy content from manufacturer website and use canonical tech to avoid any issue? You can copy the description from the manufacturer's website. That's essentially up to you. What would generally just happen is if someone is explicitly searching for a part of the description that is copied from the manufacturer's website, it might be that we show your website. It might be that we show the original website. It might be that we show some other copy. Actually, the manufacturers are based on USA. They don't sell product in Australia directly. But our clients, they are actually dealer or supplier in Australia. So they prefer to copy content from there. And so if I want to rank for those product-created keyword in Australia, will it be a problem? I think that should be fine. I mean, in an ideal world, you would have your own descriptions and your own product titles and descriptions and all of that. But I realize sometimes that's not so easy. So in a case like this, I think that would be totally fine. If someone in Australia is searching for this product and you're the company that has this product in Australia, then that would generally be what we would show. OK. And my second question is, most of our clients are use WordPress and we use USP if you're plugging to add title to get a description to the website. So sometimes that plug-in suggests us to not use preposition or the stopwatch in the URL. Do we need to, is it a problem if we use stopwatch like in add how this works in the URL? I don't see a problem with that. I think at most you will make the URL longer and it'll be harder to kind of write manually. But I don't think that's an issue anymore. OK. Thanks, John. Sure. All right. I just have one quick question if I may ask you. In e-commerce, we have such a thing as large navigation and large navigation as parameters which influence the URL. So let's say we have hundreds of thousands of large navigations and options for the customer to filter the results of the products. Now what I have done is I have made these particular options. I have injected the meta robot code. And instead of saying index and follow, I said no index and just follow. So is this going to harm our ranking? I don't know. For this I'm asking. And just to add up here, all I have done is just made sure that we don't index some sort of duplicate content. And that's all I have done. So would that influence our ranking at all? So usually it's less an issue of ranking and more a matter of crawling all of those variations that would kind of overload your server. So using no index on those pages is a good idea that tells us we don't need to focus on these pages so much. There are some other strategies that you can do as well. I believe we have a Help Center article on Asseted Navigation where you can kind of see which approach works best for you. The important part for us is that we can still find all of the individual product pages. So if you have high level category pages which are indexable and that link to your product pages, that's fantastic. If you take the secondary category or the first or second or third filtering categories and you say, I don't want these indexed, then that's fine too, as long as we can still reach the products through your main category pages. So for us it's really mostly a matter of can we find all of the individual products? And if we can, then you're welcome to kind of block all of these different facets and pagination categories or however far you want to go. Well, we usually make sure that we use side architecture to ensure that the crawlers to go from the home page to the main category page to the subcategories and deletries the product page to ensure that, well, like aside from the Google crawlers or the sessions of crawlers overall, I meant to use that for one reason, that just to improve the user experience where the customer can find that specific product that he or she is looking for. And that's the main thing after all, based on what I heard from you. The main key, the most important key in the ranking, which influence ranking overall is the user experience. If the customer satisfied and spent more time on the site, they're better for us, no? I wouldn't say there's like a one-to-one relationship with that, but that's definitely what we're looking for overall. Kind of understanding that users, when they go to your website, they can actually do whatever they were looking for, that's really important. So if you're setting this up in a way to allow all of these different filter options to make it easier for users to find what they're looking for, that's fantastic. I think a lot of times these different filter options and URLs don't need to be indexed, so using the no index there is perfectly good. All right, thank you very much for your answer. Sure. All right, if there are no other questions to start off with, I'll just run through some of the things that were submitted. And as always, if you have any questions along the way, feel free to jump on in. We'll try to have some time towards the end as well to cover anything that has come up additionally. Okay, first one, how important is the title tag as opposed to the H1 tag? We're wondering kind of where we should have put our keywords for and what we should do for best click-through rate or best keywords, what we could be doing there. So in general, these are two different things. The title tag is something that is visible to the user on the one hand when they're on the page in the tab on the browser when they bookmark that page, but primarily when it comes to search, they see this as the title that we show in the search results. So we don't always take exactly one-to-one the title tag that you have, but for a large part, we do try to focus on what you provide in the title tag and show that in the search results. So from my point of view, it's not so much a matter of making sure your keywords are in the title tag, but kind of making sure that you're describing the page properly in a really kind of brief and useful way so that users when they do search and they see your page in the search results, they know this is what I was looking for or maybe this isn't what I was looking for this now. Some noise in the background somewhere. Okay, looks like muted. Okay, perfect. So that's kind of what I'd focus on there. The H1 tag is a heading on a page that helps us to better understand what this part of the page is about. So having some information about what you're focusing on there totally makes sense. And a lot of times these keywords that you're kind of focusing on, they will just naturally align with all of this as well. If you're writing about a specific topic, chances are you mentioned that in the title as well and you mentioned that in the heading as well, kind of keeping it natural and focusing on what people are actually searching for to make it easy for them to understand what your page is about and how your page kind of fits into that topic that they're searching for. We do review markup, but it doesn't appear in the search results. When we do a site query, it shows up. So could that be a Panda problem? So in general, for review markup, for us to show it in the search results, we have to first have it technically correct. So you can do that with the testing tools that we have. On the other hand, it has to comply with our policies. So things like you have to make sure that the reviews are actually reflecting the primary content on the page. If you're doing a recipe markup, for example, then the content should actually be a recipe and not a shoe, for example. And then the third one is what you're kind of talking about here is our algorithms have to be sure that the quality of the page is kind of such that we can trust the markup on this page. We can show that in the search results. So in a case like this, where probably technically everything is marked up correctly, I'm assuming if you're focusing on this markup that you're also keeping an eye out on the policies and you're doing things correct with regards to our structured data policies. And in a case like that, it might just be that our algorithms are kind of unsure about the overall quality of the website. And that's not like one-to-one and mapping of the older Panda quality updates that we had a while back, but it is kind of similar in that overall we look at the quality of the website and we're kind of wondering, well, can we really trust this website to serve markup that we can really highlight in the search results? So if you're seeing that we're not showing your structured data markup and there's really no manual action and everything is technically correct, then maybe it's worth taking a step back and thinking about the quality of your website overall and maybe taking a bit of time to focus less on the technical details of your website and more on what it is this website is really trying to achieve, talking to users, getting feedback from them on how you can overall kind of take this website to a next level from a quality point of view. And I realize that's not something that's really that easy sometimes. So sometimes this is something that you really kind of have to kind of take a step out of your comfort zone and think about like where could there be things that aren't really that awesome?  I love it. I'm able to deal with all of the things that it offers. Maybe that's not the case for the average user. So what I would focus on there. We have a client who's starting their own e-commerce website. What kind of URL would you advise for an e-commerce site? Something like root, city name, category, product, page. There's three level depths in the URL affect negative SEO negatively. So I think first of all, when I see city name in the URL kind of at that high level, it kind of raises the suspicion that there are going to be a lot of doorway pages on this website where you're essentially copying the full content across a large number of cities. And that's generally a really bad idea. On the one hand that dilutes your content because you take one piece of content and you copy it across a whole bunch of different city pages, which makes each of those pages less valuable in our opinion because you're spreading it out across all of these pages. On the other hand, the WebFam team might take action on something like this as well, where they say, well, there's nothing unique on these pages. It's just driving traffic to the same set of kind of conversion pages. So maybe we should just take out all of these city pages manually. So that's kind of the first thing that comes to mind. Maybe that's not what you were thinking of. So perhaps that's not something you really have to worry about there. On the other hand, with regards to the rest of the URL structure, that's really up to you. That's something you can structure however way you think makes sense from your point of view. We don't have any algorithms that look at the number of subdirectories in a URL and say, oh, five subdirectories, this page must be bad, three subdirectories, this page must be great. We use the URL primarily as an identifier for a page. Having some of the keywords in the URL is fine. Using dashes to separate them is perfectly fine. But it's not the case that we kind of require URLs to have the keywords in the URL or that we require a certain URL depth when it comes to subdirectories or subdomains. So that's something I really, from my point of view, look at what your setup technically offers and do something that's easy for you, that makes it easy for you to diagnose issues as well. So if something goes wrong, you can maybe look at that sub-directory level and look at the URLs there and kind of figure out what is going wrong on my website in that part of the website. I think that's more something that I would focus on than whether or not search engines like four subdirectories or five. We're thinking about moving to HTTPS. Should we do it in stages, category by category, over a period of time or not? Should there be a ranking loss if things are migrated correctly? Am I correct in thinking that 301s now don't lose any passing link juice? So I see a lot of misconceptions there. In general, what I would do with a move to HTTPS is just move everything at once. We do try to recognize site moves like this where you're moving a bigger part of your website to a new setup. And we try to process that a little bit faster. And it helps us to really know that the whole website has actually moved. So if you're doing this in steps, what generally happens is it just takes a lot longer and there's a bit more room for error because you might be missing something. We might be assuming that you're only moving a part of your website and then next month the next part comes like where and how do we kind of combine all of these things? So my recommendation there would be to just bite the bullet and do that move completely. Obviously you want to test this ahead of time. You want to make sure that from a technical point of view, your HTTPS setup is working as expected. So that's something I'd say is kind of outside of this SEO type move. But once you're sure that technically everything is set up properly, I would just do that move. 301 redirects are the perfect method for doing this. In general, if you move to HTTPS for the most part, it'll be pretty smooth. It won't be the case that you will drop out of the search results completely. However, anytime you do a bigger move on a website or any bigger change on a website, there are potentially fluctuations that can happen. So that's something I just kind of keep in mind. Like if things do fluctuate a bit, don't panic. These will pass. Our search results page says our site isn't mobile friendly, but the mobile friendly test says it is. So what's up with that? I think this is sometimes a bit confusing. I'm currently discussing this a bit with the team to figure out how we can do that a bit better. So in general, what happens here is when we recognize that you're logged in and you're looking at one of your site's URLs in the search results, we'll highlight when we're not sure if this page is actually mobile friendly. So this is only something that you would see. We only show this to you as the webmaster. We don't show it to other people. It's kind of a hint for you, like, hey, you should take a look at this and make sure that things are actually set up properly. The tricky part here is that sometimes our algorithms haven't reprocessed the URL in a while, and they don't actually know if it's mobile friendly or not, and if they're uncertain, they will flag it as potentially not being mobile friendly in the search results. So if you check the mobile friendly test and everything is okay, then that should be fine. I think we need to make sure that we don't confuse people with this kind of thing. So I'm currently double checking with the team to see what we can do there. We used to rank in the top three positions for a specific keyword for a long period of time. Recently, we've updated our page with a new design and a new URL and are redirecting from the old one to the new one. A couple of days, everything looked fine, and then we stopped ranking. What could be the problem? So I think this is kind of a general question that comes up over and over again. It's like we used to be ranking at this position for a really long period of time, and then we changed our website and now we're ranking differently. And from my point of view, from an initial kind of guess, this is kind of expected.  And that's kind of a normal situation. So just because a website was ranking in a specific place for a longer period of time doesn't mean that it'll always rank there. So that's kind of I think the starting point in that you have to assume that if you make bigger changes on your website, things can change. And even if you don't make changes on your website, then over time things can change or algorithms adopt the rest of the web changes, what users want changes as well. And with that, we have to change our algorithm too. So all of these things can come together and even in situations where URL was ranking the same for a longer period of time, it's normal from our point of view that there are fluctuations at some point. In general, this isn't something where I'd say there's a technical issue on our side or on your side. Essentially, we're just trying to figure out where we should be kind of showing this URL or the site in the search results. And if you make bigger changes on your website, sometimes your pages rank higher, sometimes your pages rank lower. It kind of depends on what exactly was changed. You're welcome to send me a URL or a sample query where you see this happening in Google+, I can't guarantee that I can get back to you. We get a lot of requests from people who are looking for kind of one-to-one advice. Another thing that I would recommend doing there is also posting in the Webmaster Help Forum or just generally getting advice from peers with regards to specifically your site and those queries so that people can kind of double-check to make sure that there's no technical issue on your side that might be holding you back, that it's really a matter of the algorithms looking at the new content, the new pages and evaluating the page based on that. We'll structure Datamarka play a role as a major ranking factor in the mobile first index. What will the knowledge panels look like? So yes and no. With the mobile first index where essentially taking the mobile version of the page and indexing that. And since the mobile version of a page should be equivalent to the desktop page, it should have the same structured data markup on there as well. And if that's the case, then that's what we'll pick up and use. It's not that we will change anything with regards to the ranking factors of pages that use structured data markup. It's just that if you have a separate mobile page then you should really make sure that it's equivalent and that it has all of the same markup on it as your desktop page. And from at least from what I know the knowledge panel and things like that, those won't change because ideally we would have the same information just from mobile pages instead. And obviously the layout of all of the search results pages, they change all the time. These are things where lots of people are doing experiments on them to kind of constantly figure out what is actually working best for users. Case studies have shown that Google Plus campaigns can boost the website's organic visibility. We know you can't reveal ranking factors but I'd love to have a comment from you. Would you neglect Google Plus in favor of other social media? So I think first of all these, the question is kind of like, do you think these case studies are correct or not? From my point of view, I don't think this is valid at the moment. At least not at the moment. We show content from Google Plus in the search results normally. These are normal pages like any other page that can be put on the web and we do show those in the search results but it's not the case that Google Plus posts pass any page rank to other pages. As far as I know, all of those links are with no follow as they should be for user-generated content. So this is something where if you have an audience on Google Plus and you have lots of people that you're engaged with on Google Plus, then maybe this is a great channel for you to promote your website but that's not something that we would directly pick up for search results ranking. And whether or not you use of Google Plus or Facebook or Twitter or I don't know what all is out there, MySpace is probably still out there. That's really up to you. You kind of have to figure out where your audience is, where you want to engage with your audience and if you have an audience that's a fan of your website that's talking about the content that you're creating then that's always worthwhile engaging with because you get lots of valuable feedback from them and having kind of these fans that love your website, that love what you're doing, that's a great thing. That's something I'd recommend more sites do, yeah. I noticed there seems to be a character count, pixel with difference between the length of a title description fully shown on desktop versus on mobile. I can't find any documentation regarding the actual limit. So yes, we do have to use different length titles on desktop and mobile because they're different size screens but it's not the case that we have any documented title length limit that you have to kind of stick to. So from my point of view, I would recommend trying this out yourself, seeing what works best for your website. Sometimes a really short title works better than a really long title. You definitely don't have to fill out the full title. And on top of that, our algorithms do sometimes rewrite titles algorithmically as well, especially when we're seeing things like just a bunch of keywords kind of tied in together without actually being something that users can kind of recognize and then read in the search results. So I wouldn't focus on the absolute limit but rather look at the search results pages for the queries that you're targeting and think about what might make sense there. How long on average does it take Google in 2017 to process and pass on ranking value to a website after the indexing of new links and has this process time increased since Penguin 4 went real time? I don't think we have any numbers where I'd say on average it takes this long but our indexing system is really, really fast. So when we find new links pointing to a page, we follow those really, really quickly. So sometimes that's within a day. Usually the trickier part is more like we have to recognize that this page has actually changed and go and crawl and index it again. But in general when we find something has changed on a webpage, we'll try to pick that up really quickly and we'll take that into account really quickly as well. Featured snippets are pushing all other results down and reduce overall click-through rate. They also return irrelevant answer for many search queries. You have plans to reduce their impact and visibility on the search results. I think there's some assumptions here that might not be shared with a lot of people. So in particular kind of the assumption that featured snippets are bad and they don't really provide a lot of value for users. I would argue that's definitely incorrect. I see a ton of really good featured snippets that provide a lot of value. And with regards to pushing other results down, I see a lot of SEOs actually try to work on creating their pages in a way that we can pick them up and highlight them a little bit better within this kind of bigger snippet display in the featured snippet section. So that's not something I'd argue you should be fighting but rather you should be thinking about are there things on your site that you could be doing to kind of take advantage of this as well, to provide information in a way that users can find it useful within the context of a snippet, maybe within the context of a snippet that's shown a little bit bigger in the search results, giving users a bit more information and with that kind of making them curious about the other information that you might have on your website as well. People have been asking me a lot about the acrylics and accents and how not using them will help them rank better. I don't know, are you here in the hangout, Adrienne? Doesn't look like it. Okay, so if you see this now-ish and you want to jump in, feel free to jump on in and talk about that. From Google's point of view, we try to recognize words more with regards to is this a synonym or kind of like a synonym and we're trying to do that algorithmically. We don't have kind of these manual language models where we say, oh, this specific acrylic or an umlaut or something maps to this set of characters here or this, maybe this Japanese country symbol maps to these Latin characters here. We don't have a manual model like that. We try to recognize these more algorithmically. So if we can recognize that users are using these interchangeably, then we'll probably say, well, we can deal with that. And if someone is searching for one variation, then maybe we can show the other variation as well and the search results without them explicitly using exactly the same characters. So that's something that I think has improved quite a bit over time. But obviously it's always worth thinking about this, especially if you do target users that write things in different variations. What happened last Saturday in the search results? Geez, I don't know. We make changes all the time. So I'm not sure what would have happened last Saturday in the search results. For e-commerce product pages that appear in different categories, is it fine to use the hash symbol to identify in which catalog they are? So the hash symbol or that number sign, the pound symbol, I don't know what the official name is, is something that's kind of ignored on our side. So when it comes to crawling an index in pages, if you see the symbol in the URL, then we will drop pretty much everything that comes after it and focus on the URL part that's before that. So if you use this to highlight different variations and it's something that you don't need to have those individual variations index separately, that's perfectly fine. On the other hand, if this leads to unique content that otherwise wouldn't be available within the normal part of the URL, then that would be something I'd recommend changing because probably we'd skip out on that unique content if it's only identified with one of these hash symbols. I'd like to understand if the use of local jargon could affect my website's ranking, particularly for where I come from in Singapore, we tend to use Singlish, which is a mix of English along with other used languages. On the one hand, I'd like to have a local touch for my local users. On the other hand, I still want to rank in Google, I guess. This is kind of similar to the diacrylic section question earlier in the sense that we do try to recognize when things are synonyms, but kind of as I mentioned before, this is done algorithmically. So if your users are all searching in one variation, in one kind of writing style or one style of these words, then it probably makes sense to use that jargon on your pages as well. And the main advantage I see there is that we can recognize that this word is actually on your page, and if we recognize other variations of that word as well, then that's fine from our point of view, but if you're kind of matching what users are actually searching for, that makes it easier for us to recognize that your page is relevant, but it also makes it easier for your users to recognize that it's relevant to them because they can see right away that, oh, you're local. You know what I'm talking about when I talk about this, I don't know, a special dish that I want to have a recipe for or this special product that I'm looking for. You kind of speak my language. I assume you're kind of within my area, so if I order something from you, then probably that wouldn't be a big deal. All of these things kind of subtly add up. So that's something from an SEO point of view. Obviously, making it easy for users to find your pages by using their jargon makes sense. From a kind of a usability point of view, that's something where it probably also makes sense as well. Ron. Yes. Hello. Isn't it only, isn't the most important thing that the site matters what people are searching for? So if they're searching in Singlish and the site's in Singlish, then that should be fine. Yeah, for the most part, yeah. Doesn't matter what language it is, really. Yeah, I mean, there's sometimes weird quirks in that people search in one language, but they expect to see the content slightly differently. So we've seen this, for example, in Hindi where people will search with the English characters, but actually they want to see the content written in Hindi. And that's sometimes a bit tricky when people are using kind of abbreviated forms for searching that doesn't actually match what they would use for reading content. Lots of complicated things in the world. Not with my website. Okay, no Singlish on your website then? No. Not yet, not yet. All right. I'm helping a client with duplicate content, crawling issues by faceted navigation. The facets are exposing many filter combinations and permutations with low or zero search demand on Google. I plan to no follow these links and canonicalize them to the pages with more demand. Is that enough? I think that's a good approach. The other approach that was mentioned before is no indexing these pages, that also works. The rel canonical helps us to concentrate things on more on the pages that you do want to focus on. So if you can simplify things and guide them to a canonical version of the page, that's a good idea. If you just want to no index these pages because you really think they don't provide value when they're shown separately in search, that's fine too. I work for an agency and we've had a few clients get an increase in 404 pages in the past month. We identified the problem as web forms on the sites that allowed file upload and spammers would upload an illegitimately obtained file, maybe a recording of a soccer match or something. Hundreds of spam sites would link to that file and then we take it down and we get a lot of 404s. We've changed the web form to no longer allow these file uploads but rankings are not recovering. So first of all, I think fixing that vulnerability that people can just upload arbitrary files, that's fantastic, that's really the first step that you need to do there. With regards to the 404s, if these are pages that you really don't want to have index and you've removed from your website or that no longer existed, that's perfectly fine. That's not something where you need to suppress the number of 404s on a website. Sometimes you have a lot of 404s on a website and from our point of view, that's technically the right thing to do because you're telling us these pages don't exist, we can drop them from the search results, we don't have to worry about them as much anymore in the future and that's kind of the right thing to do there. With regards to ranking drops, that wouldn't be related to the 404s. So obviously, if these pages that return 404 now were ranking and you remove them, then those pages are no longer ranking anymore. So if you're looking at the absolute visibility of the website and those spammy pages used to drive a lot of traffic to your website through search, then obviously the number of referrals you get from search overall will be lower without those spammy pages. However, because the referrals for those spammy pages are gone, you'll get more referrals that are actually relevant for your website that are kind of interested in the actual content that you have on your website. So that's worth taking into account there when you're looking at the metrics with regards to your website. So especially in situations where like a spammer has hosted spammy content on your website, then you need to take the absolute number of search referrals kind of with a grain of salt and look at the actual details and think about like how are the conversions actually doing on our website? Is that still okay or are conversions going down as well? Are we getting more or less relevant users? And that's more what I would focus on rather than the absolute number of users coming from search. How long does it take for Google to figure out deadlinks for ranking? I noticed that in my area, a lot of links have built in one authoritative forum but it's been turned down a while ago and still no changes for ranking. So if the whole forum was removed then usually we try to figure this out fairly quickly and kind of recognize that the whole site has disappeared and we can drop these URLs from the search results. Sometimes we can't recognize that the whole site has gone. Sometimes maybe part of the sites is still there and we don't drop all of these right away. But in general, over time as we re-crawl and re-process URLs that should be taken into account, we'll drop these pages from the search results. I think the tricky part to keep in mind is that this can take quite a bit of time. So for technical reasons, we can't crawl the whole website every day or at least most websites not every day, especially when you're looking at a forum where there tends to be a lot of duplicate content, a lot of individual URLs pointing at postings and threads and different sorting orders and categories, all of that. And for any kind of non-trivialized website, there'll be some pages that we can crawl every day, some pages every couple of weeks, some pages take a couple of months, maybe even a half a year or longer to be re-crawled and re-processed. So that's something where I would certainly assume that maybe it'll take a year or so until all of these URLs drop out, especially if we can't recognize that the whole website has actually disappeared. We have a health Q&A site with all of the answers written by doctors. We're struggling with terrible indexing rate for our questions, even though the answers are well-written and attributed. Should we be trimming and no indexing the low-performing content pages? Should we be combining things into a single page? How can we ask Google to re-crawl a no longer but previously no index page? Good questions. So if you're looking at things where there's a low factor, low amount of pages that are actually being indexed, in a lot of cases that's more a technical issue rather than a kind of a quality issue. So if you're not looking at a situation where you suddenly add hundreds of thousands of pages to a website from one day to the next, where we might kind of take a step back and say, hey, we should kind of double check the quality first before we go and crawl so many pages. But if you're looking at something that's more kind of naturally been growing, then if you're really seeing a really low amount of pages that are actually being indexed, then that's probably more a matter of a technical issue than a quality issue. So one thing I'd recommend doing there is first of all, making sure that you're actually looking at the right metrics. So if you're looking at the sitemaps index count, for example, compare that to the index status report in Search Console, if you see a big difference between those two reports, so maybe the index status report shows 100,000 pages index and the sitemaps report shows 500 pages index, then we're probably picking up different URLs as canonicals for indexing than you have in your sitemap file. And that's something you probably want to kind of look into. So it's less a matter of ranking in a case like that, but we're picking different URLs than what you supplied. So that might be confusing to you and that might be throwing off your reports if you're looking at the sitemaps index count. And one thing to do there, or what I'd recommend doing there is maybe splitting a sitemap file up into smaller chunks so that you can kind of figure out which part of the sitemap file is actually being indexed badly, take some of those sample URLs and do an info colon query in the search results for them to see is this URL actually being indexed with a different URL from your website. And oftentimes you'll see that's the case. You'll do an info query for one URL and you'll see slightly different URL that's actually shown in the search results. It's not a perfect test for which one is the canonical version but it's a pretty good guess. And if you see that we're picking up a different version of a URL, then try to figure out like where is that URL actually coming from? So double check the pages to make sure that there's a rough canonical on these pages that matches the one you have in your sitemap file. Upper case, lower case, all of that matters. Tralink slash or not, that matters as well. Also double check the internal links on your website. Are you using the same URL for all internal links within the website? If you have an hreflang setup, are you using that URL for the hreflang as well? All of these things kind of add up on our side and based on these and maybe some other factors we try to pick a canonical URL to show. And that's not always the one that you have in your sitemap file. So that's something where you kind of need to make sure that all of your signals align and it's really clear for our algorithms that this is the URL that you want and none of the other URL variations are actually findable within your website. So that's kind of the first step there and making sure that the metrics that you're looking at are actually good. If the metrics that you're looking at are actually good, then I would double check to make sure that we can kind of crawl this website at a reasonable rate, which is kind of tricky to measure, but one thing you can look at is the crawl stats in Search Console with regards to how fast we can crawl an average URL, how many URLs we're crawling per day. To kind of see is that within the range that you're looking at there? So it's hard to say what number of URLs we should be crawling for a website every day, but you know how many pages you want to have index and you can kind of make a guess is the number of URLs that we're crawling every day kind of reasonable compared to the URLs you actually have on your website. And if you see that this number is really low compared to what you actually have on your website. So for example, if you have 1,000 pages on your website and we're only crawling 10 every day, then that would take like probably forever for us to actually get to those 1,000 pages. So in a case like that, I would look at why would Google might be crawling so slow, which could be something like your server is really slow itself. Maybe it's returning a lot of server errors. You can find that in Search Console as well. All of these things can kind of add up. John, hi, this is, I have a question. Sure. Yeah, actually I was working on my website for a couple of months and then I went into researching more into that topic and I couldn't update much. And when I was working on my website, it was ranking well. And certainly when I tried to do research more on that topic, learning more into that in depth and finding out new contents. And then my old contents were gone down slowly. And then I'm not sure what should be next approach. And I have been watching your webinar from a couple of days and I'm getting kind of a message that it can, the crawling can start anytime, any moment. And I want to know what exactly approach I should do and how I can rectify those, if there are any issues and how to find it out. Yeah, so I don't know. I think it really depends on your website. So with regards to creating content every day or not creating content every day, I think that's something that depends a lot on your audience and what you're writing about. So if you're writing about technology topics, for example, then maybe you do want to make sure that things are always up to date. On the other hand, if you're writing about things that kind of stay relevant for a longer period of time, maybe you don't need to make changes every day. So that's kind of something that depends on your audience. I'm into the second option, not technology part. So it's all about meditation and making your willpower stronger so that it will make many new upcoming young people who can use that website for a long time and to learn more about it. So that's the whole idea why I stopped in between to do more research into it. So I think that's perfectly fine. I think it's normal for a website to fluctuate in traffic and rankings. Sometimes there's more interest, sometimes there's less interest, sometimes there are other options that we can show. And if you take the time to really make sure that your website is not just kind of similar to the other one, but really a step above all of the other ones, then that's a long-term investment that I think is useful for any website. Correct, and to whom we should address if I have any queries about my website and to whom I can ask questions on email. If you can share, then I'll post my queries to them. Yeah, we do have one-to-one support for website questions. So the Webmaster Help forums would be a good place for that. Wonderful. So that's something we also have them in Hindi if you speak Hindi, I don't know. So that's kind of where I would go. But again, if you're focusing on making sure that the content of your website is really as high quality as possible and you're taking time to research that topic a bit more, then I wouldn't worry so much about these day-to-day fluctuations because you're targeting kind of the long-term gain of making sure that your website is really an authority in this area. And sometimes along that way, you'll see some things going up and going down, but the long-term trend is kind of what you should be aiming for. Thanks a lot, John. Nice talking to you. Sure, no problem. All right, let me just double check what kind of questions we have left and then I can open it up for all of you. I can stay a little bit longer so we can try to get as much as possible in. Let me see. There's one question about multi-regional, multi-lingual websites, which option is the best? I don't think there is one option that's the best there. There are different approaches that you can do there. So one thing I'd recommend doing there is there was recently a podcast with Alayda Solis, I think, Edge of the Web podcast, something like that. And she talks about this topic for long period of time and has all of the different options there. I would definitely check that out. That was a fantastic coverage of all of the international issues. Let's see, I think that's pretty much it. Most of the other questions, I think we've answered in one form or the other, either today or before as well. So let me open it up for all of you. I jump in with a couple of questions. Sure. There is this trend with the near me pages where we basically serve dynamic content related with the location of the one that searches. So for the US, since Google is only crawling from California, what would be the best technical approach to deal with those pages? It's technically just one page, but based on location, you serve different localized content. Is there like a must to have for those pages like technically set up-wise? I should really write something up about this topic. Good to keep reminding me. Like you said, Google mostly crawls from the US. So if you change your content significantly based on the location of the user, be it by country or by city or region, then that's something to keep in mind because Google will be picking up the content from the US. Most of the time, the IP addresses are geolocated to San Francisco or something like that. So what I would recommend doing there is making sure that all versions of your page have the kind of a shared content block on them that describes what your page is about and gives kind of general information with things that can be used for indexing and ranking. And if additionally you have something that is really relevant for users in individual regions or languages or however you want to split that up, that's something you can definitely do additionally. But really make sure that at least there's one shared content block on those pages that matches what Googlebot should be using for indexing. Okay, makes sense. So to have some type of boilerplate, making sure that Google understand what the page is about and then put the dynamic location state-based or what it is based on. Yeah. Also on crawling follow-up questions. So if you have a block of content on the page that is displayed with a small delay or has like an overlay and basically Google fetching like it won't render it. It will show like a white space. Would that be a big problem or Google anyway will read that content when it's crawling the page because it's on the page anyway. It's just does, it's not displayed directly. Would that be a big issue if Google doesn't see it when it's rendering or you can pass this one? I don't know, it's hard to say. So you're saying it's within the HTML already and it's just kind of being made visible a little slower? Exactly. So if it's within the HTML, then that's already a good step towards us being able to understand that this is actually on the page. So that's kind of the first step with regards to being visible or not. That's sometimes a bit tricky because if we render that page with Googlebot, with fetching render, for example, and we don't see that content visible, then it might be that we assume this content is actually invisible on this page and that we kind of don't put that much weight into it. It's like those slides. It's going to be exist. Okay. Yeah, I mean, it's something where it kind of depends on what you're trying to achieve. Some people say I don't want this content index because maybe it's like an age interstitial. You have to be so old to visit my website. But if it's actually the normal content on a page, then that's something you probably want to have it displayed fairly quickly. If it's content that's not critical for the page, then maybe it doesn't matter. So if it's just images that are kind of being displayed slowly and the textual content is actually loaded right away, then maybe that's perfectly fine. Maybe that's kind of a design choice that you're making. But it wouldn't affect us because we can still get the textual content right away and see the text itself is actually visible. Makes sense. Perfect. Thanks. One last question and I'm done. I did ask you this like probably like two years ago and I want to just circle back pagination setup. So if you have lots of pagination pages, yeah, the standard approach from Google perspective is clear. We're going to have next. However, Google is still spending a lot of crawling budget on those pagination pages and even using some of the pagination pages to display directly in search. So basically it's like lending pages for organic directly and it kind of doesn't make sense. In order to do that, I managed to have pretty good results in no indexing everything after page two. So basically you remove in real prep next and no index all pagination pages. Google did slow down crawling, slowing the no index, but is there any downside? Like, I don't know. Will that help with topicality for the first page and you lose that? Is there like any downside in killing basically all those pagination pages or is it paid for in terms? That's something you can do. The main downside I would see there is if we can't get to the actual content pages themselves. So if one product on your website, for example, is always listed on page three and that's always blocked with a no index, then maybe we don't see a link to that specific product within your website. But if it's a no follow, so basically we will end up to that product page or whatever that detail page is and it can index the actually page that is linked from this listing pagination pages but it's just not gonna see the content on the listing page page three or so. Yeah. I think it kind of matters how you have that set up on your website. So in general the thing that sometimes is a bit tricky with regards to no index and follow, especially when you're looking at things like paginated pages or just general web pages in general where you have a no index on the page but you want to follow those links is that sometimes we'll use this and say, okay, we were able to pick up these links and follow them and sometimes we'll look at this and say, oh, you're saying this page shouldn't be indexed. Therefore we can ignore everything on this page. That makes sense. If you find from the internal linking structure are the ways to link to those pages and you kill the pagination pages then no downsides whatsoever. Exactly, exactly. So for example, if you have related products on the bottom of your products then that's kind of cross-linking between related products. If you have category pages that show the full content or subcategory pages then you don't need all of those paginated pages. So you basically can even put a no index, no follow as long as the cross-links will manage to like link everything else from other sources, not the pagination. Exactly, yeah, exactly. Perfect, that's really good to hear. I need to record that and cut it out to use it. Okay, perfect. Thanks. All right, more questions from any of you. What else is on your mind? Hey John. Hi. Two quick questions. One is regarding the search analytics API. Let me give you a scenario. For example, I'm grouping by query and I'm pulling for a certain date like, I don't know, 100 rows or something like that. But then I also add all of the other dimensions and then I get zero rows. Is this because it's getting too specific and Google kind of has to hide the data to protect user privacy or might be a bug or something like that? Probably the first one with regards to showing, especially if you're looking at things that include the query, then that's something where we do apply some filtering. The other thing to keep in mind is that for sites, I believe we have a limit with regards to the number of entries that we show in the search analytics API. So it's some, I don't know, fairly high number, but especially if you have a really large website and you're trying to drill down to some really small part of the website, it might be that we just don't have those exact entries that we can show within the API. Okay, but I'm guessing, so I'm not saying about filtering, I'm saying about grouping. So simply adding more dimensions so those 100 rows gets more specific. And since I'm getting zero rows, my only guess is that getting more specific, especially when you have query, Google kind of has to filter out that data. That's possible, yeah, yeah. Okay, and second question is, it's regarding international targeting. So let's say you have a university in Switzerland, so it has a .ch domain, but it kind of targets audience from around the world, people searching for masters in international studies or something like that. But again, it's on a CH domain, even though the whole content is available in English as well, and being a university, it's not that easy for them to kind of, being a pretty big university is not that easy for them to kind of switch to a .com or some GTLD. Would that impact, would that have a significant impact over how people outside Switzerland find the site in the search results? No, that shouldn't be. So you can be internationally active with a country code top level domain. The only tricky thing there is if you have one country code top level domain and you explicitly want to target a different country. So this is something that sometimes comes up with some of the kind of quirkier top level domains. I'll say like, for example, if you have .ly at the end, and technically you're saying, well, this is for Libya, but actually you want to target users in, I don't know, France, for example, or in the UK specifically, then that would be kind of confusing for us because you're saying, well, this is actually for Libya, but I want to target people in the UK, and so that wouldn't be something that would work that well. However, if you're saying, well, this website is from Libya and we want to be globally active, then that's perfectly fine. Okay, so it wouldn't have a negative impact on rankings in the UK, for example. Exactly, that would be fine. Okay, awesome, thanks. And a lot of times this kind of happens algorithmically anyway in that we can recognize the user searching for something global so we don't really have to kind of bubble up the local results. Right, I'm just not sure something like, you know, just as I mentioned, masters in international studies, or okay, not international studies, but something, some kind of program might be perceived as a global kind of intent versus a local one. Yeah, so at least the cases I've looked into, I haven't seen any signs that this is a problem and this is really something that the engineers try to cover by default in that any local company can be globally active as well. Okay, good to know, thanks. All right, more questions from you all. What else is on your mind? I have a follow-up question with the previous discussion if nobody else has a more important one. Okay, go ahead. What's the discussion that for listing pages, either e-commerce or any type of listing pages, Google might take into account as far as like a ranking signal, the amount of results that side of that page can generate, not necessarily the amount that it's displaying on the page, but like with a previous discussion related to pagination pages. So do you think that Google can take into account that I will put a plus one on this page because it has like, I don't know, 1,000 product versus this page that only has 10 and this is displaying those only on the first page? Could that be the case or it's a midge? It shouldn't be the case. So if you're like looking at different numbers of results on a page that wouldn't be a problem for us, the only time this is a problem for us is when there are no products on a page. So you open up a listing pages and it says I couldn't find anything. And that's essentially a soft 404 for us. We try to recognize those and drop those out of the search results because it's frustrating for the user if you're searching for, I don't know, a new iPhone in this style from this country and you land on your shop and the shop says, oh, I don't actually have this but I was just like showing it in the search results and that's a really frustrating experience for users. So we try to recognize the zero results situations and treat those as soft 404s and anything else where you have one or you have a hundred or a thousand results is essentially, it's a page. It has content on it, it has links on it. It's kind of useful for us as a normal page. And also like getting back, it won't be like a downside if you kill the pagination pages, for example, that, okay, this has only a few so it will not have that many good signals going into that. That's really up to you. That's something you can do either way. Okay, perfect, thanks. Hi, John, Kuldip again. Actually, yeah, when I started my website in first three months, it got indexed for a hundred pages and then suddenly it went down during my research team when I started doing more research into my topic and now it is up to, from hundred down study to 19 to 20, somewhat like that. So it is because the contents are not updated or a lot of people advised me to do backlinks and all purchasing from good backlinks from the higher authorities with the high DA and PAs and all, but I never gone for that. And I did my own, I just wanted to share my content, that's all. So is it because of contents are not updated regularly because of that index and has gone down or it is because of some other stuff I'm really not sure why it's gone down? It shouldn't be with regards to like the content being updated freshly because if it's not indexed, we don't know how often you're updating your content. So from that point of view, that definitely wouldn't be the case. I think some amount of fluctuation with the number of pages that are indexed is normal as well, but if you're going down from a hundred pages that actually have content to 20 pages, that seems more like a technical issue rather than anything else. Kind of that's a really low number of pages to have indexed for a web page website. So that's something where I maybe double-check the technical things in Search Console, maybe also post in the help forum and ask other people to kind of take a quick look, that you're looking at the right number, that you're kind of tracking things in the right way, that things are technically set up properly. One good thing that you can also do here is think about which URLs are actually indexed and which ones aren't indexed. So with 20 pages and 100 pages of content, you can probably figure out some sample pages that aren't indexed at the moment. And those are the pages that you can kind of look at from a technical point of view, why might Google not be indexing these specific pages? If you have 100,000 pages, that's obviously a lot harder, but with 20 and 100 pages, that's something you can probably do manually and figure out which way that should happen. Right, John. Yeah, that's it. Thank you so much. No problem. And I know you're over time already. Oh, problem, go for it. Okay, this one, it's all Search Console and all the URL parameters set overall. So besides, it basically has a map and like moving that map, it's generating like a parameter URL. And that made the Google index about 20,000 pages, which basically the same page of basically. Now the settings in crawl URL parameters, I've set it to no URLs. So basically for that specific parameter because of those parameters to be indexed. But Google still has about 20,000 in indexed right now. Will that solve the issues overall? That should help to improve things, but this is something where it's not a strong directive where you're saying this is a rule Google must follow, but you're saying like this is a hint for Google, like you don't need to do this. If you do it, it's like no problem, but you don't need to do this. So that's something where probably over time, the number of indexed URLs like that will go down, but it won't disappear from one day to the next. Yeah, which makes sense. And as like a backup solution, we've also put like when the URL changes with this parameter, we put real canonical to the first one. Would that speed up the process or it's pointless? That helps us a little bit, but if you're already telling us not to crawl these as much because with the URL parameter handling tool, then probably we won't see the real canonical that quickly. So it's like the right thing to do, but it takes a bit longer to be found. But the important thing is that that's not a directive. That's just a hint Google will still crawl those URLs, but it will try not to crawl them that often or... Exactly, yeah. So it helps if we're crawling too many URLs from your site, that helps. If crawling any of these URLs causes problems on your server, I would block them in robots text to be like really strong and say, Google, you shouldn't be looking at these pages. They crash my server every time you do that or that kind of thing would be blocked. That would be like really hardcore, but then they will still be in the index, right? They will not drop them from... They will drop I guess over time as well, but it's kind of a decision that you can make on your side, like how critical is it for you that these pages disappear or how critical is it that Google stops crawling these pages? Okay, makes sense. And also on crawl stats, so a huge spike. So like if an average page crawl per day, it's like, I don't know, around 10, 20,000, but then you see like in one single day going to 200,000, so it's a really huge spike. Will that be something to be happy about, like worry about what could be that behavior? Like explain a little bit. To see how... Most of the time when I see this, it ends up being something where we've seen a lot of URLs on a website and our algorithms are just having a really weird day and they just go, oh, just crawl everything. And it's not really a sign that anything is broken. Most of the time it's just our algorithms are weird. So it can be like getting over-reservation a little bit. Yeah, yeah, sometimes that just happens. And if in that same day also time spent on the page went down with, I don't know, half of that, would that mean that it's not hitting the, I don't know, or it's hitting like smaller pages? Probably, yeah. I mean, that's something you would see in the server logs. Maybe these are small pages, maybe these are static files that can be served very quickly, those kind of things. So... And anyway, the stats in the Chrome stats in such cars that it's everything, not only pages. It's also like CSS and JavaScript, every single page, right? And from every single crawler, not only web. Exactly, yeah. Including ads? Including, I think the ads, landing page bots, those kind of things. So also if you have AdSense on the page, I think that's also included because they have to look at the page to match the ads. So that would also be there. Okay, perfect, thanks a lot. Sure. All right, so maybe we can take a break here. It's been great having you all here. Good to see some people really hardcore sneaking around until the end. I'll be setting up the next batch of Hangouts soon and hopefully I see some of you all again. The more Hangouts are really nice also so we can join more easily. All right, fantastic. Yeah, I try to separate the time zones a little bit. Sometimes that works better for some people, sometimes both of them are terrible, but I can't do them 24 hours a day. So, good to see you. So nice of you, John. Thank you so much for giving us the opportunity to talk to you directly and answering the questions straight. And it's awesome to have you as a supportive hand. Thanks, thanks. Good to hear. Okay, bye. Have a great weekend, everyone. See you. Yeah, same there. Bye.