 All right, welcome, everyone, to today's Google Search Central SEO Office Hours. My name is John Mueller. I'm a search advocate on the search relations team here at Google. And part of what we do are these office hour hangouts where people can jump in, ask their questions around search, and we can try to find some answers. Bunch of stuff was submitted already on YouTube, so we can go through some of that. But like always, I think it's always need to start with live questions. Anything from your side, anyone who wants to get started? Yeah, I would like to ask the first question. OK, go for it. My name is Vahan. I'm an IT director, a director of Search Engine Journal. And one question I have about Core Web Vitals is, is there a possibility that Google can start, revise that score in Webmaster quicker? Like, I did updates on the website and have found that Core Web Vitals are broken after 20 days because it's updating in a weeks, right, in a long period. And I have fixed that, but it will take another couple of weeks to have that fixed. Is there a possibility that Google can review and make those updates more quicker? Like, not like 28 days, but a couple of days? Yeah. I don't know. I doubt it because the data that we show in Search Console is based on the Chrome user experience report data, which is aggregated over those 28 days. So that's the primary reason for the delay there. It's not that Search Console is slow in processing that data or anything like that. It's just the way that the data is collected and aggregated, it just takes time. So usually what I recommend when people ask about this kind of thing where it's like, I want to know early when something breaks is to make sure that you run your own tests on your side kind of in parallel for your important pages. And there are a bunch of third-party tools that do that for you automatically. You can also use the PageSpeed Insights API directly and pick, I don't know, a small sample of your important pages and just test them every day. And that way you can kind of tell if there are any regressions in any of the setups you've made fairly quickly. Obviously, a lab test is not the same as the field data, so there is a bit of a difference there. But if you see that the lab test results are stable for a period of time and then suddenly they go really weird, then that's a strong indicator that something broke in your layout in your pages somewhere. So you do. No. Quick follow-up there then. So does that mean that if I see that I are really bad for core web items and managed to fix most of those issues in one day, the next day that would be, or rather two days later, that would be part of these 28 days? Because would it be a rolling update or is it every 28 days that it happens? So I don't know for sure. I think the Chrome user experience report site has that documented. I'm not sure if it's like a batched update that is just done every 28 days or if it's more of a rolling thing. I know in Search Console we have kind of the overtime data and it's not that it jumps every 28 days. So my guess is it's probably more rolling. All right. I will check that. Thank you. So it can still take 28 days to fully. So after one day, you're 128th of the way there to seeing what the results are, which is why you're just doing your own test manually. Yeah, exactly. But it makes web development very expensive as well. It makes things harder, yes. I mean, it's not that we're trying to make things harder. It's just the way that this data is collected in Chrome. It just takes time to be aggregated. So just to know everybody what did broke the Corvette Writers score since something was updated on the Corvette Writers calculations since it's since beta. So we were hiding the navigation menus to keep when you scroll down. And it showed when you scroll up. And used CSS position to animate that, like hide it. And since that position animation did spoil the Corvette Writers. So even though it's a sticky menu and it's not causing layout to shift, but it's calculated as a layout shift because you are animating the position of the element. So we did change that animation from position to opacity. Like we are just feeding out it instead of moving away from the screen by position animation. Yeah, the cumulative layout shift is sometimes, I think, tricky to interpret and figure out what exactly is causing issues there now. Yeah, because in the past it wasn't causing. Our Corvette Writers were all green. And one day I found that everything is in red. What could cause that? And I found that just CSS position animations, which even don't cause the layout shifts, are contributing to layout shift calculations. Yeah, I think for things where you feel that the calculations are being done in a way that doesn't make much sense. I would also get in touch with the Chrome team. I think, especially Annie Sullivan, is working on improving the cumulative layout shift side of things. And just make sure that they see these kind of examples. And if you run across something where you say, oh, it doesn't make any sense at all, then make sure that they know about it. It's not so much that from Google's search side, we would try to dig in and figure out exactly why this is happening with that score. But we kind of need to rely on the score from the Chrome side. And our goal with the Corvette Writers and Page Experience in general is to update them over time. So I think we announced that we wanted to update them maybe once a year and let people know ahead of time what is happening. So I would expect that to be improved over time. But it's also important to get your feedback in and make sure that they're aware of these weird cases. Thank you. Sure. All right. Hi, John. Yes, you raised your hand. Perfect, exactly. Great, yeah. So our website consists of a lot of thousands of guides that we made to help people understand visa requirements based on their location. And the way we've designed these guides are that they're meant to be a one stop destination. But that said, some of the content is overlapping. And there's a risk that Google might interpret these pages as doorway pages, even though that's not our intention. For example, we have a guide for France visa in Los Angeles and then France visa in Detroit. And it's personalized to the city. But a lot of the content is also similar. And so what is your advice to make sure it's not interpreted as doorway or canonicalized by Google, given that we have so many of these? I don't know. It's hard to say. So offhand, just hearing that you have city-level pages for visa advice feels a lot like you're headed into the direction of doorway pages. So that's something where I would be really cautious about expanding too much in that direction. Because obviously, you're going to have things like, well, all of the country information is exactly the same. And essentially, the difference is the address and maybe a telephone number opening hours. And that's something where I suspect our systems, on the one hand, could be getting confused from the content side and where probably if someone from the Web Spam team were to look at that, they would say this is potentially too much, especially if you really have on a city-level, country-wide information that feels like you could easily expand that to 10,000s of cities and claim that it's all unique content because it's for every city individually. And I have some kind of basic information about each city as well on those pages. But in the end, it's all about one country and the visa is for the other country. So that's something where I would try to take a strong look at what you can do to try to concentrate those pages so that you don't end up in a situation where you're just taking giant list of cities, giant list of countries, and then crossing them in a database and generating pages. Got it. And then just a follow-up question. So we'll definitely look into it. So across all the pages that we have, Google's indexed only about 100 of them. And the primary reason when I look at the crawl stats report is that Google only crawls about 60 pages. And all the other pages are excluded, like discovered but not crawled, which means that they didn't want to overload our website. But we have full success rate and really low response time. So how would you suggest we go about getting the crawl budget up? Yeah. So there are two aspects there with the crawl budget. On the one hand, the technical limitations of the server. And on the other hand, the demand from Google with regards to what we think is important to index. And it sounds like the technical limitations on your server are less of an issue. If you're saying it's a fast server, it responds quickly, then primarily what you're probably seeing is that Google is running into a situation where it's saying, well, I don't know how useful these pages actually are. And that's something that Google can learn over time. But it's not something that you can force. And even if you can force it for a temporary situation where Google goes off and indexes tens of thousands of pages from your site, if then it still determines, well, actually, this site is not as useful as I thought it was, then it will just drop those pages from the index over time. So assuming this is still the visa level site, then that's something where I would strongly recommend starting off with a much smaller set of pages, a much smaller set of content so that it's something that Google can index. Google can learn over time that actually this is really good content. And based on that, it can expand and say, well, OK, instead of just 100 pages, I'll go and crawl 1,000 pages or go and crawl 10,000 pages and try to get those indexes well. But especially when you're starting off with a site that has a lot of content potentially, I would try to find a way to decrease the size so that you can grow and become strong first and then expand to showing more content. Awesome. Thank you so much. John. Hi, John. Hi. So this is Raminder. I have a question regarding site maps, which is similar to the previous discussion. So we have a new site, and we have older site maps, like ranging from 2009 to 2015, say. And we're facing some of the site maps do have certain issues, like image URLs have migrated. And because of that, we're getting issues in the older site map. So just wanted to check with you how important are the older site maps since for the bot and since we feel it's already archived in that case. And secondly, does it help the crawl budget by removing the older site map? Yeah, good question. So with regards to site maps, we use that to better understand which pages we need to crawl and update. And if you know that you have site map files that point to pages that don't exist anymore or that you don't care about anymore, then essentially, I would try to remove those pages. So if this is a site map file that was useful a couple years ago and your website has migrated in the meantime, you have a different URL structure, then telling us about those old URLs doesn't give us any useful information. So I would consider regenerating the site map files and really making sure that they contain the current set of URLs from your website that you care about. And that's less a matter of crawl budget, I think, but more just kind of like general website hygiene in that you're making sure that Google understands what you care about and is able to process that as easily as possible. OK. Got my answer. Thank you. Sure. Mohawk, I think. You already answered my question. Oh, OK. Emre? Emre. Emre. Perfect. OK, so recently we implemented structured data for voice search, like speakable structured data. And we would like to understand what will be the impact. And is there any way that we can somehow understand what percentage of the traffic come from the voice search? Or is there any trick that we can use to extract this information from the search console? I don't think you can see anything with regards to voice search there at the moment. So that's something people have asked about on and off, not for a long time now, but every now and then. But I don't think there is anything in Search Console that gives information about how the speakable markup is used or when that's shown. So it's almost something that you'd probably have to try out yourself and see is it doing what you think it's doing or is it not that useful? OK, thank you. And I have another question. Sure. It's about how we can force Google to refresh the resources. I mean, the cache resources cache. For example, if we change something with our JavaScript file or, I don't know, the CSS or something like this, how we can force Google to refresh this file. OK, so you mean with regards to rendering the page or with regards to? Exactly, exactly. Because we had an issue, and the page was returning an empty page because of this caching issue. So let's say we deploy to site, and we saw that Google continued to use the old JavaScript file. So what we can do about this, I mean to force Google to refresh the cache. I don't think you can easily force it to refresh that, but there are two things you can do. One is to serve the files with the appropriate caching headers so that Google knows approximately how long it could be cached. It's a bit tricky there because the caching that we do for rendering is very different from the caching that our browser usually does for users. So it's helpful, but it's not the perfect solution. The other thing that I've seen people do is to update the URLs when they make significant changes within the content. So I have seen some that use something like a content hash in the URL for the JavaScript files, for the CSS files. And in general, when we try to render an HTML page and we see a link to a new JavaScript file, which would be based on the content hash, for example, then we would know that, oh, this is a new JavaScript file. We need to take a look at it. Whereas if you keep the same file names for JavaScript and CSS, then we might be tempted to just reuse our cache. OK, thank you. Sure. Esther, I think you're next. Hey, John. Hi. Hi. Hi. We're currently conducting a large site migration after a company was acquired by another company. So we're basically lifting and shifting some pages over to our website amongst our existing content and changing the domain. Are there any top five tips on what I should look out for whilst I'm doing this? Yeah, I think the most important part is really to track the individual URLs so that you have a clear map of what previously was and what it should be in the future. And based on that, on the one hand, to make sure that you have all of the redirects set up properly. So the various tools that you can use to submit the list of the old URLs and check to see that they redirect to the right new ones. The other thing I would watch out for is all of the internal linking so that you really make sure that all of the internal signals that you have as well, that they're forwarded to whatever new URLs. Because what sometimes happens, or what I've sometimes seen with these kind of restructurings, is that you redirect the URLs, you move them over, but you forget to set the rel canonical. You forget to set the links in the navigation or in the footer somewhere. And all of those other signals there, they wouldn't necessarily break the navigation, but they make it a lot harder for us to pick the new URLs as canonicals. So that's kind of the effect that you would see there. It's not so much that it would stop ranking, but it's more that, oh, we just keep the old URLs for much longer than we actually need to. OK, brilliant. Thank you. Yeah, sure. How's it going? Hi. Let me just grab the next one in the list and I can get back to you. Dwayne? No issues. Thank you. So were we thinking how we display our publication dates on site, on the front end? And I wanted to know what the official stance is on whether we need to have both the published date and update date, our last modified date, to comply with structured data. I know that most of structured data requires that you have some visible element that's marked up. So I just kind of want to see what you think is best there. We have a Help Center page on dates. I would double check that. I don't think it's necessary to specify any date in structured data. So if you give us some date information that helps us to better understand it, usually what happens with regards to dates is we try to pick a date that is relevant for the page. And we do that based on the structured data that you have on the page, but also based on things like what is on the page itself. So as much as possible, like a lot of SEO signals, I think it's important to make sure that all of these things align, that if you're giving us a date in one place that it's actually date that's visible on the page, that the time zone is correct, that you specify there, all of these kind of small details as well, just that it matches the other information that we find. OK, yeah, the reason we are rethinking this is because we're seeing that sometimes we aren't seeing the proper monetization date showed up in search. So we want to be able to have that work properly. So thank you. Yeah, our systems kind of work in a way that we pick up all of the dates that we can find for this piece of content. And then we try to figure out which ones kind of match up the best. And based on that, we try to pick the right date. And sometimes, if you have, I don't know, a news site, then you'll have related articles or things like that where you'll also have dates kind of mentioned in the text. And if we don't find clear information in the structured data for the date, then we might pick one of these other random dates on the page as well. We can just follow up with one more time on that. So how does the tool decide to show the last modification date? Does it need to reflect a significant change on the page? Or is there something else I can figure out? I don't think we have any specific guidelines on when you should change the dates. But for practical reasons, I would try to do it then when you have significant changes on the page. I just swapped an ad out in the sidebar kind of thing. But really, if it's in the primary content and you made some significant changes, then that feels like something that you'd want to flag there for users as well. Oh, yeah, not necessarily me changing the publication date. But will Google then pick up the modification date if I made the substantial change versus just showing me the publication date? Sorry. Yeah, I don't know how we decide between publication date and last modification date. Not really sure how you'd be able to easily influence that. I could imagine that we try to see when significant changes happen on a site, but we're on a page. But I don't think we have any explicit guidelines on that. OK, thank you so much. Sure. Hi, John. Hi, this is Mehdi Abbas. Again, I am here with a very simple basic question as I started learning SEO. So this time, my question is related to headings, heading structure, basically. Is it mandatory that we should structure our headings in ascending order or we can leverage the structure as per our need? It's not necessary to have this theoretically correct order of the headings. And the number of H1 headings that you have is also something that is kind of open. I think for a large part it makes sense to try to have a semantically correct heading structure because there are things like screen readers that also rely on headings to navigate to the right part of the page. So it certainly makes sense to try to get that. But I wouldn't see it as something where you would see significant changes in SEO if you change the order of your headings. Another question is related to S1 tags. What's the optimal or ideal numbers of S1 tag we can have in a page? Because I have read so many articles of industry expert that there should be only one S1 tag from the perspective of SEO. So what does you recommend? You can have as many as you want. So I think in many cases you have one primary heading, but if you have multiple, that's fine. With HTML5, it's also the case that by design in HTML you have multiple H1 tags. So it's something where there's definitely not a hard limit with regards to a number of primary heading tags. I think from a focus point of view that you have a clear focus on your page, it makes sense to have one primary topic. But that can be something that you highlight in other ways. It doesn't necessarily need to be the H1 tag. It could be something that you have with a big title, or if this is your home page, then maybe you have other ways of structuring what you think is the primary topic of the page. So can I say Google gives the importance on the basis of structures of headings to the content? To some extent. It's not only that, but it does help us to understand what you think is important for the page. And if you say, well, this is the primary heading for my page and what this page is about, and we see it matches what you have in your content, then that's always useful for us to know. Thank you. Sure. And Rob, you're so patient. Am I, though? So can you give us your current take on the supported image types for the Core Web vitals and page speed? Because you guys still seem to be recommending file types that you don't actually support, or are not really the optimal image types to use. And I say that because when I look at our page speed insight scores, they seem to be fine. We can save 0.15 seconds on JavaScript, 0.9 seconds on deferring off-screen images. But we can save 12 seconds by changing the file types to image types like JPEG XP or JPEG 9000 ABC that you don't even support. So can you clarify that? I haven't seen that. So it's hard for me to say. I can share my screen. Maybe not. No, I mean just because since we're talking about images and things, I don't want it to suddenly be like, oh, it's like you're showing copyrighted images on your YouTube thing. So that's the primary thing I'm a little bit worried about. But if you want to drop your URL in the chat, like the one that you're looking at, then I can take a look at that afterwards. It's just our UK homepage, which I'm sure you know. OK. But in particular, the time because we have no problem updating the image to a file type that you like. But why is that still the recommended file type when you guys don't really support JPEG 2000? I don't know. It feels like we should support that. You're saying we don't support it in image search? Well, as far as I know, and our developer, and whenever you search it, Chrome doesn't support JPEG 2000, but recommends it as the recommended file type to speed up your pages. That seems to be conflicting information. Yeah, I don't know. But it might be also a sign that there are other image optimizations that you could do to decrease the file size. But it never mentions file size. Just type. They're all PNG, which is JPEG. Yeah, JPEG 2000, that seems like forever ago. OK, I'll take a look at that. Interesting. Cool. OK, let me run through some of the submitted questions, and then we'll have more time for questions from you all along the way as well. I'm managing one of the biggest news sites in our country. I want to improve internal linking for news, and I'm thinking about including latest news section in the sidebar so that the latest articles are linked not only from the home page, but also from most pages on the site as well. Is this a good approach, or is only linking from the home page enough that these, whoops, enough and those sidebar links won't necessarily move the needle or pass additional value? Usually, this is a good approach. If there are new or important pages on your website and you link to them from across the rest of your website, then that helps us to better understand that you care about those pages, and you want them to be crawled and indexed as quickly as possible. Usually, when it comes to news sites, we focus a lot of our crawling on the news site map that you have and on so-called hubs, which are usually the home page, the category pages, pages that we can refresh very quickly where you link to the individual news articles. So probably for a reasonably-sized news site, we should be able to pick up all of the new content that way already, so it's more a matter of kind of giving us a signal for the importance of those other pages. So that's something where, if you think that these new articles are not performing as well in search as they could be, then linking to them like this probably makes sense. If you have other articles that you care about, that you want to be more visible in search, and that could be something that is older, could be something that maybe is a cause that your site cares about, maybe it's important information that you need to share for the long run, then I would definitely also include that in something like a sidebar or footer links. So I think, overall, it's a reasonable strategy. I think, especially for non-news websites, it definitely makes sense. So if it's an e-commerce site, for example, and if you have new products or related products, you link to those in the sidebar, that's a fantastic way for us to get that information. For news site, we probably can already find those pages in other ways, and it's more about giving a subtle hint of importance. What's the best practice for anchor text wording on internal links as well as external links? For example, using the website name, the blog post title, exact match, or LSI keywords. So first of all, we have no concept of LSI keywords, so that's something you can completely ignore. I think it's interesting to look at LSI when you're thinking about understanding information retrieval as a theoretical or computer science topic, but as an SEO, you probably don't need to worry about that. With regards to internal links, you're giving us a signal of context. So basically, you're saying, in this part of my website, you'll find information about this topic, and that's what you would use as the anchor text for those internal links. So that's something where, on the one hand, usually that's something that you want to give that context to users as well. So the internal links that you would use for users usually match what you would use for SEO as well. So that's something where, luckily, there's a nice overlap there. With regards to external links, if you're linking out to other people's websites, the same thing. It supplies some context why people should go and click on this link, what kind of extra information it gives. With regards to links to your website from other people's websites, usually that's something you wouldn't have control over anyway. So I'd be kind of cautious about what you need to have there. Second part of the question, is it true that the more links you have on a page, the more page authority gets divided amongst the links, if so, is there a range to be within? So we do use PageRank. We don't use page authority in our systems. We do use PageRank as a way of understanding the internal structure of a website a little bit better. And it does take into account the links on a page. And we forward the signals across these pages. But it's not the case that there's any optimal number of links that you need to have on a page to make that work well. Essentially, if you're creating a website that has a reasonable structure for users where they can navigate around your website in a reasonable way, then that would work for search as well. And especially if you're getting started, then that's something where I wouldn't necessarily focus on the number of links on a page and use that as a metric to try to figure out how to keep your pages running. I think at some point, if you have a very large website and Google has trouble understanding the structure or has trouble crawling it properly, then the internal linking structure is certainly something to look into. But especially with smaller newer sites, that's something you probably don't need to worry about too much. John, can I ask a follow-up to last question? Sure. Actually, I just want to know if I am linking to other pages on my website from an article, does Google try to understand the other article which I am linking to by looking at the article from which I am linking? I mean, Google say this is like 500-word text. From here, you are linking to this page. So we may try to understand from 500-word, get some information about that page which I am linking to internally. Let's Google do that. A little bit, but not so much in that random words on a page will impact how linked pages are handled. So we take that into account with regards to understanding the context of the pages that you have there. Usually, the anchor text is the most important part there. With images, it's something where we do take into account the content around that image. So that's in the direction that you're saying there. And in a case like that, any random text on a page will count towards that. But more really around this image or around the link there, what kind of information is available. So just for better understanding the page which you are linking to? Yeah, exactly. And you can kind of guess some of this if the destination page is blocked by robots text. Then there are still some situations where we would show it in search, even if it's blocked by robots text. And we would only be able to show it in search based on the links that we have to that page. So that's one way to kind of see, well, what kind of information is Google picking up from those internal links? OK, thank you. Sure. My blog has been completed since two months. I posted content in January. And in starting it was an index. But now it's not in Google anymore. What is the reason for the de-indexing of the post? And how can I get it back into Google? I don't know. It's really hard to say without any additional information there. So the one thing I would recommend in a case like this is go to the Search Central Help forums, post your URL, some keywords that you are targeting there, and try to get some advice from the community. Sometimes there are technical things that are wrong on a site that you need to fix to make it so that we can index it properly again. Sometimes it's more a matter of quality of individual pages or of the website overall. And that's something where the feedback is sometimes hard to take, but it's sometimes really useful to get that feedback anyway. So I would make sure to just provide all of the information that you can give there with regards to the pages, the rest of your site, what all has been happening there. If there's a web spam manual action that took place with regards to that page or the site in general, you would see that in Search Console. So probably you've seen that. For the most part, if you're using a common CMS system, then probably the technical details are kind of OK. And it's really more a matter of the quality side of things. Our log files show that Googlebot finds a lot of JSON files, even more than normal pages. Might these kind of pages exhaust our crawl budget? Does Google crawl API routes? Or is this somehow internally prevented? If we disallow our API in robots text, how does that affect the XHR request? Would they still be able to deliver content? So super good question. Yes, all of these requests do count towards the crawl budget. So that's something where essentially every request we make to the server that goes through the Googlebot infrastructure is something that we would count as a request that we make. I mean, it is a request. And we would try to limit that based on the technical limitations that we feel apply to your server. And based on that, we might say, well, we can get more or we can get less content here. So in a case like this, you're probably more looking at the technical limitations when it comes to crawl budget and less the crawl demand side of things. And it's something where if you just look at the server logs and you see a lot of JSON files that are being requested, it's not necessarily a sign that something is broken. It's not necessarily a sign that the crawling is limited due to these JSON requests that are made. It's just, well, we happen to make a lot of these. And it could be the case that we make a lot of these requests, but we can still crawl enough of the normal content. And it doesn't really affect the normal crawling and indexing of the site. So that's something I would try to figure out ahead of time. There's no simple way to see that. There's no information in Search Console directly that says, oh, you've exhausted the technical limitations that we think apply to your server. So that's something where you almost need a little bit of experience and a little bit of guessing when looking at the graphs and looking at your servers and testing individual URLs to figure out, is it possible that Google is running into limitations with regards to what it can crawl? Or is it possible that Google is crawling as much as it wants? And it's OK with that. So that's the first step there. With regards to blocking these JSON files, if you do find out that these requests are causing problems, I mean, one approach is to speed things up. So the technical limitations are less of an issue, which could be to move some content into a static CDN somewhere so that those requests are easier or cacheable, that they go a little bit faster than the rest of the request to your site. That might be an option. If you decide that you do need to block the crawling of these JSON files, then you just need to keep in mind that this does include rendering of pages that try to embed these JSON files or that request these JSON files. So if there's content on your site that is only visible after rendering pages that request these JSON files, then that content will no longer be indexable because we can't get to those JSON files anymore. So that's the downside of blocking things there. It's similar if other people on other websites are using your APIs and using your APIs to generate content for their pages. If you block those JSON files from being crawled, then those pages on their site won't be able to get that content indexed. It might be that you don't really care about that, and that's fine for you. But it's kind of something to keep in mind there. Yeah, I think. Hi, John. Pretty much it. Yeah, go for it. Yes, John. We have an event discovery platform, olimarch.in. And we are facing some issue related duplicate canonical thing. So the issue is Google is picking the wrong pages instead of choosing original pages. OK, so let me add I'm from the same team. So basically, we have 20,000 cities, and each city has different events on them, basically listing the events. So since a few months we are seeing, Google is picking up wrong city instead of other cities. If you search about events in Washington, it will show result of San Francisco. And when we check canonical, it has picked up wrong canonical. And the whole page and content, everything is different. Still is picking up whole different city for around 2,000, 3,000 pages are affected like this. OK. There are two possible things that I've seen that could be playing a role here. And the first one depends a little bit on the way that you have your site set up. I didn't check in this case, but if you're using JavaScript to generate some of this city level content and for whatever reason we can't process the JavaScript properly, then it's possible that we see more of a generic page for some cities. And then we could say, well, this generic page is the same as that other generic page. And then we treat them as duplicates. And we pick one of them as canonicals. That's something where you could probably recognize that fairly quickly if you use view source on the page and you see, well, it posts in JavaScript. It doesn't have in the HTML the actual content from the individual cities. You can double check some of that with the Inspect URL tool as well in Search Console to see what is the content that Google picks up after rendering. The tricky part there is if it's really with JavaScript, sometimes there are weird flaky issues, depending on the server, depending on the setup that happened where sometimes we can render it properly, sometimes we can't. And that's something that's sometimes a bit hard to judge if that's happening or not. The other thing is if it's not a JavaScript-based site where you're pulling in the content with JavaScript, this kind of duplicate detection can still happen even if the HTML content is different. So what tends to happen on our side is we have multiple levels of trying to understand when there is duplicate content on a site. And one is when we look at the page's content directly and we kind of see, well, this page has this content. This page has different content. We should treat them as separate pages. The other thing is kind of a broader predictive approach that we have where we look at the URL structure of a website where we see, well, in the past, when we've looked at URLs that look like this, we've seen they have the same content as URLs like this. And then we'll essentially learn that pattern and say URLs that look like this are the same as URLs that look like this. Even without looking at the individual URLs, we can then sometimes say, well, we'll save ourselves some crawling and indexing and just focus on kind of these assumed or very likely duplication cases. And I have seen that happen with things like cities. I have seen that happen with things like, I don't know, automobiles is another one where we saw that happen where essentially, our systems recognize that what you specify as a city name is something that is not so relevant for the actual URLs. And usually, we learn that kind of pattern when a site provides a lot of the same content with alternate names. So with an event site, I don't know if this is the case for your website. With an event site, it could happen that you take one city and you take a city that is maybe, I don't know, one kilometer away. And the events pages that you show there are exactly the same because the same events are relevant for both of those places. And you take a city maybe five kilometers away and you show exactly the same events again. And from our side, that could easily end up in a situation where we say, well, we checked 10 event URLs and this parameter that looks like a city name is actually irrelevant because we checked 10 of them and it showed the same content. And that's something where our systems can then say, well, maybe the city name overall is irrelevant. We can just ignore it. So what I would try to do in a case like this is to see if you have this kind of situation where you have strong overlaps of content and to try to find ways to limit that as much as possible. And that could be by using something like a rel canonical on the page and saying, well, this small city that is right outside the big city, I'll set the canonical to the bigger city because it shows exactly the same content so that really every URL that we crawl on your website and index, we can see, well, this URL and its content are unique. And it's important for us to keep all of these URLs indexed or we see clear information that this URL you know is supposed to be the same as this other one. You have maybe set up a redirect or you have a rel canonical setup there. And we can just focus on those main URLs and still understand that the city aspect there is critical for your individual pages. So that's kind of the approach I will take here. I'll also pass this on to the team internally so that they have an example of something where we're picking it up wrong and we could be doing a better job there. But I'd still try to see if there's something that you can do on your site as well to try to limit this kind of overlap with multiple URLs. John, can I just say, if you want to stick the URL into the chat, you know, quite a lot of experience in the geographic event sites, as you know. So we can have a look at it as well. Of course, yeah. Rishit, if you want to just paste it here. I just dropped the URL in the chat. One more thing that I have noticed that there is some pattern that the smaller number of cities, I mean, in length, like four or five character length cities are affected the most instead of the larger name cities. Now, that's something that could also be happening there. And that I mean, our systems, when they try to understand the duplication across URL patterns, it sometimes picks up weird, weird things there. So especially if you mentioned shorter city names and longer city names, I could imagine a case where you have abbreviations as well for the same city. And then we might learn, well, the shorter version is the same as this longer version. Therefore, we can do that more likely with shorter URLs. But I don't know. Maybe some examples, if you could post them in the chat, then I can pick those up as well and forward them onto the team. Or Rob has some tips. He's been working with EventSight since forever. Sure. I've been brought up some things. Cool. Let me just see what else we have. I saw I have a bit more time we can hang around after the recording stops as well. Let's see, one question here is someone has a bunch of XML sitemap files, and two of them have a status of can't fetch. Sitemap couldn't be read. The files are valid. And why don't they work? It's hard to say. That's something where it would be useful to have specific example URLs. And one way you can give us that information is maybe in the help forum, so to post some of the sitemap URLs that are working and some that are not working. The folks in the help forums can escalate individual issues as well so that Googlers can take a look and see if there's something on our side that's maybe blocking that as well. I have occasionally seen these kind of cases where you have a bunch of sitemap files, and some of them work, and some of them don't. Sometimes they're just technical quirks on the server side that are happening. Sometimes there are weird things on our side that are happening. So it's sometimes useful to look at the specifics. One thing I have seen is sometimes just changing the URL of the sitemap file kind of resets Google's opinion of that URL and gives us a chance to take a look at the kind of new sitemap URL. So that might be kind of a tricky workaround. Cool. OK. Let me take a break here with the recording. And I'll stick around for more as well. So if any of you want to hang out a little bit longer or chat off the record, you're welcome to stay. If you're watching this on YouTube, thank you for watching. And if you'd like to join one of these events in the future, make sure to watch out for the event listing on our YouTube page or subscribe to the calendar that we have on the Search Developer side. All right. With that, I wish you all a great weekend. And see you all maybe next time.