 All right. Welcome, everyone, to today's Webmaster Central Office Hours Hangouts. My name is John Mueller. I am a Webmaster Trends Analyst here at Google in Zurich. And part of what we do are these Office Hour Hangouts, where anyone can join in and ask any kinds of questions around websites and web search. And we can try to find some answers for you. A bunch of things were submitted already. But as always, if any of you want to get started with a question of your own, that's been burning on your mind, feel free to jump in now. I could go ahead, I guess. All right. Take it away. This is in regards to actual sitemap handling for very large websites, 100,000 millions of URLs. And the website is in the classifieds areas. So there's a lot of new URLs popping up, like every minute, every few seconds, something like that. So obviously, there's a documentation on building a sitemap. You can update it dynamically, as you should, and then Google to let the sitemap has been updated. What do you do when that update frequency is incredibly large, and every few seconds you get a new URL or something like that, is this sitemap still a good way to notify Google of new URLs or giving that it's not a publisher? So if you cannot really use the, I'm not sure if you can use the news kind of sitemap, because I know that's also an option, but more for publishers. So what would be the best practice here? You can definitely still use a sitemap, or you can use an RSS feed. I think those are kind of the directions I would go. The one thing I would try to do is maybe split it up into parts where you have the recent content and kind of the more stable or longer form content, so that you don't have to submit all of your sitemap files every time there's a change, so that you have something like a sitemap file for the last day or for the last couple hours, and you just resubmit that one when there are updates that are happening. And then over time, when a URL stays around for longer, you can move it to one of the more stable sitemap files on your site. But essentially, you have kind of one smaller file that you submit with the regular updates. With an RSS feed, that kind of happens automatically, because the RSS feed only has the last couple updates in it. And with the RSS feed, you can push those to Google as well with PubSubHubbub or Web Push, what it's called now, to kind of send those updates a little bit faster. But that's kind of the direction I'd go. I wouldn't try to update all sitemap files all the time and just send all of them again, because that's too much work on your side. And we process all of the millions of URLs, and we only find 25 that are new. So you might as well just send us those new ones separately. OK, so what would be a good minimum frequency for these kind of new URLs? Again, giving that we might have like 50 URLs a minute or something like that, 50 new URLs a minute. I would submit them once a minute maybe, once every couple of minutes, something like that, so that you have a reasonable set, but you're not pulling Google constantly with submissions. And the other one can be once a day, the bigger one once a week. And regarding the bigger one, that will likely also have a lot of classified ads that are expiring, so they're no longer available. Is that fine if they're still in the sitemap or that day and they disappear the day after? So that's not a big problem for Google. I think especially with classifieds which have a specific runtime, I would use the unavailable after meta tag to let us know that this is something that'll be valid for the next week or whatever. And then that's something that we can take into account a little bit faster rather than having to refresh every page and then check for the no index. OK, so if you had to choose between the sitemap version and the RSS version, is there any benefit to it? I don't see any big advantage either way. No, it's like whatever is easier for you to generate. That's kind of what I would focus on. We'll try one of the versions, see how it works out. Take it from there. Thanks. Cool. John, I have a tangential question on that, particularly to the unavailable after. I work in the automotive industry and we're seeing a lot of vehicle detail pages that remain on the website long after the vehicle has sold. And then it's kind of muddying the waters because each of those product pages essentially has the brand, the manufacturer and the make, or sorry, the make and the model of each one. And so we're ranking for those make model keywords. If we were to put an unavailable after, say, a week from today, would the crawler come back and check to see if it's changed before it hits that date? And if we change the unavailable after date to then extend it, could we roll that so that? OK. That should work. I mean, you can definitely change the unavailable after date. And if we re-crawl that page then and we see that it's still there, then we'll still keep it in. So I think that might be an option. In general, though, with a lot of these things, I think you have to assume that sometimes we will try to send people to a page that doesn't exist anymore, so catching that in some kind of a user friendly way is also very important. We have redirects that go to a search result page or a soft 404 afterwards. So there is a fallback. I just want to make sure that we have the most efficient line of defense first. And then if that fails, then we have a fail safe and that it would all still be customer kind of approved and friendly. That sounds good. Cool. Hi, John. Arnoldo here. Hi. How are you? Colin, in relation with the case we have opened for IKEA in a previous session or agency in Germany, they contact you through this forum. So now we are in a process of cleaning out basically a lot of old content. We are just doing a cleanup. But we still see that Google ignored the German language version and ranked the Austrian. And then in Search Console, we see also that the referral pages are like third party external spammy domains, which is weird. And that is the behavior that we see. But we've been doing basically checking all the basic stuff. We still see that Google don't catch the German version yet. Now, sometimes these things take a while to settle down. So especially if there used to be or if there still is the same content in the same language on multiple URLs, then it can happen that we pick one of the country versions as the canonical and we show that one in the search results. But I think I looked at it with the team after the last Hangout where this was mentioned. And it sounded like that's something that the team is looking into to see if we can speed that up in general so that it doesn't last this long for sites in the future. Yeah, I understand. Thanks. The other behavior that we see is that Google is actually showing on SERPs like old platform, like URLs like sites that we migrated since two years ago and then also back in March, we did another migration. So it looks like you guys keep these old URLs as a fallback or why is that happening? I don't know which exact URLs you're looking at. But in general, there are two main reasons when this happens. On the one hand, when the canonicalization from our point of view is not completely clear, so if we're not perfectly sure which one of these URLs from the set of pages that we think belong together is the right one to show, then that's something where we might pick one which you think is like an older one or that we shouldn't have picked. And that's something where we use a lot of different signals to try to figure out which of these pages to show. And sometimes if those signals don't match, then we have to kind of make a judgment call or rather our algorithms do that. So that's the one thing. And the other time that I see this happening fairly frequently is if you explicitly look for the old content. So I don't know if that's what you're seeing. But for example, if you move from one domain to another and you do a site colon query for the old domain or you search explicitly for the old domain or the old brand name or something like that, then we'll still show you the old domain even though we've moved everything over to the new domain. And that's something that can happen for, I think, several years going forward from the past where if you search for something that has moved a couple of years ago and we think you're explicitly looking for that, then we'll try to show it to you because we're trying to be helpful. But from kind of an SEO point of view, from an analytics and tracking point of view, you don't want Google to be helpful. You want to see the kind of new thing. But that's sometimes the confusing setup that happens. And if they're redirect setup from the old one to the new one, then even if users see the old one in search, they'll make it to the new one. And it's not that the ranking would be any different if we pick the new URL by default. Would you recommend right now we have the hreflang implementation on the side maps? Would it help to have it on the page? Or it would not make any difference? It wouldn't make any difference. If we see it in the sitemap and it's the right URLs in the sitemap file, that's exactly the same from our point of view as if it's on the page. OK, perfect. Thanks. Sure. I'll keep joining here and see how this developed. Thank you for your answers. Thanks. John, in a space where you've switched domains, would clearing the cache then remove those index pages from the previous domain? No. So I assume you mean removing the cache tool in Search Console? Yes. Yeah. Now, that wouldn't change anything. That's basically it just hides the cache page from the search results and removes the snippet. It wouldn't change anything from the indexing side. In general, the URL removal and the cache update tool, they don't change anything from indexing. They just try to apply a band-aid in the search results when someone searches for it. OK, would removing the old domain completely shutting it down then remove the results for the domain? Yes. It would remove those results, but it would also prevent you from getting any of the traffic if we accidentally sent people to the old domain. So that's something where I would recommend just keeping the redirect up. And that's something over time we'll pick that up. The tricky part I've seen is when you change your domain name and people used to search for your domain name specifically because maybe the domain name is almost like a part of your brand, then those are cases where if someone searches for the old domain name, we'll still show the old domain name. But if you look at the Cache page for that URL, then oftentimes you'll see we've actually indexed the new version. We're just showing the old URL in the search results because we think that's what people were looking for. Does it maintain the old metadata, the old description, or will it appropriate the new domain title and description? Yeah, it takes everything from the new domain. So if we've switched indexing to the new one and we just show the old URL, then all of indexing is based on the new one. The ranking is based on the new one, all of that. So it's really just the URL that's shown in the search results. OK, let me run through some of the submitted questions. And if you have more questions along the way, feel free to jump on in. Hopefully we'll have some time towards the end as well to go through some other live questions. So some of these are pretty long. I'll try to shorten them a little bit. The first one is we have over 3,000 articles in our help section. And we want to make them available in 25 languages. Would using the Cloud Translation API hurt our website? So of course, we'd use the Translation API markup and warnings. Would these articles be considered low quality? Is that too many articles? We can't do this manually. So first of all, I was not aware of the Translation API markup. I looked that up. That was pretty interesting to see. That's kind of a lang attribute that you can add to the pages or to elements on a page when they're machine translated, which helps our systems to understand that this is actually machine translated content. We shouldn't use it to learn further translations. So that's pretty cool. So from a purely technical point of view, there's a bit of a split, I would say, within Google with regards to what we'd recommend doing there. On the one hand, from the webmaster guidelines point of view, we might consider this to be automatically generated content. And we'd say, well, you shouldn't allow automatically generated content to be indexed, especially if it's lower quality content. I think with machine translation, it's kind of reaching a point where machine translations are actually pretty good. And it's no longer the case that machine translated content reads like gibberish. And you can barely guess what the meaning is. But actually, it's fairly reasonable translation. So from that point of view, you could argue either way and say, well, this kind of content is reasonable enough for me to stand behind as something that I would publish on my website. And in that case, that might be an option for you to say, well, I'll take these and run it over the articles that I have and generate it for the languages that I think are important for our users. That might be something to take a look at. On the other hand, especially when we look at the quality of a website overall, we do look at the quality overall. And if you're taking 100,000 articles and you're running translations and 25 languages over it, then it's going to be really hard for you to confirm that the quality that you're generating like this is actually high enough that you'd be able to stand behind it and say, well, this is what I want my website to be known for. So that's something where I would take this step by step and think about it incrementally, try things out, test some languages where you have testers who can help you to double check that the localization is really actually useful translation and not just like you can kind of guess what the meaning is translation. And if you can determine that those languages for specific articles on your website are actually pretty good, then that might be something you'd want to set to be indexable. On the other hand, if you're really unsure if this is something that you want to have indexed for your website to kind of stand behind, then that's something where maybe you'll set it to no index or you'll use just the JavaScript widget so that it doesn't generate any separate pages for your website. So that's something where there isn't this by default behavior that we would say, oh, if you use this kind of translation, then we'll think your website is really fantastic. But really, you need to double check that yourself. And that's something that's sometimes a bit hard to do. So just blindly going and saying, I have 100,000 articles and I want 25 languages and hitting the button to generate all of those, that's probably not the right approach. But rather, you want to take this step by step and make sure that you're actually creating something that is useful for your users that doesn't come across as gibberish, where if they come to your website and they see this localized version, they're like, this doesn't make any sense. This website is more like spam rather than actually something reasonable. Our website focuses on troubleshooting and I often find links getting posted on forums with foreign language or non-English forums. They're all relevant posts. Is it negative in the eyes of Google? The language on my website is 100% English. So that might be perfectly fine just because people in other languages are referring to your content doesn't mean that that's necessarily bad. I think in general, that's actually a good sign. If you're creating something so useful that people refer to it, even if it's not in their own language, then that's usually a good sign. So from that point of view, I wouldn't worry about this, but rather see it as a kind of a positive thing. It might even be something where you go further and say, well, lots of people in these specific languages are referring to my content. Maybe I can do something on my website to cater my content better to them even. But it's definitely not something where you'd look at it and say, well, these links are coming from foreign websites. Therefore, I need to disavow them or I need to block them somehow. It's perfectly fine and natural to get links from all kinds of websites. It's more of a measurement question in Search Console. We have a client that has a redirection based on IP. So when someone searches for their brand, they will be redirected to sometimes even a different domain than the one showing in the search results. Where is the click counted? Where is it counted? So if we show something in the search results, then we would track that there in Search Console. So Search Console itself wouldn't know what happens after someone clicks on a page in the search results. In analytics, you might see that differently. If you're tracking kind of the user-facing analytics, then that might be different. But in Search Console, that would refer just to what we show in the search results and which ones people clicked on there. OK, the problem is that the search term is HBO and we're working with HBO Nordics. The first result when you search for HBO from Sweden is HBO.com. We think most of the users clicked there, but Search Console data shows over 50% click-through rate on the Nordic domain, the HBO Nordic domain. So it feels kind of strange to have people clicking on the second result when the first one is what they're searching for. Is it possible that it's double counted on? No, that shouldn't be double counted or anything like that. I don't know the query and which languages you're seeing this in, but what can sometimes happen is that we show an English search result for something generic like that, as well as a local search result. And it might be that users are just seeing, oh, this English result and kind of the result in my own language, and they click on their own language version. Because it's kind of tricky with a query like HBO where we wouldn't be able to tell which language the user is actually searching. Yeah. OK. Sure. That might also be something where using hreflang would help you, because then we would be able to take the user's language settings and try to show the right version of that site. And that's something that you could do, for example, just for the homepage or separately for the homepage from the rest of the site, so that four queries which are very generic, we'd be more likely able to show the version that matches the user's language directly. OK. Thanks. Sure. All right. And now kind of a structured data question, or I guess a tricky one. So when you search for a half dome tent, the top result is the old product page, which includes a call out to kind of see the new version. And there's also a canonical on that page pointing to the new version of the product. And I think the question kind of goes into would using structured data in any way help to kind of show the newer version rather than the older version. And I took a quick look at some of the URLs that are involved with this. And essentially, what is happening is, on the one hand, we struggled to see the connection between the old URL and the new one because it's not that clear of a situation that these URLs are exactly the same content. So that's something for, from canonicalization, we're kind of unsure if these actually belong together. And the other part that's coming together here is that for canonicalization, we use a number of signals. So we do use the rel canonical on the page, which is something that's specified well here. But we also use things like internal linking, external linking, sitemap files, all kinds of other sources as well. And I assume if you take a URL that is fairly well established and you create a second URL with a product that kind of replaces the first one, then that established URL is going to remain visible in the search results for quite some time until we've really learned that the new URL is kind of the better version for these kind of search results. So that's something where structured data probably wouldn't change anything there, so in particular, using something like successor of or predecessor of, that wouldn't change anything from our point of view. It's really just that canonicalization decision where we have a lot of kind of collected signals for the old URL and not really a ton of good signals for the new URL. And we struggle to connect those two completely. One thing you could do is redirect from the old version to the new one. That would help us to figure this out a lot faster. But at the same time, if you want the old product to remain available in the sense that if people search for the old product, they can find replacement parts or kind of find manuals, those kind of things, then you don't want to completely remove the old product. The solution that we generally recommend for this general kind of problem where you have one product and then you have a replacement for that product is to reuse the old product URL for the new product and move the old product content to kind of an archive section. That way, you kind of build upon the success of your old URL and you add the new content there, kind of the new product, the new product description, new pricing, or whatever you have. And you still have the old product information and you just move the old product information to an archive section where it's a little bit less visible, kind of less strongly shown in the search results because it's a new URL. So that's kind of the general situation or general direction that we would head with something like this. I imagine for e-commerce sites that's really kind of tricky because it's hard to kind of move one product to an archive section and reuse the old URL with maybe an article ID and things like that that are associated with it. But that's generally the direction that we would go. We would also use this for recurring events. So if you have something like a yearly conference, then instead of creating new URLs for every year, then have instead use one stable URL for the conference and move the previous years to an archive section. So that kind of in both of these situations, you're building a stronger and stronger URL for the persistent version for that product. And you're moving the old things off to URLs which are a little bit weaker within your website so that they're less emphasized in search. And structured data, I don't think structured data would play a role here at all. So using kind of this setup with regards to structured data of kind of like saying, well, these are connected like this, that's not something that we would use at all for this kind of canonicalization or figuring out which one of these URLs is the one to show at the moment. Thank you, John. Sorry, go ahead. I actually wanted to ask a structured data question. I thought I put it in the comments and I'm not seeing it anymore. So I noticed that some of the Google structured data requirements can be a little bit more requirements there than what schema.org requires. So I work for an educational institution and we want to have content structured data around that talks to our degree programs, especially for use in Google colleges and universities. But I noticed that in the structured data list, there really doesn't seem to be a good type for full degrees. In fact, some of your structured data types specifically say it's not for full degrees. Do you have any recommendations there, especially given that sometimes when we test out some of the schema.org structured data types, we get notifications from Search Console that, hey, this thing is not parsable because it's not actually Google's structured data type. Yeah. So I don't know specifically about that kind of structured data, but in general, it's certainly the case that within schema.org, there's a lot more structured data that's available. And we only take a small subset of that and use that directly for the rich results and the search results. If you use other parts of schema.org, which we wouldn't use in the rich results, we would still try to understand that. But it's not that we would show it in any particular way in the search results. So kind of going past what we would use directly is certainly an option. But I think for the most part, you wouldn't get any visible effect from that. So that's kind of the starting point there. Within the structured data testing tool, I believe the structured data testing tool sticks a little bit stricter or aligns more with the schema.org markup. And the rich results test is really based on how Google would show that in the search results. So it only uses a subset of kind of the general structured data that we would find. With regards to which one to best use in a case like yours, I don't know offhand. So many different types. But I would generally try to, first of all, see if there's a type that is actually shown in the search results that matches what you're trying to achieve. And then focus on that, which would be what we would have documented in the developer documentation for search. And if there's nothing there that works for you, then you can use the schema.org markup. But I wouldn't expect a lot of visible results from that. So in particular, we'd use this to better understand those pages. But if we can already understand that this is kind of like a course or there's information about an educational setup thing here, then that's something we probably already have that information. And we don't need a lot more information about that to be able to show those pages in search, because we're already mapping them to the right queries. Whereas if it's kind of ambiguous, then that's something where extra structured data helps us a little bit. Yeah. I think I was really thinking about it, especially in terms of Google Colleges and universities, assuming that there would be a heavier reliance on structured data for that application within Google. And I didn't know if that was something that, in my research, I haven't found anything that specifically says yes, but I kind of made that assumption that that would be used moving forward. I don't know. So the tricky part is I think that's something that we only show in the US. So that's something where I don't see them in search, and it's really hard to get some firsthand experience with that. But I don't know exactly how we would show that or where we would get that from. But that's something where if it's not documented in our developer documentation, then I'd assume that we don't use the structured data there directly. Great. Thank you. Sure. OK. Is it true? Oh, go for it. Me hi. I have a quick follow up to that example you gave earlier with the products being the same URL being reused for products that get out of stock and things like that, events. I was also thinking about how you would apply that to the classified sites example I gave earlier. Would you be able to do something similar, keeping that most URLs are being created by actual users? So it's user-generated content. But it's likely that a lot of ads are very similar in what they have to offer. So when one expires, would it be possible to maybe redirect or use a URL canonical to add an ad from different users that basically sells the same product or service? Would that be a good idea? I think that might be a bit confusing for users, but having something like tag pages or category pages, that seems like something that would work better. Where if you have a category page for this brand of car and you swap out the classified ads that you have, so that this category page remains relevant for the long run, then that's something that we could probably pick up on and use like that. But for the individual classified ads, that seems tricky to determine that connection. So it's very easy to say, oh, based on this one keyword and the old classified and the new one, I would just redirect it to something else. I could imagine that gets a bit confusing. That could be. So having sort of listings or category or tag pages is probably a better way to kind of target those type of ads. John, a question for you about linking from those category pages and putting a relational tag on the links themselves. Because it's user-generated content, would you recommend putting the UGC relation from the category page to the actual description page, or is the UGC tag irrelevant? I wouldn't use it there, because you're kind of linking to your own content. And within the classified ads of users' ad links, then that's something where I'd use the rel UGC. So it's not kind of for situations where you're linking to user-generated content, but rather where the user-generated content links to other places. Great, thank you. OK. And now an HTML5 question. Is it true that HTML5 semantic tags, like main, article, et cetera, are very important? One SEO expert said that HTML5 structure is used by Google for fast understanding of the page content before analyzing hundreds of other factors. So we do try to understand the structure of a page, but we can understand the structure of a page in lots of different ways. So it's not that HTML5 section tags are something that we would use specifically when it comes to SEO. And it's not that you have a ranking advantage over other sites if you use things like main or article elements within your pages. So I think it's good to use proper HTML in general so that it's a clear page. It works well on lots of browsers. It works well for users with disabilities. But it's not something that, from an SEO point of view, we would take into account. And one of the reasons why this is sometimes, this is kind of the case, is that these technical details are things that users often don't even notice. And it wouldn't make sense for us to rank pages based on things that are essentially not noticeable by users in that sense. So that's something where you might load a page and it uses an old table-based layout and it hasn't been updated in 10 years, but it's still the right content, relevant content for the query that you are looking for. It wouldn't make sense for us to say, well, this other page has content that's kind of OK as well. And it uses HTML5 properly. Therefore, it must be a much better result for users. That's definitely not the case. So I think it's good to focus on clean HTML. It makes things a lot easier for your site in general. But I wouldn't see this as a primary SEO ranking factor in that if you're struggling with ranking, you need to fix your HTML markup, because in general, that's not going to change anything when it comes to ranking. Oh, wow, a long question, I think, with regards to purchasing website. Can you explain the situation that happens when you purchase an established website, merge most of the content into your existing website, and then 301 from the purchase websites pages to the migrated content? In principle, I would have thought that the final single website would be some of its parts. However, I've assumed that this is maybe far from the case. So in general, moving from one domain to another is something that's fairly straightforward in that we can take all of the old signals and forward it to a new domain. That's kind of the simple part of a site move. Similarly, if you move from HTTP to HTTPS, that's something we can just take everything one to one and pass it on to the next setup, the next domain, kind of the next protocol version. That's essentially the straightforward type of site move. But as soon as you do things like restructuring a website within the same website, like merging multiple websites into one website, splitting one website into multiple separate websites, that's where it gets a lot more complicated. That's where essentially our algorithms have to reprocess the whole website and understand what is this new website that we have or these new multiple websites, if it's split into multiple websites. And how do they fit in with regards to the rest of the general ecosystem on the web? How should we understand how relevant some of this content is? Which of these pages can be understood a little bit better with the new configuration? Which of these pages might be harder to understand with the new configuration? And that's a process that can take a significant amount of time. So in general, if you're looking at various changes on a website and one of the options is, oh, I will restructure everything or I will merge multiple websites or split one website into multiple websites, then it's good to keep in mind that those are long term changes that will take a lot of time to be reprocessed. You might see this as something that kind of slowly goes from one state into the other. You might also see it as something where it's like we start to see this complete restructuring and then we say, oh my god, everything is different. We have to be careful here and try to understand this new website first, where you see a significant dip until we're able to kind of stabilize on a new kind of better understanding of the website in general. So that's something which is really hard to predict ahead of time how these things will happen. I think it's just important as a site owner that if you're considering any of these options, that these are things that will take a lot of time and where you may see significant changes in fluctuations until things settle down into a more stable state. And that stable state doesn't necessarily mean that it'll be the same as before in that if you restructure a website significantly within the same website, you might see better results later on, because you have a cleaner structure. Similarly, you might see worse results, because maybe the new structure is worse. If you merge multiple websites, it might be that you have kind of a stronger visibility in the search results. But it might also mean that you're merging multiple things and they're kind of merging in ways that are clashing with each other, which are resulting in kind of a similar search visibility to before, where you had multiple websites showing. Now you have one website showing, but it's kind of shown a similar way in the search results. So this is something where it's really hard to predict ahead of time what exactly will happen. And it's definitely not the case that you can just blindly assume that this one plus that one will equal the new one, because you're creating a completely new website, which we have to essentially understand completely first. So that's something where I'm not saying nobody should do these kind of moves. Sometimes you have to do them just because things are changing within your business. But it's good to kind of be cautious about these kind of moves, and especially to see this as something that you don't want to do just to try it out and see what happens. So if you're aware of one of these moves needing to be done in the future, then try to kind of do that in one step so that you have everything moved over to the final state so that you don't run into a situation where, like, oh, I will merge everything first, and then I will split it off again, and then maybe I'll restructure part of this again, because all of those individual changes, they will require a significant amount of time on their own. So ideally, try to find the stable approach that you can keep for the long run and focus on moving things over to that. Is Zulu time for a news site map OK? So particularly with regards to publication date, so Zulu time is if you have a Z at the end of the time, which is essentially, I had to look it up, it's kind of what is it, GMT time, so essentially a specific time zone, which it refers to. From our point of view, using a specified time zone, like if you have plus and then a number of hours or minus and a number of hours is fine. Using the Zulu time is also fine. Those are both well-defined time formats that work well for us, so they're equivalent from our point of view. The examples that you have in the question are not quite equivalent because they're different times and different days. But essentially, you can use either one of these formats. You can also use some URLs with the Zulu time, some with the offset. That's totally up to you. The one thing I would watch out for here is to try to be as consistent as possible so that you don't end up in a situation where you specify one time in the site map and use a different time zone on the pages themselves. So that's something that we sometimes see, especially when it comes to news content on the pages themselves in the news article. You can also specify a time. If you specify the wrong time zone in one of these places, then we'll be kind of conflicted. Or if you specify the time zone in one of the places and you don't specify the time zone in the other place, then that's also one of those situations where we don't perfectly know what you need. So if you're using any way of specifying the time zone, then I would make sure to be consistent across your website so that it's really perfectly clear to us when we look at your pages. This is the exact point in time that you're referring to. Not that we have to guess like, oh, the server is located in this place. Therefore, probably they mean this time zone. So we'll guess that that's the case. Really kind of be as clear as possible if you want to specify something like this. We use Data Studio for several recordings. And now we recognize that URL impressions plus click through rate, and sometimes not even URL clicks sum up as visible in Search Console. How is this possible? What are we doing wrong? Is it possible to get the correct data in Data Studio? So I think there are a few things that are possibly happening here. It's hard to say exactly what you're seeing. So on the one hand, the fresh data currently isn't visible in the APIs and appropriately not in the Data Studio. I think that's also based on the API. So if you're looking at things from today that happened in the last week, for example, in the Performance Report in Search Console, then that would not match what you would see in the API. We're looking at ways that we can add the fresh data to the API as well in ways that don't confuse the consumers of the API. Because one of the tricky parts with the fresh data in Search Console is that this is data that's not really finalized yet, where it might be that we have to clean things up. And that's something that happens in the pipelines along the way. So sometimes you'll see the fresh data shows this many clicks and impressions for a period of time. If you look at that a few days later, you'll see a different number there. That's just because that data has been finalized at that point. And if we were just to blindly inject the fresh data into the API as well, then all of those people who are always trying to get the newest data with the API, they would be working with the fresh data, which could end up in situations where that data has even stronger mismatch to what is shown long-term in Search Console. So we're trying to find a way to make that a little bit easier. The other thing to keep in mind is that the aggregation of the counts that are shown above the table in the performance reports and the individual rows, which are shown, are aggregated separately. So it can happen in situations where the count on top is slightly higher than the count if you add up all of the rows. Sometimes that's due to the privacy filtering. Sometimes that's just due to the way that we aggregate the data. In general, the higher count is the more accurate one. So if you see a higher count in the sum above, then that's the one that I would focus on. If you see a higher count in the rows shown below, then that's what I would focus on. But that's something where the different aggregation methods that are used in Search Console, they can be a bit confusing in the UI. Sometimes we regularly have people ask us about that. But they're certainly also confusing if you're using the API and comparing the API results to one of those sets, either the numbers on top or the rows that are shown. So that's something where you might see differences because of that. That's actually a good official support article on how aggregation works, the property aggregation versus page aggregation if you take the rows and just look at the pages. So I found that to be useful as well. Oh, yeah, definitely. That's the other point, which also makes it tricky. Like the property and the URL and the query aggregation are sometimes a little bit different as well. It gets really hard when you have a lot of data. And all of these aggregations, they become pretty tricky, especially for larger sites. And one place where I've seen the differences more visibly is if you have a larger site and you look at a very small section of that site, then because those small numbers are a bit out of the aggregate from the larger site, you might see bigger percent-wise changes there. Oh, wow, we're kind of running towards the end of time. So I'll maybe shift things over to questions from you all before I have to jump out of the room here. Hi, John. Just a quick question about URL inspect in Google Search Console. The thing here is that because we actually have been through a couple of migration, so we take the same product URL and tested it. And then we found out that the current page that we have live doesn't have any canonical URL from Google. But the rest are pointing to a URL that doesn't really exist. So what is pointing to URL? So it's pretty much the same URL that is live without a trailing slash. So it gets a 301 redirect. So we don't really know how Google come about in picking that URL to start with, because it's never used on the site. I don't know. It's hard to say without looking at a specific example. If you want to copy the URL into the chat here, I can take a look at that afterwards. Yeah, sounds great. Yeah, I can do that. OK, cool. Yeah, super. And just a very quick question, another one. On referring page also in URL inspect, so we noticed that we are getting a referring page from a different domain that seems like a spammy domain that are redirecting a couple of times to our page. And Google actually referred that as the referring page. Shouldn't Google only pick the referring page than our domain only? No, if we can pick up a URL from other sources, we might show that too. But it's not going to be the case that this is negatively affecting your website, because it's like some spammy domain that's linking to your website, but rather it's just we happened to have initially found the URL there, and we started crawling from there. So it's not a sign of any kind of quality issue there. It's more from a technical point of view, we found it, and we picked up on it and tried to index it like that. OK, but if we disavowed it, for example, then it wouldn't change anything for those URLs that we've already seen. Because once we've seen URLs from your website, and we've indexed them and noticed that we can index them, then we'll continue to try to index them. If you disavow it, it basically just tells us we shouldn't be passing any signals to that URL. But from purely an indexing point of view, from the inspect URL point of view, that would probably remain there. All right, then you have things. Hello. Hi. Yes, I'm running a movie website, and we've been working with the shima.org review for quite some time. And it worked for like two or three years. But after the recent Google update, we keep getting warnings in our Google Search console that the review item is not supported, even if the markup is correct in the rich results test. And I was just wondering before we changed 900 reviews, what should we do? Is there any thing for movie websites that are not selling anything, but are just reviewing movies? I don't know, offhand. But I do know, with regards to the, I believe it's a review markup, or one of the other types of structured data markup, we started sending out more warnings about situations where we see that websites are using it incorrectly. So it's not that there is going to be a manual action. We're going to block these. But more, it's just, well, this isn't aligned with our guidelines. So we want to let you know that this currently isn't supported like that. And I would focus on the documentation that we have on the developer's guide and see if there is a type that matches what you're doing. But I don't know if there would be anything specific for movie sites, for example. OK. Thank you very much. Sure. All right. I need to take a break here. Someone waiting for the room. So thank you all for joining in. The next one in English I think will be on Friday. And on Thursday, we have another one in German lined up. So if you're keen on joining, feel free to jump in there. Thanks again for dropping by and hope to see you in one of the future ones. Bye, everyone.