 All right. Welcome, everyone, to today's Webmaster Central Office Hours Hangouts. My name is John Mueller. I am a Webmaster Trends Analyst at Google here in Switzerland. And part of what we do are these Office Hours Hangouts where webmasters and publishers can join in and ask questions around web search and their website. As always, looks like a bunch of questions were submitted. But if any of you want to get started with the first question, you're welcome to jump in now. I would like to ask a question. Yeah, it is about the geoblocking because we have a web page which has a lot of video and programs which we're only allowed to show in our country. So we have geoblocks. So if people come outside, they're actually redirected to a page where it says that they can watch this program. And also if you enter the front page, you can only see content which you're able to watch. So my question is whether we can whitelist Google Cros or that is a logo or how we can fix that. So in general, you should treat Googlebot the same as any other user from the same region. So since we mostly crawl from the US, you would need to treat Googlebot like another user from the US. That's a bit, I don't know, problematic in some cases because the other way around would be no problem. If you have a website in the US and you say I want to block users in Europe, then that would be no problem. But if you're a website in Europe and you want to block users in the US, then you would be blocking Googlebot as well. So that's not really something that you can get around there or at least according to our guidelines. What you can do for video content specifically is specify which countries the content is available for. So what you could do, theoretically, is make it so that the HTML pages are accessible by users everywhere and that the videos only play in the appropriate countries. And the video files, those are things that you can show to Googlebot even though users in the US would not be able to see it because you can specify the limitations with Marko. Yeah. OK, but it is a no-go to actually whitelist. Yeah. Yeah. OK, cool. I just wanted to make sure because that was the easiest way around, but yeah. Yeah, I think from a web spam point of view, the website team would probably not take action on that. But according to our guidelines, that would not be appropriate. Yeah, OK, thank you. Sure. All right. Any other questions before we jump into the submitted ones? Hey, John, I have a question. We have a main domain redirect. So will it affect my data in Search Console? How do you mean main domain redirect? Yeah. Say example.com slash. It is redirected to the example.com slash en. So should I have to change my main domain in the Search Console? Oh, no, that's a perfect answer. If you're redirecting to a lower level page on your domain, then you can keep the whole domain in Search Console. You can, if you want, just verify the sub-domain or sub-directory, but you don't need to. OK, so if verifying two domains, like my data will be available in both the domains? Yes, yes. OK, thanks. All right, let's jump into some of the submitted questions. As always, if. Sorry, John, hello. Yeah, OK, one more before we go. OK, thanks. So I asked the question on the master's help community. The question is about the Google Search Console. In the old version of Google Search Console, we had a great way to discover blocked resources. Now, as I understand, in the new one, we have the URL inspection tool, the Help Center. So just use this tool if you want to discover blocked resources. So when I test my site tool, I see blocked resources, but I can't find the same data in URL inspection tool in Search Console. Well, I wonder why. And also, wasn't it better to provide the information about blocked resources for all sites, not on a single URL basis? Thank you. No, that's a good request. So I think we dropped that feature because we noticed that most sites were no longer running into problems with that. Because with the shift to mobile friendliness, that was a big problem. If a resource was blocked from crawling with robots text, then sometimes we can't tell if a page is mobile friendly. But that has improved significantly across the web, so we decided to drop that feature. But it's good to hear feedback that it was actually useful. So I'll definitely pass that on to the team. OK. No, I don't have any work around at the moment to get a broader list of all of the blocked resources. OK, thanks. Sure. Hello, John. How are you? Hi. Yeah, John, I have a question regarding the Webmaster Office hours, which was streamed live on November 2018. Oh, gosh. Yeah, it was way ago, so. Yeah, so in that session, you mentioned that the discovered but not indexed thing, which will not happen because the pages are duplicate, right? Or maybe the pages have the same theme, but they are having different content. But once the Google will crawl 1,000 pages, then Google will get to know. Right now, this website has the same design, same way of content showing on the website. So I mean, in this way, you mentioned this. If we are using the script-based title and meta description automation, if we are putting the title and meta description using the scripts, right? For example, I mean, right now we have 2,000 pages right now we have on our website. And we are using script automation by putting the Google meta data, meta data, everything. We are using this script-based automation. So you mentioned that it is not a good practice. And my question is, in the Magento, when people are uploading Excel sheets, right? So that is also a kind of automation because they are updating their meta data by using the Excel. So how Google is reacting towards the Magento websites and how Google is reacting to the custom-based websites which are using the script-based automation. OK. I think those are two quite different things. So I think what you're referring to is using Google Tag Manager to edit titles and description. No, no. We are actually not using Google Tag Manager right now. We are just using GTM only for the schema-based variable creation thing. So we are just using the script-based automation for our meta data. And this way, what we are doing is we are just putting, you know, in the Excel, we do concatenation, right? So the concatenation process, we are just using the script for that on our website. So every time when we upload, for example, 50,000 more pages for our website, so we have a template. We upload that template again. Then every page has its own meta tag, all tag, and everything. So because right now, we have, you know, products we have different. We have different content. We have different fact pages on our page, different, different pages. But still, our indexing is not improving. I mean, my question, my main question is, is it because of the design? Is it because of the automation? Is it because of the script? I mean, what could be the reason? Because right now, we are doing everything. I mean, at our end, we are trying to keep unique content on our website. We are doing everything, I mean, you know, in a best way. But still, we are facing this problem in the indexing way. So we have like 28,000 pages indexed on Lyon. So that's why, yeah. OK. So I think there are a few aspects that might be confusing and being mixed up. So in general, when you say you're using a script-based approach there, it sounds like you have these scripts running on the server. It's not Java script. Yeah. It's not on the server. Sorry to interrupt you. But it's not on the server. But once we, before uploading the website live, what we do is we have the developer version of our website. What we do is we upload our data on the developer version. And then the developer, what they do is they upload that version on live server. So we are not actually creating the script-based thing on live website. So we are doing on our before version, you can say the first version of the website. Yeah. OK. So I think, in general, you wouldn't need to worry about the script part, because it sounds like I don't remember that particular hangout. So it's been quite a while. But one of the things we have talked about is using JavaScript to update titles and descriptions. And that would be something very different from what you're doing. So it sounds like you're uploading things, and then you have a script that processes them, and then you upload that to the server. And that results in normal HTML pages being uploaded to your website, which we can process completely normally. So that's very different from using JavaScript that runs in a browser to update the titles and the descriptions. So from that point of view, I think you're fine. I think the general problem that you're seeing is just that you have a lot of pages, and only a part of them are being indexed. Yeah. And that's something that can be quite normal. It can also be a sign that maybe there are some technical issues there. What I would recommend doing is posting that maybe in the Webmaster Help Forum and having some other people double-check your site and just give you some general advice. It could be that, for example, that we're just not convinced about the quality of the website. It could be that there's a technical issue that's blocking us from crawling these pages completely. But it's very hard to say just off the hand. I think, in general, the approach that you have with uploading your content with an Excel file and your server generates pages out of that, that's perfectly legitimate. That's something that a lot of sites do. Yeah, because I mean, when I check the Magento processing, when I check the R website, so we are using PHP. Magento is also on PHP. So Magento is right now moved to React.js on N2.3 version. So they have some different things. But right now, I was just confused. Like, if we are doing the automation process in Magento, then I mean, how could it harm to our website in the custom way? So that was my question. I think from the automation that you're doing with uploading the information with a sheet, that's perfectly fine. That's not an issue. And Magento is a fairly big platform in that a lot of sites use it. So if there were a general problem with Magento, I think that would be very visible. And it would be something that they would fix very quickly. Yeah, they'd do that, yeah. So I would just try to get advice from other people, specifically for your website, and see if there's something small that maybe you can change, or maybe you have to kind of find other approaches to make the website work better. OK, sure. I'll get it done on Google Webmaster Forum. Thank you. Cool. Yeah, thank you. Hi, John. All right. Do you mind if I ask a question? Sure, go for it. So I'm working with a site at the moment. They have actually posted this on the forum. So what's happening is we've got a bunch of pages that are no-indexed. They then get, the no-index gets removed, gets introduced to the site map. They then throw a load of errors in Search Console that they're in the site map, but no-indexed. If you hit the revalidate button, it just says it checks a few, and then says that there are no-indexed still. It seems to me that the revalidate button doesn't work, or because we can go through them, and there's definitely no ex-robots header or tagging the head of the page, but it still just keeps throwing this error, and we wondered if. So the pages are not no-indexed, or they are? They previously were no-indexed. It's a user-generated site. So the no-index gets removed when the content reaches a certain threshold, i.e. if it's had enough engagement. They then get put in the site map, and at that point, they error in Search Console, saying that they're no-indexed, but in the XML site map. So then there's like 2,000 of them at the moment, but you can click the revalidate button, and it just says, no, they're still no-indexed, even though they're definitely not. OK. I suspect what's happening there is that Search Console is a little bit faster than the rest of indexing, which is surprising sometimes. But what's probably happening is we're seeing that these pages are no-indexed, and Search Console recognizes that they're in the site map file because that's where they are now, and then Search Console will throw an error. So basically, we're taking the old status of the no-indexed pages and seeing that they're now in a site map file and thinking, oh, you added no-indexed pages to the site map file, and we haven't actually reprocessed the individual pages since you've added them to the site map. So does the revalidate button not actually go off and re-crawl all of those pages? Revalidate. Is that in the index status, or is that the site map? No, it's like a, so you can go into Search Console, you pick the section of errors that you've got, in this case, in site map, but no-indexed, and there's just a button that says revalidate, and from what I understood, it goes off and rechecks all those pages, but it doesn't seem to do that from what I can tell. It should. It should. The idea there is that it checks a sample of the pages first. I think maybe five or 10 pages and double checks that the error is resolved, and then it'll trigger a reprocessing of the rest of the pages there. I'm not 100% certain how it would handle the situation where you have the site map file in between if it just revalidates that these URLs are in the site map file or not, or it actually re-crawls the URLs themselves. But I can double check with the team on that. All right, cool. Thank you. Cool. All right, let me run through some of the questions that were submitted, because people spent a lot of time pushing them in there, so we should get through some of those. What could be a reason that a huge listing, very popular site, not being switched to mobile-first indexing? Essentially, we have multiple classifiers that try to understand when a site is ready for mobile-first indexing. And usually what we've seen with larger sites is not so much that we'd say this is an important site. We'll switch it over quickly, but rather we'll switch it over when we think it's ready. And with larger sites, what often happens is there are multiple sections of the site that use slightly different setups. So that's something that happens quite a bit, where you have maybe multiple CMSs involved, or multiple backends and frontends involved within the same domain. And it can happen that maybe some of those systems are not ready for mobile-first indexing, according to our classifiers and others are. And in a case like that, we'll hold off and wait a little bit to make sure that everything is really ready. Also, with really large sites, what we've started doing is shifting a handful of URLs over to mobile-first indexing, maybe 1%, maybe a few percent, and seeing how the site generally performs. Are they seeing that indexing is working well with mobile-first indexing for that site? And if so, we'll ramp that up slightly. So all of those things are aspects that you might be seeing there with mobile-first indexing. I wouldn't see it as a sign that anything is broken or wrong if your site is not switched to mobile-first indexing yet. It might just be that our classifiers are still a bit cautious and try to stay on the safe side. The meta tags, keywords, and news keywords aren't used anymore, I believe. However, I see a lot of publishers are still using it. Is it just redundant? Should we use them, essentially? We don't use them at all for search, so you don't need to do use them. But at the same time, they also don't cause any problems. I've used the keywords, meta tags for my own sites just as a way to help me kind of focus on a specific topic so that I know what I want to write about on a specific page. And that's more for myself and not something that search engines would really care about. So maybe others are doing that, too. But again, this is something that essentially is not something that you'd need to fix or change. We ignore them if you want to provide them. If your systems provide them automatically, no problem. I recently uncovered a big canonicalization issue on a large-scale site where many pages were incorrectly being canonicalized to other pages with non-equivalent content. Google was simply ignoring the rel canonical, which makes sense. Now I'm surfacing more examples across the site of Google ignoring rel canonical, also where it makes sense. This got me wondering that if Google sees the wrong canonical tags on a site often, if it then starts to not trust the user-selected canonical URLs across the whole site, and if it does lose trust, then maybe Google systems think it's better to select canonical URLs across the site on its own versus using the canonical tag. Do you know if that's the case? So it's theoretically possible that we ignore the canonical tag across the whole site, but I think that would be extremely rare, because that would generally be something that our engineers would have to do pretty much manually. What usually happens is with the rel canonical tag is that we do this on a per-page basis. And on a per-page basis, we use a number of factors that come into canonicalization, including the rel canonical, including information about the URL, about the content, about other URLs that have the same content, and we try to pick a canonical based on all of those factors. And the rel canonical alone isn't enough of a signal for us to say we will always be able to trust it. If we see other signals that come into play, then we might ignore the rel canonical on a page like this. And that's something that happens on a per-page basis, so not something where, at least as far as I know, we would do this on a per-site basis and say, well, the canonical links on this website overall are wrong, therefore we'll ignore them completely. It's more that on a per-page basis, we'll try to pick the canonical URLs that we think make sense. I have a lot of excluded pages in my search console. My valid pages are about 1-tenth the number of the excluded pages. And it's a big site with 170,000 valid pages. I'm wondering if excluded pages count towards our crawl budget. Once Google decides a page should be excluded from the index, does it still crawl the page periodically? Should I be concerned that the high ratio of valid to excluded pages is eating up our crawl budget? That's a good question and a complicated one, I think, in the sense that, yes, the excluded pages are counted in the crawl budget in the sense that when we try to crawl them and we end up not including them in the index, then we've tried to crawl them and they count as an attempted crawl and essentially count in that bucket of crawl budget. However, what usually happens is when we exclude a page for any particular reason, that could be because maybe it has a no index tag on it. It could be maybe we have a duplicate URL and we've picked a different canonical. Then what generally happens there is we crawl these pages a lot less frequently. So while you might have a lot of pages that are excluded and we might be recrawling them from time to time, we'll be recrawling them a lot less frequently compared to the URLs that we think are important for your website. So on the one hand, they do count in the crawl budget. On the other hand, the effect within your site's crawl budget is generally minimal. Also, when we have a number of URLs that we want to crawl for a website and we also include a number of maybe excluded URLs or URLs that we're not sure about, and we run into a situation where we're limited by your site with regards to crawl budget, then we will try to prioritize the URLs that we think are more important over the ones that are less important. So let's say in an extreme case, we can crawl 1,000 URLs a day from your website and we know about 900 URLs that are good and about maybe 10,000 URLs that are from this excluded bucket. We'll try to get those 900 good URLs in first and then the rest that we kind of have available there we'll pick from the excluded bucket just to make sure that we're not missing anything, that pages from the excluded bucket did not end up suddenly becoming includeable and that maybe a no index is gone now and we can pick that up again. So yes, they're included in the crawl budget, but generally it's not something that you need to worry about there. OK, two really big questions. Let's see, I am working for a travel agency. We have our main platform and some that revolve around the main one. The revolving ones are all linked to the main one, but they're not linked between each other and all have a different domain. The revolving ones spoke about the same thing, but ranks with different keywords and content. So the subjects in these are identical. It's all about travel. The content is different, but there can be similarities. My websites are all divided into continents and we're speaking about a lot of countries and cities in those. So it can look the same. We're talking about the same cities and locations in each of those, but worded differently, like if it was a different opinion on an identical subject. Let's see, so maybe before I get into the questions, this sounds a lot like something that you might want to watch out for in that you're creating a ton of content that can look a lot like doorway pages in that you're just kind of switching different keywords across all of these pages here. So that's something where I would tend to be pretty cautious about just running a system like this with so many different domains and sites that essentially cover the same content. A lot of times what you'll find is that if you have fewer pages or fewer sites, you can perform a lot better in search because we can see that these are really important pages versus you're kind of diluting things across a lot of pages. So let's look at the questions. My issue is that I'm using a premade theme and I wanted to know if those would have an impact on the ranking of my websites, not necessarily. So whether or not you use a premade theme or a custom theme that's essentially up to you from a user's point of view, that might be something that users recognize and maybe that's something where users will say, well, I don't know if I can trust this website if they're just using a theme that kind of came with WordPress by default. But that's essentially up to you. Let's see, the second question, this is also about having multiple websites. Would applying a no follow rule suffice? So I think it's basically between the different websites or should I do some kind of Jedi mind trick, like transforming those links into spans and using JavaScript to redirect to my domain. So I think in general, the links between these sites and pages is less of a problem than just the plain existence of so many variations. So I wouldn't worry about trying to hide any of the links between those sites. I would instead try to find ways to combine a lot of these sites and pages so that you don't have to have that many separate ones. Usually having fewer sites means you, you can make those a lot stronger, you can concentrate your energy on those sites. A question about JavaScript, if I can see my text in Google's mobile friendly text, can I ensure that Google doesn't have a problem with reading and indexing my content and my pages? For the most part, yes, that's correct. There can be sub-doll issues with regards to JavaScript, but in general, the mobile friendly test is something that uses the new chromium setup that we use for Googlebot. So if it works in the mobile friendly test, it should work for indexing as well. One of the things to watch out for here is that the mobile friendly test, as far as I know, doesn't follow the robot's text rules. So that's something where you might want to use the inspect URL tool in Search Console to make sure that actually your JavaScript files and your server responses and all of that are working well from that point of view. I changed normal images to Instagram embeds on one of my articles and saw a decrease in rankings, clicks, et cetera, for image search. It was a 43% decrease in image search clicks overnight on a very reliable article. Can you talk a bit about the difference between normal images versus Instagram embeds from Google's perspective? So I thought that was an interesting question and I created a test page to see how this actually works because it really depends a lot on how Instagram sets this up because you're essentially just taking code from Instagram and putting it on your website. And depending on how they set up that code on their end, it can have an effect on your website. So in general, what kind of the bigger picture change is you're going from a situation where the images are embedded in the HTML directly on your website, where they're really easy for us to discover and really easy for us to crawl an index to a situation where we have to process some JavaScript and do some fancy processing to get to those images. So that means it's a lot more work for us to actually get to those images. We can recognize those images and we can crawl those images using the mobile friendly test shows those embeds as well. So it kind of looks okay. However, what I noticed is specifically with the way that Instagram embeds these images, they use an iframe to embed kind of the posts from Instagram, which kind of makes sense. But with an iframe, you're basically adding another layer of interaction between your page and the images. So it goes from your page to this iframe and then from the iframe content to your images. So that makes it a little bit harder for us to pick up those images. But what really kind of breaks the story for us is that within the content that is embedded from Instagram, within the iframe, they use a no image index robots meta tag. And this meta tag tells us that you don't want those images indexed together with the page itself. So if we just look at that iframe content, we can recognize that there's an image there. We can crawl that image. But with that meta tag, you're basically telling us that you don't want this image indexed together with that landing page. So essentially, by switching from a direct embed of an image on your website to using Instagram embeds, you're kind of telling us that you don't want these images indexed for your website. And with that, I think it would be normal to see a significant drop in image search traffic to those pages because you're essentially telling us you don't want these pages to be indexed like that. So from my point of view, it essentially kind of comes back to you and kind of your preferences there. I can understand that sometimes it makes sense to embed Instagram posts directly or social media posts in general because you get a lot of added value from just kind of the whole everything around that with regards to comments and maybe the likes and the shares and all of that information that is available within the embed. On the other hand, it makes it a lot harder for us to actually index those images. So that's something that you almost need to balance on your side. Do you need to have all of this extra detail around the images? Or do you really need to make sure that those images are well indexed for your website? And depending on the website, you might have preferences one way or the other. If you want to have both kind of the Instagram embed and to have your page ranking for those images, then that will probably be tricky and might involve weird situations like having to put it in there twice. Since a few months, we're seeing a new strategy where big news websites lease a whole subfolder or subdomain to a media company. I think we've looked at this a few times here as well. So the question is, this is Bami, and I don't like it. And does a search team know about this? We do talk about this with the search quality team from time to time. And we do try to find examples where we think that things are kind of worse for users and maybe also situations where we think that things are actually pretty good for users. In general, I think these kind of changes happen from time to time in that people will find something that works really well for them. And it happens to work really well in search. And then suddenly, everyone does it. And then at some point, it becomes so, I don't know, kind of problematic in the sense that it results in a lot more low quality content. And then the websites themselves get seen as low quality content and things kind of settle down into a more reasonable place. I haven't looked at this situation for a while now, but I feel it's something where things will be settling down into a more reasonable place. And in general, when it comes to changes like these, we try to avoid going down the route of manually kind of adjusting the rankings of individual websites because of these issues, specifically when it comes to kind of topics where it's more about quality rather than pure spam, then we wouldn't have the web spam team go in there and say, like, we need to manually adjust the ranking of these websites. But rather, what we would try to do is algorithmically try to recognize the situation overall and kind of work out where the high quality the useful content is within setups like this and to promote that appropriately in the search results and to find places where our algorithms can automatically recognize that this is not so useful for users overall and to make those less visible in the search results. And sometimes this takes a little bit of time. If a site has a fairly large volume of internal links which generate 301 redirects to reach the final destination pages, will this impact crawl budget? I see Google regularly visiting the 301 redirect URLs and I'm assuming that placing the correct links to the destination pages would be better utilization of crawler resources and would speed up page load time significantly for users. This is a fairly large e-commerce site where these kind of links are regularly and repeatedly available 10,000 plus times. In general, if we recognize that a page just bounces from one URL to another in the sense that we find a link to one URL and it redirects directly to the next one, then that's something that wouldn't negatively affect the crawl budget in the sense that it's like we can process it right away. It can mean that we spend a little bit more time on a per URL basis to crawl this website and that can in turn still affect the crawl budget. So in particular, if we recognize that we need so many seconds to actually get to the content, then we'll try to limit the number of simultaneous requests to that website just to avoid causing any issues and if each request takes longer then that in turn does mean that we are not able to crawl that much. So theoretically, that could play a role. In practice, it seems pretty rare and especially if you're talking about something like 10,000 pages, then for most websites being able to crawl 10,000 pages, especially if it's a fairly large e-commerce site, that's not something that would cause any issues there. So I think you probably see a small, incremental change with regards to our crawling if you were to link directly to the target pages but you probably wouldn't see anything significant when you're talking about 10,000 pages. If you're talking about all pages within the e-commerce site, so maybe you're always linking to a tagged URL and from that tagged URL you're redirecting back to a clean URL and you have that millions of times across the whole website, then that is something where I'd say you probably would see significant change in how much content we can crawl from that website by fixing that setup. But if you're talking about 10,000 pages within an e-commerce site that has millions of pages, then that seems fairly insignificant overall. To increase the EAT of a medical page, should I use article schema, for example, or for example, web page or medical web page as a latter two has an option for reviewed by property? Or maybe Google can find that the article was reviewed from the context if I provide such details and schema property reviewed by is not necessary. I think that's kind of up to you. We do try to recognize kind of these additional details about information about the author, information about the reviewers, about the website overall through a number of ways, partially through the content directly. So kind of similar to how users would see it. If they go to the page and they see kind of information about who has reviewed this content or who has provided it, that's really useful. If it's just like hidden away in structured data, then that's not very useful for users because users tend not to use view source when looking at a page to determine whether or not they should trust it. So I would try to find an approach that works well primarily for users and focus on that. With regards to article or web page, that's something where I'm not exactly sure what the difference there would be. It seems that from a semantic point of view, they're slightly different. There's a bit of an overlap there, though. So depending on the page that you have, I would try to pick the appropriate one there. So if you have an article, then maybe the article schema is the right one. If you have something more like a tool or a lookup or a forum or something, then maybe article is not the right approach there. Google has a penchant for adding branding to title tags and search results where there are none written on the site. For example HubSpot has a guide to cryptocurrency without the brand name in the title and Google added HubSpot to the headline in the search results. Is this purely aesthetic or is there possibly more to it? For example, a signal that Google likes to see sites add branding to titles themselves. So for the most part, we do this automatically because we find that it helps users to better understand the context of the individual pages that we show in the search results. And a lot of times I think we do a fairly good job of that. Sometimes we pick the wrong ones and for those that we pick wrong, it's useful to get feedback on that. So if you see something weird happening with the title tags, then feel free to let us know about that. But it's not something where I would say you have any kind of a ranking advantage if you add the kind of a site title to your title tags or any other kind of advantage there. It's essentially purely something that we end up doing for users. Sometimes we also rewrite the titles. Sometimes we have to shorten them if they're on a mobile device, for example. The same thing happens with the descriptions. Sometimes we adjust them subtly based on the query that was made. So all of these things are aspects that we try to do to make it easier for users to understand how your page is relevant for them in their specific situation. And it's not a sign that you have to copy that and do the same thing on your pages directly. I have a question about Google Analytics. For one of my clients under GA organic keywords, I see something like NP- or NP-user slash register. What could possibly be that I'm doing wrong in terms of tracking? I don't know anything about Google Analytics, so I can't really help you with that. My guess is maybe you're providing URLs to track on your own, but I really don't know how those things end up in Google Analytics. We have a website with 50 million monthly page views, and when people search for our brand directly, they don't see site links nor the site link search box below our homepage result. Search Console detects the site links, search box marked up correctly, so it just won't show up in the search results. Does this mean that Google considers our site to be low quality? 60% of our traffic comes from organic search, and the average session time is over four minutes. So no, it doesn't mean that we think your website is low quality. Maybe just, first of all, that's something that I really wouldn't worry about specifically with regards to the site links or the site links search box. We show site links and the site links search box when we think that it makes sense for a site and for the queries that are going to the site, and it's not necessarily something that is tied to the quality of the website. Obviously, the website could still be low quality, so it's not that I'm saying your website is high quality, but just because we're not showing site links or a site links search box is not a sign that we think the website is low quality. Specifically, to the markup of the site links search box, that's something where if we were to show a search box below the listing, then we would use the markup to show the version that you prefer to have shown, but it's not the case that just because you have the markup, we would be more likely to show that box. So it's still kind of as a first step. If we were to show a site links search box, then we would use a markup. It's not that if you have the markup, then we would show the site links search box. My question is regarding multiple countries targeting for multiple products. If I have product one, which is in demand in the US and product two, which is in demand in Canada and there are other products for both countries. Oh, this is complicated. If I target product one, product three and product four in US, will it make it complex for Google to understand in which country I'm targeting my entire website? Usually this is not an issue. So in general, when it comes to geo-targeting, you can specify that in multiple ways, but it needs to be a clear section of the website. So for example, you can say your whole site is targeting one specific country, or you can say I have multiple sub-domains or multiple sub-directories, and if you list those separately in search console, you can specify the geo-targeting for those parts individually. What you can't do is specify geo-targeting for individual pages within your website. So kind of with that out of the way that kind of means if you have a shop with multiple products on it, then you would use geo-targeting to specify the primary geo-targeting of the website overall, or you can use geo-targeting to say I don't want to have any geo-targeting for my website, I just want to rank normally. And probably that would be the right approach here in that you're essentially a global website and some products are more popular in individual countries and that's perfectly fine. We will try to rank them appropriately but there's nothing special that you need to do there. So there's no special markup that you need to put on these pages to say this product is specifically for the US and the other product is specifically for Canada and maybe the third product is global. We'll treat all of these products as being global and still try to rank them appropriately within the individual countries. And a Google My Business listing question which I don't really have any insight on. In a recent webmasters meetup it was said that the CCTLD is still a strong ranking factor. So it doesn't mean that a .com website with a separate folder is not a correct practice. No. Essentially when it comes to geo-targeting we use two main factors or two main ways to try to figure out the country. On the one hand if you're using a country code top-level domain then that's a pretty clear sign that you want to target that country. On the other hand if you use a generic top-level domain then you can specify that in Search Console and both of these ways are equivalent. So if you have a generic top-level domain you can specify the geo-targeting for the whole website. You can verify just the subsection of that site and set the geo-targeting for just that subsection in Search Console and all of that is essentially equivalent. In practice that means you can use the kind of the setup that you think works best for your website but there might be some maybe market-specific approaches that you want to look at as well in the sense that from an SEO point of view like you can do all of these things but from a practical point of view maybe users in one country really prefer to see their own top-level domain in the search results and they're really kind of cautious about the more generic ones and then that's something where it's more a matter of marketing which setup that you use. Sometimes it's also a matter of policy in that maybe if you're for example if you're targeting users in China maybe there are some policy reasons where you'd have to say well I need to use a Chinese top-level domain because that's kind of what's required there. I don't know if that's the case but I could imagine there are situations that end up like that. John. Can I just follow up on that question? Okay. So I'm in current search console I haven't looked but so can you set up forward slash US and target US and then forward slash UK and target UK can you do all that in the new search console? I think geotargeting is not yet in the new search console so not so you'd have to do that in the old one but you can yeah you can kind of make some match but the thing that you can't do is if you use domain verification then that's only in the new search console but if you have the subfolder verified then that would be available in both of them. Okay. Yeah hi John. Hi. So John actually this was my question regarding geolocation so a little different a little conclusion was like best coffee shop in New York one website is in New York or in USA which is targeting US and one website is in India which is set up country target in India then how geolocation works basically like somebody searching from India will see India site first. Possibly. Possibly. So what happens with geotargeting is when we recognize that a user is in one country and they're looking for something that seems to be specific to their country then we will use geotargeting to promote the local sites so there are a lot of situations where if you search you're basically trying to search globally if you're searching for an instruction manual on one product then you don't really care which country that that's from and then geotargeting is not really a primary factor on the other hand if it looks like you're searching for something to buy then maybe geotargeting should be a stronger factor so that's something where if you're doing some query that is kind of artificial like best coffee shop in New York while located in India then I could imagine that our systems get a little bit confused because they don't really know exactly what you're trying to do but if you're searching for the best coffee shop and you're located in one country then we'll try to bring results from that region so that's kind of I think with that specific query example that you had and the location that you had there then that's not really something that would map well to the general kind of user side of how how users use geotargeting Hey John and I so we're a site that's in the Alexa Global Top 1k and around the 1st of April we've noticed that hundreds out of the many thousands of site maps that we have have since then been reporting incorrect index data via the API so in some cases for ever since early April the index count is the same and we know for sure that that can't be the case the index count in some cases is reported as 0 or in other cases the index count just seems wildly inaccurate meanwhile the submitted count does seem accurate and so essentially we posted on the webmaster forums asking for some insights into the issue and to see if others were facing a similar problem but we weren't able to gain much ground there so just kind of wondering what you think the next steps should be for us and perhaps maybe we could escalate this issue because it seems like if there is some indexation bug or something around the API that maybe was resolved for most sites our site still seems to be affected that's unfortunately something in the API itself so that's something where at some point when we switched over to the new UI for site maps reporting I think they stopped updating that data in the API so that's probably why you're seeing some stale data for some site maps and some zero data for some sites within kind of the index encounter I need to talk with the team about kind of what the next steps there are I know they've been looking into it and trying to find a way to resolve that but I think it's been long enough that we need to at least document this state to make it clear for people who are seeing this problem that this is not something that they're doing wrong but rather we just aren't updating that data at the moment. I see is there any interim solution that we can employ perhaps submitting that site maps or doing anything else differently that could enable us to get this data because this data is pretty critical for us and not having it for a large portion of the site maps that we submit is pretty unfortunate. I don't think so I think at the moment it's not being updated at all so for the site maps where you are seeing a number there I suspect it's just the number that was there since April and for the ones where you're not seeing anything it's basically we haven't added anything there but I totally get your point I know that this is something that others are using as well so we should definitely find a way to get that data back in. I just don't have any ETA on that so I think what will probably happen is we will try to get it updated at least in the documentation so that it's clear that this data is not available and then in the next step with the API where I know the teams are working on improving some things there that will get that back in. I see and so despite some of the site map indexed counts seeming accurate and seeming like they're being updated it's the case that entirely for that site map API the index counts should be considered invalid entirely? Yeah. I would consider them invalid. Okay. No problem. Thanks for the insight. Sure. We still have a bit of time left actually we don't have much time left but I have this room for a little bit longer so we can continue a little bit longer if you like if there are any other questions that are on your side feel free to jump on in. Hey John we run the e-commerce business so we have two listing pages one listing pages will consider all the brands the other listing pages is only specific brand the specific brand page is considered as duplicate so how to eliminate that and I wanted to be indexed If we consider them to be duplicate then that's probably because of the content on those pages if they're about the same brands then I could imagine that we might run into that situation so if you need to have them indexed individually then I would make sure that the content is really significantly different if you don't need to have them indexed individually then I would pick one of those on your side and use the rel canonical to tell us which one of these versions that you want to have indexed Okay. Then one more question also is it necessary to specify the domain name in the meta title and description if there is no ranking advantage so is it necessary No it's not necessary some sites use the domain name as a brand name for the sites and putting that in the title is fine but there's no ranking advantage of using a domain name in the title or description Okay. Then one more thing also like Google reads the image all text so if suppose if I am over over an image and I display the text so is that Google reads it or We do use the the alt attribute for images we use it as a part of the page for the web page and for better understanding the image itself Okay. Thanks Wow. 20 people in here. Crazy I guess this is one advantage of the new setup more people can join in at the same time Any other questions from any of you Hey John Yeah, so this is related to the domain diversity update which was released in I think so June or July So it was not top stories part of this diversity update because what we see is most of the time the same news sources repeated two or three times within the top story carousel I don't know for sure if top stories would be included in that specifically because a lot of times when we have one boxes or kind of carousel elements there then we see those as separate parts of the organic search results page not as the same thing as the normal listings there. So it's quite possible that top stories has its own setup for determining how the diversity should be setup across the pages that we show there Yeah, because it's not like other sources are not covering that same topic they are covering it but still the same source appears two or three times So that's why I don't know how top stories would deal with that I do hear this from time to time so if you have any specific examples or screenshots or something that you can post on twitter and send my way that would be useful to pass on to the team it's sometimes a bit tricky with top stories because it's so specific to the location and the exact time when you do that query so screenshots are really helpful for that Sure, we'll do that Cool John Bassin applies to PA also not a part of that domain diversity update People also ask I don't know probably I don't know how those results are created but that's also essentially a separate block so generally speaking they would have their own internal ranking within that block Let me double check Yeah please Let me double check the submitted questions to see if anything new that we can add I think for most part we have things covered What else is on your mind? I had one very in my mind So John nowadays I am seeing that people have some schedule like if we want to shift to other domain let us just redirect it for one year and we will leave it In webmaster forum I am also seeing a lot of people discussing the same thing that please tell me for how long we should have this redirect 301 and then we will leave it How does Google really see if we have shifted this domain in the market to this domain and now links are still pointing to X domain which was earlier redirecting to Y domain How Google determines later on that yeah this link equivalent to this this link Y because 6 months back it was redirecting so now it is also the link where it should be passed to this Unfortunately if you reuse a domain for something else which could be either on your side could be that someone else has bought that domain and we discover links to that domain even if these are older links then we will count those links as applying to the new domain so it is not that we would say well this is an old link that was there when that redirect took place therefore we will ignore that link or pass it to the website that has moved on it is really the case if you remove those redirects if you remove those old URLs then we will probably try to apply them to the new website there so it is not something that you would get to kind of like keep if you move to a new domain and you let the old one expire because of that that is something where I really recommend on the one hand going through and updating the links kind of how we have that listed in the help center of trying to keep that old domain for as long as possible even if you are not using redirects anymore just at least keep it within your own control so that you don't run into a situation that suddenly a competitor is taking your old domain and using it to try to rank their content so if you are moving from one domain to another and set up permanent redirects I try to keep them as permanent as possible and in any case I try to keep the old domain name so that it doesn't expire and end up being something completely unrelated yeah cool John can I ask a quick question about image links versus regular links okay because we or I want us to link to the other websites that we have but showing the logo so it is more user friendly and that people can see it and not only have a text link would it still be okay to have it the link in the image sure sure what I think is useful there is either that you have the text link as well or at least that you use the alt attribute for the image to kind of give us the anchor text that you want associated with that link so that the alt text can be the full domain name sure okay but you will also have a text under it so it will be linking with the image and then the text under okay yeah that sounds good yeah perfect thanks hi John my question is Google is solving queries on its own such as what is the capital of UK it is possible that the Google got to know about this from such as websites as Wikipedia and others if Google will keep answering these questions without mentioning the website source it is possible that in the future Google is going to kill all the traffic to the webmasters who is providing such information about the persons and places Google is thinking about the criteria of these kind of webmasters right now sure absolutely I think that's something that pretty much everyone on the search team thinks about and tries to take into account so trying to find the balance between giving people information and making sure that the whole web ecosystem has a reason to remain kind of a thriving ecosystem that's something that we definitely think about a lot I think there are some kind of queries where it makes sense to show information directly in the search results and maybe others where it doesn't make that much sense so for example if someone is looking for the opening hours of a business then showing those opening hours doesn't cause any problems for that website in the sense that users aren't showing to the website and clicking on that page anymore to find the opening hours but they find the opening hours and they use these opening hours to go and visit the business in person so for the business itself clicks to that page are not really the critical aspect there but rather kind of being visible in search and being findable and having their information available for users at the right time so that they can then kind of have it a little bit easier to actually convert with that business and become actual customers and that's one aspect there the other aspect is of course if you have content that is very limited in the sense that you ask what is the capital of India and the answer is one word then if your whole web web page is essentially just to answer that question then of course that will be trickier because on the one hand there's a lot more competition for those kind of pages out there now and on the other hand a lot of this information is general information that we can just show and search so if the whole reason for being of your website is to answer kind of these one word questions then I do imagine that's something you'll have to figure out on your side kind of migrating the change in how search works, how the web works overall but that's something that from my point of view is normal as a normal part of the web in the sense that things evolve over time the user needs to evolve over time the expectations change over time and therefore websites themselves also need to find ways to stay with the web sometimes and find ways to be unique and compelling so that users want to go to your web page and don't just want a one word answer actually in recent article of Ryan Fischkin he is saying that the Google is providing answering the queries 48% without mentioning the source isn't it alarming to the webmasters I did not read that article so it's really hard for me to comment that John do you have a number or do you know a rough percentage of what queries you answer on the page rather than not I don't know I don't think we have a public number I think it's also tricky to say because some things are answered directly in a snippet on a page and it's kind of hard to say that this is something that Google is doing differently versus maybe the answer is just in the meta description of the page no I just wonder I suspect it's not a big issue people just notice it I imagine I imagine it's something that changes over time as well depending on how people search what kind of questions people use to search it's one of those things where I think user needs and user expectations change quite a bit I think business expectations have changed as well I think people now think you can monetize what's the capital of India where 20 years ago you look at it in a book or you ask someone else there's no money to be made from that query so people have got lucky for 20 years and maybe have made some money out of it but things change you can't make money out of everything that's probably the case too yeah I mean like capital of India I could imagine that for a long time you could make kind of ads made for ads landing pages that worked really well in search for that and that like you said for a while you could probably make a decent living just answering these basic questions but things change and especially when it comes to I think bigger websites that's something that has changed significantly as well where in the beginning you could make a landing page on specific book topics or specific things just because there is no kind of general source of information on the web and you could rank for those and perform really well and nowadays there are lots of different sites that are trying to compete for all of these queries yeah I think Axel you're raising your hand Axel from Germany I'm managing a really old site where we have a special charge in the URL so like some editors created URLs with copyright names and French accents like Avan or Elmix Julli and I noticed as the gear see the check URL tool is not accepting the URL at the moment because it says it's wrong encoded could you investigate on that do you have some example URLs that maybe you can copy into the chat yeah I give you one minute so we have here one URL where the editor or the person basically putting the product in this one it's a German site and there's a product and there's a percentage AE which is the copyright sign this one I would say is not so legit but there's another one where the brand name is called French Avan is also a famous toothpaste in Germany called Elmix Julli which has an E so the content editor just types in the name of the brand and the CMS is like converting the URL and if you paste that into a check URL it's like not okay trying those in the browser also doesn't show the character but it should at least load so I'll double check with the team on that in general what we recommend for kind of non I don't know non-standard I mean these are standard characters but kind of the non-asky characters yeah the kind of special characters is that you use Unicode if you include them in a URL that way we can always pick that up but we should if you can load this page in a browser we should be able to test it with the testing tools as well so that seems like a bug on our side the tool says at the moment URL is not in the correct format and we are trying to switch our system from to UTFH so it's going to be probably so if you could pass it to the devs yeah I'll definitely pass that on thanks cool any last questions before we close out for the week everything good okay that's good I think the indexing issue that we had yesterday should be mostly resolved now as well so maybe we can go into the weekend with a little bit less stress I hope the week has been good for you all and I wish you all a great weekend thanks everyone and see you next time bye