 All right. Welcome, everyone, to today's Webmaster Central Office Hours Hangouts. My name is John Mueller. I am a webmaster trends analyst here at Google in Switzerland. And part of what we do are these Office Hour Hangouts, where anyone can join in and we can talk about their website and search. As always, it looks like a ton of questions were submitted. But if any of you want to get started with the question first, you're welcome to jump in now. Here's John. The messages get approved. Our messages seem to be vanishing from the list. Is that normal? Vanishing from the list. So how do you mean messages? It was just a question on the YouTube community comments area. Oh, I don't know. It was upvoted quite a bit, so oh well. I mean, I think there is some kind of spam filtering that happens. And partially, I get some of those listed that I have to manually approve. But I thought that's probably it. But maybe too many people like this question. Therefore, it must be something wrong. I don't know. Feel free to ask it if it's something that you submitted that's missing now. OK. I've been at this for 15 years full time. And I've seen it all. But I think I have a pretty good case for a legacy penalty on a domain registered and promoted heavily by client in the millions of dollars of branding effort. And the issue that I have is that we can't lift above position 23 for a very unique branded search. There is no competition on Google for the brand. Bing took it to number one in two days. And we have a completely scrubbed link profile, great content, good inbound links. This was in May that the site was launched. And the link profiles scrubbed. Wayback Machine had a porn history in 2014. The main was expired and then re-registered. They didn't check its history and then called me later. So what we are desperate to find out is other than doing the normal, great content, good link profile, this kind of thing, I've never seen it before. Wow, there's a lot of noise. Let me mute some of you. Feel free to unmute if you have some questions. Now, it's hard to say where to start. It sounds like you have pretty much the basics of that covered. So things like making sure that the content is good, cleaning up old issues with regards to links. Those are generally the bigger things. Sometimes there's also a matter of geo-targeting, which can play a role. So if something, for example, was highly targeted to one country, and then the next owner essentially takes it and wants to target a different country, sometimes that takes a while to settle down again. If it's a global website, that's probably less of an issue. But sometimes it can be a bit tricky. If you want, you can send me the URL, maybe drop it in the chat or send it somewhere else. And then I can take a look at that. But especially if there is, I guess, a long history behind a domain, then it can take a while for things to settle down. And it sounds like you've had this since May or have it set up since May. And that seems like it should be enough time. But sometimes things take a little bit longer, and it's good to double check. I put it in the chat for you. All right. Great. Thanks. Hey, John. It's Adelsson. Hi. I joined the Hangouts, I think, about some months ago. And I was asking about recent migration we've done, which involve Google for Jobs. And we lost a whole bunch of our visibility. And we're still not recovering, essentially, from this. And I shared my email to you about that, too. I was wondering if you had any updates on that. I did hear something back from the team. But I'd have to look it up. Let me see if I can find your email afterwards. And then I'll ping you there. Great. Thank you. Hey, John. Hey, John. Oh. Oh, go ahead, go ahead. Oh, thank you. Hey, John, how are you going? Very good. How are you? I'm very well. Thank you. It's 6 PM in Australia over here. So I'm staying up on a Friday because I'm so keen to chat to you. Oh, man. So I just have a question about featured snippets for a particular client that I'm working with at the moment. So they're very, very large site, one of the largest sites on the web. So they rank for a lot of different queries. But they don't rank for any featured snippets at all for the site. There's no technical issues on the site, or they're not using that no snippet script. And I have a good feeling that it is an algorithmic penalty that's been put in place for this domain. It does fit the criteria for one of the categories in the Google Support documentation for why featured snippets might not show for a site. So I have a good feeling that that is why. Not sure if that's algorithmic or a manual thing put in place by Google there. So yeah, basically, what I wanted to ask you is there any chance that I could send you this site privately and get you to have a look if there are any sort of lists at all? Sure, I can take a look. But especially if you're saying that it's one of the kind of sites or the kind of content that we might not show as a featured snippet, then I don't know how much we can do there. Because a lot of that is, like you mentioned, algorithmic. And that we try to figure out where our site fits in and where it makes sense to show these kind of snippets. So that's a bit tricky. But you're welcome to send it to me directly if you want. Let me just drop my email address here. Yeah, I'm not getting in contact to ask you, like, why is this happening? I want this site to rank the featured snippets. It's more so just wanting to know, is it on a list? And is that the reason why they're not ranked in training? I looked at quite a few other sites that are competitors to this particular website. And probably 80% of them don't have featured snippets showing for their websites. But there is a couple that do have featured snippets showing, and they seem to rank for similar keywords. So there's a bit of ambiguity there. Yeah, I mean, with a lot of these algorithmic factors, it's always the case that we can't catch everything or catch it perfectly. So that might be something where you might see, well, in this general niche or this general type of content, Google says they don't want to do it, but they still show this one particular one. And then that's usually not because we're trying to exclude them from that group, but rather because our algorithms just aren't picking that up. So I don't know what kind of site it is. So it's really hard to say. But I'm happy to take a look. Usually, if there's something manual that's blocking something specific, then that would be shown as a manual action in Search Console. So you'd be able to do reconsideration requests there to have someone review it. But there are lots of features in Search that have different kind of triggering algorithms to figure out when we should be showing something or when we shouldn't be showing something. So that's fine. Is that going to take a look? Yeah. One thing I recall seeing on Twitter a little while ago that Danny Sullivan said that there isn't any notification that's sent through Search Console at the moment for a featured snippet penalty. And that's something that Google is looking into at the moment. But if you know something that I don't know that, that would be awesome. I'll send you an email anyway. Sure. OK. Great. Thanks, John. Sure. Hi. Hey, John. So my question is mostly, so we have a website which has an M version and desktop version separately on the web. So right now, because of mobile first indexing, should we change the canonical and rel equal to alternative? Because before it was like in desktop, we put alternative to mobile and mobile canonical to the desktop. So should we keep same way or should we reverse it out? It should stay the same way. So you should still point the canonical to the desktop version and the alternative to the mobile version. What will happen internally is we will use that to understand which of these pages belong together, not necessarily that you're saying this is the canonical, because internally we will pick the mobile version as canonical. But we need to understand that they belong together, and we understand that through this set of links. So another question is, we have this indexing API for indexing a job-based or maybe live streaming pages. So in that also, we have to keep desktop version of the page or the mobile version. Good question. I don't know. I would assume that the mobile version would be the right one to show there, because that's what we would index. OK. So another question, sorry for that. So right now, we have lots of issue going on in the desktop as well as mobile version. Because it's a completely new website. So my question is, how to tackle it? We should go ahead and clear the issues with the mobile first and then desktop or massive version. Like go ahead and just do the changes in the desktop version and then mobile. So they should be equivalent. So the mobile version should be the same as the desktop version. So it's something where if you ask me which one to do first, it's basically, you should do both first. But I think one of the things that we've been seeing quite a bit, especially with mobile first indexing, is that when you have a separate mobile URL for the setup with MDOT version and desktop version, then that just makes everything a lot harder and a lot more confusing. So we've really started recommending not using separate mobile URLs and instead using one single URL for the both desktop and mobile version. Because then you don't have all of these problems. You don't have to worry about which URL to set up, where to have the content. It's like all one URL. So we have asked our product team to do that, but they are kind of hesitant to do this. So yeah, we are coaches of doing that. I know it's a lot of work to redesign a site like that. So it's not that we're saying you shouldn't do it like this, but we really recommend, especially if you're doing a bigger redesign at some point, then try to move from separate mobile URLs to just one URL. So is dynamic serving will help in that case? Like let's suppose if the URL will change the URL format. So it will be one URL, but in back end it will be different. So will it be different? Dynamic serving is perfectly fine. Using responsive web design is fine. We usually recommend responsive web design because then you don't have to worry about which version you show. All of the content is there. But if you want to go with dynamic serving, that works well. Because product team is kind of not ready to move into the responsive side because of some other reasons. Yeah. I know it's always a lot of work to make these kind of changes. Yeah. Yeah, that's all I have for now. Thanks. Cool. OK, let me run through some of the submitted questions. And if you all have any questions or comments along the way, feel free to kind of speak up. And I try to make sure that we have a bit of time towards the end as well for anything new that comes in. I have a client who has quite a few pages, no indexed. However, Google is grabbing these no indexed pages and assigning them as canonicals. It's a real estate site. And they're ascribing zip code searches to static neighborhood URLs, which is in fact resulting in duplicate content. I suggested they stop and engineer a better solution. But kind of like, what could be happening here? It's really hard to say what exactly is happening there. In general, when we see a URL with a no index, we try to avoid making that a canonical URL. But what can happen is that our systems try to understand broader patterns on a website and accidentally pick up things like that with regards to duplicate content and canonicalization. So a really common setup is, for example, you have dub-dub-dub and non-dub-dub-dub. And we understand that these versions are essentially the same. So if we find one that is not the canonical version, we'll kind of automatically shift that over to the other version. Other examples that I've seen are, for example, if you have a bunch of websites that essentially show the same content, maybe you have an e-commerce site and it's all the same products on two or three different domains, we might recognize that these URLs are all the same. And we'll say, at that point, our systems might say, well, any URL on this domain is the same as a URL on that domain. And it can also kind of play internally within a website in that we might find this URL pattern within the website almost always leads to exactly the same content with a different URL pattern. And we might pick one of those patterns kind of as a canonical. And then it can happen that we say, well, this URL, it fits the pattern that we know. We haven't had a chance to double check what the content actually is on this URL. But almost all of the URLs with this pattern map to this pattern. Therefore, we'll map that as a canonical. And then it could happen that you have some pages that lead to a canonical that are no index because we think, well, almost all of these URLs kind of canonicalize like this. So we'll do that here in this case as well. The real way to kind of clean this up is to convince our systems that you don't have this kind of systemic duplicate content or kind of canonicalization issue on your website. And that's something that our systems do kind of relearn over time. So if, for example, you have a bunch of search results pages and they all canonical to one version or they all show the same content as a different version, then make sure that you don't kind of have all of these duplicate URLs that lead to the same content. So that's kind of the general approach that I would take there. If that's something that you've already cleaned up and it sounds from the question like you're still discussing this kind of a cleanup, then that would also be something that we'd be able to double check manually on our side. You could either post in the Webmaster Help forum or ping us on Twitter or something so that we can double check to see what is happening here if we have to do something manual or if this is just a matter of our systems kind of relearning your site again. I have an issue that's somewhat similar. OK. Do you have a jump in? Sure. So we see the SEO of an e-com site and we have four properties, Canada, US, Australia, and New Zealand. They all share the same technical infrastructure. What I'm seeing is that in New Zealand, our website gets canonicalized to the AU site every two weeks. So the NZ site just disappears for Google search every two weeks for around two weeks and then reappears. And when I look at the URLs that disappear, I see that the user declaration, the user canonical is the NZ canonical and then the Google canonical or the canonical picked by Google is the AU one. And I'm trying to understand why the HF line is set up properly without having any restrictions on the server side. So I was thinking there might be a crawl issue. So I'm a bit clueless as to what mission would be. Yeah, I think it leads into a similar situation. And it's something that is fairly common, but it's fairly complicated. So let's see. So I think primarily what happens is our systems look at these pages and say these are the same. So probably, I mean, I don't know your site, but in a lot of cases, you'll have exactly the same product on the UK version as well as on the Australian version, and the difference might be just the price or something like that if you have different currencies. And our systems would look at that and say, well, these are essentially the same page. We can save the webmaster some trouble by just picking one of these pages and indexing that one. And then through the hreflang links, we still understand that there are multiple URLs that lead to this page. So in the search results with hreflang, we can still swap out the URLs to show the right one. But index is just one of these versions. And this is further complicated by Search Console, which sometimes makes your life a little bit harder than it needs to. In Search Console, we try to report on the canonical URL. So in the search results, we might show the Australian one because we are able to swap that out. But if we have the New Zealand one as canonical, we'll show that one in the performance report. So if you look at the indexing report and the performance report, it'll look like, well, New Zealand is the only one that's getting traffic and the only one that's indexed. But actually, in the search results, we would still be showing the Australian URL. Usually, you can try that out by just searching for a product name and then changing the URL parameter in the search query with, I think, GL for the geographic location, I guess, and then equals the country code. So that's usually how I double-check that. And you should be able to see that while we have the New Zealand version as canonical, we do show the Australian URL as well. So that's only true in some instances. The NZ, in this case, disappears. But I don't see AU showing up instead. So our domain just completely disappears. And on branded queries, we see AU, but only on branded queries. So we do that bit by bit together for AU and NZ. Yeah. OK. That shouldn't be happening. That sounds like something that maybe I should take a look at. If you want, maybe drop some of the URLs in the chat, and I can double-check that afterwards. But especially if the content is exactly the same, then all of these things kind of play a role. And it makes it really hard to figure out what is actually happening. The real way from talking with the indexing teams to fix this is to make sure that the content is different, which for an e-commerce site, when it's specific to the product, it's like that's really hard. Unless you really spend a lot of time to make sure that the template of these pages is significantly different across the different country versions. The other thing from a practical point of view that I usually recommend is to use some kind of a banner on your pages when you recognize that the user is probably from the wrong version. So if you can't recognize that a user is in New Zealand and they go to the Australian version, then use JavaScript and show kind of like a banner on top saying, hey, we have a local version. Yeah, so what we did, we did something similar, which is a geo redirect, which you probably won't like. But for any NZ customers landing on AU, we're redirecting them to NZ. Yeah, I think if you're doing that across Australia and New Zealand, we probably wouldn't see that. But if you're doing that for users in the US as well, then you might also get a redirect. And then we would just follow that redirect. That's why we're only doing it there because I thought that you might only be crawling from the US. Yeah, I would double check where we crawl from. But I think even in Australia, we crawl from the US. I'll send you the details by email if that's OK. OK, sure. Thank you. Yeah, these international sites can be quite tricky. We have the same problem in Germany, Austria, and Switzerland where everything also is in German. And usually in the German Hangouts, it's like one of those topics that comes up every time. Hey, John. Hi. Can I get a question in here? Sure. So we have a lot of user-generated content. We have a listing site where communities list. And is spelling errors and stuff like that going to hurt us and content and stuff like that that the users generate? Not necessarily. But if you provide this content in a way that we can index it, we will assume that it's content that you want to have published. So it's not that our systems will look at your site and say, oh, this was submitted by a user. Therefore, the site owner has no control over what's happening here. But rather, we look at it and say, well, this is your website. This is what you want to have indexed. You kind of stand for the content that you're providing there. So if you're providing low-quality user-generated content for indexing, then we'll think, well, this website is about low-quality content. And spelling errors don't necessarily mean that it's low quality. But obviously, it can go in all kinds of weird directions with user-generated content. All right. That's good. What about not-safe work? So some of these communities are not safe work. Is there anything that Google does in that kind of situation? We try to understand which parts of a site or which sites need to be filtered by Safe Search. And depending on how you have that set up with the communities, if that's like subdomains or subdirectories or just different domains completely, then that makes it a little bit easier. If this kind of adult content is mixed in with the rest of the website, and that from a URL pattern level, it's really hard to tell which parts are adult content and which parts are essentially just general content, then that would make it a little bit trickier for us to figure out how to deal with Safe Search there. So the clearer you can separate it, the easier it will be for us to kind of pick that up and just say, this is the part that needs to be looked at from a Safe Search point of view. Would like a not-safe work tag on the page, just like a simple tag? Would they kind of pick that up like NSFW or something? Probably not. Probably not. So there is an adult content meta tag that you can add, which I think we specifically use for image content. But that's, I don't know how easy that would be to implement. OK. Thank you. Sure. All right. We have some of the submitted questions. And we have some of the noise here. Sorry. And we'll try to make some room for more questions from you all as well. Wondering if Google checks status codes before anything else, like for rendering content. Yes, we do. And it goes to index the content or render the content. In particular, if it's a status code 200, then that's like a sign that there is something here that we might be able to index. And if it's a 400 or 500 error or redirect, then obviously those are things we wouldn't render. So if you have a really nice 404 page, then that's not something that we would see for indexing. Similarly, if your page returns 404 by default, and actually, you can't change the status code. Well, if it returns 404, then we just won't render anything there anyway. So should return 200. I have an issue with Google cache and dynamic rendering of a page with JavaScript. I always try to see to index the totality of webpages so that the cache can see what my users see. If the two are not aligned, I'm always a bit worried. So one thing about the cache page is it's not exactly tied to indexing. So just because you see something in the cache page doesn't mean that's exactly what we use for indexing. In particular, when there's JavaScript on a page, then it can be a bit hit and miss if that JavaScript is executed when you look at the cache page because JavaScript has certain requirements with regards to when it's allowed to run. And if you're pulling in further resources, if that's happening across domain, then JavaScript might not be able to do that. So the cache page really just looks at the static HTML version that we see when we try to crawl that page. If you have a website that uses JavaScript, then the cache page won't necessarily reflect what we use for indexing. Because for indexing, we will try to render that page. We want to implement a dark mode for our website. Do we have to consider anything in relation to SEO? I think this is totally cool. I really like the trend to dark mode websites or dark mode apps in general. It's something I don't know that I wouldn't have expected a few years back that people would want to have this light mode, dark mode setup. With regards to SEO, that's absolutely not a problem. Usually, people implement this using CSS. And the way that you implement things in CSS doesn't affect how we would pick things up for indexing. So go for it. I think that's really awesome. I don't think dark mode would be a ranking factor. So maybe at some point in the future, if dark mode is really, really popular, then maybe we would need to highlight dark mode sites in search when people have their phone set up to dark mode. But I don't know if that would actually happen or if that will really go that far. Can I publish multi-language versions of the main content without subdomain or subdirectory? Yes, you can. So different language content should be on different URLs. But you don't need to put it in different subdirectories or subdomains. It can be with URL parameters, even. Earlier this year, Google announced all new domains would be on mobile-first indexing. We're not really seeing that. Sometimes it says mobile. Sometimes it says desktop. Did this actually happen? Yes, it did happen. But kind of like the name mentions, it's for new domains. So if this is a domain that we've seen before in the past, then we'll do the usual process of trying to figure out when the domain is ready for mobile-first indexing. If it's something that we haven't seen before, then we will use that for mobile-first indexing. At some point, the next step will be that we move everything over to mobile-first indexing just to kind of keep things simpler. But I don't know when that would happen. We definitely announced that ahead of time. If I build 200 backlinks in two days and didn't perform any link building for years, will Google still see this as blackout and penalize me? So what about link velocity? So from my point of view, if you're jumping in with a question like this and you're saying, I am going to get 200 backlinks in two days, then that sounds a lot like you're not getting natural backlinks. That sounds a lot like you're going off and just buying them or having someone buy them for you. And that itself would be kind of the thing that we would not be happy with. So it's not so much a matter of how many links you get in which time period. It's really just, well, if these are links that are unnatural or from our point of view problematic, then they would be problematic. It's like it doesn't really matter how many or in which time. Is there a way to show the last updated date instead of the published date in the search results? No. Or rather, it's not that we show the published date in the search results. We try to figure out when a date is appropriate to show in the search results and which date would be appropriate to show there. And sometimes that can be a date on the page. Sometimes that can be a date from when we originally saw the page or when we saw that the page was last updated. So the dates that we show can be kind of different. And in a lot of cases, we don't show dates at all because we don't think that the date is an important part there. But you can't toggle between which date should Google show in the search results. We have a website with separate desktop and MDOT version. So we use the canonical. Since mobile first indexing, should we reverse that? I think we touched on this before. And the answer is no. We kind of leave those links the way that they are. We looked into this quite a bit with the team involved. And our recommendation was really like people shouldn't have to worry too much about the mobile first indexing change. In particular, they shouldn't need to watch out for when this change happens and then change everything on the website. So we use this connection to understand that the pages belong together, even if we pick the mobile version as canonical in the end. So John, sorry for disturbing. So for the sitemap also, we'll do the same thing, right? It will be as it is. Sure, yes. Perfect, thank you. Does a noindex follow header directive on an index sitemap containing links under other sitemaps block sitemap retrieval on Search Console? So first of all, normal metatags, you can't put them into sitemap files because sitemap file is an XML file and not a web page. You could use HTTP headers to give us kind of this information on noindex. And that would only apply if that URL were shown in normal web search. So it doesn't affect the processing of the sitemap file at all. You can put a noindex xrobots tag HTTP header on an XML sitemap. You can put it on a robots.txt file. You can put it on your CSS files if you want to. All that does is prevent that URL from showing up in normal web search. In almost all cases, we have enough good content to show from a website, so we would not show a robots.txt file or a sitemap file in the search results. It can happen that for whatever reason, we weren't able to kind of understand the normal web pages properly. And then suddenly, the sitemap file shows up. The more common scenario is that people explicitly search for a sitemap file using a site query or in URL query. And then in that case, we don't really have an understanding of the relevance. And then we might show that in search. But usually, that's not something that you need to suppress. So unless you really see your sitemap file showing up for normal search queries, then I would not bother with putting a noindex xrobots tag HTTP header on that. And if you do see your sitemap file showing up for normal web search queries, then I would strongly recommend figuring out why we think your sitemap file is more relevant than your normal web pages. Because that seems to be a sign of a more general problem on your website that we don't understand your website well enough to understand that actually your content pages are much better for users than the sitemap files. I have a valid FAQ schema, but I was wondering about the guidelines around not for advertising clause. Could being over promotional hurt my rankings? This would not affect your rankings. So that's kind of the first thing. What can happen is that our algorithms look at this and say, well, we wouldn't show the FAQ search results type for this page. It definitely wouldn't affect the rankings. So on the one hand, I'd love if everyone just sticks to the guidelines and kind of does it the way that we have it recommended. On the other hand, if you want to play around a little bit with that to see how far it makes sense to go and maybe how far is too much or looks kind of weird in the search results, then you're welcome to try that out. In the worst case, what would happen is that we would not show the FAQ schema for those pages. I guess if you really, really overdo it, then what could happen is that someone from the WebStand team looks at that and says, well, all of the structured data on this website is really spammy or really problematic. And we would just not show structured data rich results from this website. But again, that would not change your rankings. It's really just the presentation in search. What's the best way to embed relevant Google reviews? Is the API the same as simply copying, pasting text? So if these are reviews for your company that you want to host on your company website, we would not show them in search. So you can embed them however you want to do that. If you're using an API that uses JavaScript, keep in mind that we need to be able to render this output if you want to have that indexed. That might make it a little bit trickier. I don't know how that API in particular works with regards to, can Googlebot crawl the JavaScript files and the server responses to get those pages? You can check that with the Inspect URL tool in Search Console. Copy and pasting text is something you can always do if it's in static HTML. We'll be able to index that. I don't think this would change anything for ranking. And we do try to prevent these kind of reviews for your business when they're hosted on your business from showing up in search. But if you want to put them on your pages and you want to have them indexed, if you want users to see them, that's totally up to you. Is there a benefit for a site to have reviews for product on completely separate URLs other than the product? I don't really think so. Sometimes I see sites do that with reviews because they have a lot of reviews that they put the paginated versions on separate URLs. But in general, it helps us to understand that this is the product, and these are the reviews that are available for that. So ideally, have that together. What are the main fundamental SEO activities to grow a website traffic? I noticed that SEO has changed quite a bit. And consumers change, like they search on Quora, and they go to Amazon directly to buy, and they go to video sites for entertainment. In general, I don't know, the web keeps changing, and I don't think there's one magic trick that I can offer you that will make sure that your website stays relevant in the ever-changing world of the web. So that's something where you'll kind of have to monitor that on your side and work out what makes sense for your site, for your users, for your business. I don't. Let me run through a few more questions, and then. Can you hear me? Yes, but let me run through a few more questions, and I'll get back to you. I have one query. I'll get back to you just a second. OK, we are ready. All right, snippets and more languages coming anytime soon. I don't think so. So we try to understand what language a page is in, and then we show the snippets or the kind of text preview in that particular language. So it wouldn't be the case that we'd recognize the pages in multiple languages and try to show multiple snippets. So in particular, if you have multilingual content, make sure it's on separate URLs so that we can show it appropriately. Search Console says I have a content injection problem. After multiple analysis with multiple browsers, I still can't find it. All the content is legitimate. I requested a new review, but I'm still getting the same error. What can I do? So in general, the content injection message is something, I believe, from the security side in Search Console, which is basically that our algorithms are picking something up that looks a lot like hacked content that perhaps someone has placed on your page. And one of the things or one of the techniques that website hackers like to use is they cloak this content to Googlebot in particular or to search engines so that when you, as a site owner, look at it, it looks fine. And but when search engines look at it, they see all of these links or all of these kind of promotional material leading somewhere else. And that's something that would be problematic and might be tricky to find. So I'd recommend double checking using tools like Inspect URL in Search Console and maybe getting some help from other people who've run into similar problems like this so that you can be fairly certain that you're checking all of the right versions. And sometimes we do get this wrong. So using the review feature is a great way to make sure that someone manually looks at your pages and make sure that this is really something that is problematic and is probably from a hacker rather than something that is really on your web page. For example, I've sometimes seen cases where you have a medical website that talks about certain pharmaceuticals. And we might look at that website and say, well, this is talking about the same pharmaceuticals as spammers talk about all the time. So maybe this is a hack site as well. And that's something where when we look at that manually, the Web Sum team will be able to clean that up. We're seeing highly unusual activity in our Search Console data impressions drop suddenly and rise up again. We believe there's some bug in Search Console here. Can you let us know what's going on? I took a quick look at this thread and it looks like someone else has replied already. So maybe that's kind of OK. It sounds like what you're seeing there is something similar to the first question in that you have a country version and you have different country versions. And if the same content is available on multiple country versions, then we might pick one of these as canonical and that can shift over time. The other thing that I noticed when looking at these pages is you're automatically doing a geo redirect for individual countries and regions. So if Googlebot sees that redirect as well, then that could also result in this kind of shift. So I'd really recommend trying to stay away from geo redirects like that and instead doing a banner type thing like I mentioned in the beginning or perhaps also, and I guess, also trying to make sure that the content itself is actually different across the different country versions. We have a large price comparison site and we have structured this in a way that whenever there is zero offers per merchant, the page gets no index automatically. Is it possible that this indexing, no indexing, might affect my rankings? It shouldn't affect your rankings in that it's completely normal for sites to have some content that's indexable and then maybe later on it's no indexable and maybe then it's indexable again. So that wouldn't be affecting your site's overall ranking. However, when we see pages that are persistently no index, then we might see them as kind of soft 404 pages. And what would happen then is we would just recrawl those pages a little bit less frequently. So with a normal page, maybe we would recrawl it every couple of days. If we see that it's always been a no index for a longer time now, then we might say, well, maybe we'll look at this page every couple of weeks instead of every day. So that's something that you might be seeing there. If you're changing things back and forth fairly quickly, then sometimes it can happen that we don't recognize that the change has happened that quickly. You can let us know about this on a per page basis using the inspect URL and submit to indexing tool. You can also let us know about this using the sitemap file with the last modification date. All right. We're into the last 10 minutes, so maybe I'll just shift over to more questions from you all. Yeah, hi, John. Hi. This is Sanjay. I am from India today. We have a URL called IndiaToday.in. We are facing some issue from last three days where our site is not being crawled. So there is a zero indexing of any page on Google Search. So can you just find out? OK. Is that something that you were seeing across Google News and Google Search? Or just I think you also tweeted about this, right? Yes, correct. So it's IndiaToday.in, which is Google Search. I'm talking purely Google Search. News still we are still there. Some of articles are there. OK. One of the things I noticed with your site yesterday while looking at it is we're having a lot of trouble crawling things from your website. So that might be something to look into. In particular, we were seeing a lot of errors trying to access your website, which makes it really hard for us to crawl. I think because of that, we've significantly scaled back the crawling from your website. So that's something where I would double check from a technical point of view that you're not blocking us in particular way. Maybe check with the log files if you have access to that to make sure that there are no special response codes or no kind of geo-blocking or anything like that that's happening. It looks like we're still able to crawl a little bit. We're just not able to crawl nearly as much as we used to be able to. Yeah, yesterday there was some crawling happened. But since last night, again, everything has gone out. So whatever was crawled already. So what you're saying is right, either we have blocked something, we have checked using third party tools, or also maybe through the web console, the master console, we have tried to individually, you are trying to crawl it manually. It's showing no error. So then it becomes very difficult to identify also. OK, I'll double check with the crawling team on that. Yeah, please. How can we reach out to you? How can we talk on this particular issue? I think Twitter is probably best. OK, maybe I'll ping you on Twitter. Maybe I'll DM you. OK, cool. We are a news company. Just to inform you also, we are a news company. We publish roughly around 250 to 300 articles per day on this particular website. None of them are reflecting over there. Yeah, I saw that in your tweet. What you can also do is as a Google News publisher, there is a link to, I believe, Danny posted this to the contact forum specifically for Google News Publishers. So if there's something specific to Google News, then they would be able to help with that. If there's something just general that we can't crawl as much from your website, maybe they wouldn't be able to help. So we have submitted that also, but we did not get any feedback from that. So we have submitted the ticket also. So we hope that we will get to hear from that. Yeah, yeah. We also had some indexing issues, I believe, yesterday or the day before, but that was fairly short. So if you're still seeing issues with regards to indexing, then that wouldn't be related to those indexing issues. John, we already got response from a new support team from Google. They added and they sent the mail. We did not found any technical issues in your website. After that, I tweeted to Denny and you. OK. I already filled that form which provided by Denny. I didn't get any response, any mail after that. I don't know particularly how they're organized on the Google News site, but I'm happy to take a look. And like I mentioned, from what I looked at yesterday, it did look like we were just generally not able to crawl that much content from your site. So it's not, I don't think it's specific to Google News. It's just, in general, we're not able to crawl as much from your site as we used to. So is it generally with our website only? Or do you see, because I've seen a lot of people also tweeted the same thing, that they are also facing similar issues where the indexing is very slow or almost not? From what I can tell, it's specific to your website. So it's not a general change on our side. We still crawl as much as we can. And for pretty much the other websites that I checked, all of the crawling was normal. It's really just, from what I saw in the diagnostics, we're not able to crawl as much for your site. You probably already also see this in Search Console in the Crawl Stats report, where we show the number of pages that we crawl from the website. And I don't know exactly what it would look like to you, but my feeling is that you would see like there's a reasonably high level. And then over, I don't know, the last couple of weeks or the last couple of days, it goes down. But that's usually a sign that there is something technical somewhere on the hosting side, on your side, where we're not able to crawl as much as we like to be able to crawl. And so we slow down the crawl. And sometimes we slow down so much that if you publish a lot of new content, we don't have time to pick up all of that new content. So sure, thank you. And as you mentioned, you will take it up with your technical team. Definitely, if you get to know anything, please let us know. I'll ping you maybe on Twitter. Sounds good. Thanks so much. Sure. Hi, John. One question, if I may. Sure. I saw that now you have the snippet control feature where you can shorten the snippet. Can we expect any time soon to have us like a control over the site links? I don't think so. So the main reason there is that site links, at some point we had site links set up in a way that they were kind of a unique way of showing content in Search. And for that, we had a control in Search Console where you could say, show this one or show that one. But now, site links are essentially just a separate search results type. So it's not a rich result that we would show like this, but rather it's like we have multiple results from your website and we want to show them in Search. So we present them either as kind of multiple results in the same Search results page or as one main result with multiple site links in that. So we see them as essentially just normal multiple results from the same site. OK, the question is, because for some of the clients we work with, we see that in the site links we get pages that are 404. For example, they remove the content, but Google didn't crawl it to see that there's a 404 there. OK, is there any way of making sure that doesn't happen? I don't think there's ever a way of making sure it doesn't happen, because what usually this means is we've indexed the page and we haven't seen that it returns 404 yet. So what you can do there is when you remove a page, you can also still include that in the sitemap file for a bit longer and with a last modification date of when you remove that page so that the next time when we crawl that page, we see a clear 404 status code and then we can drop it from the index. The other thing that I sometimes see with regards to this is that when a website doesn't use a 404 status code for pages that are removed, then for a certain period of time we might continue to index that page, because we think there's content here. And then it takes a bit longer for us to realize that, oh, actually there is an error message here. It's not content that we should make out of. Yeah. OK, thank you. Sure. Hey, John. I wanted to second the last speaker that they saw a drop in their crawl set. And we also actually have seen a big drop quite. It's clear that the Google Watch activity has dropped significantly during the past week. So we've checked a lot of technical side. We've talked to our hosting. We've talked to our CDN. And everything looks just fine. Like the sitemap hasn't been read for a week now. And a lot of times we have to manually request I'm not sure if this is a bug or something, like the last ones that we've seen the past few months. Or if this is something on our end, I think we've pretty much looked everywhere for some kind of issue to track it down and fix it. Send me the URL, and I can double check. Maybe either here in the chat or on Twitter, somewhere. I think yesterday with the screenshot of the crawl sets. OK, I can put it here. My question is about Google, a selected canonical URL. We have two pages that are targeting the same, I guess, user intent. So the keywords are the same. But one is a landing page that is like 700 words long. Another one is a long form blog post that is like 2400 words long. And so the landing page was published first. And the blog post was published later. So the blog post, Google thinks that it's the duplicate of the landing page and is not indexing the blog post. Even though the set of keywords are the same, but this log is a bit different. Obviously, that one is landing page. This is a blog post. So what do you suggest we do in this case? What are our options? So I guess one thing I would double check is to make sure that this is not a systemic issue across the website. If it's really just those two pages within the whole website, then that's more a matter of us trying to crawl and index the content there and seeing that it's identical. Sometimes what can happen is if you're using JavaScript to load your content, then maybe you are not able to pick that up properly. If you're using some kind of lazy loading to expand the landing page into the blog post, if it's just the top part, then that could be something that's happening there where we index the same content on both of those URLs. Otherwise, if we're able to see that the content is different on both of these URLs, then we shouldn't be treating them as canonicals. And that's something, especially if it's significantly different content, then that should be fairly straightforward on our side. If it's really a one-to-one match, then that gets kind of tricky now. So I'm happy to know about that. The error is saying that it's duplicate. But when I even inspect it and look at the HTML that Search Console shows, of course, you're loading the whole thing. It's clear. And I can see the different headings and the text. I can actually put both URLs here so you can add it. Sounds good. All right, let me take a break here with the recording. And I can stick around a little bit longer, if any of you want to hang around, but kind of just to lock in the recording so that we don't make it all too long. Thanks for joining in. Thanks, all of you, for submitting questions and asking questions live in person. It's always good to see some activity here. And I hope I'll see you all in one of the future Hangout. Yeah, sure. John, one question.