 All right. Welcome, everyone, to today's Webmaster Central Office Hours Hangouts. My name is John Mueller. I'm a Webmaster Trends Analyst at Google here in Switzerland. And part of what we do are these Office Hour Hangouts, where people can join in and ask their questions around their website and the web search. Bunch of stuff was submitted on YouTube already. But if any of you want to get started with the first question, feel free to jump on in. Can I just ask a question? Sure. If you remember, John, I asked you some Hangouts ago about the problem of favicon having disappeared since some months ago. And I was expecting that the root not indexable may be a cause, because I moved to a structure for multi-language. And I wrote down the name of the website and I know if you have time to have a look, because nothing changed. Nothing changed. OK, I passed it on to the team to check out. So I'm a bit surprised that nothing changed, because it sounded like from their side, they would take a look. OK, I will push again. Maybe we can get something. Thank you very much. Sure. Another short question. In the same site, I have pages that have specification and reviews of products. And there is one main page with the list, of course, of all the products. And I have separate pages that do not show all the products, but filter for category. So I have one page filled in just type A of products. And another list in just type B of products. And each of these pages have a canonical URL to themselves. Of course, if you put other filters, the canonical points to the basic product page, filter at the category. And in Google search, one language is fine. I mean, all these filter at the list are indexed. While in English, almost no pages are indexed. And Google says that these are duplicated pages. So the same page in another language are considered as duplicated. And I don't know if there's anything I can look at. So is it with different languages the same page? Or is it with the filters, with the categories, and kind of? The main list, the overall list, is fine in both languages. The filtered pages, so the pages that show the list filtered by category are normally indexed in one language and are not indexed in English. And in English, Google search says they are all duplicated pages with wrong canonical because they are the canonical points to themself. And instead, Google says it should point to the main list. OK, so they are considered as being duplicated. I don't know if it has been clear. OK, I think that can make sense. I mean, it's hard to say without looking at your site. But I think that that can make sense. So our systems, when they come across setups like this, where there is a possibility for a lot of URLs to be generated, and the URLs end up pointing at very similar content. For example, if you have a category page, and you can filter by color, and you can filter by size, and all of these things, then the products that you show are essentially kind of just the same things. Different orders, different selection of the same products, essentially. And our systems try to recognize those kind of setups and to figure out which parameters in the URL are not important for the site. And then they will kind of skip that and focus on the canonical URLs, or the ones that they think are canonicals instead. So my guess is our systems looked at the setup that you have there and thought that we can save you time by focusing on the canonical URLs. So one thing I would look at there before trying to kind of fix this problem is if it's really a problem. So in particular, are these landing pages that you want to have indexed? Are they critical for indexing? Is it something that is very visible, or would otherwise be very visible in search? Is it the case that the product pages themselves are still indexable? So usually from the category page, you link to the product page. And the products are the ones that you usually would focus on. If those products are all indexed normally and if the pages that we fold out as canonical are not critical for your website, then I would just leave that and kind of let it be resolved like that. On the other hand, if the products themselves are not being indexed and if the category pages that you're trying to get indexed are really critical for your site, then I would double check to make sure that the URL structure that you're using is one that does not allow Google to kind of run into the situation where we start to ignore things. So one example that I sometimes see is that you have parameters in the URL that can be swapped out for any text, and they still leave the same page. For example, you have maybe product name equals a long descriptive name, and then you have the ID as well attached to the end. And as long as the ID is there, then that page shows a normal page. And that's something where our systems would say, oh, well, probably this product name is irrelevant. And we can just pick one and focus on that. Yeah, the URL does contain a variable because these pages are filtered by compatibility. I mean, it's a list of accessories, and the category list is the list of accessories that are compatible with a specific product. So I would be interested in having an index because if you search for accessory compatible to a specific problem, then you have that specific filtered page. And so the idea is that I have to check that if I put a random ID for compatibility, I should return 404 or yeah. Yeah, yeah. And you can also check in Search Console, there is the URL parameter handling tool. I think it's in the old part of Search Console where we show the URL parameters that we've noticed on your website and the ones that we've started to ignore. And you can change the settings there and say, well, actually, this is one that I think is important for me. And we'll pick that up. OK, thanks. Sure. All right, any other question before we get started with this interview? Done. I've got one if now's a good time, John. Go for it. Mine's a bit of a conundrum in terms of user experience. So it has to do with Flash. So we run a large digital magazine's website. Lots of its user-generated content. So we've got about 2 million Flash magazines that we're essentially going to retire because by the end of the year, most browsers don't recognize them all anyway. And so we've got the choice now purely through our server setup. We've got the choice of do we remove all of that content and essentially we'd love to 404 it. But the way that we've got it set up because a lot of these are files is we can 405 it, which is a very ugly access denied page of death. All we have the option to directly replace the file, give the user some kind of information, i.e. this content is Flash. We've retired it now. Go back to the main page and then canonicalize that content. But obviously we're talking about a scale of 2 million pages that suddenly overnight on our website become identical with the same message. Just wondering from the user experience side, but then also obviously from a crawling and indexing side, what would be the best kind of route to go down? So in the long run, from an SEO point of view, both of these would be equivalent. So what would happen is the 405 we would recognize as an error. We would drop those pages. That's pretty fine. If you serve a HTML page instead and the HTML page is the same content as other pages, then what would happen is we would pick that up as a soft 404. And then over time, we would treat it similar to the page not found. The difference that you would see probably from a practical point of view is that we would continue crawling the HTML pages longer before we slow down there. Because it looks like a normal HTML page. We'll double check a while. And probably we would just recrawl those more often. But if you used to have PDF files there or Flash files or whatever, then it's probably not the server load that you're worried about. So that's something where for a longer period of time, we'll be recrawling that. Practically speaking, we'll treat them the same. So my recommendation in a case like that would be to focus more on the user experience side and say, well, I'll put an HTML page here. And Google will treat it as a soft 404. Soft 404 isn't great, but it's essentially what you want. You want Google to figure out, OK, this page is gone. Yeah, and that is essentially it. I guess what we wanted to do from the user's perspective is when they land, kind of give them more information. Unfortunately, with our server setup, you can't customize any kind of 405 messaging to explain why this content's been removed. So OK, cool, brilliant. Thank you. Sure. OK, cheers. All right, I think someone else had a question. Yeah, OK, also sort of an old topic that we discussed in the previous hangout. Basically, if you remember, we have this weather website, and we have the issue that very weird canonicals are being selected. And we think going back and forth with the team about it since basically end of June, but still really, topic couldn't be progressed a lot. We are still in trial and error mode. And so I was wondering if there's anything that we can do to sort of speed this along, because now is our high season. And business is already pressuring me quite a lot to not get this fixed, but to take some radical measures. We are really talking about relaunching the whole site on the different URL, because it's in such a broken state that we are losing almost all of our relevant search traffic, which is horrible for us. Can you drop some sample URLs maybe in the chat here? Then I can pick that up afterwards and double check with the team. I can also post the webmaster thread. It already has almost 30 replies. So we are back and forth a lot, but it seems to be a difficult issue to pick. So I appreciate that there are a lot of people trying to fix it already, but it's really business-wise it's killer for us. It's really important. Sure, thanks a lot. If you can post maybe a link to a thread or a link to the pages where you're seeing this problem in the chat here, then I can pick that up afterwards. Oh, fantastic. Cool, thanks. All right, let me run through some of the submitted questions. And we can get, or do you want to go, Chris? Oh, yeah, I'd rather ask you, actually. It'll probably be easier. We run quite a nice career advice platform. And we've been building this for like 12 years now. Sorry, eight to 10 years. It previously allowed open submission of guest posting, and people would come in, log in, and get paid for actually providing content. And we never really had much editorial moderation in that process. It was very minimal. The last three, four years, we've stepped up the quality. We're trying to follow Google's best practices, the webmaster guidelines. And we seem to run into a little bit of an issue on the older content and some bad, outbound linking in the past. So we have a manual action now for outbound unnatural linking. And during the submission process, we tried to follow all the recommendations by it seems the tools we were using didn't uncover all the links on the first audit, and then the second audit we found issues as well. And we've learned really painfully over the last five months now that maybe we should have taken more time on the initial reconsideration. And we are where we are now. And we're just now we're waiting three months, I think, from the last response, which was a processed response. And we had no note from the reviewer telling us what to fix. So we're kind of at a dead end here, wondering what to do. Do we wait longer or do we keep following up because I've seen advice don't follow up and do follow up. And we don't want to aggravate you guys and spam you with reconsiderations. I'm just wondering, would you recommend in such a long wait for five months here? Yeah, that seems pretty long. So I think, so in general, with reconsideration requests, it's not something where you get kind of pushed forward if you do another reconsideration request. So just continuing doing that is probably not going to help. But it sounds like something is stuck. So if you want, maybe post your URL here in the chat, then I can take a look at that with the team to see what might be happening there. And the last response you got was that it was being processed or? It said it was processed and the note said underneath that it's either adjusted or revoked. And if it remains in Google search console, it means it's just adjusted. So it still applies to the whole site, the manual action. And we've seen our traffic deteriorate with COVID since the spring really. So it's kind of we're in a desperate state now to get something done. I've even contacted a consultant and they said to try reach out to you. So I'll post you the link anyway now in the chat. Yeah, if you can post it now, I can double-check quickly to see kind of roughly what the status is. It's not always the case that I can see exactly what's happening, but maybe I'll get something. Let's see, that's the correct link. See, I don't know what the current status there is. So I see we got a lot of duplicate reconsideration requests from you, but one is still kind of open now. Okay, I just did the message somewhat, but I wanted to give you all the evidence each time. But then I read maybe I should have customized the whole message each time and explained exactly what was done. And usually what happens is when we get another reconsideration request for the same site and one is still pending, we'll try to process the earlier one first. But it seems like that's from May and it's quite a good past May now, yeah. So I'll double-check with the team, see if we can. If you push it on, that'll be amazing because we're just waiting here and it's just a bit frustrating and we're already struggling with COVID and losing a bit of business and traffic as well, so we really appreciate it. So usually with these kinds of manual actions, what happens is we just devalue the outbound links on your site because we're not sure, like if we can't figure out which ones are actually good ones and might fall into kind of like a safe mode type thing, but that wouldn't affect the ranking of your website. So if you're seeing things around the ranking of your website differently now, then that seems like something worth kind of attacking separately. I think it's good to get this resolved because then your website is really in the clean state again, but if you're seeing significant changes in ranking and visibility in search, that would probably be something different. Well, we dropped, I think it was about 35% a couple of weeks after the initial notification came. So that was when it was alarming that we've been hit penalized from the manual action itself. I think after we submitted it, sorry, the first response we sent and we got rejected shortly after because of the issues of our audit. We saw an immediate drop. I think it was on Friday the 13th of April, I believe, where we saw that dip, but this COVID came at the same time as well. So it was quite difficult for us to think, you know, we've been double hit by both factors or it's Google or it's COVID, we couldn't really differentiate. And now I've got either the decision was to even no follow everything because we feel we've done, we've no followed everything, which is of any possibility of being low quality. So we don't really wanna do that because I wanted to ask you a follow-up question if I can. Would you recommend no following all outbound links on a site? Because from my understanding of SEO, this will lower the relevance, you know, of the platform. I don't think it would lower the relevance, but it's unnecessary. I would try to link naturally within the web and that's essentially fine. My general feeling here is really, if you're seeing a significant drop in search, that would be unrelated to the manual action. That would be something that would be separate. So one thing I've sometimes seen, I suspect it's not the case in your situation is that when a site has a lot of unnatural outbound links, then sometimes it's part of a bigger network where it's like everyone has all of these unnatural outbound links and a lot of support of that website was due to the unnatural outbound links. And if the web spam team takes a look at that network and kind of neutralizes the whole network, then of course those sites will also lose that support. So that's where you might see a drop in visibility. My guess just, I don't know, from talking with you is that probably you're not a part of a crazy link network where it's like the support to your site has also been neutralized. But what I would kind of focus on here is try to kind of leave the unnatural outbound links, manual action kind of running. I'll see if we can get that resolved on our side, but I wouldn't assume that that will fix the visibility issue of your site. So I try to continue looking at other things and try to find ways to really significantly take things a step further. Thanks a lot. Well, it is stabilized for now. So I think it maybe was due to COVID. So yeah, thanks for that. Really helpful. Sure. OK, let me go through some of the submitted questions and we'll have more time for other questions along the way. Do you know how Google determines how and why they show a photo of a product on one website's organic listing versus another website that doesn't receive it? For example, if you Google Use, Tanda Civic, nearly half the organic results have a photo next to the website description, but half don't. When I look at the schema and images of those and those without, they're virtually the same. What am I missing? So we do try to pick up an image for particular pages if we can find one. And we do try to show that in search. However, we also need to make sure that there is some kind of a reasonable balance with regards to how many images that we do show in search. So it can certainly happen that for some pages we show an image, for other pages we don't, maybe for other queries, we would show an image for those pages too. To make it more obvious to us which image you want to have shown, I would go back to the normal structured data. For example, with the article markup or I forget which other variations of the article or web page markup that you can use there where there is a primary image on the page that you can specify. And by doing that, you make it a little bit easier for us to pick that up. That said, even without this markup, we can usually figure out what a relevant image for a page might be. And we can usually try to show that where appropriate. A 301 redirected 500 article pages to a new URL structure. The website has about 2,000 pages in total. The pages started to get crawled and indexed and recover the traffic drop they experienced during those days. But a few days later, due to a technical bug, the URLs switch back to the previous URL structure. And traffic from those pages is almost gone. Other pages and page types of the site were not hit by this, only the articles. The fix took place the same day. Plus, we modified the canonicals and backlinks and internal links as well to the new structure in the following days. Is this mess with the bug and Google indexing the new URLs? And suddenly, those are removed and back again after fixed it, might that trigger a re-crawl for the entire website, which might take weeks to recover. It is possible that this will trigger something on our side where we try to re-crawl the website overall. Usually, the triggering of a re-crawl on our side essentially just means we try to get an updated picture as quickly as possible. And usually, that's due to us recognizing when there are significant changes on a website. So that could be, for example, you change the whole URL structure, or you move from one domain to another, then we try to get that reprocess as quickly as possible. It's not the case that the website will stand still or be dropped out of search during that time. It's just we're trying to crawl a little bit faster to catch up again. With regards to this situation, where you move URLs and then those new URLs disappear, and then you add them back again, it kind of depends a little bit on what happened during that bug stage on your side. If those new URLs disappeared completely and the redirects were still in case in place, then it would have been like you're redirecting to a 404 page. And in cases like that, we will think, well, you remove these pages, so we will drop them from the index. So in those cases, it probably takes a little bit longer than normal for us to pick that up again and to index all of those pages again, because we have to get back into when we look at your web page, we have to consider, again, well, actually, these pages might not be gone completely. We'll double check them again. And we'll get back into the normal crawling speed for those individual pages. On the other hand, if the redirect just dropped and essentially it looks like it moved back to the old URL, then those are cases which we can usually cover fairly well, because it just looks like, well, you temporarily move them here, and then you move them back again, and then you move them here again. For our systems, we don't really care. I think it helps to make up your mind which URLs you want. But essentially, this moving back and forth thing, that's something that we should be able to deal with. So that probably gets resolved fairly quickly. But in either of these cases, even in the worst case scenario where we thought you remove those pages and we kind of crawling those URLs less frequently, with a website of your size, with 2,000 pages in total, we can crawl a lot of content fairly quickly. So that's something where I would suspect, in the worst case, within a week or so, that will settle down again. And things will be pretty much OK. And at any rate, when it does settle down, it's not that Google systems will think your website is bad because you had this technical problem. It's essentially just, well, we have these pages indexed now, and we can rank them normally again. There is no kind of bad feelings left behind from a kind of a technical glitch like this. So these technical issues happen to every site. So you're not alone with that, and our systems have to deal with that all the time. I need to 301 redirect a page from a subdirectory on a domain to a subdirectory on a new domain. Do I need to have the new page indexed by Google before making the redirect to it? No, you can redirect to a completely new URL. That's usually the case how things are done. It's like you take one URL, you redirect it to another one, and then we recognize the new URL and we focus on the new URL. So it doesn't need to be the case that you have to first get that page indexed and then set up the redirect. It doesn't harm if you do that either, so whatever works. An article of mine was ranking on the first page of Google. There was a typo in the URL. I did a 301 redirect to the correct URL, and Google was still ranking the old URL. So I requested re-indexing of that page, and within five minutes of the request, the page disappeared completely and couldn't be found using the site operator. After three days, the page got back in Google Search, but now it's no more ranking and can only be found with the site operator. Can you tell me how long it'll take to get back into the original position? I don't know. So like you mentioned, I also don't think this is a penalty. It's not like a black hat practice or anything. This kind of thing can happen. Usually the cases where I have seen something like this where a page disappears completely is more due to the site owner using Search Console to remove the old URL. And then we run into a situation where maybe we make the old URL canonical, but you told us to remove it so we won't show anything. I don't know if that's something that happened here. But in any case, it sometimes happens that things fall out of our index. And usually over time, they come back in and they start ranking normally again. So this is something where I would try to just give it a little bit more time to settle down again. In Russia, we have two powerful search engines, Google and another. Can I separate the site on two domains? Visit from Google, send to the first domain, and from the other one to the other domain. The second domain is closed for Google in robots.txt, but open for other search engines. The idea is to try to recover Google traffic, but not risk losing traffic from the other search engine. Before moving, it was 52% from Google and 48% from another. Will it work any bands because the two domains with similar content, but one is closed for Google and Google Chrome users, will have different behavior on opening one domain? So I don't know if this makes it any easier for you to do, but at least from our side, if you want to do something like this, that's perfectly fine. If you prefer to block a part of your website or one of your domains and say, Google should not index this domain, that's perfectly fine. That's your decision to make. The thing to kind of keep in mind is that there's more to your website than just your domain. So in particular, links on the web are things that we try to pick up that pretty much all website, well, all search engines try to pick up. And if you have two separate domains, then you will have some links going to this domain and some links going to that domain. And if you block one domain for one search engine, then that search engine will only see a part of the picture. And they might assume that actually this website maybe is not so great after all because only the small part of the links are going there. And that's something where potentially you're making it a little bit harder for your website than it needs to be. So that's kind of what I would watch out for there. The other thing is also with regards to having two websites for two search engines, you're just making everything much more complicated from a technical point of view. How do you deal with users? How do you deal with users from different locations? All of these things still kind of fall in here if you wanted to do maybe ads at some point. How do you deal with that? Do you run ads separately on the different domains? How do you promote those websites? If you want to publish something really fantastic and you want to spread the word about that, how do you do that? These are all things which, from my point of view, make it a lot more complicated than it needs to be. And I don't know which search engine you're referring to. Well, I can guess. But my general feeling is that most search engines kind of look at similar things. So it's not that if you have headings on one site, that's one search engine will say, oh, this is fantastic. And the other one will say, oh, this is terrible. But rather, search engines try to look at pages and they look at it in slightly different ways and try to understand those pages in different ways. But it's not that they would say, this page that one search engine says is fantastic is now terrible. So they kind of have similar ways of looking at pages. So from that point of view, I kind of worry that you're making it a lot more complicated than it needs to be. And you're probably finding a problem where there is not. When taking a mobile-friendly test for the same page at a different time gap, it shows three variant results, like partly loaded, not mobile-friendly page, and sometimes showing mobile-friendly page with 17 resources unloaded. What is happening behind the crawling process? Is that the JavaScript not loading property? Or are the tracking codes making the page really slow while rendering? So this can sometimes happen. What happens with the mobile-friendly test in particular is we know users of the test are impatient and we try to bring back the results as quickly as possible. However, at the same time, we also know that websites have limited capacity. So we try not to overload their servers. So what can happen is if you have a very complex page that uses a lot of embedded resources, a lot of different things, maybe even from different locations, different servers, then it can happen that we're not able to completely load that page in time to do the full test. So what will then happen is we will load as much as we can, where we're sure that we're not overloading any servers. And we will try to run the test on that part of the page. So if you run the test and you see that there are different JavaScript files or images missing, then that's generally a hint that that is happening. And that's generally something where I would say maybe wait again a little bit longer and try that test again at some later point to make sure that you're getting a real picture of how that page is actually crawlable and renderable. And if you're seeing that it never is able to be processed properly, then I would double check to see if there are maybe things that you can simplify on your pages, maybe combining different kinds of JavaScript, maybe removing some of the different tracking setups that you have on the page. Maybe you have other things that significantly slow things down. A good way to look at that is to look at the waterfall diagram that you can see in Google Chrome if you go to the developer tools. I think that it's in the network settings in the developer tools. What happens is you reload the page when you're there. And then it shows how all of the different resources are being loaded and when they're being loaded. And usually when you look at that and you compare it to other pages that you have or other pages on other people's sites, you can kind of guess where you might be going a little bit too far. It's not that there is any specific limit on our site within number of resources or the time that it takes to load. But it is something where you can look at some pages and maybe they have 100 or so resources. And other pages, when you load them, they have 10,000 of resources that need to be loaded in order to render the page. And then you can imagine that somewhere between there is probably a reasonable range to aim for. So if you have thousands of resources that are needed to load a page, then I could imagine that the mobile-friendly test at some point was, hey, well, this is like we're running out of time. We have to make it cut off here. Another tool that you can use, which gives you this waterfall diagram in a more neutral way in the sense that it's not tied to your computer or your settings, your internet, is webpagetest.org. And there you can use different device types. You can look at the screenshots. You can see how long it takes to load different parts of your page. So that's kind of the direction that I would go there. Let's see, second part of the question. A page without an H1 title, will it still rank for a keyword, which is in the H2 title? Of course, absolutely. I mean, will it still? I don't know if it will still, but it can. It can, absolutely. So headings on a page help us to better understand the content on the page. Headings on the page are not the only ranking factor that we have. We look at the content on its own as well. But sometimes having a clear heading on a page gives us a little bit more information on what that section is about. So in particular, when it comes to images, that's something where headings and the context of that image helps us a lot to understand where we should be showing that image in image search. Because by design, images are not text. We don't automatically know what we should be showing it for. And that combination of the image plus the landing page is something that depends quite a bit on the text of the page. And when it comes to text on a page, a heading is a really strong signal telling us this part of the page is about this topic. And whether you put that into an H1 tag, or an H2 tag, or H5, or whatever, that doesn't matter so much, but rather kind of this general signal that you give us that says, well, this part of the page is about this topic, and this other part of the page is maybe about a different topic. So that's generally what I would think about there. Is it good to have structured data WordPress plug-in, or rather do it manually? Both approaches work fine. I think from purely a practical point of view, I would personally go with a plug-in that does this for you, because then you can focus on the content. You don't have to focus on the technical implementation. If you're using something like WordPress, you're already focusing more on the content rather than, how do I make an HTML page, or how do I serve my HTML page from the server? You're already focusing more on kind of the content, not the technical implementation. That said, in the end, if it's valid structured data, we don't care where it comes from. If it comes from a plug-in, from your theme, if you added it manually, if you use JavaScript to add it after the page is loaded, all of those different types of structured data are perfectly fine. Is it possible that a website has been penalized in its traffic for less than 20 minutes of 503 service temporary unavailable and returned to previous levels a week later? No, I don't think that would happen. So usually, with 503s, what happens is we will not index the content that you serve us when we see a 503 response code. And we will assume that this is a temporary issue until we recognize that it's a permanent issue. So if you're talking about 20 minutes, or maybe half a day, or a day or so of 503 response codes from your server because it's down, because something is blocked, or something needs to happen, that's definitely something we can deal with, where we say, well, we'll try again. And essentially, during that time, we will not change the indexing of those pages. However, after a couple of days, we will, when we still see a 503 status code, we will assume that this is not a temporary issue, but maybe your server is down, or maybe these pages were removed and your server is set up in a way that it serves a 503 instead of a 404 response code. And what will happen then is that page by page, we will drop those pages from our index. But if you're talking about a time frame of 20 minutes, that would definitely not happen. And it would definitely not be the case that we would kind of demote that website in ranking during a time when we're seeing 503s. Because 503s are a very common thing on the web, and it's something that you should be doing if your server is slightly overloaded, or if it can't deal with the responses, then 503 is the correct approach there. And that's not something that we would kind of penalize the website or hold against it in any way. After the 5th of May, our site lost their rich snippets and was also removed from the recipe carousel. For three months, we're looking for a reason with no luck. We did tests at different URLs with LD plus JSON, schema.org, minimum properties. Previously, recipes were fully described. And now we switch to schema microdata only. Here's an example of a recipe. Interesting thing, some of the recipe collections, which grouped together another type of URL and article, marked up only with the necessary schema.org recipe properties, which didn't have them removed from the recipe gallery. Only removed only recipes grouped by URL, recipe slash asterisks. I don't know. This seems like a very specific question. I'll take a look to see if there's something specific happening here. But generally speaking, if you had rich results, that were shown for your website and they disappear from one day to the next, then unless something specifically changed in the requirements on our side for that type of structured data, which can happen from time to time, but we try to keep it really rare and we try to let you know about it, then that's more a sign that our algorithms re-evaluated your website and we're not really sure about the quality of your website. So that's something where I wouldn't focus so much on the technical implementation of that structured data. If you're sure that it was correct before, if it passes the validators that we have, then that's generally OK. I would focus more on the overall quality of the website. So I don't know this website. It's hard for me to say that this is not a good high-quality website. But that's kind of from our point of view where we see these kind of changes happening, where it's like, well, we kind of re-evaluated everything around the website. We're like, ah, we're not really sure if it meets the bar for what we would like to show in the rich results. And what can sometimes make this confusing is that sometimes a website might be kind of on the edge and we will re-evaluate that after some time as well. And if during that time, you're kind of fiddling with the structured data and fiddling it with it in a way that kind of breaks the structured data, then suddenly we'll be like, oh, we would like to show rich results from this website, but now the rich results are broken so we don't have anything to show anymore. So that's something sometimes to watch out for there. So what I would do here is double check to see that things are technically OK. So I would use a rich results test, double check that you have the right rich result types on the pages that you want to have shown, double check the kind of policies that we have around those rich results types to make sure that you're doing things in a way that matches what our systems are looking for. And then do maybe a site query for your website to double check to see if we could directly show those rich results types. Usually when you do a site query, we try to show the rich results types even if we otherwise might not show them in search. So that's kind of a weird workaround to figure out if there's a quality issue or not. And if they're shown in a site query but they're not shown for normal queries leading to your pages, then that's usually a sign that you need to work on the overall quality of the website. So that's kind of the direction I would go externally. I'll double check with the team to make sure that things are kind of working as expected here. But that's usually the direction I would head here. Why are some URLs submitted in a site map but Search Console shows indexed not submitted in a site map? It's hard to say without looking at specific examples, but we don't always process everything in all site map files. So that might be something where you're kind of running into this kind of an edge case where we've seen the site map file, but maybe we haven't processed all of the contents in there yet. And then Search Console will say, well, it's indexed, but it's not submitted in a site map file because we haven't had time to draw that connection. Due to a bug, many of our web pages are missing meta titles and meta descriptions for three to four months. Metrics seem to indicate that this had an impact on traffic from Search. Now that the bug is fixed, what's the best way to indicate to crawlers that these pages have been updated? Submitting each URL individually for recrawl with the cumbersome, I was thinking of updating a last updated date for the offending pages in our site map, about 500 pages. Could that make it seem like I'm trying to game the system since the actual body of the content hasn't changed? Will I be penalized? Is it better to leave it be? So changing the last modified date is exactly what you should be doing here because you modified these pages. You put a title on these pages. You added a meta description on these pages. Sometimes even when you add structured data to a page, it's not visible at all. But it is a bigger change on a web page. So setting that last modified date in the site map file is exactly the right thing to do here. If you have a date that you serve with the pages themselves, then updating that would be great too. But essentially, using the site map file is what you should be doing here. You can also do that individually in Search Console, but again, with 500 pages, it's a lot of work. What I would do personally is try to find maybe the top, I don't know, 5%, 10% of the pages that are really important for you and submit those manually and just make sure that everything is otherwise set up properly in the site map file. So that way, the pages that you really care about, the ones where you think people are really searching for and a missing title or missing description is making it less interesting for people to click through, then at least those are updated as quickly as possible, and then the rest will be updated naturally. Last time in the German Webmaster Hour, you've been talking about the rich result FAQ problem that has been all focused on showing rich results and search results. I have additional questions to that. We did not change the way of schema implementation and still the site has the FAQ markup in the source code, but Search Console report is empty. All valid markups are gone. If we test the site, even as live URL in Search Console or in the rich result test tool, everything shows valid, then markup just doesn't show up in the report. What could be wrong here? I don't know. It's hard to say without looking at the site itself to kind of see what we're picking up on here. Usually the report in Search Console takes a bit of time to be updated and populated. So when you add a site to Search Console for the first time, some of the reports will have data right away and others might take maybe a week or so to be updated. So sometimes you would see a difference there like that. In general, if the markup is on the pages and is findable with the rich results test, then that's what you should be aiming for. With regards to the FAQ markup in general, one of the things that I've noticed people talking about online is that we're showing fewer of these in the search results. And that's something, from my point of view, that's kind of natural development where we try to find the right balance between showing these everywhere and showing these for pages where it kind of makes more sense. And that's something that generally doesn't have any kind of effect from the markup that you have on the pages themselves. It's really more that suddenly everyone has added FAQ markup to their pages and we can't show every search result with FAQ markup. So we have to kind of find to which of the ones, which queries, which pages, we should be showing the FAQ rich result types for. Okay, still a bunch of questions, but we're kind of running low on time. So I'll switch to anything from you all. It looks like maybe on the Google Meet side, something is kind of blocking random people from joining, but I'll pause the recording in a bit and leave the hangout running for a while. So maybe that will let more people join in. We'll see. Anyway, any questions from you all? Hi John, I have one. Okay. So this is happening with our website basically where we have multiple, you can say website within one global website. So we are using older structure to kind of target different country. Let's say you guys UK, Japan, Brazil, Mexico. So in that basically from the last week or something, you have noticed a change in the one specific country, that's Japan. So we're in Google detecting the duplicate of Brazil, that's something and now the Japan page is kind of removed from the index and instead kind of ranking the Brazil page. So I just expect URL, wherein it says it's a duplicate and kind of your Google as selected as a different chronicle of Brazil. So just wondering like when why is it happening? So maybe it might be one of the possibilities happening like recently tech team has developed or did one specific change in the actual flag, where they have implemented kind of the default version of the page is in English and the alternate in the Japanese. For similarly for the canonical version of the Brazil, where they have marked as a default English and the alternate as a, you can say the Portuguese language or the Spanish version. So in that this way, Google might be getting confused like I mean, is it the case or maybe something else which is kind of not allowing Google to kind of crawling or kind of indexing the specific page that we actually wanted to. So are the pages in the same language or are these different language pages? Yeah, they're in different language. For example, in Japan case it is in Japanese, the default one and the one, the Google's reference actually in the Portuguese. That's all to a different language. Yeah, okay. That sounds to me like either the website is trying to automatically serve the content in the user's language or there's some kind of a mismatch with the rel canonicals on the page. So there are situations where we get confused and we think that two pages are the same and we will fold them together. But usually that's the case when the pages are the same language. Like you have one page in English for Japan and one page in English for, I don't know, Hong Kong and the pages are exactly the same. They're just for different countries. Then that would be something where our systems would say, well, we can simplify this and just keep one as a canonical. But if the pages are in multiple languages, they're served directly in those languages, then that wouldn't be something where we would say these pages are the same because they're translated. Because translated content is by definition different content for us. So we shouldn't be kind of confused by that kind of setup and fold things together. That seems more like something where the confusion probably comes from something else other than kind of the hreflang pages there. But if you want, maybe you can drop the URLs in the chat here and I can take a look at that with the team afterwards. Shona, John, so let me do some more context to it. Basically, yes, like you mentioned, currently it behaves like, depending on the user's browser language, it's something that serves the content accordingly. But I cross check the same with Gary, where he mentioned it's okay as far as you are serving the right content to the user and the bot. So in that particular case, when the user is coming, they're getting the Japanese and even when the bot is coming, they're getting the content in the Japanese itself. So what conflict is happening over here with the hreflang is that the default version, the tech team has implemented something in English, but the page is in Japanese. So I feel like you mean the X default hreflang? Means like the page, for example, the slash JP is the default page where the content present on the page is in Japanese, but by the hreflang, the tech team has implemented this page in English. So that is though you can say conflict is happening, like I mean the hreflang saying this page is English, but when you look at the page, it is actually in Japanese. Oh, okay, yeah. That sounds like something worth fixing, but that shouldn't be causing an issue with indexing. I think the one thing to watch out for is that Googlebot almost never crawls with an except language header. So that's something where maybe we'll use English as an except language header, or maybe we won't use any language as an except language header. And if you're serving the English content to users with the English except language header, then we would only see the English content. So that's kind of like, you're trying to do something fancy, but instead of automatically serving that content, what I would do is maybe show a banner on top and say, hey, we have the English or the Japanese version here, and then you can follow with the link to get to that version rather than swapping out the content directly. Yeah, so John, we already have those options as well, like I mean we have providing this a language switcher where you can use it and actually switch to the different languages, but I mean, it was absolutely was fine before the implementation by the tech team and now when they implement this particular change, we have seen a lot of changes in the Japan website special. Yeah, I don't know. Okay, I'll take a look with the team. Sure, thank you, John. Okay, we're kind of out of time. I'll keep the hang out running. I'll just pause the recording now. Perhaps that makes it easier for other people to join in. Sometimes Google Meet is a little bit super protective and blocks everyone from joining in. So let me just find the pause button. Thank you all for joining in and hopefully we'll see more of you in one of the future hangouts. All right.